mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 10:59:59 +00:00
kevinveenbirkenbachandClaude Opus 5.5
e3d2a24bcd
The interim CVE-2026-109618 mitigation lived in the shared hardening.ini, so every PHP role ran without a memory limit until the last image was patched, and no role's service_memory_mb share applied. Registry metadata of the images pinned on main shows that 16 of the 20 consumers already ship PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or the Alpine/Debian build of it). Four predate the fix: markoshust/magento-php:8.4-fpm (8.4.21), ghcr.io/heviat/webmail:2024.06 (the Mailu OIDC flavor, built 2025-04-04), phpldapadmin/phpldapadmin:2.3.11 (built 2026-05-15) and ghcr.io/shopware/docker-base:8.3 (8.3.25). - Move memory_limit = -1 into its own content-addressed ini (FILE_PHP_MEMORY_UNLIMITED_INI) and mount it only in magento, mailu, phpldapadmin and shopware. - hardening.ini keeps expose_php, session.upload_progress.enabled and fatal_error_backtraces as permanent hardening. - Joomla's php-upload.ini loads as conf.d/uploads.ini again: no -1 has to be outranked anymore. - The root TODO names the four images that still need the override. Refs #1126 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>