There's a vulnerability in my bike - when I push my left handlebar hard forward when riding down a road, I can crash into a pillar.

I think a possibility of knowingly pushing the handlebar should be removed from me, just in case. After all I could do it.

And while we're at it I just realised my car has a similar vulnerability, but triggered by a slightly different mechanism, but the effect is exactly the same, I can crash into a pillar.

Edit: oops, I just discovered that if I have a banking app installed on my phone, then tap my screen in the specific places, enter several numbers, including the number I receive in text, suddenly I lose all the money.

That's staggering!

You, and may of the people in the thread here are at cross purposes, I think.

The CVE mentioned in the article is https://nvd.nist.gov/vuln/detail/CVE-2026-0073. That's a real CVE: logic error leading to auth bypass. Fix can be seen at https://android.googlesource.com/platform/packages/modules/a....

Separately, a number of people here are attempting to argue that the availability of On-Device ADB should be regarded as a "CVE" in and of itself. Google does not appear to share that view.

> This is a CVE by any definition and you'd be screaming your head off if any other OS would allow this kind of permission bypass.

Or perhaps they wouldn't? CVEs aren't holy scripture, and "security" isn't the most important consideration in computing. This theatre has gone too far IMO.

Depends how you define a CVE. If owning and controlling your device is a CVE/bug then sure you need a tight box with anti tempering as well.

The original issue is proposing letting the user assign the debug service to a specific interface, one of which would presumably be loopback. This article is about the proposal from a developer that it should only ever be assigned to wlan0, which would break a lot of apps.

Letting applications bypass permissions with this feature is the exact usecase they don't want to lose. If anything, I don't see them being against the original proposal possibly restricting non-loopback access, which would enhance security.

Because you know, the actual solution would be to have more granularity in authentication process than "allow whole device to attach to ADB", but that would be like, difficult... so they're not going to so that.

Right now any app on my PC connected to ADB could manipulate my phone then, and that's somehow not a CVE?

In this case, the OS security restrictions should be questioned in the first place as excessive if a "backdoor" is necessary for normal function.

I am not sure I follow. Are you referring to the original CVE (?), I fully agree that it should be fixed, and it is not what my comment was about.

If you are talking about allowing listening on localhost - remote ADB requires enabling in the developer settings. It is a developer feature, similar to ADB over USB. If I'm charitable, it is possible that they are seeing too many people that are using Shizuku without understanding the security implications. But Shizuku has a lot of useful applications and they use ADB because the Android APIs and permission system are lacking and do not make these applications possible.

New CVE found in Bank of America app that may cause user to transfer money to hackers if they press certain combination of keys.

"...avoiding OS security restictions by going through the debug port..." the user delibretry opened and paired to app with clear visual confirmation in order to use it.

Even if you have to deliberately enable a setting and enter a pairing code?

It's like saying that the fact the user knows their own password is a vulnerability because they might enter it to log into their account.

no, its a cve if the app can just do it automatically, it is NOT a cve that user goes through 5 steps that they very explicitly do, including unlocking hidden menus to open up developer options, and then allow it.

seriously, get real, please explain how your train of thought works here