Don't open a public GitHub issue for security vulnerabilities. Reports filed in public can be acted on by attackers before parbaked users have a chance to update.

To report a vulnerability, use GitHub's private vulnerability reporting for this repository:

1. Go to the Security tab.
2. Click "Report a vulnerability".
3. Fill in the form — only parbaked maintainers will see it.

You'll get a response within 5 working days, typically faster. If the report qualifies as a vulnerability, we'll work with you to confirm it, prepare a fix, and coordinate disclosure.

In scope:

• Auth bypass, privilege escalation (becoming admin / accessing another user's data without the credentials).
• Code injection (the framework executing strings it shouldn't — see #149 for the pattern).
• Path traversal in any kernel surface (the MCP server, the deploy generator, config loaders — see #151 for the pattern).
• Secret exposure (anything that leaks JWT secrets, admin password, or user password hashes from a default deployment).
• CSRF / session fixation on the admin dashboard.
• HMAC verification bypass in the webhook layer.
• Prod-safety bypass (anything that lets PARBAKED_ENV=production boot with auto-generated or otherwise-insecure secrets — see #195).

Out of scope:

• Consumer application code. parbaked is a framework; vulnerabilities in apps built on top of it are the app maintainer's responsibility. Example: a consumer route that queries with raw SQL and is injectable is not a parbaked bug.
• Issues that require physical access to the deployment server.
• Issues in dependencies (FastAPI, SQLModel, pyjwt, slowapi, etc.) — report those upstream. We'll backport mitigations if there's a parbaked-side change worth making.
• Social engineering of the maintainer or contributors.
• Denial-of-service via expensive parbaked operations (e.g., generating a million signups to fill SQLite) — parbaked is single-instance by design, and rate limiting is consumer-tunable.
• Self-hosted-installation hardening (file permissions, OS-level config) — out of scope for the framework.

Reproduce vulnerabilities against a freshly-scaffolded test project (parbaked new vuln-test && cd vuln-test), not against production deploys. The test surface is the same and you don't risk anyone else's data.

• Acknowledgement within 5 working days.
• A fix planned within 30 days for high-severity issues, longer for lower-severity.
• Public disclosure coordinated with you, typically as a GitHub Security Advisory
  • a CVE if applicable.
• Credit in the advisory + the CHANGELOG entry, unless you'd prefer anonymity.

None yet. As security advisories ship, they'll appear in the Security advisories tab.