libwebp animated WebP overflow (CVE-2023-5129)

In September 2023, a single malformed WebP image was enough to hand an attacker code execution inside Chrome, Firefox, Signal, Slack, and thousands of other applications that quietly bundle Google's libwebp image library. The flaw — a heap buffer overflow in libwebp's Huffman coding logic during animated WebP (ANIM) decoding — was first tracked as CVE-2023-4863 and confirmed as an actively exploited zero-day used in real-world spyware chains. Weeks later, NVD assigned a second identifier, CVE-2023-5129, to the same underlying libwebp defect, initially scoring it a maximum CVSS 10.0. That second CVE became one of the more instructive case studies in vulnerability management in recent years: it was ultimately withdrawn as a duplicate, but not before it had already propagated through advisory feeds, SBOM tools, and scanner databases — leaving security teams to reconcile two CVE numbers, two severity scores, and a fractured picture of a single, very real bug.

For supply chain security teams, CVE-2023-5129 is less a story about a novel exploitation technique and more a case study in why identifier hygiene, transitive dependency visibility, and reachability context matter as much as the raw CVSS number.

What Happened

The vulnerability lives in BuildHuffmanTable(), part of libwebp's lossless/Huffman decoding path used when parsing animated WebP frames. When a crafted WebP file specifies a color cache configuration that doesn't match what the decoder allocates for, the Huffman table construction routine writes past the bounds of a heap-allocated buffer. Because the corrupted memory is attacker-influenced, the overflow can be leveraged for memory corruption and, in the right conditions, arbitrary code execution — not just a crash.

What makes this bug dangerous isn't algorithmic novelty; it's ubiquity. libwebp is the reference implementation for WebP encoding and decoding, and it is vendored, statically linked, or wrapped by an enormous number of downstream projects: every Chromium-based browser (Chrome, Edge, Brave, Opera), Firefox, Electron applications (Slack, Discord, Microsoft Teams, 1Password, Signal Desktop), image libraries like ImageMagick, libvips, Skia, and GDK-Pixbuf, and language ecosystem packages such as Pillow (Python), sharp and libwebp-sys (Node.js/Rust), and countless container base images that quietly install libwebp as an OS package dependency for unrelated software. A single-line fix in one C library rippled outward into a patching problem spanning nearly every layer of the modern software stack.

Affected Versions and Components

• libwebp: all versions prior to 1.3.2 are vulnerable. The fix landed in the libwebp source tree in September 2023 and shipped in the 1.3.2 release.
• Browsers: Chrome versions before 116.0.5845.187/188, Firefox before 117.0.1 and 115.2.1 ESR, and other Chromium- and Gecko-based browsers that bundle their own libwebp copies.
• Desktop/Electron apps: any Electron-based application bundling an Electron/Chromium runtime older than the patched builds — this affected a long tail of chat, note-taking, and productivity apps that had no idea they shipped a vulnerable codec.
• Image-processing libraries and language bindings: ImageMagick, libvips, Pillow wheels that bundle a static libwebp, sharp, Skia, and any application that links against a system libwebp package older than 1.3.2 on Linux distributions.
• Container base images: Alpine, Debian, and Ubuntu images that installed libwebp/libwebp7 as a transitive OS dependency for unrelated packages (common with headless image processing, PDF rendering, and thumbnail-generation services).

Because libwebp is almost never a direct dependency — it arrives transitively through an image library, a runtime, or a base image — most affected organizations did not find it by searching their own manifests. It had to be found in the dependency graph.

Severity: CVSS, EPSS, and KEV Context

CVE-2023-4863 was added to CISA's Known Exploited Vulnerabilities (KEV) catalog almost immediately after disclosure, reflecting credible evidence of active, in-the-wild exploitation — reporting at the time tied exploitation to spyware delivery chains targeting mobile devices, used alongside a related Apple ImageIO/CoreGraphics flaw. Google's own advisory rated the Chrome-specific issue at CVSS 8.8, consistent with a browser-context remote code execution bug requiring user interaction (viewing a malicious image).

CVE-2023-5129, covering the same defect in the underlying libwebp library rather than a specific browser context, was initially published by NVD with a CVSS base score of 10.0 — the maximum possible — reflecting the unconstrained network attack vector and critical impact when libwebp is embedded in server-side or unsandboxed image-processing pipelines. That perfect-10 score, attached to a library present in an enormous share of the software supply chain, triggered understandable alarm and a wave of urgent patching advisories.

Not long after, however, NVD and the CVE program reviewed CVE-2023-5129 and determined it to be a duplicate of CVE-2023-4863, marking the newer identifier as rejected/withdrawn. For EPSS purposes and ongoing tracking, CVE-2023-4863 remains the canonical identifier, and — given its KEV status and confirmed exploitation — it consistently scores in the highest EPSS percentiles among CVEs published in that period, reflecting both observed exploitation and the enormous number of internet-facing systems that could plausibly process untrusted WebP input.

The practical consequence for defenders: two CVE IDs, two advisory trails, and a rejected-but-still-cited identifier that many SBOM and scanning tools continued to surface for months afterward because the data had already been ingested and cross-referenced by GHSA, OSV, and vendor advisories before the rejection propagated back through those same feeds.

Timeline

• September 6, 2023 — Google discloses CVE-2023-4863 and ships an emergency Chrome update (116.0.5845.187/188) after confirming active exploitation.
• September 7–11, 2023 — Apple and Mozilla ship corresponding fixes; security researchers link exploitation to a mobile spyware delivery chain exploiting an image-parsing vulnerability chain.
• September 2023 — The libwebp project lands the fix for the BuildHuffmanTable overflow, released as libwebp 1.3.2; downstream projects begin rebuilding and re-vendoring.
• Late September 2023 — NVD publishes CVE-2023-5129 as a distinct, library-level identifier for the same root cause, with an initial CVSS score of 10.0, prompting a second wave of urgent advisories across the industry.
• October 2023 — CVE-2023-5129 is reviewed and marked as a duplicate of CVE-2023-4863 and withdrawn, though it continues to appear in some downstream advisory data and scanner output for weeks afterward.

Remediation Steps

1. Upgrade libwebp to 1.3.2 or later wherever it is present — as a direct package, a transitive OS dependency, or vendored/statically compiled into another binary.
2. Update browsers and Electron-based applications to the patched builds (Chrome ≥116.0.5845.187, Firefox ≥117.0.1/115.2.1 ESR, and any Electron app rebuilt against a patched Chromium runtime). Do not rely solely on auto-update assumptions for enterprise-managed or air-gapped fleets.
3. Rebuild and re-scan container images. Check base image manifests for libwebp/libwebp7 package versions and rebuild any images pinned to a pre-1.3.2 release, even if libwebp is not the image's primary purpose.
4. Audit language ecosystem packages — Pillow wheels, sharp, libwebp-sys, and similar bindings often bundle a private copy of libwebp rather than linking dynamically; a system-level patch will not remediate these.
5. Reconcile both CVE identifiers in your tracking systems. Ensure remediation records, ticketing, and exception approvals reference CVE-2023-4863 as canonical, but don't let automated deduplication silently drop findings tied to CVE-2023-5129 without confirming the underlying libwebp version was actually upgraded.
6. Prioritize by exposure, not just presence. Applications that decode untrusted, user-supplied images (upload pipelines, thumbnail generators, chat apps, document converters) are far higher priority than internal tooling that happens to link libwebp but never parses external input.
7. Treat as emergency-patch priority given confirmed KEV status and in-the-wild exploitation — this is not a bug to leave in a routine patch cycle.

How Safeguard Helps

CVE-2023-5129 is a textbook example of why flat CVE matching isn't enough: the same vulnerability existed under two identifiers, buried under multiple layers of transitive dependencies, in components most teams never listed as a direct dependency. Safeguard's SBOM generation and ingest pipeline resolves exactly this kind of ambiguity, normalizing advisory data across CVE-2023-4863 and the withdrawn CVE-2023-5129 so a single libwebp finding isn't missed because one identifier was rejected. Our reachability analysis then determines whether the vulnerable animated-WebP decode path in BuildHuffmanTable is actually invoked by your application's real attack surface — distinguishing an internet-facing image upload service from a vendored dependency that never processes untrusted input. Griffin AI correlates that reachability signal with exploitation intelligence and KEV status to automatically triage and prioritize libwebp findings above lower-risk noise, and Safeguard's auto-fix PRs open the version bump — updating direct dependencies, lockfiles, and base image references to libwebp 1.3.2 or later — directly against your repository, cutting the remediation loop from a multi-team scramble down to a single reviewable pull request.