SANS Stormcast Thursday, October 22nd, 2026: Critical PHP RCE Vulnerabilities Exploited (CVE-2026-109618, CVE-2026-109619); Fortinet AI-Driven Security Hardening Release for FortiOS and More

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/10146.mp3

previous

Critical PHP RCE Vulnerabilities Exploited (CVE-2026-109618, CVE-2026-109619); Fortinet AI-Driven Security Hardening Release for FortiOS and More

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Thursday, October 22, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich, recording today from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu Graduate Certificate Program in Cloud
 Security. So today's podcast will be a little bit a one
 -topic podcast and that's due to the critical PHP
 vulnerability that was patched today. The problem with PHP,
 of course, is it's ubiquitous. 60% or so of websites run PHP.
 There are also a lot of appliances that run PHP where
 it may not always be that obvious that they are running
 PHP. Famously, many open source routers, firewalls like
 OPNsense, pfSense do use PHP and these products have
 released their own updates for it. But also a lot of
 commercial stuff like Cisco, for example, released a page
 with all of their products that are vulnerable. Palo Alto
 has done so. And they're probably not the only ones.
 They're just the ones that I sort of, you know, came across
 today. So if it's running a website, there is a good
 chance it's running PHP. Anything you do in your
 application like authentication, CAPTCHAs,
 things like this, likely will not matter and will not
 protect you from this vulnerability as it's a
 vulnerability in PHP itself. That's triggered before your
 code even sort of really comes into play. So it doesn't
 matter what modules you have loaded. Also, the
 configuration doesn't matter. There are a couple of sort of
 configuration options that are mentioned that may help you
 mitigate the vulnerability. At best, they provide a partial
 protection and will certainly not protect you from all the
 different exploits that are becoming available for this
 vulnerability right now. So that's the other thing.
 Exploitation is already well underway for this
 vulnerability. Denial of service exploit, as it turned
 out later, was released like a few hours ahead of the patch.
 That exploit at least sort of gave a blueprint how an
 exploit could work for this vulnerability. Like, for
 example, the use of multi-part MIME uploads. And that's sort
 of really sort of one of the triggers for these two
 vulnerabilities. So the two vulnerabilities here. The
 first one is an out-of-memory issue where essentially what
 happens is the attacker is starting an upload to the
 website. The PHP code is calculating the memory
 required wrong. And with that, you're going to get out of
 memory. That then leads to basically non-cleared memory.
 And that can then lead to remote code execution. The
 second one is kind of similar but a bit more complex. It
 does, first of all, rely on an initial request that does not
 fully clear the request context. That's always with
 it. And then a second request that basically then exploits
 the double free here. So we basically have that memory
 that still contains content that hasn't sort of been
 properly cleared. So it's sort of more a two request issue,
 the second one. But actually the two vulnerabilities can
 also work together. Because the second vulnerability kind
 of needs an error in order to sort of trigger the initial
 condition. And, well, that's provided by the first
 vulnerability. Anyway, so PHP version 8, you should be
 pretty good for that. Updates are available. PHP 7, PHP 5,
 no updates are available. And, yes, a lot of websites still
 run that old code. So what should you do if you're
 running an old version of PHP? That's really the big, big
 question that a lot of people are asking them. Well, the
 safe thing is shut down your site. A number of websites
 have taken that advice and have basically shut down their
 website for now until they either manage to upgrade or
 come up with some other mitigating protections. There
 are some web application firewall rules for it.
 Cloudflare and providers like that have applied them. So
 that's one way to go. Ideally, you could block all multi-part
 MIME uploads to your website. That's something that you can
 do in a web application firewall rule. But the problem
 with that is that then basically you don't allow any
 uploads to the website. So that's not ideal. And if you
 then have basically exemptions where you exempt certain URLs
 from this block, then, well, those URLs, of course, remain
 vulnerable. Because then again, you can reach the site
 and the PHP code with the multi-part MIME upload. And
 again, it doesn't matter what your code does. So it doesn't
 matter if you require authentication or CAPTCHAs or
 anything for this page. That's all irrelevant because the
 exploit triggers before your PHP code really comes into
 play. Other things that you can do is, yes, there are
 these suggestions to adjust certain PHP INI variables.
 Certainly, something that I think you should do if you can
 patch. But how well that works is somewhat questionable. You
 could hide the fact that you're using PHP good old
 obscurity instead of security. As we all know, not great. But
 maybe it buys you a little bit of time. We don't sort of see
 any sort of random, like, you know, worm-based sort of
 exploits for this yet. So and so far, it looks like the
 attacks are a little bit more targeted at this point. And
 targeting basically websites that are running PHP. But it's
 not that hard usually to figure out that a website runs
 PHP, even if you don't advertise in your headers, if
 you don't use the .php extension for your site. Also,
 you know, keep in mind that a lot of appliances are running
 PHP. Cisco, Palo Alto, they both came up with special web
 pages listing any of their products that are vulnerable.
 OPNsense, pfSense have released updates. Haven't seen
 OpenWrt. They are probably vulnerable as well. But for
 any products like that, you know, when you have these
 complex web applications, that these internal admin
 interfaces, well, they should be internal. So that's, of
 course, another protection that you can apply where these
 appliances and such, you don't expose them to the Internet.
 The problem with upgrading code, of course, from PHP 5
 and 7 to PHP 8 is that this is usually not sort of a simple,
 hey, let's just upgrade PHP. You often must adjust your
 code to actually work. If that's your own code, if it's
 not too much code, not too complex code, then you may be
 able to do that. But if you're using a lot of third-party
 libraries and things like this, then, of course, you
 have to make sure that they are working with the newer
 version of PHP. And that's not sort of, you know, a simple
 plug-and-play kind of, you know, press-a-button kind of
 update. Well, you know, maybe AI will help you. I've had in
 the past some luck with sort of some of these code-based
 updates with AI. That may be, you know, sort of a quick fix
 here if you need one and are willing to sort of risk some
 bugs sort of in your website and popping up that you may
 have to clean up later. It's not pretty. No matter what you
 do, you know, it's not pretty. It'll take a lot of work. Wiz
 apparently discovered this vulnerability using AI tools.
 They released a blog post about that. The PHP Foundation
 also released a blog post with details regarding the
 vulnerability release. It's always very complicated to
 sort of do these, you know, large coordinated releases.
 And I have to say PHP did a pretty good job with that.
 They notified, you know, Ubuntu and like all of the
 Linux distributions and such. And they pretty much came up
 with patches for the distribution within minutes of
 PHP releasing their patch. But apparently one vendor actually
 did release an update like five hours, seven hours before
 the official patch. And of course, that again gave
 attackers a head start trying to reverse the vulnerability
 and trying to come up with exploits. And then, of course,
 you have you had this leak that avoidable like this would
 be coming, which, of course, didn't help either and caused
 PHP to actually move the release up by a day. Well, is
 this sort of a sign of more similar things to come in the
 near future? That's sort of one comment I've seen quite a
 bit. Definitely, you know, take it a little bit as sort
 of an exercise, a dress rehearsal for what's coming
 next. I think as we had with a lot of similar critical
 vulnerabilities in the past, whether it's Heartbleed or
 such inventory, that's always sort of one of the big
 weaknesses. You just don't know what you're running and
 where you're running it and what version you're running.
 That's really, you know, I think if you want to work
 ahead for the next similar vulnerability, that's always
 the part that you probably need to work at first to
 hopefully be ready for. Well, the next time a PHP or a
 similar big product has a vulnerability. Anyway, so this
 is really all I have to say here about this vulnerability.
 Patch, patch quickly. Assume compromise. If you have a
 public website that has no mitigations in place tomorrow,
 definitely, you know, assume compromise. But other than
 that, yeah, there's not really much else you can do at this
 point. And, yes, shutting down your website for a couple days
 until you work out the details may be a realistic option.
 Think about the risk of exploitation and the cost of
 an exploit compared to, you know, the cost of just taking
 down a website for a couple days until you figure out
 exactly what's going on here. Other than that, didn't really
 have any huge issue. There was also a big Fortinet advisory I
 just want to mention here. At first, I thought it was
 related to this PHP issue because it was sort of across
 a number of different Fortinet products. And it was very
 vague about what they were actually patching. They just
 said that they had a security review done using AI tools.
 They credited a couple of AI vendors, but no CVEs being
 mentioned and no additional details. So if you don't run
 PHP, if you run Fortinet, definitely take a look at
 that. That also sounds something interesting. I don't
 want to get this sort of lost in all of the PHP update news.
 Anyway, that's all I have for you today. We also went to
 Infocon Yellow for this reason. We are probably going
 to go back down to green tomorrow unless there's any
 sort of substantial new developments. There were some
 rumors that some of the patches may not be complete.
 But at this point, I've seen no confirmation of this. So at
 this point, I think a good sound working hypothesis is
 that these patches will completely address these two
 vulnerabilities. And are really the only way to
 completely address these vulnerabilities. Well, and
 that's it for today. Thanks for listening. Thanks for
 liking. And hopefully, we'll get back tomorrow to our usual
 sort of news of various zero-days and vulnerabilities. Talk
 to you again tomorrow. Bye.
 Bye.