What Is XXE?

XXE stands for XML External Entity. It is a security vulnerability that happens when an application parses XML input in a way that allows external entities to be processed, which can let an attacker read local files, make server-side requests, or consume system resources. In practice, XXE is usually a parser configuration problem combined with untrusted XML input.

How XXE works

To understand XXE, the main concept is simple: some XML parsers can process special instructions inside XML documents. If those features are enabled and the application accepts attacker-controlled XML, the attacker may be able to make the parser pull in data from places it should not.

In a safe design, the parser ignores or blocks those features unless they are explicitly required. In an unsafe design, the parser trusts them and processes them.

The basic attack path

A typical XXE scenario looks like this:

1. The application accepts XML input
2. The XML parser processes external entities
3. The attacker includes a crafted XML payload
4. The parser resolves the entity
5. The application exposes the result or behaves unexpectedly

The vulnerable feature is usually not visible to the end user. It may sit behind an API, file upload workflow, document import function, SOAP service, SSO component, or back-end integration.

What an attacker may do with XXE

Depending on the parser behavior and surrounding application logic, XXE can lead to several outcomes.

Read local files

One of the classic XXE impacts is local file disclosure. If the parser can access the file system, the attacker may cause the application to load local files and return their contents in the response or error output.

Examples of target files may include:

• Configuration files
• Environment variables
• Application secrets
• Service credentials
• System files useful for reconnaissance

Trigger server-side requests

XXE can sometimes be used to make the vulnerable server send requests to internal or external systems. That makes it relevant to server-side request forgery (SSRF)-style behavior, especially in environments where internal services are reachable from the application host.

This matters because the attacker may gain visibility into:

• Internal APIs
• Cloud metadata services
• Private admin interfaces
• Services not directly exposed to the internet

If you want a deeper comparison, see what is ssrf.

Cause denial of service

Some XXE payloads are designed to consume memory or CPU by forcing the parser into expensive processing. That can degrade performance or cause application instability.

Support broader compromise

XXE is often not the final objective. It can become a stepping stone to later actions, such as harvesting secrets, understanding internal architecture, or finding credentials that help with lateral movement.

Where XXE tends to appear

XXE is most likely to show up in systems that still process XML as part of normal business logic. Common examples include:

• Legacy web applications
• Enterprise integrations
• SOAP-based APIs
• SAML-related workflows
• Office or document import features
• File upload and parsing services
• Back-end middleware that transforms XML data

It is less about whether the front-end looks modern and more about whether XML parsing exists anywhere in the request path.

Why XXE happens

In most cases, XXE exists because of one or more of these conditions:

• The application accepts XML from untrusted sources
• The XML parser uses insecure default behavior
• External entity resolution is enabled when not needed
• Developers are unaware that the parser supports risky features
• Legacy code was never hardened
• Security testing focused on common web flaws but missed parser-level issues

Many teams do not realize they are processing XML until a specific integration, import function, or middleware component is reviewed closely.

When you’ll encounter XXE

You will usually encounter XXE in application security assessments, secure coding reviews, or penetration testing of enterprise systems.

During web and API testing

If an application or API endpoint accepts XML, testers will often check whether the parser handles external entities safely. This is especially relevant for older APIs or services built around XML rather than JSON.

In legacy enterprise environments

XXE appears more often in older business applications, middleware, and integration platforms that rely on XML-heavy workflows. Environments with SOAP, SAML, or custom XML formats are common places to look.

During code review or secure development work

Developers may encounter XXE when reviewing parser libraries, framework defaults, or XML processing features. In many cases, remediation is a matter of secure parser configuration and ensuring unnecessary XML capabilities are turned off.

In cloud and internal network exposure discussions

Because XXE can sometimes trigger server-side requests, it comes up in conversations about internal service exposure, metadata access, and trust boundaries between application tiers.

For related background on application-layer flaws, read what is sql injection.

How organizations reduce the risk

The defensive guidance is well established:

• Disable external entity resolution unless it is absolutely required
• Disable support for unsafe document type declarations where possible
• Use secure parser settings and hardened libraries
• Validate and constrain XML input
• Prefer simpler formats like JSON if XML is not necessary
• Test any feature that accepts XML, not just public web forms
• Review legacy integrations and middleware for insecure defaults

The important point is that XXE is usually preventable through parser hardening and design choices.

Tools that can support safer development workflows

XXE is primarily a secure coding and configuration issue, not something a consumer security product directly fixes. Still, adjacent tools can support safer operations. For example, teams storing service credentials, admin accounts, or shared development secrets may benefit from a password manager like 1Password to reduce unsafe secret handling. On developer or test endpoints, endpoint protection such as Malwarebytes may also help detect malicious follow-on payloads if a broader compromise occurs.

These tools do not replace secure XML parser configuration, but they can support the broader security posture around development and administration.

Bottom line

XXE is a vulnerability caused by unsafe XML parsing. If an application accepts XML and resolves external entities, an attacker may be able to read files, trigger server-side requests, or disrupt service behavior. For defenders, the priority is straightforward: know where XML is used, harden the parser, and disable risky features that the application does not truly need.