Security research

Vulnerability disclosure policy

Last updated: 17th October 2026

This vulnerability disclosure policy explains how BugShield validates findings from its WordPress theme research, contacts developers privately and coordinates publication once fixes are available.

Local validation and evidence

Potential weaknesses go through additional analysis to establish whether the suspected behaviour can be reproduced. The verification workflow uses locally deployed WordPress environments, without interacting with live websites.

Proof-of-concept tests are working demonstrations of a suspected weakness. Where testing confirms a vulnerability, the evidence is retained for private disclosure to the affected developer. Suspicious code alone does not establish that a vulnerability has been demonstrated.

How developers will be contacted

BugShield will first use the developer's published security reporting address or private vulnerability reporting channel. If neither is available, we will use a contact email or private contact form published on the developer's official website or linked from their WordPress.org author profile.

The initial message will identify BugShield and the relevant product and ask for confirmation of the appropriate recipient. Technical evidence will be shared privately after that contact has been established. Public support threads will not be used to disclose the finding or post reproduction instructions.

What a private report will contain

The report will identify the tested theme and version, describe the observed behaviour and explain the conditions required to reproduce it. Supporting proof-of-concept evidence and local testing details will help the developer investigate.

Reports will distinguish demonstrated behaviour from unresolved questions. The number of installations of a theme will not be presented as a count of sites confirmed to be vulnerable.

Coordinating a fix

BugShield will ask the developer to acknowledge the report and agree a private route for technical follow-up. We will coordinate discussion of a fix and its availability with the developer.

When a candidate fix is provided, the relevant behaviour will be checked in a local environment. A proposed change or an acknowledgement alone will not be treated as an available patch.

When details will be published

For this research, each affected theme name and its vulnerability details will remain private until a patch for that theme is available. Publication will be considered for each finding separately, so a fix for one theme does not release details of another.

BugShield will not publish proof-of-concept exploit code or technical reproduction instructions before developers have had an opportunity to release fixes. Once a patch is available, public guidance will focus on the affected versions, the fixed version and the action site owners need to take.

If a developer cannot be reached

BugShield will follow up through available private contact routes. If contact cannot be established or a patch is not available, the affected theme name and technical details will remain private under this policy. Lack of a response will not be described as an acknowledgement or a resolved issue.

Contact BugShield

Developers can contact [email protected] to confirm that a disclosure message came from BugShield or to arrange a private discussion. The first reply should identify the product and report reference, where supplied. Do not send customer credentials or personal data.

Email BugShield

Read the BugShield Scout research

This policy covers BugShield’s disclosures to third-party developers. Reports about BugShield systems are covered by the separate security research and reporting policy.

Accessibility settings

Adjust how this site looks and moves. Your choices are saved in this browser.