Link Search Menu Expand Document

XML Entity Expansion in Java

Vulnerable example #1

class XXE {
  private static void receiveXMLStream(InputStream inStream, DefaultHandler defaultHandler)
      throws ParserConfigurationException, SAXException, IOException {
    SAXParserFactory factory = SAXParserFactory.newInstance();
    SAXParser saxParser = factory.newSAXParser();
    saxParser.parse(inStream, defaultHandler);
    // process xml data

  public static void main(String[] args) throws ParserConfigurationException, SAXException, IOException {
    try {
      receiveXMLStream(new FileInputStream("evil.xml"), new DefaultHandler());
    } catch ( mue) {
      System.err.println("Malformed URL Exception: " + mue);

This program is subject to an XML Entity Expansion attack if the evil.xml file contains the following:

<?xml version="1.0" ?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

After parsing, the evil.xml file will include the contents of the /etc/passwd file of the host where the application is running. The attack can be exploited to exfiltrate arbitrary files, mount server-side request forgery attacks (e.g. port scanning from the network perspective of the victim application) and perform denial of service.


Java applications using XML libraries are particularly vulnerable to XXE because the default settings for most Java XML parsers is to have XXE enabled. To use these parsers safely, you have to explicitly disable XXE in the parser you use. The following describes how to disable XXE in the most commonly used XML parsers for Java.

JAXP DocumentBuilderFactory, SAXParserFactory and DOM4J

DocumentBuilderFactory, SAXParserFactory and DOM4J XML Parsers can be configured using the same techniques to protect them against XXE. The JAXP DocumentBuilderFactory setFeature method allows a developer to control which implementation-specific XML processor features are enabled or disabled. The features can either be set on the factory or the underlying XMLReader setFeature method. Each XML processor implementation has its own features that govern how DTDs and external entities are processed. For a syntax highlighted example code snippet using SAXParserFactory, look here.

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
String FEATURE = null;
try {
    // This is the PRIMARY defense. If DTDs (doctypes) are disallowed, almost all 
    // XML entity attacks are prevented
    // Xerces 2 only -
    FEATURE = "";
    dbf.setFeature(FEATURE, true);

    // If you can't completely disable DTDs, then at least do the following:
    // Xerces 1 -
    // Xerces 2 -
    // JDK7+ -
    FEATURE = "";
    dbf.setFeature(FEATURE, false);

    // Xerces 1 -
    // Xerces 2 -
    // JDK7+ -
    FEATURE = "";
    dbf.setFeature(FEATURE, false);

    // Disable external DTDs as well
    FEATURE = "";
    dbf.setFeature(FEATURE, false);

    // and these as well, per Timothy Morgan's 2014 paper: "XML Schema, DTD, and Entity Attacks"

    // And, per Timothy Morgan: "If for some reason support for inline DOCTYPEs are a requirement, then
    // ensure the entity settings are disabled (as shown above) and beware that SSRF attacks
    // ( and denial
    // of service attacks (such as billion laughs or decompression bombs via "jar:") are a risk."

    // remaining parser logic
} catch (ParserConfigurationException e) {
    // This should catch a failed setFeature feature"ParserConfigurationException was thrown. The feature '" + FEATURE 
    + "' is probably not supported by your XML processor.");
} catch (SAXException e) {
    // On Apache, this should be thrown when disallowing DOCTYPE
    logger.warning("A DOCTYPE was passed into the XML document");
} catch (IOException e) {
    // XXE that points to a file that doesn't exist
    logger.error("IOException occurred, XXE may still possible: " + e.getMessage());

// Load XML file or stream using a XXE agnostic configured parser
DocumentBuilder safebuilder = dbf.newDocumentBuilder();

Xerces 1 Features:

Xerces 2 Features:

Note: The above defenses require Java 7 update 67, Java 8 update 20, or above, because the above countermeasures for DocumentBuilderFactory and SAXParserFactory are broken in earlier Java versions, per: CVE-2014-6517.

XMLInputFactory (a StAX parser)

StAX parsers such as XMLInputFactory allow various properties and features to be set. To protect a Java XMLInputFactory from XXE:

// This disables DTDs entirely for that factory
xmlInputFactory.setProperty(XMLInputFactory.SUPPORT_DTD, false); 
// disable external entities
xmlInputFactory.setProperty("", false);


To protect a javax.xml.transform.TransformerFactory from XXE:

TransformerFactory tf = TransformerFactory.newInstance();
tf.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "");
tf.setAttribute(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, "");


To protect a javax.xml.validation.Validator from XXE:

SchemaFactory factory = SchemaFactory.newInstance("");
Schema schema = factory.newSchema();
Validator validator = schema.newValidator();
validator.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, "");
validator.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");


To protect a javax.xml.validation.SchemaFactory from XXE:

SchemaFactory factory = SchemaFactory.newInstance("");
factory.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, "");
factory.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");
Schema schema = factory.newSchema(Source);


To protect a javax.xml.transform.sax.SAXTransformerFactory from XXE:

SAXTransformerFactory sf = SAXTransformerFactory.newInstance();
sf.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "");
sf.setAttribute(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, "");

Note: Use of the following XMLConstants requires JAXP 1.5, which was added to Java in 7u40 and Java 8:

  • javax.xml.XMLConstants.ACCESS_EXTERNAL_DTD
  • javax.xml.XMLConstants.ACCESS_EXTERNAL_SCHEMA


To protect a Java org.xml.sax.XMLReader from XXE:

XMLReader reader = XMLReaderFactory.createXMLReader();
reader.setFeature("", true);
// This may not be strictly required as DTDs shouldn't be allowed at all, per previous line.
reader.setFeature("", false); 
reader.setFeature("", false);
reader.setFeature("", false);


To protect a Java from XXE:

saxReader.setFeature("", true);
saxReader.setFeature("", false);
saxReader.setFeature("", false);

Based on testing, if you are missing one of these, you can still be vulnerable to an XXE attack.


To protect a Java org.jdom2.input.SAXBuilder from XXE:

SAXBuilder builder = new SAXBuilder();
builder.setFeature("", false);
builder.setFeature("", false);
Document doc = File(fileName));

No-op EntityResolver

For APIs that take an EntityResolver, you can neutralize an XML parser’s ability to resolve entities by supplying a no-op implementation:

public final class NoOpEntityResolver implements EntityResolver {
    public InputSource resolveEntity(String publicId, String systemId) {
        return new InputSource(new StringReader(""));

xmlReader.setEntityResolver(new NoOpEntityResolver());
documentBuilder.setEntityResolver(new NoOpEntityResolver());

JAXB Unmarshaller

Since a javax.xml.bind.Unmarshaller parses XML and does not support any flags for disabling XXE, it is imperative to parse the untrusted XML through a configurable secure parser first, generate a source object as a result, and pass the source object to the Unmarshaller. For example:

//Disable XXE
SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setFeature("", false);
spf.setFeature("", false);
spf.setFeature("", false);

//Do unmarshall operation
Source xmlSource = new SAXSource(spf.newSAXParser().getXMLReader(), 
                                new InputSource(new StringReader(xml)));
JAXBContext jc = JAXBContext.newInstance(Object.class);
Unmarshaller um = jc.createUnmarshaller();


A javax.xml.xpath.XPathExpression is similar to an Unmarshaller, wherein it can’t be configured securely by itself, so the untrusted data must be parsed through another securable XML parser first. For example:

DocumentBuilderFactory df = DocumentBuilderFactory.newInstance();
df.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "");
df.setAttribute(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");
DocumentBuilder builder = df.newDocumentBuilder();
String result = new XPathExpression().evaluate( builder.parse(
                            new ByteArrayInputStream(xml.getBytes())) );


The readObject() method in this class is fundamentally unsafe. Not only is the XML it parses subject to XXE, but the method can be used to construct any Java object, and execute arbitrary code as described here. Importantly, there is no way to make safe use of this class except to trust or properly validate the input being passed into it. As such, we strongly recommend completely avoiding the use of this class and replacing it with a safe or properly configured XML parser as described elsewhere in this cheat sheet.

Other XML Parsers

There are many 3rd party libraries that parse XML either directly or through their use of other libraries. Please test and verify that their XML parser is secure against XXE by default. If the parser is not secure by default, look for flags supported by the parser to disable all possible external resource inclusions like the examples given above. If there is no control exposed to the outside, make sure the untrusted content is passed through a secure parser first and then passed to insecure 3rd party parser similar to how the Unmarshaller is secured.

Spring Framework MVC/OXM XXE Vulnerabilities

For example, some XXE vulnerabilities were found in Spring OXM and Spring MVC. The following versions of the Spring Framework are vulnerable to XXE:

  • 3.0.0 to 3.2.3 (Spring OXM & Spring MVC)
  • 4.0.0.M1 (Spring OXM)
  • 4.0.0.M1-4.0.0.M2 (Spring MVC)

There were other issues as well that were fixed later, so to fully address these issues, Spring recommends you upgrade to Spring Framework 3.2.8+ or 4.0.2+. For Spring OXM, this is referring to the use of org.springframework.oxm.jaxb.Jaxb2Marshaller. Note that the CVE for Spring OXM specifically indicates that 2 XML parsing situations are up to the developer to get right, and 2 are the responsibility of Spring and were fixed to address this CVE. Here’s what they say: Two situations developers must handle:

  • For a DOMSource, the XML has already been parsed by user code, and that code is responsible for protecting against XXE.
  • For a StAXSource, the XMLStreamReader has already been created by user code, and that code is responsible for protecting against XXE.

The issue Spring fixed: For SAXSource and StreamSource instances, Spring processed external entities by default, thereby creating this vulnerability. Here’s an example of using a StreamSource that was vulnerable, but is now safe, if you are using a fixed version of Spring OXM or Spring MVC:

import org.springframework.oxm.Jaxb2Marshaller;
import org.springframework.oxm.jaxb.Jaxb2Marshaller;

Jaxb2Marshaller marshaller = new Jaxb2Marshaller();
// Must cast return Object to whatever type you are unmarshalling
marshaller.unmarshal(new StreamSource(new StringReader(some_string_containing_XML));

So, per the Spring OXM CVE writeup, the above is now safe. But if you were to use a DOMSource or StAXSource instead, it would be up to you to configure those sources to be safe from XXE.


OWASP - XML External Entity (XXE) Processing OWASP - XML External Entity Prevention Cheat Sheet CMU - IDS17-J. Prevent XML External Entity Attacks