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

SignaalWaarom het ertoe doetWaar te kijken
Fatale memory-limit-fouten direct na multipart-POST’sGeheugenuitputting 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 clientExploits 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-wisselingenMislukte use-after-free-pogingen laten de worker vaak crashen.FPM-log, Apache-foutlog, dmesg / journal
Ongewoon lange of percent-gecodeerde PHPSESSID in antwoordenHet 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-gebruikerKlassiek 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.

shell
# 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 -20

Na 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.

Vang het geheugenlek op bij de proxy

nginx + shell
# Temporary: log Set-Cookie on responses to spot oversized PHPSESSID values.
# This writes session IDs to disk — restrict the file and remove it afterwards.
# In the http {} block:
log_format php2shell '$remote_addr [$time_local] "$request" $status "$sent_http_set_cookie"';
# In the server {} block:
access_log /var/log/nginx/php2shell.log php2shell;

# Then, from a shell, look for long or percent-encoded session cookies
grep -E 'PHPSESSID=[^;"]{64,}|PHPSESSID=[^;"]*%' /var/log/nginx/php2shell.log

Zoek naar sporen na een inbraak

shell
# 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.

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

  1. Bewaar eerst bewijs: kopieer logs en maak zo mogelijk een schijf- / geheugensnapshot voordat je opnieuw opbouwt.
  2. Patch of isoleer de host. Opnieuw opbouwen vanuit een schoon image is beter dan ter plekke opschonen.
  3. 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.
  4. Maak sessies ongeldig zodat gestolen cookies niet meer werken, en laat beheerders opnieuw inloggen.
  5. Bepaal de schade: waar die inloggegevens nog meer toegang toe geven (cloudaccounts, interne API’s, andere databases).