Vaadin Flow and the axios npm supply-chain compromise

Description

The attack used a compromised NPM maintainer account to publish tainted versions of axios. The payload was delivered through a post-install script in the injected plain-crypto-js dependency, which downloaded and executed a remote access trojan on the build machine. The infection vector required running npm install without the --ignore-scripts flag during the three-hour window when the malicious versions were available.

NPM removed the compromised versions and published a security advisory (GHSA-fw8c-xr5c-95f9).

Impact to Vaadin and why platform users are NOT vulnerable

Vaadin Flow does not include axios in its dependency tree, either directly or transitively. A standard Vaadin application has zero exposure to this incident.

An internal audit of all Vaadin CI/CD infrastructure active during the attack window confirmed that no build artifacts, published packages, or internal systems were compromised.

• Why we are NOT vulnerable

• 1. Vaadin does not use axios: The frontend dependencies shipped with Vaadin Flow and its component bundles do not include axios. Neither the development bundle (vaadin-dev-bundle) nor the production bundle (vaadin-prod-bundle) contain this library. This was verified by scanning all supported release series.
• 2. Flow always uses --ignore-scripts: Vaadin Flow executes npm install with the --ignore-scripts parameter in all modes: both the production build (build-frontend Maven goal) and the development mode server use the same parameter. Even if a malicious package were somehow present in the dependency tree, its post-install scripts (the infection vector for this attack) would never execute.
• 3. Pinned, reproducible bundles built by us: Production Vaadin applications use pre-built frontend bundles published to Maven Central with fixed, audited versions. These bundles are created in CI with pinned dependencies and do not pull from npm at runtime.
• 4. Compromised versions removed upstream: The malicious axios versions were removed from the npm registry within three hours and are no longer installable. Fresh installs will fetch clean versions.
  
  Bottom line: Vaadin users are NOT exposed to this attack. The only scenario where a Vaadin project could be affected is if the developer has explicitly added axios (or a third-party npm package that depends on it) to the project, and the user ran npm install manually outside of the Vaadin build during the three-hour attack window. This is a very unusual setup that does not apply to standard Vaadin development workflows.
•  

Affected Products

Customer Guidance

• For projects that include axios as a direct or transitive npm dependency and may have run npm install in a clean workspace on March 31, 2026 between 00:21 and 03:29 UTC:

• - Check if axios is in your dependencies: Run `npm ls axios` in your project's frontend directory. If axios does not appear, you are not affected.
  - Run `npm audit` to check your `package-lock.json` for known vulnerabilities.
  - Reset frontend dependencies: Run `mvn vaadin:clean-frontend` to remove `node_modules` and `package-lock.json`, then rebuild. Fresh installs will fetch clean versions.
  - Use `npm ci` instead of `npm install` in CI/CD pipelines for exact version pinning from the lockfile.
  - Enable Dependabot or Snyk for ongoing supply-chain monitoring of your npm and Maven dependencies.

References

• 
  - GHSA-fw8c-xr5c-95f9: axios compromised versions