From PHP2Shell Alert to Action: Identify and Patch Your Workloads Using VMware Salt

A vulnerability alert starts the response. Salt helps carry it through discovery, approved repair, and verification—at scale, across your entire fleet.

A critical PHP advisory lands. Security wants to know which systems could be affected. Operations need the right packages, the right configuration, and a safe way to replace running workers. Application owners need confidence that their services are secure.

Our PHP2Shell use case connects those activities through Salt. The easiest way to understand it is to follow the minion: the Salt agent on a managed server.

The Problem: Patch the system running the affected application

The original PHP2Shell vulnerabilities, CVE-2026-109618 and CVE-2026-109619, concern PHP serving web requests. PHP published security releases on October 21. Its October 23 advisory described an additional, configuration-dependent issue, CVE-2026-115560, and recommended disabling session upload progress pending a fix. Our workflow tracks package patching and that mitigation separately. PHP’s advisories explain the affected configurations and response. 

Apache matters when it hosts PHP or passes requests to PHP-FPM. The PHP runtime needs the fix, and affected workers need replacement so that new code and settings take effect. Installing Apache alone does not establish exposure to these PHP vulnerabilities; upgrading Apache alone does not repair PHP.

The goal: Identify the runtime, apply the approved patch, and verify the application before closing the finding.

Follow the Minion: Five steps from identification to remediation

Figure 1 follows one Linux or Windows server. Blue activities are supplied by the Salt states. The other activities show where customer review and validation complete the response.

 Figure 1. One server’s journey through discovery and remediation. 

1. Discover what is installed

The discovery state inventories Linux OS-managed PHP packages. On Windows, it combines package information with checks of configured and common runtime locations, services, and hosting configuration. This helps locate PHP associated with Apache or IIS, including deployments that need explicit ownership mappings.

2. Decide what needs attention

Salt compares the inventory with the selected security baseline and checks the declared upload-progress configuration. The result tells an operator whether the system needs patching, needs mitigation, is mitigated or already patched, or has no PHP detected in the checked scope. Incomplete information produces undetermined and requires review.

Vendor package revisions matter. Ubuntu can deliver a security fix while retaining an older upstream version number. The states account for supported vendor baselines and explicit approved overrides, avoiding unnecessary demands for an upstream version unavailable in the repository. Ubuntu’s PHP security notice lists its corrected packages.

3. Preview and apply the approved patch

The patch state uses configured Linux repositories or approved Windows Winrepo packages and deployment mappings. Operators can preview proposed changes before applying them. Where the additional mitigation is required, Salt disables session.upload_progress.enabled in the declared startup INI files.

On Windows, confirm that exact approved versions are available in Winrepo and that runtime ownership mappings and service names match the existing installation. For deployments already using the supplied fixed-path wrappers, the corrected installer addresses a download failure that could leave Apache and its service missing. It uses .NET downloads with bounded HTTPS redirects while retaining archive checksum and Microsoft signature checks. Other production layouts require their own approved installers; the production setup guide explains both paths.

Configuration coverage must be confirmed by the operator: another startup file, pool, or server setting must not re-enable the feature. A package inventory also cannot prove that a particular application is exploitable.

4. Check configuration and replace workers

Relevant configuration checks gate service actions. Salt coordinates restarts of affected running Apache, PHP-FPM, or configured Windows services and started IIS application pools. Stopped services remain stopped. A configured Windows service must already exist; repair an incomplete installation or correct its mapping before patching. A failed prerequisite blocks dependent work and leaves the failure visible for investigation.

5. Verify the outcome

Run discovery again, confirm active workers, test application health, and validate the finding with the security team’s scanner. A mitigated result means the earlier package fixes are present and the declared workaround is configured; active-worker verification still matters.

A practical demonstration: The Ubuntu lab starts with current repository packages and upload progress enabled, reports needs mitigation, applies the configuration change, and then reports mitigated. The setup and run guide walks through this sequence on a dedicated test minion.

Connect virtual patching with workload remediation

VMware’s Neutralizing PHP2Shell: Stopping Critical PHP RCEs with VMware vDefend and Avi WAF describes network and application protections for the original PHP2Shell vulnerabilities. Gateway inspection and Avi WAF rules can intercept exploit attempts while teams prepare software updates. 

The Salt use case adds the work inside the managed server, connecting that protection window to a verified repair:

• Identify the installed runtime. Linux package inventory and Windows package, executable, and hosting checks complement traffic-based visibility. They help operators assess supported managed systems even when PHP version information is absent from HTTP headers. Containers and runtimes outside the discovery scope still require separate coverage.
• Apply the approved change. Salt updates PHP through the configured repositories or Winrepo mappings, accounts for approved vendor backports, and enforces the upload-progress workaround in the declared INI scope. That configuration step also addresses the separate October 23 advisory; the linked October 21 post discusses the original vulnerabilities.
• Verify worker replacement and retain evidence. Configuration tests, service actions, and repeatable assessments support the operational handoff. Operators then confirm the effective web runtime, application health, and scanner results before closing the finding.

Teams can use these layers together: apply the relevant vDefend and Avi protections, prioritize affected workloads, run Salt remediation on canaries, and expand after validation. Network controls and Salt jobs require their own configuration; this use case does not deploy WAF rules or correlate security telemetry automatically. The production setup guide covers the workload preparation and verification steps.

From one server to a mature customer response

A mature customer can connect these actions to its security, platform, and change-management processes. Figure 2 shows the proposed operating model around the supplied states.

Figure 2. A proposed customer operating model. Integrations, policy gates, application checks, and recovery procedures require customer configuration.

1. Scope the finding. Combine advisory or scanner information with Salt assessment results, application ownership, and business criticality.
2. Prepare and authorize. Review version-controlled states, approve package sources and configuration, and select the maintenance policy.
3. Start with a canary. Remediate a small representative group; check worker replacement, application health, and scanner results.
4. Promote in waves. Use configured Salt orchestration to sequence the rollout. Stop promotion when validation fails and follow the approved recovery procedure.
5. Keep the evidence. Attach assessment results, changes, and validation to the customer’s change or security record, then reassess periodically.

Auto-remediation is possible: these states supply the discovery and repair actions. Customers can configure scheduled assessments or event-triggered workflows to apply approved repairs to eligible systems. Salt’s Reactor responds to events, while Orchestration coordinates actions across systems. Approval routing, ticket updates, load-balancer draining, and rollback procedures must be implemented for the customer’s environment.

The bigger security and compliance opportunity

The same pattern applies beyond PHP. Salt’s configuration management states describe how a system should be configured and apply the changes needed to reach that condition. Teams can use that foundation to:

• Enforce hardening policies. Manage approved packages, file permissions, accounts, services, and security settings consistently.
• Detect and correct drift. Schedule comparisons with the approved configuration and remediate deviations according to policy.
• Coordinate response. Combine targeted execution, configuration changes, and service actions in a reviewed operational workflow.
• Support compliance evidence. Retain job results and change history, alongside independent validation, to demonstrate how selected controls are maintained.

Customers can choose and implement their own control policies, retention, reporting, and integrations suitable for their organization. Those capabilities support a compliance program through VMware Salt; certification and complete benchmark coverage require their own assessment and remediation.

The files for setup and execution of this use case can be found on github, here.

Scope: This draft describes the supplied PHP2Shell states for the original CVEs and the October 23 upload-progress advisory. Linux source builds, containers, and runtimes outside configured discovery require separate coverage. Later advisories require separate assessment and baseline updates.