CVE-2026-100397: Rucio: Unauthenticated administrator impersonation through SSH challenge tokens
Summary
SSH challenge tokens are mistakenly accepted as valid credentials during the authentication token validation process.
While an SSH challenge token is intended as a short-lived nonce for use in a subsequent SSH key exchange, the function to validate authentication tokens does not differentiate between these and actual authentication tokens. Because challenge tokens are generated based on an account name provided via headers without requiring prior authentication, an unauthenticated attacker can request a valid "challenge" token for any account (including administrative ones) and use it to authenticate against other API endpoints.
Proof of Concept
The vulnerability exists because SSH challenge tokens are stored in the same database table as regular authentication tokens and validateauthtoken in lib/rucio/core/authentication.py accepts these "challenge" tokens. An attacker can obtain a challenge token for an account such as “root” via the REST API and then present it as a valid authentication bearer token:
1. Request a challenge token for an arbitrary account (e.g., "root"): curl -i -H "X-Rucio-Account: root" https://rucio/auth/sshchallengetoken 2. The server returns a 200 OK with the header X-Rucio-SSH-Challenge-Token. 3. The attacker can then use this specific token within the ten-second challenge lifetime as an authentication credential in subsequent requests to the Rucio API: curl -H "X-Rucio-Auth-Token: $CHALLENGETOKEN" https://rucio/accounts/whoami
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/rucioto a version that resolves this vulnerability.Fixed in 41.1.1 - Upgrade
Upgrade
pip/rucioto a version that resolves this vulnerability.Fixed in 40.4.2 - Upgrade
Upgrade
pip/rucioto a version that resolves this vulnerability.Fixed in 38.6.1 - Upgrade
Upgrade
pip/rucioto a version that resolves this vulnerability.Fixed in 35.9.1
Event History
Frequently Asked Questions
Who can exploit this issue?
Any unauthenticated network-accessible attacker can exploit it. They can request an SSH challenge token for an arbitrary account name, including an administrative account such as root, and present that token to other API endpoints as a bearer token.
What configuration or exposed functionality is required?
The affected Rucio service must expose the REST endpoint used to request SSH challenge tokens and API endpoints that validate bearer authentication tokens. No prior account access, authentication, or user interaction is required.
How can I tell whether an instance is vulnerable?
An affected instance accepts an SSH challenge token issued for an arbitrary account as a valid authentication token. The described behavior is tied to validation that does not distinguish challenge tokens from regular authentication tokens.
What is the risk if exploitation succeeds?
An attacker can impersonate the account named when requesting the challenge token, including an administrator account. The reported impact includes complete compromise of confidentiality, integrity, and availability.