Vanilla-PHP-SaaS-Kit is authentication and account-management software: its whole job is to guard other people's accounts. We take security reports seriously and appreciate the time it takes to file a good one.

Please read this page before reporting — a little context up front makes reports faster to triage and act on.

This is a starter kit that people fork and self-host. There is no central service we can silently patch on your behalf. A fix landing here does not fix the running copies — every operator has to pull the change and redeploy. That shapes how we handle disclosure:

• We treat reports as affecting every deployment built on this code, not one site, so we err toward coordinated, private disclosure until a fix is available.
• The most valuable reports are about the framework code in this repository, not about a specific site that happens to run it (see scope below).

This project is distributed from source rather than as pinned releases, so security fixes are applied to the default branch (main/master). If you are running an older fork or an out-of-date copy, the first remediation step is usually to update to the current default branch and re-run the migrations.

The kit targets PHP 8.0+ (tested on 8.3). Reports that only reproduce on end-of-life PHP versions, or on configurations the README explicitly advises against, may be closed with guidance rather than a code change.

Please do not open a public issue, pull request, or discussion for a suspected vulnerability. A public report tells every operator's attacker about the flaw before operators can patch it.

Instead, use one of these private channels:

1. GitHub private vulnerability reporting (preferred). On the repository's Security tab, choose Report a vulnerability. This opens a private advisory visible only to you and the maintainers.

2. Email. Send details to the maintainer's email address: me@jasonbloomer.com

If you cannot use either, open a minimal public issue that says only "I have a security report, please provide a private contact" — with no technical detail — and wait for a private channel before sharing specifics.

A report we can act on quickly usually has:

• The affected file(s) or endpoint(s), and the commit or branch you tested.
• The vulnerability class (e.g. authentication bypass, privilege escalation, SQL injection, XSS, CSRF, SSRF, insecure direct object reference).
• Clear reproduction steps or a minimal proof of concept.
• The impact — what an attacker gains, and what preconditions are needed (authenticated vs. unauthenticated, required access level, etc.).
• Any suggested fix, if you have one. It is welcome but not required.

Please test only against your own installation. Do not attempt to exploit, scan, or "prove" a finding against anyone else's live deployment.

This is a small, volunteer-maintained open-source project, so timelines are best-effort rather than contractual:

• Acknowledgement: we aim to confirm receipt within a few days.
• Assessment: we validate the report and tell you whether we consider it in scope and how we rate its severity.
• Fix & disclosure: for confirmed issues we work on a fix privately, then publish it together with an advisory once it lands on the default branch. We will coordinate timing with you and are happy to credit you (or keep you anonymous) in the advisory.

If a report turns out to be out of scope or a configuration issue, we will still explain why, and where relevant point you at the right documentation.

In scope — vulnerabilities in the code in this repository, for example:

• Authentication or session flaws (bypass, fixation, token forgery, weak comparison, privilege escalation between access levels).
• Injection (SQL, header/email, command) and cross-site scripting.
• CSRF on state-changing actions, insecure direct object references, or missing authorization checks.
• Server-side request forgery in the OAuth or outbound-request paths.
• Insecure defaults, or documented deployment steps that leave a fresh install exploitable when followed as written.

Out of scope — typically not treated as vulnerabilities in this project:

• Findings that require an already-compromised server, database, or admin account, or that assume the attacker already holds Developer (level 5) access.
• Issues caused by an operator's own misconfiguration against the project's documented guidance (for example, leaving env.php inside the web root when the README tells you to move it above it, disabling the shipped .htaccess rules, or running with display_errors on in production).
• Missing security headers or hardening that the Developer Console exposes as a deliberate toggle (such as HSTS, which ships off until you have a valid certificate) — turn it on rather than reporting it.
• Vulnerabilities in third-party infrastructure you run alongside this (your PHP build, web server, MySQL/MariaDB, host).
• Denial of service from unrealistic traffic volumes, missing rate limits on non-sensitive endpoints, or self-XSS.
• Reports generated solely by automated scanners with no demonstrated, reproducible impact.

The one vendored dependency, PHPMailer, is pinned in assets/vendor/. If you find an issue in PHPMailer itself, please report it upstream to that project; if the issue is in how this kit uses PHPMailer, report it here.

We will not pursue or support action against researchers who:

• act in good faith and follow this policy,
• test only against installations they own or are explicitly authorized to test,
• avoid privacy violations, data destruction, and service disruption, and
• give us a reasonable opportunity to fix an issue before disclosing it publicly.

If you are unsure whether something is in scope or whether an action is acceptable, ask first through one of the private channels above.

No codebase makes a deployment secure on its own. If you run this kit in production, the baseline is: move env.php above the web root, keep the shipped .htaccess rules in place, serve everything over HTTPS and enable HSTS once your certificate is in place, keep PHP and your database patched, and review your own changes. This is a starter kit meant to be built on, and your additions are your responsibility to secure.