Why We Publish Unpatched Vulnerabilities

Today, we published 26 unpatched WordPress vulnerabilities. Why?

That is a fair question.

Publishing vulnerabilities for which no patch is available is not a decision we take lightly. It exposes an uncomfortable conflict at the heart of vulnerability research: vendors need time to investigate and fix security issues, but users also have an interest in knowing about risks that affect the software they rely on.

Keeping a vulnerability private can protect users while a fix is being developed.

Keeping it private indefinitely is not automatically the safer choice.

We found these vulnerabilities with the help of our own scanner, investigated their impact and reported them privately before publication. The 26 advisories we published today are not the result of skipping responsible disclosure. We contacted the vendor, sent repeated follow-ups and communicated disclosure deadlines without receiving a meaningful response.

And that raises a broader question:

What should security researchers do when responsible disclosure becomes one-sided?

Make verification easy

When we report a vulnerability, our goal is to give the vendor clear technical evidence and make verification as straightforward as possible.

For vendors who engaged with us, we provided proof-of-concept material. In many cases, this included Docker-based reproduction environments and scripts for Windows and Linux. The scripts set up the necessary environment and demonstrated the attack against the software version current at the time of testing.

The intention is simple: reduce the cost of verification as much as reasonably possible.

Security teams and maintainers are busy. Reports compete for attention, and complex findings can require significant time to reproduce. We understand that, and we try to remove as much of that work as possible.

But once a vulnerability has been reduced to a reproducible technical demonstration, its validity should be judged on the evidence.

Not on how elegantly the report was written.

And certainly not on whether AI helped turn technical research into a readable report.

A vulnerability does not become less real because AI helped write the report.

Equally, a polished report does not make a vulnerability real. We remain responsible for our technical claims, their prerequisites and the impact we describe.

The questions should be straightforward: can the behavior be reproduced, under which conditions, and with what security consequences?

When the disclosure process stops working

Our decision to publish did not emerge from a single unanswered email.

It grew out of a recurring problem we have encountered while reporting vulnerabilities.

We have seen reports classified as duplicates while the underlying vulnerabilities remained unfixed for months. We have received “informational” classifications that, in our assessment, did not reflect the demonstrated security impact. We have also encountered cases where AI-assisted report preparation became a reason to dismiss a report rather than evaluate its technical evidence.

And we have contacted designated security channels, followed up and still received no meaningful response.

None of this means every duplicate decision is wrong or every severity disagreement is unreasonable. A vendor may already know about a vulnerability. Researchers can overestimate impact. We can be wrong, too.

But a closed report is not the same thing as a fixed vulnerability. And a disagreement about impact should be resolved through technical analysis, not by treating a classification as the end of the discussion.

Researchers are expected — correctly — to disclose vulnerabilities responsibly.

But responsible disclosure requires someone on the other side.

Responsible disclosure cannot mean indefinite silence

We believe vendors deserve a fair opportunity to investigate and remediate vulnerabilities before they become public.

That is why we disclose privately first, provide technical information, support reproduction, send follow-ups and communicate a disclosure deadline.

But eventually, a deadline has to mean something.

Otherwise, an unintended incentive emerges:

A vendor that engages with security researchers is under pressure to investigate and fix a vulnerability, while a vendor that simply does not respond can effectively keep the same vulnerability confidential indefinitely.

That cannot be the outcome of responsible disclosure.

There is an important difference between a vendor actively investigating a difficult fix and a vendor providing no indication that the report is being investigated at all. Meaningful engagement gives researchers a basis for continued coordination. Silence does not.

Our Responsible Vulnerability Disclosure Policy sets out our approach. This article explains the principle behind it: a deadline is not a substitute for judgment, but an unanswered report cannot create an unlimited claim to confidentiality.

Responsible disclosure is a process. It is not an indefinite obligation for researchers to remain silent.

Silence does not make a vulnerability disappear

There is another assumption we believe deserves scrutiny: that an unpublished vulnerability is necessarily unknown to attackers.

The fact that we discovered a weakness does not mean nobody else has discovered it.

That is not a claim that these vulnerabilities are being exploited in the wild. We should not imply active exploitation without evidence. But the opposite assumption is also unjustified: the absence of public documentation does not establish that attackers are unaware of an issue.

We cannot know whether we are the first people to find a particular weakness.

We can only know when we found it.

Private disclosure can create valuable time for remediation. It cannot guarantee that researchers and the vendor are the only people aware of the vulnerability.

This matters especially for widely used software. A vulnerability is not merely an issue between a researcher and a vendor. The consequences are ultimately carried by the organizations and individuals operating that software.

They have a legitimate security interest too.

The practical risk still depends on each finding’s prerequisites. Twenty-six advisories do not mean every installation is vulnerable to every issue. That is another reason to publish precise technical information rather than rely on alarming headlines alone.

Transparency is not weaponization

There is an important distinction between disclosing a vulnerability and making exploitation unnecessarily easy.

For these advisories, we deliberately chose not to publish weaponized exploits or our proof-of-concept material.

We published technical descriptions and relevant code locations so that our claims could be examined and the underlying problems understood. We did not publish the reproduction packages prepared for private verification.

That distinction matters, but it has limits.

A capable attacker may still be able to develop an exploit from a technical description. Identifying affected code can lower the barrier to investigation. Withholding a working proof of concept does not make publication harmless.

We take that risk seriously.

Our objective is to provide information that supports scrutiny and informed defensive decisions without also supplying a ready-to-run attack.

Transparency and weaponization are not the same thing. Neither are transparency and zero risk.

Responsible disclosure does not have to offer a binary choice between complete secrecy and publishing a turnkey exploit. There is meaningful space between those extremes.

The question is not whether disclosure eliminates risk. It is whether continued secrecy remains justified, and what information should be released when it no longer does.

Why public disclosure matters

Public disclosure serves another purpose: accountability.

Security problems that remain invisible can be easier to postpone. Public documentation allows users, operators and independent researchers to ask questions that previously only the reporter could ask.

Yes, that creates pressure. That is part of the point.

We want credible vulnerabilities to be investigated and addressed, rather than remain unresolved and invisible to the people affected. That pressure should remain focused on the technical evidence and remediation, not personal attacks on maintainers.

It also has a purpose beyond accountability. Operators may need to assess their exposure, reconsider affected functionality or apply mitigations where those are available.

Not every vulnerability has a practical workaround, and an advisory is not a substitute for a patch. But people cannot make informed decisions about a risk they have not been told exists.

Protecting a vendor from uncomfortable publicity cannot take precedence indefinitely over informing the people who actually bear that risk.

Our concern is not whether a report receives a particular status in a submission portal. It is whether the underlying security problem is understood and addressed.

Disclosure is a shared responsibility

There is a great deal of justified discussion about what responsible behavior looks like for security researchers.

Researchers should contact vendors privately, provide sufficient information to reproduce their findings, avoid exaggerating impact and allow reasonable time for remediation. They should communicate before disclosure and think carefully about how much exploit information needs to become public.

We agree.

But responsibility cannot exist only on one side of the communication channel.

Vendors also have responsibilities: to maintain reachable security contacts, evaluate reproducible reports on their technical merits, communicate with researchers and take credible vulnerabilities seriously.

Accountability applies to us as well. Our findings should withstand scrutiny. Demonstrated behavior, exploitation prerequisites and assessed impact should be clearly distinguished. Where new evidence changes a conclusion, the public record should reflect that.

We welcome substantive technical disagreement. We do not expect every initial assessment to be accepted unchanged.

What we do expect is that credible evidence receives a technical response.

What we want to achieve

We would much rather work constructively with vendors, help reproduce our findings and eventually update an advisory with a simple sentence:

Fixed in version X.

That is the outcome we want.

We are not publishing these vulnerabilities because an unpatched vulnerability makes for a better headline. A verified fix is a better outcome than a headline.

We are doing it because we believe security improves when vulnerabilities are investigated, understood and ultimately fixed — and because transparency becomes necessary when the private process fails to produce that outcome.

Our first choice will continue to be cooperation.

Our goal is remediation.

Our responsibility includes giving vendors a fair opportunity to get there.

But our responsibility does not end with the vendor.

It also extends to the people and organizations relying on the affected software. They deserve the opportunity to understand the risks they are carrying, make informed security decisions and apply mitigations where possible.

Responsible disclosure requires responsibility from both sides.