Rucio metadata query SQL injection boundary batch¶

Sources: GitHub Security Advisories published 2026-05-06 16:42-16:45 UTC.

Why this matters¶

Rucio DID search filters are user-facing query builders. Two critical advisories show how metadata filter paths can become raw SQL execution when filter keys/values are interpolated into database-specific query fragments instead of being bound parameters.

Advisory summary¶

Impact model¶

• Any authenticated Rucio user may reach the DID search endpoint; no admin role is required.
• Database read access can expose identities, weak password hashes/salts, active tokens, accounts, storage endpoint settings, and rule metadata.
• PostgreSQL deployments may be exposed to stacked queries, COPY ... TO/FROM, or COPY ... FROM PROGRAM when database privileges are excessive.
• Oracle deployments may expose PL/SQL/DML paths and elevated database features such as scheduler or network packages if privileges are broad.

Triage now¶

• Upgrade affected Rucio branches to the fixed versions: 35.8.5, 38.5.5, 39.4.2, or 40.1.1.
• Identify metadata plugin/database combinations:
• PostgreSQL + postgres_meta is affected.
• Oracle + default json_meta is affected.
• PostgreSQL/MySQL default json_meta is not covered by the Oracle JSON path issue per advisory metadata, but still deserves query-builder review.
• Rotate active Rucio tokens if exploitation is plausible; SQLi impact includes token theft.
• Review database roles for dangerous privileges such as PostgreSQL superuser, pg_execute_server_program, filesystem COPY rights, Oracle scheduler execution, Java stored procedures, and outbound network packages.

Hunt prompts¶

• Search Rucio access logs for unusual GET /dids/<scope>/dids/search filter keys/values containing quotes, comment markers, stacked-query separators, JSON path operators, COPY, UNION, DBMS_, UTL_, or timing probes.
• Inspect database audit logs for queries generated by DID search that contain literal user-controlled fragments instead of placeholders/bind variables.
• Look for abnormal reads from identities, tokens, accounts, rse_settings, and rules after DID search requests.
• Correlate low-privilege user tokens with unusually broad metadata queries or database errors.

Durable controls¶

• Query builders must represent user filters as an AST and compile exclusively to parameterized expressions; no str.format, f-strings, or string concatenation for SQL fragments.
• Treat filter keys as untrusted, not only values. Map accepted keys through a strict allowlist before query compilation.
• Run database roles with least privilege: no program execution, no filesystem read/write, no scheduler/network packages for application query users.
• Add dialect-specific SQLi tests for metadata search paths, especially JSON path and plugin-specific branches.
• Store password hashes with a modern KDF; SQL injection is worse when extracted hashes are cheap to crack.