Tell HN: 2x PHP RCE CVEs with CVSS 10.0 Incoming

A reliable source has indicated an announcement is scheduled for 22 October 2026 at 18:00 CEST regarding 2x PHP RCEs with a CVSS score of 10.0.

I have no evidence beyond "source: trust me, bro", but if you're running PHP in production, be ready to update as a priority.

These CVEs reportedly relate to remote code execution in all affected PHP versions from PHP 5 onwards.

These are the two reserved CVEs for the reported upcoming announcement:

CVE-2026-109618

CVE-2026-109619

238 points | by petecooper 21 hours ago

20 comments

  • lol768 11 hours ago
    There comes at point at which it is better for everyone to just disclose the details and pursue Full Disclosure. I think we reached that point hours ago.

    It has been incredibly frustrating watching Twitter and that (potentially, I don't know how reliable the leaks are) being a better information source than anything else, at least so that those of us hosting stuff ourselves can try and explore if there are any defensive measures that can be put in place in lieu of any actual fixed builds being released.

    I suspect this is already being actively exploited now.

    https://x.com/J4ck3LSyN/status/2112703096443097263

    They've now posted a proof of concept as well.

    [-]
    • jwitthuhn 11 hours ago
      Seems like some of the people engaging in "responsible disclosure" were not very responsible and it leaked out.

      With that info public they do really need to just release the fix, assuming that tweet is accurate.

      edit: Mitigation for impacted versions is to set `session.upload_progress.enabled = Off` in php.ini

      [-]
      • lol768 10 hours ago
        > edit: Mitigation for impacted versions is to set `session.upload_progress.enabled = Off` in php.ini

        I think this is only partial mitigation: https://x.com/Dinosn/status/2112717168349712734

        I have additionally followed the advice to just ban multipart uploads before the request even touches PHP (luckily my app doesn't use them at all). I do now know if this conclusively resolves it.

      • Webfiletools_de 10 hours ago
        One gotcha for anyone applying this tonight: on a lot of Debian/Ubuntu-style setups the CLI and PHP-FPM read different php.ini files (for example /etc/php/8.x/cli/ vs /etc/php/8.x/fpm/), so "php -i" from a shell can show it Off while the web side still has it On. Check it through a phpinfo() page or the FPM binary itself, and remember to reload php-fpm afterwards. On shared hosting where you can't touch the main ini, it should be settable per directory in .user.ini, but that file is cached for a few minutes by default, so give it time before testing. And as others said, treat it as a stopgap until the actual patch lands.
  • Jotalea 7 minutes ago
    well, until the patch drops I'm pretty much vulnerable.

    I went and disabled my websites that run on PHP, and I will most likely migrate it to a VPS. maybe even another language like golang.

  • Amsozzer 2 hours ago
    Hey guys,

    I have a long day tomorrow auditing all our php websites and so I wrote a simple CLI tool that finds every place php version is mentioned in a repo eg (Dockerfile tags, compose/k8s images, setup-php in CI, .tool-versions, distro php packages, composer) and flags the end of life branches now.

    Floating tags and distro packages can't be labelled deterministically since the tool only reads the files right now so they get labelled "check manually"

    I will also update the package as soon as the fixes drop with the updated versioning which will not require anything on the users end (no updates required)

    Till then check out npx php2shell-repo-audit . https://github.com/Amsozzer1/php2shell-repo-audit

  • vincent_s 6 hours ago
    Two things you can do now:

    1. Turn off session upload progress

    2. Block multipart requests at the web server

    More info: https://www.vincentschmalbach.com/cve-2026-109618-and-cve-20...

    [-]
    • Svip 3 hours ago
      Or:

      3. Disable PHP entirely on your server, and live with broken sites until the patch arrives.

      That's what I did; I can live with my sites being down until it's possible to patch PHP. Though, there are likely others who cannot. The CERT-EU advisory is basically advising the same thing[1].

      [1] https://cert.europa.eu/publications/security-advisories/2026...

  • phab 12 hours ago
    Tweet allegedly showing exploit at work:

    https://x.com/k_firsov/status/2112641845926989944

    (video). Yikes

    [-]
  • lioeters 11 hours ago
    This vulnerability has already been reproduced by a third party with LLM assist. And of course they posted the details on Twitter - and someone else posted the link here just now. So the cat's out of the bag.

    That means roughly 70% of all websites (WordPress, Laravel, Drupal, Joomla, Magento) are currently open to remote code execution. About half of that is running an older PHP 5 and 7 that apparently will not receive the urgent security patch.

    > Two heap use-after-free primitives in PHP's `session.upload_progress` handler

    Guess it's time to rewrite PHP in Rust. Claude, make no mistakes, you can do it!

  • potaytopotahto 11 hours ago
    Looks like details about the exploits have already leaked on twitter, if the info is correct then it can be mitigated by setting session.upload_progress.enabled = Off until you get the opportunity to update
    [-]
  • reddalo 15 hours ago
    Official statement released by PHP: https://www.php.net/archive/2026.php#2026-10-20-1

    Statement by CERT-EU: https://cert.europa.eu/publications/security-advisories/2026... :

    >Where immediate patching is not feasible, organisations should consider isolating internet-facing applications from public networks until a fix is available.

    It seems serious. Well, good luck isolating all PHP applications from the public internet...

  • unreal37 14 hours ago
    This was supposed to be embargoed.

    So your reliable source can't keep a secret.

    [-]
    • JonKF 2 hours ago
      Responsible disclosure is broken in 2026. All it takes is a vague implication that a vulnerability exists and there are enough people with enough AI tokens that it will be found quickly.
    • petecooper 6 hours ago
      Yeah, she lied when I asked if it was under responsible disclosure/co-ordinated disclosure -- otherwise I wouldn't have posted it!
  • HotGarbage 15 hours ago
    https://www.php.net/archive/2026.php#2026-10-20-1
  • ShowalkKama 15 hours ago
    Those CVEs refer to vulnerabilities in wordpress plugins (not php) and the vulnerabilities are not RCEs.

    Am I missing something?

    https://nvd.nist.gov/vuln/detail/cve-2026-9618 https://nvd.nist.gov/vuln/detail/cve-2026-9619

    [-]
    • dylanpyle 15 hours ago
      It sounds like the upcoming ones are 2026-109618/109619, not 9618/9619
      [-]
      • ShowalkKama 15 hours ago
        I even double checked, I'm so blind.
  • SchizoDuckie 17 hours ago
    Well great thanks. I need details now. Where, core? Extensions? What config?

    My guess is on some request filtering thing

    [-]
    • reddalo 15 hours ago
      Yes, it's on core. All versions from PHP 5 onwards. Only PHP 8 will be patched.
      [-]
      • joshuat 13 hours ago
        So a few million WordPress sites are just going to be overnight targets.

        Although I guess that's not a dramatic change in the status quo.

      • Yiin 11 hours ago
        surely not only 8, that would be insane
        [-]
        • rpeden 11 hours ago
          Everything before 8.2 is past EOL.
          [-]
          • brazzy 5 hours ago
            This is serious enough that EOL should not matter. Of course, if someone is still running PHP 7 or even older, they're probably not updating anyway.
    • dwm 15 hours ago
      Details are due for disclosure at 1400hrs UTC tomorrow. That timeline may yet change.
  • archon810 12 hours ago
    Here's the alleged demo video. It's called php2shell https://x.com/k_firsov/status/2112641845926989944 and it's scary as hell.
  • kevinday 12 hours ago
    Quick correction to the text above, PHP says the patch/announcement will be available Wednesday, 21 October 2026 at 14:00 UTC.

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

    [-]
    • gnabgib 11 hours ago
      Yes it's now Wednesday, but Thursday was originally correct. Because of this HN post, it's been moved up to tomorrow.
  • kevbo823 8 hours ago
    If you don't do local file include (LFI) esp. from a $_GET or $_POST then to what degree would the site be impacted?
    [-]
  • coderdiaz 9 hours ago
    The full details will be available on 8:00 AM at Mexico City
  • cod3ninja 3 hours ago
    [dead]
  • skandar90 20 hours ago
    [flagged]
  • gumigumi 9 hours ago
    [flagged]