No version of Vaadin uses PHP

Description

On 21 October 2026 the PHP project released fixes for two critical vulnerabilities in the PHP engine, CVE-2026-109618 and CVE-2026-109619, both scored CVSS 9.2 and publicly known as PHP2Shell. Both are use after free issues: a fatal error during a request, typically an out of memory condition, interrupts native PHP code before it cleans up, and a later request on a reused worker treats the freed memory as live data. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Because the flaws are in the engine itself, any PHP application can be affected regardless of which framework it uses.

Vaadin is a Java framework. PHP plays no part in it, at any layer.

Affected products

The answer does not depend on the Vaadin version, so it covers versions that are no longer maintained just as it covers the current ones. There is nothing to upgrade to, because there is nothing to fix.

Why Vaadin is not affected

Vaadin applications run on the Java Virtual Machine. The server side is Java, the client side is JavaScript executed by the browser, and the build is Maven or Gradle. No PHP interpreter is involved in building, running or deploying a Vaadin application, and none is installed by Vaadin.

The source repositories that make up the product, vaadin/flow, vaadin/platform, vaadin/flow-components and vaadin/hilla, contain no PHP file, no composer.json or composer.lock, and no mention of PHP in any build file, dependency manifest or continuous integration workflow.

Does a Vaadin build fetch anything from a PHP based service?

The question is worth answering directly, because it is the one people actually ask. A Vaadin build downloads Node.js from nodejs.org, frontend packages through the npm registry, and Java artifacts from Maven repositories. We cannot know what server software any of those run, and neither can anyone else.

That does not change the answer, because the server's language is the wrong thing to rely on. A compromised host can serve a bad file whatever it is written in, and a host running a patched PHP is no safer than one running anything else. What protects a build is verifying what arrives rather than trusting where it came from: Vaadin 24.7 and newer check the downloaded Node.js archive against published checksums, npm and pnpm verify every package against the integrity hashes recorded in the lockfile, and Maven verifies artifact checksums. Committing a lockfile and pinning versions is what makes a build repeatable and auditable.

Scope of this statement

This page covers Vaadin products, the artifacts we publish, and the build chain those products use. Questions about Vaadin's own hosted services or about Vaadin's corporate IT are answered separately by the teams that run them, and are not in scope here.

Customer guidance

No action is required. A questionnaire asking whether PHP is used, directly or indirectly, in Vaadin products can be answered No, and the same answer applies to CVE-2026-109618 and CVE-2026-109619.

One detail is worth knowing in advance, because a file name search will find it. The npm package flatted, a development time dependency of the ESLint cache used while building Vaadin itself, ships a PHP port of its own library alongside its JavaScript, at node_modules/flatted/php/flatted.php. It is a development dependency of our build, it is not part of any published Vaadin artifact, it is never executed, and no PHP interpreter exists anywhere in the toolchain that could execute it. Finding that file in a development checkout does not mean PHP is used.

If your own application or infrastructure includes PHP for reasons unrelated to Vaadin, follow the PHP project's advisory and update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35.

References

• PHP 8 ChangeLog
• CVE-2026-109618
• CVE-2026-109619
• Vaadin security advisories