CVE-2026-29074

What it actually does

The vulnerability allows for a denial of service attack. A vulnerable version of the SVGO library fails to properly handle XML files with custom entities. An attacker can submit a small, specially crafted SVG file containing recursive or heavily nested XML entities (a type of XML bomb or "Billion Laughs" attack). When the library parses this file, it enters a loop of entity expansion that rapidly consumes system memory, leading to the exhaustion of the JavaScript heap and causing the Node.js process to crash.

Why it matters to the business

Exploitation of this vulnerability will cause any application or service using the vulnerable library for SVG processing to become unavailable. This can lead to service outages, disruption of features like image uploads or asset processing, and a degraded user experience. If the affected service is part of a critical workflow, it could halt business operations until the service is manually restarted. Repeated attacks can lead to prolonged and frustrating service instability.

How an attack unfolds

An unauthenticated remote attacker crafts a malicious SVG file. This file is technically a valid XML file but contains a payload with nested or recursive entity definitions. The attacker then uploads this file to a web application or service that uses a vulnerable version of the SVGO library to optimize or process SVG images. When the backend service receives the file and passes it to SVGO, the library attempts to parse the XML and resolve the entities. This triggers an exponential expansion that consumes all available memory, causing the Node.js process to run out of memory and crash, resulting in a denial of service.

How to fix it

To remediate this vulnerability, update the SVGO library to a patched version. Depending on the version branch your project uses, upgrade to one of the following versions or later: - If using the 2.x branch, upgrade to version 2.8.1. - If using the 3.x branch, upgrade to version 3.3.3. - If using the 4.x branch, upgrade to version 4.0.1. Update your project's `package.json` to specify the fixed version and run your package manager's install command (e.g., `npm install` or `yarn install`) to apply the update. Ensure your lockfile (`package-lock.json` or `yarn.lock`) reflects the updated version.

How to confirm the fix worked

To validate the fix, use a software composition analysis (SCA) tool or manually inspect your project's dependency tree to confirm that the installed version of the `svgo` package is 2.8.1, 3.3.3, 4.0.1, or a higher version within the respective major release branch. Check the `package-lock.json` or `yarn.lock` file to ensure the resolved version is no longer in the vulnerable range.

Typical attack path

1. The attacker identifies an application that accepts SVG file uploads and uses the SVGO library for processing.
2. The attacker crafts a malicious SVG file containing a recursive or deeply nested XML entity expansion payload.
3. The attacker submits the malicious file to the target application, for example, through a file upload form.
4. The application's backend attempts to process the uploaded file using the vulnerable SVGO library.
5. The SVGO library's XML parser begins to expand the entities, consuming excessive memory and CPU.
6. The Node.js process crashes due to memory exhaustion, causing a denial of service for the application.

How to detect it

To detect potential exploitation, monitor application logs for Node.js services that process SVG files. Look for an increase in crashes, unexpected restarts, or specific error messages like "JavaScript heap out of memory". Correlate these events with file upload activities. Forensically, you can search file systems for stored SVG files that contain suspicious XML DTDs or entity definitions (e.g., `<!ENTITY ...>`), which are not typical for standard SVG files and may indicate an attack attempt.

• log:JavaScript heap out of memory
• file_content:<!ENTITY
• file_content:&lol;

What your security team should do

• Use a Software Composition Analysis (SCA) tool to identify all instances of the `svgo` library across your codebase and determine if they are vulnerable.
• Prioritize patching for public-facing applications that allow users to upload or control SVG content, as these are the most direct attack vectors.
• Coordinate with development teams to upgrade `svgo` to the appropriate patched version (2.8.1, 3.3.3, or 4.0.1) or newer.
• Consider implementing resource limits and automated restarts for services that process external files to mitigate the impact of potential zero-day resource exhaustion vulnerabilities.