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!

I mean, you made a good metaphorical case for controlled handlebar slop/headset resistance in bicycles/motorcycles. Which are things that exist to mitigate crashes from oversteering on both of those vehicles!

In the bikes they're mostly aimed at preventing tank slappers/death wobble. I have a dampener on my bike myself, but it still allows me to countersteer as harsh/rapidly as I want, and that means crashing into a railing or a cliff wall if I overshoot.

No technology prevents the crash, they just lower the chance of it happening accidentally (like, say, ABS or DCT). I can remove almost all of the guardrails on my bike choosing more aggressive riding mode.

Countermeasures to the accidentally allowing a malware to "do something" already exist and were described in the original article. The comment I was responding to wants a removal of the whole capability, hence my cases.

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.

> 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 was proposed by a Google employee: https://issuetracker.google.com/issues/526109803#comment3

That link is mentioned in the article. To quote it:

> Connection to localhost has also been the source of exploit where app are using that socket to adbd to escalate their privileges. What about we restrict to always only binding to wifi interface wlan0 ?

Nowhere in that text do I see a proposal to assign an additional CVE for this behaviour. Personally I think it would be unusual to assign a CVE for intended-but-potentially-harmful functionality, although I expect people have done that in the past. But, I think overall we're agreeing here.

Yeah, they didn't claim that it's a CVE, just behavior that they wanted to change. Miscommunication then.

>>I use loopback ADB daily to automate scheduling eye care display settings using settings since my OEM does not provide advanced scheduling routines.

>Which OEM do not provide this feature? This hardly quality as a legitimate usecase but rather as a shortcoming of the OEM.

I find this kind of attitude maddening. Although I assume they overlooked "advanced" because as soon as I read that, I knew this wasn't going to be something ever supported as a basic functionality. I get that many people will be fine with simple things but I hate being forced into them.

> 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.

Allowing strangers to run adb commands on your phone without your consent is about as bad as a compromise can get. Your keyboard can be replaced with a keylogger and all of your data can be stolen without your knowledge by simply connecting to the wrong wifi network.

Yes, but what about allowing me to run adb commands on my phone with my consent, and especially delegating that privilege to "strangers", again, with my (one-time) consent - by which I mean authorizing apps to run with elevated privileges and/or reestablish the debugging bridge once it invariably disconnects (for other more or less legitimate security reasons)?

It's not like those threats silently turn on ADB on people's phones without their knowledge. You have to opt in to a rather obscure, hidden by default, and very fickle feature to become potentially vulnerable in the first place.

They're 3 separate issues. There's a genuine vulnerability (CVE) which has been fixed, there's a follow-up proposal to allow the user to choose which interfaces to bind to, and there's another proposal to disallow ADB over loopback which would cut you off from using ADB on-device.

Your problem is with the last one which has nothing to do with the CVE itself.

Correct.

That, and security maximalism displayed in 3. and some comments in the HN thread.

I agree with user TeMPOraL in his comment. Those who aren't trapped in tunnel-vision, know the app permissions themselves have ALOT of access to all data on your device and users give the apps these permissions. Should we say that every app is a CVE? The real reason any Google dev wants ADB gone is to close open source and lock down the OS to Google sign-ins and a proxy proprietary closed source eco-system. ADB is the master-key to rooting Android devices, getting Android shell access to /root, uploading *.apks, etc... But for the Google monopoly, it makes sense to them to close/restrict this access, then funnel all requests for it through Google's identity gateway for access. So the argument "this app can bypass OS security through ADB and is therefore a CVE" is not valid and an foolish from its /root.

> So the argument "this app can bypass OS security through ADB and is therefore a CVE" is not valid

That's not the argument. What gave you the impression that this is what the CVE was about? I'm really confused.

The CVE is "Your android device allows any hacker on your wifi to install/remove apps on your device and steal your private information, unauthenticated"

See: https://news.ycombinator.com/item?id=49046270

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.

Can you provide a reasonable definition where an authentication bypass in ADB doesn't qualify as a vulnerability? Is there a use case for allowing anyone on your network to run adb commands without your approval?

There are 3 things which I feel like are being confused here:

1. There was a genuine authentication bypass vulnerability in ADB (bad)

2. Initial proposed change wants to add an option to limit the ADB server to certain IPs or network interfaces (good - it doesn't affect you)

3. Response to the original request, proposing that ADB shouldn't be allowed to listen on loopback interfaces (bad/nefarious - it breaks functionality)

[1] https://nvd.nist.gov/vuln/detail/CVE-2026-0073

[2] https://issuetracker.google.com/issues/526109803#comment1

[3] https://issuetracker.google.com/issues/526109803#comment3

The act of "allowing“ negates the “without your approval“. You see the failure in the logic here I hope.

I thought we were having a technical discussion not a linguistic one. Baseline level of technical understanding is expected. s/allowing/enabling/.

allow [intransitive verb]: to make a possibility

https://www.merriam-webster.com/dictionary/allow

"An app can bypass OS security system with certain setting enabled" absolutely fits into CVEs. There's no "depends: on it.

I love how quickly you all forget about security and privacy when it gives a chance to angrily rant.

Anything can fit into CVE.

"An app can bypass OS security system with certain setting enabled" is absolutely a valid CVE. We have countless examples every day of vendor apps bypassing OS security systems because they're allowed to do so.

"A device can bypass protective layers and cause soft tissue damage when thrown" is an absolutely fine CVE, too.

Whether it matters or is something that should be addressed, is the depends part. Here we're talking about CVE that's at risk of trying to address a feature.

You are forgetting the most important questions of security, without which the whole discussion becomes pointless:

Who is securing what, and from who?

CVEs seem much less like holy writ when they're aimed at protecting the device for commercial interests and from the device owner.

Apps being able to bypass a restriction put on them by the OS always matter.

Whether that means there's a _feature_ lacking there, is another question.

The OS provides restrictions and permissions so that the user can apply them to apps.

If the user chooses to free certain apps from restrictions, that should be their choice.

But if a piece of software overrides the users' choice, that certainly qualifies as a CVE.

This is an important distinction! The user must always have final say.

Whether an app breaks out of the sandbox and steals my vacation photos, or the OS sets new restrictions I can't remove, both are wrong.

Any piece of software has to act in service of the user, and ONLY the user. It must not do things or set restrictions without the users consent. No means no.

a lot of cves are of the type "if you leave the keys in the door, then anyone can unlock it and get in! We must destroy all doors, they are insecure!"

This is one of them

This is not one of them. This is "the lock accepts any key" type of CVE.

> In adbd_tls_verify_cert of auth.cpp, there is a possible bypass of wireless ADB mutual authentication due to a logic error in the code. This could lead to remote (proximal/adjacent) code execution as the shell user with no additional execution privileges needed.

Patch: https://android.googlesource.com/platform/packages/modules/a...

Docs:

> EVP_PKEY_cmp() return 1 if the keys match, 0 if they don't match, -1 if the key types are different and -2 if the operation is not supported.

The original code cast the integer return value to boolean, and -1 and -2 cast to "true", therefore authentication would succeed if the key types were different or the operation wasn't supported.

You jest, but passkeys seem to have literally been invented to address something like: "Keys to your doors can be used by anyone to open those doors, regardless of your knowledge or presence".

Which is a problem only if the third party acquired those keys without your permission, but the industry decided to "fix it" regardless.

I changed the sudo settings to not require a password.

Now an application on my computer can obtain root without user interaction.

Where is my CVE?

Same. There are so many things you could mess up without root from my account anyway. My account isn't a locked down one. You could alias sudo to a keylogger, for instance, and then do whatever as root the next time I sudo something.

So the password check really has no point. Typing sudo is still a lightweight sanity check, otherwise I may as well just log in as root.

When half that security is aimed against the user it's pretty easy to cheer for cracks in it.

Sounds like the Settings panel is a CVE, we should immediately get rid of it. And don't forget the Play Store!

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.

It would break exactly 0 apps because none of the apps should be using this API to access your private data and phone call audio.

So why do Google Play Services, etc. have full privileged access to a phone, including private data and phone call audio, but the user doesn't?

It is tech feudalism - you don't own anything anymore, you just get to live on the digital land of a bunch of ~trillion dollar companies.

At least, that is the goal.

IMO either everyone gets access at the user's discretion or Google has to sandbox their own GMS services as well.

  Quod licet Iovi, non licet bovi

And yes, bovi is as in bovine

Why? What other APIs should my apps (or the apps I explicitly want to authorize for this purpose) use to access my private data and my phone call audio?

So what official API call recorder app can use?

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?

Is it a CVE that an app running on my PC could actually be running under GDB? It's the entire purpose of these tools.

Mind you, I'm not arguing for the CVE, just complaining that the current thinking is very selective.

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.

More like if you have some settings enabled someone on your network can do it for you without your permission

More like the credit card company can initiate automatic withdrawals from your bank account without your permission if you previously authorized the company to do autopay.

Actually that's what the whole fraud detection thing is about. If you transfer money wrong, they lock your account. Some countries like Sweden even went cashless so they can see all transfers.

"...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