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.

▲

dns_snek 5 hours ago | parent | next [-]

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

▲

5 hours ago | parent | prev | next [-]

[deleted]

▲

izacus 5 hours ago | parent | prev [-]

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

▲

TeMPOraL 5 hours ago | parent | next [-]

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.

	▲	izacus 2 hours ago \| parent [-]
		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.

▲

vrighter 5 hours ago | parent | prev | next [-]

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

	▲	dns_snek 4 hours ago \| parent \| next [-]
		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.
	▲	TeMPOraL 4 hours ago \| parent \| prev [-]
		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.

▲

rcxdude 5 hours ago | parent | prev | next [-]

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

▲

J-Kuhn 2 hours ago | parent | prev | next [-]

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?

▲

crote 4 hours ago | parent | prev [-]

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