EUVD-2026-109276
GHSA-rq5g-4m5j-8p36
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as ordinary tenant user
-
ExploitEnumerate sequential notification IDs
-
ExecutionPOST /api/notifications/:id/read for victim IDs
-
ImpactSuppress victims' unread indicators
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
|
| Exploitation Conditions | Requires a valid authenticated account on the target ONEARMY community-platform tenant (PR:L); the attacker then sends POST /api/notifications/:id/read requests iterating sequential, attacker-chosen notification IDs that belong to other users in the same tenant. No user interaction and no special configuration are needed - the pre-2.165.2 endpoint updated 'notifications' by id alone with no owned_by_id ownership check. Limiting factors: exploitation is confined to users within the same tenant, needs authentication, and the only achievable effect is marking others' notifications as read (integrity-only, no confidentiality or availability impact), so the attacker cannot read notification content, alter other data, or disrupt the service. |
| Impact | This is a genuine but low-severity authorization flaw (CWE-639 IDOR), and the signals are internally consistent rather than conflicting. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms a network-reachable, low-complexity attack that nevertheless requires authentication (PR:L) - so this is not an unauthenticated internet-wide threat. Impact is limited to integrity only (VI:L; VC:N/VA:N), meaning no data disclosure and no service disruption: the attacker can only flip other users' notifications to 'read', suppressing their unread indicators. The vuln.today decision label is 'this_month' (not act_now/emergency), aligning with a medium 5.3 score. No EPSS score and no CISA KEV entry are provided, and there is no indication of active exploitation. A public PoC reference exists (a HackMD write-up plus a VulnCheck advisory), but it is not verified as working exploit code. Net: a real, confirmed-and-patched issue worth scheduling into normal maintenance, not a drop-everything priority - the capped integrity-only impact and authentication requirement keep real-world risk modest. |
| Exploit ScenarioDerived | An attacker registers or already holds a normal account on a ONEARMY community-platform tenant, then scripts POST requests to /api/notifications/:id/read while iterating sequential notification IDs belonging to other users in the same tenant. Because the vulnerable code updated notifications by id alone without checking ownership, the victims' unread badges are cleared and they miss replies, comments and new-content notices. A public PoC reference exists (HackMD write-up); it is not verified as working exploit code. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 24, 2026
Authenticated users of ONEARMY community-platform before 2.165.2 can mark other users' notifications as read by iterating sequential notification IDs against the POST /api/notifications/:id/read endpoint, which updated the notifications table by ID alone without verifying ownership. The effect is integrity-only and confined to users in the same tenant: victims silently lose unread indicators for replies, comments and new-content notices, and may miss activity they would otherwise respond to. The vendor has released 2.165.2 with the ownership check, and a public technical writeup of the IDOR exists; no public exploit code or active exploitation is confirmed (not in CISA KEV), and the vendor-assigned CVSS 4.0 score is 5.3 (assessed as CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), so priority is this-month rather than emergency.
RemediationAI
Upgrade to ONEARMY community-platform 2.165.2 or later - the vendor-released patch that adds the owned_by_id ownership check to the notification-read handler (PR https://github.com/ONEARMY/community-platform/pull/5011, commit 571732c26caf1a0a46e5335d275cef2e19dfab08, release https://github.com/ONEARMY/community-platform/releases/tag/v2.165.2). No standalone hotfix or configuration toggle is documented in the available references, and deploying the patched route file without the accompanying notification-mapper changes in the same PR risks breaking notification listing. If the upgrade must be scheduled, the compensating option is to block POST requests to /api/notifications/*/read at the reverse proxy or WAF for untrusted users; the trade-off is that notification-read functionality is disabled for legitimate users until the patched build is deployed, and client-side calls will fail. Because exploitation requires only a valid low-privilege account, review tenant membership and account provisioning for unknown or stale users while the patch is pending; there is no public exploit code confirmed, but the endpoint is trivially reachable with a browser or curl.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The affected component is a SvelteKit route handler, src/routes/api.notifications.$id.read.ts, which exports an action that takes the :id route parameter and issues a Supabase client call of the form client.from('notifications').update({ is_read: true }).eq('id', Number(params.id)). Because the query filters only on the notification's primary key and never on owned_by_id, any authenticated caller can address another user's notification row directly - the classic CWE-639 (Authorization Bypass Through User-Controlled Key) pattern where a client-supplied identifier substitutes for an authorization decision. The IDs are sequential integers, so enumeration is trivial once an attacker holds a valid account on the tenant; the platform's multi-tenant design (storage buckets keyed by TENANT_ID) bounds the blast radius to that tenant. The upstream fix in PR #5011 resolves the Supabase auth subject to a profile row (select id from profiles where auth_id = claims.sub) and appends .eq('owned_by_id', profile.data.id) to the update, returning HTTP 400 when no profile is found; the same PR reworks notification listing in api.notifications.ts to order by is_read then created_at with a 50-row limit and batches content/tag lookups in NotificationMapperServiceServer.
Know when Community Platform gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Network endpoint with low complexity but requires an authenticated low-privilege account (PR:L); impact is integrity-only (I:L) from flipping others' read state, with no confidentiality or availability effect.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
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.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Exploit-DB