CVE-2026-86112 in BookWyrm
Summary
by MITRE • 09/05/2026
BookWyrm through 0.9.1 fails to validate user visibility permissions in the Favorite and Unfavorite views, allowing authenticated attackers to favorite or unfavorite followers-only and direct statuses they cannot access. Attackers can POST to the favorite endpoint with a status ID to create unauthorized interactions, trigger ActivityPub broadcasts, and enumerate private status IDs through response differentiation.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/05/2026
The vulnerability identified in BookWyrm versions up to 0.9.1 represents a critical failure in server-side access control mechanisms within the application's social interaction features. Specifically, the Favorite and Unfavorite views lack proper validation of user visibility permissions when processing requests related to status interactions. In a secure implementation, any action that modifies state or triggers external communications based on content ownership must verify that the requesting user has explicit permission to view the underlying resource. However, in this flawed architecture, the application accepts POST requests targeting specific status identifiers without confirming whether the authenticated attacker is authorized to see those statuses. This oversight allows an authenticated adversary to interact with followers-only and direct messages intended for other users or private circles, effectively bypassing the privacy boundaries established by the content creators.
From a technical perspective, this flaw constitutes an Insecure Direct Object Reference (IDOR) combined with Broken Access Control vulnerabilities as defined in common industry standards such as CWE-639 and CWE-284 respectively. The attacker exploits these weaknesses by crafting HTTP POST requests to the favorite endpoint using valid session credentials but supplying status IDs that belong to private or restricted content. Because the backend logic does not cross-reference the requester's identity against the visibility settings of the target status, the system processes the interaction as legitimate. This leads to unauthorized state changes where the attacker appears to have favorited content they cannot actually view, creating a discrepancy between the user interface and the underlying data model that can be leveraged for further exploitation.
The operational impact of this vulnerability extends beyond simple privacy violations into potential denial-of-service conditions and information disclosure through side-channel analysis. When an attacker successfully favorites or unfavorites a status, the system triggers ActivityPub broadcasts to notify followers and federated instances about the interaction. This means that malicious actors can force the generation of network traffic and notifications for content they do not have access to, potentially causing noise in the federation ecosystem or exhausting resources on affected servers if performed at scale. Furthermore, by observing response differentiation—such as distinct error codes, timing differences, or UI feedback—the attacker can enumerate valid status IDs within private feeds. This enumeration capability allows adversaries to map out the existence of hidden content and identify active users who interact with specific posts, thereby compromising user anonymity and social graph integrity even without direct access to the message bodies themselves.
Mitigation strategies must prioritize strict enforcement of authorization checks at every step of the request lifecycle. Developers should implement middleware or service-layer validation that explicitly verifies whether the authenticated user has permission to view a given status ID before allowing any interaction such as favoriting, unfavoriting, boosting, or replying. This check must occur prior to triggering external protocols like ActivityPub to prevent unnecessary broadcast generation for unauthorized actions. Additionally, implementing consistent error responses regardless of whether an action is permitted or denied can help mitigate enumeration attacks by removing the side-channel information that allows attackers to distinguish between invalid IDs and forbidden access attempts. Regular security audits focusing on object-level permissions and adherence to principle of least privilege are essential to prevent similar vulnerabilities in future releases.