Coordinated disclosure
Ninety days, and the clock starts when we make contact.
Our researchers find vulnerabilities in widely deployed software as well as in client systems. This is what happens next — published so a vendor hearing from us knows exactly what to expect, and so anyone reading our advisories knows how they came to be there.
- 1We contact the vendor first
Before anything is published, and before a CVE is requested. We use the vendor’s published security contact where one exists — a security.txt, a disclosure page, a bug bounty programme — and look for a human if it does not. The report includes what the flaw is, where it is, how to reproduce it and what an attacker gets.
- 2The clock starts at first contact
Ninety days. It starts when we make contact, not when the vendor chooses to reply, because otherwise silence would be a way to stop the clock. If we cannot find any contact route at all, we will say so in the advisory.
- 3We coordinate, and we will move
If a vendor is engaged and needs longer for a legitimate reason — a complicated fix, a release train, a coordinated upstream patch — we will extend. We would rather a fix landed properly than land a deadline. What we will not do is extend indefinitely for a vendor who has stopped replying.
- 4A CVE is requested where one applies
So that users of the product can track it, and so the record exists independently of us. Where the vendor is a CNA for their own product, that is their call to make.
- 5We publish after the fix, or after 90 days
Whichever comes first. The advisory goes on our advisories index with the affected versions, the fixed version where one exists, the references and the researcher credited by name.
The other half
What we do not do
- We do not sell what we findNot to brokers, not to governments, not to anyone. A flaw we find in third-party software goes to the vendor. Every advisory we have published went to the vendor first.
- We do not publish a working exploitOur advisories describe the vulnerability class, the affected component and the impact at the level a vendor advisory does. Where a proof of concept is already public we may link it; we do not add one.
- We do not publish without trying to make contactEven where a vendor has no security contact, no disclosure page and no obvious owner. If we publish without a reply, the advisory records what we tried.
- We do not hold findings indefinitelyA vulnerability that is never disclosed protects nobody but the vendor. Ninety days is long enough to fix a flaw and short enough that users are not left exposed while nothing happens.
If you are a vendor we have contacted
Reply to the address the report came from, or write to [email protected]. If you need a secure channel, ask and we will set one up. We are not trying to catch you out: an extension for a vendor who is engaged and fixing the problem is almost always available, and a fixed flaw is a better outcome than a punctual advisory.
FAQ
Questions about disclosure
What if the flaw is already being exploited?
Then the ninety days may not apply. Where we have reason to believe a vulnerability is being exploited in the wild, the balance shifts from giving the vendor time to giving users a chance to defend themselves, and we may publish sooner. If we do that, the advisory will say so and say why.
What if the vendor does not reply?
We publish at ninety days. The advisory records that contact was attempted and went unanswered. We would much rather coordinate, but a vendor who does not engage cannot stop the clock by staying silent.
Can a vendor get an extension?
Yes, where they are engaged and there is a real reason — a complicated fix, a release cycle, an upstream dependency, a coordinated multi-vendor issue. Ask us. What does not earn an extension is going quiet and then objecting at day eighty-nine.
Do you report flaws you find during a client engagement?
If we find a vulnerability in third-party software while testing for a client, the finding belongs in the client’s report first. Disclosing it onwards to the vendor is a separate decision, made with the client, because it may expose that they were testing. We do not disclose a client’s identity to a vendor, ever.
Does this cover flaws in your own systems?
No. That is the other direction, and it is on our trust page along with our security.txt. If you have found something in a PXLSec site or in software we publish, we want to hear about it.
Need to reach us about a report?
Tell us what you want to protect. A senior tester will help you agree the scope and next steps. We usually reply within one business day.
Confidential from the first conversation
We can sign your NDA before you share sensitive details. Your enquiry is covered by our privacy policy.
How we protect your information · Privacy policy