After PHP2Shell: critical vulnerability response for a small team in the first 48 hours

On 21 October 2026, the PHP project released fixes for two critical remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619. For a small team, critical vulnerability response in the first 48 hours comes down to five steps: identify every place the software runs, prioritise systems exposed to the internet, patch or mitigate the highest-risk systems first, verify that the corrected version is actually running, and check for signs of compromise.

Key facts

In this article

• What happened with PHP on 20 and 21 October, and what is still unknown?
• What does critical vulnerability response look like for a small team in the first 48 hours?
• How do you decide what to fix first?
• Should you patch or mitigate when the fix has only just landed?
• How does a bug like this actually work?
• Why do security embargoes break, and how does that affect your response time?
• How do you make the next 48 hours shorter?
• Where RocketDevs fits
• Conclusion: make the first 48 hours count before they begin
• Frequently asked questions

What happened with PHP on 20 and 21 October, and what is still unknown?

PHP is a programming language widely used to build websites and web applications. It often runs behind the scenes, processing requests, connecting to databases, and generating the pages users see. Because PHP runs on servers connected to the internet, a serious vulnerability can give an attacker a way to execute malicious commands on an affected server.

On 21 October 2026, the PHP security team released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. On 26 October the US Cybersecurity and Infrastructure Security Agency (CISA) added both to its Known Exploited Vulnerabilities (KEV) catalogue, and Amazon has reported exploitation attempts dating back to 17 October, four days before the fixes were public. Reports of attack attempts, an early disclosure, and uncertainty about how many attacks have succeeded still leave important questions unanswered.

The PHP project's advisory confirms that versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. In plain English, remote code execution means an attacker may be able to run their own commands on a vulnerable server from another computer. Unauthenticated means they may be able to do this without first logging in.

The vulnerabilities affect several ways PHP can handle web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP advisory identifies mod_php as the highest-risk configuration.

The two vulnerabilities work differently. CVE-2026-109618 allows remote code execution through out-of-memory corruption, while CVE-2026-109619 involves remote code execution through stale global state.

Wiz Research, one of the organisations that reported the vulnerabilities, says that every PHP version released over the previous decade is affected by at least one of the flaws, reaching back to version 5.4. Wiz sells cloud security products, so its framing should be considered in that context. The PHP project's own advisory remains the primary source for the affected versions and official fixes.

How the disclosure unfolded

The events of 20 and 21 October developed quickly. The following timeline uses UTC to make the sequence clear.

The release did not follow the original schedule precisely. The Hacker News discussion about PHP 8.2.35 appeared at 13:45, before the advertised 14:00 release time, while a joint statement from European organisations placed the release at 13:40. By our count, the interval between the pre-announcement and the GitHub release was just under 19 hours.

For a small engineering team, that timing matters. A team that planned to begin patching at 14:00 could already have lost valuable time. Security incidents do not always unfold according to the published schedule, so teams need to monitor developments and prepare before a fix becomes available.

How much is attacked, and how much is noise?

The number of affected servers that attackers have targeted remains unknown, and public reports differ on whether any attacks have succeeded.

CISA's alert said at first that it had not observed successful exploitation in the wild. On 26 October it added both vulnerabilities to the KEV catalogue. On 23 October, Johannes Ullrich of the SANS Internet Storm Center also wrote that he knew of no reliable public exploit, while noting that Cloudflare and Amazon had reported a large number of exploit attempts.

Other reports describe more concerning activity. Cloudflare says it observed attack traffic and attackers changing their payloads to bypass its security rules. Its chief technology officer also told BleepingComputer that the company was already observing early attacks.

Amazon Threat Intelligence reports that its MadPot honeypots logged "a PHP2Shell exploitation attempt dating to Oct. 17, 2026", four days before disclosure, and that PHP2Shell "is now seeing broad exploitation attempts in the wild." Amazon also says it is unclear whether any of those attempts would have succeeded on real systems.

Cloudflare and Amazon both sell security products. Cloudflare has not published a count of the relevant attempts, and Amazon does not say how many succeeded.

Attempts and intrusions are still different things. As TryHackMe's roundup puts it: "An attempted exploit is not the same as a successful intrusion." Security systems can detect malicious requests without those requests gaining access to a server. A KEV listing tells you CISA has evidence of active exploitation. It does not tell you how many systems were breached, or whether yours was.

The missing information is substantial. No public source establishes the total number of attempts, how many succeeded, or which builds were targeted.

For a small team, the practical conclusion is straightforward: do not interpret the absence of publicly confirmed compromises as proof that your own systems are safe. Check your exposure, patch affected systems, and investigate suspicious activity.

Is it easy to exploit?

The answer depends on the configuration and the exploit being tested. Different researchers have reported different results, and those findings should not be treated as mutually exclusive.

Wiz says it demonstrated unauthenticated remote code execution against WordPress deployments. The PHP advisory also warns that a working exploit against mod_php can execute before any application code runs. This is important because an application-level security control may not have an opportunity to intervene.

On 21 October, Elias Taylor reported that public proof-of-concept exploits he tested did not work on a standard installation. Security researcher Daniele Berardinelli separately outlined eight conditions that a reliable exploit must satisfy, while warning that an unreliable exploit does not make the vulnerability safe to ignore.

The distinction is between a demonstration that works in a particular environment and a reliable exploit that works against a range of real-world systems. An exploit may fail on one installation but succeed on another because of differences in configuration, PHP versions, or other environmental factors.

Do not rely on an exploit being unreliable as a security measure. Attackers need working exploits for only some of the configurations they encounter. Your team may not know which configurations they can target successfully, so patching and verification should take priority over trying to establish whether a public proof of concept works against your own systems.

A patched release is not necessarily the end

Cloudflare's 23 October update reported a related vulnerability, CVE-2026-115560, which it said affected fully patched PHP releases, including PHP 8.5.12. According to Cloudflare, the issue was expected to be fixed in the next regular PHP release.

Cloudflare is the only source cited here for this identifier, and the National Vulnerability Database had no record of it on 25 October. It should therefore be treated as a reported issue rather than a confirmed vulnerability.

Nevertheless, the operational lesson remains useful. An emergency patch may not be the final change required, particularly when researchers continue investigating related weaknesses.

Small teams should keep their deployment process ready for another update. That means knowing which systems run PHP, understanding how patches are deployed, and having a way to verify that a subsequent fix reaches the affected systems.

Do not assume that installing one emergency release means you can stop monitoring the situation. Continue following official advisories and assess new information as it becomes available.

Why this is not only a PHP story

PHP's widespread use makes the incident relevant even to businesses that do not develop software themselves. W3Techs reports that PHP is used by 69.2% of websites for which it can identify the server-side programming language.

The level of public interest also increased sharply. According to Wikimedia's page-view data, the English Wikipedia article about PHP received 928 views on 20 October and 87,141 views on 21 October.

A business does not need to write PHP code to depend on it. Its marketing website, help centre, content management system, or a third-party appliance may run PHP behind the scenes. The challenge for a small team is identifying these dependencies, particularly when a vendor manages the underlying infrastructure.

The same day brought another security concern involving Railway. On the morning of 21 October, the platform reported anomalous activity involving systems that store customer environment variables. It advised customers to rotate their environment variables and registry credentials and paused deployments while investigating.

This was a different type of incident. The PHP vulnerabilities concern software that an organisation or its service providers may run, whereas the Railway incident concerned a platform on which customers may depend.

The distinction changes the immediate response. With an affected PHP installation, the priority is to identify exposure, apply the relevant fix or mitigation, verify the running version, and investigate potential compromise. With a potentially compromised hosting or development platform, the response may instead begin with rotating credentials, reviewing access, and following the provider's incident guidance.

For a small team, both incidents reinforce the same broader lesson: security response depends on knowing which systems you control, which services you rely on, and what action each type of incident requires.

What does critical vulnerability response look like for a small team in the first 48 hours?

Spend the first four hours finding every copy of the affected software, the next eight ranking those copies by exposure, and the remainder of the first day patching or mitigating the highest-risk systems. On the second day, verify that the fix is running and investigate signs of compromise. This 48-hour timeline is our recommendation, not an established industry standard. Its purpose is to give small teams a clear order of operations when time and resources are limited.

Hours 0 to 4: find every copy

The first question is not how serious the vulnerability is. It is where the affected software runs.

The UK's National Cyber Security Centre (NCSC) recommends identifying systems running any version of PHP across the organisation's infrastructure and prioritising internet-facing systems. It also advises teams to check third-party vendors, including appliances and services that may bundle PHP. The US Cybersecurity and Infrastructure Security Agency (CISA) makes a similar point: PHP is often included within other software, so its presence may not be immediately visible. A joint statement from the European Union Agency for Cybersecurity (ENISA), CERT-EU, and the European Commission reinforces the need to look for PHP running behind the scenes.

This discovery process determines everything that follows. If you do not know which systems contain the vulnerable software, you cannot reliably identify which systems need patching.

The US Cyber Safety Review Board highlighted this problem in its review of the Log4j incident. It described an accurate inventory of technology assets and applications as an established cybersecurity best practice that helps organisations identify affected systems during an incident.

The US Government Accountability Office's investigation of the Equifax breach provides another example of the consequences of poor asset management. An outdated recipient list meant that the vulnerability notification did not reach the appropriate people, while a subsequent scan missed the vulnerable portal. The result illustrates how a patch can be available without reaching the system that needs it.

A small team does not need an elaborate asset management database to get started. It needs a spreadsheet covering every plausible location where the affected software could be running. Build that list from six sources.

Two common mistakes deserve particular attention.

First, do not rely solely on the PHP installation available from your terminal. Datadog warns that the command-line installation may differ from the version serving web requests. Your terminal could report a patched version while the web server continues using a vulnerable one.

Second, updating application dependencies does not necessarily update PHP itself. Flavio Copes highlights that updating WordPress plugins or running composer update does not automatically update the PHP runtime. A successful dependency update therefore does not prove that the vulnerable interpreter has been fixed.

If you cannot identify a version within the first four hours, record it as an unknown, assign an owner, and document the action being taken. For example, note that the hosting provider was contacted at 11:40 and that a response is pending.

An unknown with an owner and a follow-up time is a managed risk. An unknown nobody is tracking can become a missed vulnerability.

To reduce the time needed for this process during future incidents, improve your software inventory before the next critical advisory arrives.

Hours 4 to 12: rank by exposure

Once you know where the software runs, rank each installation according to how easily an attacker could reach it.

Start with systems that accept requests from unauthenticated users over the internet. CISA and the NCSC both recommend prioritising internet-facing systems. CISA's implementation guidance for directive BOD 26-04 describes an exposed asset as one accessible to unauthenticated or untrusted entities through a public network.

This makes exposure a more useful starting point than simply sorting systems by their vulnerability scores. A critical vulnerability on a publicly accessible server may require more immediate attention than the same vulnerability on an isolated internal machine.

Prioritise internet-facing systems first, followed by other affected systems according to their accessibility, evidence of exploitation, and the potential consequences of compromise. Internal systems and those protected by a VPN still need patching, but their relative priority depends on the actual risk.

The next section examines how to build a more detailed ranking.

Hours 12 to 24: patch or mitigate

Begin by patching the highest-risk systems through your normal build and deployment process. Where appropriate, deploy to a small canary group first, verify that the application still works, and then continue rolling out the fix.

A canary deployment means updating a limited number of systems before applying the change everywhere. It helps the team identify unexpected problems without exposing the entire service to a potentially faulty deployment.

If a patch is unavailable or cannot be applied immediately, use a suitable temporary mitigation. Record which systems remain vulnerable, what protection has been applied, who owns the outstanding work, and when the mitigation will be reviewed.

If neither a patch nor a mitigation adequately protects a system, isolate it where feasible.

The important point is to make a deliberate decision for every affected installation. Do not assume that one deployment fixes every copy of the software, particularly when different services use different runtimes or deployment processes.

Hours 24 to 36: prove it

A patch that has not been verified is an assumption, not a confirmed fix.

After deployment, check the version used by the running web process and confirm that the relevant workers have restarted. Long-running workers may retain old code in memory, so updating files alone does not necessarily mean that every active process is using the corrected version.

Some deployment guides, such as Sliplane's, recommend running php -v inside the relevant container after updating it. This is useful for checking the command-line installation, but it is not sufficient on its own. You must also verify the runtime serving web requests.

Pinned container image tags are another potential problem. A deployment that continues using an older pinned image will not automatically receive the fix simply because a newer image exists. Update the image reference, rebuild where necessary, and redeploy.

There is also an important complication with operating-system packages. As Datadog notes, distribution vendors sometimes backport security fixes into their existing package versions rather than changing the version number to match the latest upstream PHP release.

Consequently, a version number that looks older is not automatically proof that the system remains vulnerable. Check the security advisory from your distribution vendor and confirm whether the specific package build contains the relevant fix.

Your verification record should identify the system, the deployed build, the evidence that the running service uses it, and the person who confirmed the result.

Hours 36 to 48: look for compromise

Applying a patch closes a vulnerability, but it does not remove anything an attacker may already have installed or changed.

Investigate whether there are signs that someone exploited the vulnerability before the fix was deployed. Start the search from 17 October, the date of the earliest attempt Amazon has reported, not from the day you patched. Wiz recommends paying attention to unusual multipart HTTP requests followed by memory-limit errors. CISA also advises monitoring for suspicious activity, including PHP worker processes launching shell commands or downloading tools.

Look for unexpected child processes started by web workers, unfamiliar files in directories writable by the web application, and unusual bursts of HTTP 500 errors before the patch was installed. Compare findings with deployment records and normal application behaviour so that legitimate activity is not mistaken for an attack.

If you find suspicious evidence, preserve it before cleaning up the affected system. Unplanned changes can destroy information that may help establish what happened, how far the attacker reached, and whether credentials or other systems were affected.

CISA's BOD 26-04 implementation guidance outlines a forensic triage process for US federal agencies, including recommended timelines for scoping and escalation. These are recommendations rather than universal deadlines for every organisation, but a small team can use the underlying sequence:

• Scope: Identify the potentially affected systems and the extent of the exposure.
• Preserve: Protect relevant logs, files, and other evidence.
• Patch: Close the vulnerability or apply an appropriate mitigation.
• Contain: Restrict access or isolate systems where compromise is suspected.
• Analyse: Investigate the available evidence to understand what happened.
• Decide: Determine whether further incident response, recovery, or escalation is required.

The key is to distinguish between a system that was vulnerable and a system that was actually compromised. Both require attention, but confirmed or suspected compromise may demand additional containment and recovery work beyond patching.

When the problem is your platform, not your stack

The PHP incident was not the only security concern reported on 21 October 2026.

Railway published a security disclosure advising customers to rotate environment variables stored by the platform, including API keys and registry credentials. The company said it was still determining the full scope of the incident.

This required a different response from the PHP vulnerability. There was no PHP installation for the customer to patch. Instead, customers needed to treat the secrets held by the affected platform as potentially exposed and replace them.

When a vendor's security notice concerns credentials or secrets, use a separate response process:

• Identify what the vendor holds. List the API keys, environment variables, registry credentials, and other secrets stored or accessible through the service.
• Revoke and replace credentials. Rotate affected credentials at the systems that issued them, following the vendor's incident guidance.
• Review activity. Check your own logs for unexpected use of the credentials and investigate anything suspicious.
• Record the response. Track which secrets have been replaced, which systems depend on them, and whether any further investigation is needed.

This is closely related to the security work covered in RocketDevs' pre-launch security review, which addresses secrets stored in repositories and the checks teams should complete before launch.

The broader lesson is that different incidents require different first moves. A vulnerable runtime calls for exposure assessment, patching, and verification. A potentially compromised platform may require credential rotation, access reviews, and investigation. A prepared team knows which response applies before the pressure begins.

How do you decide what to fix first?

Rank vulnerabilities by internet exposure first, evidence of exploitation second, and severity score third. FIRST, which maintains CVSS, explains that a CVSS base score measures vulnerability severity and should not be used alone to assess risk. A severity score tells you how serious a flaw could be, but not necessarily how urgently your team needs to act.

PHP2Shell is a useful example because different security tools assess the same vulnerability from different angles. Each provides useful information, but none gives you the complete picture on its own.

Why severity scores are not enough

The three severity assessments for CVE-2026-109618 illustrate why teams should not treat a single score as the final word.

The PHP team's CVSS v4.0 assessment gives the vulnerability a score of 9.2. The NIST database assigns it 9.8 under CVSS v3.1, while Red Hat assigns it 8.1 under the same version of the scoring system. The sources show one specific difference: Red Hat rates attack complexity High, where NVD rates it Low.

Red Hat also notes that standard Red Hat Enterprise Linux deployments use PHP-FPM rather than mod_php. This matters because the PHP advisory identifies mod_php as the highest-risk configuration.

These scores are not necessarily contradictory. They reflect different assessment methods and assumptions about how the vulnerability can be exploited.

For your team, use the scores to understand the potential severity, then consider which systems you run, how accessible they are, and what an attacker could do if exploitation succeeds.

Why exploitation evidence matters more than severity alone

CISA's KEV catalogue contained 1,756 vulnerabilities in its 23 October 2026 version, and neither of the new PHP vulnerabilities was in it. Both were added on 26 October, and the 27 October version lists them with a federal remediation deadline of 29 October.

The KEV catalogue is deliberately evidence-based. CISA adds vulnerabilities when it has reliable evidence that they are being actively exploited. That makes inclusion an important signal for prioritisation, but absence from the list does not prove that a vulnerability is safe or has never been exploited.

Of the 1,756 entries in the 23 October version, 1,025 had a 21-day remediation deadline and 280 had a deadline of 14 days, according to our count. The PHP pair got three days.

Comparing the new PHP vulnerabilities with two older PHP flaws already listed in KEV provides further context. CVE-2024-4577 and CVE-2019-11043 have EPSS scores of 0.99987 and 0.99748, respectively. On 24 October, before the KEV listing, the new PHP vulnerabilities had scores of 0.118 and 0.062.

The older vulnerabilities therefore had much higher predicted exploitation probabilities at the time of the cited comparison. However, the new vulnerabilities' lower scores do not guarantee that their exploitation risk will remain low. New evidence, working exploits, or changes in attacker activity can affect the assessment.

The research paper by Jacobs and colleagues explains why severity-based prioritisation alone can be ineffective: severity scores are poor predictors of whether vulnerabilities will actually be exploited. EPSS helps address this limitation by estimating exploitation likelihood across a large number of vulnerabilities.

However, EPSS is still a model. It is useful for comparing vulnerabilities at scale, but it cannot reliably settle every decision about an individual vulnerability during a fast-moving incident, particularly when information is incomplete or changing quickly.

How decision frameworks add context

CISA's SSVC assessment for CVE-2026-109618, in the NVD record, records three important factors: no known exploitation, no expected automation, and total technical impact.

These factors help distinguish the vulnerability's potential consequences from the evidence available about how attackers are using it.

CISA's BOD 26-04 directive sets a three-day remediation deadline for assets that are publicly exposed, have total technical impact, and are considered automatable. The PHP vulnerability has total technical impact, but CISA's SSVC entry marks it as not automatable.

The directive applies to US federal agencies, not private companies generally. It can still serve as a useful example of structured risk assessment, but its deadlines should not automatically be treated as requirements for your organisation. The directive's other deadline categories are presented in an image, so we do not infer additional deadlines from them.

For a small team, the lesson is to assess the vulnerability in context rather than relying on a single score or checklist. Ask whether the system is exposed, whether exploitation has been reported, how much damage a successful attack could cause, and whether the attack can be carried out reliably or at scale.

A practical prioritisation ladder for small teams

Combine the available evidence into four priority levels:

1. Internet-facing systems with credible reports of exploitation: fix immediately, ideally the same day. If a patch is unavailable, apply an effective mitigation or isolate the affected system.
2. Internet-facing systems with critical vulnerabilities but no confirmed exploitation: aim to patch within 24 hours. This was the recommended priority for PHP2Shell on 22 October, given the severity and uncertainty surrounding exploitation.
3. Internal systems or systems protected by a gateway you control: patch within your emergency remediation window, usually within a few days. Adjust the priority if evidence of exploitation or additional exposure emerges.
4. Systems that cannot be patched or whose vendor has not responded: apply an appropriate mitigation or isolate the system. If neither option provides adequate protection, take it offline where feasible until a safe resolution is available.

These timings are a proposed operating framework for a small team, not universal regulatory deadlines. A credible report of successful exploitation, a newly available exploit, or evidence that your own system has been compromised should trigger an immediate reassessment.

For an external reference point, the UK's Cyber Essentials scheme requires critical and high-risk security updates to be installed within 14 days of release. It describes longer delays as a serious security risk. That window of 14 days is an outer compliance reference in that scheme, not a reason to wait when a critical, internet-facing system needs urgent attention.

The principle is simple: fix the systems that are most exposed and most likely to be attacked before working through less urgent installations. Severity tells you how serious the vulnerability could be. Exposure and exploitation evidence help you decide what to do first.

Should you patch or mitigate when the fix has only just landed?

Patch as soon as you can do so safely, ideally within the same day. Use temporary mitigations only when a fix is not yet available or cannot be deployed immediately. The PHP project is clear that “only an update is a complete solution.” Its interim measures reduce exposure to specific attack methods but do not make an installation fully secure.

NIST's patch management guide identifies four ways to respond to a vulnerability: accept the risk, mitigate it, transfer it, or avoid it. It also warns that public disclosure usually increases risk because attackers become more likely to develop exploits targeting the vulnerable software.

When a security fix is available, a small team should work through the following options in order of preference.

What does the patch look like in practice?

Security fixes do not reach every operating system, hosting provider, and deployment platform simultaneously. After PHP publishes an upstream fix, individual vendors may still need to package, test, and distribute it for their supported environments.

Ubuntu rates CVE-2026-109618 as Critical and lists fixed packages across releases ranging from Ubuntu 14.04 ESM to 26.10. Debian lists the fix for Bookworm as 8.2.35-1~deb12u1, under DLA-4848-1, and for Trixie as 8.4.27-1~deb13u1, under DSA-6574-1.

Amazon's advisories list fixes for PHP 8.2 through 8.5 on Amazon Linux 2023 as released on 22 October, one day after the upstream release. However, Amazon marks the core PHP package on Amazon Linux 2 and PHP 8.1 on Amazon Linux 2023 as “No Fix Planned.”

Hosting control panels may provide their own patched packages. Webhosting Today reports that cPanel backported the fixes to its PHP 7.4, 8.0, and 8.1 packages.

These differences matter because the upstream release date does not tell you when a fix became available for your particular environment. The cited trackers do not establish the exact time each package first became installable. Check your distribution's advisory and package status rather than assuming every system received the fix on 21 October.

Containers introduce another potential problem: the image tag used by your deployment.

Sliplane explains that a floating tag such as php:8.4-fpm can pick up an updated image when you redeploy after the official image has been rebuilt. A pinned tag, however, continues to reference the specified image until you deliberately change it or update the referenced image.

Coolify's security advisory similarly says that PHP applications may need their runtimes or images updated, followed by a rebuild or redeployment where necessary.

The official PHP image on Docker Hub had been pulled 1,386,874,842 times according to the cited repository data. That figure includes automated and continuous integration activity, not just individual production deployments. It illustrates the scale of PHP's use, but it does not tell you whether your own pipeline has picked up the corrected image.

The practical lesson is to verify the entire deployment path. Confirm the image or package contains the fix, rebuild or redeploy where required, restart the relevant workers, and check the version actually running your application.

What do the interim settings do, and why are they only temporary?

The PHP security advisory recommends specific configuration changes for the two vulnerabilities.

For CVE-2026-109618, the recommended measures include setting memory_limit=-1 in a way that applications cannot override it, setting a low post_max_size, and enforcing appropriate limits at the web server or proxy layer.

For CVE-2026-109619, the advisory recommends disabling session upload progress with session.upload_progress.enabled=0 and restarting every worker. On PHP 8.5, it also recommends setting fatal_error_backtraces=0.

The advisory warns against treating operating-system limits such as RLIMIT_AS and RLIMIT_DATA as substitutes for these measures because they can cause the vulnerable allocation failure. It also explains that hiding diagnostic messages through error_reporting or the @ operator does not prevent the underlying problem.

Disabling session upload progress blocks the confirmed session-related attack paths, but the advisory explicitly warns that it does not eliminate every possible variant.

Cloudflare's WAF rules provide another layer of temporary protection, but Cloudflare also urges customers to patch their PHP installations. Harness makes the same point in its analysis: a virtual patch is a bridge, just like a WAF rule. Cloudflare further notes that its rule does not cover customers who have changed session.upload_progress.name.

These mitigations can buy time while you prepare a proper update. They should not become a reason to delay patching or assume that every attack path has been closed.

How long should a canary deployment take?

A canary deployment means applying a change to a small number of systems before rolling it out more widely. It allows the team to check that the patch is intact, the application still works, and the change has not introduced unexpected problems.

NIST's patch management guidance explains that even during an emergency, deploying a patch to a small number of canary assets can be beneficial. It notes that the initial testing period could last from a few minutes to a few hours.

For a runtime patch, our recommendation is to test one server or application pod handling real traffic for approximately 15 to 60 minutes, provided the system can be monitored properly and the risk justifies that approach. This is our suggested operating window, not a timeframe specified by NIST.

NIST also recommends planning to replace emergency mitigations with permanent fixes on an enforced schedule. Record an expiry or review time whenever you apply a mitigation, along with the person responsible for removing it.

Without a clear deadline, a temporary workaround can become permanent simply because nobody remembers to revisit it.

How does a bug like this actually work?

Both PHP2Shell vulnerabilities involve what happens when PHP fails to complete a request normally. The PHP advisory explains that PHP uses longjmp() to leave the current execution context when an out-of-memory error occurs. Depending on when that happens, request memory may be only partially initialised when cleanup begins.

The second vulnerability involves a related but different problem: state left behind by a completed request that can affect a later request handled by the same worker.

To understand why this matters, consider how a PHP web server works. A worker might be an Apache child process running mod_php or a member of a PHP-FPM process pool. During its lifetime, that worker can handle many requests, one after another.

For each request, PHP creates and manages internal data structures for input, sessions, errors, objects, and extension state. When the request finishes, PHP normally cleans up that request's resources before the worker handles another one.

This design makes request handling efficient, but it also creates a security requirement: memory and state from one request must not be used incorrectly during another. If a failure interrupts cleanup or leaves stale state behind, a later operation may encounter data in an unexpected condition.

CVE-2026-109618 is a one-request problem. According to the advisory, PHP uses longjmp() to abandon the current work when it runs out of memory. If the request was only partially initialised, the shutdown process may encounter invalid state. Harness describes a scenario in which an attacker sends an oversized upload that causes PHP to run out of memory before request setup is complete. The reported impact is unauthenticated remote code execution under the web worker's account, demonstrated against mod_php with default settings.

CVE-2026-109619 involves two requests handled by the same surviving worker. The advisory explains that state associated with a previous request, including error, session, object, or extension state, may remain even after the memory it refers to has been freed. Some input, configuration, session, and error-handling operations can occur before normal initialisation of the next request.

Fatal errors, including out-of-memory conditions and execution timeouts, are among the ways stale state can be left behind. Security researcher Daniele Berardinelli summarises the issue by explaining that exploitation requires two requests to reach the same surviving worker.

Why login screens and application code do not protect you

The critical issue is that the vulnerable processing can happen before your application's code runs.

The PHP advisory identifies mod_php as the highest-risk configuration and describes a demonstrated exploit in which an unauthenticated request can trigger the vulnerability before application code executes. Wiz likewise explains that exploitation does not depend on a flaw in the application itself.

That means an application login screen, strong user passwords, a patched plugin, or a framework maintenance page may not protect the vulnerable PHP runtime. These controls operate at different layers and may never get the opportunity to intervene.

The appropriate response is to fix or mitigate the runtime itself, rather than assuming that application-level security controls will prevent exploitation.

Why turning off the PHP memory limit is a mitigation, and a hard cap is not

At first glance, PHP's recommendation to set memory_limit=-1 seems counterintuitive. The PHP manual lists the default memory_limit as 128 MB and post_max_size as 8 MB, and explains that -1 means no PHP-level memory limit.

It makes sense because the trigger an attacker controls is PHP's own memory limit: a crafted request can run into it. Removing that particular limit takes away one way of triggering the failure. The advisory still warns that an underlying allocation failure can reach the vulnerable code path, so this setting does not make the installation safe by itself.

Operating-system limits such as RLIMIT_AS and RLIMIT_DATA are not equivalent substitutes. They can cause allocation failures at a different point, potentially recreating the conditions that expose the vulnerability.

This does not mean that unlimited memory use is generally safe. Removing PHP's memory limit can create resource-exhaustion risks, as Sliplane's guide notes, so follow the advisory's exact instructions, enforce suitable controls at the web server or proxy layer, and monitor resource use. The setting should be treated as a specific interim measure, not a general-purpose security recommendation.

The session upload progress setting follows a similar principle. The PHP manual lists session.upload_progress.enabled as enabled by default. The advisory recommends disabling it because the feature is involved in a confirmed attack path. Wiz also reports that the upload-progress issue can be relevant even when the application does not explicitly call session_start().

The key point is that a feature can create risk through the runtime's own request processing, even when your application does not deliberately use that feature.

Why public exploits fail, and why that is no comfort

A vulnerability does not automatically translate into a reliable exploit that works on every installation.

Berardinelli's analysis describes several conditions that can make exploitation difficult. The attacker needs an allocation failure to occur at the right point, useful memory state to remain accessible, and the requests to reach the same worker where required. Request handling can differ between frontends, and the exploit must account for the target's PHP build and memory layout.

Address randomisation can add another obstacle. Depending on the exploit technique, an attacker may need a useful memory address, an information-disclosure method, or another way to overcome uncertainty about the process's memory layout. The final exploitation stage may also depend on the target platform and compatible memory objects.

These constraints help explain why a proof of concept might fail on one server but work on another. They do not make the vulnerability harmless.

Attackers do not need a universal exploit that works everywhere. They need working techniques for enough common configurations to make their efforts worthwhile. Once they develop and test a reliable technique for a particular build, they can potentially reuse it against other systems with similar characteristics.

For defenders, exploit unreliability is therefore not a mitigation, as Berardinelli concludes. Patch the software, reduce exposure while patching, and investigate suspicious activity rather than relying on a public exploit's limitations.

The vulnerability class has a name

OWASP's 2025 Top 10 includes A10, Mishandling of Exceptional Conditions. This category covers situations in which software fails to prevent, detect, or respond correctly to unusual or unpredictable events, potentially causing crashes, unexpected behaviour, or security vulnerabilities.

Both PHP advisories list CWE-755, which concerns improper handling of exceptional conditions.

The lesson extends beyond PHP. Developers often concentrate testing on the normal path: valid input, successful requests, and expected outcomes. But the code that handles failures, such as memory exhaustion, timeouts, and incomplete initialisation, also needs careful testing. If an attacker can deliberately trigger an exceptional condition, a failure-handling path can become an attack surface.

The PHP Foundation has described the wider challenge facing the project's security process. The PHP source repository, php/php-src, has 41,653 GitHub stars and 2,251 open issues, while the Foundation reported publishing 15 CVEs since 1 July and working through more than 100 invalid, duplicate, or non-reproducible reports.

That context helps explain the pressure on maintainers who must investigate reports, validate vulnerabilities, develop fixes, and coordinate security releases. It also reinforces why organisations should maintain their own inventory and response process rather than depending entirely on maintainers to make every part of the response easy.

The practical takeaway is that a small team needs both a reliable patching process and an understanding of how software behaves when things go wrong. The first reduces the immediate risk; the second helps teams build systems that are more resilient to the next vulnerability.

Why do security embargoes break, and how does that affect your response time?

Security embargoes give software developers time to prepare fixes before vulnerability details become public. However, these windows are deliberately short. The linux-distros mailing list allows embargoes of up to 14 days and recommends periods shorter than seven days. Teams should therefore expect limited time between learning about a vulnerability and getting a fix. In the PHP2Shell incident, the embargo broke two days before the targeted release date, by the PHP Foundation's account.

The PHP Foundation says coordinated disclosure worked well until two days before the planned release. After that, accounts of the events differ. The Foundation says the CVE identifiers circulated with an incorrect release time and severity score, a researcher accidentally published a proof-of-concept video, and Chainguard released fixed images more than six hours before the agreed time.

OfficeChai describes Chainguard's early publication as a breach of the coordinated embargo. However, the account available here does not include Chainguard's response. Infosecurity Magazine also reports that a Hacker News user posted the vulnerability identifiers on 20 October. A later “Tell HN” post, published on 22 October, describes an unintentional embargo breach, but the available information does not establish whether the same person made both posts.

The exact sequence of disclosures, who published first, and which event had the greatest impact remain disputed. For engineering teams, the important point is that an embargo can break shortly before a planned release, leaving little time to prepare.

Wiz says it reported the PHP vulnerabilities on 24 August, approximately 58 days before public disclosure by our calculation. This suggests the embargo held for most of the disclosure process before breaking in its final days.

The PHP Foundation has also reported receiving more security reports as AI-assisted research becomes more common. It emphasises that people still assess reports and work on patches. Meanwhile, Verizon's 2026 Data Breach Investigations Report identifies vulnerability exploitation as the starting point in 31% of breaches, ahead of stolen passwords. WatchTowr's analysis of the report puts the median time organisations take to remediate a known-exploited vulnerability at 43 days. That figure comes from WatchTowr's analysis, not directly from Verizon's report.

For a small team, the lesson is straightforward: do not rely on advance warning to prepare for an emergency patch. In the PHP2Shell case, the pre-announcement gave teams less than a day before the release. That warning was most useful to organisations that already knew where PHP was running.

Your first four hours should be possible without relying on news reports, vendor reminders, or someone else identifying your affected systems.

How do you make the next 48 hours shorter?

Assign an owner to every runtime, maintain an up-to-date inventory, establish a clear policy for container tags and updates, and rehearse a runtime patch every quarter. The biggest time-saver is a deployment process your team has already tested, not simply a better scanner.

Keep the inventory up to date

NIST's patch management guidance warns that monthly or quarterly inventories based on vulnerability scans are no longer sufficient. It recommends automated asset discovery and continuous collection of software information. Vendors may also provide a software bill of materials (SBOM).

CISA defines an SBOM as an inventory of the components that make up a software product. For a small team, this means generating an SBOM for each container build and storing it alongside the corresponding image. When a vulnerability is announced, the team should be able to search its inventory to find every place PHP runs instead of manually checking servers and repositories.

Assign an owner to every runtime

Every inventory entry should identify the person responsible for keeping that runtime secure. Someone must own the base image, someone must manage the hosting environment, and someone must follow up with vendors when a fix is unavailable.

This is where the bus factor becomes important. If only one person knows how to deploy an update and that person is unavailable, a response can stall. The same applies to who reviews an urgent change. Decide in advance whether an emergency runtime update needs one reviewer or two, and document the process so nobody has to negotiate it during an incident.

Set a clear container tag and update policy

A pinned container tag gives you control over when the image changes, but you must deliberately update it when a security fix becomes available. A floating tag can pick up a newer image during a rebuild, but the image may change without a separate decision to update that version.

Neither approach is automatically wrong. The risk comes from having no clear policy.

GitHub Dependabot applies a default three-day cooldown to version updates, but its documentation says this cooldown does not apply to security updates. Check how your runtime updates are classified and ensure your cooldown settings match your patching policy. Routine updates and urgent security fixes should not necessarily follow the same schedule.

Measure how long patching really takes

DORA defines change lead time as the time between a code commit and its deployment to production. It also tracks how long teams take to recover from deployments that require immediate intervention.

You do not need a sophisticated dashboard to apply this thinking to security updates. Record when your team decides to patch, when the update reaches production, and when you verify that the fix is active.

This gives you a real measurement of your response time instead of an estimate based on how quickly you think the team could act.

Track software support deadlines

A runtime's support status determines whether you can obtain a fix from its maintainers. According to PHP's supported-versions page, each branch gets two years of active support, followed by two additional years of critical security support only.

According to the cited endoflife.date data, PHP 8.2 security support ends on 31 December 2026. PHP 8.1 reached the end of security support on 31 December 2025, PHP 8.0 on 26 November 2023, and PHP 7.4 on 28 November 2022.

The cited WordPress.org statistics show that PHP 7.4 accounts for 15.2% of reporting WordPress sites, PHP 8.1 for 9.7%, and PHP 8.2 for 23.3%. These figures illustrate how many sites may still rely on older runtimes. Whether a particular installation can receive a fix depends on its operating system, hosting provider, and package.

If your environment uses an older branch, you may need a vendor backport or a planned runtime upgrade. Identify these dependencies before the next critical vulnerability appears, rather than discovering during an incident that your version has no fix planned.

Rehearse the patching process

NIST warns that delaying routine patching makes emergency updates more difficult, time-consuming, and disruptive because earlier patches may need to be installed first.

A quarterly rehearsal can help avoid this problem. Choose a non-critical service, update its runtime to the latest patch release through your normal deployment pipeline, and record how long the process takes. Repeat the exercise with another service a couple of weeks later.

After two rehearsals, you should have a clearer understanding of how long an update takes, which approvals slow it down, and where deployment problems are likely to occur.

Also maintain a short inventory of the external components your builds trust, including packages and registries. Lessons from package registry attacks apply here: a secure deployment process depends not only on how quickly you patch, but also on knowing which components and sources your software relies on.

The goal is to make the next emergency predictable. When a vulnerability is announced, your team should already know which systems are affected, who owns them, how to deploy a fix, and how to verify that it worked.

Where RocketDevs fits

The steps in this guide are straightforward to describe, but they are easy to postpone. Maintaining a software inventory, assigning an owner to every runtime, setting a container update policy, and rehearsing emergency patches do not deliver a visible new feature. On a small team, these tasks compete with customer requests, product deadlines, bug fixes, and the next release. Without clear ownership, they can remain unfinished until a critical security advisory turns them into an urgent problem.

Ask candidates practical questions about their previous work. Where did PHP run in their last production environment? How did the team track runtime versions across servers, containers, and managed hosting? How did they learn about the last critical vulnerability affecting their stack? What did they do while waiting for a permanent fix? How long did the last runtime patch take from the decision to deploy through to verification in production? Ask them to explain the checks they performed, the problems they encountered, and how they confirmed the application was safe to return to normal operation.

RocketDevs can help businesses find developers with the technical skills to support this work without having to manage the entire recruitment process themselves. Each developer completes 6-8 hours of technical assessment, and RocketDevs accepts the top 2% of applicants. That screening provides an additional basis for evaluating technical ability, although the final interview should still establish whether a candidate has the specific production experience and security discipline your environment requires.

Rates start at $9.99/hr for Associate engineers, with higher rates for more experienced developers. RocketDevs also offers a 14-day risk-free trial, money back and 100% honoured, giving businesses an opportunity to assess whether a developer is a good fit for the role.

If your team uses PHP and needs additional engineering capacity to maintain its runtime inventory and patching process without slowing product delivery, start with a pre-vetted PHP developer from RocketDevs. If you need broader engineering support, you can also build a vetted development team with RocketDevs.

The objective is not simply to add another developer. It is to give essential maintenance work a clear owner, a repeatable process, and enough capacity to happen before the next security emergency.

Conclusion: make the first 48 hours count before they begin

A critical vulnerability does not wait for your team to finish its sprint, update its documentation, or work out who owns the affected server. When PHP2Shell broke its planned disclosure window, the teams best placed to respond were the ones that already knew where PHP ran, who was responsible for it, and how to deploy and verify a fix.

That is the difference between having a security policy and being ready to act. Keep your runtime inventory current, assign an owner to every environment, define how updates reach production, and rehearse the process before an emergency forces you to use it. Patch as soon as you safely can, treat mitigations as temporary, and verify the running system rather than assuming a successful deployment means the vulnerability is gone.

You cannot control when the next vulnerability is discovered, whether an embargo holds, or how quickly a vendor releases a fix. You can control how much time your team wastes finding affected systems, negotiating responsibilities, and figuring out a deployment process under pressure.

The first 48 hours are won before the advisory arrives. Build the process now, test it while the stakes are low, and make sure someone has the time and skills to carry it through when the stakes are high. When the next critical flaw appears, your team should be executing a known plan, not building one in the middle of the incident.

Frequently asked questions

How quickly should I patch a critical vulnerability?

The UK's Cyber Essentials scheme requires critical and high-risk updates within 14 days of release. However, for a critical vulnerability affecting an internet-facing system, such as PHP2Shell, 14 days is not an appropriate response target. Aim to patch exposed systems on the same working day where possible, then address other affected systems within the same week. If your team cannot meet those targets, identify what is slowing the process down and improve it before the next security advisory arrives.

Do I still need to patch PHP if my website is behind Cloudflare or another web application firewall (WAF)?

Yes. Cloudflare advises customers to patch PHP even when its WAF protections are enabled. A WAF can block known attack patterns, but attackers may change their payloads or find ways around the rules. Treat the WAF as an additional layer of protection while you deploy the permanent fix. Keep the relevant protections enabled, patch the affected runtime, and verify that the corrected version is running.

What should I do if I run PHP 8.1 or an older version?

PHP 8.1 and older branches no longer receive updates directly from the PHP project. You will need a security backport from your operating-system vendor or hosting provider, or you will need to upgrade to a supported version. For this release, the PHP project also published minimal source backports for PHP 7.4, 8.0, and 8.1 for teams building from source. Some distributions and hosting panels have provided their own fixes. Check the advisory for your exact build. If no suitable fix is available and you cannot adequately mitigate the risk, follow the applicable security guidance, including taking the affected system offline if necessary.

How can I tell whether my PHP server has been compromised?

Look for suspicious activity rather than relying on one definitive test. Check for unexpected child processes launched by PHP workers, unfamiliar files in directories writable by the web server, and unusual bursts of HTTP 500 responses or memory-related errors before the patch was applied. Review web server and application logs for suspicious requests, and investigate any unexpected changes to the system. Search back to 17 October, the earliest attempt Amazon has reported. If you find evidence of a compromise, preserve logs and other evidence before cleaning up, isolate the affected system where appropriate, and rotate any credentials or secrets the server could access. Patching closes the vulnerability but does not remove changes an attacker may already have made.

Does a CVSS score of 9 or higher automatically mean a vulnerability is an emergency?

Not by itself. CVSS measures the severity of a vulnerability, but FIRST advises against using the base score alone to determine risk. For PHP2Shell, different assessors assigned scores of 9.2, 9.8, and 8.1, reflecting differences in their scoring approaches and assumptions. Use the score as an important warning, then assess whether your system is internet-facing, whether credible exploitation reports exist, how much damage a successful attack could cause, and whether a fix is available for your specific build. A lower score does not automatically make an exposed system safe.

James Hitch, COO at RocketDevs.LinkedIn

Sources

• PHP project, Security advisory and Upcoming Critical PHP Security Release, php.net news, 20 and 21 October 2026
• GitHub, GHSA-w8hw-w9fx-j79w, CVE-2026-109618, 21 October 2026
• GitHub, GHSA-6wmf-4rv5-p3rp, CVE-2026-109619, 21 October 2026
• GitHub API, php-8.2.35 release, read 25 October 2026
• GitHub API, php/php-src, read 25 October 2026
• GitHub API, anchore/syft, read 25 October 2026
• NIST, National Vulnerability Database record for CVE-2026-109618, read 25 October 2026
• FIRST, EPSS API, CVE-2026-109618 and CVE-2026-109619, 24 October 2026
• FIRST, EPSS API, CVE-2024-4577 and CVE-2019-11043, 24 October 2026
• CISA, Known Exploited Vulnerabilities catalog JSON, versions 2026.10.23 and 2026.10.27, read 28 October 2026
• CISA, Critical Vulnerabilities in PHP Require Immediate Patching, revised 26 October 2026
• CISA, BOD 26-04 implementation guidance, 2026
• CISA, Software Bill of Materials
• UK NCSC, Critical security issue affecting PHP, 21 October 2026
• European Commission, ENISA, CERT-EU, Europol EC3 and the EU CSIRTs network, Joint statement on critical PHP vulnerabilities, 21 October 2026
• UK NCSC and IASME, Cyber Essentials: Requirements for IT Infrastructure v3.3, April 2026
• NIST, SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning, April 2022
• FIRST, CVSS v4.0 User Guide
• Jacobs, Romanosky, Suciu, Edwards and Sarabi, Enhancing Vulnerability Prioritization, arXiv 2302.14172, 2023
• Red Hat, CVE-2026-109618, read 25 October 2026
• Ubuntu Security, CVE-2026-109618, read 25 October 2026
• Debian Security Tracker, CVE-2026-109618, read 25 October 2026
• CJ Moses, AWS Security Blog, Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot, 21 October 2026
• Amazon Linux Security Center, CVE-2026-109618, read 25 October 2026
• The PHP Foundation, Today's PHP security release, and how we're strengthening PHP security, 21 October 2026
• OfficeChai, PHP rushes out emergency patch for two critical flaws after vulnerability details leak online, 21 October 2026
• Kevin Poireault, Infosecurity Magazine, Critical PHP vulnerabilities leaked ahead of scheduled security patches, 21 October 2026
• Hacker News, pre-announcement submission, PHP 8.2.35 thread, Tell HN post, read 25 October 2026
• Wiz Research, PHP2Shell, 21 October 2026
• Cloudflare, Cloudflare deploys protections against php2shell vulnerability, 21 October 2026, updated 23 October
• Sergiu Gatlan, BleepingComputer, PHP ships emergency patches for critical PHP2Shell flaws, 21 October 2026
• Datadog Security Labs, PHP2Shell: critical vulnerabilities in PHP, 21 October 2026
• Soujanya Namburi, Harness, PHP2Shell: the flaw hiding all across the web, 21 October 2026
• Johannes Ullrich, SANS Internet Storm Center, PHP Vulnerability Wrap-Up, 23 October 2026
• TryHackMe, PHP2Shell update, 21 October 2026
• Elias Taylor, There isn't an easy exploit for this PHP vulnerability, 21 October 2026
• Daniele Berardinelli, PHP2Shell, 22 October 2026
• Flavio Copes, PSA: update PHP today, 21 October 2026
• Natalia Nowak, Webhosting Today, Two critical PHP flaws leaked ahead of the October 21 security release, 21 October 2026
• Coolify, PHP Security Advisory 2026 (PHP2Shell), 21 October 2026
• Lukas Mauser, Sliplane, PHP2Shell: critical PHP vulnerability and what you need to do, October 2026
• Jacob Cooper, Railway, Security disclosure, Wednesday October 21st, 21 October 2026
• WordPress.org, Update PHP and PHP version statistics, read 25 October 2026
• W3Techs, Usage statistics of PHP, 25 October 2026
• Wikimedia, pageviews for the English Wikipedia article PHP, October 2026
• PHP manual, php_sapi_name, core php.ini directives and session configuration, read 25 October 2026
• PHP, Supported versions and endoflife.date PHP record, read 25 October 2026
• Docker Hub, library/php repository, read 25 October 2026
• OWASP, Top 10:2025, A10 Mishandling of Exceptional Conditions, 2025
• Verizon, 2026 Data Breach Investigations Report, and watchTowr, Verizon DBIR 2026: vulnerability exploitation
• Cyber Safety Review Board, Review of the December 2021 Log4j Event, 11 July 2022
• US Government Accountability Office, GAO-18-559, Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach, 30 August 2018
• Google Project Zero, Vulnerability Disclosure Policy
• Openwall, oss-security distribution contact lists
• DORA, Software delivery performance metrics
• GitHub Docs, About Dependabot version updates