Correct Code, Wrong Baseline: The Hidden Security Risk of AI-Assisted Node.js Development

by:

in ai on Sep 17 2026

AI coding tools are becoming increasingly capable of writing software that compiles, passes tests, and solves real engineering problems.

But generating working code is only part of what these systems now do.

When an AI assistant creates a Node.js project, it may also influence decisions about:

which Node.js version to use
which dependency versions to install
which Docker image becomes the production baseline
how CI environments are configured
which packages developers introduce to solve a problem
which APIs and security practices become part of the application

Those decisions can survive much longer than the generated code itself.

A runtime version placed in a Dockerfile today can remain in CI pipelines, internal templates, base images, and production infrastructure for years.

That changes the security question.

The question is no longer only:

Can AI generate secure code?

It is also:

Can we trust the technical defaults AI helps us choose to remain correct as the ecosystem changes?

That distinction matters in Node.js, where the runtime, its bundled dependencies, the package ecosystem, and the security landscape continue evolving long after an application is first deployed.

A Node.js version does not become “old” only because newer features exist.

Supported releases keep receiving security fixes for vulnerabilities that developers could not have anticipated when the original code was written.

And that is where AI-assisted development and runtime security begin to intersect.

Running an EOL Version of Node.js?

An unsupported runtime may continue working today while security, dependency compatibility, and operational risk accumulate around it.

Understand your application's upgrade risk and build a clear path to a supported Node.js release with the NodeSource Upgrade Program.

Assess Your Node.js Upgrade Risk →

Your Code Can Be Correct While the Baseline Is Wrong

A growing body of research suggests that generating correct code and selecting safe software versions are not necessarily the same problem.

A 2026 study titled Correct Code, Vulnerable Dependencies evaluated 10 LLMs across 1,000 programming tasks. The research focused on Python rather than Node.js, so its percentages should not be interpreted as measurements of the npm ecosystem. But the underlying finding is important.

When models explicitly selected library versions, 36.7% to 55.7% of evaluated tasks included at least one dependency version associated with a known CVE. More strikingly, in 72.27% to 91.37% of those cases, the relevant CVE had already been publicly disclosed before the model's stated knowledge cutoff. The researchers concluded that version selection itself represents a distinct risk surface in AI-assisted development.

Read: Correct Code, Vulnerable Dependencies

Another 2026 study, When LLMs Lag Behind, examined what happens when software APIs evolve after patterns have already been learned by a model. Researchers found that stale internal knowledge can continue influencing generated code even when newer documentation is supplied as context. Structured documentation and reasoning techniques improved results, but did not completely eliminate the problem.

Read: When LLMs Lag Behind

The implication is not that AI coding assistants are inherently unsafe.

It is that software changes continuously, while learned patterns can persist.

A recommendation that was reasonable two years ago can become a poor production default today.

Node.js gives us a particularly clear example.

As of September 2026, Node.js 24 is Active LTS, Node.js 22 is Maintenance LTS, and Node.js 26 is Current. Node.js 20 reached End-of-Life on April 30, 2026.

That lifecycle distinction has real security consequences.

Security Does Not Stop When the Application Ships

Rafael Gonzaga, Principal Open Source Engineer at NodeSource and a Node.js TSC member involved in Node.js security, addressed this directly in his 2026 talk The State of Node.js Security.

One of the central themes of the talk is that application security extends beyond the JavaScript developers write themselves.

Node.js includes native dependencies such as OpenSSL, nghttp2, llhttp, V8, and others. When vulnerabilities are disclosed in those components, the Node.js Security Team evaluates whether the APIs used by Node.js make the runtime itself affected. Depending on that assessment, fixes may ship through security releases or regular releases.

Watch Rafael Gonzaga: The State of Node.js Security

This is an important distinction.

Your application's business logic may not change for six months.

The security environment around it can.

New vulnerabilities are discovered.

Bundled dependencies change.

Attack techniques evolve.

Security boundaries are tested in ways developers did not anticipate when the application was created.

That is precisely why supported runtime versions continue receiving fixes.

In June 2026 alone, Node.js issued security updates across the supported 22.x, 24.x, and 26.x release lines. The release included fixes affecting WebCrypto, HTTP/2, the Permission Model, HTTP agents, and several bundled dependencies including OpenSSL, nghttp2, llhttp, and Undici. Rafael Gonzaga and Matteo Collina were among the contributors credited with fixes in that release.

A month later, another security release addressed multiple issues, including two High-severity HTTP/2 vulnerabilities, Permission Model bypasses, HTTPS behavior, DNS handling, zlib, SQLite, and HTTP request processing. Rafael and Matteo again appear among the contributors responsible for fixes.

None of those fixes could have been encoded into an application before the vulnerabilities were discovered.

That is the point.

Keeping the runtime supported is part of application security, even when the application code itself has not changed.

EOL Changes the Security Equation

When a Node.js release reaches End-of-Life, the project stops maintaining it.

That includes security patches.

The Node.js EOL documentation explains that if a vulnerability disclosed in a newer release also affects an unsupported version, the project will not publish a new upstream release for that EOL line. It also warns about ecosystem drift, tooling compatibility, and compliance concerns that accumulate as an application stays on an unsupported runtime.

Node.js security announcements make this even more explicit.

The June and July 2026 security releases both warn that End-of-Life versions should be considered affected when security releases occur and direct users to stay on versions covered by the current release schedule.

This creates a simple but important difference:

A vulnerability may be discovered tomorrow.
A supported Node.js line can receive a fix.
An End-of-Life line will not receive that fix from the Node.js project.

That is why selecting a runtime version is not merely a compatibility choice.

It is a future security decision.

And increasingly, AI may participate in making that decision.

AI Is Already Influencing More Than Code

Rafael highlighted another scenario in The State of Node.js Security that feels increasingly familiar.

A developer has a problem.

They ask an LLM for help.

The model suggests installing a package.

The package solves the immediate problem.

But what else does that package do?

Rafael uses this scenario while discussing the Node.js Permission Model: a package could have been compromised or behave maliciously behind the scenes, reading sensitive files or communicating externally. The Permission Model can restrict what an application is allowed to access, acting as a defensive boundary if something unexpected happens.

His larger point is important: developers remain responsible for evaluating what they install and execute.

Node.js' own security policy makes the trust boundary explicit. Malicious third-party modules are not considered vulnerabilities in Node.js itself because Node.js treats executed code as trusted.

Application developers therefore need their own protections against supply-chain risks and untrusted packages.

The Node.js Security Best Practices documentation similarly calls out third-party libraries, malicious packages, typosquatting, and related application-level threats that teams should account for.

So when AI recommends a dependency, the recommendation should not become automatic trust.

The same principle applies to runtime versions.

AI can help make the decision.

It should not be the source of truth for whether that decision is still secure.

AI Is Changing Vulnerability Discovery Too

There is another side to this story.

AI is not only generating software decisions.

It is increasingly being used to look for security problems.

During the 2026 Node.js Collaborator Summit, Rafael discussed a large influx of AI-generated vulnerability reports reaching the Node.js security process. The Node.js event summary describes high volumes of noisy, duplicated, or poorly reproduced submissions that placed significant pressure on maintainers responsible for determining which reports represented genuine security issues.

OpenJS Foundation later quantified the shift.

According to its Q2 2026 security update, the Node.js security team had received 352 HackerOne reports over the preceding two years. In February 2026, report volume increased 4.6x following the emergence of AI agent-assisted scanning tools, and March alone produced 65 reports.

That does not mean AI-generated reports are inherently invalid.

AI-assisted security research may surface real bugs.

The challenge is verification.

A generated report still needs to demonstrate reproducible impact, respect the Node.js threat model, and be evaluated by people who understand where Node.js' security responsibility begins and ends.

Rafael makes that distinction repeatedly in The State of Node.js Security: not every crash, malicious package, prototype modification, or application-level issue qualifies as a vulnerability in Node.js core. The project's threat model exists specifically to define those boundaries.

This creates an interesting parallel.

AI can generate a security report that looks convincing but requires expert verification.

AI can also generate a technical recommendation that looks reasonable but requires current ecosystem context.

In both cases:

Plausibility is not the same as correctness.

The Developer Machine Is Part of the Attack Surface

Another observation from Rafael's talk is particularly relevant to AI-assisted workflows.

While reviewing HackerOne reports, the Node.js Security Team found that many security issues did not primarily threaten production servers.

They threatened developers.

Installing packages, executing unfamiliar code, running installation scripts, testing generated commands, and granting development tools access to local environments can expose credentials, company information, source code, or other sensitive data. Rafael specifically calls attention to malicious packages and post-install behavior as risks developers need to consider.

Watch Rafael's earlier talk: 5 Ways You Could Have Hacked Node.js

That matters even more as coding agents become capable of executing commands rather than simply suggesting them.

The transition from:

“Here is some code you could run.”

to:

“I ran this package installation for you.”

changes the security boundary.

AI-assisted development therefore needs the same engineering discipline we expect from any other automation system: least privilege, controlled environments, trusted sources, version verification, and human review for consequential changes.

Check the Runtime Instead of Assuming

One practical step is remarkably simple.

Check the version of Node.js you are actually running against known security data.

Rafael recommends is-my-node-vulnerable, a Node.js tool designed specifically for this purpose.

Run:

npx is-my-node-vulnerable

The tool compares the current process.version against the Node.js Security Database and reports known vulnerabilities that affect the installed runtime. End-of-Life versions are treated as unsafe because new Node.js security releases are no longer tracked and backported for those release lines. The project also recommends integrating the check into CI so a vulnerable runtime can prevent a deployment rather than being discovered after it reaches production.

Explore is-my-node-vulnerable

This is the kind of grounding AI-assisted development needs.

Do not rely on whether a runtime version sounds current.

Do not rely on whether a Dockerfile builds successfully.

Do not rely on whether the tests pass.

Check against authoritative, current security information.

AI Should Accelerate Engineering — Not Replace the Source of Truth

There is an important distinction between using AI to help make a decision and using AI as the authority behind that decision.

A coding assistant can help create a Dockerfile.

The Node.js release schedule should determine whether the runtime inside it is supported.

An AI agent can suggest a dependency.

Current vulnerability and package information should determine whether that version is appropriate.

An AI security tool can identify suspicious behavior.

The Node.js threat model, reproduction steps, maintainers, and security process determine whether that behavior constitutes a Node.js vulnerability.

This does not diminish the value of AI.

It makes AI more useful.

The most reliable AI-assisted development workflows will increasingly combine model reasoning with current, authoritative evidence.

That is particularly important in an ecosystem that moves as quickly as Node.js.

Your Runtime Is a Living Dependency

We often think of Node.js as the platform underneath our dependencies.

Operationally, however, the runtime behaves much like one of the most important dependencies in the entire application.

It has versions.

It has a support lifecycle.

It contains dependencies of its own.

It receives security fixes.

Eventually, it reaches End-of-Life.

And every application built on top of it inherits those realities.

So when AI helps create the next Node.js application, the question should not only be:

Did it generate code that works?

We should also ask:

What technical assumptions did it make for us?

Because correct code can still run on the wrong baseline.

And the security of that baseline will continue changing long after the code has shipped.

Running an Unsupported Node.js Version?

Knowing that a runtime needs to be upgraded is often easier than completing the upgrade.

Legacy dependencies, native addons, deprecated APIs, testing requirements, and production constraints can turn a version change into a significant engineering project.

That is why NodeSource participates in the Node.js LTS Upgrade & Modernization Program with the OpenJS Foundation.

The program helps organizations identify upgrade blockers, understand migration risk, and build a practical path from unsupported Node.js versions to supported releases. NodeSource's Upgrade Discovery tooling can inspect dependencies, native addons, and Node.js API usage to help turn an uncertain migration into a measurable engineering project.

If your application is still running Node.js 20, Node.js 18, or another End-of-Life release, start by understanding what is actually preventing the upgrade.

Explore the Node.js Upgrade Program

The NodeSource Blog