CVE feed → CVE-2023-4863

CVE-2023-4863 — libwebp heap overflow (RCE via crafted image)

One library, hundreds of products. CVE-2023-4863 is a heap buffer overflow in libwebp's lossless decoder — a routine memory-safety bug that became one of 2023's most consequential vulnerabilities because libwebp ships statically linked inside Chromium, Firefox, Safari, every Electron app on your desktop, and a long tail of server-side image-processing tools. The single upstream fix had to be re-issued by every downstream re-bundler, and many took weeks or months to catch up.

TL;DR

• Heap buffer overflow in libwebp's BuildHuffmanTable() when decoding crafted lossless WebP images — exploitable for remote code execution in any process that decodes an attacker-supplied image.
• Disclosed 2023-09-11 by Apple's Security Engineering and Architecture team after Citizen Lab observed the BLASTPASS exploit chain (NSO Group / Pegasus) using it against iOS Safari. Actively exploited in-the-wild at disclosure; subsequently CISA KEV-listed.
• Affects libwebp 0.5.0 through 1.3.1; fixed in upstream libwebp 1.3.2 (2023-09-12).
• Originally filed against Chrome as CVE-2023-4863, then re-scoped to libwebp. The same code path is reachable in every Chromium derivative, Firefox, Safari, Electron-based apps, image libraries (Pillow, ImageMagick, libheif), and server-side thumbnailers (Plex, Jellyfin, *arr, Home Assistant).
• Fix path: system libwebp gets an apt/dnf update; bundled libwebp gets fixed only when each downstream vendor ships a new release. The "did I patch it?" question has a per-application answer, not a per-host answer.

At a glance

What goes wrong in BuildHuffmanTable

WebP's lossless format uses a Huffman-coded entropy layer. When libwebp decodes a lossless image, it builds an in-memory Huffman lookup table from code-length statistics carried in the image header. The function BuildHuffmanTable() in src/utils/huffman_utils.c walks those code-length groups, computes how large the lookup table needs to be, and writes the table entries.

The bug is in the size calculation. For an unusual but specification-conformant arrangement of code lengths — multiple subtables overlapping at certain depths — the calculation underestimates how many entries the writer will produce. The buffer is allocated for the smaller size, then the writer walks off the end. Because the table sits on the heap adjacent to attacker-influenceable allocations, an attacker who controls the WebP file controls what gets clobbered.

Triggering it requires only that the victim's process decode the crafted WebP — open a web page, render a thumbnail, preview an attachment. No user interaction beyond what already happens when an image loads. In the BLASTPASS chain, the trigger was an iMessage attachment that Safari decoded automatically as part of a PassKit pass.

The bundled-library problem

libwebp is one of those libraries that gets vendored everywhere. Apps want predictable behaviour, predictable performance, and to avoid dlopen-ing a system library that may not exist or may be the wrong version. So they statically link or bundle libwebp into their own binary, ship it in their package, and forget about it until something like this happens.

A non-exhaustive list of products that shipped affected libwebp versions in September 2023:

• Browsers: Chromium and every derivative (Chrome, Edge, Brave, Vivaldi, Opera), Firefox, Safari. Each vendor had to ship a new browser release pulling in libwebp 1.3.2 (or the equivalent backport).
• Electron apps: Slack, Microsoft Teams, VS Code, 1Password, Signal Desktop, Discord, Spotify, Notion, and effectively every desktop application built on Electron. Each one bundles its own copy of Chromium, including its own copy of libwebp. The fix shipped per-app on each vendor's own cadence — some within days, many over the following months.
• Image libraries: Pillow (Python), ImageMagick, GraphicsMagick, libheif, and anything else that links libwebp for WebP encode/decode support. Server-side image-processing pipelines built on these inherit the bug until the library is updated and the application is restarted.
• Homelab apps: Home Assistant (image processing and dashboard thumbnails), Plex and Jellyfin (artwork and preview generation), the *arr suite (Sonarr, Radarr, Lidarr, Readarr — all of which fetch and process cover art), Immich, PhotoPrism, Nextcloud preview generators. Each one's libwebp lives inside its own container or binary and updates on the app vendor's release schedule, not yours.

The "double counting" problem this creates: Chrome got CVE-2023-4863. Electron got the same code path with the same bug — and for weeks there was no separate CVE for downstream Electron apps. Every vendor that re-bundled the library had to issue its own patch, and many of them did so without a fresh CVE number, so a scanner looking only at canonical CVE IDs would have missed the long tail.

Affected versions and fix paths

System libwebp (the shared library installed by your package manager) gets the standard distro security-update treatment. The table below covers the system package. For bundled libwebp inside browsers and Electron apps, see the "Bundled libwebp" rows.

Quick scan check

Run this on each Linux host to inventory the system libwebp. Compare the installed version against the table above.

# Debian / Ubuntu
apt list --installed 2>/dev/null | grep -i libwebp
dpkg-query -W -f='${binary:Package} ${Version}\n' '*libwebp*' 2>/dev/null

# RHEL family
rpm -q libwebp
rpm -qa | grep -i libwebp

For bundled libwebp the answer is per-application. There is no single command that enumerates statically-linked libwebp inside every binary and container on a host. The practical rule: check the changelog of every application that processes user-supplied images for a libwebp update after 2023-09-12. If the vendor has shipped a release since then that mentions libwebp, WebP, CVE-2023-4863, or "security update", you're almost certainly covered. If you can't find one, you probably aren't.

What Noxen does about this

Noxen matches CVE-2023-4863 against the system libwebp package version on every host you've enrolled. The agentless SSH probe inventories libwebp / libwebp7 / libwebp6 via the host's package manager and the matcher consults the daily-refreshed CVE feed, applying distro-aware version comparison so backports are credited correctly. If a host is on Debian 12 and still running an unpatched libwebp, the next scan surfaces it.

Noxen does not currently detect statically-linked libwebp inside Electron apps, browser bundles, or container images without a registry SBOM. That kind of binary-introspection probe (planned as LanguagePackageProbe on the roadmap) is necessary for the bundled-library problem and is explicitly out of scope today. The honest line: Noxen catches the system layer; the bundled layer is on you and your application vendors. The paired blog post walks through the rings of "did I patch it?" and what defence-in-depth around the bundled layer looks like for a homelab.

The deep-dive

For the full narrative — the September 2023 disclosure timeline, the BLASTPASS exploit chain context, why bundled-library CVEs keep blindsiding fleets, and a four-ring "did I patch it?" checklist for your homelab — read The libwebp problem — when one bundled library breaks a hundred apps on the Noxen blog. The parallel with CVE-2024-3094 (xz-utils) is unavoidable: different mechanism, same structural lesson about dependency depth.

Authoritative sources

• NVD entry for CVE-2023-4863
• cve.org record
• FIRST EPSS API for CVE-2023-4863
• CISA KEV catalogue (search for CVE-2023-4863)
• libwebp 1.3.2 release tag (upstream fix)

See what Noxen does about CVEs like this →   More on CVE management →