Security update: CVE-2026-90898 and CVE-2026-86242 are fixed in Bifrost v2.1.0

JFrog Security Research recently disclosed two vulnerabilities in Bifrost's management API. They can only be exploited when both of these are true: the instance is exposed to the internet, and dashboard authentication has not been set up. Both are fixed in transports/v2.1.0.

If you have enabled authentication on your dashboard or your gateway is exposed in private network, you are not impacted by these vulnerabilities.

What happened

CVE-2026-90898 (CVSS 9.8): An unauthenticated request to /api/mcp/client could register an MCP stdio client and run a command on the gateway host.

CVE-2026-86242 (CVSS 8.1): An unauthenticated request could register a custom plugin from an HTTP path. On the official Docker image, this was limited to SSRF. This was fixed in v2.0.0.

Who was affected

Both issues required two conditions at once:

• The Bifrost dashboard and management API were reachable from the internet.
• Dashboard authentication was not set up.

If your instance was on a private network, or you had auth enabled, these paths were not exploitable.

What we already had in place

We shipped without a default password so teams could get Bifrost running in minutes. We expected auth to be set up before a deployment went to production, and we said so in two places:

• Documentation: The Setting up auth guide explains how to password-protect the dashboard and admin API. It is part of the quickstart.
• In-product checklist: On May 20th, we shipped an onboarding widget (commit 997db46). It asks every admin to enable dashboard auth, restrict CORS, enforce auth on inference, and add provider keys. The steps check themselves off based on your live config.

The reports came in July, after both of these were already in place.

The gap, and how we closed it

Guidance and nudges were not enough. Some instances still could end up exposed to the internet with no authentication. That is a gap in our defaults, and we own it.

After working with the JFrog team, we added a setup token. You now have to provide it when you create the first admin account. You configure it ahead of time with setup_token in config.json or with the BIFROST_SETUP_TOKEN environment variable. It is never stored and never logged. If no setup token is configured, Bifrost rejects first-admin creation. A reachable instance can no longer be claimed by whoever finds it first.

How we protect stored keys

• Provider keys and virtual keys are encrypted at rest.
• The encryption key and salt are never stored in the database or in the codebase.
• We never return stored provider keys or Bifrost API keys through any API.

What you should do

If your Bifrost gateway runs on a private network, or you have dashboard auth set up, you don't need to take any immediate action.

• Upgrade to transports/v2.1.0. It fixes both CVEs. Note that v2.0.0 fixes only CVE-2026-86242, and the 1.6.x line (up to 1.6.11) fixes neither.
• Set up auth by following the Setting up auth guide, and configure a setup token.
• Keep the management port off untrusted networks. This matters most for Docker, where the API binds to 0.0.0.0. We are now changing it to 127.0.0.1 if dashboard auth is not set up.
• Rotate your provider API keys and virtual keys as a precaution if your instance was internet-facing with auth disabled.

Thanks to Yuval Moravchik and the JFrog Security Research team for the responsible disclosure and for working with us on the fix.