CVSS scoring explained, and where severity scores go wrong

When Google shipped an emergency Chrome update on September 11, 2023, the release notes described a single, unassuming bug: a heap buffer overflow in WebP image processing, tracked as CVE-2023-4863, scored 8.8 (High) by NVD. Within two weeks that story fell apart. The flaw wasn't a Chrome bug at all — it lived in libwebp, the WebP codec library bundled into nearly every major browser, dozens of Electron apps, and countless image-processing pipelines. NVD revised the score to 9.8 (Critical). A second CVE, CVE-2023-5129, was filed for the same root cause and later marked a duplicate. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog because it had already been used in the wild, chained with a PDF parsing flaw in Apple's ImageIO framework as part of the BLASTPASS exploit chain deployed against journalists and activists via NSO Group's Pegasus spyware.

The technical bug was simple: a malformed WebP file could trigger a heap buffer overflow during Huffman coding table construction, leading to arbitrary code execution with no user interaction required — a zero-click exploit primitive. The business impact was anything but simple. Because libwebp is a transitive dependency buried three or four layers deep in most software supply chains, security teams spent weeks just figuring out whether they were exposed, while the CVE identifier, the CVSS score, and the affected-component list all kept shifting under them. It's one of the cleanest real-world illustrations of why "what's the CVSS score" is the wrong first question to ask about a vulnerability — and why scanners that stop at that question routinely mis-prioritize the exact bugs attackers are already using.

Affected versions and components

libwebp versions prior to 1.3.2 contain the vulnerable Huffman table decoding logic. Because libwebp ships as a static or vendored dependency in an enormous number of downstream projects, the practical blast radius extended far beyond "update libwebp":

• Browsers: Chrome before 116.0.5845.187, Firefox before 117.0.1, Firefox ESR before 102.15.1 and 115.2.1, Microsoft Edge, Brave, Opera, and Vivaldi (all Chromium-based).
• Electron and Chromium Embedded Framework apps: Signal, 1Password, Slack, Discord, Microsoft Teams, Notion, and hundreds of lesser-known desktop apps that bundle their own Chromium runtime and don't auto-inherit OS-level browser patches.
• Image libraries and toolchains: ImageMagick, Skia, Android's image codecs, and language bindings such as Pillow (via libwebp) that many backend services use for thumbnailing or transcoding.
• Container base images: Alpine, Debian, and Ubuntu images with libwebp installed as a system package, meaning the vulnerability rode along in thousands of derivative container images even when the application itself never touched WebP directly.

That last category is where software composition analysis (SCA) tools should earn their keep — and where many fall short. A registry-level or manifest-level scan can tell you libwebp is present. It cannot tell you whether your application ever decodes untrusted WebP input, which is the difference between "theoretically affected" and "actually exploitable."

CVSS, EPSS, and KEV: three numbers, three different questions

This case is a useful teaching example precisely because all three major severity signals were in play, and they measured different things:

CVSS (Common Vulnerability Scoring System) answers "how bad is this vulnerability in the abstract, assuming it's reachable and exploited?" The base score is built from exploitability metrics (attack vector, complexity, privileges required, user interaction) and impact metrics (confidentiality, integrity, availability). CVE-2023-4863's vector string — AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H under CVSS 3.1 — reflects a network-reachable, low-complexity, no-interaction bug with full impact and a scope change (the overflow could affect components beyond the vulnerable one). That combination is why it landed at 9.8 once properly attributed to libwebp rather than treated as a narrower Chrome-specific issue. But CVSS has no field for "is this actually being exploited" or "is this reachable in your specific build" — it's a severity taxonomy, not a risk model.

EPSS (Exploit Prediction Scoring System) answers a different question: "what's the probability this CVE will be exploited in the next 30 days?" It's a statistical model trained on real-world exploitation signals — scanner activity, dark web chatter, proof-of-concept availability. CVE-2023-4863's EPSS score climbed into the 90th-plus percentile almost immediately once the KEV listing and Pegasus reporting became public, which is a far stronger prioritization signal than the base CVSS score alone. Plenty of 9.8-scored CVEs sit at near-zero EPSS for their entire lifecycle because no one has bothered to weaponize them.

KEV (Known Exploited Vulnerabilities) answers the most binding question of all: "is CISA telling federal agencies — and by extension, everyone doing business with them — that this is confirmed to be exploited in active campaigns, with a mandated remediation deadline?" KEV status doesn't come from a formula; it comes from evidence. CVE-2023-4863 was added within days of the BLASTPASS disclosure, well ahead of many organizations even finishing their initial impact assessment.

The gap between these three signals is exactly where severity scoring goes wrong in practice. A team that only tracks CVSS treats every 9.8 the same, whether it's actively deployed in a spyware chain or sitting unexploited in an obscure library. A team that ignores EPSS and KEV entirely will correctly triage this one as urgent, purely by luck, but will systematically deprioritize other actively-exploited bugs that happen to carry a "merely High" CVSS score of 7.x. This is a known, documented weakness of severity-first scanning tools — including widely used SCA platforms like JFrog Xray, whose default risk views lean heavily on CVSS severity buckets and vendor advisory data, without EPSS or KEV correlation surfaced as a first-class signal in the primary triage workflow. That design choice makes sense for compliance checklists. It's a poor fit for a SOC that needs to answer "what do we patch this week" under limited engineering capacity.

Timeline

• Early September 2023: Citizen Lab discloses BLASTPASS, a zero-click iMessage exploit chain used to deliver NSO Group's Pegasus spyware, involving a malicious PDF and an image parsing flaw.
• September 6, 2023: Apple ships emergency patches for the ImageIO component of the chain.
• September 11, 2023: Google patches Chrome and assigns CVE-2023-4863, initially scoped and scored as a Chrome-specific bug (8.8).
• September 12–20, 2023: Firefox, Chromium-based browsers, and Electron-based desktop apps ship patches as the community realizes the vulnerable code lives in libwebp itself, not just Chrome's WebP handling.
• September 2023: CISA adds CVE-2023-4863 to the KEV catalog, confirming active exploitation.
• September 27, 2023 (approx.): NVD revises the CVSS score to 9.8 to reflect the true scope of affected software.
• Late September 2023: libwebp maintainers file CVE-2023-5129 for the same underlying defect; it is later marked a duplicate/reject, but not before it propagated into multiple vulnerability databases and scanner feeds, causing double-counting and reconciliation headaches for teams tracking remediation.
• Into 2024: Reports continue to surface of container images, mobile apps, and enterprise software still shipping unpatched libwebp, illustrating how deep and persistent transitive dependency exposure can be.

Remediation steps

1. Inventory every path libwebp enters your environment. Don't rely on a single manifest scan — check container base images, vendored/static libraries, language bindings (Pillow, node-webp, etc.), and any Electron or CEF-based desktop applications.
2. Upgrade to libwebp 1.3.2 or later, or the patched browser/runtime version that bundles it (Chrome 116.0.5845.187+, Firefox 117.0.1+/ESR 102.15.1+/115.2.1+).
3. Rebuild and redeploy container images rather than assuming an OS package manager update alone closes the gap — many images vendor a static copy of libwebp that isn't touched by apt upgrade.
4. Reconcile duplicate CVE entries. If your tracking shows both CVE-2023-4863 and CVE-2023-5129 open against the same asset, confirm they resolve to a single remediation action rather than double-counting risk or effort.
5. Prioritize by reachability and exploitation evidence, not CVSS alone. Confirm whether your application actually decodes untrusted WebP input before treating this as a top-priority fire drill versus a routine dependency bump — and cross-reference EPSS and KEV status for every other CVE in your backlog while you're at it.
6. Verify the fix, not just the version string — confirm the patched Huffman decoding logic is actually present in the compiled artifact, especially for statically linked binaries.

How Safeguard Helps

This case is a textbook argument for why severity scoring needs more inputs than a single CVSS number. Safeguard ingests CVSS, EPSS, and KEV signals for every vulnerability in your software supply chain and correlates them against your actual SBOM and build artifacts — including transitive, vendored, and statically linked dependencies like libwebp that manifest-only scanners routinely miss. When duplicate or superseded CVE identifiers like CVE-2023-4863 and CVE-2023-5129 appear in upstream feeds, Safeguard reconciles them into a single tracked finding instead of inflating your backlog with phantom duplicates.

Where CVSS-forward tools stop at "this component has a 9.8," Safeguard adds reachability analysis to confirm whether the vulnerable code path is actually invoked by your application, live exploitation intelligence to flag when a CVE moves onto KEV or spikes in EPSS after you've already triaged it, and continuous re-scoring so that a bug initially filed as a narrow, moderate-severity issue — the way CVE-2023-4863 was on day one — gets re-prioritized automatically the moment new evidence changes the picture. The result is a remediation queue ordered by actual risk to your environment, not by whichever severity label happened to be assigned at disclosure time.

For teams comparing SCA platforms, the question worth asking isn't just "does it flag CVSS 9.8 vulnerabilities" — every tool does that. It's "does it tell me which of my dozens of 9.8s is being exploited against software like mine, right now, and which one is safely deferrable." That's the gap Safeguard is built to close.