XML External Entity (XXE) Attacks Explained for Site Owners

Short answer: An XML external entity (XXE) attack abuses a feature of XML that lets a document pull in content from a file or a web address. If a website parses XML from an untrusted source with that feature switched on, an attacker can make the server read local files, call internal services or run out of memory. The fix is simple for developers: turn off DTD processing and external entity loading in the XML parser, and keep libraries up to date.

What XML entities are

XML is a text format for structured data. It is used in feeds, sitemaps, office documents, SVG images, payment and shipping integrations and many older APIs. To keep documents short, XML lets you define an entity: a named placeholder that the parser replaces with some content. A document might define a company name once and then use the short placeholder everywhere.

Entities are declared in an optional block at the top of the document called a document type definition, or DTD. Most entities are harmless text. The risky kind is the external entity, which does not contain the text itself but points to somewhere else: a file path on the server or a URL. When the parser meets it, it can fetch that resource and place the content into the document, as if it had been typed there.

This was designed for convenience in the early days of XML, and nearly every application that reads XML today never needs it. That gap between a rarely used feature and a default setting in some parsers is what attackers exploit.

How an XXE attack works

An XXE attack needs three things: a place where the website accepts XML, a parser that processes external entities, and a way for the result to reach the attacker. The attacker sends a crafted document that declares an external entity pointing at a sensitive target, then refers to that entity in a field the application will show or store.

When the server parses the document, the parser quietly loads the target and substitutes it into the field. If the application echoes that field in a response, an error message or a saved record, the attacker reads the content of the file. The application does nothing wrong in its own code. It simply trusts the parser to behave safely.

There is also a “blind” version. The application never shows the result, but the attacker makes the parser send a request to a server the attacker controls, or triggers errors that leak information. Blind attacks are slower and noisier, yet they work against many systems that look safe at first glance.

What an attacker can do with it

The impact depends on the server and on what the parser is allowed to reach. Typical outcomes include:

Reading local files. Configuration files, application source code and system files that the web server account can read. Files that contain database credentials or secret keys are the most valuable.
Server-side request forgery. The parser can be told to request internal addresses that the outside world cannot reach, such as admin panels, internal APIs or cloud metadata services. Our article on server-side request forgery explains why that is so serious.
Denial of service. A tiny document can define entities that expand into enormous amounts of text, often called a “billion laughs” attack. The server spends all its memory and CPU on one request.
Port scanning and data leaks. Response times and error messages can reveal which internal hosts and ports exist.

In some environments an XXE flaw is the first step in a longer chain. A stolen credential file leads to database access, and database access leads to a full site takeover.

Where XXE hides on a website

Most website owners never write XML by hand, but plenty of features parse it on their behalf. Look for places where outside parties can send or upload XML-based content:

Old SOAP or XML-RPC style endpoints. Services that accept XML requests are the classic target.
File uploads. Several file types are XML inside. SVG images, and Word, Excel and PowerPoint files are zipped bundles of XML files. A feature that reads or converts them runs an XML parser.
Import tools. Product, order or contact imports that accept XML or spreadsheet formats.
Feed and sitemap readers. Plugins that fetch and parse RSS, Atom or sitemap files from other websites.
Payment, shipping and marketplace callbacks. Some providers still send XML notifications to a URL on your site.
Single sign-on. SAML messages are XML, and a weak SAML library is a well-known place for XML parsing flaws.

Content that you wrote yourself and that never leaves your server is not a risk. The danger starts when the document comes from a visitor, a customer, a partner or another website.

Why WordPress and PHP sites should care

Modern PHP builds and current versions of the underlying libxml library do not load external entities by default, which has removed many older XXE problems. That is good news, but it is not a guarantee. A developer can switch the dangerous behaviour back on, for example with a parser option that substitutes entities, and older servers may still run outdated software.

The bigger risk on WordPress usually comes from plugins and themes. Each one brings its own code and sometimes its own XML libraries. An abandoned plugin that parses uploaded files may contain a flaw that was fixed years ago in a newer library. Our guide on abandoned WordPress plugins describes how to spot that situation. If your site accepts SVG uploads from users, make sure they are sanitised or restricted to trusted roles.

How developers prevent XXE

Prevention is mostly a matter of configuration. The principle is to treat every XML document from outside as hostile and to remove the features it could abuse.

Disable DTDs completely when the application does not need them. This blocks both external entities and the entity expansion tricks.
Disable external entity and external schema loading in every XML parser the application uses, not only the main one.
Never enable entity substitution on parsed untrusted input. Read the documentation for any parser flag before using it.
Prefer simpler formats. If you control the interface, JSON removes this whole class of problem. Use XML only when a partner requires it.
Validate and limit input. Restrict file size, reject documents that contain a DTD and apply timeouts and memory limits.
Keep libraries and plugins updated. Many XXE fixes arrive as ordinary version updates.
Limit what the server can reach. Run the web server with the lowest file permissions and block outgoing requests to internal addresses, so that a flaw has less to steal.

The same defence-in-depth thinking applies to other input-based attacks. We cover related risks in the articles on SQL injection and file permissions on a web server.

How to check whether you are exposed

If you have a developer, ask three direct questions: which parts of the site parse XML, which parser and options do they use, and where do the documents come from? A good answer names the endpoints and confirms that DTD processing is off.

If you do not have a developer, make a short inventory yourself. List the plugins that import data, convert files, read feeds or connect to payment, shipping and login providers. Check each one for recent updates and remove anything abandoned. Then use a vulnerability scanner or ask your host to run a security scan, because XXE is hard to find by eye. Do not test other people’s websites without written permission.

Logs can help too. Unusual XML requests to endpoints that normally receive few visitors, unexpected outgoing connections from the server and spikes in memory use after a request are all warning signs.

What Site AI Audit can and cannot tell you

Site AI Audit looks at your website from the outside. It checks the SSL certificate and its expiry, the redirect from HTTP to HTTPS, security headers and exposed software versions. It does not send crafted XML documents to your forms or upload endpoints, so it cannot prove or rule out an XXE flaw. What it can do is show whether your public setup follows the basics, and exposed software versions can tell you which components deserve an update first. You can run a free check of your website or see the plans.

The bottom line

XXE is an old but still relevant flaw that appears when an application parses XML from outsiders with risky options turned on. The attacker needs no password, only a place that accepts XML. Know where your site handles XML, switch off DTDs and external entities, keep plugins and libraries current and prefer simpler data formats where you can.

الأسئلة الشائعة

Is XXE still a real problem today?

Yes, although it is less common than it used to be. Newer parsers disable external entities by default, but older software, custom parser options and third-party plugins can still be vulnerable. It remains worth checking wherever a site accepts XML or XML-based files.

Can an SVG upload cause an XXE attack?

It can. An SVG file is XML, so a feature that parses or converts uploaded SVG files runs an XML parser. If that parser processes external entities, a crafted file may read local files or trigger requests. Restrict who can upload SVG files and sanitise them.

Does my site need XML at all?

Many sites use it without the owner knowing, through sitemaps, feeds, imports and plugin integrations. Reading XML is not a problem by itself. The risk comes from parsing untrusted XML with external entities and DTD processing enabled.

How is XXE different from SQL injection?

SQL injection tricks the database by inserting commands into a query. XXE tricks an XML parser by inserting a reference that makes it load files or addresses. Both come from trusting input too much, but they target different components and need different fixes.

What is the single most important fix?

Disable DTD processing and external entity loading in every XML parser the application uses. Then keep the software updated. Together these two steps close the large majority of XXE problems.