WEBVTT
00:00:00.160 --> 00:00:12.400
Hi, this is Tanya Jenka from DevSecStation, and I'm interrupting our regular podcast schedule with a short security emergency bulletin because these two critical vulnerabilities cannot wait.
00:00:12.720 --> 00:00:22.480
PHP released two critical vulnerabilities, and if you develop or maintain PHP applications, I need you to listen to the message that follows.
00:00:22.719 --> 00:00:27.600
If you have a website or application running PHP, you need to pay attention to this.
00:00:27.839 --> 00:00:41.280
Yesterday, the PHP team released emergency patches for two critical security vulnerabilities that could allow an attacker to remotely execute code on your server without logging in.
00:00:41.439 --> 00:00:44.320
They're called PHP2 Shell.
00:00:44.799 --> 00:00:52.640
And the vulnerabilities are CVE 2026, 1009618, and 1009619.
00:00:53.280 --> 00:00:56.960
Both have a critical severity rating of 9.2.
00:00:57.520 --> 00:01:01.439
And this is the thing that makes this really important and really scary.
00:01:01.600 --> 00:01:03.759
These vulnerabilities are not in your application.
00:01:03.840 --> 00:01:06.079
They are in PHP itself.
00:01:06.239 --> 00:01:09.040
So you could have done every single thing right as a developer.
00:01:09.280 --> 00:01:19.920
You could have perfect input validation, parameterized queries, strong access control, and great secure coding practices, and your application could still be vulnerable.
00:01:20.239 --> 00:01:20.879
Why?
00:01:21.439 --> 00:01:26.719
Because these are memory safety vulnerabilities inside the PHP runtime.
00:01:26.959 --> 00:01:31.920
One involves what happens when PHP runs out of memory at exactly the wrong moment.
00:01:32.159 --> 00:01:37.120
The other involves PHP accidentally using memory that's already been freed.
00:01:37.200 --> 00:01:39.359
So use after free is what that's called.
00:01:39.519 --> 00:01:46.400
In certain circumstances, an attacker can exploit these problems to execute their own code on your server.
00:01:47.280 --> 00:01:55.599
In one demonstrated attack against Apache with mod underscore PHP, the exploit could happen before the application code even started running.
00:01:55.920 --> 00:02:02.480
So all that beautiful input validation that you wrote, it doesn't get to help you.
00:02:02.959 --> 00:02:06.000
So now let's talk about what you should do about this.
00:02:06.159 --> 00:02:11.599
First, find out if you are running PHP, 69% of the entire internet is.
00:02:12.240 --> 00:02:13.759
Not just your main website.
00:02:13.919 --> 00:02:20.800
Check your containers, older applications, third-party products, and anything else that might have PHP bundled inside of it.
00:02:21.199 --> 00:02:24.400
Second, please update immediately.
00:02:24.560 --> 00:02:29.919
Cancel whatever meeting you're about to go to, whatever you are about to do, do it literally right now, please.
00:02:30.159 --> 00:02:44.719
The patched versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
00:02:45.039 --> 00:02:51.919
If you are using PHP 8.1 or older, you are running an unsupported version, no comment.
00:02:52.159 --> 00:02:59.520
Check whether your operating system vendor has provided a backported security fix or upgrade to a supported release.
00:02:59.759 --> 00:03:06.080
And if you use containers, make sure you rebuild and redeploy them with the patched runtime.
00:03:06.319 --> 00:03:09.520
Updating your source code alone won't fix this.
00:03:09.759 --> 00:03:11.199
Okay, third thing to do.
00:03:11.360 --> 00:03:15.360
Please don't assume your web application firewall is going to save you from this.
00:03:15.520 --> 00:03:24.800
A WAF might help block certain exploit attempts, but it is not a complete fix for a vulnerability inside the programming language runtime.
00:03:24.960 --> 00:03:28.400
This is very different than most vulnerabilities we've previously seen.
00:03:28.639 --> 00:03:30.960
The PHP project has been extremely clear.
00:03:31.120 --> 00:03:32.719
You must update.
00:03:33.120 --> 00:03:35.919
Okay, another interesting part of the story.
00:03:36.319 --> 00:03:38.240
Of course, AI was evolved.
00:03:38.479 --> 00:03:39.759
Of course it was.
00:03:40.800 --> 00:03:46.560
Researchers at Wiz used AI models to help find, investigate, and validate these vulnerabilities.
00:03:46.800 --> 00:03:56.240
And I feel that that is important because it shows how AI can help security researchers find serious problems in the foundations of software.
00:03:56.560 --> 00:04:04.800
But on top of that, the really big scary lesson here is that secure coding doesn't end with the code that you personally wrote.
00:04:04.960 --> 00:04:06.960
The entire supply chain matters.
00:04:07.120 --> 00:04:16.160
So your application depends on programming language, runtime, frameworks, libraries, and all sorts of other components that make up your supply chain.
00:04:16.240 --> 00:04:18.959
And any one of those can have vulnerabilities.
00:04:19.199 --> 00:04:35.199
And that is why secure software development includes keeping your dependencies and runtimes updated, understanding the entire package that you are deploying, and having a way to respond quickly when something serious is discovered.
00:04:37.759 --> 00:04:45.360
At this point, I want to acknowledge the PHP maintainers and security team here because obviously they have been working around the clock to fix this.
00:04:45.680 --> 00:04:55.439
Fixing critical vulnerabilities and software that so much of the internet depends on is difficult work, stressful work, high pressure work.
00:04:55.600 --> 00:04:59.439
And they have coordinated these emergency releases to protect users.
00:04:59.600 --> 00:05:05.199
So please, if you're running PHP, check your versions, get those patches applied right away.
00:05:05.360 --> 00:05:11.680
And if you are a developer who does not control production updates, send this video to the people that do.
00:05:12.319 --> 00:05:17.199
Just to be clear, the lesson here is not that secure coding doesn't matter because it absolutely does.
00:05:17.360 --> 00:05:33.680
The lesson here is that even excellent application security practices can't compensate for every vulnerability in the software underneath your application, which is why we need to be able to be agile and release updates quickly and safely.
00:05:34.480 --> 00:05:36.160
Please patch your PHP.
00:05:36.399 --> 00:05:40.160
One more thing that I needed to mention that I didn't mention in that video.
00:05:40.480 --> 00:05:49.279
If you are on WordPress.com, so if your website is hosted by WordPress.com, you are safe from this vulnerability.
00:05:49.680 --> 00:05:59.600
However, if you are hosting WordPress yourself, if you're hosted elsewhere, if you have taken your version of WordPress from WordPress.org, none of that is the same thing.
00:05:59.759 --> 00:06:00.800
None of that is guaranteed.
00:06:00.879 --> 00:06:02.399
And I need you to go check right now.
00:06:02.560 --> 00:06:04.959
So again, good job, WordPress.com.
00:06:05.120 --> 00:06:08.000
Thank you so much for having the announcement and patching that quickly.
00:06:08.160 --> 00:06:09.199
I appreciate you.
00:00:00.160 --> 00:00:12.400
Hi, this is Tanya Jenka from DevSecStation, and I'm interrupting our regular podcast schedule with a short security emergency bulletin because these two critical vulnerabilities cannot wait.
00:00:12.720 --> 00:00:22.480
PHP released two critical vulnerabilities, and if you develop or maintain PHP applications, I need you to listen to the message that follows.
00:00:22.719 --> 00:00:27.600
If you have a website or application running PHP, you need to pay attention to this.
00:00:27.839 --> 00:00:41.280
Yesterday, the PHP team released emergency patches for two critical security vulnerabilities that could allow an attacker to remotely execute code on your server without logging in.
00:00:41.439 --> 00:00:44.320
They're called PHP2 Shell.
00:00:44.799 --> 00:00:52.640
And the vulnerabilities are CVE 2026, 1009618, and 1009619.
00:00:53.280 --> 00:00:56.960
Both have a critical severity rating of 9.2.
00:00:57.520 --> 00:01:01.439
And this is the thing that makes this really important and really scary.
00:01:01.600 --> 00:01:03.759
These vulnerabilities are not in your application.
00:01:03.840 --> 00:01:06.079
They are in PHP itself.
00:01:06.239 --> 00:01:09.040
So you could have done every single thing right as a developer.
00:01:09.280 --> 00:01:19.920
You could have perfect input validation, parameterized queries, strong access control, and great secure coding practices, and your application could still be vulnerable.
00:01:20.239 --> 00:01:20.879
Why?
00:01:21.439 --> 00:01:26.719
Because these are memory safety vulnerabilities inside the PHP runtime.
00:01:26.959 --> 00:01:31.920
One involves what happens when PHP runs out of memory at exactly the wrong moment.
00:01:32.159 --> 00:01:37.120
The other involves PHP accidentally using memory that's already been freed.
00:01:37.200 --> 00:01:39.359
So use after free is what that's called.
00:01:39.519 --> 00:01:46.400
In certain circumstances, an attacker can exploit these problems to execute their own code on your server.
00:01:47.280 --> 00:01:55.599
In one demonstrated attack against Apache with mod underscore PHP, the exploit could happen before the application code even started running.
00:01:55.920 --> 00:02:02.480
So all that beautiful input validation that you wrote, it doesn't get to help you.
00:02:02.959 --> 00:02:06.000
So now let's talk about what you should do about this.
00:02:06.159 --> 00:02:11.599
First, find out if you are running PHP, 69% of the entire internet is.
00:02:12.240 --> 00:02:13.759
Not just your main website.
00:02:13.919 --> 00:02:20.800
Check your containers, older applications, third-party products, and anything else that might have PHP bundled inside of it.
00:02:21.199 --> 00:02:24.400
Second, please update immediately.
00:02:24.560 --> 00:02:29.919
Cancel whatever meeting you're about to go to, whatever you are about to do, do it literally right now, please.
00:02:30.159 --> 00:02:44.719
The patched versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
00:02:45.039 --> 00:02:51.919
If you are using PHP 8.1 or older, you are running an unsupported version, no comment.
00:02:52.159 --> 00:02:59.520
Check whether your operating system vendor has provided a backported security fix or upgrade to a supported release.
00:02:59.759 --> 00:03:06.080
And if you use containers, make sure you rebuild and redeploy them with the patched runtime.
00:03:06.319 --> 00:03:09.520
Updating your source code alone won't fix this.
00:03:09.759 --> 00:03:11.199
Okay, third thing to do.
00:03:11.360 --> 00:03:15.360
Please don't assume your web application firewall is going to save you from this.
00:03:15.520 --> 00:03:24.800
A WAF might help block certain exploit attempts, but it is not a complete fix for a vulnerability inside the programming language runtime.
00:03:24.960 --> 00:03:28.400
This is very different than most vulnerabilities we've previously seen.
00:03:28.639 --> 00:03:30.960
The PHP project has been extremely clear.
00:03:31.120 --> 00:03:32.719
You must update.
00:03:33.120 --> 00:03:35.919
Okay, another interesting part of the story.
00:03:36.319 --> 00:03:38.240
Of course, AI was evolved.
00:03:38.479 --> 00:03:39.759
Of course it was.
00:03:40.800 --> 00:03:46.560
Researchers at Wiz used AI models to help find, investigate, and validate these vulnerabilities.
00:03:46.800 --> 00:03:56.240
And I feel that that is important because it shows how AI can help security researchers find serious problems in the foundations of software.
00:03:56.560 --> 00:04:04.800
But on top of that, the really big scary lesson here is that secure coding doesn't end with the code that you personally wrote.
00:04:04.960 --> 00:04:06.960
The entire supply chain matters.
00:04:07.120 --> 00:04:16.160
So your application depends on programming language, runtime, frameworks, libraries, and all sorts of other components that make up your supply chain.
00:04:16.240 --> 00:04:18.959
And any one of those can have vulnerabilities.
00:04:19.199 --> 00:04:35.199
And that is why secure software development includes keeping your dependencies and runtimes updated, understanding the entire package that you are deploying, and having a way to respond quickly when something serious is discovered.
00:04:37.759 --> 00:04:45.360
At this point, I want to acknowledge the PHP maintainers and security team here because obviously they have been working around the clock to fix this.
00:04:45.680 --> 00:04:55.439
Fixing critical vulnerabilities and software that so much of the internet depends on is difficult work, stressful work, high pressure work.
00:04:55.600 --> 00:04:59.439
And they have coordinated these emergency releases to protect users.
00:04:59.600 --> 00:05:05.199
So please, if you're running PHP, check your versions, get those patches applied right away.
00:05:05.360 --> 00:05:11.680
And if you are a developer who does not control production updates, send this video to the people that do.
00:05:12.319 --> 00:05:17.199
Just to be clear, the lesson here is not that secure coding doesn't matter because it absolutely does.
00:05:17.360 --> 00:05:33.680
The lesson here is that even excellent application security practices can't compensate for every vulnerability in the software underneath your application, which is why we need to be able to be agile and release updates quickly and safely.
00:05:34.480 --> 00:05:36.160
Please patch your PHP.
00:05:36.399 --> 00:05:40.160
One more thing that I needed to mention that I didn't mention in that video.
00:05:40.480 --> 00:05:49.279
If you are on WordPress.com, so if your website is hosted by WordPress.com, you are safe from this vulnerability.
00:05:49.680 --> 00:05:59.600
However, if you are hosting WordPress yourself, if you're hosted elsewhere, if you have taken your version of WordPress from WordPress.org, none of that is the same thing.
00:05:59.759 --> 00:06:00.800
None of that is guaranteed.
00:06:00.879 --> 00:06:02.399
And I need you to go check right now.
00:06:02.560 --> 00:06:04.959
So again, good job, WordPress.com.
00:06:05.120 --> 00:06:08.000
Thank you so much for having the announcement and patching that quickly.
00:06:08.160 --> 00:06:09.199
I appreciate you.
