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
allow [intransitive verb]: to make a possibility
I love how quickly you all forget about security and privacy when it gives a chance to angrily rant.
"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.
Whether that means there's a _feature_ lacking there, is another question.
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.
This is one of them
> 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.
Which is a problem only if the third party acquired those keys without your permission, but the industry decided to "fix it" regardless.
Now an application on my computer can obtain root without user interaction.
Where is my CVE?
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.