All articles

NewsOctober 6, 20265 min read

Red Hat Lightwell: over 400 Java vulnerabilities fixed

IBM and Red Hat’s Lightwell project has found and fixed over 400 previously unknown flaws in Java libraries. Backports, SBOMs and what to do now.

A metal chain breaking apart, with fragments of the links scattered on a white background

Lightwell, the open source security initiative run by IBM and Red Hat, has identified and fixed more than 400 previously unknown vulnerabilities in widely used Java libraries. Infosecurity Magazine (6 October 2026) and CSO Online (9 October 2026) report it alongside the general availability of Lightwell Clearinghouse, the service to which customers can submit their own open source dependencies.

There are two sources, and neither publishes the list of vulnerabilities or the CVEs assigned, so this news does not translate into specific updates to install. It does, however, concern anyone running Java applications in production with library versions that have not moved in years.

What happened

According to Infosecurity Magazine, the 400-plus vulnerabilities have been fixed since the project launched in June, in “foundational” Java libraries; CSO Online describes them as previously undiscovered vulnerabilities in widely used Java libraries. Both outlets report the commitment made by IBM and Red Hat: $5 billion and 20,000 engineers dedicated to the project. According to CSO Online, the announcement dates back to May.

Infosecurity Magazine writes that the Clearinghouse reaches general availability after a pilot phase, and names several large US and Canadian financial companies among the early adopters, including Bank of America, Citi, Goldman Sachs, JPMorganChase, Mastercard, Visa and Wells Fargo. No European adopters appear in the sources.

Gunnar Hellekson, vice president at Red Hat and general manager of Lightwell, quoted by both outlets, says AI agents exploit old dependencies “at machine speed” and that finding bugs is only half the job: the rest is bringing fixes to the versions already in production. Infosecurity Magazine also links the initiative to the rise in AI-generated vulnerability reports, often noisy or inaccurate, which weigh on open source maintainers.

How Lightwell works

According to Infosecurity Magazine, IBM and Red Hat presented two offerings in July:

  • Lightwell Network: a continuous stream of digitally signed binaries, source code and compliance documentation, including complete SBOMs (software bills of materials);
  • Lightwell Clearinghouse Premier: for selected customers running pinned versions in production who need targeted fixes and backports.

The Premier workflow, as the outlet describes it:

  1. the customer reports a vulnerability tied to a specific package and version;
  2. Red Hat triages it and determines severity, applicability and remediation;
  3. it develops a patch or backport for that version;
  4. it coordinates with the upstream project so that the fix is technically acceptable;
  5. it builds the fixed package on its own infrastructure;
  6. the output is signed and attested, with verifiable provenance;
  7. the customer deploys the binary without having to repeat the fix and validation on their own.

According to Red Hat, the fixes are delivered from secured repositories that integrate with the scanners, repositories, CI/CD pipelines and validation processes already in use.

The technical picture: pinned dependencies

The sources describe no attacks and no indicators of compromise: the technical issue is dependency management. In Java applications a library often arrives as a transitive dependency through Maven or Gradle and ends up packaged inside a JAR or WAR: it does not show up among the operating system packages and slips past traditional inventories. When a fix is released only for a newer version, upgrading can mean API changes and retesting the application, which is why many companies stay on old versions. A backport brings just the fix to the version in use.

As an example of the kind of flaw the service will look for, CSO Online cites the sandbox bypass in the Thymeleaf template engine, rated critical (CVSS 9.1) and discovered in April; the outlet gives neither the CVE number nor the affected versions. When a vulnerable library is reachable from an internet-facing application, exploitation falls under MITRE ATT&CK technique T1190 (Exploit Public-Facing Application).

Finally, CSO Online notes that Lightwell is not the only initiative in this area: Azul offers a free vulnerability risk assessment for Java Virtual Machines.

Impact for European and Italian companies

For NIS2 entities, supply chain security and vulnerability handling in the development and maintenance of systems are measures required by the directive, and the open source libraries inside applications are part of them. Banks and other financial entities, like the early adopters named, must also manage ICT risk, including third-party risk, under the DORA regulation. Anyone making software sold in the European Union must also comply with the Cyber Resilience Act, which requires documenting components and handling their vulnerabilities.

Lightwell is a commercial service for Red Hat customers: the sources do not say whether or when the fixes will be available to everyone in the releases published by the original projects.

What to do now

  1. Inventory the Java libraries in your applications, including transitive dependencies, by generating an SBOM at every build.
  2. Identify long-pinned versions and who owns them: these are the ones for which a fix may never come from the original project.
  3. Match the SBOM against known vulnerabilities continuously, not only at release time: new CVEs also emerge for versions that have stopped moving.
  4. Check whether you use Thymeleaf and look up in the project’s official advisories which versions fix the sandbox bypass.
  5. Prioritise internet-facing applications and libraries reachable from external input.
  6. Ask software vendors and development partners for SBOMs and fix timelines for the libraries they ship.

How ARXDOME helps

ARX Shield shows open vulnerabilities by machine and by package, with their age and those already exploited highlighted, and ARX Sentry keeps an inventory of the software installed on computers and servers. Libraries packaged inside applications, on the other hand, should be checked with the SBOM in the development pipeline. ARX Expose adds the outside view: known vulnerabilities on public services and the products recognised on the attack surface.

Last updated:

Any questions?

Let’s talk about your company’s needs, with no obligation.

Contact us

Related articles