Vulnerability disclosure policy

Scope

This policy governs vulnerabilities that Starfish Security researchers discover independently in third-party software: open source projects, WordPress plugins and themes, commercial products, and internet-facing services. It is the basis for the CVEs on our research page.

It does not cover client engagements. Anything we find under contract belongs to the client, is governed by that engagement's rules, and is never published without the client's written consent.

Our commitments

• Vendor first. We never publish, sell, or share vulnerability details before the vendor has had the chance to fix them, except as described in the timeline below.

• Complete reports. Every report contains affected versions, a working proof-of-concept, the root cause, and a suggested fix, so the vendor can reproduce and remediate immediately.

• Minimal footprint. We only go as far as needed to prove impact. We do not access, modify, or exfiltrate user data, pivot into internal systems, or degrade a live service.

• Expert-verified. Every finding is reproduced and confirmed by a Starfish researcher before any report leaves our hands. We do not send unverified scanner output to vendors.

• No strings attached. We do not ask for payment, a bounty, or a contract as a condition of reporting or of staying quiet. Vendors that run bounty programs are welcome to reward the report under their own rules.

• Credit, not blame. Our advisories describe the flaw and the fix, and credit vendors that respond well. We name unresponsive vendors only because users deserve to know what is unpatched.

1. Day 0

   Private report

   We send the full report to the vendor's security contact, or through a coordinating CNA when the vendor has none. The clock starts the day the report is sent, not the day it is read.

2. Day 0–14

   Acknowledgement

   We expect an acknowledgement within 14 days. If none arrives we retry through every public channel we can find: security@ addresses, bug-bounty programs, support desks, GitHub, social profiles, and the CNA.

3. Day 1–90

   Coordinated window

   The vendor has 90 days to ship a fix. During that time we answer questions, retest candidate patches, and keep every detail private. Nothing is shared with third parties.

4. Fix released

   Publication

   Once a fix is generally available we publish the advisory and request the CVE be made public. If a fix ships early, we publish shortly after it, giving users time to update first.

5. Day 90

   Deadline

   If no fix is available and no extension has been agreed, we publish on day 90. This applies equally to vendors who never replied: silence does not stop the clock.

Exceptions

• Extensions. A vendor actively working on a fix can ask for more time before the deadline. We grant reasonable extensions when a release date is committed; we do not grant open-ended ones.
• Active exploitation. If we see the vulnerability being exploited in the wild, or it becomes public through another party, the window shrinks to 7 days so users can defend themselves.
• Silent fixes. If a vendor patches without an advisory or a CVE, we publish once we confirm the fix has shipped, so users know they need to update.
• Abandoned software. For projects with no maintainer and no contact, we notify the ecosystem (plugin directory, distribution, CNA) and publish on the standard schedule so the software can be removed or forked.

What we publish

Every advisory carries the CVE identifier, affected and fixed versions, a technical analysis of the root cause, a proof-of-concept that demonstrates real impact, and the complete disclosure timeline with dates, so anyone can see how the process went. Where a fix exists, the PoC is published only after users have had time to apply it.

We request CVE identifiers through the vendor's own CNA or a coordinating CNA (for example Wordfence or Patchstack for the WordPress ecosystem) so each issue is tracked in the public record independently of us.

Received a report from us?

Reply to the original message or email info@starfishsec.com with the report reference. We will confirm the researcher's identity, walk you through reproduction, retest your fix, and agree the publication date. Everything stays confidential until then.

Found something in our own systems?

We hold ourselves to the same standard. Report vulnerabilities in this website or any Starfish service to info@starfishsec.com. Good-faith research that respects this policy, avoids privacy violations and service disruption, and gives us a reasonable time to fix will never be met with legal action. We will acknowledge within 14 days, keep you informed, and credit you when we publish.