high CVSS 8.8

CVE-2026-29080·MySQL vulnerability

A SQL injection vulnerability in `FilterEngine.create_sqla_query()` allows any authenticated Rucio user to execute arbitrary SQL against the backend database through the DID search endpoint (`GET /dids/<scope>/dids/search`). On Oracle deployments attacker-controlled filter keys and values are interpolated directly into `sqlalchemy.text()` via Python `.format()`, completely bypassing parameterization. This enables full database compromise including extraction of authentication tokens, password hashes, and all managed data identifiers. This affects versions 1.27.0 and later before 35.8.5, 38.5.5, 39.4.2, and 40.1.1. The vulnerability exists in `lib/rucio/core/did_meta_plugins/filter_engine.py` within the `create_sqla_query()` method. When the database dialect is Oracle, filter expressions for JSON metadata columns are constructed using `text()` with Python string formatting. Both `key` and `value` are attacker-controlled strings derived from HTTP query parameters. The `text()` function creates a raw SQL fragment — it does **not** escape or parameterize its contents. Any authenticated Rucio user can exploit this through the DID search API to execute arbitrary SQL against the backend database. This can expose all managed data identifiers and sensitive tables such as identities, tokens, accounts, rse_settings, and rules, and may allow modification of database contents. The issue affects Oracle deployments using the default json_meta plugin and does not affect PostgreSQL or MySQL deployments using that plugin. This vulnerability has been fixed in versions 35.8.5, 38.5.5, 39.4.2, and 40.1.1.

Severity
high
Software
MySQL
Fixed in
40.1.1
Published
2026-05-06

Affected versions

From: 40.0.0

Until: 40.1.1

Fixed in: 40.1.1

How to fix this CVE

Update Rucio to version 40.1.1 or later to eliminate the SQL injection vulnerability in the DID search filter engine. Organizations running Oracle deployments with Rucio versions 40.0.0–40.1.0 should prioritize this patch, as authenticated users can execute arbitrary SQL queries against the backend database. Apply the update immediately and verify the patched version is running in production.

sudo dnf update rucio-40.1.1 || sudo dnf install rucio-40.1.1

Defensia detects this vulnerability

What an exploitation attempt looks like

Sample log line indicative of exploitation attempts:

POST|GET /dids/[^/]+/dids/search.*[?&](key|value|filter)=.*((union|select|insert|update|delete|drop|create|alter|exec|execute|script|../|OR|AND|1=1|--|;)[\s\S]*?)

WAF mitigation (if patching is not yet possible)

Add this rule to your WAF to block exploitation attempts while you schedule the patch. 

Block or rate-limit requests to GET /dids/*/search endpoints that contain SQL keywords (UNION, SELECT, INSERT, UPDATE, DELETE, EXEC, OR, AND) in query parameters. Implement IP-based access controls to restrict DID search API access to trusted internal clients only. Enforce authentication token validation and log all API calls for forensic analysis.

How to check if you are affected

  1. Check Rucio version: rpm -qa | grep rucio or dpkg -l | grep rucio — confirm the installed version is between 40.0.0 and 40.1.0 (inclusive)
  2. Verify database backend: grep -r 'oracle' /etc/rucio/rucio.cfg — confirm Oracle is the configured database dialect to determine actual exposure
  3. Search application logs for DID search API calls with suspicious filter parameters: grep -i 'GET /dids/.*/search' /var/log/rucio/access.log | grep -E '(union|select|insert|update|delete|exec|script)' — look for SQL keywords in query parameters
  4. After patching, re-verify version: rpm -qa | grep rucio or dpkg -l | grep rucio — confirm version 40.1.1 or later is installed, then restart Rucio: sudo systemctl restart rucio

FAQ

What is CVE-2026-29080?

CVE-2026-29080 is a SQL injection vulnerability in Rucio's DID (Data IDentifier) search filter engine that allows authenticated users to bypass parameterized queries on Oracle databases and execute arbitrary SQL commands. This can lead to unauthorized data access, credential theft, and database modification.

Is CVE-2026-29080 being actively exploited?

No, CVE-2026-29080 is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no public exploits have been disclosed. However, the ease of exploitation via an authenticated API call makes proactive patching essential.

What versions of Rucio are affected by CVE-2026-29080?

Rucio versions 40.0.0 through 40.1.0 are affected when deployed with Oracle as the backend database. Earlier major versions (35.x, 38.x, 39.x) have already been patched in their respective update releases (35.8.5, 38.5.5, 39.4.2).

How do I check if my server is vulnerable to CVE-2026-29080?

Run: rucio --version or grep -E 'version|VERSION' /etc/rucio/rucio.cfg — if you see 40.0.0 to 40.1.0 and your database backend is Oracle (check rucio.cfg for sqlalchemy_conn), your deployment is vulnerable.

Does Defensia detect CVE-2026-29080?

Yes — Defensia's CVE advisory scanner compares installed package versions against the NVD database. If Rucio is installed on a monitored server, CVE-2026-29080 will appear in your dashboard with remediation steps.

References

Track CVEs across your fleet automatically

Defensia scans your Linux servers and tells you exactly which ones are running vulnerable versions — including CVE-2026-29080. Free for 1 server.

Get started free