How to find and fix Critical WebP zero-day vulnerability CVE-2023-4863
Tags: vulnerabilityinsights
Published: 2023-10-06 02:00:18

Last month, two Critical vulnerabilities ([CVE-2023-4863](https://security.snyk.io/vuln/SNYK-UNMANAGED-CHROMIUM-5892808) and [CVE-2023-5129](https://security.snyk.io/vuln/SNYK-UNMANAGED-WEBMPROJECTLIBWEBP-5918283)) were identified by Apple Security Engineering and Architecture (SEA) in collaboration with The Citizen Lab at the University of Toronto’s Munk School. The vulnerabilities involved maliciously formed WebP images that would exploit Chromium-based browsers and the `webmproject/libwebp` library provided by Google. You can learn more about the vulnerability and the recent history of it in our [previous blog post](/blog/critical-webp-0-day-cve-2023-4863/). 


In particular, the `libwebp` vulnerability extends beyond just browsers and affects developer ecosystems, operating systems, and containers. Here are all of the different ecosystems and containers that we have found to be impacted by `libwebp`:


![](https://res.cloudinary.com/snyk/image/upload/v1696529494/blog-webp-fix-chart.jpg)
Demonstrating the breadth of the impact of this vulnerability, you can see it’s detected in various developer ecosystems as both a direct and transitive dependency. It’s primarily found as a transitive dependency in Cocoapods, Swift, and Python projects which can make it more difficult for developers to be aware of the impact. However, both [Snyk Container](/product/container-vulnerability-management/) and [Snyk Open Source](/product/open-source-security-management/) are able to detect the relevant packages, and you can [use Snyk right now for free](https://app.snyk.io) to determine which of your projects incorporate them.


![](https://res.cloudinary.com/snyk/image/upload/v1696529493/blog-webp-fix-deps.jpg)
While we’ve done a comprehensive analysis of the impact of `libwebp`, security experts are still researching the different uses of `libwebp` across applications, ecosystems, and operating systems. Since the vulnerability impacts software components that make use of .webp image codecs and render its content (such as browsers, design tools, etc.), the scope will continue to increase. Therefore, it’s crucial to keep up to date on the latest news regarding `libwebp`.


The focus of this blog post is to provide a better understanding of the impact this vulnerability has on software ecosystems and act as a quick reference to address it.


As of Oct. 3, 2023, the CVEs known to actively track this `libwebp` vulnerability include:


* [CVE-2023-4863](https://security.snyk.io/vuln/SNYK-UNMANAGED-CHROMIUM-5892808): Opened Sept. 11, 2023 with a CVSS score of `9.6`; EPSS score 31.86% (97th percentile). **Note:** This CVE was originally scored `8.8` (“High”) before further details were disclosed.
* [CVE-2023-5129](https://security.snyk.io/vuln/SNYK-UNMANAGED-WEBMPROJECTLIBWEBP-5918283): Opened Sept. 25, 2023 with a CVSS score of `10` (the maximum possible) and was later rejected on Sept. 27, 2023 by Google, the assigned CVE Numbering Authority, as a duplicate;


You can learn more about the vulnerability and the recent history of it in our [previous blog post](/blog/critical-webp-0-day-cve-2023-4863/). In this post, we'll explore these remediation recommendations:


1. [Identify](#identify) where you use `libwebp`
2. [Upgrade](#upgrade) to `libwebp` 1.3.2 or higher
3. [Monitor](#monitor) projects using auto-PR support


[1. Identify where you use libwebp](anchor:identify)
----------------------------------------------------


The most challenging part of addressing a zero-day vulnerability is determining if and where you are impacted by it. In the case of `libwebp`, it is no different. `libwebp` can be found as a dependency within your project either [directly or indirectly as a transitive dependency](/series/open-source-security/software-dependencies/), making identification critical so that you can properly address the issue as it’s highly likely you are impacted to some degree without knowing it. Some areas of impact include: 


* Any software you’re building that either depends directly on the `libwebp` library or indirectly via transitive dependencies is impacted by the vulnerability.
* Any software you use that’s responsible for encoding and/or decoding .webp images is impacted by the vulnerability.
* Any operating systems or container images that bundle tooling for handling .webp images is impacted by the vulnerability.


A contributing factor to how widespread this vulnerability impacts the developer ecosystems is that higher-level programming languages use the underlying `libwebp` library. As an example, the GoDot Game Engine used for creating 2D and 3D games [depends on the libwebp library](https://github.com/godotengine/godot/commit/2529ad6a6427a27f47c1ef8ce2aac608f6c20ed8), and the widely used FFmpeg utility also makes use of the [libwebp library](https://github.com/FFmpeg/FFmpeg/blob/7f685d0f493bbfa44cf1b3b65f9347291e23872b/doc/encoders.texi#L2316).


### Detecting the libwebp vulnerability with Snyk


There are various ways to detect the `libwebp` vulnerability — [for free](https://app.snyk.io) — using Snyk. Using the [Snyk CLI](/platform/snyk-cli/), you can test your projects locally:


* For applications, run `snyk test --unmanaged` from the Snyk CLI to compare unmanaged dependencies in your repository to detect individual packages and their vulnerabilities.
* For containers, run `snyk container test` to detect operating system packages that depend on vulnerable versions of `libwebp`.


You can also run a [scan across all your projects in your Git repositories](/platform/git-repository-security/), providing you with a report of all the direct and transitive dependencies you are using. From this [report](https://docs.snyk.io/manage-risk/reporting), you'll see if you're relying on `libwebp`, and how many paths in your dependency graph it's being used in. You can also run a quick search for "CVE-2023-4863" across all the projects. 


![](https://res.cloudinary.com/snyk/image/upload/v1696529494/blog-webp-fix-report.jpg)
[2a. Upgrade to libwebp 1.3.2 or higher (open source)](anchor:upgrade)
----------------------------------------------------------------------


* **Automatic fix:** Connect Snyk to your Git repositories so it can raise pull requests to update your dependency graph where possible. Then rebuild your application.
* **Manual fix:** If you are using `libwebp` as a direct dependency in your application, you can upgrade your dependency file directly to `1.3.2` or higher. Then rebuild your application.
* **Manual fix:** If you are using `libwebp` as a transitive dependency in your application, identify a version of your direct dependency that pulls in the transitive `libwebp` dependency at `1.3.2` or higher. Then rebuild your application.


2b. Upgrade to libwebp 1.3.2 or higher (container)
--------------------------------------------------


* **Automatic fix:** Connect Snyk to your Git repositories so it can raise pull requests to update your Dockerfile base image where possible. Preview if the suggested base image upgrade still carries the vulnerability by using `https://snyk.io/test/docker/` , then rebuild your container once you have identified an acceptable upgrade path.
* **Manual fix:** If you are using `libwebp` as a direct or transitive dependency in your container, you can upgrade your dockerfile directly to the patched version by adding a `RUN` layer in your Dockerfile. Example: Use the Snyk issue recommendation for `node@18.13.0 › libwebp/libwebp6@0.6.1-2.1` and add:
`RUN npm install libwebp/libwebp6@0.6.1-2.1+deb11u2`
to the Dockerfile and rebuild your container.


[3. Monitor projects using auto-PR support](anchor:monitor)
-----------------------------------------------------------


Due to the nature of this as a zero-day vulnerability, the impacts are being discovered daily and therefore it’s important to actively monitor your projects on a regular basis for new recommendations to remediate the issue. If you’re using Snyk, be sure to [keep your projects monitored](https://docs.snyk.io/features/snyk-cli/secure-your-projects-in-the-long-term/monitor-your-projects-at-regular-intervals) (enabled by default when importing a repo into the Snyk app). This means Snyk will automatically test projects daily, in addition to the other tests carried out when you make updates.


These daily tests will automatically identify when security improvements can be made, including where new fixes can be applied. For example, if you’re using `libwebp` as a transitive dependency of `package A`, you need `package A` to release a version that uses `libwebp` at version `1.3.2` or higher. This might not be available today, but it might be released tomorrow or next week. Using `snyk monitor` will test daily for you and send you a PR when the new upgrade becomes available which will upgrade the version of `libwebp` to remediate the vulnerability.


It’s also important to note that Snyk will alert you, via PRs or other mechanisms, if further fixes are made under this vulnerability or if future attack vectors are found that surface new vulns. This helps make sure that you’re the first to know what you need to do if further issues arise.