CVE-2026-27468: 
NixOS vulnerability analysis and mitigation

CVE-2026-27468 is a missing authorization vulnerability in Mastodon's experimental Federated Application Service Provider (FASP) feature that allows unapproved FASP registrations to subscribe to account/content lifecycle events and request content backfill without administrator approval. It affects Mastodon versions 4.4.0 through 4.4.13 and 4.5.0 through 4.5.6, and was published on February 24, 2026. Only servers that have explicitly enabled the experimental FASP feature via the EXPERIMENTAL_FEATURES environment variable are affected. It carries a CVSS v3.1 base score of 8.2 (High) and a CVSS v4.0 base score of 4.8 (Medium) (GitHub Advisory, Red Hat).

The root cause is CWE-862 (Missing Authorization): the FASP API endpoints responsible for event subscriptions and content backfill did not verify whether the requesting FASP provider had been confirmed/approved by an administrator (GitHub Advisory). Specifically, the Fasp::Provider.find(keyid) call in app/controllers/api/fasp/base_controller.rb retrieved any registered provider without filtering for confirmed status, and the Fasp::BaseWorker did not check provider.confirmed? before processing jobs (GitHub Commit). An attacker with a registered but unapproved FASP can send authenticated API requests to endpoints such as POST /api/fasp/data_sharing/v0/event_subscriptions and POST /api/fasp/data_sharing/v0/backfill_requests to exploit this flaw. The attack requires no privileges beyond having a registered (unconfirmed) FASP entry and is remotely exploitable over the network.

A single exploitation results in a minor information leak — the attacker receives URIs that are publicly accessible anyway — posing a low confidentiality risk. However, repeated exploitation creates a serious denial-of-service (DoS) vector by flooding the Sidekiq worker queue responsible for the fasp queue, potentially degrading or fully disrupting the availability of the Mastodon service for legitimate users (GitHub Advisory). There is no integrity impact, and the vulnerability scope is limited to servers that have opted into the experimental FASP feature.

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Red Hat). The EPSS score is approximately 0.041%, reflecting a low probability of near-term exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation is limited to the small subset of Mastodon servers that have explicitly enabled the experimental fasp feature flag, significantly reducing the attack surface.

1. Identify a target: Locate a Mastodon server running versions 4.4.0–4.4.13 or 4.5.0–4.5.6 with the EXPERIMENTAL_FEATURES environment variable set to include fasp.
2. Register a FASP: Submit a FASP registration request to the target Mastodon server. The registration will be pending administrator approval, but the attacker proceeds without waiting for approval.
3. Obtain signing credentials: Use the key pair generated during FASP registration to sign API requests, as the server validates request signatures but does not check confirmation status.
4. Subscribe to lifecycle events: Send authenticated POST /api/fasp/data_sharing/v0/event_subscriptions requests with parameters such as { category: 'content', subscriptionType: 'lifecycle', maxBatchSize: 10 } to subscribe to account or content events without admin approval.
5. Request content backfill: Send authenticated POST /api/fasp/data_sharing/v0/backfill_requests requests to trigger content backfill, receiving publicly available URIs.
6. Amplify for DoS: Repeat steps 4–5 at high frequency to flood the Sidekiq fasp queue, exhausting worker capacity and degrading or disrupting the Mastodon service (GitHub Advisory, GitHub Commit).

• Network: Unusual or high-volume POST requests to /api/fasp/data_sharing/v0/event_subscriptions, /api/fasp/data_sharing/v0/backfill_requests, or /api/fasp/data_sharing/v0/backfill_requests/:id/continuations from unrecognized or unapproved FASP sources.
• Logs: Mastodon application logs showing repeated successful API responses (HTTP 201) to FASP endpoints from providers that have not been confirmed by an administrator; Sidekiq logs showing abnormal queue depth or worker saturation on the fasp queue.
• Application State: Presence of Fasp::Subscription or Fasp::BackfillRequest database records associated with FASP providers whose confirmed field is false or null.

The fix is included in Mastodon versions 4.4.14 (for the 4.4.x branch) and 4.5.7 (for the 4.5.x branch); administrators running servers with the experimental FASP feature enabled should upgrade immediately (GitHub Advisory). The patch adds a confirmed scope to Fasp::Provider and enforces a provider.confirmed? check in both the base controller and base worker before processing any FASP requests (GitHub Commit). As a workaround, administrators can disable the experimental feature by removing fasp from the EXPERIMENTAL_FEATURES environment variable; servers not using this feature flag are entirely unaffected and require no action.

The advisory was published by Mastodon maintainer oneiros on GitHub on February 24, 2026, noting that while the overall severity is rated "Low" due to the small number of affected servers, the severity is "High" for those actively testing the FASP feature (GitHub Advisory). The vulnerability was reported by security researcher geeknik. Red Hat tracked the CVE and published their own advisory shortly after (Red Hat). Social media discussion was limited, with brief mentions on Bluesky from automated CVE tracking accounts.