Vaadin and the October 2026 Node.js security releases

Description

On 21 October 2026 the Node.js project released fixes for ten vulnerabilities, in versions 22.23.4, 24.22.1 and 26.12.1. The ones that drew attention:

Six further issues are rated Medium or Low, among them a non canonical IPv4 hostname matching a DNS SAN, repeated values from crypto.randomUUID() in startup snapshots, and two Permission Model bypasses. The same releases update the bundled root certificates for the eMudhra intermediate certificate compromise disclosed on 19 October 2026.

Where Vaadin uses Node.js

Vaadin uses Node.js in two places, both of them on a developer machine or a build server:

• At build time, to compile the frontend bundle. The Maven goals that do this bind to the process-resources and prepare-package phases, so this happens while the application is packaged, not while it runs.
• In development mode, to run the development server.

Vaadin does not require Node.js to be installed. When it is not, or when the installed version is outside the range Vaadin supports, Vaadin downloads a known version into ~/.vaadin and uses that. When a suitable Node.js is already on the PATH, Vaadin uses it and downloads nothing.

Why a deployed Vaadin application is not affected

The code that locates, downloads and runs Node.js lives in a separate build time module. The Vaadin runtime artifact does not depend on it, so an application in production contains nothing that can start a Node.js process. Development mode startup exits early when production mode is configured, before any Node.js setting is read. A production Vaadin application serves a frontend bundle that was built in advance and is read from the classpath.

There is no Node.js process in a production deployment, so none of the issues above applies to it.

Exposure in build and development environments

The remaining question is what these vulnerabilities mean for the machine that builds the application.

The Brotli issue, CVE-2026-111497, requires the vulnerable Node.js process to decompress attacker controlled Brotli data. A Vaadin frontend build compresses the application's own assets and does not decompress untrusted input. Vaadin does not even install Node.js for compression: it uses one only if it is already there.

The TLS hostname issues matter to anything that makes HTTPS requests, which during a build means the package manager fetching frontend dependencies. Exploiting them requires an attacker already positioned to intercept that traffic and holding a certificate for a name that the flawed check accepts.

So the realistic exposure is the general one that applies to any Node.js installation on a build machine, not something specific to Vaadin. It is still worth fixing, which is what the guidance below is for.

Affected products

Which Vaadin versions download a patched Node.js

Free maintenance has ended for Vaadin 24, 23 and 14, so on those lines the release carrying the updated default is only available to extended-support customers.

Lines that no longer receive releases, among them Vaadin 25.1, 25.0, 24.8, 24.6 and 24.5, keep the Node.js version their last release pinned and will not get an updated default. Vaadin Framework, the 8 and 7 lines, does not use Node.js at all.

Customer guidance

Install a patched Node.js on your build and development machines. This is the action that helps immediately and it does not depend on a Vaadin release, because Vaadin prefers a suitable Node.js that is already installed over the one it downloads. The version to install depends on the Vaadin line:

Development prereleases of the next line use Node.js 26, where the patched version is 26.12.1.

Two settings are worth knowing. vaadin.nodeFolder points Vaadin at a specific Node.js installation and takes precedence over everything else, so Vaadin never downloads when it is set. require.home.node does the opposite: it forces Vaadin to use the copy in ~/.vaadin and ignore the one on the PATH. If you have set it, the Node.js on your PATH is not the one being used.

Then upgrade to a Vaadin release that carries the updated default. Every supported line now has one, listed in the table above. Vaadin 25.2.12 was the first, on 21 October 2026, and the remaining seven lines released on 26 October 2026.

Older versions

Two different things get called old here, and the answer differs.

A maintained line on an old patch version, for example Vaadin 14.5.1 when the 14 line is at 14.14.x, is not stuck. The line is still receiving releases, and the updated Node.js default arrives on it like any other change. What is needed is to move to the current patch version of that line, which on Vaadin 24, 23 and 14 is available to extended-support customers.

A line that no longer receives releases at all will never get an updated default, because the Node.js version a release downloads is fixed in that release and is never changed retroactively. Vaadin 23.1 pins Node.js 16.16.0, Vaadin 14.5 pins 14.15.4, and Vaadin 13 predates this mechanism entirely and used Node.js 8.11.1 through a third party Maven plugin. All three of those Node.js versions reached end of life years ago.

On both, installing a supported, patched Node.js on the build machine works, and so does pointing Vaadin at one with vaadin.nodeFolder. Neither requires a Vaadin upgrade.

Integrity of the Node.js download and the eMudhra certificate compromise

Because Vaadin can download Node.js over HTTPS, the eMudhra intermediate certificate compromise is worth addressing directly.

Vaadin 24.7 and newer verify the downloaded archive against the SHASUMS256.txt published alongside it. A further layer ships the expected checksums inside the Vaadin artifact itself and trusts them over anything served by the download location, so that a mirror cannot substitute a different archive. It is available in Vaadin 25.3.4 and 24.10.13, and is not present on the other lines.

Vaadin versions older than 24.7 do not verify the downloaded archive at all and rely on HTTPS alone. On those versions, and in any environment where the certificate trust store has not been updated, installing Node.js yourself rather than letting Vaadin download it removes the concern entirely.

Vaadin ships no certificate authority store of its own. Build time HTTPS connections use the trust store of the JDK running the build, so updating the JDK is what updates the trusted certificates.

References

• Node.js: October 2026 security releases
• Vaadin docs: Node.js configuration
• Vaadin security advisories