Last month, two Critical vulnerabilities (CVE-2023-4863 and CVE-2023-5129) 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.

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:

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 and Snyk Open Source are able to detect the relevant packages, and you can use Snyk right now for free to determine which of your projects incorporate them.

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: 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: 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. In this post, we'll explore these remediation recommendations:

1. Identify where you use libwebp
2. Upgrade to libwebp 1.3.2 or higher
3. Monitor projects using auto-PR support

1. Identify where you use libwebp

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, 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, and the widely used FFmpeg utility also makes use of the libwebp library.

Detecting the libwebp vulnerability with Snyk

There are various ways to detect the libwebp vulnerability — for free — using Snyk. Using the 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, providing you with a report of all the direct and transitive dependencies you are using. From this report, 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. 

2a. Upgrade to libwebp 1.3.2 or higher (open source)

• 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

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 (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.