Application credentials of other users can be deleted when knowing the ID

Bug #1901207 reported by Arjen on 2020-10-23
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Lance Bragstad
OpenStack Security Advisory

Bug Description

While performing a penetration test on a new OpenStack install of version Train, we found a vulnerability that could lead to a Denial of Service condition. Using an installation of DevStack we verified that the issue is still present.

In the test situation we had two, separate, projects, each with their own user. Users were only authorised for their own project, not for the other's project.

After creating an application credential for user A, we were able to delete that credential with user B by issuing the OpenStack application credential delete command with the credential ID as parameter.

Apparently, there is no authorisation check on the delete (and show) action and anyone who knows the credential ID can remove it, potentially creating a Denial of Service attack on the affected project.

- Logged in user (user B)
- Knowing the ID of an application credential of another user (user A)

Discovered on October 8, 2020 by Arjen Zijlstra (<email address hidden>) and Arthur Donkers (

Arjen (arjentz) on 2020-10-23
description: updated
description: updated
description: updated
Jeremy Stanley (fungi) wrote :

Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security
reviewers for the affected project or projects confirm the bug and
discuss the scope of any vulnerability along with potential

Changed in ossa:
status: New → Incomplete
description: updated
Jeremy Stanley (fungi) wrote :

In the past, OpenStack's vulnerability managers have considered exploit scenarios requiring the malicious actor to guess or otherwise obtain version 4 UUIDs for resources to which they're not entitled as impractical and safe to discuss in public, class C1 in our report taxonomy:

Are there unusual circumstances for this report which should require private discussion under embargo instead?

Arjen (arjentz) wrote :

Not from our side.

Gage Hugo (gagehugo) wrote :

C1 seems appropriate here, alongside making this public.

Jeremy Stanley (fungi) wrote :

I have switched this bug to public, treating it as a security hardening opportunity pending further insights from reviewers.

description: updated
information type: Private Security → Public
Changed in ossa:
status: Incomplete → Won't Fix
tags: added: security

Fix proposed to branch: master

Changed in keystone:
assignee: nobody → Lance Bragstad (lbragstad)
status: New → In Progress
Changed in keystone:
importance: Undecided → High
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers