VCF Helping You Respond to PHP2Shell

(Day 17 of 22 in our Cybersecurity Awareness Month series. Today: responding to a busy week of vulnerabilities)

For information on Broadcom products and the PHP2Shell vulnerabilities, see https://www.broadcom.com/php2shell.

We are deviating from our posted schedule a little bit to talk about the events of this week: a lot of vulnerability news at once, including two critical flaws in PHP, known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619), that let attackers run code on web servers without logging in; a certificate authority, eMudhra, whose intermediate keys turned out to be weak enough to forge certificates for any website; and a long list of critical bugs in remote access tools, firewalls, email gateways, and developer platforms, several of them already under attack.

A busy stretch like this is hard on everyone who runs infrastructure, and it’s a good opportunity to remind everyone that VMware Cloud Foundation (VCF) has a lot of things in it that can help with weeks like this one. Not to mention that we’ve been talking about some of these topics throughout our Cybersecurity Awareness Month series anyhow.

Check Whether VCF Is Affected, Then Find Affected Workloads

To check VCF, start with the VMware Security Advisories and the CVE disposition report on the VCF download portal, which our post on vulnerabilities walks through. We don’t usually publish statements about vulnerabilities that don’t affect a particular product, but PHP2Shell is severe enough that it is worth doing, and the answers are straightforward: VCF components don’t use PHP and aren’t affected (KB 459989). Broadcom’s PHP2Shell response page has the status for every Broadcom division, with links to each one’s advisories.

Next, find the workloads running PHP, starting with the ones that face the Internet. VCF gives you several ways to find them:

• Find the web servers with VCF Operations. VCF Operations service discovery uses VMware Tools to find the services running inside each of your VMs, like web servers and databases, along with the connections between them, so you can see which VMs run web servers and what depends on them. VMware Tools application discovery adds the applications running in each guest and their versions. One thing to consider is that you may have disabled this functionality by following the VCF Security Configuration Guide. Disabling things you are not using is a good idea, but these functions can be especially useful in times like these. Perhaps you might choose to re-enable them, and to do that just reverse what is in the Security Configuration Guide.
• Find the web servers with VMware vDefend. vDefend Security Intelligence maps the traffic flows to and between your workloads, so you can see which VMs serve web traffic and what talks to them, and its segmentation reports and policy recommendations help you build the rules for the next step. With the PHP2Shell IDS/IPS signatures turned on, vDefend’s events can also show which of your workloads are receiving exploit attempts.
• Find what’s exposed with VCF Operations for Networks. Flow data can show which of your VMs actually receive traffic from the Internet. A search along the lines of flows where Flow Type = ‘Source is Internet’ and Flow Type = ‘Destination is VM’ can list them, and application discovery groups VMs into applications by name, tag, and traffic pattern.
• Let Avi show you what’s behind it. For applications behind VMware Avi Load Balancer, the WAF reads the Server and X-Powered-By headers in live traffic, which can reveal the PHP versions your applications are running (VMware Security Blog).
• Turn the list into owners. vCenter tags and custom attributes that record owners and applications turn a list of VMs into a list of people to call, and the same tags can drive the vDefend security groups in the next step.
• Check appliances and templates. Virtual appliances you run from other vendors may include PHP, so check those vendors’ advisories. Check your templates and content libraries, too, so new VMs don’t start out vulnerable while you’re updating the existing ones.
• Patch any systems that are restored. Make sure that any restores you do from backups include a step to update them to the current software levels.

Buy Time and Limit Lateral Movement

As our post on vulnerabilities put it, isolation, hardening, and access control can buy you time while patching is underway, and VCF has good tools for that. Our post on the VMware Security Blog walks through using them against PHP2Shell (VMware Security Blog):

• Virtual patching with vDefend IDS/IPS. Our VMware Threat Analysis Unit released IDS/IPS signatures for both vulnerabilities, 1156209 and 1156210, so VMware vDefend can detect and block exploit attempts headed for vulnerable workloads (KB 460110). Turn on TLS inspection on the gateway firewall, too, so the signatures can see inside encrypted web traffic.
• Web application firewall rules with Avi. The VMware Avi Load Balancer WAF has rules aimed at remote command execution and PHP application attacks, plus virtual patch rules for these CVEs that you can run in enforcement mode (KB 460068).
• Segmentation with the vDefend Distributed Firewall. Tag the VMs you found running PHP, put them in a security group, and tighten what they can reach until they’re patched, so it’s much harder to use a compromised web server to attack its neighbors. Many security organizations like CERT-EU and CISA, and even the Prime Minister of Japan, have recommended isolating internet-facing applications that can’t be fixed right away, or temporarily taking them offline. With the distributed firewall, isolating them takes only a policy change.

These controls can give you time to apply the patch during a planned maintenance window. They also help the next time something like this happens, which is a good reason to have segmentation in place before you need it. Inside your guests, Symantec and Carbon Black endpoint protection can help, too, and the Symantec Threat Hunter team’s post covers their PHP2Shell protections (Symantec).

It’s also a good time to check the controls that limit lateral movement:

• Filter outbound traffic. Add egress rules, including DNS filtering and outbound inspection, so a compromised web server has a much harder time calling home.
• Let vDefend block automatically. Having vDefend block detected threats without waiting for someone to act on an alert may occasionally interrupt something by mistake, which is worth the trade-off, because that usually costs far less than a missed intrusion.
• Wall off the management plane. Keep strict controls between your management interfaces and the rest of your organization, use privileged access workstations, and drive access to ESX through vCenter and its permissions model.

Get a Trusted Fix Into Production Quickly

If you build applications with VMware Tanzu, patched components were available shortly after the PHP updates shipped. For PHP2Shell, our Tanzu team updated the PHP binaries and container images, built with Bitnami technology, in TrueSource Trusted Artifacts within an hour of disclosure (TrueSource team), and Tanzu Platform had updated PHP buildpacks with patched runtimes the same day, so developers could rebuild their applications on fixed components. The vDefend and Avi protections above can also help cover the time it takes to test and roll out those changes.

Use Snapshots to Take the Risk Out of Patching

Our post on vulnerabilities suggested treating updates like this as emergency changes, and snapshots make that an easy call. Our post on snapshots covers them in depth, but for vulnerability response:

• Snapshot first, and automate it. Take a snapshot of each VM before you patch it or change its configuration, so if the update breaks the application, reverting usually only takes a minute. Script it through the API so it happens every time, and schedule the cleanup, too, either from your scripts or as a recurring scheduled task in vCenter that deletes the snapshots for you.
• Test on a clone, then roll out in stages. Clone a production VM onto an isolated network and try the update there first, then patch a few canary systems before the rest, so problems show up early, on just a few systems. With VCF Networking (NSX), you can recreate an application’s networks as isolated virtual networks, even with the same IP addresses, and clone its VMs into them, so several of your teams can test in parallel without touching production.
• Keep the service up with Avi. With VMware Avi Load Balancer in front of a pool of web servers, you can patch them one at a time while traffic keeps flowing, so users shouldn’t notice. That helps take away the “too important to be down” reason for leaving a server unpatched.
• Add point-in-time recovery with vSAN Data Protection. Snapshots are short-lived, and vSAN Data Protection keeps scheduled point-in-time copies of workloads that you can go back to hours or days later. It doesn’t replace backups, but it can cover a lot of “the patch broke something we didn’t notice until Tuesday.”
• Fix the templates. Update templates and images so new VMs and containers start out patched. For containerized applications, rebuilding on patched base images and libraries from TrueSource and Bitnami Secure Images can make that quicker.
• Plan for the ones that can’t be fixed. Keep systems that can’t be patched right away, or at all, like applications stuck on an old version of PHP, behind the tightest segmentation you have until they can be upgraded or retired, and do the upgrade testing on a cloned copy, as described above.

Snapshots have evolved into a serious risk-mitigation tool inside the platform, but they are often overlooked because of legacy ideas and practices, and because they blur boundaries inside organizations. Moving forward, as more all-hands-on-deck weeks like this happen, you need to use all the tools you have at your disposal.

Check Who You Trust

Browsers have already stopped trusting the eMudhra intermediates, but software that keeps its own list of trusted certificates, like Python, Go, and Node.js applications, container images, and many appliances, may keep trusting them until it’s updated.

Inside VCF, people establish trust between components, for example by confirming an ESX host’s certificate fingerprint when adding the host to vCenter, or by verifying a component’s certificate when connecting it to VCF. The places to look are your guests, your applications, and anything you’ve added to VCF’s trust stores:

• Update guest operating systems and runtimes. Operating system updates usually refresh the system trust store, and applications with their own trust stores need their own updates, which may mean rebuilding container images, and snapshots make those updates safer, too.
• Check what you’ve added to VCF. vCenter’s trusted roots may include public CA certificates added for an integration or a proxy, so review the list in the vSphere Client under Administration > Certificates > Certificate Management, or with the PowerCLI Get-VITrustedCertificate cmdlet, and remove anything you no longer trust.
• Keep VCF’s own certificates current. VCF Operations can manage and replace certificates for VCF components across your fleet, and our post on certificates covers how VCF uses them.
• Leave certificate checking on. If a service breaks because it no longer trusts a certificate, get it a new certificate from a CA you trust instead of turning off verification.

Make the Next Busy Week Easier

It’s painful to think about, but there will be more weeks like this one in the future. It’s much easier to get through calmly when you already know what you run, who owns it, and how to shield and patch it quickly. In VCF, that means current inventory and tags, vDefend segmentation and egress rules in place before you need them, snapshots and staged rollouts as part of every patch, logs stored where attackers can’t easily reach them, and a recovery plan you’ve practiced.

While you work through this week’s issues, keep notes on what went well and what didn’t, including information you wanted but didn’t have, like where PHP was running or which VMs receive traffic from the Internet, and steps that took longer than you expected. Once things calm down, go back through those notes and pick the improvements that will help the most next time.

The VCF Security Configuration Guide is the definitive guide to securing VCF, with hardening guidance across all of VCF and scripts that help you check your environment against it. If you’d like help deciding where to start, the Frontier AI Security Readiness Program includes an assessment that scores your VCF environment’s security posture and can help show where the gaps are.

The same practices can pay off well beyond patching, too, when ransomware hits, when hardware fails, when an application upgrade goes sideways, or when someone deletes the wrong thing. Do the work, and the next incident, of any sort, can be just a busy week instead.