Skip to content

← Public intelligence

PyPI package

rucio

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. High, CVSS 8.8PyPIAmendedPublished

    rucio has an Authorization Bypass on REST API endpoint for signing URLs

    CVE-2026-58273 · GHSA-5j9r-fx4x-rpvg

    Affected
    • PyPI rucio >= 1.16.1, < 35.9.0; >= 36.0.0rc1, < 38.6.0; >= 39.0.0rc1, < 41.0.0rc1
    Fixed in
    41.0.0rc135.9.038.6.0· Vendor fix available
    Issue
    The `/credentials/signurl` endpoint decides authorization from the client-supplied `X-Rucio-Account` HTTP header instead of the authenticated token's account. Any client holding any valid auth token (even a low-privilege account they legitimately own) can send `X-Rucio-Account: root` to pass the root-only permission check and have the Rucio server mint a presigned read / write / delete URL for an arbitrary object, signed with the RSE's stored S3 / GCS / Swift credentials. Details `SignURL.get()` takes the authorization principal from a request header and never uses the token-authenticated identity: ```python lib/rucio/web/rest/flaskapi/v1/credentials.py account = request.headers.get('X-Rucio-Account', default=None) L165 (attacker-controlled) ... result = get_signed_url(account, rse=rse, service=service, L194 operation=operation, url=url, lifetime=lifetime, vo=vo) ``` The gateway then uses that header value as the `issuer` for the permission check:…

    Recommended action: Upgrade to 41.0.0rc1 (pre-release), 38.6.0 or 35.9.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  2. Critical, CVSS 9.0PyPIAmendedPublished

    Rucio has SQL Injection in FilterEngine PostgreSQL Query Builder via DID Search API

    CVE-2026-29090 · GHSA-6j7p-qjhg-9947

    Affected
    • PyPI rucio >= 1.30.0, < 35.8.5; >= 36.0.0, < 38.5.5; >= 39.0.0, < 39.4.2; >= 40.0.0, < 40.1.1
    Fixed in
    35.8.540.1.139.4.238.5.5· Vendor fix available
    Issue
    A SQL injection vulnerability in FilterEngine.createpostgresquery allows any authenticated Rucio user to execute arbitrary SQL against the configured PostgreSQL metadata database through the DID search endpoint (GET /dids/<scope/dids/search). When the external metadata plugin postgresmeta is configured, attacker-controlled filter keys and values are interpolated directly into raw SQL statements via Python str.format. This enables full database compromise including data exfiltration, data modification, and potential remote code execution via COPY ... FROM PROGRAM. --- Details The vulnerability exists in lib/rucio/core/didmetaplugins/filterengine.py within the createpostgresquery() method (lines 408-484). This method builds raw SQL strings via Python .format() across 6 distinct injection points: filterengine.py:477 (string equality — default branch): filterengine.py:442 (wildcard/LIKE branch): filterengine.py:456 (boolean branch — value unquoted): filterengine.py:462 (numeric…

    Recommended action: Upgrade to 40.1.1, 39.4.2, 38.5.5 or 35.8.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  3. Critical, CVSS 9.4PyPIAmendedPublished

    Rucio has SQL Injection in FilterEngine Oracle JSON Path via DID Search API

    CVE-2026-29080 · GHSA-vjr5-c9qv-hgm3

    Affected
    • PyPI rucio >= 1.27.0, < 35.8.5; >= 36.0.0, < 38.5.5; >= 39.0.0, < 39.4.2; >= 40.0.0, < 40.1.1
    Fixed in
    35.8.540.1.139.4.238.5.5· Vendor fix available
    Issue
    A SQL injection vulnerability in the Oracle path of FilterEngine.createsqlaquery allows any authenticated Rucio user to execute arbitrary SQL against the backend database through the DID search endpoint (GET /dids/<scope/dids/search). Attacker-controlled filter keys and values are interpolated directly into sqlalchemy.text via Python str.format, completely bypassing parameterization. This enables full database compromise including extraction of authentication tokens, password hashes, and all managed data identifiers. The vulnerability is affecting deployments using the default metadata plugin configuration jsonmeta with Oracle database backends. --- Details The vulnerability exists in lib/rucio/core/didmetaplugins/filterengine.py within the createsqlaquery() method. When the database dialect is Oracle, filter expressions for JSON metadata columns are constructed using text() with Python string formatting: filterengine.py:552 (string equality — default branch):…

    Recommended action: Upgrade to 40.1.1, 39.4.2, 38.5.5 or 35.8.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →