CVE-2026-106457 in plugin-auth-backend-module-cloudflare-access-provider
Summary
by MITRE • 10/07/2026
Backstage is an open framework for building developer portals. From 0.1.0 until 0.5.0, the @backstage/plugin-auth-backend-module-cloudflare-access-provider package is affected by insufficient audience validation in the cloudflare access auth provider. The Cloudflare Access auth provider verifies a token's signature and team issuer, but affected versions do not verify that the token was issued for the Backstage application. A user holding a valid token for another Access application in the same Cloudflare Zero Trust team may therefore be able to authenticate to Backstage if that token reaches the auth endpoint without the Backstage application's audience already being enforced upstream. Cloudflare Access normally evaluates the protected application before forwarding requests. This issue is fixed in version 0.5.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified within the @backstage/plugin-auth-backend-module-cloudflare-access-provider package affects versions ranging from 0.1.0 to 0.5.0 of Backstage, an open-source framework designed for building developer portals. This specific flaw constitutes a critical authentication bypass mechanism rooted in insufficient audience validation during the token verification process. While Cloudflare Access serves as a robust identity provider that typically enforces strict access policies and application-specific restrictions before forwarding requests to backend services, this particular implementation failed to enforce one of the most fundamental security checks required for OpenID Connect compliant applications: the validation of the intended recipient or audience claim within the JSON Web Token.
Technically, the Cloudflare Access authentication provider implemented in these affected versions correctly verifies the cryptographic signature of the token and confirms that it was issued by a trusted team issuer within the Cloudflare Zero Trust infrastructure. However, the implementation omits the verification of the aud (audience) claim embedded within the token payload. In standard OAuth 2.0 and OpenID Connect flows, the audience field specifies which service or application the access token is intended for. By neglecting to validate that this value matches the specific identifier configured for the Backstage instance, the authentication module accepts any validly signed token from the same Cloudflare team, regardless of whether it was originally issued for a different protected application within that organization's Zero Trust perimeter.
The operational impact of this vulnerability is significant because it allows unauthorized users to gain access to the Backstage developer portal if they possess a valid authentication token intended for another service hosted under the same Cloudflare Access policy. An attacker could potentially exploit this by obtaining a legitimate token from a different application within the organization, such as an internal wiki or documentation site protected by Cloudflare Access, and presenting it directly to the Backstage auth endpoint. If upstream infrastructure does not already enforce audience restrictions before forwarding requests to Backstage, the vulnerable plugin will accept this misdirected token, granting the attacker authenticated access to sensitive developer tools, service catalogs, and potentially underlying system configurations exposed through the portal.
This flaw aligns with CWE-287, which describes Improper Authentication, specifically relating to the failure to verify identity claims correctly during the authentication process. Furthermore, it relates to CWE-345, Insufficient Verification of Data Authenticity, as the application fails to ensure that the received token is authentic for its specific context rather than just cryptographically valid within a broader trust domain. From an ATT&CK perspective, this vulnerability facilitates Initial Access via Valid Accounts, allowing adversaries who have compromised or obtained credentials from one service to pivot into another critical infrastructure component without needing additional credential theft efforts.
The issue was resolved in version 0.5.0 of the Backstage framework by implementing strict audience validation logic within the Cloudflare Access authentication provider. To mitigate this risk for organizations still running affected versions, it is imperative to upgrade to version 0.5.0 or later immediately. For environments where an immediate upgrade is not feasible due to dependency constraints, a temporary mitigation involves configuring upstream reverse proxies or API gateways in front of Backstage to enforce audience validation before requests reach the application backend. This ensures that tokens intended for other services are rejected at the network edge rather than being processed by the vulnerable authentication module. Additionally, organizations should review their Cloudflare Access policies to ensure strict separation between critical infrastructure applications and less sensitive ones where possible, reducing the attack surface available via token reuse.