6 ms·

The bug literally describes how they're avoiding OS security restictions by going through the debug port. This is a CVE by any definition and you'd be screamin

by izacus 3mo ago

The bug literally describes how they're avoiding OS security restictions by going through the debug port. 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 even if another app did it). But sure, Google evil.

TeMPOraL 3mo ago
> 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.
- dns_snek 3mo ago
  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.
  - TeMPOraL 3mo ago
    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.
    - dns_snek 3mo ago
      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.
      - TeMPOraL 3mo ago
        Correct. That, and security maximalism displayed in 3. and some comments in the HN thread.
  - 3xpltr3 3mo ago
    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.
    - dns_snek 3mo ago
      > 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 https://news.ycombinator.com/item?id=49046270
theplumber 3mo ago
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.
- deleted 3mo ago
  [deleted]
- izacus 3mo ago
  "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.
  - rcxdude 3mo ago
    When half that security is aimed against the user it's pretty easy to cheer for cracks in it.
  - TeMPOraL 3mo ago
    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 3mo ago
      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.
3form 3mo ago
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?
- dminik 3mo ago
  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.
  - 3form 3mo ago
    Mind you, I'm not arguing for the CVE, just complaining that the current thinking is very selective.
roer 3mo ago
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.
- izacus 3mo ago
  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.
  - TeMPOraL 3mo ago
    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?
  - microtonal 3mo ago
    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.
    - p0w3n3d 3mo ago
      Quod licet Iovi, non licet bovi And yes, bovi is as in bovine
  - subscribed 3mo ago
    So what official API call recorder app can use?
zmmmmm 3mo ago
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.
mrsssnake 3mo ago
"...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.
spaqin 3mo ago
In this case, the OS security restrictions should be questioned in the first place as excessive if a "backdoor" is necessary for normal function.
gnfargbl 3mo ago
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 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/adb/+/842d331f9e5fb10770a09379e19240daea057dba%5E%21/#F0 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.
- dns_snek 3mo ago
  > 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 https://issuetracker.google.com/issues/526109803#comment3
  - gnfargbl 3mo ago
    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.
    - dns_snek 3mo ago
      Yeah, they didn't claim that it's a CVE, just behavior that they wanted to change. Miscommunication then.
  - duskdozer 3mo ago
    >>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.
microtonal 3mo ago
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.
redeeman 3mo ago
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
yyhhsj0521 3mo ago
New CVE found in Bank of America app that may cause user to transfer money to hackers if they press certain combination of keys.
- phoghed 3mo ago
  More like if you have some settings enabled someone on your network can do it for you without your permission
  - duskdozer 3mo ago
    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.
- inigyou 3mo ago
  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.
subscribed 3mo ago
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!
- zbentley 3mo ago
  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!
  - subscribed 3mo ago
    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.

by izacus 3mo ago

TeMPOraL 3mo ago

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

dns_snek 3mo ago
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.
- TeMPOraL 3mo ago
  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.
  - dns_snek 3mo ago
    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.
    - TeMPOraL 3mo ago
      Correct. That, and security maximalism displayed in 3. and some comments in the HN thread.
- 3xpltr3 3mo ago
  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.
  - dns_snek 3mo ago
    > 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 https://news.ycombinator.com/item?id=49046270

theplumber 3mo ago

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.

deleted 3mo ago
[deleted]
izacus 3mo ago
"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.
- rcxdude 3mo ago
  When half that security is aimed against the user it's pretty easy to cheer for cracks in it.
- TeMPOraL 3mo ago
  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 3mo ago
    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.

3form 3mo ago

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?

dminik 3mo ago
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.
- 3form 3mo ago
  Mind you, I'm not arguing for the CVE, just complaining that the current thinking is very selective.

roer 3mo ago

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.

izacus 3mo ago
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.
- TeMPOraL 3mo ago
  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?
- microtonal 3mo ago
  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.
  - p0w3n3d 3mo ago
    Quod licet Iovi, non licet bovi And yes, bovi is as in bovine
- subscribed 3mo ago
  So what official API call recorder app can use?

zmmmmm 3mo ago

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.

mrsssnake 3mo ago

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

spaqin 3mo ago

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

gnfargbl 3mo ago

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 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/adb/+/842d331f9e5fb10770a09379e19240daea057dba%5E%21/#F0 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.

dns_snek 3mo ago
> 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 https://issuetracker.google.com/issues/526109803#comment3
- gnfargbl 3mo ago
  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.
  - dns_snek 3mo ago
    Yeah, they didn't claim that it's a CVE, just behavior that they wanted to change. Miscommunication then.
- duskdozer 3mo ago
  >>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.

microtonal 3mo ago

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.

redeeman 3mo ago

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

yyhhsj0521 3mo ago

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

phoghed 3mo ago
More like if you have some settings enabled someone on your network can do it for you without your permission
- duskdozer 3mo ago
  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.
inigyou 3mo ago
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.

subscribed 3mo ago

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!

zbentley 3mo ago
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!
- subscribed 3mo ago
  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.