CVE-2026-25540 in Mastodon
Summary
by MITRE • 02/05/2026
Mastodon is a free, open-source social network server based on ActivityPub. Prior to versions 4.3.19, 4.4.13, 4.5.6, Mastodon is vulnerable to web cache poisoning via `Rails.cache. When AUTHORIZED_FETCH is enabled, the ActivityPub endpoints for pinned posts and featured hashtags have contents that depend on the account that signed the HTTP request. However, these contents are stored in an internal cache and reused with no regards to the signing actor. As a result, an empty response generated for a blocked user account may be served to requests from legitimate non-blocked actors, or conversely, content intended for non-blocked actors may be returned to blocked actors. This issue has been patched in versions 4.3.19, 4.4.13, 4.5.6.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 02/21/2026
This vulnerability affects Mastodon servers running versions prior to 4.3.19, 4.4.13, and 4.5.6, representing a critical web cache poisoning flaw that undermines the integrity of access control mechanisms. The issue stems from improper cache handling within the Rails caching framework where content generated for specific authenticated users is cached without considering the requesting actor's identity. When the AUTHORIZED_FETCH configuration is enabled, the ActivityPub endpoints for pinned posts and featured hashtags contain user-specific content that should vary based on the authenticated account making the request. However, the caching mechanism fails to differentiate between different users, leading to a scenario where cached responses are incorrectly served to actors other than the original requester.
The technical flaw manifests in the application's failure to implement proper cache key generation that incorporates the requesting user's authentication context. This vulnerability directly relates to CWE-200, Information Exposure, and CWE-501, Trust Boundary Violation, as it allows unauthorized access to content that should be restricted to specific users. The caching layer stores responses based solely on the endpoint path rather than including user-specific identifiers in the cache key, creating a situation where a blocked user's empty response gets cached and subsequently served to legitimate users, or conversely, legitimate users receive content that should be restricted to blocked accounts. This represents a classic cache poisoning attack vector where the cache becomes a conduit for unauthorized information disclosure.
The operational impact of this vulnerability extends beyond simple information disclosure to potentially enable privilege escalation and access to restricted content. Attackers can exploit this weakness to bypass account blocking mechanisms, gain access to content intended for specific users, or potentially discover information about other users' activities within the network. The vulnerability affects the core ActivityPub functionality that enables federated social networking, making it particularly dangerous in distributed environments where multiple Mastodon instances communicate with each other. This issue creates a persistent security gap that could allow malicious actors to manipulate content delivery across the federated network, affecting not just individual instances but the broader social graph.
Mitigation strategies should focus on immediate patching of affected Mastodon installations to versions 4.3.19, 4.4.13, or 4.5.6 where the vulnerability has been addressed. Administrators should also implement additional monitoring of cache behavior and user access patterns to detect potential exploitation attempts. The fix involves ensuring that cache keys properly incorporate user authentication context, making the cache entries specific to individual actors rather than generic to endpoint paths. Organizations should also consider implementing cache invalidation procedures for sensitive endpoints and conducting thorough security reviews of caching mechanisms throughout their applications. This vulnerability demonstrates the importance of proper cache key design and the need for comprehensive security testing of authentication and authorization flows in web applications, particularly those implementing federated protocols like ActivityPub that require careful handling of user-specific content across distributed systems.