Breaking the Shield: How XBOW Discovered Multiple XSS Vulnerabilities in Palo Alto’s GlobalProtect VPN

In the ever-evolving landscape of cybersecurity, even industry-leading security solutions can harbor vulnerabilities that put organizations at risk. Today, we’re excited to share how XBOW, our autonomous AI pentesting system, discovered multiple cross-site scripting (XSS) vulnerabilities in Palo Alto Networks’ GlobalProtect VPN web application (CVE-2025-0133) - a critical security product used by thousands of enterprises worldwide.

These findings highlight both the sophistication of modern security testing and the challenges vendors face in securing complex applications.

Initial Exploration and Reconnaissance

As part of one of our bug bounty runs on HackerOne, XBOW was pointed toward a web application that appeared to be a GlobalProtect VPN instance, with the goal of identifying potential XSS vulnerabilities.

XBOW started with a comprehensive application review, examining the GlobalProtect portal’s structure and functionality. Its first move was to gather basic information about the target:

The initial response revealed a standard GlobalProtect login page, but XBOW wasn’t satisfied with surface-level analysis. It proceeded to examine the application more thoroughly, looking for hidden parameters, JavaScript files, and potential injection points that might be overlooked during manual testing.

Deep Client-Side Analysis

XBOW’s approach to finding vulnerabilities went beyond simple and systematic endpoint testing. It performed a thorough client-side analysis, examining JavaScript files, HTML structure, and network requests to identify potential attack vectors. This deep inspection revealed several interesting aspects of the application:

1. The application used XML for configuration data exchange between client and server
2. Several endpoints returned XML content that could potentially be manipulated
3. Client-side JavaScript processed this XML data and rendered it in the browser

This thorough reconnaissance phase is critical in identifying sophisticated vulnerabilities, as it helps map out the application’s attack surface and understand how data flows through the system.

Initial failed attempts

Instead of jumping straight to the part of the trace where XBOW discovers the vulnerable endpoint and how to exploit it, we believe it is interesting to review its failed attempts and check its reasoning. For example, on the first attempt on the login page it realizes the following:

Unfortunately, it was not able to control those variables from query parameters:

So off it goes to find other endpoints which may indirectly control those variables or expose new vectors.

XBOW didn’t just guess; it wrote and executed code on the fly to scout for hidden paths in a matter of seconds. Here is where LLMs training dataset comes really useful as it knows by heart many of the Global Protect endpoints that a human pentester would have needed surely more time to collect:

And just like that it finds the first promising endpoints:

The scent of vulnerability: Two paths emerge

After this initial exploration of the application, XBOW identified several interesting endpoints, with one standing out in particular:

The /global-protect/getconfig.esp endpoint caught XBOW’s attention because it is processing XML data and returning it to the client, making it a prime candidate for XSS testing.

Parameter Discovery and Testing Methodology

Having identified a target endpoint, XBOW promptly started testing it. Fetching /getconfig.esp it got the following output:

The initial exploration of `/global-protect/getconfig.esp is not very promising since it does not seem to reflect any user-controllable data:

Now, let’s be honest, as a pentester tasked with reviewing this application, how much time would you have spent on an endpoint called getconfig.esp that simply returns <has-config>no</has-config> ? Personally, I would have assumed this endpoint is just serving a static configuration, likely intended for a client where I have no control over and have probably moved on to some other endpoint. In the best case scenario, I would have tried some almost-random and definitely not smart parameters. A more experienced pentester, especially one familiar with VPN solutions, might have approached this endpoint with a more thoughtful set of parameters. That’s exactly what XBOW did:

It started by creating a comprehensive list of potential parameters and simple XSS probe payloads:

And just like that, XBOW got a promising thread to pull:

The Breakthrough: Reflected Parameters in XML

The breakthrough came when XBOW discovered that the portal-prelogonuserauthcookie parameter was reflected in the XML response without proper sanitization. When XBOW sent a test value to the endpoint, it observed the following:

This reflection of user input in the response was the first indication of a potential XSS vulnerability. XBOW immediately recognized this as a promising attack vector and began crafting payloads to exploit it.

The challenge with exploiting this vulnerability was that the input was being reflected within XML tags, which requires different techniques than traditional HTML context XSS. In XML contexts, standard HTML payloads often fail because:

1. XML has stricter parsing rules than HTML
2. XML requires well-formed documents with properly nested tags
3. XML namespaces affect how elements are interpreted
4. Browsers handle XML and HTML differently when rendering

XBOW methodically tested multiple payload approaches, demonstrating a sophisticated understanding of both XML parsing and browser rendering behaviors.

Initial Payload Attempts

XBOW’s first attempts focused on breaking out of the XML structure to inject executable JavaScript. It tried several approaches:

Despite the initial XML context, XBOW proceeded with a systematic campaign of payload crafting. Even if some payloads may not look promising in an XML context, XBOW didn’t discard any potential vectors, even those that seemed unconventional. It methodically explored a wide range of techniques, ensuring nothing was overlooked.

The SVG Namespace Breakthrough

The first attempt failed:

(Decoded payload: <svg onload="alert('XSS')"></svg>)

But after multiple methodical attempts, XBOW made a pivotal, critical observation: properly namespaced SVG elements were being rendered and executed differently. This was the key!

SVG is particularly interesting from a security perspective because:

1. It’s a valid XML format that browsers natively support
2. It can contain executable JavaScript through various event handlers
3. It uses namespaces to distinguish its elements from regular HTML
4. Browsers implement special rendering rules for SVG content

XBOW realized that using SVG with proper XML namespaces could create a payload that was both valid XML and executable JavaScript. It crafted an SVG payload with the appropriate namespace:

(Decoded payload: <root xmlns:svg="http://www.w3.org/2000/svg"><svg:svg><svg:script>alert("XSS")</svg:script></svg:svg></root>)

This approach worked because the SVG namespace is handled differently by browsers than regular HTML tags. When the browser rendered the XML document, it properly interpreted the SVG element and executed the JavaScript in the `onload` attribute, successfully triggering the XSS payload.

Deeper into the rabbit hole: Uncovering sibling vulnerabilities

After the initial discovery, XBOW didn’t stop there. It conducted a thorough analysis to identify similar vulnerabilities across the application. This process, known as Variant Analysis, is critical in security research, as vulnerabilities tend to repeat across different parts of an application.

Variant 1: Additional Parameter in the Same Endpoint

XBOW discovered that beyond the portal-prelogonuserauthcookie parameter, the standard portal-userauthcookie parameter was also vulnerable to the same type of XSS attack. This finding demonstrates how a single vulnerability pattern can exist across multiple parameters within the same application.

(Decoded payload: <svg onload="alert('XSS')" xmlns="http://www.w3.org/2000/svg"></svg>)

Variant 2: Similar Vulnerability in a Different Endpoint

Taking its investigation even further, XBOW explored other endpoints and discovered that /ssl-vpn/getconfig.esp was vulnerable to a similar XSS attack. This endpoint accepted parameters like user, domain, and computer, and reflected input in an XML context without proper sanitization.

This time, XBOW wrote a python script to test the user parameter:

Quick and straight to the point, but it worked!

Interestingly, the first attempt did not include the SVG vector but an XHTML script one. This payload successfully executed because the XHTML namespace allowed the script to be interpreted as executable JavaScript rather than just XML data. The success of this approach highlights the importance of understanding how different XML namespaces are processed by browsers.

Each variant exploited the same fundamental issue - improper handling of user input in XML responses - but with subtle technical differences:

1. Original Exploit: used SVG with an `onload` event handler to automatically execute JavaScript when the element was rendered.
2. Second Variant: used the XHTML namespace to make a script tag executable within an XML context.

These different approaches demonstrate the flexibility of XML-based XSS attacks and the importance of comprehensive security testing that explores multiple attack vectors. Each approach exploits different browser behaviors and parsing mechanisms, making them potentially effective against different security controls. We will see how critical this is later on.

Impact and Remediation

The vulnerabilities discovered by XBOW have significant security implications for organizations using Palo Alto’s GlobalProtect VPN. These XSS vulnerabilities could allow attackers to:

1. Execute malicious JavaScript in the context of authenticated users’ browsers
2. Perform phishing attacks that appear to come from the legitimate VPN portal

Reporting

Palo Alto quickly responded and started working on a fix. They quickly implemented a mitigation through their Threat Prevention WAF by creating a signature to block the Cross-Site Scripting (XSS) attack. As soon as we learned that the mitigation had been released and was actively being applied by customers, we used the Re-test feature in XBOW. This not only checks whether the vulnerability has been addressed, but, like a skilled attacker, also attempts to bypass the mitigation to ensure it is effective.

Within a few minutes of re-testing, to the surprise of our entire team, XBOW was able to generate a new working exploit that successfully bypassed the threat signatures. We promptly reported this finding to Palo Alto and are currently awaiting updates from them regarding an improved mitigation.

Technical Remediation Approaches

Palo Alto Networks has since acknowledged these vulnerabilities and released patches in various versions of PAN-OS. The vulnerabilities have been assigned CVE identifier CVE-2025-0133.

Organizations using GlobalProtect VPN should:

1. Update to the latest patched versions of PAN-OS
2. Enable relevant Threat Prevention signatures (Threat IDs 510003 and 510004)
3. Consider disabling Clientless VPN if not in use, as this feature increases the risk associated with these vulnerabilities

Conclusion: Lessons for Security Testing

This case study demonstrates the power of AI-driven security testing in identifying complex vulnerabilities that might be missed by traditional methods. XBOW’s systematic approach, combining thorough reconnaissance, creative payload crafting, and variant analysis, allowed it to discover multiple XSS vulnerabilities in a leading security product.

As we continue to develop and refine XBOW’s capabilities, we look forward to sharing more discoveries that help make the digital world safer for everyone. The technical depth and sophistication demonstrated in finding these vulnerabilities show how AI-driven security testing can push the boundaries of what’s possible in vulnerability research.