Simple Bugs in SAML Apps - Oracle Commerce Cloud
Security Assertion Markup Language (SAML) is a protocol that provides a single sign-on capability for applications, allowing users to sign in once and access multiple apps without repeatedly entering their credentials. It uses XML to transmit identity information between two key entities: an Identity Provider (IdP) and a Service Provider (SP). Though it has many benefits, including enabling good security practices like a Zero Trust security strategy, its flexibility and complexity makes it easy to introduce hidden vulnerabilities. SAML flows usually sit on your most exposed attack surface, and bugs in authentication flows are often highly impactful, making it a great target for attackers.
Over the past few years, I’ve spent significant time hunting SSO-related bugs, including SAML/OAuth misconfigurations, earning over $23,000 in bounties from just one company’s SAML vulnerabilities. Despite it being widely used, bug hunters often either skip or under-test SAML flows—possibly due to the assumption that they’re secure or too complex to analyze. My experience of having relatively few duplicates when reporting SAML-related bugs confirms this.
In July 2023, while spending time hacking a US shipping vendor’s environment, I discovered an XXE (XML External Entity) vulnerability in the Oracle Commerce Cloud SAML login flow which allowed an attacker to forge server-side requests (SSRF) via an external DTD. In this post, I outline how I found it, the methods I used, and the disclosure process.
Target Recon & SAML Flow
Recon and Identification
My typical process for finding SAML or OAuth-based targets involves subdomain enumeration, followed by httpx to detect redirects pointing to SAML or OAuth flows.
The snippet below shows an example of how you can identify hosts that redirect to SSO flows using open-source tools.
➜ cat active | httpx -silent -stats -fr | grep -iE "oauth|saml|redirect_uri|client"
By looking for interesting markers in responses, we can easily locate SAML/OAuth flows. Two examples with output are below:
https://admin-dogfood.teams.microsoft.com -> [https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=2ddfbe71-ed12-4123-b99b-d5fc8a062a79&redirect_uri=...]
https://api-dev.msapprovals.microsoft.com -> [https://login.microsoftonline.com/.../oauth2/authorize?response_type=id_token&redirect_uri=...]
In our target environment for the XXE bug, numerous custom and SaaS applications were hosted on different subdomains. One subdomain was running Oracle Commerce Cloud with SAML for authentication.
Finding the XXE with Burp & SAML Raider
Self-Registration & SAML Consume endpoints
As an attacker, a useful feature in this environment was a self-registration link on the IdP. Even though the newly created user had no real permissions assigned, it still allowed me to complete the SAML flow and see what the expected SAML requests looked like.
During testing, I spotted two SAML consumption endpoints on Commerce Cloud:
1. /SAML/post
– The main route for standard SAML responses.
2. /ccstore/v1/login
– A second route, perhaps for more advanced login logic / different functionality.
The first endpoint (/SAML/post
) appeared secure; my attempts to insert malicious data or manipulate the SAML request didn’t pan out. The second endpoint, however, was more interesting. Using SAML Raider to ensure my SAML messages were properly formatted, I injected a generic XXE payload at the top of the XML above the signed SAML message. I immediately received a callback on my Burp Collaborator server, confirming the parser was fetching an external DTD.
Below is a simplified snippet of the injected payload. Notice the <!DOCTYPE>
directive pointing to an external resource:

Once the request with the modified SAML message containing the XXE is sent to the vulnerable /store/v1/login
endpoint, the server attempts to load http://[COLLABORATOR_SERVER]
, indicating that the XXE was successfully triggered. Although the app returned a “401 Unauthorized,” the request to my callback URL verified that the server is making requests to arbitrary hosts without restrictions (SSRF).
Under the hood
HTTP Request

HTTP Response

Shortened SAML Message

XXE Impact
In this case, the XXE flaw resulted in a blind SSRF with no direct file read or internal service compromise. Though this is less impactful than some other forms of XXE weakness, blind SSRF vulnerabilities in a SAML/SSO environment remain a significant concern. Even a low-impact SSRF can be escalated if a parser is poorly configured or the network isn’t segmented correctly.
The blind-ssrf-chains repo from Assetnote has some good examples of how you can escalate a blind SSRF into a vulnerability chain with critical impact. For example, SSRF in Oracle WebLogic’s UDDI Explorer & CVE-2020-14883 can be used to grant Remote Code Execution. Though ‘blind’, it can also still be used for further recon by leveraging various techniques outlined in the repository, such as SSRF canaries or side channel leaks.
Key Takeaways
- Validate XML Safely: Always ensure that your XML parsing libraries are ignoring or rejecting external DTDs and entity references.
- XXE in SAML: An XML External Entity flaw in the SAML parsing logic can lead to SSRF, local file disclosure, etc.
- Identify as many SAML consumption routes as possible: Large target environments may contain tons of hosts utilizing SSO in some way, each could have numerous SAML consumption endpoints to test. Even if one is secure, another might be overlooked. They might even have separate SAML/OAuth flows for different account types. It’s important to identify and test all of them.
- SSO Impact: A single SSO misconfiguration can compromise the integrity of numerous connected applications.
Disclosure
After reproducing the XXE, I reported it to Oracle. Oracle Commerce Cloud patches are typically applied automatically for customers, but the vendor does not assign CVEs for these cloud-based issues, and as of January 2025, there’s no direct mention in their public security advisories. Nevertheless, they acknowledged my report and fixed the vulnerability.
Timeline
- July 9, 2023: Discovered the XXE bug in Oracle Commerce Cloud while hacking on a BBP; submitted the details to Oracle.
- July 17, 2023: Oracle acknowledged the vulnerability and started working on it.
- September 2023: Patch released.
- January 21, 2025: Oracle issued a Security Advisory crediting me but did not include explicit technical details of the vulnerability.
Further reading
For penetration testers, security engineers, or bug hunters, SSO apps remain a really wide avenue for exploration. Whenever you see SAML being used on a target host, keep an eye out for classic XML vulnerabilities like XXE. I’d recommend having a read of the following to learn more:
HackTricks: SAML Attacks (XXE)
OWASP SAML Security Cheat Sheet
GitHub XSW SAML Vulnerability Example
Keep up with the latest CVE trends with Intruder's free vulnerability intelligence platform.