Samsung's September 2026 monthly release (SMR Sep-2026 Release 1) fixes two vulnerabilities rated CVSS 9.8, both in the same library: libimagecodec.quram.so, Samsung's proprietary image decoder.
| CVE | Decoder | NVD description |
|---|---|---|
| CVE-2026-21095 | DNG | Heap-based buffer overflow in DNG decoder of libimagecodec.quram.so prior to SMR Sep-2026 Release 1 allows remote attackers to execute arbitrary code. |
| CVE-2026-21096 | JPEG | Heap-based buffer overflow in JPEG decoder of libimagecodec.quram.so prior to SMR Sep-2026 Release 1 allows remote attackers to execute arbitrary code. |
Shared vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
What makes this batch serious comes down to two elements of that vector: AV:N (network) and above all UI:N — no user interaction. On an image decoder flaw, that combination describes precisely what the industry calls zero-click.
Why Image Decoders Are a Phone's Most Dangerous Attack Surface
The reasoning is simple and counter-intuitive.
To display an image, a phone has to parse it before it can decide whether it trusts the sender. That's the reverse of what security would want. An image arrives by MMS, by RCS, in a messaging app, in a conversation preview, in a browser cache, in a notification — and the decoding code runs to produce a thumbnail, often before the user has opened anything.
Hence the UI:N. The victim clicks nothing. In the worst case, receiving the message is enough.
That's the mechanism behind the most notable mobile exploitation chains of the past decade, and why media decoders concentrate the attention of researchers and attackers alike.
The Quram specifics
libimagecodec.quram.so isn't stock Android code: it's a Samsung-proprietary library, supplied by Quramsoft, which replaces or supplements the AOSP decoders.
Two practical consequences:
It falls outside Google's Android patch. The monthly Android security bulletin doesn't cover it. A Samsung phone current with Google's patch but not with Samsung's SMR remains vulnerable.
It has history. This library has already produced several critical decoding vulnerabilities on Samsung devices. This isn't an isolated discovery but a component that comes up repeatedly.
The DNG format deserves a mention
CVE-2026-21095 targets the DNG (Digital Negative) decoder, Adobe's raw format. That's an interesting choice from an attacker's perspective: DNG is a complex TIFF-based container, far less fuzzed than JPEG, and above all far less expected. A filter inspecting attachments would focus on JPEG and PNG; DNG frequently passes without special scrutiny while being handled by the same library.
Affected Devices and Versions
| Platform | Affected versions |
|---|---|
| Samsung Android | 14.0, 15.0, 16.0, 17.0 |
The range covers four Android generations, so most of the Samsung fleet in circulation — from recent Galaxy S models to devices still under support.
Fix: SMR Sep-2026 Release 1.
Check on the device:
Settings → Software update → Update information
The field to read is "Android security patch level": it must show September 1, 2026 or later.
In fleet management (MDM), the useful query is the security patch level, not the Android version:
ro.build.version.security_patch >= 2026-09-01
That's the distinction that matters: a device can be on Android 17 and still carry a March patch level.
What an Attacker Gains
libimagecodec.quram.so is loaded by whichever process displays the image. Depending on the entry point that may be the messaging app, the gallery, the browser or a system thumbnailing service.
Code execution in that context yields access to the relevant app's data — and above all a starting point for a chain: on mobile, a memory primitive in a rendering process is classically chained with a sandbox escape and then a kernel escalation.
The S:U (scope unchanged) confirms it: the flaw alone doesn't cross the sandbox boundary. It supplies the first step, not the whole staircase.
For an organisation, the concrete stake is corporate messaging and company data on personal devices. A handset compromised via an image yields conversations, attachments and — depending on configuration — authentication tokens for business apps.
Detection
Let's be direct: on mobile, there is no usable user-side detection for this class of flaw. No accessible logs, no EDR comparable to an endpoint's, and successful exploitation leaves no visible trace.
The only indirect signals, all weak:
- Repeated crashes of the messaging app or gallery — failed attempts take the process down before successful ones land
- Abnormal, unexplained battery or data consumption
- Unknown apps or unrecognised management profiles
The genuinely useful control therefore isn't detection but inventory: what share of your fleet carries a patch level earlier than September 1, 2026? That's the only question you can answer with certainty, and it's the one that determines your exposure.
Mitigation
1. Apply the September 2026 SMR
That's the only fix. On a managed fleet, force the update rather than relying on the user: Samsung updates often require confirmation, and many devices sit pending for weeks.
2. Reduce automatic decoding
Pending rollout, the most effective measure is limiting what gets decoded without user action:
- Disable automatic media download in messaging apps (WhatsApp, Signal, Telegram, Messages) — this is what removes the zero-click property
- Disable MMS auto-retrieve:
Messages → Settings → Advanced settings → Auto retrieve
These settings fix nothing, but they remove the most dangerous scenario: the one where the victim did nothing.
3. Check patch level, not Android version
This is the most common fleet-management mistake. Add ro.build.version.security_patch to your MDM compliance dashboards, and make it a conditional access criterion if your solution supports it.
4. Handle end-of-support devices
Samsung models no longer receiving SMR will never get this fix. On a corporate fleet, an out-of-support device accessing company data is a standing risk no technical measure closes.
Why Continuous Monitoring of Your Mobile Fleet Matters
Mobile devices occupy the same blind spot as network gear: they reach company data, but appear in no software inventory, aren't scanned, and their patch cycle depends on both the manufacturer and the carrier. Add proprietary libraries like this one — invisible to Google's Android bulletins — and "am I affected?" becomes hard to settle.
With cveo.tech, inventory your mobile devices and their patch levels alongside your servers, and get automatic alerts whenever a critical CVE targets one of your exact versions.