ignacionelson
469ba8d8c8
There was no security policy in this repository, and no "Report a vulnerability" button either — private reporting was switched off, so the Security tab offered an outside researcher nothing to press. The Docker Hub description meanwhile told people to report privately through GitHub advisories, which is advice for a thing that did not exist. The likely outcome of that combination is somebody filing a working exploit as a public issue, having tried to do the right thing first. Reporting is on now, for this repository and for both public packages. This is the policy that goes with it. v1's policy was the starting point and about half of it survived. The address is the same, contact@projectsend.org, which is still live and still in CONTRIBUTING.md and both CLAs. "Do not open a public issue" is still the point. What did not carry: it predates private reporting and would have contradicted what we already tell Docker users, and it sent readers to v1's SECURITY_HARDENING.md — eight kilobytes about hand-writing Nginx and Apache rules to keep uploads private, which in v2 ship in the nginx config and are already in place inside the image. Pointing a v2 operator at it would be pointing them at a different architecture. What is new is what v1 never needed: which versions are supported, now that there are version numbers and two packages on their own lines, and a sentence on what is not a vulnerability — an installation that skipped the install guide, an unread scanner report, a dependency finding Dependabot already watches. The response times are deliberately modest and honest about the size of this project, including what to do about silence. Better that than an SLA nobody is on call for. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4.1 KiB
Security Policy
Reporting a vulnerability
Use GitHub's private vulnerability reporting. It is the "Report a vulnerability" button on this repository's Security tab. The report stays private between you and the maintainers, the whole exchange lives in one place, and it is the route that can end in a published advisory with a CVE and your name on it.
If you would rather not use GitHub, or the report does not fit that form, email contact@projectsend.org instead. Either is fine. What matters is that it does not start in public.
Please do not open a public issue for a security report. An issue is world-readable the moment it is filed, including by people running the version you just described how to break.
What helps
Enough to reproduce it, and nothing you would not want to write down:
- The version, from System → About (self-hosted) or
config/projectsend.php. - How the installation is deployed — the Docker image, a manual install behind nginx, something else — and anything unusual in front of it.
- The steps, and what you saw. A short recording or a
curlcommand beats a description. - What an attacker gets out of it, if it is not obvious.
You do not need a proof-of-concept exploit, and you should not run one against an installation that is not yours.
What to expect
An acknowledgement within a few days, and a real answer — a fix, a plan, or a reason it is not what it looked like — once it has been reproduced. If a fix ships, you are credited by name unless you would rather not be.
This is a small project. If a week goes by in silence, assume the message went astray rather than that it was ignored, and send it again.
What is in scope
Anything that lets somebody reach a file, an account, or an installation they should not: the sharing and permission rules, authentication and two-factor, the public pages and share links, the API, the upload and download paths, and the setup and update flows.
Some things are worth a report but are not vulnerabilities in ProjectSend:
- An installation that has not done what the install guide says. Serving the storage directory straight from the web server, or running without the protected-file rules, is a deployment problem — see INSTALL.md and DOCKER.md. Tell us anyway if the documentation is what led somebody there.
- Findings from a scanner, unread. A header a tool wanted and an exploit are different claims. Say which one you have.
- Anything in a dependency, unless ProjectSend's use of it is what makes it reachable. Those belong upstream, and Dependabot already watches for them here.
Supported versions
| ProjectSend 2.x | Supported. Fixes land on the current release line; upgrade before reporting that an older 2.x behaves differently. |
The companion packages — community-modules, v1-migration-tool |
Supported, on their own version lines. Report them here or on their own repository; both reach the same people. |
| ProjectSend Legacy (v1) | A separate application in a separate repository — see projectsend/legacy for how it handles reports. Nothing here applies to it. |
Hardening your own installation
If you are trying to configure an installation rather than report a bug, the deployment documentation is what you want: INSTALL.md for a manual install, including the web server rules that keep uploaded files private, and DOCKER.md for the image, where those rules are already in place.
Two things are worth knowing whichever way you installed:
- Put TLS in front of it, and set
TRUSTED_PROXIESwhen you do. Without it every visitor appears to come from the proxy, which turns the login rate limiter into one bucket for all of them and records the wrong address in the download log. APP_KEYdecrypts what is already stored. Back it up with the database, and do not rotate it on a running installation without knowing what you are doing.