https://github.com/Ashwesker/Blackash-CVE-2025-48633
The text there:
┌──────────────────────────┐
│ Attacker (C2 Server) │
└────────┬─────────────────┘
│ 1. Delivers malicious APK
│ (phishing, fake app store, drive-by)
▼
┌─────────────────────────────────────────────────────┐
│ Victim's Android 15 Phone │
│ (Security patch < 2025-12-01 → still vulnerable) │
└─────────────────────────────────────────────────────┘
│
┌──────────────┴──────────────┐
▼ ▼
User installs & opens Malicious app runs in background
"Fake Game / Tool" APK (no permissions needed for this CVE)
│
│ 2. App triggers vulnerable Framework API
│ (crafted Intent / Binder transaction)
▼
┌───────────────────────────────────┐
│ Android Framework (buggy) │
│ code in Parcel/Binder handling) │
└───────────────────────────────────┘
│
│ 3. Information Disclosure occurs
│ → Sensitive data leaked without user interaction
▼
Leaked data examples:
• Device ID / IMEI
• Installed app list
• Account tokens
• Contacts / SMS snippets
• Clipboard content
• Location history fragments
│
│ 4. Data silently sent back
▼
┌───────────────────────────────────┐
│ Attacker receives stolen data │
→ Can be sold, used for │
└───────────────────────────────────┘ spying, or chained with
other exploits (e.g. CVE-2025-48572)True, it says almost nothing of value about the exploit, but it does teach us that 30% is almost one in three.
This is just polluting the namespace and making it harder for blue teamers and incident responders to find actionable IOCs.
Being reliant on a single OS permanently nailed to the hardware is no less crazier. I'd like to be able to install another OS on a vulnerable device, it would help tremendously and not only with the security of that specific device.
Now I've got some expensive paperweights that I can't even use as such because every time I see them I have the urge to throw them in the trash can.
Provide a way to unlock the phones and a standard BSP, it should be the law.
Pixel 8 here, still don't have the update. That's... not great.
Yes, they can. We are talking about applying provided security patches to source code, and then releasing a new version of their OS. For patches that have existed for months. The time from patch to release should be on the order l of days from receiving the patches to having a validated OS release with the fix being sent to users. It's not the control of Android which makes Google possible to patch their Pixel branch of AOSP faster than Samsung can patch their own. It's that Samsung doesn't care about prompt security fixes so they don't allocate engineers to do the work.
https://source.android.com/docs/security/bulletin/2025-12-01
Squeeze2664•1h ago
jackwilsdon•36m ago
[1]: https://discuss.grapheneos.org/d/27068-grapheneos-security-p...
bramhaag•25m ago