GHSA-9H47-PQCX-HJR4: Insecure Cryptographic Defaults in Better Auth OIDC Provider

The OpenID Connect (OIDC) provider component (oidcProvider) of the Better Auth framework is responsible for identity federation, issuing JSON Web Tokens (JWTs) representing authenticated sessions, and managing standard OIDC endpoints. In versions preceding v1.6.11, the provider suffered from critical insecure cryptographic defaults that compromised the integrity of token verification and session exchange flows. This vulnerability falls under the category of cryptographic issues and insecure configurations.

The attack surface is exposed via standard OIDC routing interfaces. Specifically, the metadata discovery endpoint (/.well-known/openid-configuration) and the token validation handlers within client integrations are affected. When these endpoints are configured with insecure defaults, they allow clients to trust weak algorithms or unhashed verifiers, compromising the entire trust boundary.

An unauthenticated remote attacker can exploit these configurations to bypass token signature verification or intercept and exchange authorization codes. The impact of these weaknesses is severe, potentially allowing unauthorized access to system resources and privilege escalation across downstream client systems that consume identities from the affected Better Auth OIDC provider.

The first critical issue lies in the advertisement of the none signature algorithm in the OIDC configuration. In the JWT specification (RFC 7519), the none algorithm indicates that the token is unsigned and requires no validation signature. Under normal operations, an OIDC provider must enforce cryptographic signatures (such as RS256 or ES256) to ensure the token has not been altered. Better Auth advertised none within the list of supported signing algorithms, meaning relying clients might accept unsigned assertions as authentic.

The second issue is the default acceptance of the plain code challenge method for Proof Key for Code Exchange (PKCE, RFC 7636). PKCE protects authorization flows against interception by requiring clients to present a secret verifier. There are two challenge methods: S256 (where the verifier is hashed using SHA-256) and plain (where the raw verifier is sent in the initial request).

By allowing plain by default, Better Auth removes the cryptographic protection intended by PKCE. If an attacker intercepts the initial authorization request, they capture the cleartext code challenge. Since no cryptographic hash transformation is applied, the intercepted value serves directly as the verifier, allowing the attacker to complete the token exchange process.

The vulnerability manifests in how the OIDC configuration metadata is assembled and how PKCE requests are handled during verification. Prior to version v1.6.11, the provider endpoint exposed none in its supported algorithms, and validation checks allowed plain verifier matching without enforcing secure hashing.

The configuration template of the discovery endpoint previously contained the following algorithm list:

// Vulnerable OIDC discovery configuration template
const oidcConfig = {
  issuer: 'https://auth.example.com',
  authorization_endpoint: 'https://auth.example.com/oauth2/authorize',
  token_endpoint: 'https://auth.example.com/oauth2/token',
  // INSECURE: 'none' is explicitly advertised as a valid signing algorithm
  id_token_signing_alg_values_supported: ['RS256', 'none'],
  // INSECURE: 'plain' is allowed as a valid PKCE verification method
  code_challenge_methods_supported: ['plain', 'S256']
};

In the updated version (v1.6.11), the none algorithm is removed entirely from the advertised capabilities to prevent clients from choosing unsigned verification paths. Additionally, the token validation module rejects the plain PKCE challenge method unless explicitly configured to allow it for legacy compatibility.

// Patched OIDC discovery configuration template in v1.6.11
const oidcConfig = {
  issuer: 'https://auth.example.com',
  authorization_endpoint: 'https://auth.example.com/oauth2/authorize',
  token_endpoint: 'https://auth.example.com/oauth2/token',
  // SECURE: Only strong cryptographic algorithms are advertised; 'none' is removed
  id_token_signing_alg_values_supported: ['RS256'],
  // SECURE: Only 'S256' is advertised by default to enforce SHA-256 code challenge verification
  code_challenge_methods_supported: ['S256']
};

This mitigation is robust because it addresses both metadata advertisement and server-side enforcement. Removing none ensures compliant client libraries will never attempt to validate unsigned tokens against the provider, while enforcing S256 ensures the server rejects cleartext verifiers.

To exploit the signature bypass, an attacker first queries the openid-configuration endpoint to verify if the server advertises support for none. If advertised, the attacker constructs a forged JWT with the algorithm header set to none and an empty signature block. When the client application attempts to verify this token, it matches the header with the advertised capabilities and skips the cryptographic check, granting access to the attacker.

For PKCE interception, the attacker targets native or mobile clients that leverage custom URI schemes. The attacker installs a malicious application designed to register the same custom URI scheme. When the target client initiates authorization, it sends a cleartext challenge. Since plain is accepted, the attacker intercepts the code and challenge, directly exchanging them at the /oauth2/token endpoint.

This exploitation methodology requires no complex cryptanalysis. It relies entirely on the logical bypasses enabled by the insecure defaults, making the vulnerability trivial to exploit in environments where transport layer security or deep linking configurations are compromised.

The impact of these insecure defaults is high. In systems where client libraries blindly trust the discovery metadata, the alg=none capability allows complete account takeover. Attackers can forge identity tokens representing any user, including administrative accounts, bypassing authentication controls entirely without needing access to secret keys.

For systems relying on PKCE for mobile or single-page applications, accepting the plain code challenge method introduces session hijacking and authorization code theft vectors. An adversary positioned on the local network or hosting a malicious application on the user device can obtain session tokens, leading to unauthorized API access.

This vulnerability affects any deployment utilizing Better Auth as an identity provider with default configurations. The lack of standard cryptographic enforcement compromises the confidentiality and integrity of all data protected by the authentication system.

The primary remediation strategy is upgrading the Better Auth package to version v1.6.11 or later. This update enforces secure defaults by removing none from advertised algorithms and disabling support for the plain PKCE method in default configurations.

To upgrade the package in a Node.js environment, execute the following command:

npm install better-auth@1.6.11

After upgrading, verify that the OIDC discovery configuration endpoint no longer lists none under id_token_signing_alg_values_supported and only advertises secure PKCE methods:

curl -s https://<your-auth-domain>/.well-known/openid-configuration | grep -i '"none"'

Ensure that any integrated client applications are configured to explicitly demand the S256 PKCE method, preventing any legacy clients from downgrading to insecure validation paths.