Private security reports
A security problem in the software (a way to see or change what one should not) must reach the people who can fix
it, and must not reach attackers first. This page tells an owner and their team what to do with such a finding. The
rules come from SECURITY.md at the root of every installation.
Two different situations
| Situation | What it is | What to do |
|---|---|---|
| A weakness in Exponential itself | Anyone running the same version could be affected | Report it privately to the project (this page) |
| A break-in or misuse of your site | Something happened on your site: unknown accounts, changed files, pages you did not publish | Call your host now; it is a severity 1 incident (When the site is down, Compromised site) |
Sometimes the second leads to the first: the investigation finds that the cause is a weakness in the software. Then both apply.
Report it privately
"Please report security issues privately by e-mail to [email protected], not in the public issue tracker or the
discussions" (SECURITY.md). The help's error report page also offers GitHub's private vulnerability reporting of
the repository (When something goes wrong).
Do not post it in a public issue, a forum, a chat, a pull request or a social network.
What to include
SECURITY.md asks for:
- the version (
composer show se7enxweb/exponential, or the tag or commit you run) and the PHP version; - the engine that serves the site (Exponential Velocity, FrankenPHP, Apache or nginx with PHP-FPM) and the database;
- what an attacker can do, and the steps to reproduce it.
Leave out passwords, secrets and personal data (same file). Reproduce the problem on a test copy if you can, never against someone else's site.
Usually your administrator or partner writes the report, because they can describe versions and steps precisely. The owner's job is to make sure it is sent, privately, and to know it was sent.
What happens next
From SECURITY.md:
- "You can expect a first answer within one business day."
- "You will be told whether the report is accepted or declined, and kept informed while a fix is prepared."
- "An accepted issue is fixed on
mainand released with the next 6.0.x version."
That first answer is the only response commitment in the project's own files (Contracts and SLA basics).
While you wait for the fix
- Keep the finding to the people who need to know.
- Ask your partner or host whether a temporary measure (a configuration or web server rule) protects your site in the meantime; the hardening guides describe many (Security hardening).
- When the release with the fix appears, have it applied quickly (Upgrades with your provider).
- Partners do not tell the public before a fix is released (Escalations and security issues); hold your own communications to the same rule.
Extensions from other authors
An extension that is not part of the project has its own author and its own security contact, if any. Check the extension's repository for a security policy; if it has none, contact its author privately rather than in public. The Info > About page names each extension's website (About and Copyright pages).
Personal data
If customers' personal data may have been exposed, there may be legal duties to report it. Ask your data protection officer or lawyer at once. This page is not legal advice; see GDPR basics.
Related pages
- Security basics
- Security updates and disclosure (for businesses)
- Reporting problems
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.