ProjectSend EUVD-2026-103456

Requires an authenticated ProjectSend staff account that has been granted the import_orphans permission; this is NOT remote-unauthenticated access. Exploitation further requires that files owned by other users exist to be targeted, and that the attacker submit a non-canonical path spelling the storage layer would rewrite - e.g. './a/b.txt', 'a/./b.txt', 'a//b.txt', '/a/b.txt', 'a\b.txt', or 'a/x/../b.txt' - to the orphans import or delete endpoint. Limiting factors: affected versions are ProjectSend 2.0.0 through 2.6.x (fixed in 2.7.0), the import_orphans permission is not held by ordinary recipients, and the delete_others_files control is the boundary being bypassed, so impact is confined to tenants where staff accounts are only partially trusted.

This is a moderate, authorization-bypass issue rather than a critical remote-code flaw. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:L) and score of 6.0 are internally consistent with the description: the attack is network-reachable but requires an authenticated staff account holding the import_orphans permission (PR:L), and the AT:P flag reflects that exploitation depends on the presence of other owners' tracked files to target. Impact is primarily to integrity (VI:H - attacker deletes or adopts files they should not control), with limited availability impact (VA:L) and no confidentiality loss (VC:N), which fits CWE-180 (incorrect behavior order: validate-before-canonicalize). No EPSS score was provided, the CVE is not in CISA KEV, and no public exploit was supplied, so the real-world exploitation signal is currently low: no public exploit identified at time of analysis. The 'Authentication Bypass' tag is somewhat misleading - this bypasses an authorization control (delete_others_files) for an already-authenticated staff user, not authentication itself. Overall this is a legitimate but bounded privilege/permission-boundary defect, not a high-urgency internet-wide threat; prioritize patching for multi-tenant ProjectSend deployments where staff accounts are not fully trusted.

A malicious or compromised ProjectSend staff user who has been granted the import_orphans permission submits a non-canonical path such as './uploads/victim.pdf' or 'uploads//victim.pdf' to the orphan import or delete endpoint. Because isOrphan() compares the raw string before Flysystem canonicalizes it, the tracked file owned by another user appears to be an orphan, letting the attacker delete it or adopt ownership while bypassing the delete_others_files restriction. No public proof-of-concept was provided, but the vendor commit and GHSA advisory describe the bypass mechanics in detail.