CVE-2026-116018 in Community Platform
Summary
by MITRE • 10/24/2026
ONEARMY community-platform before 2.165.2 contains an insecure direct object reference vulnerability that allows authenticated users to mark other users' notifications as read via POST /api/notifications/:id/read. Attackers can iterate sequential notification IDs to suppress unread indicators of users in the same tenant, causing them to miss replies, comments and new-content notices.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/24/2026
The identified security flaw represents a classic Insecure Direct Object Reference vulnerability within the ONEARMY community-platform prior to version 2.165.2. This type of weakness occurs when an application uses user-supplied input to access objects directly, such as database records or files, without performing sufficient authorization checks to ensure that the requesting user is permitted to perform actions on that specific object. In this specific instance, the vulnerability resides in the API endpoint POST /api/notifications/:id/read, which is designed to mark a notification associated with the authenticated session as read. The critical failure lies in the server-side logic, which accepts an arbitrary identifier for the notification ID from the request payload and processes it without verifying that the notification actually belongs to the user making the request or that they have permission to modify its state. This lack of object-level authorization control allows any authenticated member of a tenant to manipulate notifications belonging to other members within that same tenancy boundary.
From an operational perspective, this vulnerability enables attackers to engage in enumeration and suppression attacks against their peers on the platform. By iterating through sequential notification IDs, an attacker can systematically mark as read all visible or guessable notifications for targeted users. This action effectively suppresses unread indicators, which are critical UI elements that alert users to new activity such as replies to their comments, responses to their posts, or updates from communities they follow. The consequence is a denial of service against the user experience rather than system availability; victims may remain unaware of important interactions, leading to missed communications, delayed responses in collaborative projects, and potential loss of engagement with community features. This can be particularly damaging in professional or educational contexts where timely notification response is essential for workflow continuity and social interaction integrity.
The technical classification of this issue aligns directly with CWE-639, which defines Insecure Direct Object References as a flaw allowing access to data or functionality without proper authorization checks on the object identifier itself. Furthermore, from an adversary behavior perspective, this vulnerability facilitates actions consistent with ATT&CK technique T1078, specifically Valid Accounts and potentially T1528 Steal Application Access Token if combined with other exploits, though here it is primarily about abusing existing valid credentials to manipulate state. The ability to iterate IDs also touches upon CWE-209 Generation of Error Message Containing Sensitive Information if the API returns distinct error codes for non-existent versus unauthorized access attempts, aiding further enumeration efforts.
Mitigation strategies must focus on implementing strict object-level authorization checks within the application logic. Developers should ensure that every request to modify a notification's state verifies that the authenticated user is the rightful owner of that specific notification record before processing the update. This typically involves querying the database with both the provided ID and the current user's identity, ensuring they match, or utilizing indirect references such as opaque tokens instead of sequential integer IDs where feasible. Additionally, implementing rate limiting on this endpoint can mitigate the efficiency of iterative enumeration attacks by slowing down rapid-fire requests from a single source. Upgrading to version 2.165.2 or later is the primary remediation step provided by the vendor, as these updates likely include patches for this authorization bypass. Security teams should also audit other API endpoints that accept object identifiers via POST or PUT methods to ensure similar patterns of insecure direct references are not present elsewhere in the platform architecture.