GHSA-RPFR-X88X-XWCW
Vulnerability from github – Published: 2026-05-04 21:24 – Updated: 2026-05-13 13:42Background
On April 2nd, 2026, a Claude coding agent alerted Pelican PI Brian Bockelman to a privilege escalation vulnerability affecting Pelican's Web User Interface (WebUI) for various versions between v7.21 and v7.24. Upon further investigation, the Pelican team discovered this attack allows any user authenticated to the WebUI via OAuth to gain admin privileges under certain configurations. These may include servers with the following configuration variables enabled:
- Server.UIAdminUsers: Affected if any of the listed admin users or the default admin account have not previously logged in to the server.
- Server.AdminGroups: Affected if
Issuer.GroupSourceis set tointernaland an admin of the group has not previously logged in to the server.
The OSDF operations team has mitigated these for core services, origins, and caches operated by the PATh project. However, mitigation may be needed for caches and origins not centrally operated.
Pelican Command Line has not currently identified any evidence this attack has been exploited in the services managed by OSDF operators.
Severity and Impact
When leveraged, an attacker with any kind of authenticated session on the server can create database records that cause the server to grant them admin privileges on subsequent login. Critically, admin access enables modifying the server's configuration, creating persistent API tokens, and changing admin passwords. The table below summarizes potential implications of this exploit.
| Service | Data exposure risk | Data tampering risk | Federation-wide impact |
|---|---|---|---|
| Director | Low (no data stored) | High — can modify configuration to point to a different Registry | High — can modify configuration to add GeoIP overrides to steer federation. Denial of service on the federation |
| Registry | Low | High — can modify existing or create malicious namespaces that impersonate trusted paths | High — federation-wide namespace poisoning. Denial of service on the federation |
| Origin | High — can expose protected paths via config or export object store/filesystem paths into a namespace | High — can potentially enable writes + change export paths | Medium — scoped to that origin's namespaces |
| Cache | Medium — can expose cached protected data via config changes | Low — caches don't originate data | Low — scoped to that cache |
Attack Preconditions
Both attacks share the same prerequisites:
1. The server's OIDC logins must be enabled.
2. The attacker must have some form of authenticated session on the server, typically from an OIDC login.
3. The attacker must know or guess a relevant admin identifier (a Server.UIAdminUsers username or a Server.AdminGroups group name) for an admin who has not previously logged into the WebUI.
Immediate Mitigation Steps
1. Audit the consuming service's database
Before upgrading, Pelican Command Line recommends auditing the service's database to see if it has already been exploited and to block further exploitation. Upgrading an exploited server is insufficient to prevent future unauthorized access if the exploit has already occurred.
Pelican Command Line is providing a script mitigate-user-escalation.sh that:
- Displays all user records and group memberships for manual review, highlighting any that show fingerprints of the attack with
[!]for explicit review — administrators should verify all entries, but especially those with this syntax highlighting. The highlighted changes do not guarantee an exploit occurred but that further examination is needed. - Creates database records mitigating the attack vector.
- Displays all API tokens, which may have been created by an attacker for persistent access, for administrator review. Suspicious tokens should be deleted using the provided SQLite commands.
- Provides additional guidance about rotating secrets on the server.
This script is available as a github gist: https://gist.github.com/jhiemstrawisc/8c4b2b3ec5cb2ca06537d9439dc16cc9
To run the script:
# Run as the same user that runs the Pelican server (e.g., pelican):
$ sudo bash mitigate-user-escalation.sh
# If using a non-standard config file:
$ sudo bash mitigate-user-escalation.sh --config /path/to/pelican.yaml
# If the database is in a non-standard location:
$ sudo bash mitigate-user-escalation.sh --db-path /path/to/pelican.sqlite
2. Upgrade to a patched version
Administrators for Pelican servers running an affected version should upgrade to a patched release. Within each minor release series, these versions include:
- >=v7.21.5
- >=v7.22.3
- >=v7.23.3
- >=v7.24.2
Administrators can check their server's version by invoking pelican with the --version flag, or by inspecting the WebUI's ? icon displayed in the lower left corner.
3. Disable vulnerable configuration if not upgrading immediately
If administrators are unable to upgrade to a patched version, disable the vulnerable configuration by commenting or removing the relevant settings from the service's pelican.yaml:
Server:
# Comment or remove these lines:
# UIAdminUsers:
# - user1
# - user2
# AdminGroups:
# - admin-group
Note: Disabling
Server.UIAdminUsersremoves OIDC-based admin access entirely, leaving only password-based login for admin access. Ensure the project has a working admin password before making this change.
If a server doesn't currently configure Server.UIAdminUsers or Server.AdminGroups, do not populate these settings until the administrator has upgraded to a patched version. If their project doesn't currently have these configured but have in the past, they should still audit the records using the provided mitigation script.
Long-Term Fixes
In addition to closing the immediate vulnerabilities, the Pelican development team is working toward several defense-in-depth solutions to minimize the risk of similar vulnerabilities in the future. These include: - Reviewing all code in the vicinity of these vulnerabilities for other attack vectors. - Changing internal frameworks so security implications of new APIs are more visible to code reviewers. - Automating security scanning using coding agents like the one that discovered this class of vulnerabilities.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/pelicanplatform/pelican"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260408120501-7f73b9c3e677"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42571"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-04T21:24:50Z",
"nvd_published_at": "2026-05-09T20:16:29Z",
"severity": "CRITICAL"
},
"details": "## Background\n\nOn April 2nd, 2026, a Claude coding agent alerted Pelican PI Brian Bockelman to a privilege escalation vulnerability affecting Pelican\u0027s Web User Interface (WebUI) for various versions between `v7.21` and `v7.24`. Upon further investigation, the Pelican team discovered this attack allows any user authenticated to the WebUI via OAuth to gain admin privileges under certain configurations. These may include servers with the following configuration variables enabled:\n\n- **Server.UIAdminUsers**: Affected if any of the listed admin users or the default admin account have not previously logged in to the server.\n- **Server.AdminGroups**: Affected if `Issuer.GroupSource` is set to `internal` and an admin of the group has not previously logged in to the server.\n\nThe OSDF operations team has mitigated these for core services, origins, and caches operated by the PATh project. However, mitigation may be needed for caches and origins not centrally operated.\n\n**Pelican Command Line has not currently identified any evidence this attack has been exploited in the services managed by OSDF operators.**\n\n## Severity and Impact\n\nWhen leveraged, an attacker with any kind of authenticated session on the server can create database records that cause the server to grant them admin privileges on subsequent login. Critically, admin access enables modifying the server\u0027s configuration, creating persistent API tokens, and changing admin passwords. The table below summarizes potential implications of this exploit.\n\n| Service | Data exposure risk | Data tampering risk | Federation-wide impact |\n|---------|-------------------|---------------------|----------------------|\n| **Director** | Low (no data stored) | **High** \u2014 can modify configuration to point to a different Registry | **High** \u2014 can modify configuration to add GeoIP overrides to steer federation. Denial of service on the federation |\n| **Registry** | Low | **High** \u2014 can modify existing or create malicious namespaces that impersonate trusted paths | **High** \u2014 federation-wide namespace poisoning. Denial of service on the federation |\n| **Origin** | **High** \u2014 can expose protected paths via config or export object store/filesystem paths into a namespace | **High** \u2014 can potentially enable writes + change export paths | Medium \u2014 scoped to that origin\u0027s namespaces |\n| **Cache** | **Medium** \u2014 can expose cached protected data via config changes | Low \u2014 caches don\u0027t originate data | Low \u2014 scoped to that cache |\n\n## Attack Preconditions\n\nBoth attacks share the same prerequisites:\n1. The server\u0027s OIDC logins must be enabled.\n2. The attacker must have some form of authenticated session on the server, typically from an OIDC login.\n3. The attacker must know or guess a relevant admin identifier (a `Server.UIAdminUsers` username or a `Server.AdminGroups` group name) for an admin who has not previously logged into the WebUI.\n\n## Immediate Mitigation Steps\n\n### 1. Audit the consuming service\u0027s database\n\nBefore upgrading, Pelican Command Line recommends auditing the service\u0027s database to see if it has already been exploited and to block further exploitation. **Upgrading an exploited server is insufficient to prevent future unauthorized access if the exploit has already occurred.**\n\nPelican Command Line is providing a script `mitigate-user-escalation.sh` that:\n\n- Displays all user records and group memberships for manual review, highlighting any that show fingerprints of the attack with `[!]` for explicit review \u2014 **administrators should verify all entries, but especially those with this syntax highlighting**. The highlighted changes do not guarantee an exploit occurred but that further examination is needed.\n- Creates database records mitigating the attack vector.\n- Displays all API tokens, which may have been created by an attacker for persistent access, for administrator review. Suspicious tokens should be deleted using the provided SQLite commands.\n- Provides additional guidance about rotating secrets on the server.\n\nThis script is available as a github gist: https://gist.github.com/jhiemstrawisc/8c4b2b3ec5cb2ca06537d9439dc16cc9\n\nTo run the script:\n```bash\n# Run as the same user that runs the Pelican server (e.g., pelican):\n$ sudo bash mitigate-user-escalation.sh\n\n# If using a non-standard config file:\n$ sudo bash mitigate-user-escalation.sh --config /path/to/pelican.yaml\n\n# If the database is in a non-standard location:\n$ sudo bash mitigate-user-escalation.sh --db-path /path/to/pelican.sqlite\n```\n\n### 2. Upgrade to a patched version\n\nAdministrators for Pelican servers running an affected version should upgrade to a patched release. Within each minor release series, these versions include:\n- `\u003e=v7.21.5`\n- `\u003e=v7.22.3`\n- `\u003e=v7.23.3`\n- `\u003e=v7.24.2`\n\nAdministrators can check their server\u0027s version by invoking pelican with the `--version` flag, or by inspecting the WebUI\u0027s `?` icon displayed in the lower left corner.\n\n### 3. Disable vulnerable configuration if not upgrading immediately\n\nIf administrators are unable to upgrade to a patched version, disable the vulnerable configuration by commenting or removing the relevant settings from the service\u0027s `pelican.yaml`:\n\n```yaml\nServer:\n # Comment or remove these lines:\n # UIAdminUsers:\n # - user1\n # - user2\n # AdminGroups:\n # - admin-group\n```\n\n\u003e **Note:** Disabling `Server.UIAdminUsers` removes OIDC-based admin access entirely, leaving only password-based login for admin access. Ensure the project has a working admin password before making this change.\n\nIf a server doesn\u0027t currently configure `Server.UIAdminUsers` or `Server.AdminGroups`, ***do not populate these settings until the administrator has upgraded to a patched version.*** If their project doesn\u0027t currently have these configured but have in the past, they should still audit the records using the provided mitigation script.\n\n## Long-Term Fixes\n\nIn addition to closing the immediate vulnerabilities, the Pelican development team is working toward several defense-in-depth solutions to minimize the risk of similar vulnerabilities in the future. These include:\n- Reviewing all code in the vicinity of these vulnerabilities for other attack vectors.\n- Changing internal frameworks so security implications of new APIs are more visible to code reviewers.\n- Automating security scanning using coding agents like the one that discovered this class of vulnerabilities.",
"id": "GHSA-rpfr-x88x-xwcw",
"modified": "2026-05-13T13:42:30Z",
"published": "2026-05-04T21:24:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/PelicanPlatform/pelican/security/advisories/GHSA-rpfr-x88x-xwcw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42571"
},
{
"type": "WEB",
"url": "https://github.com/PelicanPlatform/pelican/commit/7f73b9c3e677a0ae4a0ec465c5d98bb8bd948854"
},
{
"type": "PACKAGE",
"url": "https://github.com/PelicanPlatform/pelican"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "Pelican Web UI Affected by a Privilege Escalation Attack"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.