ZombieMutex / Security research / Technical write-up
CVE-2023-4863 — libwebp image decoder heap overflow
Google / libwebp · libwebp / image-consuming applications · Libraries
My engineering notes on a third-party disclosed vulnerability. I didn't discover this CVE or test it against a real target. Source-backed facts are distinguished from defensive recommendations and conceptual models.
01 / Description
What happened
A heap buffer overflow in libwebp image decoding could be reached through crafted WebP content, affecting Chrome and other applications that bundled the vulnerable library.
An image isn't passive data once a native decoder processes it. The libwebp overflow affected a widely reused library, which meant browser patching was only part of the response. A mobile app, embedded SDK or desktop tool could carry its own vulnerable copy.
The part I'd remember
A dependency's patched version in one product does not establish that every bundled copy is fixed.
02 / Severity
Metrics
CVSS v3.1 base score
8.8 / 10
Severity
High
Score source
NVD
CVSS 3.1 vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:HNVD CVSS v3.1 base score. The vector assumes user interaction; this does not mean every integration has an identical exploit path.
CISA Known Exploited Vulnerability
This vulnerability appears in CISA's KEV catalog. That is evidence of exploitation in the wild, not proof that a particular installation was attacked.
Check CISA entry03 / Affected scope
Known affected software
Vulnerable libwebp releases before 1.3.2 and applications that embed affected decoder copies. A curated, source-attributed overview—not a complete CPE inventory or version classifier.
| Product / branch | Condition / fix | Status |
|---|---|---|
| libwebp before 1.3.2 | Affected decoder versions; exact integration depends on application build and packaging. | Affected |
| libwebp 1.3.2 and corrected downstream builds | The upstream decoder issue was addressed; confirm the library actually loaded in your application. | Fixed |
| Browser and mobile/desktop applications | Applications with bundled, vendored or transitive vulnerable libwebp copies can be in scope. | Conditional |
For the exhaustive affected-software matrices, current hotfixes and CPE strings, use the vendor/CVE/NVD records linked below. An affected product family alone does not establish exposure.
04 / Engineering notes
How I'd think through it
01Why image parsing crosses a trust boundary
The entry point is a crafted WebP image. The important transition happens when untrusted compressed bytes reach native decoding logic that manages memory buffers. A heap write outside the intended bounds can corrupt nearby memory.
The impact depends on how the application loads the image, its sandbox and the mitigations around the decoder. I wouldn't treat every WebP file as a working exploit, but I'd take the decoder's attack surface seriously.
02A dependency inventory problem
libwebp is not only a browser problem. Applications can package a copy in a native SDK, image-processing pipeline or helper library. Upgrading a browser is necessary for that browser, but it doesn't repair unrelated apps using the same affected code.
The actual binary dependency tree matters more than a manifest search for 'libwebp'. Statically linked code and redistributed SDKs are easy to miss.
03Validation without a malicious image
A safe regression plan checks a patched decoder and uses sanitized, ordinary images to verify functionality. If an authorized security team has a validated proof-of-concept, that belongs in a controlled environment with its own safeguards.
For ordinary release engineering, the strongest signal is the actual bundled and loaded version plus a reproducible dependency audit. 'We upgraded an npm package' isn't enough if a native library was embedded separately.
05 / Classification
Weakness enumeration
- CWE-787Out-of-bounds write
Weakness identifiers describe categories of mistakes, not a step-by-step exploit procedure.
06 / Evidence trail
References and further reading
These links leave ZombieMutex and point to the original vulnerability records, vendor guidance and supporting research. An outbound link is not an endorsement.
| Reference | Source / purpose |
|---|---|
| NVD vulnerability record | NVD |
| CVE record | CVE record |
| CISA KEV catalog | CISA |
What supports the conclusions
- The NVD record describes the vulnerable heap write and a CVSS 3.1 base score of 8.8.
- The affected code was used in multiple products; a product-specific fix must be verified separately.
- No exploit sample was executed or published as part of this write-up.
07 / Editorial record
Scope, limitations and review history
- CVE publication
- 2023-09-12
- Editorial snapshot reviewed
- 2026-11-08
- Source score
- NVD · CVSS v3.1
- Research method
- Public-source analysis, not hands-on exploitation
This article does not enumerate every impacted application or embedded SDK. Use vendor bulletins and a current software-bill-of-materials review to assess your builds.
This is a third-party disclosed CVE explained in my engineering notebook. I don't claim to have discovered it, tested impacted customer systems or received a bug bounty for it. Use current official vendor guidance for security decisions.
Public conversation / GitHub Discussions
Discuss this article
Read and reply using GitHub Discussions. A GitHub account is needed to post. Comments are public and subject to GitHub moderation.
For privacy, the external giscus widget does not load until you choose to open it. Opening it connects your browser to giscus and GitHub. Do not post credentials or private project data.