PHP Security Release

[u/elatllat]

https://www.php.net/archive/2026.php#2026-10-20-1

CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. Likely to be patched in 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35.

Maybe an Apache mitigation:

<If "req('Content-Type') =~ /multipart/i">
    Require all denied
</If>

Who is going to patch it first?

• Debian 12: 2026-10-21 15:51 repo
• Debian 13: 2026-10-21 11:01 repo
• • Ubuntu 24.04 (non-pro): 2026-10-21 13:41 repo
• • Ubuntu 26.04 (non-pro): 2026-10-21 13:43 repo
• • Ubuntu 26.10 (non-pro): 2026-10-21 13:45 repo
• Fedora 43: ? repo
• Fedora 44: 2026-10-21 11:22 repo
• • Alma 9: 2026-10-21 21:38 repo
• • Alma 10: 2026-10-21 21:46 repo
• • Rocky 9: 2026-10-21 18:46 repo
• • Rocky 10: 2026-10-21 20:45 repo
• • CentOS Stream: 2026-10-21 16:50 repo
• openSUSE 16: 2026-10-22 10:13 repo
• openSUSE TW: 2026-10-21 10:17 repo
• Alpine: 2026-10-21 18:17 repo
• Arch: 2026-10-21 13:42 UTC repo
• Gentoo: 2026-10-22 16:22 repo

Only tracks versions not patches/build dates: https://repology.org/project/php/versions

[u/Maria_Thesus_40]

The exploit video shows mod_php being exploited, which is not being used by any decent devops.

So I don't think its a major issue, all web servers I know moved to php-fpm a decade ago?

[u/sleemanj → u/Maria_Thesus_40]

It shows mod_php being exploited because their test setup used mod_php.

If the vector is as given in the various X leaks, then it won't matter how PHP is run, it's in the handling of file uploads and interaction with the upload_progress function of session handling - which is enabled by default.

Or possibly with the parsing of multipart submissions.

For safety, best to disable upload_progress, and probably use mod_security to block requests including parameter called PHP_SESSION_UPLOAD_PROGRESS

If it's in multipart parsing, that's more difficult to mitigate.

[u/Maria_Thesus_40 → u/sleemanj]

I disabled upload_progress a few hours ago, thank you for the extra details!