PHP2Shell, Node.js, and LiteLLM: What Businesses Need to Know Now

October 2026 has given software development and IT teams plenty to deal with.

On October 21, PHP released patches for two critical remote code execution vulnerabilities. Node.js published a security release addressing 10 vulnerabilities, four classified as high severity. And LiteLLM, a tool used to connect applications with large language models, disclosed that attackers had compromised its software release process.

Three different technologies, with very different problems, all demanding attention at roughly the same time.

For a business running several custom applications, integrations, and cloud services, that's a difficult position to be in. You need to figure out which announcements affect your environment, how serious the exposure is, and what can be fixed without disrupting the systems people depend on.

I've been following these disclosures closely, and one thing I keep coming back to is how much of our software we rely on without necessarily thinking about it.

We build applications on top of frameworks, libraries, and components developed by other people. That's how modern software development works, and for good reason. But it also means a vulnerability in something relatively obscure can suddenly become a problem for thousands of applications.

And knowing that a vulnerability exists is only the beginning. You still need to find out whether you're affected and what to do about it.

What Happened with PHP2Shell, Node.js, and LiteLLM?

Although the incidents made headlines within days of each other, they weren't all the same kind of security issue.

PHP2Shell: Critical Vulnerabilities with Confirmed Exploitation

On October 21, PHP disclosed two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell.

Both could potentially allow an unauthenticated attacker to execute code remotely on affected systems. The specific conditions for exploitation depend on how PHP is configured and used.

PHP has been around for decades, and an enormous amount of the web still depends on it. That includes older applications that may not receive much attention as long as they're working.

On October 26, the Cybersecurity and Infrastructure Security Agency (CISA) added both vulnerabilities to its Known Exploited Vulnerabilities Catalog.

That listing matters because it indicates that exploitation has been observed, not merely that researchers have demonstrated a possible attack.

CISA gave federal civilian executive branch agencies until October 29 to respond. The required response includes forensic triage, which I'll come back to because it's an important distinction.

For the affected PHP versions, technical details, and patching guidance, we've already covered those in our PHP2Shell vulnerability advisory.

Node.js: Ten Vulnerabilities, Including One That Reaches Well Beyond Node.js

The October 21 Node.js security release addressed 10 vulnerabilities, including four classified as high severity.

The issues involved different areas of Node.js, including DNS resolution, TLS certificate validation, and the handling of compressed data.

One that particularly caught my attention was CVE-2026-111497, a vulnerability involving the Brotli decoder.

Brotli is a compression technology developed by Google. It makes data smaller, it's fast, and it's widely used. There are good reasons so many projects have adopted it.

The problem is that a flaw in the decoder could allow specially crafted compressed data to corrupt memory, potentially resulting in an application crash, memory disclosure, or remote code execution.

And this wasn't strictly a Node.js problem.

The vulnerable decoder is used in other software ecosystems, including Python packages and components used by .NET applications. Different projects may track related issues under different advisory or CVE identifiers, which can make the overall picture confusing.

The Broccoli2Shell technical resource does a good job documenting the underlying vulnerability, affected products, and available fixes.

For a closer look at the Node.js release, read our Node.js security update analysis.

This is where looking at only a CVE headline can get you into trouble. A team might see a Node.js advisory, determine that one application doesn't use Node.js, and move on. But if another application uses the same vulnerable underlying library through a different framework or package, there may still be exposure.

LiteLLM: When the Update Itself Is the Problem

LiteLLM was different.

On October 21, attackers compromised the project's release pipeline and published malicious version 1.107.0 packages to PyPI, along with compromised container images.

The malicious software was designed to steal credentials and load additional code.

According to LiteLLM's investigation, the attack involved credentials that had previously been exposed but not revoked. The attacker used that access to compromise additional credentials and manipulate the project's release workflow.

The resulting malicious packages were distributed through official channels.

That creates a particularly difficult situation for development teams. Updating dependencies is normally part of how we keep applications secure. In this case, installing the affected release introduced the threat.

The compromised artifacts were removed, but organizations that installed or ran them during the affected period need to investigate possible credential exposure and follow LiteLLM's recovery instructions.

These incidents illustrate different weaknesses in software security. One involves the runtime, another a shared dependency, and another the process used to distribute software.

But for the people responsible for maintaining applications, all three lead to the same immediate question: Are we affected?

What Should Businesses Do Right Now?

If your business uses PHP, Node.js, or LiteLLM, I'd start by finding out exactly where those technologies are running.

Don't assume an application is unaffected simply because it's operating normally. A vulnerable component can sit quietly in a production environment until someone finds a way to exploit it.

1. Identify Affected Systems and Versions

Have your development or IT team check the runtimes, packages, libraries, and container images used by your applications.

For these particular incidents:

• PHP: Review the affected versions and patched releases for CVE-2026-109618 and CVE-2026-109619. Pay attention to older applications and servers that may be running PHP without an obvious owner. Our PHP2Shell advisory includes a practical checklist.

• Node.js: Review the complete October 21 release, not just CVE-2026-111497. The patched release lines are 22.x, 24.x, and 26.x. Teams should also look for affected Brotli implementations elsewhere in their software.

• LiteLLM: Check whether version 1.107.0 or any of the affected container images were installed or run during the compromise window. LiteLLM published the specific affected artifacts and recovery guidance.

If you can't easily tell which applications use a particular component, that's useful information in itself. It means your software inventory probably needs work.

2. Prioritize Systems That Are Exposed or Business-Critical

An internet-facing application that handles sensitive information deserves particular attention, especially when the vulnerability is known to be actively exploited.

But external accessibility isn't the only factor. Internal systems with broad permissions, access to critical databases, or connections to other infrastructure can also represent significant risk.

Assess whether the vulnerable functionality is actually reachable, what access an attacker could gain, and how a compromise would affect the business.

3. Apply the Appropriate Fixes and Verify Deployment

Follow the official guidance for each affected product.

Depending on the issue, that might mean installing a patched runtime, updating a library, rebuilding a container image, or redeploying the application.

Make sure the fixed version is actually running in production.

For example, installing an updated Brotli library doesn't necessarily fix an application that's still running an older copy in memory. A container may need to be rebuilt and deployed again.

If a system can't be patched immediately, review the vendor's recommended mitigations. In some situations, restricting access or temporarily taking the affected service offline may be necessary.

4. Check Whether a Compromise Already Occurred

This step deserves attention, particularly for PHP2Shell and LiteLLM.

Before restarting or rebuilding potentially compromised systems, coordinate with your security team on preserving logs and other evidence. Investigate suspicious activity and determine whether additional remediation is needed.

For LiteLLM, anyone who ran affected artifacts should follow the project's incident guidance, including the relevant credential rotation and environment recovery steps.

5. Confirm Who Is Responsible for Finishing the Job

Someone needs to own each affected application, verify that remediation was completed, and document anything that remains unresolved.

If a fix requires downtime, application changes, or additional investigation, make sure those decisions aren't left sitting between the development team, infrastructure team, and an outside provider.

Once the immediate exposure is handled, the next question is why identifying and updating those systems was easy or difficult. That's worth addressing before another vulnerability is announced.

The Problem with Dependencies You Didn't Know You Had

One of the more frustrating aspects of modern vulnerability management is that an application can depend on a vulnerable component without anyone on the team having deliberately chosen to use it.

Let's say your application uses a framework. That framework depends on several libraries. Those libraries depend on other libraries.

Eventually you have an entire graph of software components, many of which were installed automatically.

We call these transitive dependencies.

Most of the time, this arrangement is perfectly sensible. It's much faster to use well-established software than to build and maintain every component yourself. You also benefit from the work and experience of the people maintaining those projects.

But somebody still needs to understand what's included in the application.

With Broccoli2Shell, for example, the problem wasn't necessarily in code your developers had written. It could be in a compression decoder included several layers down.

Is It Realistic to Know Every Dependency?

Historically, not really. Keeping a complete inventory of every library, framework, runtime component, and related dependency could be extremely difficult.

That situation has improved.

In the .NET ecosystem, where we do a lot of work at Emergent, development tools can enumerate direct and transitive package dependencies.

Containerization can also help because it makes the components of a deployment environment more explicit, although you still need to account for software and services outside the container.

Another increasingly useful concept is the Software Bill of Materials (SBOM).

CISA has published guidance on SBOMs and their role in software supply chain visibility.

None of these approaches makes dependency management effortless. Inventories become outdated, not every component is captured automatically, and knowing a vulnerable library exists doesn't always tell you whether the vulnerable functionality can be exploited.

But they're a substantial improvement over discovering your dependencies one emergency at a time.

What About Applications Nobody Wants to Touch?

Older systems deserve special attention.

A business might have an application that's been running for 15 years. It works, people depend on it, and there hasn't been a compelling reason to replace it.

Then a serious vulnerability appears in the runtime or one of its dependencies.

Suddenly, updating the application isn't a routine maintenance task. The new runtime might not support parts of the original code. A library may have been abandoned years ago. Documentation might be missing.

This is one reason I think application maintenance decisions need to account for long-term security.

Sometimes the answer is a relatively small update. In other cases, modernizing an older application may be the more practical option.

The goal isn't to rebuild functioning software unnecessarily. It's to avoid reaching a point where a necessary security fix becomes a major development project.

Why Installing a Patch Isn't Always Enough

There's a distinction between closing a security vulnerability and determining whether someone has already exploited it.

The recent CISA action involving PHP2Shell is a good example.

On October 26, CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities Catalog. Federal civilian executive branch agencies were given three calendar days, until October 29, to respond.

That response includes forensic triage.

In other words, affected agencies aren't simply being told to install the patch. They also need to investigate whether vulnerable systems may already have been compromised.

That matters because applying a patch doesn't reverse everything an attacker might have done while a system was vulnerable.

What Can Happen When an Attacker Exploits Remote Code Execution?

Remote code execution is particularly serious because successful exploitation can allow an attacker to run code of their choosing within the privileges of the affected process.

Imagine a relatively ordinary business application connected to a database containing customer records.

If an attacker successfully exploits a remote code execution vulnerability, and the compromised application has sufficient database access, they may be able to write code that copies those records and sends them elsewhere.

They could also try to install malicious software, modify application behavior, or establish a way to regain access later.

That's why I take these vulnerabilities so seriously.

The exact impact depends on the application, its permissions, and the security controls around it. A vulnerable process doesn't automatically give someone unrestricted access to an entire network.

But when exploitation is possible, the consequences can go well beyond an application crash or a temporary outage.

Think About What Happens Before the Patch

When a system may have been compromised, investigators need to consider what evidence should be preserved.

That could include application and system logs, network activity, suspicious processes, unexpected file changes, or other indications of unauthorized access.

Restarting or rebuilding the system without considering that evidence can make it harder to understand what happened.

Of course, that doesn't mean leaving a known vulnerability exposed indefinitely while investigating. Containment, evidence preservation, and remediation need to be coordinated based on the circumstances.

The LiteLLM incident raises a similar concern.

If malicious software has already collected credentials, removing the package doesn't invalidate those credentials. Organizations may also need to rotate secrets, investigate their use, and review whether the attacker accessed other systems.

A vulnerability can be patched while the effects of an earlier compromise remain.

How Do You Prioritize Vulnerabilities When Everything Seems Urgent?

With several serious vulnerabilities arriving close together, it can be difficult for IT teams to decide where to start.

Security advisories include severity ratings and CVSS scores, but those numbers don't tell you everything you need to know about your own environment.

For example, a vulnerability affecting a public-facing application that processes customer information is a different situation from one affecting an isolated development environment.

A vulnerability that's being actively exploited also deserves different consideration from one without evidence of exploitation.

Here's how I'd approach prioritization.

I also wouldn't rely exclusively on CVE notifications.

One of the complications with the recent disclosures is that several related issues appeared under different identifiers, while one underlying vulnerability affected multiple products.

If you're only watching for one specific CVE, you can miss important information about the wider problem.

It's worth following the organizations and maintainers responsible for the software you use, along with resources such as the CISA Known Exploited Vulnerabilities Catalog.

And it's worth revisiting your assessment as new information becomes available. The picture can change considerably in the first few days after a major disclosure.

Preparing for the Next Major Security Vulnerability

There are some things I would encourage development and IT teams to work on once the immediate issues are resolved.

Most of them aren't especially complicated ideas. The challenge is making them part of normal operations, instead of trying to establish a new process in the middle of an emergency.

Have a Dependable Way to Inventory Software

Your team should be able to identify the runtimes, major libraries, and supporting infrastructure used by critical applications.

That doesn't mean someone needs to maintain an enormous spreadsheet by hand. Development tools, dependency analysis, container inventories, and SBOMs can help.

What matters is being able to answer a straightforward question when a new vulnerability is announced: Where are we using this?

Make Room for Emergency Dependency Updates

There's an interesting tradeoff in dependency management right now.

Because of attacks involving malicious packages, some teams have adopted what's called a dependency cooldown. Rather than installing every new package release immediately, they wait for a period of time.

That's a reasonable approach to reducing certain supply chain risks.

But what if the new release contains a fix for a critical vulnerability that's already being exploited?

Obviously, you may need to install that update immediately.

So now you need two processes: one that deliberately delays routine updates and another that allows your team to override the delay when circumstances justify it.

Both need to be understood and tested.

The goal isn't to create more bureaucracy. It's to avoid having your security policy prevent you from responding to a security emergency.

Slow Is Smooth, Smooth Is Fast

This is something I try to keep in mind when responding to urgent problems in production.

When a serious vulnerability is disclosed, there's pressure to do something immediately. That's understandable, particularly when the affected application is important to the business.

But rushing through a fix can create problems of its own.

You might update the wrong component, overlook another affected instance, or assume a vulnerability is fixed when the original code is still running somewhere.

You might also break something that the application depends on.

That includes understanding the affected systems, evaluating potential compromise, applying the appropriate fix, testing the result, and verifying what's actually running in production.

It's much easier to do those things quickly when the team has practiced them beforehand.

Decide Who Makes the Difficult Calls

Someone needs to be responsible for approving emergency changes, deciding when an application should be taken offline, and coordinating communication with the rest of the business.

Those decisions can become complicated when an application supports critical operations.

There may also be situations where the development team can apply the patch but doesn't have the expertise to investigate a possible compromise.

Knowing when to involve security specialists or an outside partner should be part of the plan.

Revisit the Build-Versus-Buy Decision

This is one of the longer-term questions I've been thinking about after the recent incidents.

We routinely choose to use external dependencies because someone else has already solved a problem. That's generally a good engineering decision.

But what happens when an important dependency becomes difficult to maintain?

Maybe the original project is no longer supported. Maybe the update schedule doesn't work for your business. Maybe the component has accumulated technical debt or presents ongoing security concerns.

At that point, it's worth reconsidering whether to continue using it, replace it, or take greater responsibility for maintaining it internally.

There are real costs involved in each option.

If you bring a dependency under your own control, you also take on the work of maintaining, testing, and securing it. That's not necessarily less expensive or less risky.

But the decision deserves to be made deliberately.

At Emergent, this is the kind of question we work through when helping clients evaluate custom software development and modernization options. Sometimes a small change is enough. Sometimes replacing an old component is worth the investment.

How Emergent Software Helps Businesses Respond

Part of what makes these security incidents difficult is the variety of technologies involved.

An organization might have people who are very comfortable maintaining its core applications but less familiar with a particular dependency, runtime, or deployment environment.

At Emergent Software, we're working across different technology stacks and application environments for a wide range of clients. That means we're continually encountering software components and security considerations that may not be front and center for any one client's internal team.

We also have an ongoing responsibility to the systems we've helped build and maintain.

The recent PHP2Shell situation is a good example.

Before the vulnerabilities were publicly disclosed, we reached out to some of our existing clients, as well as a few prospective clients, because we knew they had systems that relied on PHP.

We wanted to make them aware of the potential exposure and give them the opportunity to address it before the situation became more urgent.

That's how I think a technology partner should operate.

We're often the people someone calls when an application has a problem. But if we know enough about that application to recognize a potential problem ahead of time, we should be having that conversation too.

Depending on the client's situation, our team can help with:

Sometimes that means helping a client work through an urgent update. Other times, it's reviewing the longer-term costs of continuing to rely on a particular component.

There's rarely one answer that makes sense for every application.

What Happens When the Next Vulnerability Is Announced?

I don't think the answer to incidents like these is to stop using open-source libraries or try to build every component yourself.

That would create an entirely different set of problems.

The better approach is to understand the dependencies you've accepted and make sure you have the people and processes in place to maintain them.

For businesses currently dealing with the October vulnerabilities, that means identifying affected systems, applying the appropriate fixes, and investigating possible compromise where warranted.

Afterward, I'd spend some time looking at what made the response difficult.

Did you know which applications were affected? Were the right people available to make decisions? Could you deploy a fix without creating new problems? Did you have the information needed to investigate suspicious activity?

Those answers will tell you a lot about how prepared you'll be for the next disclosure.

And given the number of vulnerabilities we're seeing across the software industry, I wouldn't assume it'll be a long time before another one deserves your attention.

Frequently Asked Questions

What Is Vulnerability Management?

Vulnerability management is the ongoing process of finding, evaluating, prioritizing, and addressing security weaknesses in software and IT systems. It includes tracking affected components, reviewing security advisories, applying updates, and confirming that identified risks have been addressed.

How Can Businesses Tell Whether They're Affected by a New Vulnerability?

Start by checking which applications, runtimes, libraries, and supporting services are running in your environment. Compare that inventory against the affected products and versions listed in official security advisories. For complex applications, it may also be necessary to check indirect dependencies and determine whether vulnerable functionality is actually exposed.

What Is the Difference Between Vulnerability Management and Patch Management?

Patch management involves installing software updates. Vulnerability management includes that work but also covers discovering weaknesses, assessing their relevance to your environment, prioritizing fixes, and investigating possible compromise when necessary.

What Is a Software Bill of Materials (SBOM)?

An SBOM is a structured inventory of the software components included in an application or product, including dependencies. It helps teams identify where vulnerable libraries may be used, although it still needs to be maintained and interpreted as part of a broader security process.

Can an Application Still Be Compromised After a Security Patch?

Yes. A patch may prevent new exploitation of a vulnerability, but it doesn't necessarily remove malicious software, restore stolen credentials, or undo changes an attacker made before the patch was installed. Additional investigation or remediation may be necessary.

How Should Businesses Prioritize Critical Security Vulnerabilities?

Consider whether the vulnerability is being actively exploited, whether affected systems are accessible to attackers, what those systems can access, and the potential business consequences. Severity scores are useful, but they don't replace an assessment of your own environment.

How Can Emergent Software Help with Vulnerability Management?

Emergent Software provides security assessments, custom software development, application modernization, and managed services. Depending on the situation, our team can help identify affected applications, evaluate remediation options, support updates, and address longer-term maintenance concerns.