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
How likely is exploitation
FIRST's Exploit Prediction Scoring System puts the probability of this CVE being exploited in the next 30 days at <0.1% — higher than 17% of all published CVEs. EPSS is an independent forecast of exploitation, not a severity rating: it says nothing about how much damage a successful attack does, which is what a CVSS score measures.
Read the two together. CVE-2026-29080 scores 8.8 on CVSS, so a successful attack would be serious — but at <0.1%, almost nobody is currently attempting it. That is a different situation from a flaw under mass exploitation, and it is usually the difference between patching on your next maintenance window and patching tonight.
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.1Defensia 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
- 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)
- Verify database backend: grep -r 'oracle' /etc/rucio/rucio.cfg — confirm Oracle is the configured database dialect to determine actual exposure
- 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
- 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.
Related MySQL CVEs
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