Security update: authentication bypass via encoded path traversal is fixed in Bifrost v2.2.5

We fixed an authentication bypass in the Bifrost HTTP gateway. A request that used percent-encoded dot segments, such as ..%2F, could make a protected route look like a public one. The request then skipped authentication. The fix ships in transports/v2.2.5.

This affects instances where the gateway can be reached by clients you do not trust. Instances on private networks have much lower exposure, because an attacker first needs access to that network. Because a compromised internal host could still send the request, we recommend upgrading those too.

What happened

Bifrost keeps a whitelist of routes that do not need authentication, for example the skills serve endpoint. The auth middleware checked each request path against that list.

fasthttp gives a handler two views of the same path:

• PathOriginal() is the raw path, with percent-encoding intact.
• Path() is the decoded and normalized path, with %2F turned into / and dot segments collapsed.

The fasthttp router dispatches on the raw path. The auth middleware read the normalized one. The two disagreed on what a request was asking for:

• Routing: /api/providers/..%2Fskills%2Fserve%2Fmalicious is one opaque segment. It matches the protected /api/providers/{provider} route.
• Auth check: after decoding, the same request became /api/skills/serve/malicious, which is on the whitelist.

The router sent the request to a protected handler, and the auth check let it through as public.

The fix

The auth middleware now checks the raw path, the same one the router uses. Both components now agree on which route a request targets. We added a regression test that covers:

• The original traversal pattern
• Variations across every whitelisted prefix
• Doubly encoded dot segments
• A check that normal, unencoded whitelisted routes still bypass auth as designed

Encoded traversal requests now return 401 Unauthorized.

Impact

An unauthenticated client that could reach the gateway could call protected management endpoints. Exposure depends on which handler the crafted path lands on. Treat any internet-exposed instance on an earlier version as potentially affected.

Clients that send normal paths are unaffected. There are no breaking changes.

Recommended actions

• Upgrade to transports/v2.2.5. Enterprise customers should upgrade to Enterprise v2.2.5.
• Restrict management ports to trusted networks, and do not expose them to the public internet.
• Set a setup token for new installs. v2.2.5 requires one through BIFROST_SETUP_TOKEN or setup_token in config.json.
• Search access logs for %2f, %2F, or ..%2 in request paths against /api/. Rotate virtual keys if you find hits. Provider keys are safe as we do not send them back in plain text ever.