23.10.2026

PHP2Shell: Is the Log4Shell Scenario Repeating Itself?

How to address critical PHP vulnerabilities and reduce the risk of incidents.

Warning from Datakom’s cybersecurity team:

Two critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619, CVSS v4 9.2) allow remote code execution without authentication. Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart all PHP processes. Until then, use a WAF and temporary configuration measures.

If your company’s websites, e-commerce platforms or internal systems run on PHP, they need to be updated within the next few days. On 21 October, the PHP developers released an emergency security update for two critical vulnerabilities collectively known as PHP2Shell. An attacker can exploit them to execute code remotely on a server without any authentication.

PHP powers a large part of the internet, including WordPress, Drupal, Magento, Joomla and Laravel solutions. These vulnerabilities lie in the PHP interpreter itself, rather than in a plugin or application, so virtually every PHP installation that handles web requests is affected. Information about the vulnerabilities leaked before the patches were released, leaving little time to respond.

History repeats itself:
from Log4Shell to PHP2Shell

The situation closely resembles December 2021, when Log4Shell (CVE-2021-44228, CVSS 10.0) was discovered. In that case, the critical flaw was in the Apache Log4j Java logging library. To take over a server, an attacker only needed to submit a single specially crafted string to any field whose contents would be logged.

The vulnerability was disclosed on 9 December. Widespread scanning began the following day, and some attacks had already been observed before disclosure. On 17 December, CISA issued Emergency Directive ED 22-02, requiring federal agencies to remediate the vulnerability by 23 December. Three more related CVEs followed within weeks because the initial patches were incomplete. Total losses are estimated at more than US$10 billion, and attacks continued for years.

The biggest lesson from Log4Shell was not a technical one. For weeks, many organisations could not answer the question, “Where are we actually using Log4j?” The same applies to PHP: it is often embedded in hosting environments, containers, vendor products and forgotten websites.

	Log4Shell (2021)	PHP2Shell (2026)
Affected component	The Log4j Java library, embedded in thousands of products	The PHP interpreter, which powers a large share of websites
Severity	CVSS 10.0; unauthenticated RCE	CVSS v4 9.2; unauthenticated RCE
Disclosure	Details spread before everyone was ready	Leaked a day before the scheduled patch
Exploit complexity	Very simple: a single text string	Complex memory corruption, usually requiring specialist expertise
Time to attacks	Hours after disclosure	First attempts on the day the patch was released
Main challenge	Not knowing where Log4j was used	Not knowing where PHP is running or which versions are in use

What is different this time?

Back then, attacks began quickly because the exploit was trivial. PHP2Shell involves memory corruption vulnerabilities, and just a few years ago, developing reliable exploits for such flaws took weeks of specialist work. This time, several teams reproduced the vulnerabilities on the very first day.

This reflects a broader trend. According to Mandiant, the average time between vulnerability disclosure and exploitation was approximately 63 days in 2018–2019, but in 2025 it turned negative, at around −7 days. In other words, attacks often begin before a patch is available. Research shows that AI tools can produce a working exploit from a vulnerability description in minutes. Meanwhile, organisations still take an average of around 55–60 days to remediate critical vulnerabilities.

CISA also responded within days in the case of Log4Shell. However, its emergency directive and inclusion of the vulnerability in the Known Exploited Vulnerabilities (KEV) catalogue came after attacks were already underway. Today, this gap is even wider, so organisations cannot wait for official confirmation of exploitation. The first hours should be spent identifying affected assets, applying compensating controls and adjusting WAF rules, followed by patching within the first few days.

The vulnerabilities at a glance

Both vulnerabilities are rated critical (CVSS v4 9.2) and can be exploited without authentication.

CVE	Description	Highest risk
CVE-2026-109618	Memory corruption when the server runs out of memory; this can be triggered by a specially crafted multipart request	Apache mod_php, where the attack takes effect before application code runs
CVE-2026-109619	Use-after-free caused by stale state persisting between requests	Environments that reuse worker processes; attack vectors through session upload progress and PHP 8.5 error backtraces

Affected environments:
PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed

Patched versions:

PHP version	Patched version
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
7.4, 8.0, 8.1	No official updates; requires a patch from the distribution or an LTS provider, or an upgrade to a newer version

Status as of 23 October:

CERT.LV and EU-CERT report the first attempted attacks. Several research teams have already reproduced the vulnerabilities, and a public exploit is expected soon. As of 21 October, the vulnerabilities had not yet been added to CISA’s KEV catalogue, but attackers were already exploiting them in attacks involving the automated use of an executable file.

Recommendations: an action plan

Only updating PHP and restarting all PHP worker processes fully remediates the vulnerabilities. The other measures reduce risk until the update has been installed.

Within the first 24 hours

Identify all PHP installations: websites, online stores, customer portals, internal systems, containers and hosting services. Establish the version and operating mode (FPM, mod_php or CGI) for each one.
Prioritise publicly accessible systems and those running Apache mod_php.
Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install the patch provided by your operating system distribution. Then restart all PHP processes.
If hosting is provided by an external supplier, request written confirmation of the update and its completion timeline.

Within 72 hours

For systems running PHP 7.4, 8.0 or 8.1, obtain a vendor patch or prepare a migration plan. In the meantime, apply the temporary protections described in the next section.
Check for suspicious activity since 20 October: unusual PHP process crashes, out-of-memory errors, new files in web directories and unexpected outbound connections. Keep in mind that empty logs do not necessarily mean a system is secure.
Run vulnerability scans to confirm that the update has been installed across all systems.

Within a week

Inform management about the affected systems, the measures taken and the remaining risk.
Implement ongoing monitoring of PHP and other platform versions so that a list of affected systems is immediately available the next time a similar situation arises.
Review the emergency patching process: who makes the decision, how quickly production systems can be restarted and how customers are informed.

Risk mitigation measures

A web application firewall (WAF) and server configuration changes cannot replace an update. However, when properly configured, they make attacks significantly harder and prevent a single vulnerability from turning into a serious incident

Adjusting WAF rules

Virtual patching. Enable your WAF vendor’s rules for CVE-2026-109618 and CVE-2026-109619 as soon as they become available. Check that they are operating in blocking mode, rather than monitoring-only mode.
Multipart request controls. One attack vector involves specially crafted multipart requests. Block these requests entirely in applications that do not require file uploads. For other applications, restrict uploads to specific URLs.
Request size limits. At the WAF or reverse proxy level, limit the request body size, the number of parts and the parameter nesting depth to what the application actually requires.
Rate limiting. An attack may require several consecutive requests to reach the same worker process. Limiting the rate of requests from a single source reduces the likelihood of a successful attack.
Disabling unnecessary endpoints. Block access from the public internet to administration panels, test scripts and unused PHP files.

Server configuration

Apply the settings in php.ini or at the FPM pool level, then restart the processes. Settings applied through ini_set() or .user.ini take effect too late.

session.upload_progress.enabled=0 closes the confirmed session-related attack vector.
fatal_error_backtraces=0 applies to PHP 8.5.
memory_limit=-1 must only be used together with strict post_max_size, upload_max_filesize and request size limits.

Monitoring and containment

Set up alerts for PHP process crashes, out-of-memory errors and unusual spikes in 5xx errors. Give the web server process only the permissions it needs and restrict its outbound connections. This prevents an attacker from moving further into the internal network even after a successful attack.

Sources

How Datakom can help?

The Datakom team can help you quickly establish whether your systems are at risk and secure them. We have been providing cybersecurity services for more than 10 years.

Vulnerability assessment. We identify all your PHP installations and their versions, and prepare a prioritised update list.
Patching and WAF configuration. We help install patches, configure temporary protections and adjust WAF rules without disrupting your applications.
Compromise assessment. We check whether your systems were accessed without authorisation before the update was installed.
SOC monitoring. Our security operations centre continuously monitors your systems so that attempted attacks are detected and stopped in time.
Virtual Chief Information Security Officer (vCISO). We help establish a patch management process and prepare management briefings, enabling a fast, coordinated response to the next critical situation.

Author:
Arturs Filatovs
Product Manager for Security Solutions

Not sure whether your systems are affected?

Contact us. We can carry out an initial assessment immediately.

Sales: +371 67628888 | sales@datakom.lv

Technical support: +371 67442800 | support@datakom.lv

subscribe to our newsletter

Stay informed about our latest developments and industry insights.

Please leave this field empty.

I agree with Privacy Policy

Professional IT services and infrastructure solutions for businesses. We provide reliable technology support and managed services.

SIA Datakom

Reģ. nr. 40103142605
PVN reģ. nr. LV40103142605

Maldugunu iela 2, Marupes novads, Marupe, LV-2167,

AS Luminor Bank Latvian branch, RIKOLV2X LV69RIKO0000080227272

Office

+371 67628888

info@datakom.lv

Sales

+371 67628888

sales@datakom.lv

Service

+371 67442800

support@datakom.lv

Marketing

+371 67628888

marketing@datakom.lv

Tiki-Taka PAY

Datacenter AI

Datakom products

Infrastructure Solutions

Cybersecurity Solutions

Datakom AI Solutions

About us

Partners IT solution

23.10.2026

PHP2Shell: Is the Log4Shell Scenario Repeating Itself?

Warning from Datakom’s cybersecurity team:

History repeats itself:
from Log4Shell to PHP2Shell

What is different this time?