Critical Vulnerability in LibWebP Exploited in the Wild


The vulnerability discovered in the libwebp library extends beyond browsers such as Chrome, Edge and Chromium-based applications because libwebp is in widespread use by numerous operating systems and popular application frameworks that render .webp images.
As a result, the libwebp vulnerability impacts general-purpose software like Pillow and FFMPEG.
It's important to note that some of these applications and software components can be bundled as dependencies to containers and possibly direct or in-direct dependencies to your software.
Reported CVEs
CVE-2023-4863 CVSS: 8.8: Heap buffer overflow in libwebp in Google Chrome prior to 116.0.5845.187 and libwebp 1.3.2 allowed a remote attacker to perform an out-of-bounds memory write via a crafted HTML page. (Chromium security severity: Critical)
CVE-2023-41064 CVSS: 7.8: Buffer overflow vulnerability in iOS 16.6.1 and iPadOS 16.6.1, macOS Monterey 12.6.9, macOS Ventura 13.5.2, iOS 15.7.9 and iPadOS 15.7.9, macOS Big Sur 11.7.10. Processing a maliciously crafted image may lead to arbitrary code execution.
CVE-2023-41061 CVSS: 7.8: This issue is fixed in watchOS 9.6.2, iOS 16.6.1 and iPadOS 16.6.1. A maliciously crafted attachment may result in arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.
Note that CVE-2023-5129, submitted by Google Chrome and initially ranked with the maximum vulnerability score of 10, was later rejected due to duplication.
How can I tell if I am Affected?
Libwebp from 0.5.0 up to and including 1.3.1 are affected. You must ensure that you have version 1.3.2 or newer to remediate the vulnerability.
To know whether you’re affected you need to understand all the building blocks of your software. A Software Bill of Materials (SBOM) is a comprehensive inventory, a detailed list of ingredients that make up software components, including the usage and version of libwebp. Because SBOM contains every building block of the software, it means that it contains much more than the direct dependencies of your software. Before you rush into fixing the vulnerability, first, ensure it is executed. If the vulnerable library exists but isn't running, it doesn't pose a security gap.
Runtime SBOM required to fix libwebp
Determining if libwebp is running in your environment requires a runtime SBOM tool which can detect which code is active. It can identify if the vulnerable library was loaded into memory, if the vulnerable function [.code-span]ReadHuffmanCodes[.code-span] was loaded into memory, and if that function was executed. One of the main goals of runtime SBOM is to reduce false positives and alerts, enabling you to focus on fixing only the most relevant vulnerabilities.
Using Kodem you can detect all your dependencies and know which service uses a vulnerable libwebp and whether it is loaded into memory and executed.

After detecting the vulnerable packages, we face the important question of how they should be fixed? Using Kodem’s runtime application context we can not only understand that we have a vulnerable package but also determine which resource is using it, and which command downloaded the library as part of the Docker build.

Kodem's Runtime-powered Application Security Platform Can Help
The Kodem platform is differentiated in the crowded landscape of application security because of its focus on runtime AI and streamlining remediation. Let us help you scan your infrastructure today to discover if you’re really affected by Libwebp vulnerabilities.
More blogs

Malicious Packages Alert: The Qix npm Supply-Chain Attack: Lessons for the Ecosystem
The npm ecosystem is in the middle of a major supply-chain compromise. The maintainer known as Qix is currently targeted in a phishing campaign that allows attackers to bypass two-factor authentication and take over their npm account. This is happening right now, and malicious versions of widely used libraries are being published and distributed.

Security Issues in popular AI Runtimes - Node.js, Deno, and Bun
Node.js, Deno, and Bun are the primary runtimes for executing JavaScript and TypeScript in modern applications. They form the backbone of AI backends, serverless deployments, and orchestration layers. Each runtime introduces distinct application security issues. For product security teams, understanding these runtime weaknesses is essential because attacks often bypass framework-level defenses and exploit the runtime directly.

Application Security Issues in AI Edge and Serverless Runtimes: AWS Lambda, Vercel Edge Functions, and Cloudflare Workers
AI workloads are increasingly deployed on serverless runtimes like AWS Lambda, Vercel Edge Functions, and Cloudflare Workers. These platforms reduce operational overhead but introduce new application-layer risks. Product security teams must recognize that serverless runtimes are not inherently safer—they simply shift the attack surface.
A Primer on Runtime Intelligence
See how Kodem's cutting-edge sensor technology revolutionizes application monitoring at the kernel level.
Platform Overview Video
Watch our short platform overview video to see how Kodem discovers real security risks in your code at runtime.
The State of the Application Security Workflow
This report aims to equip readers with actionable insights that can help future-proof their security programs. Kodem, the publisher of this report, purpose built a platform that bridges these gaps by unifying shift-left strategies with runtime monitoring and protection.
.png)
Get real-time insights across the full stack…code, containers, OS, and memory
Watch how Kodem’s runtime security platform detects and blocks attacks before they cause damage. No guesswork. Just precise, automated protection.

Stay up-to-date on Audit Nexus
A curated resource for the many updates to cybersecurity and AI risk regulations, frameworks, and standards.