GHSA-GFJ5-979R-92PW: Unauthenticated Authentication Bypass in @acastellon/auth via Header Spoofing

The @acastellon/auth NPM package is an Express-based middleware library designed to handle unified authentication across microservice architectures. It integrates support for diverse protocols, including JWT, NTLM, and OpenID Connect (OIDC). By registering the validateToken(app) middleware, developers protect downstream API endpoints by requiring incoming requests to possess valid, cryptographically verified tokens.

In versions of the library prior to 2.3.0, a structural flaw exists in how the middleware handles service-to-service communication. To allow legitimate internal systems to interact without token validation, a dedicated trusted peer exception was implemented. However, this exception relies entirely on client-controlled values, establishing an authentication bypass vulnerability classified as CWE-290 (Authentication Bypass by Spoofing).

Because the middleware does not perform cryptographic validation of the client's identity when triggering this exception, any network adversary can exploit this pathway. An unauthenticated remote attacker can easily assume the identity of a trusted internal component, bypassing all authentication mechanisms. This access compromises the confidentiality and integrity of any API route secured by the module.

The root cause of the vulnerability lies within the validateToken function inside the auth.js module of @acastellon/auth version 2.2.0. The middleware attempts to authorize requests from a trusted internal service identity designated as service-brother using non-cryptographic attributes retrieved directly from the HTTP request context.

Specifically, the application parses the auth-user custom header and compares it against the hardcoded literal 'service-brother'. Simultaneously, the code retrieves the request's Host header via req.get('host') and asserts that it matches the configured server hostname or CNAME value returned by getHostName(). If both conditions are evaluated as true, the execution flow is immediately redirected to the Express next() function.

This logic represents a critical security failure because both the auth-user and Host headers are fully controlled by the client. The middleware trusts these attributes implicitly without validating the client's actual network boundary or cryptographic signature. Consequently, an attacker can supply these values arbitrarily, satisfying the conditional logic and preventing the subsequent token verification block from executing.

To understand the precise differences in execution flow, we compare the vulnerable implementation in version 2.2.0 with the corrected logic introduced in version 2.3.0. The patch replaces the insecure header evaluation with cryptographic Mutual TLS (mTLS) certificate verification and introduces mandatory sanitization for incoming request headers.

The vulnerable code path completely trusts incoming headers and passes them down the middleware chain. This allows an attacker to not only bypass token validation but also inject arbitrary user parameters or roles such as is-admin: true directly into the request headers. These headers are subsequently trusted by downstream route handlers.

The patched implementation in version 2.3.0 introduces the sanitizeIncomingAuthHeaders function, which runs first in the middleware lifecycle. This function explicitly deletes the client-supplied auth-user header and any headers starting with the is- prefix. Following sanitization, the middleware utilizes checkMtlsServiceAuth to perform secure authentication. This function retrieves the peer certificate from the TLS socket and validates the Common Name (CN) against an authorized list, injecting the authenticated context only after verifying the transport-layer identity.

Exploitation of GHSA-GFJ5-979R-92PW does not require specialized tooling, active session tokens, or pre-existing credentials. The attack surface is exposed to any network entity capable of issuing HTTP requests to the target microservice endpoint.

An attacker begins by identifying an API route protected by the vulnerable version of the library. They then construct an HTTP request that mimics the trusted peer service. By manually crafting the headers, the attacker supplies 'service-brother' in the auth-user header and specifies the target's public-facing CNAME or hostname in the standard Host header.

GET /api/v1/protected-resource HTTP/1.1
Host: target-api.example.com
auth-user: service-brother
is-admin: true
Connection: close

Upon receipt, the @acastellon/auth middleware matches the header values against the hardcoded conditions. Because the condition is met, the code immediately invokes next(). The unsanitized is-admin: true header is preserved, allowing the attacker to interact with the target microservice with administrative privileges.

The impact of this vulnerability is classified as Critical, as reflected by its CVSS v4.0 score of 9.3. The flaw permits complete authorization bypass, rendering cryptographic tokens, session states, and directory-service mappings (such as NTLM/LDAP) entirely ineffective.

Because downstream microservices in a distributed architecture often trust headers forwarded by gateway middleware, the absence of header sanitization in @acastellon/auth version 2.2.0 exposes internal APIs to privilege escalation. Attackers can control the context variables used by the application to enforce role-based access control (RBAC).

This vulnerability can lead to unauthorized data exfiltration, system state modification, and full takeover of the application interface. If the target endpoint exposes administrative actions, the unauthenticated attacker can execute state-changing operations without leaving standard audit trails.

The primary remediation step is upgrading the @acastellon/auth dependency to version 2.3.0 or higher. This update removes the insecure header-based bypass mechanism, implements header sanitization, and shifts the peer validation architecture to Mutual TLS (mTLS).

To secure internal service-to-service communication, developers must configure the application to utilize client certificates. The updated middleware reads the peer certificate from the incoming socket connection and verifies that the Common Name (CN) matches one of the authorized values listed in the TRUSTED_MTLS_SERVICES configuration array.

const auth = require('@acastellon/auth')({
  TRUSTED_MTLS_SERVICES: ['trusted-gateway', 'internal-worker']
});

For environments where immediate dependency updates are not feasible, temporary mitigation can be implemented at the API Gateway or reverse proxy layer. Administrators should construct rewrite rules to drop incoming auth-user headers and any headers prefixed with is- at the external perimeter. This prevents external clients from injection attacks against the internal context.