Missing ownership check in the Registry downtime API

Impact

On July 23, 2026, an open-source community member reported a security vulnerability in the Pelican Registry (the federation's central service) to the Pelican team. We have confirmed that any registered origin or cache can use the Registry's token-authenticated API to tamper with any other server's scheduled downtime:

• Delete any other server's downtime
• Modify a federation-admin-authored (Registry-sourced) downtime (not another server's self-scheduled downtime, which the update endpoint already protects)
• Schedule a new downtime attributed to any other server, or forge one that appears to be authored by the Registry, since the create endpoint trusted the identity fields supplied in the request body

The Registry's Web UI is not affected. This issue is specific to the token-authenticated API path.

Deleting a downtime restores Director routing to a server that its operator had deliberately taken offline, and clients are then sent to a server meant to be out of service. Modifying a downtime causes a similar integrity and availability problem. When the downtime was authored by a federation administrator (rather than self-reported by the server), the deletion is permanent: no re-advertisement restores it, and an administrator must re-enter it by hand. If the deleted downtime is self-reported by the server, it will be restored by the next server advertisement.

Immediate Action

There is no configuration setting that disables this behavior. Federation administrators should watch for scheduled downtimes, especially administrator-authored ones, in case they disappear unexpectedly or end at a different time. Also audit the approved server list in case any unauthorized server has been approved. Missing federation-admin-authored downtimes should be re-entered, and the offending origin or cache can be identified from the Registry logs.

If you do not operate a Pelican Registry (for example, you run an origin or cache, or you only use the Pelican client to access data), no action is required on your part.

Patches

An upcoming patch will add per-record ownership checks to the Registry's downtime API: a downtime can be updated or deleted only by its owner (the registering server for server-authored downtimes, or a federation administrator for Registry-authored ones), and a downtime created by a registered server is bound to that server's token-verified identity instead of identity fields in the request body. Pelican Registry administrators running an affected version should upgrade to the patched release once it is available. The OSDF Registry is already running the patched code.