Debian Patches

Status for keystone/2:27.0.0-3+deb13u5

Patch Description Author Forwarded Bugs Origin Last update
keystone-bug-2119646-stable-2025.1.patch Add service user authentication to ec2 and s3 endpoints Add a policy to enforce authentication with a user in the service
group. This maintains AWS compatibility with the added security
layer.

===================================================================		 Grzegorz Grasza <xek@redhat.com> yes upstream https://bugs.launchpad.net/keystone/+bug/2119646 2025-10-30
CVE-2026-33551~OSSA-2026-005_Prevent_unauthorized_EC2_credential_creation_and_deletion.patch Prevent unauthorized EC2 credential creation and deletion A restricted application credential could be used to create EC2
credentials granting full user access to S3, bypassing the role
restriction. Add the same _check_unrestricted_application_credential
guard that already protects application credential create/delete
endpoints.
.
Additionally, tighten the ec2_create_credential and ec2_delete_credential
policies to require at least member role, as these are write operations
that should not be accessible to reader-role users regardless of whether
they are using an application credential.

diff --git a/keystone/api/users.py b/keystone/api/users.py
index b3ec13f..f614f1c 100644		 Grzegorz Grasza <xek@redhat.com> yes debian upstream upstream, https://review.opendev.org/c/openstack/keystone/+/983589 2026-04-10
install-missing-files.patch install missing files Thomas Goirand <zigo@debian.org> not-needed 2019-08-18
do-not-set-chartset-in-flask-responce.patch Do not set charset in flask responce
===================================================================		 Thomas Goirand <zigo@debian.org> no 2024-01-22
set-deprecation-warnings-to-ignore.patch Set deprecation warnings to ignore Otherwise, Keystone FTBFS in Unstable. Thomas Goirand <zigo@debian.org> no 2025-03-13
api_Remove_constraints_on_user_IDs.patch api: Remove constraints on user IDs Per the comment added inline, this is not valid when LDAP is in use.

===================================================================		 Stephen Finucane <stephenfin@redhat.com> yes upstream upstream, https://review.opendev.org/c/openstack/keystone/+/951282 2025-05-20
CVE-2026-40683-OSSA-2026-007-fix_ldap_enabled_setting_not_interpreted_as_boolean.patch OSSA-2026-007: fix ldap 'enabled' setting not interpreted as boolean interpretation of the ldap enabled attribute as boolean
is only done if enabled_invert setting is set to true.

diff --git a/keystone/identity/backends/ldap/core.py b/keystone/identity/backends/ldap/core.py
index 5ddf14d..fd09c7c 100644		 Benedikt Trefzer <benedikt.trefzer@cirrax.com> yes debian upstream upstream, https://review.opendev.org/c/openstack/keystone/+/982408 2026-04-15
0001-Add-tests-for-restricted-app-cred-guard.patch [PATCH 1/5] Add tests for restricted app cred guard
Verify that the _check_unrestricted_application_credential guard on
the OS-EC2 credential create endpoint blocks restricted application
credentials from creating EC2 credentials, while still allowing
unrestricted application credentials to do so.

(cherry picked from commit c87ce6ed435f01431343d6b2bb6697a640514d27)		 Boris Bobrov <b.bobrov@sap.com> no 2026-04-07
0002-Block-restricted-app-creds-from-creating-EC2-credent.patch [PATCH 2/5] Block restricted app creds from creating EC2 credentials via /credentials

The POST /v3/credentials endpoint accepted EC2 credential creation
from restricted application credential tokens, bypassing the guard
on the dedicated OS-EC2 endpoint. Add the same unrestricted
application credential check to the generic credentials API for
EC2-type credentials, and update the existing test to use an
unrestricted application credential.

(cherry picked from commit d6a3dc511057d6ac25bd2d75776a4233c5608684)		 Boris Bobrov <b.bobrov@sap.com> no 2026-04-07
0003-Block-app-cred-tokens-from-authorizing-OAuth1-reques.patch [PATCH 3/5] Block app cred tokens from authorizing OAuth1 requests
The OAuth1 authorize endpoint checked is_delegated_auth to block
trust-scoped and OAuth-scoped tokens from authorizing request
tokens, but application credential tokens were not covered by
this check. A restricted application credential could authorize
a request token with any role the user actually holds, producing
an access token that yields an unrestricted Keystone token with
roles beyond the application credential's restricted set.

Add an explicit check for application credential tokens on the
OAuth1 authorize endpoint, consistent with how trust-scoped and
OAuth-scoped tokens are already blocked.

(cherry picked from commit 29246c5fd8d1dafbe6cc8cec4c57faf5590cd44e)		 Boris Bobrov <b.bobrov@sap.com> no 2026-04-07
0004-Enforce-app-cred-project-boundary-on-EC2-credential-.patch [PATCH 4/5] Enforce app cred project boundary on EC2 credential paths
POST /v3/credentials did not validate that the caller-supplied
project_id for an EC2-type credential matched the project of the
authenticating application credential. This allowed an attacker
holding an unrestricted application credential for project A to
create an EC2 credential targeting project B; a subsequent
/v3/ec2tokens exchange would then issue a Keystone token scoped to
project B while still carrying the original app_cred_id, enabling
cross-project lateral movement within the credential owner's role
footprint.

Two fixes:

1. credentials.py: after extracting app_cred_id from the token,
check that credential['project_id'] == app_cred['project_id']
for EC2-type credentials and raise ForbiddenAction otherwise.

2. EC2_S3_Resource.py: in handle_authenticate(), assert that the
stored EC2 credential project_id matches the application
credential's project before issuing the token.

This issue is orthogonal to CVE-2026-33551 (LP#2142138 / Gerrit
983655), which blocks restricted application credentials from
creating EC2 credentials at all. The project-boundary check is
absent regardless of the restricted flag and requires separate
treatment.

(cherry picked from commit b6fd80996b882890a51f3e2aab41d952d7ff68ae)
(cherry picked from commit d9e18a37888cabdea919c58b24f630fd722aa8b0)		 Grzegorz Grasza <xek@redhat.com> no 2026-04-22
0005-Use-branch-constraints-for-tempest-venv-on-stable-20.patch [PATCH 5/5] Use branch constraints for tempest venv on stable/2025.1
The stable/2025.1 gate is completely broken for all Keystone changes.
The grenade, grenade-skip-level, k2k federation, and other devstack-
based jobs fail during configure_tempest because tox creates a 'venv'
environment using master's upper-constraints.txt, which pins
Sphinx===9.0.4. This conflicts with tempest's doc/requirements.txt
(sphinx>=2.0.0,!=2.1.0), producing a ResolutionImpossible error from
pip. No Keystone code executes before the failure.

Fix this by setting TEMPEST_VENV_UPPER_CONSTRAINTS to the branch-
specific constraints file from the locally cloned requirements repo.
DevStack already supports this: when the variable is set to a file
path (not "master"), set_tempest_venv_constraints in lib/tempest
reads the file and exports UPPER_CONSTRAINTS_FILE pointing to it.
The cloned requirements repo on each branch has a compatible Sphinx
pin, eliminating the resolution conflict.

For grenade jobs, the variable is set via grenade_devstack_localrc
(shared) so it applies to both old-side and new-side devstack. On
the old side (stable/2024.2), $DEST expands to /opt/stack/old and
the requirements repo is cloned from stable/2024.2. On the new side,
$DEST is /opt/stack/new with stable/2025.1 constraints. Both have
Sphinx pins compatible with their respective tempest versions.

This is a standalone CI configuration change, separate from change
988237 (the EC2 credential policy fix that was blocked by this gate
failure).		 "Dave Wilde (d34dh0r53)" <dwilde@redhat.com> no 2026-05-19
CVE-2026-43001-2025.1.v4.patch [PATCH 1/5] Enforce delegation project boundary for delegated tokens Delegated tokens (trusts, application credentials, OAuth1 access tokens)
are scoped to a single project at delegation time. This must be enforced
thoroughly while granting the API access to Keystone resources that
might be also bound to a single project. Without this it is possible to
gain different access (using trust to see application credentials for a
different project, reuse the MFA seed, etc).
.
* Credentials CRUD (/v3/credentials)
.
All five CRUD operations verified ownership via user_id but did not bind
credential.project_id to the delegating token's project scope.
.
Fix: _check_credential_project_scope() - no-op for non-delegated tokens,
raises ForbiddenAction on project mismatch. For list, out-of-scope
credentials are silently filtered.
.
Credentials with project_id=None (TOTP/MFA bindings) are treated as
out-of-scope for any delegated token: they are user-level secrets with no
project anchor, and a delegated token should never be able to enumerate,
read, or mutate them - doing so would allow a stolen delegation token to
exfiltrate or destroy a user's MFA binding.
.
* OS-EC2 credential CRUD (/v3/users/{id}/credentials/OS-EC2)
.
POST accepted any tenant_id from a delegated token. GET and DELETE had
no delegation check at all.
.
Fix: _check_delegation_for_ec2() enforces the project boundary;
list silently filters.
.
Additionally, pre-existing OAuth1 access-token-backed EC2 credentials
with a mismatched project_id could be used at auth-time (POST /v3/ec2tokens)
to obtain a cross-project token. Added a check in EC2_S3_Resource.py that
cred_data['project_id'] matches access_token['project_id'] before issuing
the token. The trust branch does not need this check - the token provider
uses the trust's project regardless of the credential's project_id.
.
* OS-OAUTH1 access token management (/v3/users/{id}/OS-OAUTH1/access_tokens)
.
GET and DELETE had no delegation check. List blocked trust/OAuth but not
app-cred tokens.
.
Fix: _block_delegated_token() raises Forbidden for any delegation type
on list, get, and delete.
.
* Application credential management (/v3/users/{id}/application_credentials)
.
Trust-scoped and OAuth1 tokens had no guard on the application credential
and access rule management APIs. An impersonating trust could LIST, CREATE,
or DELETE application credentials, creating a persistent backdoor that
outlives the trust's own expiry. App credential tokens are intentionally
excluded - the unrestricted/restricted distinction is handled separately by
_check_unrestricted_application_credential.
.
Fix: _block_delegated_token_app_creds() raises Forbidden for trust-scoped
and OAuth1 tokens on all six app credential and access rule endpoints.

===================================================================		 Grzegorz Grasza <xek@redhat.com> yes debian upstream upstream, https://bugs.launchpad.net/keystone/+bug/2150089 2026-05-26
CVE-2026-80182_CVE-2026-80184_1_Block_app_credential_token_rescoping.patch Ban ec2credential tokens from Keystone API
EC2 credentials are supported by Keystone only to allow Swift to
implement S3 protocol while using Keystone identities. There are no real
reasons for ec2credential fernet tokens (after authenticating) being
accepted by the Keystone itself. There are many barriers where
Keystone explicitly checks and bans such credentials to prevent
rescoping or accessing resources belonging to other projects. There
have been multiple security issues due to missing guards. Instead of
those individual barriers, simply bar such tokens from any Keystone
operation except validating the token (which Swift needs to do) and
re-authenticating (renewing the token). The latter is questionable on
its own, but is kept for now.

Solve the problem by simply rejecting the ec2credential issued token
in the auth middleware which runs before any authenticated request.
The /auth/tokens are unauthenticated and as such are not affected.		 Artem Goncharov <artem.goncharov@gmail.com> no 2026-07-15
CVE-2026-80182_CVE-2026-80184_2_auth_encode_ec2credential_and_oauth2_credential_in_the_method_bitmask.patch auth: encode ec2credential and oauth2_credential in the method bitmask
convert_method_list_to_integer() builds its map from CONF.auth.methods,
so a method name absent from that list is silently dropped and the
result is 0, which convert_integer_to_method_list() turns back into
an empty list.

'ec2credential' (keystone.api._shared.EC2_S3_Resource) and
'oauth2_credential' (keystone.api.os_oauth2) are written into
token.methods by endpoints that are not auth plugins, so they cannot
be listed in CONF.auth.methods: load_auth_methods() would look for a
keystone.auth.<name> entry point that does not exist, and the name
would become client-requestable on POST /v3/auth/tokens. Neither has
ever survived the fernet round-trip.

Master already ships the EC2 API ban (910ebab06) which rejects
tokens with 'ec2credential' in token.methods. Without this round-trip
fix that check never sees the method on a fernet token, so the ban
is a no-op for issued tokens.

Reserve fixed high bits for both so they round-trip. High and fixed
means they never collide with the sequential indexes and adding one
never shifts an existing index, so tokens in circulation stay
decodable.

This does not fix tokens already issued: they carry the integer 0
and still decode to an empty list.		 Benjamin Pinchon <benjamin.pinchon@corp.ovh.com> no 2026-08-25
CVE-2026-80182_CVE-2026-80184_3_trusts_oauth1_app-creds_reject_delegated_tokens_across_all_endpoints.patch trusts, oauth1, app-creds: reject delegated tokens across all endpoints

_check_application_credential() in trusts.py only recognized
'application_credential' in token.methods, so OAuth1 access-token-scoped
and ec2credential-derived tokens were never blocked from creating,
listing, reading, or deleting trusts -- unlike application_credential,
which has had this restriction since LP#2148477.

Two more endpoints that mint a new persistent grant had the same gap:

- users.py's _block_delegated_token_app_creds (guarding application
credential and access-rule CRUD) only checked trust_id/access_token_id,
so ec2credential-scoped tokens could create, list, read, and delete
application credentials.
- os_oauth1.py's AuthorizeResource.put (PUT /v3/OS-OAUTH1/authorize) only
checked is_delegated_auth (trust/oauth1) and application_credential, so
an ec2credential-scoped token could authorize OAuth1 request tokens.

All three are extended to the same primary-auth-method allowlist used in
credentials.py, users.py, and token.py: any token whose methods aren't
entirely primary auth methods is rejected outright. Trust-scoped tokens
are deliberately not blocked from trust operations on trust_id alone --
that's the trust redelegation feature working as designed (a trustee
creating a further, narrower trust from one they were delegated) and
trustee self-service reads of their own trusts. A trust-scoped token
whose underlying method is itself delegated (an EC2 credential's blob
can embed a trust_id, see keystone.api.credentials._assign_unique_id) is
still caught by the method check regardless of trust scoping.
application_credential keeps its existing, documented opt-in escape
hatch for trust management
(allow_insecure_application_credential_trust_escalation) and its
unrestricted/restricted distinction for creating further application
credentials (_check_unrestricted_application_credential); OAuth1 and EC2
credentials have no such use case and are blocked unconditionally
everywhere.

This also closes off the underlying role-escalation path in trust
assignments, not the requesting token's own scoped roles, so a
narrowly-scoped oauth1/ec2 token could previously delegate roles it was
never itself authorized for. Blocking those token types from trust
creation removes the path to that gap without needing to touch the
validation itself.

Neither the app-cred nor the OAuth1-authorize gap is reachable on
current master, where a separate middleware change globally rejects any
caller token with 'ec2credential' in its methods before Flask routing --
but that change is not backported to stable branches, so both gaps are
live there. Fixed at the source regardless, so the guard doesn't depend
on an unrelated middleware check remaining in place.

An empty token.methods list (e.g. an ec2credential-derived token that
lost its methods on a fernet cache-miss round-trip -- ec2credential has
no bit in the method bitmask) is also treated as delegated at all three
call sites: _PRIMARY_AUTH_METHODS.issuperset([]) is True, so without this
an empty list would otherwise be accepted as 'all primary'.

Consolidated the three independent _PRIMARY_AUTH_METHODS copies (this
patch, LP#2158538, LP#2159643) into keystone.api._shared.delegation,
per gtema's review comment #16 -- now that all three land together the
NameError-avoidance reason for keeping them separate no longer applies.
Also replaced the hardcoded method list with an operator-extensible one
([auth] additional_primary_auth_methods): a hardcoded allowlist blocks
any third-party auth plugin (e.g. a site-specific SSO integration) from
reauthenticating/managing its own trusts, app-creds, and OAuth1 tokens,
since it can never appear in a list only keystone maintainers can edit.		 Grzegorz Grasza <xek@redhat.com> no 2026-07-23
CVE-2026-80182_CVE-2026-80184_4_auth_reject_delegated_tokens_from_token-method_reauthentication.patch auth: reject delegated tokens from token-method reauthentication

token_authenticate() unconditionally blocks trust-scoped and
OAuth1-scoped tokens from creating another token via the token
method, but application_credential tokens were only blocked from
requesting an explicit scope -- an omitted scope fell through to
the user's default-project scoping, letting an app-cred token
bound to project A come back scoped to the user's default project
B. ec2credential tokens matched no check at all, so they could
rescope via an explicit scope to any project the underlying user
has a role on, not just a default-project fallback.

Both are the same root cause: application credentials and EC2
credentials are deliberately narrow, single-project grants, and the
"token" method's rescoping logic never accounted for that, treating
them like a normal user session that's free to move between any of
its own role assignments.

Block application_credential tokens from this path entirely,
matching trust/OAuth1, using the same shared
keystone.api._shared.delegation classification introduced by
LP#2153453: any token whose methods aren't entirely primary auth
methods (built-in, or operator-registered via
[auth] additional_primary_auth_methods) is rejected outright,
including ec2credential and any future delegated method. An empty
token.methods list (e.g. an ec2credential-derived token that lost its
methods on a fernet cache-miss round-trip) is also treated as
delegated, since issuperset([]) is True and would otherwise be
accepted as 'all primary'.		 Grzegorz Grasza <xek@redhat.com> no 2026-08-24
CVE-2026-80183_Prevent_unauthorized_project-scoped_assignment_list.patch Prevent unauthorized project-scoped assignment list
Any user holding `role:reader` on any project could list all role
assignments under any domain by passing a domain ID as
`scope.project.id` to `GET /v3/role_assignments?include_subtree`.
Domain projects store `domain_id=null`, which matched the `null`
`domain_id` of any project-scoped token in the oslo.policy string
comparison, bypassing the domain-reader restriction. An explicit `not
None:%(target.domain_id)s` guard has been added to the affected policy
rules.

(cherry picked from commit eb27f4e309708746a8e7a5f0ad7e9a510e47ff0b)		 Artem Goncharov <artem.goncharov@gmail.com> no 2026-08-04

All known versions for source package 'keystone'

Links