Recently, a critical vulnerability (CVE-2022-44729) came to light in the Apache XML Graphics Batik library. This security issue can be exploited to perform Server-Side Request Forgery (SSRF) if you are using vulnerable versions. In this blog post, I’ll explain what happened, show you how the exploit works, and provide guidance on how to stay secure.

What is Apache Batik?

Apache Batik is a popular Java library for reading, manipulating, and converting SVG (Scalable Vector Graphics) files. It's commonly used in server software and desktop applications that need to generate images on-the-fly or analyze vector graphics.

Official Description

The official advisory (NVD, Apache Security Advisory)) summarizes it as:

> A Server-Side Request Forgery (SSRF) vulnerability exists in Apache XML Graphics Batik version 1.16 and below. By crafting a malicious SVG file, a remote attacker can potentially force the server to load external resources. This can lead to resource exhaustion or leakage of internal system information.

What is SSRF?

Server-Side Request Forgery is a class of vulnerability where an attacker tricks your server into making HTTP, FTP, or other network requests on their behalf. This can let attackers access internal systems, steal administrative data, or abuse your server for resource-intensive tasks.

How Does This Play Out in Batik?

Batik, when processing SVGs, follows external references (like images, scripts, or fonts) inside those files. Normally, you wouldn't want to let strangers upload random SVGs to your site because of the risk of malicious content. In version 1.16 and below, Batik does not restrict external resource loading, making it possible for an attacker to embed sensitive or dangerous requests inside their SVG files.

Let's say you run a Java web service that lets users upload SVGs for image conversion or viewing

import org.apache.batik.transcoder.TranscoderInput;
import org.apache.batik.transcoder.TranscoderOutput;
import org.apache.batik.transcoder.image.PNGTranscoder;

// ... inside file upload handler ...
PNGTranscoder transcoder = new PNGTranscoder();
TranscoderInput input = new TranscoderInput(svgInputStream);
TranscoderOutput output = new TranscoderOutput(pngOutputStream);
transcoder.transcode(input, output);

If an attacker uploads the following SVG

<svg xmlns="http://www.w3.org/200/svg"; width="100" height="100">
  <image xlink:href="http://localhost:808/internal-admin"; x="10" y="10" height="80" width="80"/>
</svg>

Batik will, by default on version 1.16, try to load the image from http://localhost:808/internal-admin. If your application is running on a server that has private admin interfaces, this SSRF can let an attacker indirectly probe or even extract information from those endpoints.

Other Examples

Attackers may also try to load arbitrary external URLs, causing your server to download large files, or even connect to internal cloud metadata URLs such as http://169.254.169.254/latest/meta-data/ in AWS environments.

Proof-of-Concept Code

Here is how an attacker might send a malicious SVG and probe your internal metadata (for environments like AWS):

<svg xmlns="http://www.w3.org/200/svg";>
  <image xlink:href="http://169.254.169.254/latest/meta-data/iam/security-credentials/" x="" y="" height="10" width="10"/>
</svg>

If your server is running Batik 1.16, it will silently send a GET request to the internal cloud metadata URL.

Information Disclosure: Attackers can access internal URLs, leak sensitive server data.

- Resource Exhaustion: Repeated large requests can exhaust server resources (such as bandwidth or memory).
- Potential RCE/Privilege Escalation: If internal endpoints allow side effects, there is the potential for further compromise.

Mitigation and Fix

- Upgrade Now! The Batik team released version 1.17 to close this vulnerability. In version 1.17 and above, external resource loading can be restricted or disabled by default.

Validate Input: Reject or sanitize any SVG files you receive from untrusted sources.

- Configure Batik: Use Batik’s security options to block remote resources if you absolutely must process user SVGs.

Upgrading Example in Maven

<dependency>
  <groupId>org.apache.xmlgraphics</groupId>
  <artifactId>batik-transcoder</artifactId>
  <version>1.17</version>
</dependency>

References

- Apache Security Advisory)
- NIST NVD Entry
- Batik Project News
- OWASP SSRF Guide

Conclusion

If you use Apache XML Graphics Batik (1.16 or below), upgrade now to 1.17 or later! SSRF is a real threat that could let attackers reach internal network services from the outside just by uploading a malicious SVG file. Stay safe—always use the latest versions and filter user-submitted content!

If you found this article helpful, share it with your team and check your own applications for risky dependencies. Responsible use of graphics libraries protects both your users and your infrastructure.

Timeline

Published on: 08/22/2023 19:16:00 UTC
Last modified on: 10/30/2023 02:17:00 UTC