CVE-2026-40293

What it actually does

OpenFGA versions 0.1.4 through 1.13.1 can disclose the configured preshared API key in the unauthenticated HTML response from the /playground endpoint when three conditions are true: preshared-key authentication is enabled, the built-in playground remains enabled, and the playground is reachable outside localhost or another trusted network. Because the disclosed value is an API authentication secret, an attacker who can retrieve it may authenticate to OpenFGA APIs as a trusted client and interact with authorization stores and relationship tuples according to the permissions associated with that key. The issue is an information disclosure with potential integrity impact because leaked credentials can enable unauthorized API use.

Why it matters to the business

If an exposed OpenFGA playground leaks the preshared API key, an attacker may gain unauthorized access to the authorization service that applications rely on for permission decisions. This can lead to disclosure or manipulation of authorization data, incorrect access decisions in dependent applications, incident response costs, and loss of trust in access-control enforcement. The current EPSS is low and there is no known CISA KEV listing or ransomware association, but the exposure is simple to test over the network and should be prioritized wherever OpenFGA is internet-accessible or reachable from untrusted networks.

How an attack unfolds

An attacker first identifies an OpenFGA service with the playground endpoint exposed, typically by probing for /playground over HTTP or HTTPS. If the instance is running an affected version, uses preshared-key authentication, and has the playground enabled, the server returns an HTML page that includes the preshared API key. The attacker extracts the key from the page source or network response, then uses it in API requests to OpenFGA. With a valid key, the attacker can query authorization data and potentially create, modify, or delete authorization model and relationship data depending on the OpenFGA API surface and deployment configuration. The attack requires no prior authentication, no user interaction, and low complexity, but only applies to deployments that exposed a development/debugging endpoint beyond trusted boundaries.

How to fix it

Upgrade OpenFGA to version 1.14.0 or later, which remediates the key disclosure behavior. If immediate upgrade is not possible, disable the playground by starting OpenFGA with `--playground-enabled=false`. Production deployments should not expose the playground to the internet or untrusted networks; restrict access with network controls, bind administrative/debug endpoints to localhost or private management networks, and block external access to /playground. Rotate any preshared API keys that may have been exposed, because once the endpoint was reachable the secret should be considered compromised. Review OpenFGA stores, authorization models, and relationship tuples for unauthorized changes after key rotation.

How to confirm the fix worked

Confirm the deployed OpenFGA version is 1.14.0 or later, or verify the service is started with `--playground-enabled=false`. From an untrusted network path, request `/playground` and confirm it is inaccessible, disabled, blocked, or does not include any preshared key material in the response body. Validate that OpenFGA API calls using the previous preshared key fail after rotation. Review service configuration to ensure `--authn-method preshared` deployments do not expose development endpoints beyond localhost or trusted networks. Network scanners and application tests should check for externally reachable OpenFGA playground pages and flag affected versions up to and including 1.13.1.

Typical attack path

1. Discover an OpenFGA service reachable over the network.
2. Request the unauthenticated /playground endpoint.
3. Inspect the returned HTML or JavaScript for the embedded preshared API key.
4. Use the leaked key as the API credential for OpenFGA requests.
5. Query authorization stores, models, or relationship tuples, and potentially modify authorization data where API access allows.
6. Leverage altered or exposed authorization data to support broader application access or persistence.

How to detect it

To determine whether exploitation already occurred, review HTTP access logs from OpenFGA, reverse proxies, ingress controllers, API gateways, load balancers, and web application firewalls for unauthenticated requests to `/playground`, especially from external or unexpected source IPs. Correlate any `/playground` access with subsequent OpenFGA API requests using preshared-key authentication from the same IP address, user agent, autonomous system, or time window. Look for unusual calls that read or modify stores, authorization models, relationship tuples, or check/write APIs shortly after a playground request. Examine OpenFGA application logs for store creation, model write, tuple write, tuple delete, or other administrative activity that does not align with expected deployment workflows. If request-body logging is available, inspect for unexpected authorization API operations after the suspected disclosure. Because the exposed secret appears in an HTTP response rather than a server-side error, absence of explicit error logs does not prove the key was not leaked; focus on access logs, response sizes, endpoint hits, and follow-on authenticated API activity. Rotate keys before deeper investigation to prevent continued use of any exposed credential.

• GET /playground
• POST /playground
• /playground
• --authn-method preshared
• --playground-enabled=true
• --playground-enabled=false
• OPENFGA_PLAYGROUND_ENABLED=true
• openfga run
• Authorization: Bearer
• Authorization: Basic
• /stores
• /authorization-models
• /write
• /check
• /expand
• /read

What your security team should do

• Inventory OpenFGA deployments and identify any running versions 0.1.4 through 1.13.1.
• Prioritize remediation for instances using `--authn-method preshared` with `/playground` reachable from the internet, partner networks, shared internal networks, or other untrusted segments.
• Upgrade affected instances to OpenFGA 1.14.0 or later.
• Disable the playground in production using `--playground-enabled=false`, even after upgrading, unless there is a controlled operational need.
• Block or restrict access to `/playground` at load balancers, reverse proxies, ingress controllers, firewalls, and service meshes.
• Rotate preshared OpenFGA API keys for any deployment where `/playground` may have been reachable.
• Search access logs for historical requests to `/playground` and investigate follow-on OpenFGA API activity from the same source addresses.
• Review authorization models and relationship tuples for unexpected changes during the exposure window.
• Prefer stronger, centrally managed authentication patterns over long-lived preshared keys where supported by the deployment architecture.