XXE Vulnerability

XML is a markup language — a kind of structured text format — that software uses to exchange and store data. Within XML there is a feature called “External Entity”: at a given point in an XML file, you can define a placeholder that points to another file or a web address. The XML parser — the program that reads and processes the XML file — then fetches this content and inserts it. If the parser is poorly configured, an attacker can abuse this behavior. They send a manipulated XML file that doesn’t point to harmless content, but to sensitive system files. This is exactly what is called an XXE vulnerability — short for “XML External Entity”.

What’s at stake

A successful XXE attack can hand attackers the contents of arbitrary files on the server. On a Linux server, for instance, the file /etc/passwd contains a list of all user accounts on the system. Via an XXE flaw, it can be read out with a single manipulated request, without the attacker knowing a password or logging in anywhere.

It becomes especially dangerous when the server has internal access to other systems that are actually shielded from the outside world. The attacker then uses the vulnerable server as a springboard to query internal services — an attack known as “Server-Side Request Forgery.” This expands an XXE flaw from a simple file leak into an entry point into the entire network.

How the attack plays out in practice

Many web applications accept XML data from users — for example, when uploading a file or sending a request in a particular format. An attacker constructs an XML file with a manipulated placeholder. Simplified, it looks like this: they define an entity named “secret” that points to the file /etc/passwd, and then output this entity somewhere in the XML document. If they send this file to the server, the parser dutifully reads the referenced system file and returns its contents in the response — because nobody told it not to.

The underlying problem is that the external entity feature is almost never needed in modern applications, but is enabled by default in many parsers. Defending against it is therefore relatively simple: you disable the feature in the parser. Nevertheless, the flaw keeps showing up again and again, because developers use external libraries to process XML without questioning their default settings.

An additional safeguard is input validation: the application checks incoming XML files against a fixed schema and rejects anything that doesn’t match that schema. This way, a manipulated entity never even reaches the parser.

XXE in security lists and real-world attacks

The non-profit organization OWASP — which regularly publishes a list of the most dangerous web security vulnerabilities — long listed XXE as its own separate entry in its “Top 10.” Since 2021, it has been folded into the category “Security Misconfiguration,” because the root cause is almost always a misconfigured library. Being on the list means: attackers are well aware of this attack path, and it is being actively exploited.

Real-world cases have occurred on a large scale. In 2018, the US ride-hailing company Uber reported a vulnerability of this kind in one of its systems. Similar flaws have been found in well-known enterprise software packages and cloud services. Enterprise applications in particular often communicate internally via XML interfaces — an environment in which poorly configured parsers are especially easy to overlook.

In security competitions, so-called “Capture the Flag” challenges, XXE is one of the standard tasks. Anyone learning IT security therefore encounters this flaw early on. This mirrors real-world practice: the attack path is well known, well documented, and yet still repeatedly found out in the wild.