GHSA-XWMW-PRC4-V3CR: OAuth Dynamic Client Registration Enables API Token Theft via Audience Confusion in Obot Platform

The Obot Platform is an open-source system designed for orchestrating AI agents and Model Context Protocol (MCP) servers. To secure its control plane and manage agent access, the platform integrates an internal OAuth 2.0 authorization server. When authentication is enabled via the OBOT_SERVER_ENABLE_AUTHENTICATION=true configuration, this server governs how users and components authenticate and access APIs.

In versions prior to v0.23.0, the platform exposed a critical security flaw involving its OAuth flow. The vulnerability arises from three interacting weaknesses: unauthenticated dynamic client registration, a consentless authorization sequence, and a complete lack of audience validation during JWT verification. An attacker can exploit this combination to execute a silent privilege escalation attack.

This architecture permits an external adversary to register a malicious client, trick an authenticated administrator into navigating to a crafted authorization URL, and steal their OAuth authorization code. Because the platform does not validate the token audience, the resulting token grants the attacker full control over the Obot Server.

The security failure of GHSA-XWMW-PRC4-V3CR is caused by three separate implementation flaws. The first flaw is located in the dynamic client registration endpoint (/oauth/register). This endpoint was exposed publicly without authentication, allowing any remote client to register arbitrary redirect URIs.

The second flaw occurs within the OAuth authorization workflow. The Obot Server lacked a consent screen or confirmation step. If an authenticated user accessed the /oauth/authorize endpoint, the server assumed immediate consent, issuing an authorization code and redirecting the browser automatically.

The final and most critical flaw lies in the token verification subsystem of the Obot core API. While the server issues JSON Web Tokens (JWT) with an audience (aud) claim matching the requested Model Context Protocol (MCP) server, the API gateway verified only the signature and issuer. It omitted validation of the aud claim, allowing scoped MCP tokens to be accepted as administrative credentials.

The vulnerable authentication logic failed to cross-reference the client identity with the intended token audience during JWT validation. The following conceptual Go implementation illustrates the missing validation check in the token parsing logic.

// VULNERABLE: Token parsing logic in < v0.23.0
func ValidateTokenVulnerable(tokenStr string, secret []byte) (*Claims, error) {
    token, err := jwt.ParseWithClaims(tokenStr, &Claims{}, func(t *jwt.Token) (interface{}, error) {
        return secret, nil
    })
    if err != nil {
        return nil, err
    }
    claims, ok := token.Claims.(*Claims)
    if !ok || !token.Valid {
        return nil, errors.New("invalid token")
    }
    // MISSING: Validation of the audience claim (claims.Audience)
    // The server trusts any signed token containing group mappings
    return claims, nil
}

In the patched version (v0.23.0), the validation subsystem explicitly checks that the target audience corresponds strictly to the expected service. The repaired code path ensures that specialized tokens are rejected on administrative routes.

// PATCHED: Enforced audience validation in >= v0.23.0
func ValidateTokenPatched(tokenStr string, secret []byte, expectedAudience string) (*Claims, error) {
    token, err := jwt.ParseWithClaims(tokenStr, &Claims{}, func(t *jwt.Token) (interface{}, error) {
        return secret, nil
    })
    if err != nil {
        return nil, err
    }
    claims, ok := token.Claims.(*Claims)
    if !ok || !token.Valid {
        return nil, errors.New("invalid token")
    }
    // PATCH: Explicitly check the audience claim
    if claims.Audience != expectedAudience {
        return nil, errors.New("audience mismatch: token is unauthorized for this endpoint")
    }
    return claims, nil
}

This logic prevents scoped OAuth tokens from being used outside their designed context. Even if an attacker registers a client and obtains a token, the token is bound to a specific audience and is useless for administrative API execution.

Exploitation of this vulnerability requires a multi-stage process where the attacker establishes a rogue client and redirects an active administrative session. First, the attacker registers a client pointing to a remote server. Because registration is unauthenticated, no API key or session is required to establish this rogue client.

The attacker then constructs an authorization link containing the registered client ID and sends it to the targeted administrator. The target, possessing an active session on the Obot server, opens the link. The server immediately generates an authorization code and redirects the victim's session to the attacker's server.

The attacker exchanges this code for a JWT. Although this JWT was issued under the guise of an MCP server scope, the attacker submits it to the administrative endpoints. Due to the lack of audience checks, the API processes the request with administrative rights. The following diagram illustrates this sequence.

The impact of GHSA-XWMW-PRC4-V3CR is classified as high because it allows complete control over the Obot Platform's data and agent systems. Because the tokens capture the full group memberships of the authorized user, an attacker gaining an administrator's token achieves administrative parity. They can modify workflows, read sensitive parameters, and access internal configurations.

The CVSS v3.1 base score is assessed at 8.8 (High). The primary mitigating factor in this vector is the requirement for User Interaction (UI:R), as the administrator must navigate to the authorization URL. However, the attack requires no privileges (PR:N) and is highly reliable once the victim triggers the link.

Since this is tracked via a GHSA advisory without an active CVE, it is not currently listed on the CISA KEV or tracked by public EPSS systems. Nonetheless, because the underlying primitives utilize standard OAuth registration and exchange flows, the exploitability of this issue is high and reliable.

The primary remediation path is upgrading the Obot installation to version 0.23.0 or later. This release addresses the vulnerability by introducing three defensive layers. First, a mandatory consent dialog is presented to the user, blocking auto-completion of authorization requests. Second, issued tokens are tightly scoped to specific MCPs. Finally, the core API enforces audience verification.

If upgrading is not immediately feasible, operators should apply temporary access controls. Network policies can be configured to block access to the /oauth/register endpoint from public networks. This prevents external actors from registering clients and interrupts the first stage of the attack chain.

Additionally, operators can temporarily disable authentication by setting the environment variable OBOT_SERVER_ENABLE_AUTHENTICATION=false. This configuration removes the vulnerable OAuth server code from the active execution path. However, this is an emergency measure and should only be applied within trusted networks.