GHSA-q333-f498-w2x7: Medium severity npm/@backstage/plugin-auth-backend-module-cloudflare-access-provider vulnerability
Impact
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. The reported reproduction exercises the provider directly and does not demonstrate bypass through the ordinary Cloudflare-protected Backstage URL. Relevant deployment topologies include direct origin access, alternate routes around the intended Access application, or another proxy forwarding the assertion unchanged.
A successful sign-in also depends on the deployment's sign-in resolver mapping the presented identity to a Backstage user. The resulting impact depends on the permissions assigned to that identity.
Patches
Upgrade @backstage/plugin-auth-backend-module-cloudflare-access-provider to version 0.5.0 or later. The fixed package is available in Backstage v1.55.0.
This is a breaking configuration change. Before upgrading, set auth.providers.cfaccess.audience to the Audience (AUD) tag for the Backstage application in Cloudflare Zero Trust:
yaml auth: providers: cfaccess: teamName: example audience: ${AUTHCFACCESSAUDIENCE}
Workarounds
- Restrict access to the Backstage auth endpoint to the intended Cloudflare Access application. - Use a custom authenticator that validates the application audience. - Disable the provider until the patched package can be deployed.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/@backstage/plugin-auth-backend-module-cloudflare-access-providerto a version that resolves this vulnerability.Fixed in 0.5.0 - Upgrade
Upgrade
@backstage/plugin-auth-backend-module-cloudflare-access-providerto a version that resolves this vulnerability.Fixed in 0.5.0 - Configuration
Set auth.providers.cfaccess.audience to the Audience (AUD) tag for the Backstage application in Cloudflare Zero Trust before upgrading.
Backstage Cloudflare Access auth provider auth.providers.cfaccess.audience = ${AUTH_CFACCESS_AUDIENCE} - Configuration
Disable the provider until the patched package can be deployed.
Cloudflare Access auth provider provider enabled = false - Compensating control
Restrict access to the Backstage auth endpoint to the intended Cloudflare Access application.
- Compensating control
Use a custom authenticator that validates the application audience.
Event History
Frequently Asked Questions
Which deployments are realistically exposed?
Exposure is most relevant where requests can reach the Backstage auth endpoint without the Backstage application's Cloudflare Access audience being enforced first. Examples include direct origin access, alternate routes that bypass the intended Access application, or another proxy that forwards the Access assertion unchanged.
Can this be exploited through the normal Cloudflare-protected Backstage URL?
Cloudflare Access normally evaluates the protected application before forwarding requests, and the reported reproduction did not demonstrate a bypass through the ordinary Cloudflare-protected Backstage URL. The risk is instead tied to paths that reach the provider directly or otherwise avoid that upstream audience enforcement.
What does an attacker need to authenticate successfully?
The attacker needs a valid Cloudflare Access token issued for another application in the same Cloudflare Zero Trust team and a route that delivers it to the Backstage auth endpoint without Backstage audience validation upstream. The deployment's sign-in resolver must also map the token's identity to a Backstage user.
What should be done if upgrading cannot happen immediately?
Ensure the Backstage auth endpoint is reachable only through the intended Cloudflare Access-protected application and that its audience is enforced before requests are forwarded. Remove or restrict direct-origin and alternate proxy routes that could forward assertions without that enforcement.
How can the issue be remediated?
Upgrade @backstage/plugin-auth-backend-module-cloudflare-access-provider to version 0.5.0 or later. The impact of any successful sign-in depends on the permissions assigned to the mapped Backstage identity.