An order portal can keep working while the PHP runtime behind it remains unpatched. A business owner needs an answer that identifies which services use PHP, who maintains them, and what evidence confirms the fix.
On October 21, 2026, the PHP security team released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which can allow unauthenticated remote code execution (RCE). The upstream fixes are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The team urges immediate updates in its October 21 security advisory.
This article reflects sources checked on October 22, 2026, and proposes a business patch workflow. The systems and responsibilities below form a hypothetical example, not an attack report or an account of an Enersys customer deployment.
Where should a PHP web service review start?
PHP's advisory covers installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The team considers mod_php the highest risk and reports a demonstrated exploit that runs before application code. That supports urgent review and patching; it does not establish that every website has been attacked. Scope identified by the PHP team
A CMS name or a website's appearance cannot establish its exposure or patch status. Ask the maintainer to inspect the runtime actually handling requests, including container copies, standby systems, and provider-managed hosting. A command-line PHP check alone may describe a different runtime from the one used by the web server.
CVE-2026-109618 concerns out-of-memory handling while internal request data is only partly initialized. CVE-2026-109619 concerns internal state surviving after its backing memory has been freed and potentially being used by a later request. The OOM corruption advisory and stale global state advisory provide the technical conditions.
Match the fix to the package source
For releases obtained directly from the PHP project, check the fixed release for the branch in use, then review current release notes again before installation.
| PHP branch |
Fix released on October 21, 2026 |
| 8.5 |
8.5.12 |
| 8.4 |
8.4.27 |
| 8.3 |
8.3.36 |
| 8.2 |
8.2.35 |
A Linux distribution or long-term support vendor may backport a fix while retaining an older upstream version number. Obtain the vendor notice covering both CVEs and the fixed package identifier, then compare it with the installed package. The upstream version number alone is insufficient. PHP directs users to check vendor packages in its update guidance.
For hosting where the business does not install PHP itself, open a provider request naming the service and both CVEs. Ask for confirmation of the fix, the systems covered, and when the updated runtime became active. “The system has been updated” should come with evidence that can be checked later.
Turn the advisory into work that can be closed
Suppose a wholesaler runs a PHP 8.2 order portal that sends sales orders to its ERP. Operations can see that customers can still place orders, but does not know which PHP package the hosting provider uses. The immediate goal is to patch PHP while preserving the order from customer confirmation through acceptance by the receiving system.
The IT owner should collect the service name, runtime location, version and package identifier, update source, web server integration, and maintainer in one inventory. Record internet exposure and unanswered questions so the manager can prioritize work and follow up on missing information.
Next, the hosting maintainer or vendor confirms the fix, the application team prepares a representative staging environment, and the sales process owner defines acceptable transaction results. Responsibilities should produce evidence such as the following.
| Role in the hypothetical example |
Evidence needed for the decision |
| Hosting or infrastructure maintainer |
Vendor notice covering both CVEs and the package or image to be installed |
| Application developer and tester |
Results for login, order submission, document upload, and delivery to ERP |
| Sales process owner |
Confirmation that amounts, items, and order status match the test transaction at the destination |
| Change approver |
Installation window, stop or rollback criteria, and a named person monitoring after the change |
These tests are proposed for this fictional portal. Each business should choose tests for its actual services, including scheduled jobs and integrations that are absent from the web interface. Passing business tests helps detect update regressions; it does not prove the absence of all vulnerabilities.
Test the patch and prepare recovery before production
Install the patch in staging through the same channel intended for production. Check required extensions and configuration, then submit an order using non-sensitive test data. Follow it through the receiving system: no missing or duplicate records, and the expected error handling when delivery fails.
Before the production change, confirm usable backups and recovery steps. Define stop criteria, such as failed order intake or mismatched downstream records, and name the decision maker. Rolling back to an unpatched PHP runtime restores the vulnerability too. That decision therefore needs explicit limits on the affected service and a follow-up fix plan.
After installation, the maintainer must confirm that active workers and containers use the fixed package through the procedure appropriate to that system. New files on disk do not establish that old processes have stopped using the previous runtime. Attach evidence of the running version, service checks, and a post-change order test to the same work item.
Choose monitoring signals connected to the business process, such as web errors, queued integration jobs, or orders whose status differs from ERP. Assign an owner and a review period. Systems awaiting a vendor response need a named owner and a next follow-up date.
What if patching is delayed?
The PHP team says temporary measures reduce exposure to particular attack paths, and only an update provides the complete solution described in its advisory. Maintainers should read the limits of each temporary measure before changing configuration. A generic command list is unsuitable for every deployment.
While awaiting the fix, the responsible team should assess restricting access or suspending the affected service against the business impact. Record the controls applied, remaining exposure, the person accepting the risk, and the review time. A WAF or hidden error messages should never be treated as evidence that PHP has been patched.
PHP 8.2 also needs a migration date
PHP 8.2.35 fixes this advisory, but does not extend the branch's support life. PHP project security support for 8.2 ends on December 31, 2026, according to its supported versions table. Track the urgent patch separately from the project to move to a branch with continuing support.
For PHP 8.1 and older, verify the entitlement and scope of vendor maintenance individually. The existence of selected backports does not restore normal PHP project support. Assign compatibility testing, an owner, and a migration date that can be tracked.
Questions to resolve before closing the work
Which PHP version fixes these vulnerabilities?
The PHP project released 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on October 21, 2026. For distribution or vendor packages, use a vendor notice covering both CVEs and confirm the installed package identifier.
Does a working website mean the fix is installed?
No. Obtain evidence of the running runtime and patch, along with important transaction tests after the update. A successful page load is only one service check.
What belongs in the completion record?
Include the service and maintainer, patch evidence covering both CVEs, the running version, business test results, recovery plan, and outstanding items with follow-up dates. This lets the approver distinguish services that have been fixed from those still requiring action.
Related reading
AI-generated illustration created for this article, not an image of an actual attack.
