Google just got hit by yet another record antitrust fine by the EU [1]. But as long as they see these fines as cost of doing business, nothing will change. Especially if it always takes almost a decade to push this through the judicial system. Their net income last year alone was $130 Billion.

[1] https://www.reuters.com/world/eu-top-court-dismisses-google-...

Sometimes attacks happen from users being instructed to enable settings in order to achieve something regardless of whether you’d expect them to have a reason to use the setting

It seems to require the user to:

1. Enable Developer Mode by going to an obscure settings page and tapping the build number seven times

2. Enable USB ADB debugging in the Developer Options

3. Establish an actual USB ADB session

4. Enable TCP/IP ADB debugging in the Developer Options

5. Unknowingly download a malware app from the official Play Store

6. Blindly click "Yes" on the permission prompt.

In other words: this is all but impossible to impact regular users, and it requires a particularly careless developer to be hit by it. And it only works if the Play Store is useless at preventing malware in the first place - but I thought their excellent app scanning was the entire reasoning behind all-but-banning 3rd-party app stores and sideloading???

It is "for safety" in the same sense that governments banning all encryption is to "protect the children" or to "prevent terrorism": flawed justification invented to distract from the real reason they want it.

You haven't been able to connect to an android device on port 5555 for yeeears. Every time you enable adb/IP it generates a new random port, or you need to use the QR/PIN pairing thing. On top of needing to enable developer options, adb/IP, confirm the fingerprint.

Hadn't thought about that additional attack vector those proxies are enabling. In addition to "internet access from residental connection" privileges, the attacker also gets access to loopback on the device that does the proxying...

But even then, shouldn't this show the same permission prompt for the user that anything else trying to connect to port 5555 would?

It's not side loading. Word you are looking for is called "installing".

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.

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?

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.

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.

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.

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

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