← back

Hijacking Netflix SMS

we all get those otp texts from our banks or other apps, right? like "your code is 4829" or "BofA: Sijan sent you $200.00"? what if someone could modify that? that's what i did with netflix's official phone number.

netflix uses the short code 68359 to send texts like:

"Netflix: 1234 is your temporary sign-in code."

at twilio's signal conference in 2019, netflix's director of messaging and contact engineering explained how deeply sms is integrated into their workflows:

"In addition to recovering passwords through email, customers can also do that through SMS. We now also text a message to the mobile phone number if they provide one to us and then they're able to finish a signup flow there."

(3:22–3:52 in this talk)

that means sms isn't just marketing, it's core to netflix's security and customer experience. they've been using this same number worldwide for years. so the impact is huge.

how it started

summer 2025. i didn't get any internship in my freshman year. i spent the first few months building web apps, designing UI, and messing with random ideas. basically, i love building things. but when i get bored of building stuff, i start exploring the other part of web. it's always fun when you get access to something you weren't supposed to get.

so i opened my terminal, plugged in my rooted pixel 6 via usb, and did the usual: adb set proxy, adb pull apk, jadx, burpsuite, frida to bypass ssl pinning, and started poking through every request the apps make.
if you've ever decompiled android apps, you know how fun it is. you can find free api keys, dev debug menus, weird endpoints, and sometimes entire unauthenticated systems.
you could download the top 100 android apps and find at least one with something exposed.

while looking at netflix's login screen, i noticed their "sign in with code" feature. it sends a 4-digit pin. it just felt like something might be wrong there. i was curious because most other companies use at least 6 or even 8 digits for login codes. seeing just 4 digits on netflix made me think the endpoint might be interesting to explore.

what happened next

i hit "sign in with code" and intercepted the login request in burp. i saw an androidAppHash value at the bottom. that's when things clicked.

Burp Suite showing Netflix login request with androidAppHash parameter
Netflix login request in Burp Suite

i'd seen those random 11-character strings before in sms from apps like instagram, whatsapp, airbnb, telegram, and always wondered what they were.

that was androidAppHash which is part of google's SMS Retriever API. it lets android apps auto-read login codes without needing full SMS permissions.

Diagram of SMS Retriever API sign-up and verification flow
Google's SMS Retriever API verification flow

the hash is supposed to be fixed. netflix's app actually hardcodes two values in the app itself:

Netflix app source code showing hardcoded hash values
Netflix's hardcoded app hash values in the source code

the problem was the backend. netflix's server wasn't checking that the incoming hash matched those hardcoded values. the sms templating service grabbed whatever value the client sent, dropped it into the message, and handed it off to twilio.

what that meant

because the service used the client value directly, i could replace the hash with any text. for example, "verify now at attacker.com".

send that to the public endpoint and netflix's real short code 68359 would deliver the exact message to any number i provided. no account, no session, no auth. just a public endpoint.

here's what the malicious sms looked like when it landed:

Screenshot of malicious SMS sent from Netflix's official number
The proof-of-concept SMS sent from Netflix's official short code

impact

the endpoint was not authenticated. an attacker could have used this vulnerability to distribute malware or attempt mass scale phishing campaigns because messages from that short code don’t get filtered by carriers or spam systems.

disclosure and response

i reported it to netflix through HackerOne on june 27, 2025. they replied fast, asked for more details, verified the issue, and awarded me a $X,XXX bounty. they later fixed the bug and migrated sms to a new short code (71907). their security team was professional and quick. huge respect.

final thoughts

never trust client input. even small stuff can blow up big when validation is missing. and as users, we shouldn't click random links just because they look official. if this was a message from a bank or payment app, most people would've trusted it instantly.