CVE-2026-112001 is a high severity (CVSS 7.2) incorrect authorization flaw in ProjectSend 2.0.0 before 2.7.0. A restricted API token can reset its owner's password and clear two-factor, then sign in with the owner's full role. Upgrade to 2.7.0. The sections below cover affected versions, how to check, and what to do first.
What's affected
ProjectSend 2.0.0 through 2.6.0. The GitHub advisory lists 2.7.0 as patched, and the record and VulnCheck agree.
The flaw is in the users API. A token limited to the manage users and edit users abilities can change its own owner's credentials. The advisory also describes a client scenario where a token that can only edit clients replaces a client's password and removes two-factor. Administrators are the highest risk when they own a token.
Scoring note: the record's 7.2 is a CVSS 3.1 base score. VulnCheck's advisory also lists 8.6 under CVSS 4.0. Both describe the same flaw, and the two versions weigh the factors differently.
How to check if you're exposed
Check the ProjectSend version shown in your installation and compare it with 2.7.0 on the project's release page.
Then list API tokens and their abilities, and who owns them. Review recent password and two-factor changes for the accounts that own tokens.
What to do now
- Find your ProjectSend version.
- Upgrade to 2.7.0 or later.
- List API tokens and revoke any you do not need.
- Reset passwords and re-enable two-factor for accounts that own tokens with user abilities.
- Review account changes and file access in recent logs.
- Scan your dependencies with the free in-browser scan and look the CVE up in the Gold directory to see where else it appears.
Do not stop at one host. Write down every place the affected software runs, including test servers, forgotten containers and copies bundled inside other products. Then rank them by exposure: anything reachable from the internet comes first, internal systems next. A short inventory now saves hours when the next advisory lands.
Why it matters
This is CWE-863, incorrect authorization. The token system lets an admin grant a narrow set of abilities, but the users update route did not honour that boundary when the target was the token's own owner. Narrow tokens are meant to limit the damage of a leak. Here a narrow token became a full account.
The vector rates privileges required as high, since a token has to exist, but the effect is complete. It is a good reminder to treat scoped credentials as a security boundary that every route must enforce. It is not listed in CISA KEV.
Quick check
Why does a limited token matter?
Limited tokens are given out on the assumption that a leak is contained. This flaw breaks that assumption.
Which version fixes it?
2.7.0, per the GitHub advisory.
Sources
- VulnCheck advisory
- ProjectSend GitHub advisory
- ProjectSend 2.7.0 release
- Gold entry for CVE-2026-112001
Last reviewed: 18 October 2026.
