Kort gezegd: Een workaround voor het PHP-beveiligingslek PHP2Shell kan het risico verlagen, maar vervangt de update niet. php.net noemt daarvoor vaste geheugen- en uploadgrenzen, het uitschakelen van session upload progress en op PHP 8.5 fatal_error_backtraces=0. Is ook dat op korte termijn niet mogelijk, dan adviseert het BSI de webserver tijdelijk van het netwerk te halen.
Wat een workaround kan bereiken en wat niet
De overbruggingsmaatregelen van php.net moeten de voorwaarden bemoeilijken waaronder de kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 te misbruiken zijn. Ze zijn uitdrukkelijk geen volledige bescherming. Verholpen zijn de kwetsbaarheden alleen in PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 of in een bevestigde backport van uw aanbieder.
Zinvol zijn de maatregelen als de update om een concrete reden nog niet kan: een onderhoudsvenster staat nog open, een toepassing moet eerst worden getest, of u draait PHP 8.1 of ouder, waarvoor er geen officiële update meer is. Ze zijn dan een brug, geen doel.
Plan daarom met de workaround tegelijk de update: wie voert hem uit, in welk onderhoudsvenster, en wie controleert daarna dat alle workers zijn herstart? Een overgang zonder einddatum dreigt een blijvende toestand te worden.
Optie 1: server tijdelijk van het netwerk halen
Het BSI (de Duitse federale dienst voor informatiebeveiliging) heeft waarschuwingsniveau 3 (oranje) afgekondigd en adviseert getroffen webservers tijdelijk van het netwerk te halen als de update niet direct mogelijk is. Sommige aanbieders hebben dat voorzorgshalve gedaan; dat betekent niet dat deze sites zijn gehackt.
Voor veel bedrijven is een uitval van de shop of het portaal duur. Een afweging kan zinvol zijn: toegang alleen nog via VPN of vrijgegeven IP-adressen, een statische onderhoudspagina in plaats van de PHP-toepassing of het uitschakelen van afzonderlijke, niet benodigde websites op de server. Hoe minder PHP van buitenaf bereikbaar is, hoe kleiner het aanvalsoppervlak.
Belangrijk is de beslissing bewust te nemen en vast te leggen: wie heeft wanneer besloten de server online te laten, en met welke beschermingsmaatregelen? Dat helpt later tegenover verzekeraar, gegevensbescherming en directie.
De overbruggingsmaatregelen van php.net
| Maatregel | Waarde | Opmerking |
|---|---|---|
memory_limit |
-1, niet overschrijfbaar |
geheugengrens dan instellen via container of cgroup |
post_max_size |
8M zonder uploads, 32M met uploads |
upload_max_filesize daaronder |
| Geheugengrens | via container/cgroup | niet via RLIMIT_AS of RLIMIT_DATA |
session.upload_progress.enabled |
0 |
in php.ini, pool of serverconfiguratie, niet via ini_set() of .user.ini |
fatal_error_backtraces |
0 |
alleen PHP 8.5 |
De instelling session.upload_progress.enabled=0 is tegelijk de remedie voor de op 23 oktober gemelde kwetsbaarheid CVE-2026-115560.
De workaround voor het PHP-beveiligingslek goed instellen
Beslissend is de plaats. De waarden moeten zo zijn ingesteld dat een toepassing ze niet kan overschrijven. Paden en dienstnamen verschillen per distributie; de voorbeelden gaan uit van PHP 8.3.
PHP-FPM, in de pool (bijv. /etc/php/8.3/fpm/pool.d/www.conf):
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; alleen PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off
Apache met mod_php, in de serverconfiguratie of in de VirtualHost:
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
Geheugengrens via cgroup, hier via systemd voor de FPM-dienst. De waarde past u aan uw server aan:
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
Herstart daarna alle workers, anders werkt niets hiervan: systemctl restart php8.3-fpm of bij mod_php Apache. Hoe u controleert dat er geen oud proces meer draait, staat onder PHP-FPM en alle workers herstarten. Algemene hardening van de configuratie beschrijft php.ini veilig configureren.
Test uploads en grote formulieren na de omschakeling. Een te krappe post_max_size kan bestellingen, sollicitatieformulieren of media-uploads blokkeren. Dat is een reden om de update niet lang uit te stellen.
Extra beschermingslagen
Een Web Application Firewall of virtueel patchen kan als verdere laag helpen. Cloudflare heeft beschermingsregels uitgerold, maar waarschuwt zelf dat regels op basis van alleen de verzoekgegevens niet volstaan. Een WAF is daarom een aanvulling, geen vervanging. Meer daarover onder WAF en virtueel patchen.
Veiligstel bovendien de serverlogs vanaf 20 oktober. Volgens berichten in de media werd al op 17 oktober een eerste aanvalspoging waargenomen; de logs zijn de grondslag als u later moet uitzoeken of er vóór de patch iets is gebeurd.
Hoe helpt PHP SOS concreet?
- Situatie verhelderen: wij controleren of een update op korte termijn mogelijk is of een overgang nodig is, en bespreken met u de optie om delen van het netwerk te halen.
- Maatregelen instellen: wij voeren de waarden van php.net op de juiste plaats in, stellen de cgroup-grens in en herstarten alle workers.
- Functie testen: formulieren, uploads en bestelprocessen controleren we na de omschakeling.
- Naar de patch leiden: via de PHP-patchservice plannen we de update en nemen we de overgangswaarden daarna gecontroleerd terug waar ze storen.
Veelgestelde vragen
Beschermt de workaround volledig tegen PHP2Shell?
Nee. php.net noemt de maatregelen uitdrukkelijk een overgang en geen volledige bescherming. Ze verkleinen het risico tot de update is geïnstalleerd. Het BSI adviseert servers zonder patch tijdelijk van het netwerk te halen.
Kan ik de instellingen via .htaccess of .user.ini instellen?
Voor session.upload_progress.enabled sluit php.net ini_set() en .user.ini uitdrukkelijk uit. Ook voor memory_limit geldt: de waarde moet zo zijn ingesteld dat de toepassing hem niet kan overschrijven. Dat lukt in de php.ini, in de FPM-pool met php_admin_value of in de Apache-serverconfiguratie.
Volstaat een Web Application Firewall als workaround?
Als extra laag kan ze helpen. Cloudflare heeft beschermingsregels uitgerold, maar wijst er zelf op dat regels op basis van alleen de verzoekgegevens niet volstaan. Een WAF vervangt noch de update noch de overbruggingsmaatregelen op de server.
Wat doe ik als ik alleen shared hosting heb?
Dan liggen php.ini en herstart bij de hoster. Vraag concreet of de update is geïnstalleerd of de overbruggingsmaatregelen zijn ingesteld en of alle PHP-processen zijn herstart.