Rucio CVE-2026-100397: anyone can act as admin, upgrade now

TL;DR

• CVE-2026-100397 is a critical authentication flaw in Rucio, published on November 13, 2026: an attacker with no login can obtain a credential for any account, including an administrator.
• The advisory lists a CVSS v3.1 base score of 9.8, and the weaknesses are CWE-287 (improper authentication) and CWE-305 (authentication bypass by primary weakness).
• The advisory does not state that the flaw is exploited in the wild, but it needs no credentials, so exposed servers should be treated as urgent.
• Fixed releases are 35.9.1, 38.6.1, 40.4.2 and 41.1.1, one per release line.
• Upgrade the package, then review who used your API since the flaw became public.

What the flaw is, in plain English

Rucio is an open source system, installed with pip, that scientific and research organisations use to manage large collections of data files. Its REST API hands out authentication tokens, and clients present a token on each request to prove who they are.

One of those token types is a short-lived challenge used while a user proves they own an SSH key. It is meant as a one-time nonce: a number the server hands out so that the next step of the key exchange cannot be replayed. The server produces it from an account name supplied in a request header, and it does that before anyone has authenticated.

The problem is that both kinds of token live together in one database table, and the routine that validates a token never distinguishes between them. So a challenge token passes as a login. The GitHub advisory GHSA-x585-4vv8-2mh2 describes the result: an unauthenticated attacker can ask for a challenge token for any account, an administrative one included, and then present it as a credential against other API endpoints. The token only lives for a very short time, but nothing stops an attacker from asking for a fresh one whenever they need it.

In other words, there is no password to guess, no key to steal and no foothold needed. If the API is reachable, the attacker can ask to be the administrator and be treated as one.

Why it matters now

Three things make this one worth acting on quickly rather than at the next maintenance window.

• Severity. The advisory rates it critical with a CVSS v3.1 base score of 9.8. That score reflects a flaw reachable over the network, needing no privileges and no user interaction, with high impact on confidentiality, integrity and availability.
• The advisory is public. It was published on November 13, 2026 and it explains the mechanism clearly. Once the way in is public, the gap between disclosure and attempts shrinks.
• Administrator access to a data system. Whoever impersonates an administrator can read, change or remove what the system manages and can create other accounts to keep access after you patch. Patching closes the door, but it does not remove anything already planted.

This is the kind of finding that tends to hide in a dependency list. Rucio is a Python package, so it is often installed into a virtual environment or a container image by one team, and the team that owns the network or the vulnerability programme may not know it is there. Our guide to upgrading a vulnerable dependency safely covers the same habits for npm, and most of them carry over to Python.

Am I affected?

You are affected if you run the Rucio server package from one of these ranges (each range excludes its upper version):

• from 1.14.0.post1 up to 35.9.1
• from 36.0.0rc1 up to 38.6.1
• from 39.0.0rc1 up to 40.4.2
• from 41.0.0rc1 up to 41.1.1

Anything at or above the fixed release of its own line is not affected by this advisory. The flaw is in the server side authentication code, so a machine that only runs a client is not the main concern, though it is worth checking what it talks to.

To check one machine by hand, activate the environment the service runs in and ask pip for the installed version:

pip show rucio

pip list

If Rucio runs in a container, run the same command inside the container, because the version in the image is what counts, not anything on the host. In a project repository, look for rucio in requirements.txt, pyproject.toml or the lock file, and note the pinned version.

Also find where the API is reachable. A server that is only open to a private network is exposed to fewer people than one on the internet, but an attacker who is already inside the network, or a compromised workstation, is exactly who this flaw helps. Do not treat internal as safe.

How to fix Rucio CVE-2026-100397

1. List every Rucio installation you own: servers, virtual environments, container images and repositories. Write down the version and the release line of each.
2. Upgrade each installation to the fixed release of its own line: 35.9.1, 38.6.1, 40.4.2 or 41.1.1. Choose the newest line your deployment supports, since older lines get fewer fixes. For a pip install, use pip install --upgrade rucio or pin the exact fixed version in your requirements file and reinstall.
3. Rebuild and redeploy any container image that bundles Rucio, then restart the service so the new code is the code that runs.
4. Run pip show rucio again in each place and confirm the version is the fixed release or later.
5. Review your API access logs from before the upgrade. Look for requests that used a token for an account that did not make the request, administrator actions at odd times, and accounts or credentials you do not recognise. If you find any, treat the system as compromised: rotate secrets, review accounts and restore from a known good state where needed.
6. If you cannot upgrade immediately, restrict network access to the API to the clients that need it until you can. This reduces exposure but does not fix the flaw, and it is a stopgap only.

The advisory does not describe a configuration setting that switches the behaviour off, so we do not suggest one. Upgrading is the fix.

How to check with Stackurity

Doing the inventory by hand works for one server. It does not work when Rucio sits in several repositories, images and virtual environments owned by different teams.

Stackurity keeps one live inventory of the software on your servers, deployed applications, repositories and container images, and matches it against new vulnerability advisories every hour. A Python library such as Rucio is found in the repositories you add (PyPI is among the supported ecosystems) and in the libraries your deployed applications actually load. When the advisory matches, the finding names the package, where it is installed and the version to move to, and the fix groups every place that needs the same upgrade. The remediation documentation explains how fixes are ordered, most urgent first.

After you upgrade, Check again asks for a fresh report and records whether the issue is really gone, so you do not have to take a ticket status on trust. There are limits: Stackurity does not cover appliance firmware or libraries copied into an application outside a package manager, so a vendored copy of Rucio would need a manual check.

Start a free trial of Stackurity to see which of your repositories and servers use an affected Rucio.

FAQ

What is CVE-2026-100397?

It is a critical authentication flaw in Rucio, the Python data management package. A short-lived token meant only for an SSH key exchange is accepted as a normal login credential, and anyone can request one for any account, so an attacker with no login can act as an administrator.

Which Rucio versions are affected?

Releases from 1.14.0.post1 up to 35.9.1, from 36.0.0rc1 up to 38.6.1, from 39.0.0rc1 up to 40.4.2, and from 41.0.0rc1 up to 41.1.1 are affected, in each case excluding the upper version.

Which Rucio version fixes it?

Move to the fixed release of your own line: 35.9.1, 38.6.1, 40.4.2 or 41.1.1. If you are not tied to an older line, the newest of these is the simplest choice.

Is CVE-2026-100397 being exploited?

The advisory we used does not say it is exploited in the wild, and we do not know of an entry in the CISA catalogue for it. It needs no login and no special access, so treat it as urgent anyway.

Does Stackurity find vulnerable Rucio installs?

Stackurity matches advisories against the Python libraries found in your repositories and the libraries your deployed applications load, so a Rucio dependency in either place can be flagged. It does not inspect appliance firmware or libraries copied into an application outside a package manager.

Sources: GitHub Advisory Database, GHSA-x585-4vv8-2mh2.