TLDR: Q2 2026 brought a Node.js 26 release, a major security release addressing 18 vulnerabilities with a streamlined 36-to-7-step process, the removal of the security embargo requirement, and a new LLM-assisted report classifier and web viewer for release management. The OpenJS CNA passed its one-year milestone, Ulises Gascón joined Alpha-Omega as an AI Security Engineer in Residence, and new tooling — the GHSA Dashboard and a CNA API proof-of-concept — is moving advisory operations forward.

The OpenJS Foundation's security team covered significant ground between April and June 2026. Here is a comprehensive look at what shipped, what changed, and what is still in motion.

Node.js 26 Arrives — the Last Under the Old Release Cycle

Node.js 26 shipped in May as a major release and the final one under the decade-old odd/even release model. Starting with Node.js 27 in October, every release will go LTS, version numbers will align to the calendar year, and the number of concurrent active release lines will shrink — a direct sustainability win for security backport work.

Node.js 26 shipped with the Temporal API enabled by default, ending years of dependency on third-party date libraries that carry their own vulnerability surface. For teams still relying on packages like date-fns, the native Temporal implementation is a meaningful supply chain risk reduction — a timely reminder given that date-fns itself was compromised earlier this year.

The new release schedule is covered in detail in the Node.js Collaboration Summit recap from London and in Rafael's Node.js security presentation at the summit (https://gamma.app/docs/Nodejs-Security-jznd05udav90fp0).

June Security Release: 13 Vulnerabilities

The June security release addressed 18 vulnerabilities across all active release lines. What made this release notable was not just the number of patches — 13 total, up from the previous norm of around 6–7 per release — but how it was handled.
Rafael Gonzaga has spent the last cycle building automation for Node.js security releases. Until now, he was effectively the only person using it. This release was different: Antoine joined to run through the full process alongside Rafael using the automation tooling:

A new web viewer for the security release process

A visual dashboard showing which reports are included, what is missing, and the checklist status for each line. Previously this was managed entirely from the terminal; at 18 patches, that is no longer practical.

LLM-assisted report validation built into the viewer. When a report is queued for inclusion, an LLM analyzes it against the Node.js threat model, prior accepted CVEs, CWE patterns, and historical report context, returning a confidence score and CVSS estimate. This is the same tooling Rafael prototyped in May and refined into the release workflow in June.

The tooling is in beta. The plan is to use the next security release as the real-world test, document it thoroughly, and record a walkthrough video for the security team.

Security Embargo Removed

One of the more structural changes this quarter: Node.js no longer requires a public security embargo for most patches.

The previous setup required that CI (the Node.js Jenkins environment) be locked down to TSC-only access during security release preparation — meaning a fix could not be tested until the embargo window was formally opened. That created a recurring problem: fixes written weeks or months in advance would fail CI checks during the release crunch, leaving the team scrambling.

The fix was simpler than the workarounds. Jenkins read-only access is now restricted to collaborators only. A contributor can write and test a patch the same day a report comes in, without waiting for an embargo window.

Permission Model: Audit Mode and Runtime Drop

The Permission Model continued to ship meaningful features this quarter.

--permission-audit mode (landed in April) gives teams a way to evaluate the Permission Model without breaking anything. Rather than enforcing restrictions and throwing errors, audit mode emits permission check events through the diagnostics channel. Teams can run their existing application, see every permission check that fires, and use that as the basis for building their grant set — before any enforcement is turned on. This addresses the most common reason teams have avoided adopting --permission: uncertainty about what their application actually needs.
permission.drop() (landed in May) lets an application reduce its own permissions at runtime after initialization. A server that only needs filesystem access during startup can drop network permissions once it is running. This makes least-privilege architecture practical for real production workloads, not just greenfield projects.

Ulises wrote in depth about why these capabilities matter now — and why npm v12's install-script blocking, while welcome, only addresses one moment in the attack timeline. The execution-time vector remains wide open without runtime permission constraints. Read the full analysis: Blocking Install Scripts Is Not a Silver Bullet (https://nodesource.com/blog/npm-v12-install-scripts-not-a-silver-bullet)

Handling the AI Report Flood

The Node.js security team received 352 HackerOne reports over the two years prior to this quarter. In February 2026 alone, reports spiked 4.6x following the arrival of AI agent-assisted scanning tools. March brought 65 reports in a single month.

This quarter's response continued on several fronts:

• HackerOne template update. Reproducible examples must now be in JavaScript. Previously, reporters could submit Python or other language examples, leaving maintainers to translate them before the issue could even be triaged. This one change eliminated a category of volunteer time sink.
• LLM report classifier (in development). Beth (working with IBM support) is helping build a dedicated classifier that receives an incoming HackerOne report and returns a confidence assessment before a human looks at it. Rafael has built a parallel prototype that is already in production use for the Node.js security team and has been integrated into the June release web viewer. Both initiatives are aimed at the same outcome: use automation to triage at volume, so human time goes to real vulnerabilities.
• AI contributions policy. The Node.js project formalized guidance on AI-assisted contributions in the spring. Two significant outcomes: pull requests are now expected to stay under 5,000 lines, regardless of whether AI generated them, and DCO sign-off is enforced more strictly. The underlying concern — that AI-assisted submissions can look correct on the surface while hiding subtle behavioral changes — drove the call for smaller, reviewable units of work. The security implications here are real: a 50,000-line AI-generated PR is not reviewable by any practical standard.

A Dashboard for Advisory Operations

Coordinating disclosure across dozens of repositories usually means living in scattered advisory pages with no shared view of where things stand. The GHSA Dashboard (v1.0.0, MIT) closes that gap: clone it and you get a populated 18-panel overview in minutes, covering advisory state, severity, CVSS, CWE ranking, throughput over time, time-to-publish, and the advisories aging in triage.

It is deliberately simple to run: plain Postgres, a single table that mirrors the GitHub API one to one, two containers, and a scraper of about a hundred lines. GitHub's own security team is reportedly building something similar internally, but this is available to any CNA or maintainer today.

Toward a CNA API

Today, CVE records move through the OpenJS CNA largely by hand, managed through manual GitHub workflows. The CNA API proof-of-concept, demonstrated at the OpenJS Security Working Group on June 22, sketches a different model: a standard interface that automates how advisories are created, routed, and published, so operational load drops and the process stays consistent as volume grows.

It is explicitly a proof of concept, not the final implementation. The goal right now is to align everyone on the model before the production version is built. Work is already underway to fit it to the existing Node.js release process and extend it to the Node Core Utils tooling, and the effort can be tracked in the Security WG.

OpenJS CNA: One Year In

The OpenJS Foundation CNA (https://cna.openjsf.org/security-advisories.html) passed its first year this quarter, and the numbers tell a clear story about how fast the landscape is shifting. A Grafana dashboard now tracks every published CVE across OpenJS projects at a glance:

In the second half of 2025 the CNA published 3 CVEs. Through the first half of 2026 that jumped to 49 published, with roughly 10 more in the pipeline waiting on releases and publication.

Those published CVEs count only valid vulnerabilities that are already patched. Behind them sits a far larger volume of invalid reports: on Express and Lodash alone, 70 to 90% of what comes in is rejected. So the jump reflects heavy triage more than a wave of new bugs, with AI-assisted scanning surfacing candidates across the ecosystem faster than manual research ever could.

A Dedicated Security Engineer in Residence

Security work across OpenJS projects has mostly run on volunteer, part-time effort. This quarter the Alpha-Omega Project funded a dedicated Security Engineer in Residence, held by Ulises Gascón, running from June through December. (announcement)

He continues as the de-facto first call for OpenJS coordinated disclosures, now with formalized on-call expectations, and as a trusted advisor for high-criticality maintainers facing supply-chain compromise, from assessment and disclosure coordination through mitigation, communication, and post-mortem. The scope is deliberately cross-ecosystem, because supply-chain events do not respect org boundaries. Building on the Alpha-Omega 2025 mentorship work, the role also brings a patch-quality review gate and consistent, documented criteria for the report classes that recur across OpenJS projects.

Much of this is being wired into automation, including the CNA API work described above, so operations keep running after the grant ends with less friction and far less volunteer time to sustain them.

ABI Stability Discussion Opens

A discussion is now open on whether Node.js should drop its longstanding V8 ABI stability commitment. The current policy requires maintaining compatibility with how V8 structures are mapped in memory — which is what makes V8 upgrades slow and why Node.js releases sometimes ship with a V8 version that is already months old.

Relaxing this would primarily affect projects that vendor Node.js into their own binaries (Electron being the most prominent example). It would not affect the vast majority of Node.js users. The benefit: faster V8 adoption, faster releases, and reduced delay on security patches that land in V8. A community discussion is underway before any decision is finalized.

What to Watch Next

The Node.js Collaboration Summit is planned for late September. If you have been thinking about contributing to Node.js security work and have not known where to start, that event is the right moment. Several contributors who joined the project in recent cycles came in through exactly that door.

The CNA API PoC will move toward implementation. The LLM report classifier is in beta. The June security release process, now with a second person running the tooling, will inform how the automation gets documented and opened up to the broader security team.

If you depend on Node.js or any OpenJS Foundation project and want to support the security work described here, reach out through the OpenJS Foundation Slack (https://slack-invite.openjsf.org) or the security collab space on GitHub (https://github.com/openjs-foundation/security-collab-space).

This update covers April – June 2026 and is produced with support from the Alpha-Omega Project (https://alpha-omega.dev).