CVE-2026-42999: An issue was discovered in OpenStack Keystone before 29.0.2.
An issue was discovered in OpenStack Keystone before 29.0.2. The Keystone RBAC policy enforcer in enforce_call unconditionally merges the raw JSON request body into the policy enforcement dictionary via policy_dict.update(json_input.copy()), overwriting trusted target data that was previously set from database lookups. Because flask.request.get_json is called with force=True, this works regardless of Content-Type or HTTP method. Any authenticated user can inject arbitrary policy target attributes (e.g., user_id, project_id) into the request body to bypass RBAC checks and perform unauthorized operations on resources belonging to other users or projects. This was introduced in commit 5ea59f52 (Rocky/14.0.0).
Security readout for executives and security teams
Plain-English summary
An authenticated OpenStack user may deceive Keystone’s authorization checks by supplying identity or project details that replace trusted database values. This can enable unauthorized actions across users or projects, threatening tenant isolation and exposing data or allowing changes. The issue is remotely reachable and requires only a low-privileged account.
Executive priority
Prioritize remediation for internet-reachable or multi-tenant Keystone deployments. A valid account could potentially bypass tenant boundaries with little complexity, creating material confidentiality and integrity risk. Patch promptly and review recent authorization-sensitive activity; urgency is high, although active exploitation is not established by the supplied sources.
Technical view
Keystone’s enforce_call merges raw JSON input into its policy dictionary after trusted target data is loaded, allowing attacker-controlled fields to overwrite authorization attributes. Forced JSON parsing makes the flaw independent of Content-Type or HTTP method. The supplied CVSS 3.1 score is 8.3, reflecting high confidentiality and integrity impact plus limited availability impact.
Likely exposure
Potentially exposed deployments run Keystone from Rocky/14.0.0 through versions before 29.0.2 and permit untrusted authenticated users to reach Keystone APIs. Risk is greatest in multi-tenant environments because successful abuse can cross user or project boundaries. Confirm distribution-specific package status with the vendor.
Exploitation context
Exploitation requires network access and valid low-level authentication, but no user interaction and low attack complexity. The source bundle does not identify CISA KEV listing or evidence of active exploitation. Treat plausible abuse as cross-tenant authorization bypass, not unauthenticated compromise.
Researcher notes
The defect maps to CWE-639 and CWE-863. Its security boundary failure is ordering: trusted lookup-derived targets are established, then overwritten through policy_dict.update using attacker-controlled JSON. Forced JSON parsing broadens applicable request forms. The bundle attributes introduction to commit 5ea59f52 in Rocky/14.0.0; branch-specific affected and fixed builds require vendor confirmation.
Mitigation direction
Upgrade Keystone to 29.0.2 or a vendor-supported package containing the correction.
Check OpenStack and operating-system vendor advisories for branch-specific fixed packages.
Until corrected, limit Keystone API access to trusted networks and necessary authenticated users.
Review privileged and cross-project operations for evidence of authorization abuse.
Validation and detection
Inventory Keystone versions and identify installations older than 29.0.2.
Confirm the installed distribution package is marked fixed by its vendor.
Test that request-body attributes cannot replace trusted policy target values.
Audit Keystone activity for unexpected cross-user, cross-project, or administrative operations.
Verify tenant-isolation and authorization regression tests pass after remediation.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-639: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
CWE-863: Authorization and privilege behavior lookup
Authorization weaknesses can support privilege escalation and valid-account review, depending on exploit path. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references database injection or access, so collection and exfiltration review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-639 · source CWE mapping
Authorization Bypass Through User-Controlled Key
Authorization Bypass Through User-Controlled Key represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Incorrect Authorization represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.