Summary

ZScaler’s SAML 2.0 Service Provider (SP) implementation does not verify that incoming SAML responses are signed with the configured Identity Provider’s (IdP) public key.

Impact

An attacker can generate arbitrary SAML Assertions naming themselves as any user. The server responds with an access token which can be used to register an arbitrary device in Zscaler, under the targeted account.

Affected Versions

Confirmed on 6.2r.2505_prod.68.438498_114 (2025-07-16)

Technical details

The SP POST binding endpoint /sfc_sso accepts a <Response> and associated <Assertion> that are signed with any certificate, regardless of the IdP certificate configured in the admin UI.

When POSTing a forged SAMLResponse to the /sfc_sso endpoint, the server does not properly validate the SAML assertion signature and a JWT token is returned - allowing an attacker to use the returned token to register an unauthorised device.

No privileged access or prior compromise of the IdP is required.

Exploitation

An attacker who knows the target user’s email can:

1. Fetch the AuthN request from https://login.zscaler.net/clstart, passing a chosen PKCE code_challenge and challenge_method (e.g. S256).
2. Extract the SAMLRequest and RelayState from the response.
3. Create a self signed X.509 certificate and corresponding private key.
4. Craft a SAML Assertion with the victim’s email in <NameID> and in <AttributeStatement>.
5. Sign the Assertion with the attacker’s key
6. Base64 encode the <Response> and submit it via HTTP POST to https://login.zscaler.net/sfc_sso in the SAMLResponse parameter, and the RelayState from the original /clstart response.

The SP issues a valid JWT, which can in turn be used to register a new device in the victim’s tenant, by providing the chosen code_verifier and generated JWT.

In the following example, the attacker provides the target domain and specifies the target user’s email address in the user parameter. When the script is run, it creates the required PKCE verifier, fetches the AuthN request, generates an arbitrary certificate and signs a forged assertion with the certificate. The forged assertion is then POSTed to the SP and a JWT is returned.

Looking at the request in burp, we can see the SAMLResponse parameter being sent to the server, containing the self signed, forged assertion.

Demo

The following video demonstrates exploitation of this issue. First, we forge a SAML assertion for a user and send it to the server, which responds with a JWT. We then use this JWT to register a fake machine in Zscaler, with a controlled hardware ID and MAC address to demonstrate JWT validity.

Zscaler’s Response

• This issue was reported to Zscaler on 2025-07-18. Zscaler quickly fixed the issue within 4 hours of our initial report
• On 2025-07-22, we discovered that the vulnerability had been regressed and we were able to exploit the same vulnerability against the previously patched endpoint
• We reported the regression to Zscaler’s security team who advised that applying the hotfix caused a higher severity regression, and they had to undo the hotfix
• On the 4th August, Zscaler confirmed that the fix had been reinstated and fully rolled out to all supported clouds. CVE-2025-54982 has been assigned by Zscaler for this vulnerability. The fix was applied server-side, and no further action required by Zscaler customers
• Zscaler have released their own advisory for this issue which can be found here