niklas‑stephan.de

PHP containers on the homelab and the Oct 2026 PHP RCE update

Last updated 05/11/2026 · php, security, handtrixxx, roundcube, wordpress, matomo

Where PHP runs (checked 2026-10-22, all 4 servers)

Only handtrixxx.com. metis, iris and hestia have no PHP (no host packages, no container). Four containers, all floating image tags, so docker compose pull gets security rebuilds:

Container Project dir (/data/docker/...) Image Server
roundcube webmail.handtrixxx.com roundcube/roundcubemail:1.7.x-apache apache mod_php (no volumes: plugins thunderbird_labels, tls_icon, show_folder_size are composer-installed at start; data in roundcube-db)
matomo-app stats.handtrixxx.com matomo:fpm-alpine php-fpm (nginx matomo-web in front)
frau-eulede-wordpress-1 frau-eule.de wordpress:7-apache mod_php, serves dev.frau-eule.de only (public frau-eule.de is the static nginx fraueule-app, so its wp-login.php is 404 by design)
malchsee-app ac-malchsee.de wordpress:7-apache mod_php (iThemes/Solid Security, wp-login redirects 302)

Incident 2026-10-22: PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (CVE-2026-109618 OOM corruption, CVE-2026-109619 stale global state, unauthenticated RCE, CVSS 9.2; mod_php highest risk)

  • Containers ran 8.4.26 / 8.3.35 since 21 Oct 01:25 UTC (before the 21 Oct 14:00 UTC release). Fixed images were on Docker Hub within hours.
  • Compromise check found nothing: no restarts/OOM/segfaults in 14 days of logs; Matomo and Roundcube trees byte-identical to the pristine /usr/src copy in the image (Roundcube: only plugins, config, composer vendor differ); WordPress core and plugins match the wordpress.org checksum APIs; no webshell patterns, no auto_prepend_file, no PHP in upload dirs, no outbound connections. Only scanner noise (.env, phpinfo.php, traversal probes returning 404/homepage; one IP fuzzing core PHP files directly on malchsee, producing 500s).
  • Updated 2026-10-22 12:27 UTC to 8.4.27 (roundcube, matomo-app) and 8.3.36 (both WordPress), verified with php -v, HTTP checks and Roundcube plugin presence.

Recipe for the next PHP security release

  1. Inventory: for each container docker exec C sh -c 'command -v php php-fpm apache2'; a find / -xdev -name "libphp*" -o -name php-fpm* catches the rest (headscale has no shell: not PHP).
  2. Check Docker Hub last_updated of the tags (https://hub.docker.com/v2/repositories/<repo>/tags/<tag>), then docker compose pull in the project and verify with docker run --rm --entrypoint php IMAGE -v before recreating.
  3. Recreate only the PHP service: docker compose up -d --no-deps <service> (the pull also fetches db/nginx images, which stay on the old ones until recreated).
  4. Verify php -v, HTTP 200, a real PHP path (Matomo matomo.php returns image/gif).
  5. Integrity: compare image /usr/src/<app> vs live tree with md5sum lists; WordPress with https://api.wordpress.org/core/checksums/1.0/?version=V and https://downloads.wordpress.org/plugin-checksums/<plugin>/<version>.json. Gotcha: the advisory’s interim mitigations (memory_limit=-1, post_max_size, session.upload_progress.enabled=0) are not a fix; only the update is.

Source: Wiki.js