### Summary
A SQL injection vulnerability exists in Rucio versions 1.30.0 and later before 35.8.5, 38.5.5, 39.4.2, and 40.1.1, in `FilterEngine.create_postgres_query()`. This allows any authenticated Rucio user to execute arbitrary SQL against the PostgreSQL metadata database through the DID search endpoint (`GET /dids/<scope>/dids/search`). When the `postgres_meta` metadata plugin is configured, attacker-controlled filter keys and values are interpolated directly into raw SQL strings via Python `.format()`, then passed to `psycopg3`'s `sql.SQL()` which treats the string as trusted SQL syntax.
Depending on the database privileges assigned to the service account, exploitation can expose sensitive tables, modify or delete metadata, access server-side files, or achieve code execution through PostgreSQL features such as COPY ... FROM PROGRAM. This issue affects deployments that explicitly use the postgres_meta metadata plugin. This vulnerability has been fixed in versions 35.8.5, 38.5.5, 39.4.2, and 40.1.1.
A critical SQL injection vulnerability exists in Rucio versions 1.30.0 through 40.1.0 when using the postgres_meta metadata plugin. Authenticated users can execute arbitrary SQL queries against the PostgreSQL metadata database via the DID search endpoint, potentially exposing sensitive data, modifying metadata, or achieving code execution. This affects data management platforms used in research and enterprise environments, particularly those managing large-scale distributed datasets.
IMMEDIATE ACTIONS:
1. Identify all Rucio deployments using the postgres_meta metadata plugin by checking configuration files for 'postgres_meta' references
2. Restrict network access to the DID search endpoint (/dids/*/dids/search) to trusted internal networks only
3. Review database service account privileges and apply principle of least privilege - remove SUPERUSER, CREATEDB, and file system access permissions
4. Enable PostgreSQL query logging and audit all DID search requests for suspicious filter patterns
PATCHING GUIDANCE:
1. Upgrade immediately to patched versions: 35.8.5, 38.5.5, 39.4.2, or 40.1.1 depending on your current version
2. Test patches in non-production environments first
3. Plan maintenance window for production upgrades
COMPENSATING CONTROLS (if patching delayed):
1. Implement Web Application Firewall (WAF) rules to block SQL injection patterns in filter parameters (detect: UNION, SELECT, DROP, INSERT, UPDATE, DELETE, EXEC, SCRIPT keywords)
2. Use database connection pooling with read-only accounts for the search endpoint
3. Implement input validation at application layer to whitelist allowed filter keys and sanitize values
4. Deploy PostgreSQL row-level security policies to limit data exposure
5. Monitor for exploitation attempts: log all queries containing SQL keywords in filter parameters
DETECTION RULES:
1. Alert on DID search requests with filter parameters containing: SQL keywords (SELECT, UNION, DROP, etc.), SQL comments (--), or special characters (;, ', ")
2. Monitor PostgreSQL slow query logs for unexpected complex queries from Rucio service account
3. Track failed authentication attempts and permission errors in PostgreSQL audit logs
4. Alert on any COPY...FROM PROGRAM or similar file system access attempts
الإجراءات الفورية:
1. تحديد جميع نشرات Rucio التي تستخدم مكون postgres_meta من خلال فحص ملفات التكوين
2. تقييد الوصول إلى نقطة نهاية البحث DID للشبكات الداخلية الموثوقة فقط
3. مراجعة امتيازات حساب خدمة قاعدة البيانات وتطبيق مبدأ أقل امتياز
4. تفعيل تسجيل استعلامات PostgreSQL ومراجعة جميع طلبات البحث عن DID
إرشادات التصحيح:
1. الترقية الفورية إلى الإصدارات المصححة: 35.8.5 أو 38.5.5 أو 39.4.2 أو 40.1.1
2. اختبار التصحيحات في بيئات غير الإنتاج أولاً
3. تخطيط نافذة الصيانة لترقيات الإنتاج
الضوابط البديلة:
1. تطبيق قواعد جدار الحماية لحجب أنماط حقن SQL في معاملات التصفية
2. استخدام حسابات القراءة فقط لنقطة نهاية البحث
3. تطبيق التحقق من صحة المدخلات على مستوى التطبيق
4. نشر سياسات أمان مستوى الصف في PostgreSQL
5. مراقبة محاولات الاستغلال من خلال تسجيل الاستعلامات