← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2025-54957 · CWE-190 · Disclosed 2025-10-20

Dolby UDC 4

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is less an open front door than a bad mail slot that only matters when your apps auto-open the package

CVE-2025-54957 is an integer-overflow-to-out-of-bounds-write bug in Dolby UDC's Dolby Digital Plus decoder, affecting UDC versions 4.5 through 4.13. The vulnerable path sits in handling of crafted DD+ Evolution data: a length calculation wraps, the decoder allocates too small a buffer, then writes past it. On platforms that automatically decode or transcode inbound audio, that turns a malformed-but-still-valid media stream into memory corruption in the media process.

The 9.8/CRITICAL intake label overstates the risk for a typical enterprise fleet because this is not a broadly exposed network service and exploitation depends on a reachable DD+ decode path plus favorable platform conditions. But it is also more than a boring crash bug: Google Project Zero demonstrated a 0-click Pixel exploit chain using this flaw, so the right read is HIGH—serious where the media pipeline is attacker-reachable, not universal internet-RCE across every host.

"Dangerous on mobile auto-decode paths, but not a fleet-wide 9.8 fire drill"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a crafted DD+ payload

The attacker uses a malformed DD+ bitstream packaged in a media file, as shown by the public AlphabugX/CVE-2025-54957 crash PoC and the original Project Zero proof-of-concept reference. The key is not raw network reachability to Dolby UDC, but getting a target application or OS media stack to ingest the file automatically.
Conditions required:
  • Attacker can send or place media where the target device will process it
  • The target workflow reaches a DD+ decode path
Where this breaks in practice:
  • Most enterprise desktops do not auto-decode arbitrary inbound DD+ content without user action
  • Many business apps never touch Dolby DD+ at all
Detection/coverage: Email/web gateways may see the container file, but signature coverage for malformed DD+ internals is typically weak. Scanner coverage is poor because this is a library-reachability problem, not a simple open-port issue.
STEP 02

Trigger the integer wraparound in evo_priv.c

When vulnerable UDC 4.5-4.13 parses the crafted Evolution data, the write-length calculation can overflow. That causes an undersized allocation and makes the subsequent bounds check ineffective, opening the door to an out-of-bounds write.
Conditions required:
  • Target has a vulnerable Dolby UDC build
  • The platform actually invokes the affected DD+ decoder path
Where this breaks in practice:
  • Patched Pixel devices at 2025-12-05 SPL and Android devices at 2026-01-05 SPL or later are outside the practical window
  • Some platforms compile the codec with stronger mitigations that turn this into a crash instead of usable corruption
Detection/coverage: Version-only scanners may flag the CVE if they inventory embedded codecs, but many SBOM and host tools will miss it because Dolby UDC is often buried in vendor firmware or media components.
STEP 03

Turn corruption into code execution in the media process

Project Zero showed this bug is unusually high quality because it can provide both memory disclosure and overwrite primitives under favorable layouts. On Android, they demonstrated code execution in the media decoding context from a 0-click entrypoint, proving the bug is not merely theoretical.
Conditions required:
  • A platform-specific heap layout and target structure arrangement that make the overwrite useful
  • A reachable media process with enough post-corruption utility
Where this breaks in practice:
  • Exploit reliability is platform-specific, not generic across all Dolby consumers
  • Sandboxing and syscall filters materially reduce what a successful media-process foothold can do
Detection/coverage: Crash telemetry, media service restarts, and suspicious mediacodec process deaths are the best practical signals. Traditional vulnerability scanners will not detect active exploit attempts here.
STEP 04

Escape the sandbox or settle for process compromise

Meaningful device takeover often requires either a weak media sandbox or a second vulnerability. In Google's published Pixel chain, CVE-2025-54957 was the entry bug and a separate kernel-adjacent bug was used to reach full compromise.
Conditions required:
  • Either the media context is already sufficiently privileged, or a second bug is available
  • Target device lacks mitigations that block the needed follow-on primitives
Where this breaks in practice:
  • On hardened devices, this is frequently where the chain breaks
  • Without a follow-on bug, the practical outcome may be a decoder or app crash rather than durable control
Detection/coverage: EDR or mobile threat defense may catch the second-stage behavior; they are far more likely to see post-exploitation than the initial decoder corruption itself.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo broad, independent in-the-wild campaign evidence and not KEV-listed, but Google Project Zero published a working Pixel 9 0-click exploit chain in January 2026 that used this CVE as the entry bug.
Proof-of-concept availabilityPublic crash PoC exists at AlphabugX/CVE-2025-54957. Project Zero also references the original PoC attached to issue 428075495.
EPSS0.00029 (~0.029%), which is very low and argues against mass exploitation pressure despite the scary technical impact.
KEV statusNot present in the current CISA Known Exploited Vulnerabilities Catalog.
CVSS vector reality checkCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H describes the best-case attacker path, but it ignores the biggest real-world qualifier: the attacker needs a reachable DD+ auto-decode path, not just IP connectivity.
Affected versionsDolby UDC 4.5 through 4.13 per Dolby and NVD.
Fixed versions / patch pointsDolby's advisory tells OEMs to obtain updated deliverables directly. Public downstream patch markers are Pixel SPL 2025-12-05, Android SPL 2026-01-05, and Project Zero says ChromeOS received first binary fixes on 2025-09-18.
Exposure / scanning realityThere is no meaningful Shodan/Censys-style internet fingerprint for this bug because UDC is a bundled codec library, not a listening service. Exposure is driven by product population and media workflow reachability, not open ports.
Disclosure timelineDolby advisory dated 2025-10-14; CVE published in NVD on 2025-10-20; Project Zero's exploit-chain write-up landed in January 2026.
Reporting researchersCredited by Dolby to Ivan Fratric and Natalie Silvanovich of Google Project Zero.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to HIGH (8.1/10)

The decisive factor is reachability friction: this is only dangerous where attackers can force a vulnerable device to automatically decode crafted DD+ content. That sharply narrows the exposed population versus a true internet-facing pre-auth RCE, but Project Zero's 0-click exploit evidence keeps it solidly above MEDIUM.

HIGH Affected version range and root-cause characterization
HIGH Exploitability on Pixel/Android auto-decode paths
MEDIUM Generality of exploitation across all Windows and non-mobile Dolby consumers

Why this verdict

  • Start from the scary label, then subtract reachability. A 9.8-style reading assumes broad unauthenticated network reachability, but this bug sits behind a codec invocation path, not a socket.
  • Population is narrower than the CVSS suggests. Exploitation requires a vulnerable host that both ships Dolby UDC 4.5-4.13 and actually auto-processes attacker-controlled DD+ media.
  • Exploit evidence prevents a bigger downgrade. Project Zero proved 0-click code execution on Pixel-class Android targets, so this is not just a crash-only media parser issue.
  • A second-stage requirement lowers fleet-level severity. On hardened devices, meaningful takeover often needs sandbox weakness or a second vulnerability; the published Pixel chain used another bug for full compromise.
  • Threat telemetry is cold. EPSS is extremely low and the CVE is not in KEV, which argues against mass exploitation pressure today.

Why not higher?

This is not a wormable, internet-facing service flaw that an unauthenticated attacker can spray across every enterprise subnet. The attacker must find a platform and workflow that automatically decodes crafted DD+ media, and on well-hardened devices the first-stage foothold may still need a second bug to matter.

Why not lower?

Project Zero moved this out of the 'just patch it eventually' bucket by showing a real 0-click exploit path on Pixel. If you manage Android, Pixel, ChromeOS, or any product that auto-processes inbound audio with Dolby UDC, the exploitation path is real enough that MEDIUM would understate the operational risk.

05 · Compensating Control

What to do — in priority order.

  1. Prioritize auto-decode endpoints — Identify managed Android, Pixel, ChromeOS, conferencing, media-processing, and preview-heavy Windows endpoints that can ingest untrusted DD+ audio automatically. For a HIGH verdict, complete this scoping and targeting within 30 days so patching effort lands on the real exposed population first.
  2. Reduce automatic media handling — Where business-tolerable, disable or restrict automatic transcription, preview, or background decoding of inbound audio attachments in messaging and media workflows. This directly breaks the easiest 0-click entry condition; deploy the policy change within 30 days on the highest-risk device groups.
  3. Watch for media-service crash loops — Alert on repeated decoder, mediacodec, or media-framework crashes/restarts, especially immediately after receipt of external audio content. This will not stop exploitation, but it gives you one of the few realistic signals available before full post-exploitation telemetry appears; tune and deploy within 30 days.
  4. Enforce mobile threat defense and EDR telemetry — Make sure mobile security tooling and endpoint telemetry are enabled on the device classes most likely to process attacker-controlled media. These controls are more likely to catch the second stage of a chain than the parser bug itself, and should be enforced within 30 days for the relevant fleet.
What doesn't work
  • A perimeter WAF does nothing here; the vulnerable component is a local codec, not a web application.
  • A network vulnerability scan will miss the real risk because there is no stable open-port fingerprint for embedded Dolby UDC versions.
  • Generic attachment blocking by file extension is weak coverage because the payload can be containerized and reach the decoder through normal media formats.
06 · Verification

Crowdsourced verification payload.

Run this on an auditor workstation, CI job, or asset-enrichment pipeline, not on the target device itself. Invoke it with inventory facts, for example: python3 verify_cve_2025_54957.py --platform pixel --patch-level 2025-12-05 or python3 verify_cve_2025_54957.py --platform generic-udc --udc-version 4.13; no elevated privileges are required.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# verify_cve_2025_54957.py
# Determine likely exposure to CVE-2025-54957 from known version / patch-level facts.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/error

import argparse
import re
import sys
from datetime import datetime


def parse_date(value):
    try:
        return datetime.strptime(value, "%Y-%m-%d").date()
    except Exception:
        return None


def parse_version(value):
    if value is None:
        return None
    m = re.match(r'^\s*(\d+)\.(\d+)(?:\.(\d+))?\s*$', value)
    if not m:
        return None
    major = int(m.group(1))
    minor = int(m.group(2))
    patch = int(m.group(3) or 0)
    return (major, minor, patch)


def version_in_range(v, low, high):
    return low <= v <= high


def main():
    parser = argparse.ArgumentParser(description="Assess likely exposure to CVE-2025-54957 based on platform patch level or Dolby UDC version.")
    parser.add_argument("--platform", required=True, choices=["pixel", "android", "chromeos", "generic-udc", "windows"], help="Platform or assessment mode")
    parser.add_argument("--patch-level", help="Security patch level in YYYY-MM-DD format (for Android/Pixel/ChromeOS if known)")
    parser.add_argument("--udc-version", help="Dolby UDC version, e.g. 4.13")
    args = parser.parse_args()

    patch_date = parse_date(args.patch_level) if args.patch_level else None
    udc_version = parse_version(args.udc_version) if args.udc_version else None

    # Known vulnerable range from vendor/NVD
    vuln_low = (4, 5, 0)
    vuln_high = (4, 13, 999999)

    # Public downstream patch markers
    pixel_fixed = parse_date("2025-12-05")
    android_fixed = parse_date("2026-01-05")
    chromeos_first_fix = parse_date("2025-09-18")

    # Generic UDC version-only logic
    if args.platform == "generic-udc":
        if udc_version is None:
            print("UNKNOWN: provide --udc-version for generic-udc mode")
            sys.exit(2)
        if version_in_range(udc_version, vuln_low, vuln_high):
            print(f"VULNERABLE: Dolby UDC version {args.udc_version} falls in affected range 4.5 through 4.13")
            sys.exit(1)
        print(f"PATCHED: Dolby UDC version {args.udc_version} is outside the published affected range")
        sys.exit(0)

    # Pixel-specific public marker
    if args.platform == "pixel":
        if patch_date is not None:
            if patch_date >= pixel_fixed:
                print(f"PATCHED: Pixel patch level {args.patch_level} is at or newer than 2025-12-05")
                sys.exit(0)
            else:
                print(f"VULNERABLE: Pixel patch level {args.patch_level} predates 2025-12-05")
                sys.exit(1)
        if udc_version is not None:
            if version_in_range(udc_version, vuln_low, vuln_high):
                print(f"VULNERABLE: Dolby UDC version {args.udc_version} is in the affected range and no Pixel patch level was supplied")
                sys.exit(1)
            print(f"PATCHED: Dolby UDC version {args.udc_version} is outside the affected range")
            sys.exit(0)
        print("UNKNOWN: provide --patch-level or --udc-version for Pixel mode")
        sys.exit(2)

    # Generic Android public marker
    if args.platform == "android":
        if patch_date is not None:
            if patch_date >= android_fixed:
                print(f"PATCHED: Android patch level {args.patch_level} is at or newer than 2026-01-05")
                sys.exit(0)
            else:
                print(f"VULNERABLE: Android patch level {args.patch_level} predates 2026-01-05")
                sys.exit(1)
        if udc_version is not None:
            if version_in_range(udc_version, vuln_low, vuln_high):
                print(f"VULNERABLE: Dolby UDC version {args.udc_version} is in the affected range and no Android patch level was supplied")
                sys.exit(1)
            print(f"PATCHED: Dolby UDC version {args.udc_version} is outside the affected range")
            sys.exit(0)
        print("UNKNOWN: provide --patch-level or --udc-version for Android mode")
        sys.exit(2)

    # ChromeOS public marker from Project Zero timeline
    if args.platform == "chromeos":
        if patch_date is not None:
            if patch_date >= chromeos_first_fix:
                print(f"PATCHED: supplied ChromeOS patch/build date {args.patch_level} is on or after the first public binary-fix date 2025-09-18")
                sys.exit(0)
            else:
                print(f"VULNERABLE: supplied ChromeOS patch/build date {args.patch_level} predates 2025-09-18")
                sys.exit(1)
        if udc_version is not None:
            if version_in_range(udc_version, vuln_low, vuln_high):
                print(f"VULNERABLE: Dolby UDC version {args.udc_version} is in the affected range and no ChromeOS patch/build date was supplied")
                sys.exit(1)
            print(f"PATCHED: Dolby UDC version {args.udc_version} is outside the affected range")
            sys.exit(0)
        print("UNKNOWN: provide --patch-level or --udc-version for ChromeOS mode")
        sys.exit(2)

    # Windows is harder: public MSRC mapping exists, but a simple universal patch-level cutoff is not reliable here.
    if args.platform == "windows":
        if udc_version is not None:
            if version_in_range(udc_version, vuln_low, vuln_high):
                print(f"VULNERABLE: Dolby UDC version {args.udc_version} is in the affected range")
                sys.exit(1)
            print(f"PATCHED: Dolby UDC version {args.udc_version} is outside the affected range")
            sys.exit(0)
        print("UNKNOWN: Windows mode needs a trustworthy embedded Dolby UDC version from your inventory/SBOM data")
        sys.exit(2)

    print("UNKNOWN: unsupported assessment path")
    sys.exit(2)


if __name__ == "__main__":
    try:
        main()
    except KeyboardInterrupt:
        print("UNKNOWN: interrupted")
        sys.exit(2)
    except Exception as exc:
        print(f"UNKNOWN: {exc}")
        sys.exit(2)
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not treat this like a universal 9.8 emergency across every endpoint. First, use the noisgate mitigation SLA for a HIGH issue to identify and contain the real exposure set—managed Android/Pixel/ChromeOS devices and any workflows that auto-process untrusted DD+ media—within 30 days; then use the noisgate remediation SLA to push the vendor/device patches across that scoped population within 180 days. If you run a mobile-heavy fleet, front-load Pixels and Android devices below 2025-12-05 / 2026-01-05 patch levels, because that's where this CVE stops being a theoretical media bug and starts looking like a practical entry point.

Sources

  1. NVD CVE-2025-54957
  2. Dolby Security Advisory CVE-2025-54957
  3. Android Security Bulletin—January 2026
  4. Pixel Update Bulletin—December 2025
  5. Project Zero: A 0-click exploit chain for the Pixel 9 Part 1
  6. Project Zero: A 0-click exploit chain for the Pixel 9 Part 3
  7. GitHub PoC: AlphabugX/CVE-2025-54957
  8. CISA Known Exploited Vulnerabilities Catalog
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.