Two critical vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, allow attackers to execute code on vulnerable web servers without authentication. PHP released fixes on October 21, 2026, including versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
But patching your servers is only part of the response. Organizations must also understand what their websites delivered to customers during the exposure window, including scripts served by third-party vendors whose infrastructure may have been vulnerable.
What Happened
Details of both vulnerabilities leaked on October 20, ahead of their coordinated disclosure, prompting the PHP project to accelerate its security release. Both flaws are rated critical at CVSS 9.2 and allow unauthenticated remote code execution. An attacker doesn't need a password, a stolen account or prior access to your environment. They only need a vulnerable server that can be reached from the internet.
Who Is Affected
Any website running a vulnerable version of PHP may be at risk, including sites built on WordPress, Drupal, Joomla and Magento (Adobe Commerce). The vulnerabilities affect a broad range of PHP installations, making it critical for organizations to identify affected systems and apply the appropriate security updates.
The PHP project has released fixes for supported versions, along with limited security backports for certain older versions. Organizations running outdated PHP installations should work with their hosting providers or vendors to determine the appropriate remediation path.
For organizations unable to patch immediately, cybersecurity agencies have recommended restricting access to vulnerable systems or taking affected internet-facing applications offline until they can be secured. This presents a difficult tradeoff: maintain availability and the customer experience while potentially exposing systems to attack, or prioritize security at the expense of business continuity.
The exposure doesn't stop at your own servers. Many of the scripts running on your checkout, login and account pages are delivered through third-party infrastructure, including analytics tags, chat widgets, A/B testing tools, marketing pixels and plugins. If those vendors operate vulnerable PHP infrastructure, the scripts running on your pages could be compromised at their source, even if your own servers are fully patched.
Why a Server-Side Vulnerability Creates Risks for Your Web Pages
An attacker who exploits a vulnerable PHP server may gain the ability to modify files, inject malicious code or install a backdoor that provides persistent access to the compromised system. From there, attackers could alter the pages and scripts delivered to customers, even after the original vulnerability has been patched. This creates opportunities to:
- Inject a skimmer into payment and login forms to capture card numbers, credentials and personal data as users type them.
- Change form behavior so that a copy of what users enter is quietly sent to a server the attacker controls.
- Add redirects or fake overlays that send users to phishing pages that look legitimate.
- Modify a third-party script at its source, so every website that loads it starts delivering malicious code at the same time.
In each case, malicious code executes on your website, often delivered through a trusted third-party script. Traditional security controls, including firewalls and vulnerability scanners, may not detect unauthorized script behavior on your pages after they load. This creates a critical visibility gap that attackers can exploit to steal sensitive customer data.
What To Do Now
- Inventory every PHP application. Include microsites, legacy campaign pages, partner portals, staging environments and acquired domains, not just your main site.
- Apply the appropriate PHP security updates immediately. Restart PHP-FPM or your web server to ensure the patched version is running.
- Isolate what you can't patch. For end-of-life versions or vendor-hosted apps, restrict access to vulnerable applications or temporarily take them offline until an appropriate fix is available.
- Ask your script vendors about their exposure. Find out whether the infrastructure serving scripts to your pages runs PHP and when it will be patched.
- Baseline your sensitive pages now. Record which scripts load on checkout, login and form pages today, and what data each one can access. After you patch, you'll be able to tell whether anything was added during the exposure window.
- Investigate potential compromise and backdoors. Review logs and file changes dating back to October 20. Look for unexpected uploads, modified PHP files, unauthorized administrative accounts, suspicious outbound connections and potential backdoors that could allow attackers to maintain access after patching.
A patch closes the vulnerability. It doesn't tell you whether someone got in before you closed it, and it does nothing about the vendors you depend on.
How Feroot Helps Protect Against Web Supply Chain Attacks
The most damaging web attacks of the last decade didn't start with one company's server being breached. They started with one trusted script being compromised, and that script was loaded by thousands of websites.
The compromise of AppsFlyer's JavaScript SDK in March 2026 illustrates how attackers can exploit trusted third-party infrastructure to distribute malicious code. Malicious code was distributed through the vendor's infrastructure, potentially affecting websites that loaded the compromised SDK. Those websites made no changes to their own code, and they still delivered the attack to their users. A critical server-side vulnerability like this one could create similar opportunities for attackers to compromise the scripts delivered through vulnerable third-party infrastructure. Any third-party script vendor operating vulnerable PHP infrastructure could introduce risk to your website and the sensitive data customers enter on it.
Feroot DXSecure helps organizations secure the digital experience layer by providing continuous visibility and protection for the scripts and third-party code running on their websites and web applications.
- Continuous discovery and inventory. DXSecure's AI agents find every page across your web properties and catalog every first-party and third-party script running on them. You see what loads, where it comes from and what data it can access.
- Runtime behavior monitoring. DXSecure doesn't trust a script because of the domain it comes from. It monitors script behavior at runtime on your web pages and flags new scripts, modified code and unexpected behavior, such as a tag that suddenly starts reading payment fields.
- Real-time blocking. When a script attempts to skim form data, inject unauthorized code or transmit sensitive information to an unauthorized destination, DXSecure enforces security policies to block the activity.
- Supply chain visibility. Gain visibility into first-, third- and fourth-party scripts, including the vendors responsible for loading them, to identify potential risks across your web supply chain.
- Audit-ready compliance evidence. Feroot's PaymentGuard solution helps organizations support PCI DSS 4.0.1 Requirements 6.4.3 and 11.6.1 by providing script inventory, monitoring and reporting capabilities that support compliance assessments.
Patching addresses the vulnerabilities in your servers, but it doesn't automatically eliminate the consequences of a prior compromise. Feroot does not detect or remediate PHP vulnerabilities or server-side backdoors directly. Instead, DXSecure helps organizations identify and block unauthorized script activity on their websites that may result from a compromised server or third-party vendor, protecting sensitive customer data at the digital experience layer.
Know what's running on your most sensitive pages. Get a free website assessment to identify scripts, uncover potential risks and strengthen your web application security.
