The OpenJS CNA Pause: An Unreproduced Report Is Work You Handed Someone Else

As of September 18, 2026.

A security report you have not reproduced is a request for someone else to reproduce it. Language models made those requests nearly free to write, and the people who read them are mostly volunteers. The OpenJS Foundation's CVE team has now stopped reading for three weeks.

What the foundation announced

On September 11 the OpenJS Foundation CNA said it would pause its security operations from September 17 to October 6, 2026, both days included. A CNA, or CVE Numbering Authority, is the body that assigns CVE IDs and publishes advisories; this one's scope is projects the foundation hosts.

The pause covers all CNA activity: triage, acknowledging new reports, validating advisories, assigning CVEs and publishing them. Escalations, the reports sent to the CNA because a project did not answer in time, are paused too. Email and advisory channels stay open, but anything sent is queued for after the team returns on October 7. Express, an OpenJS-hosted project, joined the break.

The reason is stated in one paragraph. Over the last several months, the foundation wrote, the volume of advisories and CVE requests "has grown sharply," and "a significant part of that growth comes from reports generated or assisted by large language models." Many are low signal, and each one still takes a volunteer's time to separate from noise.

There is an exception. For a vulnerability being actively exploited, or a critical issue posing immediate risk, the CNA still responds through the #security channel on the OpenJS Slack. The channel is public, so the foundation asks reporters to keep the first message high-level and mark it urgent.

The numbers behind it

The foundation laid out the problem in February, in a post titled AI is stress testing open source. Node.js usually receives six to seven vulnerability reports a month. Between December 15 and January 15 it received over 30, against three in the same window a year earlier.

The line the September announcement quotes from that post is the clearest statement of the problem: "AI has lowered the barrier to generating security reports, but not the cost of handling them." Writing a plausible report now takes minutes. Reading one still takes a maintainer who knows the code, checks the claimed path, and tries to make it fail.

A pattern, not a one-off

OpenJS is following curl. Daniel Stenberg's project took July off from vulnerability reports, after what he called "a huge pressure for the last four months or so." His post-mortem on August 3 called it "possibly our best project decision in a long while," with no CVE assignments needed during the break and paying support customers unaffected.

He also named the risk on the way back. Queued reports could "hit us in a short period time" once intake reopened, with more duplicates than usual. OpenJS's queue reopens on October 7.

A pause gives volunteers rest, and on curl's evidence it costs little security. It does not shrink the pile. The reports filed during these three weeks will all land on the same people in October, and the real ones will wait behind the rest.

If you use AI to find bugs in open source

The cost of a report now sits with whoever sends it, or it lands on a volunteer. The February post lists what reporters should do, and each item is a step the sender can do and the reader cannot do for them.

• Reproduce it on a released version. Run the proof of concept yourself and include the one you ran, not the one the model described.
• Check it against the project's threat model. A finding that needs the attacker to already control the config file is often out of scope by design. Read the project's security policy first.
• State the impact you saw. "Crashes the process with this input" is a report. "Could potentially lead to remote code execution" with no demonstration is a request for research.
• Drop what you cannot make fail. A model's confident explanation of a bug is not evidence the bug exists. If you cannot trigger it, do not file it.
• Hold non-urgent reports to OpenJS projects until October 7, as the foundation asks, and use the Slack channel only for active exploitation.

Our August post on AI vulnerability research looked at the same gap from the research side: published campaigns report what they found, and almost nobody outside them checks the candidates that did not hold up. A maintainer's inbox is where those candidates end up.

If you consume OpenJS projects

For three weeks, a quiet CVE feed for an OpenJS-hosted project means the people who would publish a CVE are on break. It says nothing about whether new bugs exist.

• Do not read silence as safety. Scanners that key on CVE and advisory feeds depend on someone publishing the record, and this CNA is not publishing until the queue moves.
• Expect a burst after October 7. Plan time to triage advisories for Express and other hosted projects in the weeks after the team returns, and triage them like any other finding: check whether the vulnerable path is reachable in your code before rushing an upgrade.
• Know the emergency path. If you find a hosted project being actively exploited, the OpenJS Slack #security channel is the route during the break.
• Fund what you depend on. The February post asks companies that rely on OpenJS projects to invest upstream, through membership, funding or engineer time. A security team that ships Node.js in production is one of those companies.

Where the cost lands

Every report used to cost its author some effort, and that effort filtered out most of the noise before a maintainer saw it. Language models removed the author's share and left the reader's. Until reporters take that share back by reproducing before they send, the only control a volunteer team has left is the one OpenJS just used: stop reading for a while.