Skip to main content
A Leader in the 2026 Gartner® Magic Quadrant™ for Endpoint Protection. Six years running.Find Out Why
CVE Vulnerability Database
Vulnerability Database/CVE-2024-53916

CVE-2024-53916: OpenStack Neutron Privilege Escalation

CVE-2024-53916 is a privilege escalation vulnerability in OpenStack Neutron that allows unprivileged tenants to modify network tags without authorization. This article covers technical details, affected versions, and mitigation.

Published:

CVE-2024-53916 Overview

CVE-2024-53916 is a broken access control flaw in OpenStack Neutron, the networking component of the OpenStack cloud platform. The file neutron/extensions/tagging.py uses an incorrect object ID during policy enforcement when handling network tag changes. As a result, the proper policy authorization check is not applied to tag modification requests. An unprivileged tenant can add or clear tags on network objects owned by other tenants. The flaw affects Neutron releases 23 before 23.2.1, 24 before 24.0.2, and 25 before 25.0.1, and is tracked as [CWE-754] Improper Check for Unusual or Exceptional Conditions.

Critical Impact

An authenticated, unprivileged OpenStack tenant can manipulate tags on networks owned by other tenants, breaking cross-tenant isolation and integrity of network metadata.

Affected Products

  • OpenStack Neutron 23.x before 23.2.1
  • OpenStack Neutron 24.x before 24.0.2
  • OpenStack Neutron 25.x before 25.0.1

Discovery Timeline

  • 2024-11-25 - CVE-2024-53916 published to the National Vulnerability Database
  • 2024-12-03 - Issue disclosed on the OpenWall oss-security mailing list via OSSA-2024-005
  • 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2024-53916

Vulnerability Analysis

Neutron exposes a tagging extension that allows tenants to attach metadata tags to networking resources such as networks, subnets, ports, and routers. The tagging logic resides in neutron/extensions/tagging.py. When a tenant submits a request to update or clear tags on a network, the controller is expected to call the OpenStack oslo.policy engine using the target network's identifier so that ownership and role checks can be evaluated against the correct resource.

Instead, the controller passes an incorrect ID into the policy enforcement call. The policy engine therefore evaluates authorization against the wrong object, and the ownership check that would normally reject cross-tenant access does not fire. The request then proceeds and the tag operation is committed to the targeted network.

The consequence is an integrity violation across tenants. Tags are widely used for automation, billing, scheduling hints, and security group selection in many OpenStack deployments. An attacker with any valid project credentials can alter or wipe tags on networks they do not own, which can disrupt orchestration pipelines that rely on those tags.

Root Cause

The root cause is an authorization logic error in the tag change handler in neutron/extensions/tagging.py between lines 138 and 232. The wrong object identifier is supplied to the policy enforcement function, so the update_tags and delete_tags actions are not bound to the actual target network during the policy check.

Attack Vector

The attack is remote and network-based. An attacker only needs valid credentials for any project in the target OpenStack cloud and network reachability to the Neutron API endpoint. The attacker issues a standard PUT or DELETE request against the tagging endpoint of a target network owned by a different tenant. No user interaction and no elevated privileges are required.

See the OpenStack Security Advisory OSSA-2024-005 and the upstream fix on OpenDev for the corrected policy enforcement logic.

Detection Methods for CVE-2024-53916

Indicators of Compromise

  • Neutron API access log entries showing PUT or DELETE requests to /v2.0/networks/{network_id}/tags where the requesting X-Project-Id header does not match the owning project of network_id.
  • Unexpected additions, modifications, or clearing of tags on networks across tenant boundaries.
  • Spikes in update_tags or delete_tags actions in Neutron audit logs originating from low-privilege service accounts.

Detection Strategies

  • Correlate Neutron API request logs with the Neutron database standardattributes and tags tables to flag tag changes initiated by a project that does not own the target network.
  • Enable oslo.policy debug logging temporarily to record which policy rules are evaluated for each tagging request and compare against expected ownership rules.
  • Hunt for anomalous tag churn on production networks using a SIEM, focusing on requests from projects that historically do not interact with those networks.

Monitoring Recommendations

  • Forward Neutron server logs and Keystone authentication events to a centralized log platform with cross-tenant correlation.
  • Alert on any tag modification where the request principal's project ID differs from the network owner's project ID.
  • Track Neutron version inventories across controller nodes to identify hosts still running 23.x, 24.x, or 25.x releases below the fixed point versions.

How to Mitigate CVE-2024-53916

Immediate Actions Required

  • Upgrade Neutron to 25.0.1, 24.0.2, or 23.2.1 or later on all controller nodes running the neutron-server process.
  • Restart neutron-server after upgrading so the patched tagging.py controller is loaded.
  • Audit recent tag changes on production networks and revert any unauthorized modifications.
  • Rotate Keystone credentials for any tenant suspected of abusing the flaw.

Patch Information

The upstream fix is merged in OpenStack Neutron via change 935883 on OpenDev and is included in releases 23.2.1, 24.0.2, and 25.0.1. The patch corrects the identifier passed to policy.enforce in neutron/extensions/tagging.py so authorization is evaluated against the actual target network. Distribution packages from Red Hat, Canonical, and other downstream vendors should be applied where available.

Workarounds

  • If immediate upgrade is not feasible, customize the policy.yaml file for Neutron to restrict update_tags and delete_tags actions to rule:admin_only until the patched version can be deployed.
  • Restrict API access to the Neutron tagging endpoints at the load balancer or API gateway layer for non-admin service accounts.
  • Monitor and alert on all cross-project tag modification attempts until the patch is applied.
bash
# Example Neutron policy override to restrict tag changes to admins
# Append to /etc/neutron/policy.yaml on all controller nodes
"update_tags": "rule:admin_only"
"delete_tags": "rule:admin_only"
"create_tags": "rule:admin_only"

# Restart neutron-server to apply
sudo systemctl restart neutron-server

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.

Try SentinelOne