Upcoming Critical PHP Security Release

Comments

• COLBYLICIOUS Member

  1:57PM

  @Access2IT said:
  Update is live!

  https://www.php.net/index.php

  The site loads very slow to me, F to their servers.
• hyperblast Member

  2:04PM

  all-inkl.com a big player in germany handles it like this (translated):

  The PHP development team has announced a critical security update for this afternoon (approximately 4:00 p.m. CET) regarding the vulnerabilities CVE-2026-109618 and CVE-2026-109619.
  Based on current information, one of the vulnerabilities affects the upload progress indicator function (upload_progress.enabled), which could potentially allow malicious code to be executed.

  Our protective measure:
  To protect your systems as much as possible right now, we are disabling this function on the server side for all PHP versions as a precaution.
  Apart from the possible absence of a progress indicator during file uploads, you should expect virtually no restrictions on your web applications.

  Note regarding PHP updates:
  We will apply the official patches promptly after their release and then re-enable the feature.

  Older PHP versions (e.g., PHP 5.6, PHP 7.4, PHP 8.0):
  The vendor is not expected to release any further official security updates for these outdated versions. We are already working on an alternative solution to permanently secure these environments without having to disable the upload function.
• SplitIce Member, Host Rep

  2:04PM

  hub.docker.com is failing for me, everyone watching for that container build.
• amarc Veteran

  2:13PM

  lsphp (at least on OLS) still not available as far as I can see..
• JohnFilch123 Member

  2:18PM

  arm64 still not available
• SplitIce Member, Host Rep

  2:19PM

  Wow thats a big patch, hard to audit...

  Also, you arent resolving that with any certainty through a WAF or configuration.

  OOM = RCE
  Fatal Error = RCE

  Very few languages can ever be provably error free, PHP is certainly not one.
• MrRadic Host Rep, Veteran

  2:22PM edited 2:24PM

  For older PHP versions, the WAF rules I previously posted help with a couple scenarios (but will break uploads).

  https://x.com/RadicDavydov/status/2112744227553648737

  Additional mitigations recommended by PHP:

  https://x.com/RadicDavydov/status/2112911895388619072

  I'm not sure if you read the details yet, but this is not easy to reproduce, even with AI.
  https://www.wiz.io/blog/php2shell-php-rce

  Finally, CloudFlare has already pushed out a lot of WAF rules to mitigate it as well.
• rpqu Member

  2:23PM edited 2:23PM

  @angstrom can we make roll call. Seems like there's one-man or smaller hosts that hasn't get the note

  Thanked by 2angstrom mrTom
• ScreenReader Member

  2:30PM

  launchpad ppa is going to get hammered considering with how many people relies on ondrej/php
• JohnFilch123 Member

  2:30PM

  @ScreenReader said: ondrej

  I think he is migrating to sury
• wii747 Member

  2:55PM

  Ubuntu has released a fix

  https://ubuntu.com/security/CVE-2026-109618
  https://ubuntu.com/security/CVE-2026-109619
• Decicus Member

  2:58PM

  @SplitIce said:
  hub.docker.com is failing for me, everyone watching for that container build.

  They only just merged it ~30 minutes ago. At the moment it doesn't look like those new versions are tagged yet on Docker Hub.

  ---

  I haven't tested / confirmed since I don't run EOL versions, but it seems that the Sury.org repo (for Debian/Ubuntu) already has new versions all the way back to PHP 7.0 - at least based on the build dates for these versions.

  Launchpad PPA lagging behind it seems?

  Thanked by 1Murv
• OhJohn Member

  2:58PM

  Have to say ubuntu had been really fast in providing patched versions, also for eol version 8.1.2

  Thanked by 2mrTom tux
• angstrom Moderator, Veteran

  3:04PM

  @rpqu said:
  @angstrom can we make roll call. Seems like there's one-man or smaller hosts that hasn't get the note

  As you saw, I've made an announcement

  Thanked by 3rpqu ScreenReader JohnnySac
• jgoossens Member

  3:18PM

  As promised, an update after PHP's advisories: the session upload-progress handler is one of the confirmed routes, but not the only one. The advisories also describe out-of-memory tricks in the multipart parser, plus some routes no extension can close. Our extension's v3 carries the fixed multipart parser with a memory guard and keeps the upload-progress handler out, which on typical PHP-FPM hosting closes the routes that work before any application code runs. Still a stopgap: update to 8.5.12/8.4.27/8.3.36/8.2.35 (or your vendor's backport) as soon as you can. Thanks to everyone who pushed back today.
• raindog308 Administrator, Veteran

  3:30PM

  @angstrom said: I imagine that third-party vendors will try to patch earlier series ASAP

  cPanel already did:

  
• aj_potc Member

  3:33PM

  Interestingly for those in the Red Hat ecosystem, Red Hat doesn't classify these CVEs as Critical, but Important (score = 8.1). Their descriptions make them sound not quite as scary as I've read elsewhere:

  https://access.redhat.com/security/cve/cve-2026-109618

  Rated Important. An unauthenticated remote attacker could corrupt engine memory and potentially execute arbitrary code, but reliable exploitation requires precise heap manipulation and timing. Standard Red Hat Enterprise Linux deployments use PHP-FPM rather than mod_php. PHP-FPM workers exit on early initialization failures before reaching the corrupted structures, so remote code execution is difficult in practice and typically requires non-default behavior such as parsing a second request body during script execution.

  https://access.redhat.com/security/cve/cve-2026-109619

  An unauthenticated remote attacker can trigger memory corruption leading to potential arbitrary code execution. In typical Red Hat Enterprise Linux deployments, PHP applications exposed to public networks handle incoming requests directly, so no prior authentication is needed to reach the vulnerable code. Exploitation requires hitting a precise out-of-memory condition during request processing, which keeps this below Critical.
• ScreenReader Member

  3:46PM

  @JohnFilch123 said:

  @ScreenReader said: ondrej

  I think he is migrating to sury

  for deb package, sure. the ubuntu ones still stuck in launchpad ppa
  https://deb.sury.org/
• raindog308 Administrator, Veteran

  4:03PM

  @aj_potc said: Interestingly for those in the Red Hat ecosystem, Red Hat doesn't classify these CVEs as Critical, but Important (score = 8.1)

  I'm not a security nerd but is this because RedHat's default configuration isn't as vulnerable?

  PHP on Ubuntu could be a 9.2 but on RedHat it's an 8.1 - is that a thing?

  Thanked by 2mustafamw3 stable_genius
• Zhenmue Member

  4:23PM

  How can Cpanel and DA update their php versiones in less than 20-30 minutes

  and CloudLinux needs at least 5 hours.
• averagedatahoarder Member

  4:26PM

  botnets go brrr
• OhJohn Member

  4:33PM

  We need a new HTTP Error code, code 666: "This server does not run PHP. Look elsewhere instead of bothering us with your stupid automatic exploit poking requests."

  Thanked by 1t0m
• glueckself Member

  4:45PM

  Seems like there is a third one too. Either incomplete fix, or an own vuln. https://fedi.katze.sh/@elise/117479459565085083
• ScreenReader Member

  4:46PM

  @Zhenmue said:
  How can Cpanel and DA update their php versiones in less than 20-30 minutes

  and CloudLinux needs at least 5 hours.

  sire, a new exploit has hit the building https://fedi.katze.sh/@elise/117479383739450605
• aj_potc Member

  4:52PM

  @raindog308 said:

  I'm not a security nerd but is this because RedHat's default configuration isn't as vulnerable?

  PHP on Ubuntu could be a 9.2 but on RedHat it's an 8.1 - is that a thing?

  Both great questions that I can't answer.

  I am assuming Red Hat was given early access to the vulnerability details and had time to come up with their own scores. But I would love to know what, specifically, makes them think their distro is harder to exploit.

  Thanked by 1stable_genius
• rpqu Member

  4:55PM

  @ScreenReader said:

  @Zhenmue said:
  How can Cpanel and DA update their php versiones in less than 20-30 minutes

  and CloudLinux needs at least 5 hours.

  sire, a new exploit has hit the building https://fedi.katze.sh/@elise/117479383739450605

  
• cochon Veteran

  5:02PM

  Glad the Debian sury patches were so quick. Just waiting on Alpine now myself.
• rpqu Member

  5:05PM

  Yup, @forest is definitely won't be out of woodwork at least 5-7 days from now

  Thanked by 1tux
• wii747 Member

  5:07PM edited 5:09PM

  Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages. Then all the other software companies will get the fix at the same time as the general public
• jonathann Member

  5:13PM edited 5:13PM

  @NameCrane please upgrade the PHP versions. DA reports PHP 8.2.34, which is below 8.2.35

  Thanked by 3COLBYLICIOUS tux NBO