Bringing technical clarity to the unknown

The PHP CVE impacted you, too

23 Oct 2026 🔖 security
💬 EN

Even if you didn’t program any of your applications in PHP, you were impacted by PHP CVE-2026-109618 & CVE-2026-109619, because it’s time to go look at how your vendors managed it. After all, they’ll be handling similar attacks against whatever programming language you do use.

Maybe you host Java, .NET, Python, Ruby, NodeJS, etc. applications on a hyperscaler cloud provider’s managed platform – AWS Elastic Beanstalk, Azure App Service, or GCP App Engine, perhaps. The exciting thing is that they patch the operating system and the programming language. But will they patch yours, specifically? It’s worth researching.

  • Microsoft blog: “Critical PHP Security Release: What It Means for Azure App Service”
    • If you use PHP Azure App Service on Linux, they mostly fixed it promptly.
      • Takeaway: Hooray for managed services!
    • However, if you had your Azure App Service resources set in “Change is good; you go first” (“Extended” or “Standard” instead of “Latest”) update-timing mode, then it wouldn’t have been all that promptly.
      • Takeaway: Prepare to have to flip settings on all your resources’ configuration settings, and then flip them all back again to whatever they were before after the crisis has passed. And know how long it would take to do so, because you’ll need to compare that against the vendor’s promises. (Even if you’ve got a well-managed infrastructure-as-code program, maybe you segmented it into a bunch of different source control repositories specifically to prevent people who haven’t had enough coffee from breaking things on every enterprise resource all at the same time with a single typo. So you might have this something that takes a few hours of toil, by design.) You’ll want to know how it compares against the vendor’s timelines, so you can decide whether to flip the switch or just wait, etc.
    • If you were using a configuration that they were still willing to run but had deprecated to “end of life,” like PHP Azure App Service on Windows, they didn’t bother patching you and left you to do it.
      • Takeaway: Get your monitoring and governance house in order. Do you know exactly which cloud resources are out of compliance with what’s fully supported by the vendor? Do the people at your company responsible for fixing it know? How soon are they going to get to that? And if not soon, are they ready to have to be the one wearing the pager to personally do the next patch that they could’ve otherwise let the vendor do?
  • Google blog: “Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619” & Amazon blog “Release: Elastic Beanstalk Amazon Linux 2023 PHP platform updates on October 21, 2026”:
    • I didn’t see anything as clearly and helpfully worded in terms of “we’re not covering this; that’s your problem” as I saw on Azure, but if you were on less than PHP 8.2, you were in the same boat as the PHP Azure App Service on Windows folks – GCP & AWS weren’t going to fix that for you. (AWS really didn’t even spell anything helpful out at all. At least Google bothered to say “PHP 8.1 & under – this means you.”)
      • Takeaway: Get your monitoring and governance house in order. See above. Do you definitely know if your company’s got any poorly-configured GCP or AWS resources?

Also, speaking of seeing how vendors did, I’ve got a neighbor whose business uses Lightningbase for managed Wordpress hosting, and they seemed patched pretty promptly, so shoutout to a Minnesota company for that. I mean, hopefully all the major managed Wordpress & managed Drupal hosts did that, but, ope, I’m always happy to see Minnesota just quietly gittin ‘er done. (They say there’re just 3 things Minnesotans like most – 1. Minnesota, 2. Talking about how great Minnesota is, & 3. Hearing how great Minnesota is.)

--- ---