Skip to content
arrow-alt-circle-up icon

Cyber Incident?

arrow-alt-circle-up icon

Call 00800 1744 0000

arrow-alt-circle-up icon

See all Threat Responses

Dutch follows English

We want to update you on our latest threat response regarding the critical PHP RCE vulnerabilities dubbed ‘PHP2Shell’. PHP has released updates for PHP versions 8.2, 8.3, 8.4 and 8.5 [1]. Source-backports have been made available for PHP 7.4, 8.0 and 8.1 which can be used to build from source if updating is not possible yet. Please update your systems with this latest release before making PHP available to the internet again.
 
Details
 
PHP has made patches available and provided more information regarding the vulnerability [1].
  • Update PHP immediately to a fixed version: 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Apply vendor-provided security updates where available.
  • Verify patch availability with your operating system or LTS vendor. Most major Linux distributions received the fixes before public disclosure and should provide updated packages.
  • PHP 8.1 and older are end-of-life (EOL) and no longer receive official security updates. If you are running these versions, upgrade to a supported release as a priority. Some vendors may provide backported fixes for supported LTS distributions.
  • Organisations relying on community-maintained repositories should migrate to vendor-supported packages or build directly from source to ensure timely access to security updates.
  • For environments that cannot immediately upgrade, the PHP security team has made limited source-level backports available for PHP 7.4, 8.0 and 8.1. These should be considered a temporary mitigation and not a long-term solution.
Together with the patches, more information regarding the vulnerability became available regarding the research from Calif [2] and Wiz [3]. With this new information we are updating our detections for MDR customers where possible.
When patching, take into account updating appliances which may be running PHP and are open to the internet.
 
Mitigations
Together with the vulnerability details, partial mitigations have been shared. For both CVEs there are no complete mitigations available, the only full mitigation is by upgrading to the latest patch.
RCE via OOM corruption (CVE-2026-109618) [4]:
  • Set memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
  • Set a low post_max_size. For applications that don't require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.
  • Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.
RCE via stale global state (CVE-2026-109619) [5]:
  • Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.
  • On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
  • Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help.
  • Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing and cleanup.
What will Northwave do?
We will monitor any developments regarding this vulnerability. If new critical information about this threat arises we will reach out to you. You can call us by phone or send us an email if you would like additional information.
E-mail: soc@northwave-cybersecurity.com
Do you have an incident right now? Call our Incident Response Team: 00800 1744 0000

Disclaimer applies, see below.

Sources

 

Wij willen u informeren over onze laatste respons op de kritieke PHP RCE-kwetsbaarheden die bekendstaan als ‘PHP2Shell’. PHP heeft updates uitgebracht voor de PHP-versies 8.2, 8.3, 8.4 en 8.5 [1]. Daarnaast zijn source-backports beschikbaar gesteld voor PHP 7.4, 8.0 en 8.1, waarmee systemen vanuit de broncode kunnen worden bijgewerkt indien een reguliere update nog niet mogelijk is. Wij adviseren om uw systemen zo snel mogelijk bij te werken naar deze nieuwste release voordat PHP opnieuw rechtstreeks vanaf het internet toegankelijk wordt gemaakt.
 
Details
PHP heeft patches beschikbaar gesteld en aanvullende informatie gepubliceerd over de kwetsbaarheid [1].
  • Werk PHP direct bij naar een gepatchte versie: 8.5.12, 8.4.27, 8.3.36 of 8.2.35. Pas waar mogelijk de door uw leverancier verstrekte beveiligingsupdates toe.
  • Controleer de beschikbaarheid van patches bij uw besturingssysteem- of LTS-leverancier. De meeste grote Linux-distributies hebben de fixes al vóór publieke bekendmaking ontvangen en zouden bijgewerkte pakketten beschikbaar moeten hebben.
  • PHP 8.1 en ouder zijn end-of-life (EOL) en ontvangen geen officiële beveiligingsupdates meer. Als u deze versies gebruikt, raden wij aan om zo snel mogelijk te upgraden naar een ondersteunde release. Sommige leveranciers bieden mogelijk backported fixes aan voor ondersteunde LTS-distributies.
  • Organisaties die afhankelijk zijn van door de community onderhouden repositories wordt geadviseerd over te stappen op door leveranciers ondersteunde pakketten of rechtstreeks vanuit de broncode te bouwen, zodat beveiligingsupdates tijdig beschikbaar zijn.
  • Voor omgevingen die niet direct kunnen upgraden heeft het PHP-beveiligingsteam beperkte source-level backports beschikbaar gesteld voor PHP 7.4, 8.0 en 8.1. Deze moeten worden beschouwd als een tijdelijke mitigatie en niet als een structurele oplossing.
Naast de patches is meer informatie beschikbaar gekomen over de kwetsbaarheden, gebaseerd op onderzoek van Calif [2] en Wiz [3]. Op basis van deze nieuwe informatie actualiseren wij waar mogelijk onze detecties voor MDR-klanten.
Houd er bij het installeren van patches rekening mee dat je apparaten moet updaten waarop mogelijk PHP draait en die toegang hebben tot het internet.
 
Mitigaties
Samen met de technische details van de kwetsbaarheden zijn gedeeltelijke mitigaties gepubliceerd. Voor beide CVE's geldt dat er geen volledige mitigatie beschikbaar is; het volledig verhelpen van het risico vereist een upgrade naar de meest recente gepatchte versie.
 
RCE via OOM-corruptie (CVE-2026-109618) [4]
  • Stel memory_limit=-1 in, bij voorkeur op een manier waarop applicaties deze instelling niet kunnen overschrijven, bijvoorbeeld via php_admin_value in de FPM-pool- of Apache-configuratie. Controleer tevens dat geen pool-, directory- of applicatie-instellingen opnieuw een limiet instellen. Hiermee wordt de door PHP beheersbare geheugenlimietfout voorkomen, maar onderliggende allocatiefouten kunnen nog steeds het kwetsbare codepad bereiken.
  • Stel een lage waarde in voor post_max_size. Voor applicaties die geen bestandsuploads vereisen, wordt post_max_size = 8M aanbevolen. Indien uploads noodzakelijk zijn, stel post_max_size = 32M in. Zorg ervoor dat upload_max_filesize lager ligt dan post_max_size. Overweeg daarnaast limieten af te dwingen op webserver- of proxyniveau voor de gedecodeerde requestgrootte, het aantal invoervelden, multipart-secties, headers en nestingsdiepte. Deze limieten moeten ook gelden voor verzoeken zonder bruikbare Content-Length.
  • Gebruik container- of cgroup-limieten als beschikbaarheidsgrens, bij voorkeur met een beleid dat uitsluitend de getroffen worker beëindigt. Gebruik geen RLIMIT_AS of RLIMIT_DATA als alternatief, omdat deze juist de kwetsbare allocatiefout kunnen veroorzaken.
  • RCE via verouderde globale status (CVE-2026-109619) [5]
  • Stel session.upload_progress.enabled=0 in en herstart alle workers. Gebruik hiervoor php.ini, een FPM-poolconfiguratie of een serverconfiguratie die vóór requestverwerking wordt toegepast. Vertrouw niet op ini_set() of FPM .user.ini. Dit blokkeert de bevestigde sessiegerelateerde aanvalspaden, maar niet noodzakelijk alle varianten.
  • Stel op PHP 8.5 fatal_error_backtraces=0 in en herstart alle workers. Dit blokkeert uitsluitend het bevestigde aanvalspad via fatale backtraces.
  • Verwijder ongeldige of verouderde instellingen die per request worden toegepast en vóór initialisatie diagnostische meldingen genereren. Het onderdrukken van meldingen via error_reporting, display_errors of @ biedt geen bescherming.
  • Verhelp fatale fouten en time-outs die door een aanvaller kunnen worden getriggerd, waaronder fouten in callbacks, upload- of importverwerking en opruimprocessen.
Wat doet Northwave?
Wij blijven de ontwikkelingen rondom deze kwetsbaarheid actief monitoren. Mochten er nieuwe kritieke bevindingen of risico's aan het licht komen, dan zullen wij u hierover informeren. Heeft u aanvullende vragen of behoefte aan meer informatie, neem dan gerust telefonisch of per e-mail contact met ons op.
 
 
Disclaimer van toepassing, zie hieronder.


Disclaimer

Northwave has made every effort to make this information accurate and reliable. However, the information provided is without warranty of any kind and its use is at the sole risk of the user. Northwave does not accept any responsibility or liability for the accuracy, content, completeness, legality or reliability of the information provided. We will not be liable for any loss or damage of whatever nature, direct or indirect, consequential or other, whether arising in contract, tort or otherwise, which may arise as a result of your use of, or inability to use, this information or any additional information provided by us in direct or indirect relation to the information provided here.
.