Blame heartbleed for the practice, which long predates ChatGPT and vibecoding. Human psychology is to blame. Only nerds are going to find CVE-2014-0160 triggering, but if I say heartbleed everyone who was there remembers.
> Only nerds are going to find CVE-2014-0160 triggering, but if I say heartbleed everyone who was there remembers.
That has more to do with the severity of heartbleed than the fact that it had a name and a logo. I've since seen a lot of vulnerabilities try to market themselves with websites, cute names, and stupid logos but I still don't remember them because they still just weren't big enough to actually be memorable.
agreed, we should all use gopher and block all web traffic, go back to text based systems, use single threaded operating systems and use token ring NIC's
Ah before www, gopher was used to try arrange information, similar to this page. Prior to that there were bbs’s where you dialed up to another computer.
Well, to be fair, you don't know it is until after you've gotten there. But also to be fair the other way, you can just click the close tab and move on with your life. But again to the other side, it sucks when N% of HN articles end up being closed within 2 seconds as you realize the author spent about 4 seconds writing a prompt and is now asking you to spend 5 minutes reading what they likely didn't even review themselves before hitting publish.
A bit like the postal system. Yes, it's meant to send physical letters and what not to my home, but it still sucks when I get ads that just goes straight into the trash. Yes, you're using the system as intended, but I still consider your business slop if you send ads to me this way.
This sort of thing can make sense in manufacturing where you want to clear evidence of tests run, etc. For example, it is common to run optical test suites and then program the optics within a phone to account for imprecision rather than attempt to manufacture for a lack of it. Source: Drinking in Dongguan with the head of optics manufacturing for the company subcontracted to produce the iPhone optics assembly some years ago.
WAP Push is a specially formatted SMS that triggers your phone to download a URL. Unfortunately the vuln here appears to hit at the SMS parsing phase, which I don't think can be turned off easily.
mind boggles, issue is they're swamped with AI slop and high number of findings, they're using AI assistance operated by a 3rd party to handle researcher submissions so many legitimate findings slip through the cracks.
That's unfortunate. They need to do some kind of triage then, I hope this doesn't mean that they're constantly busy now with equally bad or worse bugs, but I guess it wouldn't be too surprising.
False negative? I honestly don't know what we can do about it. If this is a real issue, maybe another llm will rediscover it and it eventually will get triaged right?
True, I should have written they misclassified it, should it work as advertised. If Google knows something that makes it not an issue, hopefully they'll let us know.
Ironic comment from someone who literally just submitted an AI slop report and went so far as to give it a website and cutsey name to attempt to feign legitimacy and skill behind the "researcher."
The "if" is doing a lot of heavy lifting. Can it do what it claims to do? LLMs are always hallucinating that they've found the most severe bug in software history.
> LLMs are always hallucinating that they've found the most severe bug in software history.
That is a function of the training data/method, like many of AI's problems. This doesn't stop it being a problem of course, but it shouldn't be a surprise.
Big bugs, like heartbleed, over the years have had breathy websites going over how serious the problem is because the problem was that serious, so the models associate that sort of wording with bug reports. Less serious bugs don't get the same excited treatment, repeated in many many places, so more measured descriptions figure in the training data relatively less.
Good point, I don't know! That's why I formulated it this way.
Edit: I guess what I'm trying to say is, with security relevant things it might do no harm to be a bit more credulous when it comes to initial reports. (In theory, no idea how to best handle the growing flood of LLM generated stuff. Pointing LLMs at each other doesn't seem great.)
My previous question does not indicate more belief than that it might be true, so I can't answer you there. Should I adopt the belief any information put into words by an LLM is wrong? I don't think it would do me any good. I wish people would stop giving over their writing (or other things) completely to LLMs too, but I can't make them.
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:
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:
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.
Access points are a phone network thing specifying which IP gateway the phone network routes your internet packets to. Not sure if they're still a thing in LTE which is natively IP-based.
They do accept/forward messages without checking if they are special carrier-only ones. ~10 years ago I had some fun sending a "voicemail received" message to people, which caused android phones to display a notification which couldn't ever be dismissed. IIRC it only worked on HTC phones and required root/xposed. SS7 in general is built with total trust in connected systems.
Edit: I think it was called "HushSMS"
I've sent weird SMS messages through my (rooted) phone before. Silent SMS messages (useful for police trying to activate your phone for triangulation) still returned delivery reports a year or two ago, allowing someone to find out if someone else's phone is on without the target ever noticing.
I think Android removed the ability to send more annoying messages through its normal APIs (like flash SMS messages) but if you have access to any modem (either a smartphone or a full ESP32 dev board costing <50 bucks on AliExpress for 4G LTE), you can bypass any such restriction.
Carrier firewalls will probably filter these messages out but I wouldn't rely on it.
Direct Carrier Billing is (was) also a thing. It had crazy silent mode where site can charge you (adding new item to your normal phone bill) just by serving special HTTP header - that your mobile internet provider picked up. As ripe for abuse as it sounds.
Omfg I am interested in this, I'm interested in wtf a WAP push is, but all I'm getting on this website is Claude-speak "not this, but that" and tables of irrelevant numbers, because Claude fucking loves a table.
Look at this Claude shit:
> Zero-click. The victim does nothing. No tap, no open, no notification.
> Silent. Nothing appears in Messages; the attacker's number is never shown.
Congrats, now you sound like yet another AI YouTube advertisement. "You control when we... ...woohoo"...
OP, please, if you think you have important information, please write it up yourself, I am so sick and tired of being sent LLM generated Markdown files with zero human input, and now you're just publishing that on a website.
FFS.
Oh you had Claude publish your name presumably so you'd get credit for "your" "discovery".
>...which is the exact shape of a "Destructive Remote DoS" in the VRP's own rules.
The trend of Claude referring to everything as having a "shape" irrationally annoys the hell out of me. What an absolutely idiotic way to say "X is like Y."
This trend upsets me so much, because my brain actually does work like that, concepts and ideas exist in 3d space and have likenesses to each other.
I used to write like this, but I can't anymore. (I suspect enough people did in the training set that that's why it ended up being part of the vernacular.)
I just wanted a home for it to share, llm just polished it up.
the message is silent, no notification notifying of the attackers origin, doesn't matter if it's locked, or connected to mobile data, so i stand by what is written.
I don't care about the credit, i have enough CVE's under my belt which are higher severity, none which have dedicated write-ups. i care that this gets fixed and give answers to those who are experiencing their phones constantly disconnecting from carrier.
No need to be dramatic, some people’s first language isn’t English, some have dyslexia, some just hate writing (myself) and won’t bother reading it twice to fix typos or grammar, your criticism is ok if the context doesn’t matter, but I would be ok with a fully generated landing page if the exploit is worthy.
The Google Issue Tracker link [0] on the site shows access denied for me. Not sure if this is due to it being reappraised or because I specifically don't have access
If it was filed as a security issue, most well-set-up projects with public issue trackers would keep it closed off only to a reporter and internal security audit team.
Perhaps it was never really declassified in the tracker.
You can't access issues that are not assigned to you. I remember reporting a bug via VRP once, and it was marked as duplicated with another id, that I cannot access and see the original report.
That's the problem with LLMs. Sometimes they follow instructions too precisely, others they sneak in a slow and buggy IEEE-754 parser instead of using `stof`.
I don't see why Android or iOS couldn't enable location based DnD at certain locations. Of course make it optional, but they already have your location and know that the place you are at is an Opera house, theater, etc...
No thanks. "I tried to reach you yesterday". "Oh sorry, I happened to walk by an opera house." PLEASE, less, not more automatisms. Everything has a tendency to produce false positives.
> "Oh sorry, I happened to walk by an opera house."
It would be unfortunate for them to phone you precisely in the small period where DND was turned on as you walked past the opera house (even a large one would be, what, under two minutes of walking?) and not try you again.
(Because if you have instant location-based DND, yes, it might turn on as you walk by an opera house but equally it would turn off when you were past the opera house. Normally, though, I'd expect location-based DND to only kick in after a certain period of time in the same location - say 10 minutes.)
Sure, the coffee shop might be a problem (since I'm guessing that'd be more than 10 minutes.) You could always turn it off (and a smart system wouldn't turn it back on 10 minutes later unless you leave and come back.)
Apple and Google know the geolocation of every WiFi network in the US at this point. They could use signal strength as an additional measure if GPS is not accurate enough (though I'm pretty sure it is).
So, Android formerly offered geofenced "Rules" for DND, and even flexible "Modes". You could set a location, or a WiFi network, and a radius slider to set the distance from that location or network. But the geolocation features have been removed. The Modes functionality is still available, but you're only allowed to configure time-based schedules or calendar events for triggering them.
Just before they were removed, I decided to eliminate all of my Rules and Modes entirely, because they were turning out to be extremely unreliable, and there was a bug whereby the Pixel went back into DND mode after a restart, even when it had already been moved outside of the location. It was also quite unpredictable how any Mode would behave, when there were all kinds of settings for each one, and it was just too much to set up and keep track of.
Today, DND is even more onerous. In the Clock app's Alarms tab, if DND is enabled, the app prevents me from editing or deleting or modifying, in any way, the alarms as they are set. This is terrible. You see, Google really, really wants us to disable DND and keep it off forever. DND is very bad for Android. So they are making it as inconvenient as all-get-out to leave DND enabled. If it were up to me, I'd leave it defaulted to "on" until I wanted to be disturbed.
My experience with DnD has been that it pretty much just works how I want it to. DnD from 10 PM to 8 AM, only certain people can reach me via call or text, alarms break through it. Never had any buggy behior setting, editing, or deleting alarms.
No, talking to other humans is over and if it's not a technological solution with zero human feedback, it's not a solution I could build a VC-funded startup on, so obviously not a solution in real-life.
The issue seems serious but the part about Australia and 000 that would ban an attacked device seems the typical LLM-being-too-anal paragraph, and completely lacking common sense.
Maybe I'm wrong and naive but given that the AU law was done to force people move forward from 3G only phones because the network was being shutdown and 000 moved to 5G (I believe), it's a law for operator to contact their customers still using an old phone and migrate them to a newer one.
I doubt they will block automatically the number if you are under that DOS for a few days in a row.
It didn't. The 3g network was shut down. There were several older devices that were 4g but still used 3g to call 000, so they had to be blocked from connecting.
Australia has laws that require companies that provide a cellular service to follow, not fixing such a exploit would breach these laws. Under no circumstance can a telco, phone manufacturer or intermediary restrict or knowingly allow the restriction of access to Emergency Services. Google in this case would be considered as knowningly allowing the restriction as they're refusing the acknowledge this as an issue, something I'm sure ACMA could act upon or compel Google into fixing.
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.
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)
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?
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.
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?
> 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..."
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.
> 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.
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.
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.
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
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.
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.
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:
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:
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.
Is this AI security slop or a real issue? Can the phone actually receive these kind of messages from the network?
Also, I don't understand Googles position here. On android the phone ia not part of the OS and can be updated via an app or framework update. Why not just fix this as a functional bug?
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:
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:
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.
> 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:
The style / design in general looks AI. Generate enough sites, reports, etc and you'll recognize it without even being able to articulate why it's AI.
But imo it's not a bad thing. Most sites looked like shit in the past. The content is usually where I focus my changes when dealing with LLM generated HTML. And if I want it slightly less LLM flavored in terms of design I just pick a random design system to tell it to use. Apple HIG, IBM Carbon, etc.
Usually just picking your own palette, a design system, and making it remove all the stupid details it decides to add will improve your end result by a lot.
It's the uncanny valley for text. Models were previously nicer to talk with because they were incompetent enough to still appear to be machines to our minds.
Hi I saw your post on eMudhra "refusing to elaborate on how exactly the failure occurred", but in fact they elaborated before the news stories even broke:
Those complaining about slop are not the majority of users, and this is different from the "Claude think pieces" that most users take particular issue with.
The discussion is moreso about the vulnerability (and PoC) itself rather than the AI-generated aspects.
The people upvoting the slop may not be the same people complaining about slop. With no downvoting, a subset of the population that doesnt' like a topic doesn't necessarily bury it.
Additionally, even those that dislike slop may still upvote a security issue that they think is important.
YC backs slop security startups (though this is not from one of them), and they've been having trouble getting people to take their slop writeups seriously. See also https://news.ycombinator.com/item?id=50294391
The page mentions that an adb command is required to recover the device, but I can't find details on what exact adb this is.
Overall a bit frustrating to have such a fancy webpage with a dedicated address, but then no description on how to actually #1 identify and #2 recover an affected device...
> "Once the database is corrupt, com.android.phone no longer needs a fresh message to fail: it crashes immediately on every boot as it reads the damaged store [..] a factory reset only helps temporarily"
Can't I delete the storage of com.android.phone instead of a full factory-reset?
yes, valid guess, I should have extended the quote.
The page describes that this part is resolved by putting the SIM into a non-Android device to receive the queued messages and acknowledge to the network.
To then recover the device it only vaguely mentions "adb commands" and "factory reset", but I can't find a description what actually needs to be done on the device.
I guess the specific question is: The message database that is corrupted due to this issue, is this DB owned by (and stored as part of) com.android.phone?
Networks still send WAP pushes but you can't just send randomly formatted WAP pushes to your friends. You can, however, use a stingray to MITM your friend's Android phone and send whatever you want to them, because now there is no network firewall to protect them. The combination of MITM and a bug like this could be pretty devastating.
"On a device using an eSIM, where the SIM can't simply be moved to another handset, recovery would be significantly harder, and for a non-technical user, effectively out of reach."
eSims are great until they are not. Give me a second physical SIM tray over an eSim any day of the week.
SQLite data corruption needs some explanation because SQLite is normally very reliable. How do I know this isn't slop written to spread a Trojan horse APK?
As an ex-Google ISE, part of my work was to review security vulnerability reports to us. If this report came on my lap I would definitely have flagged this as a severe security issue. Just a DoS yes, but a severe DoS. I did tier two engineering reviews though. From the website's timeline it seems like a tier one triager dismissed it. And I would see this happen occasionally: tier one triagers either dismissing things that shouldn't, or the reverse, flagging things that don't deserve it. My personal opinion is that the quality of Google's work has declined somewhat in the last decade. Disappointing...
triage seems outsourced for android, messages like "we will forward this to the android team". This seems to have been a communication issue, they set it as Will Not Fix, they 'fixed' the bug by adding try/catches further up the chain in upcoming release, i missed that before i submitted.
they did set it as a duplicate of a ticket they disregarded.
I found the Chrome team the easiest to communicate with, devs would actually respond.
The issue is assigned CVE-2026-58882, has Critical severity and is part of the November 2026 security patch level. OEMs received the patch in July 2026 and have been allowed to ship it since then. That's how the patch system now works for Android. GrapheneOS has access to the security preview patches so we got it patched for our users in July 2026.
Android's public issue tracker isn't the real issue tracker. They create internal issues for what's reported there. That means the discussion about it doesn't happen there. Security bug reports are mainly treated as a request for a bounty and little communication happens beyond what's related to receiving a bounty for it. If someone else filed it then it gets closed and no further info is provided. If someone external filed the first report, they hardly get any updates themselves beyond eventually being informed which Android Security Bulletin included it months after it was disclosed to OEMs and allowed to be patched.
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:
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:
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.
It is more likely a severe communication issue happened. A related fix was committed by Google on June 15th [0] and was apparently assigned CVE-2026-58882. GrapheneOS [1] was able to ship the fix through the security preview channel as early as July, but it will otherwise be in the upcoming November security bulletin.
What confused the people dismissing this all over the comments here? It was clearly a DoS bug.
Perhaps the site's tagline was all they read and admittedly I'd have phrased differently.
> A single malformed WAP Push SMS crashes com.android.phone on Android, dropping active calls (including emergency calls), with zero interaction from the victim.
An easier way to deliver the point across could be:
> Anyone can send an specially crafted SMS to repeatedly crash the victim's phone app on Android without user interaction. Google didn't fix it, here's an app you can download to send that SMS and disable anyone's phone remotely.
Just my 2 cents for OP, good job on finding and reporting this and it sounds great that it was actually patched, glad you persisted through the frustration of dealing with google's triaging.
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:
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:
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.
0xcrypto | a day ago
solyin | a day ago
autoexec | 23 hours ago
That has more to do with the severity of heartbleed than the fact that it had a name and a logo. I've since seen a lot of vulnerabilities try to market themselves with websites, cute names, and stupid logos but I still don't remember them because they still just weren't big enough to actually be memorable.
cowlevel | 15 hours ago
__m | a day ago
[OP] MarkBlah | 23 hours ago
AspireOne | 21 hours ago
[OP] MarkBlah | 20 hours ago
rustyhancock | 23 hours ago
Before this practice in general you simply released the exploit and see if enough chaos triggers a fix.
exploderate | 22 hours ago
couchand | 15 hours ago
therealmarv | 21 hours ago
embedding-shape | 20 hours ago
A bit like the postal system. Yes, it's meant to send physical letters and what not to my home, but it still sucks when I get ads that just goes straight into the trash. Yes, you're using the system as intended, but I still consider your business slop if you send ads to me this way.
[OP] MarkBlah | 16 hours ago
xuhu | 21 hours ago
mirror_dude | 13 hours ago
tencentshill | 11 hours ago
est | a day ago
latexr | 22 hours ago
contingencies | 21 hours ago
fg137 | 20 hours ago
Thanks to some genius at Samsung who thinks this is a good idea.
contingencies | 20 hours ago
cowlevel | 15 hours ago
villgax | a day ago
[OP] MarkBlah | 23 hours ago
pogue | 22 hours ago
I'm not familiar with WAP Push and how it works, but is it possible to disable it or block that port on a non-rooted phone?
motionlessveloc | 22 hours ago
klhs | 23 hours ago
[OP] MarkBlah | 23 hours ago
klhs | 23 hours ago
j16sdiz | 21 hours ago
False negative? I honestly don't know what we can do about it. If this is a real issue, maybe another llm will rediscover it and it eventually will get triaged right?
klhs | 20 hours ago
[OP] MarkBlah | 16 hours ago
coldfloor | 22 hours ago
luca020400 | 20 hours ago
EDIT: actually already fixed in https://review.lineageos.org/c/LineageOS/android_frameworks_...
There's yet another PDU fixup that stems from negative index
anonymous908213 | 23 hours ago
dspillett | 21 hours ago
That is a function of the training data/method, like many of AI's problems. This doesn't stop it being a problem of course, but it shouldn't be a surprise.
Big bugs, like heartbleed, over the years have had breathy websites going over how serious the problem is because the problem was that serious, so the models associate that sort of wording with bug reports. Less serious bugs don't get the same excited treatment, repeated in many many places, so more measured descriptions figure in the training data relatively less.
klhs | 21 hours ago
paxy | 20 hours ago
[OP] MarkBlah | 16 hours ago
klhs | 11 hours ago
grapheneos | 7 hours ago
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.
yellow_lead | 23 hours ago
err, how can I send an SMS like this? Would a mobile network even accept/forward such an SMS?
Little hard reading through the vibe slop here
rustyhancock | 23 hours ago
But not all SMS are text messages for the user.
snitch182 | 22 hours ago
LtWorf | 22 hours ago
My provider had given me a remotely managed router. It was trivial to change the configuration and have it work normally.
jeroenhd | 21 hours ago
cowlevel | 15 hours ago
lesspassiveobse | 22 hours ago
jeroenhd | 21 hours ago
I think Android removed the ability to send more annoying messages through its normal APIs (like flash SMS messages) but if you have access to any modem (either a smartphone or a full ESP32 dev board costing <50 bucks on AliExpress for 4G LTE), you can bypass any such restriction.
Carrier firewalls will probably filter these messages out but I wouldn't rely on it.
1116574 | 21 hours ago
Those APIs are probably still online, and still require to nail your ass to the contract, but technically I would assume it's possible.
Good4boothee | 16 hours ago
EdwardDiego | 23 hours ago
Look at this Claude shit:
> Zero-click. The victim does nothing. No tap, no open, no notification.
> Silent. Nothing appears in Messages; the attacker's number is never shown.
Congrats, now you sound like yet another AI YouTube advertisement. "You control when we... ...woohoo"...
OP, please, if you think you have important information, please write it up yourself, I am so sick and tired of being sent LLM generated Markdown files with zero human input, and now you're just publishing that on a website.
FFS.
Oh you had Claude publish your name presumably so you'd get credit for "your" "discovery".
Mark Blaszczyk, please do better.
hard_times | 22 hours ago
coldfloor | 22 hours ago
The trend of Claude referring to everything as having a "shape" irrationally annoys the hell out of me. What an absolutely idiotic way to say "X is like Y."
birdsongs | 22 hours ago
I used to write like this, but I can't anymore. (I suspect enough people did in the training set that that's why it ended up being part of the vernacular.)
dsr_ | 22 hours ago
cowlevel | 15 hours ago
kome | 21 hours ago
[OP] MarkBlah | 21 hours ago
the message is silent, no notification notifying of the attackers origin, doesn't matter if it's locked, or connected to mobile data, so i stand by what is written.
I don't care about the credit, i have enough CVE's under my belt which are higher severity, none which have dedicated write-ups. i care that this gets fixed and give answers to those who are experiencing their phones constantly disconnecting from carrier.
cyclopeanutopia | 17 hours ago
tamimio | 18 hours ago
DeluluDon | 12 hours ago
grandfunction | 23 hours ago
tompagenet2 | 22 hours ago
[0] https://issuetracker.google.com/issues/509520497
necovek | 21 hours ago
Perhaps it was never really declassified in the tracker.
KJs6ZxELzQM37O | 21 hours ago
pitkali | 20 hours ago
soltanov | 22 hours ago
dmitrijbelikov | 22 hours ago
shrimppersimmon | 22 hours ago
:grimace:
zamalek | 15 hours ago
nubinetwork | 22 hours ago
sandos | 18 hours ago
"core Android Telephony Framework GPS race condition from the early days of Android (roughly 2011–2014)."
My AI was unable to find any existing webpages for this though?
Also there was this:
https://community.oneplus.com/thread/579700
izacus | 16 hours ago
This requires carrier to cooperate.
jpl56 | 22 hours ago
ece | 22 hours ago
Geezus_42 | 22 hours ago
lynx97 | 21 hours ago
zimpenfish | 21 hours ago
It would be unfortunate for them to phone you precisely in the small period where DND was turned on as you walked past the opera house (even a large one would be, what, under two minutes of walking?) and not try you again.
(Because if you have instant location-based DND, yes, it might turn on as you walk by an opera house but equally it would turn off when you were past the opera house. Normally, though, I'd expect location-based DND to only kick in after a certain period of time in the same location - say 10 minutes.)
thereader12 | 21 hours ago
zimpenfish | 21 hours ago
Geezus_42 | 20 hours ago
Geezus_42 | 20 hours ago
broken-kebab | 21 hours ago
Geezus_42 | 20 hours ago
zimpenfish | 21 hours ago
ButlerianJihad | 20 hours ago
Just before they were removed, I decided to eliminate all of my Rules and Modes entirely, because they were turning out to be extremely unreliable, and there was a bug whereby the Pixel went back into DND mode after a restart, even when it had already been moved outside of the location. It was also quite unpredictable how any Mode would behave, when there were all kinds of settings for each one, and it was just too much to set up and keep track of.
Today, DND is even more onerous. In the Clock app's Alarms tab, if DND is enabled, the app prevents me from editing or deleting or modifying, in any way, the alarms as they are set. This is terrible. You see, Google really, really wants us to disable DND and keep it off forever. DND is very bad for Android. So they are making it as inconvenient as all-get-out to leave DND enabled. If it were up to me, I'd leave it defaulted to "on" until I wanted to be disturbed.
DangitBobby | 18 hours ago
cowlevel | 15 hours ago
Items placed in a Bag of Holding may not be retrieved within half a mile of a real-life police station
user2722 | 21 hours ago
embedding-shape | 20 hours ago
cowlevel | 15 hours ago
darkwater | 21 hours ago
Maybe I'm wrong and naive but given that the AU law was done to force people move forward from 3G only phones because the network was being shutdown and 000 moved to 5G (I believe), it's a law for operator to contact their customers still using an old phone and migrate them to a newer one. I doubt they will block automatically the number if you are under that DOS for a few days in a row.
chinathrow | 21 hours ago
dools | 20 hours ago
erebussss | 20 hours ago
dools | 20 hours ago
You doubt correctly. The law is about blocking IMEI numbers of phones that use the 3g network to dial 000 despite being 4g devices.
jeroenhd | 21 hours ago
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?
_trampeltier | 21 hours ago
jeroenhd | 21 hours ago
mzajc | 21 hours ago
rvba | 20 hours ago
perhaps even a rogue employee
t_mahmood | 20 hours ago
DaSHacka | 18 hours ago
izacus | 16 hours ago
And it's not that hard, bring down a VPN or some core routing service.
DaSHacka | 11 hours ago
izacus | 16 hours ago
How do you make calls without trusting them?
[OP] MarkBlah | 21 hours ago
jonathanstrange | 21 hours ago
vijaybritto | 20 hours ago
Geezus_42 | 20 hours ago
pnt12 | 19 hours ago
For the lulz.
Geezus_42 | 19 hours ago
kirth_gersen | 18 hours ago
int0x29 | 15 hours ago
vijaybritto | 14 hours ago
whizzter | 20 hours ago
tyingq | 19 hours ago
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..."
ufmace | 19 hours ago
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.
dns_snek | 18 hours ago
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.
[OP] MarkBlah | 16 hours ago
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.
[OP] MarkBlah | 18 hours ago
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 | 17 hours ago
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
[OP] MarkBlah | 17 hours ago
zamalek | 15 hours ago
The software is installed on the _sender_ device.
amluto | 17 hours ago
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 | 12 hours ago
cowlevel | 15 hours ago
zamalek | 14 hours ago
1. Revenge on an ex.
2. Send someone the packet, set up a situation where they need to call 911.
grapheneos | 7 hours ago
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.
syshyk | 21 hours ago
throwa356262 | 21 hours ago
Also, I don't understand Googles position here. On android the phone ia not part of the OS and can be updated via an app or framework update. Why not just fix this as a functional bug?
[OP] MarkBlah | 20 hours ago
Google are rather vague in their triage, they just said temporary DoS does not qualify, then rejected to investigate further.
grapheneos | 7 hours ago
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.
Tepix | 21 hours ago
other8026 | 14 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...
https://x.com/GrapheneOS/status/2115848460578762757
Retr0id | 20 hours ago
goody71 | 18 hours ago
qmr | 16 hours ago
phoghed | 16 hours ago
But imo it's not a bad thing. Most sites looked like shit in the past. The content is usually where I focus my changes when dealing with LLM generated HTML. And if I want it slightly less LLM flavored in terms of design I just pick a random design system to tell it to use. Apple HIG, IBM Carbon, etc.
Usually just picking your own palette, a design system, and making it remove all the stupid details it decides to add will improve your end result by a lot.
Steltek | 15 hours ago
Also, I want to expunge the word "shape" from my vocabulary at this point. I think I'm developing a nerve twitch just reading it.
therein | 15 hours ago
zamalek | 14 hours ago
Retr0id | 13 hours ago
ranger_danger | 5 hours ago
https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c10
And again with the follow-up issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=2085612#c3
paxy | 20 hours ago
kirth_gersen | 18 hours ago
DaSHacka | 17 hours ago
The discussion is moreso about the vulnerability (and PoC) itself rather than the AI-generated aspects.
advisedwang | 16 hours ago
Additionally, even those that dislike slop may still upvote a security issue that they think is important.
[OP] MarkBlah | 16 hours ago
cowlevel | 15 hours ago
Retr0id | 13 hours ago
rickdeckard | 20 hours ago
Overall a bit frustrating to have such a fancy webpage with a dedicated address, but then no description on how to actually #1 identify and #2 recover an affected device...
> "Once the database is corrupt, com.android.phone no longer needs a fresh message to fail: it crashes immediately on every boot as it reads the damaged store [..] a factory reset only helps temporarily"
Can't I delete the storage of com.android.phone instead of a full factory-reset?
ratdragon | 19 hours ago
rickdeckard | 19 hours ago
The page describes that this part is resolved by putting the SIM into a non-Android device to receive the queued messages and acknowledge to the network.
To then recover the device it only vaguely mentions "adb commands" and "factory reset", but I can't find a description what actually needs to be done on the device.
I guess the specific question is: The message database that is corrupted due to this issue, is this DB owned by (and stored as part of) com.android.phone?
[OP] MarkBlah | 17 hours ago
Only fix is to place sim/esim into non Android device
masfuerte | 14 hours ago
hjadoui | 20 hours ago
dools | 20 hours ago
rickdeckard | 19 hours ago
Disclaimer for non-aussies (like me): That's not the newest hacker slang for something, 000 is the phone number of Australian's emergency services...
Replace with "can cut you off from 911" or 112, 999, etc. as needed (optionally wear sunglasses and add hand-gestures to amplify the effect)
...or just call it "emergency services"
bossyTeacher | 18 hours ago
eSims are great until they are not. Give me a second physical SIM tray over an eSim any day of the week.
cowlevel | 18 hours ago
[OP] MarkBlah | 16 hours ago
cowlevel | 15 hours ago
mah4k4l | 17 hours ago
hackersnooze1 | 17 hours ago
[OP] MarkBlah | 16 hours ago
iugtmkbdfil834 | 16 hours ago
- targeted suppression - targeted disruption
mrb | 14 hours ago
[OP] MarkBlah | 13 hours ago
they did set it as a duplicate of a ticket they disregarded.
I found the Chrome team the easiest to communicate with, devs would actually respond.
page updated to reflect.
mrb | 11 hours ago
grapheneos | 7 hours ago
Android's public issue tracker isn't the real issue tracker. They create internal issues for what's reported there. That means the discussion about it doesn't happen there. Security bug reports are mainly treated as a request for a bounty and little communication happens beyond what's related to receiving a bounty for it. If someone else filed it then it gets closed and no further info is provided. If someone external filed the first report, they hardly get any updates themselves beyond eventually being informed which Android Security Bulletin included it months after it was disclosed to OEMs and allowed to be patched.
grapheneos | 7 hours ago
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.
Wonderfall | 14 hours ago
[0] https://android.googlesource.com/platform/frameworks/opt/tel...
[1] https://x.com/GrapheneOS/status/2115848460578762757
6thbit | 12 hours ago
Perhaps the site's tagline was all they read and admittedly I'd have phrased differently.
An easier way to deliver the point across could be: Just my 2 cents for OP, good job on finding and reporting this and it sounds great that it was actually patched, glad you persisted through the frustration of dealing with google's triaging.grapheneos | 7 hours ago
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.
shushpanchik | 10 hours ago