Hacker News

points by jeroenhd 18 hours ago | 0 comments

Google has clearly flagged this as "not a security issue", repeatedly. It's a weird bug for sure, but what's the scenario here?

Correct me if I'm wrong, but the carrier configuration messages can normally only come from carriers. The demo APK sends a message to the phone itself, but sending SMS messages requires special confirmation.

Practically speaking, what's the risk?

[–] grapheneos 4 hours ago

Google committed a fix on June 15th and it was shipped in the security preview patches in mid-July. GrapheneOS shipped it in our security preview releases in July. It's in the upcoming November security bulletin but a patch was pushed to AOSP in October:

https://android.googlesource.com/platform/frameworks/opt/tel...

It's assigned CVE-2026-58882 and a Critical severity in the November 2026 Android Security Bulletin. We've had it listed as one of the patches included in our security preview releases since our 2026072901 release which you can see in the release notes:

https://grapheneos.org/releases#2026072900

Google mishandled the issue report. There was likely an internal miscommunication and they handled the report incorrectly. It's possible the issue was already filed internally and they meant to close it as a duplicate instead of WONTFIX. Closing it at all may have been an error.

[–] tyingq 16 hours ago

> The demo APK sends a message to the phone itself

That's not what the readme on the repo says.

"Install on a sender device, enter (or auto-fill from an active SIM) the target number, pick the sending SIM, and tap SEND CRASH SMS. Observe on the target..."

[–] MarkBlah 15 hours ago

Load apk, select which sim you want to use, enter Android victims phone number, hit send, it will crash telephony app and it’ll restart.. carrier will resend the text message as there was no acknowledgment crashing it again in a loop.

Only “fix” for this attack is to place SIM card in a non-Android phone to ack the inbound messages, or wait a few days of constant disconnects.

[–] ffsm8 14 hours ago

Huh, but then it's neither remote nor zero click if you need to locally install malware?

Or did I misunderstand you and can you input any phone number to cause this issue? If so that would sound more like a carrier issue then a android issue to me

[–] zamalek 11 hours ago

> Huh, but then it's neither remote nor zero click if you need to locally install malware?

The software is installed on the _sender_ device.

[–] MarkBlah 14 hours ago

Huh, Yes victims phone number, bug is in android. Carriers just send messages.

[–] whizzter 17 hours ago

Where does it say that it's carrier configuration? Looking through the page it mentions WAP and PDU, seems PDU from my skimming is just a part of encoding WAP messages, so basically anyone being able to send WAP messages onto the network will have the carrier happily retransmitting it unless carriers starts blocking them/filtering these incorrect ones?

[–] amluto 14 hours ago

Even if you are correct on the technical point, it’s still a security issue.

1. A carrier should not be able to render my device unusable in a manner that persists after I remove the SIM.

2. Dual SIM is a thing. One carrier should not be able to disable the other one.

(You do appear to be incorrect on the technical point as well.)

[–] rtkwe 9 hours ago

The carrier is just delivering a message your phone chokes on and then redelivers the message because your phone choked before it could ACK the message so as far as the carrier is concerned you never received it.

[–] zamalek 11 hours ago

> Practically speaking, what's the risk?

1. Revenge on an ex.

2. Send someone the packet, set up a situation where they need to call 911.

[–] cowlevel 11 hours ago

I'm not sure the details but there have been vulnerabilities in the past that involve sending invisible SMSes to people. I believe the usual "text message" is just one format of an SMS, SMS itself is more akin to ICMP with subtypes, and networks don't always filter them.

[–] ufmace 15 hours ago

It's not clear, which makes me skeptical that this is all that serious of an issue.

I'd like to know - can any devices actually put such a malformed message onto the carrier network? It probably requires at least a custom app that would never be allowed on an app store, if it's possible at all. And do any carriers actually let it go through their network and to a device like a normal message? It's entirely possible the malformed message would crash some software in the carrier's processing stack first and so never be delivered. And if it doesn't, they could easily add a check to block such messages. It's difficult to believe they don't already have some sort of protection against spamming tons of messages to any device. It's also entirely possible it works differently on different carriers, and some but not others might add blocks for this but not make a press release about it or anything.

This seems more like meh, minor bug, fix it quietly in the next Android release, not OMG the world is on fire to me.

[–] MarkBlah 12 hours ago

You sound like android triage team.

Apk provided can be installed on an attackers phone, you specify the msisdn (phone number) of victims phone, click send and it crashes telephony app of the victim.

Multiple messages may create a race condition that corrupts an SQLite database that stores message which stops telephony from functioning as a phone. WiFi will still work so I guess you can use it as a tablet as long as you don’t mind the constant dialogs popping up.

Tested in AU, US, DE and UK with 100% success rate.

[–] dns_snek 14 hours ago

> can any devices actually put such a malformed message onto the carrier network? It probably requires at least a custom app that would never be allowed on an app store, if it's possible at all.

The author has provided an APK that claims to do just that. Hacking tools aren't allowed on app stores, no, but that has no bearing on the severity of vulnerabilities they exploit.

> And do any carriers actually let it go through their network and to a device like a normal message? It's entirely possible the malformed message would crash some software in the carrier's processing stack first and so never be delivered.

Apparently, unless you're accusing the author of lying.

> And if it doesn't, they could easily add a check to block such messages.

Your ISP could block RDP but that doesn't lessen the severity of RDP vulnerabilities, shift responsibility, or lessen the need for the vendor to respond in any way, that's not how this works.

This is an Android vulnerability and it should be assumed that the carrier is indifferent, actively hostile, cooperating with law enforcement to carry out this attack, or someone might carry out this attack using an IMSI catcher.

> It's difficult to believe they don't already have some sort of protection against spamming tons of messages to any device.

20? I doubt it. Do you think the author is lying?

> It's also entirely possible it works differently on different carriers, and some but not others might add blocks for this

Indeed. What's indefensible is Google's classification that this isn't a security vulnerability.

[–] MarkBlah 17 hours ago

wap-push is a legacy protocol, it predates mms's, android can send it fine, ios just ignores them.

[–] vijaybritto 17 hours ago

If the carrier is compromised an attacker could destroy millions of phones and cause humongous economic losses no?

[–] Geezus_42 16 hours ago

Why would they do that when they could use that access to harvest tons of valuable data?

[–] pnt12 16 hours ago

In a war scenario, Russia would could destroy Ukranian phones for example.

For the lulz.

[–] Geezus_42 15 hours ago

Wouldn't it be easier to just takedown the carrier they've already exploited?

[–] kirth_gersen 14 hours ago

why not do both?

[–] int0x29 11 hours ago

Because keeping the phones down longer than 5 minutes requires the carriers to still be up and retransmitting un-acked SMS messages

[–] vijaybritto 10 hours ago

Bless your heart but the world is full of evil people, my friend.

[–] _trampeltier 18 hours ago

So you can allways trust the carriers. So then it's maybe a feature.

[–] jeroenhd 17 hours ago

I don't think carriers can be trusted per se, but if a carrier wants to interrupt your call, they can just kill the connection.

[–] mzajc 17 hours ago

I trust mine not to brick my smartphone on purpose, at least. Especially not using methods that leave traces of what was done.

[–] rvba 17 hours ago

a bad actor can hack the carrier and brick the phones the same way the fridges were hacked and bricked few weeks ago

perhaps even a rogue employee

[–] t_mahmood 17 hours ago

If that happens, I think the actors will have more serious things to hack around then phone-looping some poor souls

[–] DaSHacka 14 hours ago

Why would you assume that? Being able to brick a substantial portion of citizen's devices would be of great value to many adversaries abroad.

[–] izacus 12 hours ago

They could just... take down the mobile network without having to go through the hassle of bricking your phone individually.

And it's not that hard, bring down a VPN or some core routing service.

[–] DaSHacka 7 hours ago

But that's temporary, and phones can roam to other carriers. Bricking large swaths of consumer devices is a much more permanent effect, especially for non-phones (think modern cars, PoS terminals, and other devices with SIMs)

[–] izacus 12 hours ago

The carrier? You mean the company that actually routes and controls the emergency calls and other calls this DDoSes? And routes and controls all your data transfer and owns the cell towers?

How do you make calls without trusting them?

[–] jonathanstrange 17 hours ago

It seems to me that the scenario is that someone spoofing a cell tower can disable your phone practically forever and recovery requires expert interference. Maybe I'm mistaken, though, it's not clear from the description whether a spoofed cell tower would suffice and whether it needs to remain in the vicinity to repeat the attack often enough or whether sending 200 corrupt SMS messages in one go would suffice.