Mastodon CVE-2025-62175

The exploiting party must already possess a valid, non-revoked OAuth access token for an account on the Mastodon instance (PR:L) - exploitation is only available to the suspended or disabled user themselves, not to arbitrary remote parties. The condition is the absence of a streaming-side suspension/disabled check: before 4.4.6/4.3.14/4.2.27 the streaming server's token lookup only filtered on users.disabled IS FALSE and token revocation, never re-checking accounts.suspended_at, and suspension never terminated live connections. Limiting factors: the attacker is confined to read-only real-time streaming data (C:L only) and cannot reach other authenticated API endpoints; impact is bounded to continued visibility of timeline/notification streams rather than any write or account-takeover capability; no unauthenticated or UI-based vector exists.

This is a genuine but low-severity moderation-bypass/information-exposure issue, not a high-priority emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N = 4.3 Medium) is internally consistent with the description: exploitation requires an account that was already provisioned and authenticated (PR:L), the account holder simply retains or re-establishes a streaming connection after being suspended/disabled, and the only impact is continued low-level confidentiality exposure (C:L) of real-time timeline updates - no integrity or availability impact. All corroborating signals point to low real-world risk: EPSS is 0.23% (13th percentile), there is no CISA KEV listing, and no public exploit code is referenced. The signals are consistent rather than conflicting - low EPSS, no KEV, and a modest CVSS all agree this is a correctness/moderation-integrity defect rather than a mass-exploitation threat. The practical significance is operational (moderation actions do not fully take effect) rather than a path to compromise, so it warrants routine patching, not emergency response.

An administrator suspends or disables a user account for abuse, expecting the account to be fully cut off. Because the streaming server never checks the account's suspended/disabled state after the initial token issuance, the offending user keeps an existing WebSocket/streaming connection open (or opens a new one) and continues receiving real-time timeline, notification, and message updates despite the moderation action. No public exploit code is referenced, but the technique is trivial for the suspended account holder since it only requires a valid pre-existing OAuth token.