Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as client-scoped staff user
-
ExploitLink own file onto an intermediate revision via version API
-
ExecutionTrigger moveAssignmentsToRoot() recipient reassignment
-
ImpactExpose protected root file to unauthorized clients
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires an authenticated staff account (PR:L) with file upload/edit capability in ProjectSend; anonymous or pure-client access is not sufficient. Exploitation is further gated (AT:P) by pre-existing state the attacker does not fully control: either a multi-level version chain where the linked $previous is itself a revision so its root is a separate protected file, or a situation where someone else has already shared the attacker's upload with a client outside the attacker's authorized roster. The flaw is reached through the file version linking endpoints (web route files.version.store or PUT /api/v1/files/{id}/version with previous_file_id). Limiting factors: the attacker must be a trusted client-scoped staff member, the abuse only widens exposure to recipients/roots that the required preconditions make available, and the patched versions add authorization checks that refuse the link entirely. The default-configuration, remote-unauthenticated case does not apply. |
| Impact | This is a genuine but moderate-priority issue, not a drop-everything emergency. The only severity data supplied is a CVSS 4.0 base score of 6.0 (MEDIUM); no CVSS 3.1 vector, no EPSS score, and no SSVC decision breakdown were provided, so exploitation-probability modeling is unavailable. The 4.0 vector tells a consistent story: AV:N (reachable over the network via the web UI or /api/v1 endpoint) and UI:N, but PR:L means the attacker must already hold a staff account, and AT:P means success depends on specific preconditions (an existing multi-level version chain, or a file already shared with an out-of-scope client by someone else). Impact is weighted to confidentiality (VC:H - protected original files exposed to unauthorized clients) with only low integrity (VI:L) and no availability impact; SC/SI/SA:N indicate no scope change to other systems. It is NOT in CISA KEV, there is no EPSS signal, and the input shows no PoC or exploit reference - exploitation status is 'no public exploit identified at time of analysis.' The vuln.today priority is 'this_month,' which aligns with the picture: a real authorization-boundary flaw that requires a trusted insider (client-scoped staff) and pre-existing conditions, so it favors targeted misuse by an authorized-but-limited user rather than widespread opportunistic attack. Missing EPSS/KEV data should be treated as absence of a widespread-exploitation signal, not as confirmation of low risk. |
| Exploit ScenarioDerived | A client-scoped staff member in ProjectSend (who may only share files with their own assigned clients) uses the file-version linking feature to link one of their own files onto an intermediate revision whose root is a third, protected file, or to carry an out-of-scope client recipient onto that root. Because moveAssignmentsToRoot() reassigns recipients to the chain's root without re-authorizing them, a protected original file belonging to another scope becomes visible to clients the attacker was never allowed to share with. No public exploit is identified at the time of analysis, though the vendor patch commit and VulnCheck advisory describe the mechanism in detail. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 25, 2026
Incomplete authorization in ProjectSend's file-version linking lets an authenticated staff user cause a protected original file to be shared with clients who should never see it. A staffer holding upload/edit permission can link a file they control onto another user's intermediate revision, and because linking moves the new file's assignments onto the root of the version chain, the real original becomes visible to the attacker's recipients; a client-scoped staffer can likewise carry an out-of-roster client onto someone else's file. Exploitation is gated by pre-existing state the attacker does not fully control (a multi-level chain where the linked previous item is itself a revision, or an upload already shared with an outside client), no public exploit code is identified at time of analysis and there is no CISA KEV entry, and the vendor has published an upstream fix commit (a6ce4f51cfd05e1c9895f8daed261ef1fdfd194d).
RemediationAI
Apply the upstream fix commit a6ce4f51cfd05e1c9895f8daed261ef1fdfd194d (https://github.com/projectsend/projectsend/commit/a6ce4f51cfd05e1c9895f8daed261ef1fdfd194d), which adds the root-level setVersion authorization check and the recipient-assignability guard in FileVersions::link(); a tagged release containing this commit is not independently confirmed in the available data, so verify the commit is present in whatever build you deploy, and consult the VulnCheck advisory (https://www.vulncheck.com/advisories/projectsend-2.0.0-through-2.7.1-incorrect-authorization-via-file-version-linking) for vendor guidance. Where the fix cannot be deployed immediately, reduce exposure by limiting version-linking to administrators - the patched behavior refuses the link outright rather than partially completing it, so restricting who can reach files.version.store and PUT /api/v1/files/{id}/version removes the attack path at the cost of staff workflow convenience - and by reviewing staff roles so that upload/edit permissions, particularly edit_files without edit_others_files and client-scoped ClientManager rosters, are granted only to accounts trusted to link versions against other users' files. Also audit existing version chains and file assignments for originals that were exposed to unexpected clients or groups, since the abuse widens visibility of the root file and may leave lasting sharing state that the patch does not retroactively clean up.
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
ProjectSend is a PHP file-sharing application built on Laravel (Eloquent ORM, Gate authorization, API tokens via Sanctum), and the flaw sits in app/Modules/Files/Versions/FileVersions.php. CWE-863 (Incorrect Authorization) describes the root cause: FileVersions::link() guarded the file being linked and the immediate $previous record, but not the root of the version chain, which is where recipient assignments actually land through moveAssignmentsToRoot(). When $previous is itself a revision, version_root_id points at a third, separate file, so permission to change a revision said nothing about the original it belonged to. A second gap was in recipient handling: the move runs through FileSharing::assign(), which performs no authorization of its own, so a client-scoped staff member could attach clients or groups outside their roster to the root. The upstream fix injects a StaffLibraryScope dependency, adds a Gate::forUser($actor)->authorize('setVersion', $root) check against the resolved root, and adds guardRecipientsAssignable(), which validates each assignment against canAssignClient()/canAssignGroup() and throws a ValidationException (refusing the whole link rather than silently dropping recipients) when a target is out of scope and not already present on the root. The trigger is reached through the version-linking endpoints - the web route files.version.store or PUT /api/v1/files/{id}/version with a previous_file_id parameter - and requires edit/upload capability on the linking account.
Know when Projectsend 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:P/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N
Network-reachable but requires an authenticated staff account (PR:L) and pre-existing version-chain/out-of-scope-assignment conditions outside the attacker's control (AC:H); high confidentiality exposure, low integrity, no availability impact.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
ProjectSend 2.0.0 through 2.7.1 contains an incomplete authorization vulnerability in FileVersions::link() that allows staff users to share files without authorization by linking file versions. Attackers can link their file onto an intermediate revision or assign out-of-scope clients, causing moveAssignmentsToRoot() to expose protected original files to unauthorized clients.
Threat Intelligence Overview
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.
More in Projectsend
View allProjectSend versions prior to r1720 are affected by an improper authentication vulnerability. Rated critical severity (C
Unrestricted file upload vulnerability in process-upload.php in ProjectSend (formerly cFTP) r100 through r561 allows rem
install/make-config.php in ProjectSend r754 allows remote attackers to execute arbitrary PHP code via the dbprefix param
Projectsend version r1295 is affected by a directory traversal vulnerability. Rated critical severity (CVSS 9.8), this v
An issue was discovered in ProjectSend r1053. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable
Projectsend version r1295 is affected by sensitive information disclosure. Rated high severity (CVSS 8.1), this vulnerab
reset-password.php in ProjectSend before r1295 allows remote attackers to reset a password because of incorrect business
SQL injection vulnerability in client-edit.php in ProjectSend (formerly cFTP) r561 allows remote authenticated users to
Projectsend version r1295 is affected by a directory traversal vulnerability. Rated medium severity (CVSS 6.5), this vul
Projectsend version r1295 is affected by Cross Site Scripting (XSS) due to lack of sanitization when echo output data in
Projectsend r1295 contains a stored cross-site scripting vulnerability that allows authenticated attackers to inject mal
Cross-site scripting (XSS) vulnerability in ProjectSend (formerly cFTP) r561 allows remote attackers to inject arbitrary
EUVD-2026-109388
GHSA-gjpq-2gcq-78q9
NVD
CVE.org
EPSS
VulDB
Exploit-DB