Joplin Server EUVD-2026-84177

Requires (1) a running Joplin Server instance prior to version 3.7.7, (2) an authenticated low-privileged user account (PR:L), and (3) that the attacker has been sent a folder-share invitation which is still in the pending/Waiting state (ShareUserStatus not yet Accepted). Given those, the attacker sends an item-creation API request specifying the target share_id; the flaw is in ItemModel.checkIfAllowed() accepting any share_users row regardless of acceptance status. LIMITING FACTORS: attacker cannot target arbitrary shares - a legitimate invitation to the specific shared folder is a prerequisite, so this is scoped to social/collaboration relationships; impact is limited to injecting content (integrity), with no read or deletion capability. This is not exploitable against default configurations without the invitation precondition.

This is a genuine but low-to-moderate severity authorization flaw, not a high-impact emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, 4.3) is internally consistent with the description and the patch: network-reachable, low complexity, but requiring an authenticated low-privileged account (PR:L) and yielding only limited integrity impact (I:L) - the attacker can inject/create items into a share but cannot read (C:N) or delete/deny (A:N) existing owner data. No EPSS score, KEV entry, or public POC was provided, so exploitation status is 'no public exploit identified at time of analysis.' The one meaningful gating factor beyond authentication is that the attacker must have received a pending folder-share invitation from the target - the server does not let arbitrary users write into arbitrary shares, only into shares they were invited to but have not yet accepted. That significantly narrows the realistic attacker population and makes this a targeted, socially-scoped issue rather than a broadly automatable one. Priority is moderate for Joplin Server operators (patch in normal cadence); it does not warrant emergency response absent active-exploitation signals.

An attacker who has been invited to collaborate on a shared folder (but has not yet clicked accept) issues an authenticated API call to create a note under the share's ID. Because ItemModel.checkIfAllowed() only checks that a share_users row exists - not that its status is Accepted - the write succeeds, and ShareModel.updateSharedItems3() then propagates the attacker's injected content to the folder owner and all accepted participants. No public exploit code is identified, but the fix commit's regression test demonstrates the exact request sequence.