OIDC Provider Takeover + JSONP Callback Injection

If users can point SSO at an arbitrary OIDC provider, the auth boundary shifts to attacker-controlled metadata. JSONP-style callback endpoints add a second browser-side code-execution vector.

Why It Works

• Weak issuer allowlists let attacker discovery documents drive auth; JSONP callbacks reflect a caller-supplied function name into executable script.

Vulnerable Pattern

• Admin or self-service OIDC configuration endpoints with weak issuer allowlists, plus endpoints like directory.js?callback=... still supporting JSONP.

Exploit Flow

1. Test the JSONP endpoint independently first to see if callback injection is directly exploitable.
2. Separately test whether OIDC issuer configuration accepts attacker metadata or weakly validated discovery endpoints.
3. Combine them only if necessary — often one is enough.

Variations

• CRLF in callback names, javascript: references in OIDC metadata, or discovery documents hosted under attacker control.

Common Blockers

• Strict OIDC issuer pinning, callback-name regexes, or JSONP wrappers that stringify safely.

PoC Sketch

GET /directory.js?callback=alert(1)//
# and try registering an attacker-controlled OIDC issuer in /api/sso

Good Situations To Use It

• SSO issuer config is user-settable with weak validation.
• A JSONP endpoint reflects the callback name.
• You need either auth takeover or browser-side execution.

Sources

• labossi_2026/web/trusted_support_v2