libwebp heap buffer overflow zero-day (CVE-2023-4863)

In September 2023, Google disclosed a heap buffer overflow in libwebp, the open-source library that decodes the WebP image format used across nearly every modern browser, mobile OS, and desktop application. Tracked as CVE-2023-4863, the flaw was not a theoretical bug caught by a fuzzer — it was already being weaponized in the wild as part of a zero-click iOS exploit chain used to install NSO Group's Pegasus spyware on the phones of civil society targets. Because libwebp is vendored, statically linked, or bundled inside an enormous number of downstream applications — Chrome, Firefox, Electron apps, image-processing SDKs, mobile frameworks — the practical blast radius extended far beyond "update your browser." This is one of the clearest recent examples of how a single vulnerable component deep in the supply chain can silently propagate risk into hundreds of unrelated products, and why software composition visibility matters as much as patching discipline.

What the vulnerability actually is

CVE-2023-4863 lives in libwebp's handling of the lossless WebP compression format, specifically in the Huffman coding logic used during image decoding (the BuildHuffmanTable path in huffman_utils/vp8l decoding code). When libwebp parses a specially crafted lossless WebP image, it can miscalculate the size of an internal buffer relative to the number of Huffman codes needed, leading to a heap buffer overflow — attacker-influenced data gets written outside the bounds of an allocated heap buffer.

Because image decoders are routinely invoked on completely untrusted input (any image rendered in a browser tab, chat app, PDF viewer, or thumbnail preview), a heap overflow in this code path is about as attacker-reachable as it gets. Successful exploitation can corrupt adjacent heap memory to achieve memory corruption and, when chained with additional sandbox-escape or privilege-escalation bugs, arbitrary code execution — which is exactly what happened in the real-world attacks that led to its discovery.

The bug was first identified and reported by Apple's Security Engineering and Architecture (SEAR) team and The Citizen Lab, who found it being actively exploited as one link in the "BLASTPASS" exploit chain (paired with an ImageIO vulnerability, CVE-2023-41064) to deliver Pegasus spyware via maliciously crafted images sent through iMessage — with zero clicks required from the victim.

Affected versions and components

• libwebp: all versions prior to 1.3.2 are vulnerable. This is the authoritative fix version; anything embedding an older libwebp is exposed.
• Google Chrome / Chromium: versions before 116.0.5845.187 (Chrome bundles its own copy of libwebp for WebP decoding).
• Mozilla Firefox and Thunderbird: versions before 117.0.1 / 118.0.1 and corresponding Thunderbird releases.
• Electron-based applications: any app built on an Electron/Chromium runtime older than the patched build inherits the flaw — this swept in a very long tail of desktop apps (chat clients, IDEs, productivity tools) that most security teams don't think of as "browsers."
• Mobile and native applications: Android apps, iOS apps, and cross-platform frameworks that statically link libwebp for image handling (including many that vendor it transitively through image libraries such as ImageMagick, libvips, and various Rust/Go/Python bindings).
• Container base images and OS packages: distro packages (Debian, Ubuntu, Alpine, RHEL, etc.) shipping libwebp, and any container image built on top of them.

The multi-ecosystem exposure is the real story here: this is a C library that gets pulled in transitively, often several layers deep in a dependency tree, with no obvious "libwebp" line item in a team's mental model of their attack surface.

CVSS, EPSS, and KEV context

CVE-2023-4863's severity scoring tells its own story about how understated this vulnerability initially looked. It was originally filed against Chrome specifically, with an initial CVSS v3.1 score of 8.8 (High). Once NVD and the broader community recognized that the underlying defect was in libwebp itself — not a Chrome-specific issue — the score was revised upward to 9.6 (Critical), reflecting the low complexity of exploitation, no privileges required, and the potential for full system compromise across a much wider set of affected products. A related tracking identifier, CVE-2023-5129, was briefly filed to capture the libwebp-specific scope before being reconciled as a duplicate of CVE-2023-4863.

Given confirmed in-the-wild exploitation prior to public disclosure, CVE-2023-4863 was added to CISA's Known Exploited Vulnerabilities (KEV) catalog, with a mandated remediation deadline for federal civilian agencies. Its EPSS (Exploit Prediction Scoring System) probability sits at the high end of the distribution, consistent with a vulnerability that had a working exploit chain in active use against real targets before a patch was even available — the textbook definition of a zero-day.

For any organization prioritizing a remediation backlog by risk rather than by CVSS score alone, this CVE is a strong illustration of why KEV membership and EPSS should carry at least as much weight as the base severity score: a "High" that is actively being exploited in a spyware campaign is a different animal than a theoretical "High" sitting in a scanner report.

Timeline

• Early September 2023: Citizen Lab, investigating a compromised device belonging to a Washington DC-based civil society organization employee, discovers the BLASTPASS zero-click iMessage exploit chain, which includes a malicious WebP image triggering a libwebp memory corruption bug.
• September 6, 2023: Google ships a Chrome update patching the flaw and assigns CVE-2023-4863, initially scoped as a Chrome vulnerability with a CVSS score of 8.8.
• September 7, 2023: Citizen Lab publishes its BLASTPASS report; Apple simultaneously patches the related ImageIO bug (CVE-2023-41064) and ships emergency iOS/iPadOS/macOS/watchOS updates.
• September 11, 2023: The libwebp project releases version 1.3.2, containing the upstream fix, making clear the vulnerability lives in the shared library rather than Chrome's code alone.
• Mid-to-late September 2023: Firefox, Thunderbird, and a wave of Electron-based applications ship patched builds as the ecosystem-wide scope becomes apparent.
• September 27, 2023: NVD revises the CVSS score for CVE-2023-4863 from 8.8 to 9.6, formally acknowledging the vulnerability's true scope across every product embedding libwebp.
• Following weeks: CISA adds the CVE to the KEV catalog; security teams across the industry begin the much harder task of finding every place libwebp is vendored, statically linked, or transitively bundled inside their software estate.

Remediation steps

1. Update libwebp to 1.3.2 or later wherever it is directly consumed, and rebuild/redeploy any statically linked binaries — a package manager bump alone will not fix an already-compiled artifact.
2. Patch browsers and browser-based runtimes immediately: Chrome ≥116.0.5845.187, Firefox ≥117.0.1, Thunderbird ≥102.15.1/115.2.2, and any Electron app framework updated to a patched Chromium version.
3. Inventory transitive exposure. Search container images, mobile app bundles, and language-ecosystem dependency trees (npm, PyPI, crates.io, Go modules, RubyGems) for anything that vendors or dynamically links libwebp — including image-processing libraries like ImageMagick, libvips, Pillow (via system libwebp), and Skia.
4. Rebuild and redeploy container images and OS packages rather than relying on host-level library patches alone; verify base images have pulled the fixed distro package (libwebp / libwebp-dev/libwebp0 on most distros).
5. Re-scan SBOMs after remediation to confirm no build stage, cached layer, or offline artifact still references the vulnerable version — a common failure mode is patching the base image but not the application layer that copied in a vendored .so/.dll earlier in the pipeline.
6. Treat KEV-listed findings as SLA-exempt from normal triage queues. Given confirmed exploitation, this class of finding should bypass standard severity-based SLAs and go to the front of the remediation queue regardless of where it sits in a dependency tree.

How Safeguard Helps

CVE-2023-4863 is exactly the kind of finding that overwhelms traditional SCA tooling: it is buried several layers deep in dependency graphs, silently vendored into binaries, and trivially missed by scanners that only check top-level manifests. Safeguard's SBOM generation and ingestion pipeline builds a complete, transitive inventory of every component in your software — including statically linked C libraries like libwebp — so this vulnerability surfaces even when it's hiding inside an Electron app or a container base image three layers removed from your code. Griffin AI then correlates that inventory against live exploitation intelligence and KEV/EPSS signal to flag CVE-2023-4863 findings as immediate priorities rather than another line in a severity-sorted backlog. Reachability analysis goes a step further, confirming whether the vulnerable WebP-decoding code path is actually invoked by your application's runtime behavior, so teams aren't burning cycles chasing unreachable instances while a real exploitable path sits unpatched. Finally, where a fix is available, Safeguard's auto-fix PR generation opens the dependency bump or base-image update directly against your repository, cutting the time between "known exploited" and "patched in production" down from days to minutes.