Debian DSA-6480-1: OpenStack Keystone Auth Bypass and Information Disclosure — Patching, Detection, and Token Abuse Hunting Guide

Debian has published DSA-6480-1, a security update for Keystone, the identity and access management service at the heart of every OpenStack cloud. The advisory addresses multiple vulnerabilities that can result in authorization bypass or information disclosure. For the stable distribution (Debian 13 trixie), these flaws are fixed in package version 2:27.0.0-3+deb13u5.

If you operate OpenStack on Debian — whether a private cloud, a CI/CD platform, a research cluster, or a hosted customer environment — this is not a routine maintenance item. Keystone is the trust anchor for your entire cloud: it issues tokens, enforces policy, and federates identity for Nova, Neutron, Glance, Cinder, Swift, and every other service. A flaw in Keystone doesn't compromise one service; it compromises the authorization boundary of the whole platform.

Bottom line: identify every Debian trixie host running keystone, patch to 2:27.0.0-3+deb13u5 immediately, rotate service credentials and tokens, and hunt for anomalous token issuance and policy changes that may have predated the fix.

Why Keystone Is a High-Value Target

In over a decade of responding to cloud and infrastructure intrusions, identity services are consistently where attackers go once they have any foothold at all. Keystone specifically holds:

• The token store — Fernet or UUID tokens that grant bearer access to every other OpenStack API.
• The service catalog — a map of every endpoint in the cloud, invaluable for internal reconnaissance.
• User, project, domain, and role assignments — the entire RBAC model of the environment.
• Federation mappings — trust relationships into enterprise IdPs (SAML, OIDC, LDAP).

An authorization bypass here means an attacker with a low-privilege account — or in some configurations, mere network reachability to the Keystone API — can potentially assume roles or project scopes they were never granted. The information disclosure component compounds this: user enumeration, project metadata, or catalog details handed to an unauthenticated or under-privileged caller dramatically shortens the reconnaissance phase of a cloud intrusion.

Technical Analysis

Affected Products and Versions

Debian's advisory tracks this under DSA-6480-1; upstream OpenStack security notes typically map these fixes to specific Keystone bug fixes in the Epoxy/2025 release line. Operators running Keystone from source, from distro packages on Ubuntu, or from RDO/Kolla containers should cross-check their own channels — the underlying upstream fixes may apply to them even though this DSA is Debian-specific.

How the Vulnerability Class Works (Defender's Perspective)

Debian advisories of this type — "multiple vulnerabilities... may result in authorisation bypass or information disclosure" — almost always trace back to weaknesses in one of three Keystone code paths:

1. Policy enforcement gaps. Keystone evaluates API requests against policy.yaml (or the policy database). Flaws in how specific API paths — application credentials, trust creation, group membership, federated mapping lookups — invoke the policy engine can let a request execute an action the caller's roles should never permit.
2. Token scope confusion. Bugs in token validation (Fernet payload parsing, scope checks on project/domain trust tokens, or trust redelegation) can allow a token minted for one scope to be honored for another.
3. Overly permissive read paths. Listing or showing users, groups, projects, or credentials without adequate filtering leaks identity metadata to callers who should only see their own records — the classic information disclosure pattern.

Exploitation requires network access to the Keystone API (traditionally port 5000 for the public/v3 interface; the legacy admin port 35357 should already be disabled on any modern deployment). Depending on the exact flaw, exploitation may require only a valid low-privilege user account — which in a multi-tenant or self-service cloud is trivial to obtain. That is what elevates the severity: the barrier to entry is low and the blast radius is the entire cloud.

Exploitation Status

At the time of publication, there is no confirmed in-the-wild exploitation campaign publicly attributed to these specific fixes, and Debian DSAs of this nature are frequently shipped proactively against upstream-disclosed bugs. That said, Keystone flaws of the auth-bypass class are historically attractive precisely because exploitation blends into legitimate API traffic — there is no crashing service, no obvious payload, just API calls that succeed when they shouldn't. Treat the absence of public PoC as a patching window, not a safety guarantee.

Detection & Response

Keystone attacks are, at their core, API-log and configuration-integrity problems. Your detections should focus on (a) anomalous behavior against the identity API, and (b) unauthorized changes to the Keystone policy and configuration surface, which is how an attacker who gained partial access would convert it into durable control.

Sigma Rules

The following rules target the most reliable host-side observables for Keystone compromise: tampering with the policy/config tree (privilege persistence) and Keystone processes spawning unexpected children (post-exploitation via the service account).

---
title: OpenStack Keystone Policy or Configuration File Modification
id: 8f2c1a4e-3b6d-4a91-9c7e-5d0b2f8a1c34
status: experimental
description: Detects modification of Keystone policy, configuration, or credential files. Unauthorized changes to policy.yaml or keystone.conf can weaken RBAC enforcement, enable auth bypass, or plant persistence following exploitation of identity service flaws such as those addressed in Debian DSA-6480-1.
references:
  - https://linuxsecurity.com/advisories/debian/debian-dsa-6480-1-keystone
  - https://attack.mitre.org/techniques/T1098/
author: Security Arsenal
date: 2026/06/12
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1098
logsource:
  product: linux
  category: file_event
detection:
  selection_paths:
    TargetFilename|startswith:
      - '/etc/keystone/policy'
      - '/etc/keystone/keystone.conf'
      - '/etc/keystone/credential-keys/'
      - '/etc/keystone/fernet-keys/'
      - '/etc/keystone/sso/'
      - '/etc/keystone/domains/'
  filter_package_ops:
    Image|endswith:
      - '/apt'
      - '/apt-get'
      - '/dpkg'
      - '/unattended-upgrade'
  condition: selection_paths and not filter_package_ops
falsepositives:
  - Legitimate cloud-admin configuration changes and Ansible/ Puppet runs; whitelist your configuration-management tooling
level: high
---
title: OpenStack Keystone Process Spawning Unexpected Child Process
id: 3d9e6b21-7a4f-4c58-b2d1-9e0f5a7c3b68
status: experimental
description: Detects the Keystone identity service (keystone-manage, uwsgi or Apache workers serving Keystone) spawning shells or command interpreters. Keystone is a pure Python API service and should never spawn interactive shells; this behavior is a strong post-exploitation indicator.
references:
  - https://linuxsecurity.com/advisories/debian/debian-dsa-6480-1-keystone
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/06/12
tags:
  - attack.execution
  - attack.t1059
logsource:
  product: linux
  category: process_creation
detection:
  selection_parent:
    ParentImage|endswith:
      - '/keystone-manage'
      - '/uwsgi'
      - '/apache2'
      - '/httpd'
  selection_parent_user:
    ParentUser:
      - 'keystone'
      - 'www-data'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/base64'
  filter_apache_children:
    ParentCommandLine|contains:
      - 'keystone-wsgi'
      - 'mod_wsgi'
    Image|endswith:
      - '/apache2'
      - '/httpd'
  condition: (selection_parent or selection_parent_user) and selection_child and not filter_apache_children
falsepositives:
  - Rare administrative wrapper scripts; review parent command lines for mod_wsgi/keystone-wsgi context before tuning out
level: critical

KQL Hunting (Microsoft Sentinel / Defender)

Keystone runs on Linux, so your hunting is only as good as your log ingestion. If you forward host syslog and — critically — Keystone's own application logs (/var/log/keystone/keystone.log plus the Apache/uwsgi access logs for the API vhost) into Sentinel via the Syslog/CEF connector or a custom table, the following queries hunt for token-issuance anomalies and identity-enumeration bursts consistent with auth-bypass and info-disclosure abuse.

// Hunt 1: Burst of token issuance from a single source IP against the Keystone v3 API.
// Auth-bypass abuse typically shows as rapid /v3/auth/tokens calls, often with mixed
// success codes, as the attacker probes which scopes they can mint.
let threshold = 30;
Syslog
| where TimeGenerated > ago(24h)
| where SyslogMessage has_any ("/v3/auth/tokens", "keystone")
| extend SrcIP = extract(@"(\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b)", 1, SyslogMessage)
| where isnotempty(SrcIP)
| summarize TokenCalls = count(), DistinctPaths = dcount(SyslogMessage) by SrcIP, bin(TimeGenerated, 5m)
| where TokenCalls >= threshold
| order by TokenCalls desc;

// Hunt 2: Identity enumeration — excessive list/show operations on users, groups,
// projects, or credentials, consistent with information disclosure abuse.
Syslog
| where TimeGenerated > ago(24h)
| where SyslogMessage has_any ("/v3/users", "/v3/groups", "/v3/projects", "/v3/credentials", "/v3/domains")
| extend SrcIP = extract(@"(\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b)", 1, SyslogMessage)
| where isnotempty(SrcIP)
| summarize EnumCalls = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by SrcIP, bin(TimeGenerated, 10m)
| where EnumCalls >= 50
| order by EnumCalls desc;

// Hunt 3: Non-package processes writing to the Keystone configuration tree,
// surfaced via auditd/syslog forwarding.
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has_any ("/etc/keystone/policy", "keystone.conf", "fernet-keys", "credential-keys")
| where SyslogMessage has_any ("syscall=open", "name=", "writable", "O_WRONLY", "O_RDWR")
| where SyslogMessage !has_any ("apt", "dpkg", "unattended-upgrade", "ansible", "puppet")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc;

Tune the thresholds to your environment's baseline. A busy self-service cloud may legitimately mint dozens of tokens per minute from automation IPs — the signal is the deviation from baseline, not the absolute count. Build a watchlist of known CI/CD and orchestration source IPs and subtract them.

Velociraptor VQL

For endpoint hunts across your Keystone controller nodes, this artifact inventories the identity service's security posture: the integrity of the policy/config tree, recent modifications, and the Keystone package version — giving you both a compromise-assessment sweep and a patch-compliance check in one collection.

-- DSA-6480-1 Keystone hunt: config integrity, package version, and listening services
-- Collect on all OpenStack controller / identity nodes

-- Section 1: Keystone package version (expect 2:27.0.0-3+deb13u5 or later on trixie)
SELECT * FROM execve(argv=['dpkg-query', '-W', '-f=${Version}', 'keystone'])

-- Section 2: Recent modifications to the Keystone configuration and policy tree.
-- Anything newer than your last authorized change window warrants review.
SELECT FullPath, Mtime, Size, Mode
FROM glob(globs=['/etc/keystone/**', '/etc/apache2/sites-enabled/*keystone*'])
WHERE NOT IsDir
ORDER BY Mtime DESC

-- Section 3: Confirm Keystone API listeners and their owning processes.
-- The legacy admin port 35357 should NOT be listening on any modern deployment.
SELECT Pid, Name, Address, Port, Status
FROM netstat()
WHERE Port in (5000, 35357)

If you find the package version below 2:27.0.0-3+deb13u5, the node is vulnerable — prioritize it. If you find port 35357 listening, that is an independent hardening failure regardless of this advisory: the admin API surface should be unified behind port 5000 with policy enforcement.

Remediation and Verification Script

Run this on every Debian trixie host in the Keystone role. It reports the installed version, applies the security update, restarts the service cleanly, and verifies the fix landed.

#!/bin/bash
# DSA-6480-1 Keystone remediation — Debian 13 (trixie)
# Expected fixed version: 2:27.0.0-3+deb13u5
set -euo pipefail

FIXED_PREFIX="2:27.0.0-3+deb13u5"

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

if [ "$CURRENT" = "NOT_INSTALLED" ]; then
    echo "[-] keystone package not installed on this host. Nothing to do."
    exit 0
fi

echo "[*] Installed version: $CURRENT"

if dpkg --compare-versions "$CURRENT" ge "$FIXED_PREFIX" 2>/dev/null; then
    echo "[+] Already at or above fixed version. Verify no pending security updates below."
else
    echo "[!] VULNERABLE. Applying DSA-6480-1 update..."
    apt-get update
    apt-get install --only-upgrade -y keystone python3-keystone keystone-common 2>/dev/null \
        || apt-get install --only-upgrade -y keystone
fi

echo "[*] Verifying final version..."
FINAL=$(dpkg-query -W -f='${Version}' keystone)
echo "[*] Final version: $FINAL"
dpkg --compare-versions "$FINAL" ge "$FIXED_PREFIX" \
    && echo "[+] PASS: DSA-6480-1 fix is applied." \
    || { echo "[-] FAIL: still below fixed version. Investigate apt sources."; exit 1; }

echo "[*] Restarting Keystone services (adjust unit names to your deployment)..."
systemctl restart apache2 2>/dev/null || systemctl restart keystone 2>/dev/null || true

echo "[*] Post-patch hygiene recommendations:"
echo "    1. Revoke outstanding tokens: keystone-manage token_flush (or revoke via API)"
echo "    2. Rotate the service account passwords in keystone.conf for Nova/Neutron/Glance/Cinder"
echo "    3. Audit policy.yaml for unauthorized changes since your last known-good config"
echo "    4. Confirm port 35357 is NOT listening: ss -tlnp | grep 35357"
echo "    5. Review /var/log/keystone/keystone.log for anomalous 200/201 responses on admin-scoped calls predating the patch"

Remediation Checklist

1. Patch immediately. Update all trixie Keystone nodes to 2:27.0.0-3+deb13u5 per DSA-6480-1. Identity services are internet-adjacent by design — do not wait for a change window that spans weeks.
2. Invalidate existing tokens. Patching closes the hole; it does nothing about tokens that may have been minted under the vulnerable code. Flush the token table and force re-authentication for interactive users. Accept the operational friction — it is far cheaper than an incident.
3. Rotate service credentials. Rotate the keystone-stored passwords/keys for every OpenStack service user, plus any LDAP bind credentials and federation secrets referenced in Keystone configuration.
4. Audit policy and config integrity. Diff /etc/keystone/policy.yaml (or your policy database), keystone.conf, and the fernet/credential key directories against configuration management. Any delta you cannot attribute to an authorized change is an IR trigger.
5. Reduce the attack surface. Confirm the legacy admin endpoint (port 35357) is disabled, restrict API reachability with security groups/host firewalls to known consumers, and place Keystone behind a TLS-terminating reverse proxy with request logging.
6. Verify logging is actually capturing identity events. Before you need it: confirm Keystone access and audit logs flow to your SIEM. Mid-incident is the wrong time to discover your controllers only forward syslog.
7. Check non-Debian consumers of the same upstream code. Ubuntu, RDO, and source/container-based deployments of the same Keystone release line may carry the same flaws under different trackers. Inventory your entire OpenStack estate, not just the Debian boxes.

Final Assessment

DSA-6480-1 does not arrive with a headline CVE, a public exploit, or a KEV listing — and that is exactly why advisories like this get deprioritized, and exactly why they shouldn't be. Authorization bypass in an identity provider is the vulnerability class that turns a minor foothold into total cloud compromise. The patch is available, the verification is trivial, and the hunt queries above give you a way to look backward for abuse while you roll the fix forward. Treat identity-service patches as emergency changes. Always.

Related Resources

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