CVE-2026-90460: OpenStack Keystone Delegated Authentication Privilege Escalation — Debian DSA-6554-1 Patching and Detection Guide

Debian has issued security advisory DSA-6554-1 addressing CVE-2026-90460, a vulnerability in the handling of delegated authentication in Keystone, the identity service that underpins every OpenStack cloud. The flaw can result in information disclosure and unauthorized privilege gain — two outcomes that, in an identity service, are about as bad as it gets. Keystone is the trust anchor for your entire OpenStack deployment: it issues tokens, enforces roles, and brokers access to Nova, Neutron, Cinder, Glance, and every other service in the catalog. An attacker who can abuse Keystone's delegated authentication (trusts and impersonation mechanisms) to gain privileges they were never granted effectively owns the cloud.

For the stable distribution (trixie, Debian 13), the issue is fixed in version 2:27.0.0-3+deb13u6. If you run OpenStack control-plane nodes on Debian — whether a production private cloud, a lab, or a managed hosting environment — treat this as a priority patch. Identity-plane vulnerabilities have a long history of being quietly weaponized after disclosure because they rarely trip traditional perimeter controls; the abuse looks like legitimate API traffic.

Technical Analysis

Affected Products and Versions

• Product: Keystone (OpenStack Identity Service)
• Distribution: Debian 13 "trixie" (stable)
• Vulnerable: Keystone packages prior to 2:27.0.0-3+deb13u6
• Fixed: 2:27.0.0-3+deb13u6
• CVE: CVE-2026-90460
• Advisory: Debian DSA-6554-1 (https://linuxsecurity.com/advisories/debian/debian-dsa-6554-1-keystone)

A CVSS score was not published in the Debian advisory text at the time of writing. However, the impact pairing — information disclosure plus unauthorized privilege gain in the identity service — warrants treatment as a high-severity issue regardless of the eventual numeric score. Identity-plane bugs punch above their CVSS weight because they bypass, rather than trigger, most detection layers.

How the Vulnerability Works

Keystone supports delegated authentication — most notably the OS-TRUST (trusts) API and impersonation flows — which allow one user (the trustor) to delegate a constrained subset of their roles to another user or service (the trustee). This is the mechanism that lets Heat orchestrate resources on a user's behalf, or lets automation act with scoped credentials after the original user session ends.

The flaw lives in how Keystone validates or constrains these delegation relationships. When the trust-scoping logic is mishandled, a trustee (or a caller abusing a delegated token) can obtain authorization scope beyond what the trustor actually delegated — i.e., privilege gain — and read identity data they should not have access to — i.e., information disclosure. From a defender's perspective, the exploitation characteristics matter more than the exact code path:

• Exploitation requires API access. The attacker needs network reachability to the Keystone API (typically TCP/5000 on the public endpoint, TCP/35357 on legacy admin endpoints) and, most realistically, a low-privilege authenticated identity. This makes it a classic insider-threat / post-compromise lateral escalation primitive: an attacker who phishes one developer's cloud credentials, or pops a single tenant workload, can pivot to broader authorization scope.
• Abuse looks like legitimate traffic. There is no memory corruption, no malformed packet, no obvious exploit signature. The malicious request is a syntactically valid call to the Keystone v3 API (/v3/OS-TRUST/trusts, token issue/validate endpoints). Detection must therefore be behavioral and audit-log-driven, not signature-driven.
• Blast radius is the whole cloud. Elevated Keystone scope means the ability to enumerate projects/users (information disclosure), create tokens, spin up instances, attach volumes, and modify networks across tenants.

Exploitation Status

As of publication, there is no confirmed public proof-of-concept, no CISA KEV listing, and no confirmed in-the-wild exploitation reported alongside DSA-6554-1. That should not breed complacency. Debian advisories of this type typically follow upstream OpenStack embargoed fixes, and the window between advisory publication and researcher/attacker analysis of the patch diff is reliably short. Identity-service diffs are especially easy to reverse into a working exploit because the trust/token code paths are well documented and consistently deployed. Patch before the diff gets weaponized.

Detection & Response

Because exploitation is valid-API-call abuse, your detection surface is Keystone's own logging (and the WSGI/Apache access logs in front of it) shipped to your SIEM. If you are not already centralizing /var/log/keystone/keystone.log and Apache access.log/error.log from your controller nodes, that is your first gap — close it this week.

Focus hunting on:

1. Trust creation and trust-scoped token issuance anomalies — spikes in POST /v3/OS-TRUST/trusts, trusts created with broad or admin-equivalent roles, or trusts created by accounts that have never used the delegation API before.
2. Privilege-gain patterns — role assignments (PUT /v3/projects/.../roles/...), token validation events where the effective scope exceeds the trustee's standing roles, and successful POST /v3/auth/tokens calls carrying trust IDs from unusual source IPs.
3. Enumeration behavior — high-volume GET requests against /v3/users, /v3/projects, /v3/role_assignments, and /v3/domains from a single identity or IP, consistent with the information-disclosure side of the bug.

SIGMA Rules

---
title: OpenStack Keystone Trust API Abuse - Excessive Trust Creation
description: Detects spikes or unusual usage of the Keystone OS-TRUST delegated authentication API, consistent with abuse of CVE-2026-90460 delegated authentication handling for unauthorized privilege gain. Baseline before tuning; legitimate orchestration (e.g. Heat) creates trusts routinely.
author: Security Arsenal
date: 2026/04/06
references:
  - https://linuxsecurity.com/advisories/debian/debian-dsa-6554-1-keystone
logsource:
  product: linux
  service: syslog
detection:
  selection:
    - 'POST /v3/OS-TRUST/trusts'
    - 'POST /v3/auth/tokens'
  filter_legit_orchestration:
    - 'service user'
    - 'heat'
  condition: selection and not filter_legit_orchestration
falsepositives:
  - Legitimate use of trusts by Heat orchestration, Magnum, or custom automation
  - Cloud administrators performing delegation testing
level: medium
---
title: OpenStack Keystone Identity Enumeration Activity
description: Detects high-volume enumeration of Keystone identity resources (users, projects, role assignments, domains) consistent with the information disclosure component of CVE-2026-90460 or reconnaissance following privilege gain via delegated authentication abuse.
author: Security Arsenal
date: 2026/04/06
references:
  - https://linuxsecurity.com/advisories/debian/debian-dsa-6554-1-keystone
logsource:
  product: linux
  service: syslog
detection:
  selection:
    - 'GET /v3/users'
    - 'GET /v3/projects'
    - 'GET /v3/role_assignments'
    - 'GET /v3/domains'
    - 'GET /v3/roles'
  condition: selection
falsepositives:
  - Horizon dashboard normal operation
  - Infrastructure-as-code tools (Terraform OpenStack provider) refreshing state
  - Monitoring and inventory scripts
level: low
---
title: OpenStack Keystone Role Assignment Modification
description: Detects grant or revocation of roles on projects/domains via the Keystone v3 API. Privilege escalation through delegated authentication flaws such as CVE-2026-90460 commonly manifests as unexpected role assignment changes granting broader scope.
author: Security Arsenal
date: 2026/04/06
references:
  - https://linuxsecurity.com/advisories/debian/debian-dsa-6554-1-keystone
logsource:
  product: linux
  service: syslog
detection:
  selection_put:
    - 'PUT /v3/projects/'
    - 'PUT /v3/domains/'
  selection_roles:
    - '/roles/'
  condition: selection_put and selection_roles
falsepositives:
  - Cloud administrators managing project membership
  - Automated provisioning pipelines assigning default roles
level: medium

KQL (Microsoft Sentinel)

This query assumes Keystone and Apache/WSGI logs are ingested via Syslog or CEF from your controller nodes. It hunts for trust-API usage combined with role assignment changes from the same source — the classic privilege-escalation-via-delegation pattern.

// Keystone delegated authentication abuse hunt (CVE-2026-90460)
// Correlates OS-TRUST API usage with role assignment modifications from the same source IP
let timeframe = 24h;
let TrustActivity =
    Syslog
    | where TimeGenerated > ago(timeframe)
    | where SyslogMessage has_any ("OS-TRUST/trusts", "/v3/auth/tokens")
    | extend SourceIP = extract(@"(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})", 1, SyslogMessage)
    | where isnotempty(SourceIP)
    | summarize TrustCalls = count(),
                FirstTrustCall = min(TimeGenerated),
                LastTrustCall = max(TimeGenerated) by SourceIP;
let RoleChanges =
    Syslog
    | where TimeGenerated > ago(timeframe)
    | where SyslogMessage has "/roles/" and SyslogMessage has_any ("PUT /v3/projects/", "PUT /v3/domains/")
    | extend SourceIP = extract(@"(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})", 1, SyslogMessage)
    | where isnotempty(SourceIP)
    | summarize RoleChanges = count(),
                SampleMessages = take_any(SyslogMessage, 3) by SourceIP;
TrustActivity
| join kind=inner RoleChanges on SourceIP
| project SourceIP, TrustCalls, RoleChanges, FirstTrustCall, LastTrustCall, SampleMessages
| order by TrustCalls desc;

A complementary single-source query for enumeration behavior:

// Keystone identity-plane enumeration hunt
Syslog
| where TimeGenerated > ago(1h)
| where SyslogMessage has_any ("GET /v3/users", "GET /v3/projects", "GET /v3/role_assignments", "GET /v3/domains")
| extend SourceIP = extract(@"(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})", 1, SyslogMessage)
| where isnotempty(SourceIP)
| summarize EnumCalls = count(), DistinctEndpoints = dcount(SyslogMessage) by SourceIP, Computer
| where EnumCalls > 100
| order by EnumCalls desc;

Tune the threshold against your baseline — Horizon and Terraform will show up here, so maintain an allowlist of known automation IPs before enabling alerting.

Velociraptor VQL

For endpoint-side verification on controller nodes, this artifact inventories the installed Keystone package version and enumerates Keystone processes and their network listeners — useful both for patch-state verification at scale and for confirming the service exposure surface.

-- Keystone patch-state and exposure hunt (CVE-2026-90460)
-- Verifies installed keystone package version and maps keystone processes to listeners
LET pkg = SELECT
    "keystone" AS Package,
    expand(path=Version) AS InstalledVersion,
    "2:27.0.0-3+deb13u6" AS FixedVersion
FROM Artifact.Linux.Debian.Packages()
WHERE Package =~ 'keystone'

SELECT * FROM if(
    condition = pkg,
    then = {
        SELECT Package, InstalledVersion, FixedVersion,
               if(condition = InstalledVersion >= FixedVersion,
                  then = "PATCHED", else = "VULNERABLE") AS Status
        FROM pkg
    },
    else = {
        SELECT Pid, Name, CommandLine, Username
        FROM pslist()
        WHERE Name =~ 'keystone' OR CommandLine =~ 'keystone'
    })

Remediation Script

The following Bash script verifies the installed Keystone version against the fixed release, applies the update on Debian trixie, restarts the relevant services, and performs a post-patch sanity check. Run it on every controller/identity node, ideally via your configuration management tooling.

#!/usr/bin/env bash
# CVE-2026-90460 / DSA-6554-1 Keystone remediation and verification
# Target: Debian 13 (trixie) OpenStack controller nodes
set -euo pipefail

FIXED_VERSION="2:27.0.0-3+deb13u6"

echo "[*] Checking installed keystone package version..."
INSTALLED=$(dpkg-query -W -f='${Version}' keystone 2>/dev/null || echo "not-installed")

if [ "$INSTALLED" = "not-installed" ]; then
    echo "[+] keystone is not installed on this host. Nothing to do."
    exit 0
fi

echo "[*] Installed: $INSTALLED | Fixed: $FIXED_VERSION"

if dpkg --compare-versions "$INSTALLED" ge "$FIXED_VERSION"; then
    echo "[+] Already patched. Version $INSTALLED >= $FIXED_VERSION"
else
    echo "[!] VULNERABLE. Updating keystone..."
    apt-get update
    apt-get install -y --only-upgrade keystone python3-keystone
    echo "[+] Package updated. Restarting Keystone services..."
    # Keystone typically runs under Apache2/mod_wsgi; restart both paths defensively
    systemctl restart apache2 2>/dev/null || true
    systemctl restart keystone 2>/dev/null || true
fi

echo "[*] Post-patch verification..."
NEW_VERSION=$(dpkg-query -W -f='${Version}' keystone)
if dpkg --compare-versions "$NEW_VERSION" ge "$FIXED_VERSION"; then
    echo "[+] CONFIRMED PATCHED: keystone $NEW_VERSION"
else
    echo "[!!!] PATCH FAILED. Installed version is still $NEW_VERSION"
    exit 1
fi

echo "[*] Keystone API health check..."
if curl -s -o /dev/null -w "%{http_code}" http://localhost:5000/v3 | grep -qE "200|300"; then
    echo "[+] Keystone v3 API responding on :5000"
else
    echo "[!] WARNING: Keystone API did not respond as expected. Investigate service state."
fi

echo "[*] Checking for legacy admin endpoint exposure (port 35357)..."
if ss -tlnp | grep -q ':35357'; then
    echo "[!] WARNING: Legacy admin port 35357 is listening. It should be disabled in production."
else
    echo "[+] No legacy admin endpoint exposure detected."
fi

echo "[+] Done. Review /var/log/keystone/keystone.log and Apache logs for pre-patch abuse indicators."

Remediation

1. Patch immediately. Update all Debian trixie systems running Keystone to 2:27.0.0-3+deb13u6: apt-get update && apt-get install --only-upgrade keystone python3-keystone, then restart the WSGI host (typically Apache2) so the patched code is actually loaded. Updating the package without restarting the service leaves you vulnerable.
2. Patch all identity nodes. Keystone is almost always deployed redundantly behind a load balancer. Verify every controller — a single unpatched node behind the VIP is a fully exploitable endpoint.
3. Audit trust relationships now. Enumerate existing trusts (openstack trust list) and role assignments. Look for trusts you cannot attribute to a known service (Heat, Magnum) or workflow, trusts carrying admin-equivalent roles, and trustees with unexpectedly broad project scope. Delete anything unaccounted for.
4. Rotate credentials on suspicion. If your log review surfaces anomalous trust creation or role assignment activity predating the patch, treat it as an incident: revoke the implicated tokens, rotate service account passwords, invalidate Fernet/UUID token caches by restarting Keystone, and scope a forensics review of API logs going back to your earliest retained data.
5. Reduce the attack surface permanently. Ensure the Keystone public endpoint (5000) is not internet-exposed unless your architecture explicitly requires it; place it behind an authenticated reverse proxy or VPN where possible. Confirm the legacy admin endpoint (35357) is disabled. Enforce MFA-backed external IdP federation for human users so a single phished password cannot reach the API at all.
6. Centralize identity-plane logging. Ship Keystone and Apache access logs to your SIEM with at least 12 months retention. Identity-service intrusions are discovered late; you will need the history.
7. Track the advisory. Monitor DSA-6554-1 and the upstream OpenStack security advisory for follow-on details, a published CVSS vector, or additional fixed versions for other OpenStack components in the same release train.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub