Finding XSS in Salesforce Aura Components: How XBOW Got Creative

We’re back with another discovery from XBOW, our agentic, human operated, AI powered ethical hacker, and this time an opportunity to enhance the security posture of Salesforce’s Aura framework. Today we’re diving into a Cross-Site Scripting (XSS) vulnerability that XBOW uncovered in Salesforce Aura components - specifically affecting the /s/sfsites/aura and /sfsites/aura endpoints.

For those not familiar with Salesforce Aura, it’s the framework that powers Lightning components across Salesforce’s ecosystem. While Salesforce recommends Lightning Web Components (LWC) over Aura, Aura components remain in widespread use from custom applications to Experience Cloud sites (formerly known as Community Cloud). This highlights the critical need for continuous security vigilance across thousands of Salesforce implementations. Although Aura components are robust and widely tested, the vulnerability XBOW identified demonstrates the evolving nature of cybersecurity threats, emphasizing why ongoing monitoring and innovative testing methods are critical.

XBOW reported this to Salesforce through their Coordinated Vulnerability Disclosure (CVD) process, and Salesforce’s response was exemplary. Their dedicated security team acted promptly, communicating clearly and effectively throughout remediation. They quickly pushed out fixes across their infrastructure and granted us permission to share this technical breakdown publicly. We commend Salesforce’s swift action and commitment to maintaining trust and security across their platforms.

The Initial Reconnaissance: Mapping a Salesforce Landscape

XBOW kicked off this hunt with one clear objective: to find an XSS vulnerability. From the very first request, XBOW technology recognized a clue about the target environment:

“The initial request shows that the application redirects to `/s/login`. This suggests we’re dealing with a Salesforce-based application.”

Rather than getting distracted by the redirection or the login page itself, XBOW stayed laser-focused on its mission. Like any skilled penetration tester or bug bounty hunter, XBOW technology focuses on preventing disruption as it starts to look for security vulnerabilities. It spun up a Python script to systematically test basic XSS payloads across various parameters discovered during the early reconnaissance, emulating manual human research activity in doing so. As the application’s structure started to unfold, more potential injection points were identified, and those too were put under the microscope.

But what makes XBOW stand out isn’t just automation or persistence—it’s creativity. Despite the minimal attack surface presented by the initial pages (with almost no forms or user input areas), XBOW didn’t stop. It tapped into its extensive training data and deep contextual knowledge of Salesforce. Here’s where it made a leap:

“Looking at the login page again, I notice that this is likely a Salesforce Community (Experience Cloud) site. Let’s now check for some Salesforce-specific endpoints and parameters that might be vulnerable to XSS. Salesforce applications often have specific URL patterns and parameters that can be exploited.”

This wasn’t brute-forcing blindly. XBOW started crafting combinations of known Salesforce endpoints and common parameters, pairing them with various XSS payloads—an approach born out of both knowledge and ingenuity. It was a strategic shift, proving that creativity isn’t just about guessing.

The Learning Phase: When Nothing Works (Yet)

After extensive testing across various Salesforce-specific endpoints, XBOW had to face some hard truths. The results weren’t immediately promising:

“After extensive testing, we’ve learned that:

• The application is a Salesforce Experience Cloud (Community) site. Many endpoints return HTML but don’t have visible forms or input fields (they may be dynamically generated).
• The Content Security Policy (CSP) only contains ‘upgrade-insecure-requests’ which doesn’t protect against XSS.
• We didn’t find any obvious reflection points in the parameters we tested.”

But here’s what separates XBOW from typical automated scanners: it learns from negative results and adapts its strategy. Instead of giving up, XBOW pivoted to focus on a more specific attack vector.

“Let’s now focus on exploring Aura/Lightning components, which are commonly used in Salesforce Experience sites. These components are loaded dynamically and might have XSS vulnerabilities. Specifically, I want to check the aura endpoints and test for parameters that might be processed by these components.”

This pivot was crucial. XBOW was targeting the specific technology stack it had identified: Aura/Lightning components. This focused approach would soon pay off in a big way.

The Breakthrough: Finding Reflection in Aura

XBOW’s systematic testing of Aura-specific endpoints finally yielded results. After combining typical Salesforce endpoints with common parameters and various XSS payloads, something interesting happened:

“We’ve made a significant breakthrough! We found that the ‘aura.tag’ parameter in the /s/sfsites/aura endpoint reflects our XSS payloads. The response shows that our payloads are being reflected with a [COMPONENT] suffix. This could be a potential XSS vulnerability.”

This was the moment when persistence met opportunity. The aura.tag parameter was reflecting input, and XBOW had found its injection point. But finding reflection is just the first step - confirming actual XSS execution is where the real work begins.

The Verification Challenge: Content-Type Complications

One of XBOW’s strongest features is its ability to distinguish between false positives and real vulnerabilities. It doesn’t just report potential issues - it verifies them thoroughly. So when XBOW found the reflection, it immediately moved to confirm whether this could lead to actual JavaScript execution.

XBOW fired up a headless browser to test the payload in a real browsing context. The results were… disappointing. The payload that looked so promising in the HTTP response was being HTML-encoded in the final DOM. The culprit? The response was being served with a text/plain content type, which meant the browser wouldn’t interpret the reflected content as executable HTML.

Most researchers might have called it a day here. The reflection was there, but it wasn’t exploitable due to the content type. But XBOW doesn’t operate with the same limitations as human researchers - it doesn’t get tired, it doesn’t experience burnout, and it doesn’t make assumptions about what should or shouldn’t work.

XBOW created another Python script, this time focusing on an additional parameter it had in its knowledge base: aura.format. This is where things got really interesting.

The Counter-Intuitive Discovery: JSON Format, HTML Content Type

What happened next perfectly demonstrates why XBOW’s approach is so effective. Most people would assume that setting aura.format=JSON would result in a JSON response with appropriate `application/json` content type headers. That would be logical, predictable, and … completely wrong.

XBOW tested various parameter combinations methodically, and when it tried aura.format=JSON, something unexpected happened:

This was counterintuitive in the best possible way. Setting the format to JSON actually caused the response to be served with an `text/html` content type. This kind of discovery showcases exactly why XBOW’s tireless, assumption-free approach is so powerful. A human researcher might have skipped testing aura.format=JSON because “obviously that won’t help with HTML injection.” XBOW tested it anyway, and that made all the difference.

The Final Push: Bypassing Script Tag Filtering

XBOW now had all the pieces: a reflection point (aura.tag), a way to get HTML content type (aura.format=JSON), but there was still one hurdle. The <script> tags in the initial payload were being escaped, preventing execution.

For XBOW, this was just another problem to solve systematically. It created yet another script to test alternative XSS payloads that might work in this specific context. After trying various approaches, XBOW found the winning combination:

SVG with onload event handlers. These weren’t being filtered the same way as script tags, and they executed perfectly in the HTML context that the aura.format=JSON parameter was creating.

Mission accomplished! The XSS vulnerability was successfully triggered, and it captured the flag.

By combining an SVG payload with the aura.tag parameter and setting aura.format=JSON, it achieved script execution. The exploit worked due to three key factors:

• The aura.tag parameter reflected input without proper sanitization.
• The aura.format=JSON parameter caused the server to return the response with a text/html;charset=utf-8 content type.
• This allowed the browser to interpret the response as HTML, leading to execution of the onload handler within the injected SVG.

Each of these elements was necessary, but none was sufficient on its own. It took XBOW’s systematic approach, combined with its willingness to test counter-intuitive parameter combinations, to discover how they worked together.

Impact and Responsible Disclosure

XBOW reported this to Salesforce through their Coordinated Vulnerability Disclosure (CVD) process, and Salesforce’s response was exemplary. Their dedicated security team acted promptly, communicating clearly and effectively throughout remediation, quickly pushing out fixes across their infrastructure.

Before the bug was discovered and remediated, an attacker could craft malicious URLs that, when visited by authenticated users, would execute arbitrary JavaScript in the context of their Salesforce session. This could potentially lead to session hijacking, data theft, or unauthorized actions performed on behalf of the victim.

This Salesforce Aura XSS discovery represents exactly the kind of creative, thorough security testing that XBOW excels at. While human researchers bring intuition and contextual understanding to security testing, XBOW brings unlimited persistence, systematic coverage, and freedom from assumptions about how things “should” work.

The combination of extensive training data about specific technologies (like Salesforce Aura) with systematic testing approaches creates opportunities for discoveries that might be missed by traditional testing methods.

As applications become more complex and attack surfaces continue to evolve, having an AI that can systematically explore every possibility - no matter how counterintuitive - becomes increasingly valuable.

The hunt continues, and XBOW is just getting started!