What is the CVSS score of CVE-2026-48096?

CVE-2026-48096 has a CVSS 3.1 base score of 5.3 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-48096?

Yes, a patch is available for CVE-2026-48096. Update the affected software to the latest version immediately.

OpenFGA CVE-2026-48096

EUVD-2026-36061 MEDIUM

Insufficient Verification of Data Authenticity (CWE-345)

2026-06-10 GitHub_M

GHSA-8396-jffm-qx4w

Information Disclosure Openfga Red Hat

5.3

CVSS 3.1 · NVD

Severity by source

Vendor (GitHub_M) PRIMARY

MEDIUM

qualitative

NVD

5.3 MEDIUM

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Red Hat

5.0 MEDIUM

qualitative

Primary rating from Vendor (GitHub_M).

CVSS VectorNVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

Low

Availability

None

Lifecycle Timeline

CVSS changed

Jun 12, 2026 - 00:52 NVD

5.0 (MEDIUM) 5.3 (MEDIUM)

Patch available

Jun 10, 2026 - 17:01 EUVD

Source Code Evidence Fetched

Jun 10, 2026 - 16:41 vuln.today

Analysis Generated

Jun 10, 2026 - 16:41 vuln.today

DescriptionNVD

OpenFGA is an authorization/permission engine built for developers. Prior to version 1.16.0, when iterator caching is enabled, two distinct check requests can produce the same cache key, leading to OpenFGA reusing an earlier cached result for a subsequent request. This issue has been patched in version 1.16.0.

AnalysisAI

Cache key collision in OpenFGA's iterator caching mechanism allows two distinct authorization check requests to resolve to the same cache key, causing the engine to return a stale, incorrect authorization result to a subsequent requester. All OpenFGA deployments prior to version 1.16.0 with iterator caching enabled are affected, specifically when using the experimental weighted_graph_check union resolution path. An authenticated attacker who can trigger authorization checks under conditions that produce a colliding cache key may receive an incorrect allow or deny decision, undermining the integrity and confidentiality of access control enforced by the engine. No public exploit identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.

Technical ContextAI

OpenFGA (cpe:2.3:a:openfga:openfga:*:*:*:*:*:*:*:*) is an open-source authorization engine implementing the Zanzibar relationship-based access control model, widely used as a policy-enforcement backend. The vulnerability resides in the experimental weighted_graph_check resolution path, where result caching was applied at the union node level rather than the individual edge level. Because union nodes aggregate multiple edges that share structural properties across different requests (differing only in object or relation), the cache key construction was insufficiently granular, allowing two logically distinct check requests to map to the same key. This is classified under CWE-345 (Insufficient Verification of Data Authenticity): the engine trusts a cached authorization result without verifying that it was produced for the same effective request context. Additionally, a related race condition allowed in-flight goroutines cancelled by a union short-circuit to write a false result into the cache, which subsequent requests would then consume without hitting the datastore. The root fix (PR #3117) moved caching from union node to individual edge scope; PR #3125 addressed the goroutine cancellation race.

RemediationAI

Upgrade OpenFGA to version 1.16.0 or later; this is the vendor-confirmed patched release per the GitHub advisory GHSA-8396-jffm-qx4w and release notes at https://github.com/openfga/openfga/releases/tag/v1.16.0. The fix restructures cache key granularity at the individual edge level (PR #3117) and resolves the goroutine cancellation race (PR #3125), fully addressing both root causes. If an immediate upgrade is not feasible, disabling iterator caching eliminates the vulnerability surface at the cost of increased datastore query load and higher authorization check latency under concurrent request patterns. Alternatively, disabling the experimental weighted_graph_check feature and falling back to the standard check algorithm avoids the vulnerable code path without disabling caching globally, though this trades off any performance or graph-weighting benefits the experimental feature provided. Deployments not using the weighted_graph_check experimental feature are not affected and do not require emergency action beyond scheduling the standard upgrade.