PHP and Node.js Vulnerabilities 2026: Why We Publish SBOMs

PHP and Node.js both released security updates on October 21. TulipTech's write-up covers the vulnerabilities and the work of finding and updating affected installations. Reading through it, the question I keep coming back to is what the customer can actually check. You bought a product. Do you know what's inside it?

This is why we at Zenpo publish a software bill of materials, or SBOM, for each and every build of the Zenpo Intranet Suite. We want customers and their IT Security teams to know what goes into our software, and to be able to review that information at their convenience.

It keeps us honest too. We're making our dependencies visible. When a day like October 21 comes along, we have to look at what we're using and keep up with what needs to change.

What happened with PHP and Node.js

The PHP security advisory describes two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can allow an unauthenticated attacker to execute code. PHP released fixes in 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The project says all PHP installations serving web requests are at risk, with the highest risk in Apache's mod_php configuration.

The Node.js security release includes CVE-2026-111497, a flaw in the bundled Brotli decoder. If an application decompresses attacker-controlled Brotli data, the bug can corrupt memory and potentially lead to code execution. The release also addresses other issues, including DNS and TLS hostname verification problems.

These are problems in the underlying software your application depends on. Your own application code doesn't have to change for a new advisory to change your assessment of it.

And the information keeps moving. On October 23, PHP published a follow-up advisory about session upload progress, describing another possible code-execution path under an unusual combination of configuration and application behavior. If you're responsible for PHP systems, read that follow-up along with the October 21 guidance.

That's already another thing to review, two days after the initial releases.

What customers can review in our SBOMs

An SBOM is an inventory of software components and their versions. It gives a security reviewer a place to start when a component appears in an advisory. Without that information, the reviewer may have to ask the vendor whether the component is present before they can even begin assessing it.

Our public Intranet Suite documentation repository contains versioned release folders with SBOMs, release notes, build metadata, and checksums. The SBOM files use CycloneDX JSON, a format that tools can process. Customers can download the record for the release they're reviewing.

That last part matters. The package a customer installed three months ago may have different dependencies from the one we ship today. A list describing only the latest release doesn't answer their question. They need the record that goes with their version.

We want IT Security to be able to look at this when it fits their work. During an initial review, before approving an upgrade, or when an advisory lands. They shouldn't have to arrange a meeting with us to get the component list. If they have questions after reviewing it, then we can have a much more specific conversation.

This is also part of giving customers the information they need to operate what they own. The software arrives with dependencies. The customer should be able to see them.

The inventory still needs interpretation

There is a limit to what a component list tells you. Finding a name in an SBOM doesn't, by itself, establish that the deployed application is vulnerable. You still need to understand the version, how the component is used, and whether the conditions described in the advisory apply.

Take Node.js. Using Node to build a browser application is different from running a Node server that processes requests. A build dependency and a production runtime can both need attention, but they aren't interchangeable. You have to know which environment you're examining. The Node advisory itself describes an attack condition involving decompression of untrusted data; seeing the word "Node" somewhere in a project isn't the whole assessment.

A package inventory also has a scope. It may include development tooling, and it may not describe the runtime installed on a separate server or the contents of a hosting provider's environment. Those need their own records and checks.

So I wouldn't hand someone an SBOM and tell them that proves the product is secure. It gives them information they can use to ask better questions. We still have to answer those questions and do the maintenance.

Publishing an SBOM keeps us honest

Getting this into our release process took some work. Back in February, I wanted an SBOM generated with the Intranet Suite build, included in the test and production ZIPs, and kept with the other release artifacts. I knew security and compliance teams would ask for it.

I wrote about the six attempts it took to get that working. One pipeline task copied zero files and carried on. There were path problems between steps, a version-format issue with the generator, and cleanup that initially only ran when generation succeeded. Eventually, the pipeline generated the file in staging and copied it to the destinations with checksum checks.

I needed to know the SBOM actually made it into both ZIPs. I added checksum checks so I could verify each copy.

Publishing it creates an obligation on our side as well. The versions are there for customers to inspect. If a dependency needs updating, we have to assess the change, test it, and get it into the appropriate build. If there's a reason an update is complicated, we need to be able to explain that. Leaving an old dependency in place because nobody has asked about it yet is a poor way to maintain software.

That's what I mean by keeping us honest. We aim to be transparent about what we include, and that transparency pushes us to stay current. It doesn't make the maintenance automatic. It makes it harder to ignore.

The SBOM work started months before October 21. A day like that is a reminder of why we wanted it in the first place. When a customer asks what's in the package they're running, I want us to have a record they can inspect while we work through what the advisory means for them.