Detectie & respons
Ben ik geraakt?
Geen enkele regel vangt elke variant, en de kwetsbare code draait onder je applicatie, dus applicatielogs kunnen niets laten zien. Gebruik deze signalen om te prioriteren — niet om een systeem vrij te pleiten.
Laatst gecontroleerd 2026-10-22
Geen signalen is geen bewijs van veiligheid
Het geheugenlekpad kan geheimen stelen zonder ooit code op de server uit te voeren. Patch ongeacht wat je vindt.
Signalen die het onderzoeken waard zijn
| Signaal | Waarom het ertoe doet | Waar te kijken |
|---|---|---|
| Fatale memory-limit-fouten direct na multipart-POST’s | Geheugenuitputting is één trigger. CVE-2026-109619 kent ook paden zonder OOM; ontbrekende OOM-fouten sluiten de kwetsbaarheid niet uit. | PHP- / FPM-foutlog + toegangslog van de webserver |
| Pieken van HTTP 500 vanaf één client | Exploits hebben meerdere pogingen nodig om zich aan de geheugenindeling van het doelwit aan te passen. | Toegangslog |
| Workers die sterven op SIGSEGV / SIGABRT, of ongewoon veel worker-wisselingen | Mislukte use-after-free-pogingen laten de worker vaak crashen. | FPM-log, Apache-foutlog, dmesg / journal |
| Ongewoon lange of percent-gecodeerde PHPSESSID in antwoorden | Het geheugenlekpad URL-codeert gelekt heap-geheugen in de sessiecookie — zelfs op sites die nooit session_start() aanroepen. | Logs van reverse proxy / CDN / WAF met Set-Cookie (niet in standaard toegangslogs) |
| Nieuwe .php-bestanden in de webroot, onverwachte childprocessen van de PHP-gebruiker | Klassiek gedrag na een inbraak: webshells, curl/wget, reverse shells vanaf www-data. | Bestandssysteem, EDR, procesaccounting |
Een normale PHPSESSID is kort en alfanumeriek (standaard 32 tekens). Honderden tekens of %xx-bytereeksen erin zijn niet normaal.
Doorzoek je logs
De paden zijn de standaard van Debian/Ubuntu. Pas ze aan voor je systeem; bekijk minstens de periode sinds begin oktober 2026.
# 1. Memory-limit fatals (PHP's exact message)
sudo grep -rh "Allowed memory size of" /var/log/php*-fpm.log /var/log/apache2/ /var/log/httpd/ /var/log/nginx/ 2>/dev/null | tail -50
# 2. Workers killed by signals
sudo grep -rhE "exited on signal (6|11)|exit signal (Segmentation fault|Aborted)" \
/var/log/php*-fpm.log /var/log/apache2/ /var/log/httpd/ 2>/dev/null | tail -50
sudo journalctl --since "2026-10-01" | grep -E "php.*segfault" | tail
# 3. Clients producing many 500s on POST (combined log format)
sudo awk '$6=="\"POST" && $9==500 {print $1}' /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null \
| sort | uniq -c | sort -rn | head -20Na het patchen kan de nieuwe harde geheugenlimiet workers ook abrupt beëindigen. Eén worker die stopt is geen bewijs van een aanval — zoek naar clusters bij dezelfde client of hetzelfde requestpatroon.
Zoek naar sporen na een inbraak
# PHP files changed in the web root since the bugs became known (adjust path/date)
sudo find /var/www -type f -name '*.php' -newermt '2026-08-01' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort | tail -100
# Processes the web user is running right now (shells and downloaders are red flags)
ps -u www-data -o pid,ppid,lstart,cmd | grep -vE 'php-fpm|apache2|httpd'
# Established connections owned by PHP / Apache — review every remote address
sudo ss -tpn state established | grep -E 'php|apache|httpd'WAF-dekking
Beheerde regels zijn een noodoplossing terwijl je patcht. Bekijk de PHP2Shell-richtlijnen van je aanbieder. Cloudflare publiceerde zijn regel-ID’s — zie de Cloudflare-pagina.
Detecties van leveranciers
Gebruik je een van deze producten, dan beschrijven hun artikelen de signatures en zoekopdrachten die ze hebben uitgebracht.
- AkamaiCritical RCE vulnerabilities in PHP core
- ImpervaPHP2Shell vulnerability updates
- CorelightPHP2Shell detection
- CrowdStrikeProtecting customers from PHP RCE zero-days
- Unit 42CVE-2026-109618 / CVE-2026-109619
- Cisco TalosTwo critical RCEs in PHP core
- watchTowrPHP RCE FAQ: CVE-2026-109618
- SansecPHP2Shell: critical PHP RCE
Draai geen “PoC”-scripts van GitHub op je servers
Behandel exploit- en scannerrepository’s als onbetrouwbaar. Openbare beschikbaarheid bewijst werking noch veiligheid. Gebruik leverancierscontroles en test onbekende scripts nooit in productie.
Als je iets vindt
- Bewaar eerst bewijs: kopieer logs en maak zo mogelijk een schijf- / geheugensnapshot voordat je opnieuw opbouwt.
- Patch of isoleer de host. Opnieuw opbouwen vanuit een schoon image is beter dan ter plekke opschonen.
- Vervang alles wat PHP in het geheugen kon zien: databasewachtwoorden, API-sleutels, OAuth-client-secrets, SMTP-gegevens, app-sleutels (
APP_KEY, WordPress-salts), TLS-private keys als PHP er toegang toe had. - Maak sessies ongeldig zodat gestolen cookies niet meer werken, en laat beheerders opnieuw inloggen.
- Bepaal de schade: waar die inloggegevens nog meer toegang toe geven (cloudaccounts, interne API’s, andere databases).