pentestplate stores client-confidential material — findings, evidence files and signed-off reports — so we take reports about it seriously, and we would rather hear about a problem early than quietly.

Please do not open a public issue for a security problem.

Use GitHub's private vulnerability reporting instead: open the Security tab and click Report a vulnerability. If you would rather not use GitHub, email support@proofpointed.com with SECURITY in the subject line.

A useful report tells us:

• what you did, and what you expected instead
• the version or commit you tested
• the smallest set of steps that reproduces it
• whether it needs a specific role or tenant to trigger

Short reports with a reproduction are triaged first. We aim to acknowledge within 3 business days and to give you an assessment — accepted, or why not — within 10. If a fix is going to take longer we will tell you rather than go quiet. When the issue is resolved we will credit you unless you ask us not to; if work has not started 90 days after the disclosure you are free to publish it.

In scope — problems in pentestplate's own code:

• Authentication or session flaws: token forgery, replay, refresh-token abuse, cookie handling, auth bypass
• Authorisation flaws: RBAC bypass, privilege escalation, or reaching another tenant's data through any endpoint
• Path traversal, content-type confusion or unsafe handling in evidence upload/download, or evidence served to a user who should not see it
• Injection: SQL, command, or template/HTML injection through finding or report fields, including stored XSS that fires in a reviewer's or client's browser
• Sensitive data leaking between engagements, tenants or generated report formats (PDF/HTML/Excel/JSON), or in logs and error responses
• Secrets committed to the repository

By design — not a vulnerability in pentestplate:

• The default credentials. The repository ships a well-known admin login so the quickstart works. Changing it is your responsibility, not a bug.
• Running it insecurely. Plain HTTP, an exposed Postgres port, the published development JWT_SECRET, or leaving public registration enabled are deployment choices. See the hardening list below.
• Vulnerabilities in your target. pentestplate is not a scanner; it is where you write down and manage what you found. A finding about a system you tested belongs to that system's owner.
• The demo data. go run ./cmd/seed-data invents Acme Corp findings on purpose, and creates three demo users whose passwords are published in this repository. It is a local evaluation aid: do not run it against an instance holding real work, and do not leave it enabled on one.

If you are unsure which side of that line something falls on, report it and let us decide.

pentestplate is pre-1.0. Only the latest commit on main is supported; there are no backported fixes yet. Before reporting, please confirm the problem still reproduces on the current main.

This is an internal tool for a trusted team, not a hardened public service. It holds everything that will end up in a client report, so treat it that way:

• Change the admin password on first sign-in, and set ALLOW_REGISTRATION=false once the accounts you need exist.
• Set a strong POSTGRES_PASSWORD and a random JWT_SECRET (openssl rand -hex 32). The defaults are published in this repository.
• Serve it over HTTPS. COOKIE_SECURE defaults to true; leave it there.
• Set CORS_ALLOWED_ORIGINS to your real web origin instead of the localhost defaults.
• Do not expose the API or Postgres directly to the internet — put them behind a reverse proxy or a VPN, and keep UPLOAD_PATH on storage you back up and restrict.
• Evidence files are stored on disk with a SHA-256 checksum. The checksum tells you a file changed; it does not by itself keep the storage private.