Hi,
while checking my installation for CVE-2026-109618 / CVE-2026-109619 (PHP2Shell) I noticed something that will block the fix for every mailcow user, even after the PHP security release today (21 Oct, 14:00 UTC):
data/Dockerfiles/phpfpm/Dockerfile starts with FROM php:8.2-fpm-alpine3.21
On Docker Hub, the php:8.2-fpm-alpine3.21 tag was last updated on 2025-10-10. The official PHP images only maintain alpine3.23 and alpine3.24 for 8.2 now (both currently 8.2.34).
That is why the current ghcr.io/mailcow/phpfpm:8.2.29-3 still ships PHP 8.2.29, five patch releases behind.
The fixed 8.2 release from today will land in php:8.2-fpm-alpine3.23/3.24, but not in the alpine3.21 base, so a rebuild of the current Dockerfile will not pick it up.
Suggestion: bump the base to php:8.2-fpm-alpine3.24 (or alpine3.23) and publish a new phpfpm image once the fixed PHP release is out.
Until then, what I did as a mitigation (no mailcow files changed, only docker-compose.override.yml):
with zz-upload-progress-off.ini containing:
The publicly described attack path uses multipart uploads with PHP_SESSION_UPLOAD_PROGRESS, and mailcow does not need that feature. If you run CrowdSec AppSec in front of mailcow, the virtual patch crowdsecurity/vpatch-CVE-2026-109618 blocks the same pattern.
Thanks!
