Report a Security Issue
WPManageNinja values the security and privacy of our customers and the WordPress ecosystem. If you discover a security vulnerability affecting any WPManageNinja product (plugins, themes, SaaS components, or services), we ask that you report it responsibly so we can evaluate and remediate it quickly and safely.
We participate in coordinated disclosure processes and work with trusted third-party programs such as Patchstack. You should report vulnerabilities to either Patchstack or WPManageNinja Internal Team directly, do not notify both at the same time. (If you report to Patchstack, please follow Patchstack’s reporting rules; if you report to WPManageNinja, please follow the instructions below.)
Scope: What to report
We accept reproducible, exploitable issue reports that affect the security, confidentiality, integrity or availability of WPManageNinja products (plugins/themes), user data, or WPManageNinja infrastructure. These includes (but are not exclusive to):
- Cross-Site Scripting (XSS)
- Cross-Site Request Forgery (CSRF)
- SQL Injection (SQLi)
- Remote Code Execution (RCE)
- Server-Side Request Forgery (SSRF)
- Privilege escalation / broken access controls (e.g., low-priv user performing admin tasks).
- Authentication bypass, session fixation or insecure session management that enables account takeover.
- Exposure of sensitive secrets, API keys, DB credentials, or private customer data in plugin code, endpoints, or backups.
- Insecure deserialization or logic flaws that enable fraud (e.g., bypassing payment checks / coupon abuse leading to revenue loss).
- Any plugin code vulnerability that can be reproduced against an official WPManageNinja plugin version (report against the specific version).
Out of scope
These reports are not qualified for a reward program. But notifying us would help improve our service better and we would appreciate that.
Where & how to report
Do not publish or disclose the vulnerability publicly before remediation or coordinated disclosure.
Choose one of these reporting paths:
- Patchstack: If you prefer third-party handling, submit the report via Patchstack’s vulnerability disclosure process (Patchstack’s rules and timelines apply). Patchstack may disclose per their timelines and may request additional proof or an unaltered premium archive for validation
- WPManageNinja direct report: Submit the details in the following form. Do not send samples of customer data unless requested; see “Sensitive data” below.
When you submit a report, please include the following minimum information:
- Product name and exact version(s) affected
- A clear description of the vulnerability and impact
- Proof-of-concept (PoC) or steps to reproduce (redacted where necessary, see “PoC expectations”)
- Any affected URLs, endpoints, or plugin/theme ZIPs (for premium plugins, supply an unaltered copy if requested to validate)
- Your preferred contact details and any timeline constraints.
Report via Patchstack
If you report via Patchstack, Patchstack will coordinate disclosure and may provide reward opportunities under the Patchstack Alliance/bug bounty framework; WPManageNinja may independently credit or reward researchers as appropriate but will not duplicate Patchstack-administered rewards unless otherwise arranged.
CVE requests & credits
Valid, confirmed vulnerabilities may be assigned a CVE upon request. If you would like a CVE, indicate this in your report.
We will credit researchers in the coordinated disclosure notice unless you request anonymity.
Rewards & acknowledgements
WPManageNinja does not guarantee a monetary reward for every report. We may offer recognition, swag, or bounties on a case-by-case basis; rewards may be processed in coordination with third-party programs (e.g., Patchstack) when applicable. If you expect compensation, note this in your submission. (See Patchstack pages for how they handle bounty distributions.)
It is to be noted that, only the first report of a specific issue will be acknowledged or rewarded.
PoC expectations & safe testing
We welcome reproducible PoCs but insist on responsible testing:
- Avoid running destructive tests on production customer sites.
- Refrain from exfiltrating real customer data. If a proof requires sample data, use non-sensitive test samples and clearly label them.
- If sensitive data exposure is required to validate impact, coordinate with us first and follow any instructions we give for collecting redacted evidence.
- Provide step-by-step reproduction instructions, expected and actual results, and any logs. If browser console or server logs help, include sanitized extracts.
Sensitive data & privacy
Do not send full customer records, payment data, or private keys. If such data is inadvertently included, mark it and notify us immediately; we will securely delete or redact as needed.
We will treat vulnerability reports and researcher data in line with applicable privacy laws and with discretion during remediation.
Third-party code, integrations & supply chain
If the vulnerable code appears to originate in a third-party library, theme, or external service, we will coordinate disclosure with the third party and share validation materials where necessary. You may submit the report to Patchstack for ecosystem handling or report to the original vendor in parallel (but please avoid duplicative reporting to WPManageNinja and Patchstack simultaneously).
Legal considerations & safe harbor
We support good-faith security research. If you follow this disclosure policy, act lawfully, and avoid data exfiltration / disruption, WPManageNinja will not pursue legal action for the vulnerability research conducted in compliance with this policy.
Do not attempt to exploit vulnerabilities beyond what is required to demonstrate impact. Denial-of-service and other high-impact testing must be approved in advance.
Note: This policy does not grant permission to violate laws; it only clarifies WPManageNinja’s intended response to good-faith researchers who adhere to this policy.
Severity classification & remediation priority
We will triage reported issues and classify them by severity (Critical, High, Medium, Low) based on impact to confidentiality, integrity, and availability. Critical and High issues will receive the highest remediation priority.
Disclosure & publication rules for researchers
Please do not publicly disclose the vulnerability until WPManageNinja (or Patchstack, if they are coordinating) publishes a coordinated advisory.
We will work with you to determine an appropriate disclosure timeline. We request at least 30 days from the time of reporting before any public disclosure. For critical vulnerabilities, we may request additional time to ensure proper remediation. We may request temporary non-disclosure while we patch and release fixes. Once a patch is available and public, we will coordinate credit and disclosure wording.
Acknowledgement
Researchers who responsibly disclose issues may be acknowledged on our changelogs unless they ask for anonymity. If you wish to be credited, please include your preferred handle and a short bio in your submission.
Examples of expected report contents
- Product name & version.
- Vulnerability type (e.g., SQLi, XSS, auth bypass).
- Steps to reproduce (concise, ordered).
- Proof-of-concept (PoC) or minimal exploit (redacted if sensitive).
- Screenshots, logs, sample payloads.
- Whether the vulnerability exists in free or premium builds (if premium, include archive if requested).
- Your contact details and CVE request / reward expectation.
Why this matters
Responsible disclosure helps protect WPManageNinja users and the broader WordPress ecosystem. We appreciate researchers who help identify and responsibly disclose vulnerabilities so we can fix them before attackers can exploit them.
