Coordinated disclosure
Report a vulnerability
A security plugin with a vulnerability in it is worse than no plugin at all, because it is trusted. If you have found a flaw in Total Security WP, we want to hear about it before an attacker does — and we would rather fix it than argue about it.
How to report
Please do not open a WordPress.org support-forum thread, a public issue, or a social media post about an unfixed vulnerability. Every install stays exposed for as long as the details are public and the patch is not.
Private security contact
Email [email protected] with the details below. Reports are read by a human, not a ticket bot.
Prefer an encrypted channel or a coordinating platform? Say so in a first message with no technical detail, and we will arrange one before you send anything sensitive.
If you would rather go through a third-party coordinator, reports submitted via the WordPress plugin-security programmes reach us too. Whichever route you pick, one report is enough — you do not need to send it twice.
What to include
The faster we can reproduce it, the faster it is fixed. A good report contains:
- The plugin version, plus WordPress and PHP versions.
- The vulnerability class — for example stored XSS, privilege escalation, authenticated SQL injection, path traversal.
- Reproduction steps precise enough to follow on a clean install, including the privilege level required (unauthenticated, subscriber, editor, admin).
- A proof of concept: request, payload, or a short script.
- The impact in plain terms — what an attacker gains.
- Anything relevant about the configuration: firewall mode, whether the finding depends on a non-default setting.
WordPress grants administrators the ability to run arbitrary code by design. A report that requires an administrator account to execute code is generally not a vulnerability in the plugin. Findings that cross a privilege boundary — unauthenticated, subscriber or contributor reaching something they should not — are exactly what we want.
Scope
In scope
- The Total Security WP plugin, all tiers, current release
- The firewall prepend and generated server rules
- The plugin's REST API and capability checks
- The standalone recovery endpoint
- The license token verification path
- Quarantine, repair and backup file handling
- A firewall bypass for a rule that should have blocked
Out of scope
- Vulnerabilities in WordPress core, or in other people's plugins and themes — report those to their authors
- Anything requiring an administrator account to exploit
- Missing hardening on this marketing site that has no security impact
- Automated scanner output with no demonstrated impact
- Denial of service through sheer request volume
- Social engineering of us or our users
- Reports asking for payment before disclosing details
Please research against a site you own or have written permission to test. Do not test against other people's WordPress sites, and never access, modify or exfiltrate data that is not yours.
What we commit to
| Stage | Target |
|---|---|
| Acknowledge your report | Within 3 business days |
| Triage — confirmed, duplicate, or not a vulnerability, with reasoning | Within 7 days |
| Fix released for a confirmed critical or high-severity issue | Within 30 days, sooner where exploitation is trivial |
| Public disclosure and credit | Coordinated with you, normally after the fix ships |
We will also:
- Keep you updated as the fix progresses, rather than going quiet after triage.
- Publish the fix in the plugin's changelog on WordPress.org and label it as a security change, instead of hiding it inside a generic “various improvements” line.
- Tell you honestly if a fix will take longer than the target, and why.
- Never ask you to sign an NDA as a condition of reporting.
Safe harbour
If you make a good-faith effort to follow this policy while researching a vulnerability, we will treat your research as authorised. Specifically, we will not pursue or support legal action against you, and if a third party brings action over research that followed this policy, we will make it known that you were acting in good faith.
Good faith means, concretely:
- You tested only against installs you own or are authorised to test.
- You did not access, alter, destroy or exfiltrate data belonging to anyone else, and stopped as soon as you had enough to prove impact.
- You did not degrade service for other users.
- You gave us a reasonable window to fix the issue before disclosing it publicly.
- You did not use the finding as leverage for payment.
If you are unsure whether something is within the rules, ask us first. We would much rather answer that question than have you not report at all.
Recognition
We do not currently run a paid bug bounty. What we do offer, for every valid report: credit under the name or handle you choose in the release notes and any advisory, and a straight answer at every stage. If you would prefer to stay anonymous, say so and we will credit the fix without naming you.
My WordPress site was hacked — is that this page?
No, and we do not want you to lose time here. This page is only for vulnerabilities in the Total Security WP plugin itself. If your own site has been compromised, the docs cover the response path directly:
- Run a full malware scan to identify infected files.
- Check file integrity against WordPress.org checksums to find modified core, plugin and theme files.
- Quarantine and repair — restore authentic files rather than deleting blind.
- Emergency recovery if wp-admin will not load at all.
- Then rotate every credential, and check the audit log for the rogue administrator account attackers usually leave behind.
Advisories
Security fixes are published in the plugin's changelog on WordPress.org, explicitly marked as security changes. Update promptly when one appears — the window between a public advisory and mass exploitation of a WordPress plugin is usually measured in days.