Full Report
In a previous blog post, they discussed a vulnerability in an authentication flow that was broken through bad frame communication. One of the issues that made this possible is discussed in depth in this blog post. OAuth Proof Key for Code Exchange (PKCE) is an authorization flow used to prevent code interception and injection attacks. This is done via the calling application, creating a secret that is then verified by the authorization server. The code was generated on the client side as a SHA-256 hash and then sent to the server for later use. The authorization code returned by the SSO is bound to whatever codeChallenge was in the URL when the SSO page loaded. The parent page generates the PKCE and includes the challenge as part of the SSO URL. This is a problem though: the challenge must be generated and unique to the request! If an attacker can set it, then it bypasses the entire purpose of PKCE. A good quote from the author: "PKCE protects the code in transit. It does NOT protect against an attacker who controls the authorization request itself." Understanding what a security does and doesn't protect against is crucial. Great spot to finish off the chain!
Analysis Summary
# Vulnerability: OAuth PKCE Bypass via Attacker-Controlled Initiation
## CVE Details
- **CVE ID**: Not Assigned (Discovered via Bug Bounty Program)
- **CVSS Score**: 8.3 (High) - *Estimated based on Zero-Click Account Takeover impact*
- **CWE**: CWE-601: URL Redirection to Untrusted Site ('Open Redirect'), CWE-1021: Improper Restriction of Renderable Layers (Clickjacking)
## Affected Systems
- **Products**: Major E-commerce Platform (Unnamed)
- **Versions**: All versions prior to the remediation date (February 2026)
- **Configurations**: OAuth 2.0 implementations using an SSO popup/iframe where the authorization request URL can be initiated from an untrusted third-party origin.
## Vulnerability Description
The vulnerability exists because the OAuth implementation allowed the **client** (the initiator of the request) to specify the `codeChallenge` without verifying the legitimacy or origin of the initiation request.
While Proof Key for Code Exchange (PKCE) is designed to protect the authorization code from interception in transit, it assumes the legitimate client generates the secret. In this flaw, an attacker-controlled page initiates the SSO flow within an iframe or popup, supplying a `codeChallenge` for which the attacker already holds the `codeVerifier`. Because the authorization server binds the resulting code to the attacker's provided challenge, the attacker can successfully complete the exchange, bypassing PKCE's security guarantees.
## Exploitation
- **Status**: PoC available (Validated in a Bug Bounty environment)
- **Complexity**: Medium
- **Attack Vector**: Network (Web-based)
## Impact
- **Confidentiality**: High (Full access to user sessions and JWT tokens)
- **Integrity**: High (Ability to perform actions on behalf of the user)
- **Availability**: Low (No direct system denial of service, but account lockout is possible)
## Remediation
### Patches
- The vendor has resolved the issue by implementing stricter origin validation. Specific versioning is not applicable as it is a SaaS platform.
### Workarounds
- **Frame Protection**: Implement `Content-Security-Policy: frame-ancestors 'self' [trusted_domains]` to prevent the SSO page from being embedded in malicious iframes.
- **X-Frame-Options**: Use `X-Frame-Options: DENY` or `SAMEORIGIN` on OAuth endpoints as defense-in-depth.
- **Origin Validation**: Ensure the authorization server validates the `Redirect_URI` and the origin of the request strictly against a whitelist.
## Detection
- **Indicators of Compromise**:
- Multiple OAuth authorization codes being exchanged for tokens from IP addresses differing from the initiation IP.
- Large volumes of SSO requests originating from unauthorized or unknown referrers.
- **Detection Methods**:
- Monitor OAuth logs for mismatches between the client that initiated the flow and the client that completed the token exchange.
- Audit JavaScript SDKs for non-standard PKCE implementations (e.g., Hex encoding vs. Base64URL).
## References
- Trace37 Labs - Original Research: hxxps[://]labs[.]trace37[.]com/blog/pkce-bypass-oauth/
- Companion Post on MessagePort Injection: hxxps[://]labs[.]trace37[.]com/blog/messageport-ato/
- OAuth 2.0 Security Best Current Practice: hxxps[://]datatracker[.]ietf[.]org/doc/html/draft-ietf-oauth-security-topics