I cover most languages on my website, but there’s one I’ve avoided: PHP — PHP: Hypertext Preprocessor.
Why? Because, in the past, it was a language that has often ended up with code being integrated using a notepad-type approach and where bugs were often not fully tested. The other problem with PHP is that the code is often hidden away from the actual creator of the web server, and where they create content that is eventually coded into PHP and HTML.
With PHP, we integrate code into an HTML page within the <?php> and <?> tags:
This allows the code to be compiled and run when the page is loaded, and where the server will use a PHP compiler to convert the PHP code into HTML code that can be run in the browser. This avoids having to send special code to the browser (often with JavaScript), and means that the server can send code which does not need too much interpretation. PHP is thus server-side code, rather than client-side.
Is PHP still used?
So why is it still around and useful? Well, it is the server-side code that Linux servers use, and where Linux servers are by far the most popular type of operating system. In fact, it is estimated that around 90% of public cloud infrastructure runs on Linux servers, and almost every electronic gadget with an embedded operating system runs Linux.
Currently, Shodan — the scanner service on the Internet — reveals that there are nearly 3 million servers which support PHP [here].
and where the server responds with the form of:
We can see that this is an Apache Web server running PHP Version 7.0.31 (Apache/2.4.34 (Win32) OpenSSL/1.0.2o PHP/7.0.31). A key factor in the success of PHP is its usage on the Apache Web server, and which is one of the most popular Web servers. But while PHP is well supported on many systems, it is often not well liked by programmers, and who often rate it as their least liked programming language alongside with Perl, VBA (Visual Basic) and Objective-C.
Anyone who has ever used PHP on an Apache Web site will know that it typically has the standard folder of public_html, and where the index.php file is normally the default file that is loaded from the Web site:
Over the years, PHP has not had a great track record for security, and where many cybersecurity scanners scan for known vulnerabilities. With this, the Websites that often run the PHP code are often hidden away from the owner, and where there can be a lack of patching against vulnerabilities. With this, the user often has a graphical user interface to design their Website, and then the system automatically produces the required PHP code to run the site, such as with WordPress:
Some estimates put the use of PHP on Websites as high as 70% of all running Web servers. Other examples include Drupal (as used by many government web sites around the World), Worktribe and Moodle.
PHP Vulnerability
Yesterday, the National Cyber Security Centre (NCSC) identified a critical security vulnerability with PHP and that can allow intruders to execute commands on web servers. The key vulnerabilities relate to how PHP handles memory and which can expose underlying data within the connected database:
- CVE-2026–109618. This is an “Out-of-memory handling” issue that can lead to memory corruption.
- CVE-2026–109619. This is a “Request-owned internal state” that can persist after memory is freed, and where code and data are still left there.
The basic fix for this is to find the systems that support PHP, and update these to the latest version of PHP:
The fixed versions are PHP 8.5.12, PHP 8.4.27, PHP 8.3.36,and PHP 8.2.35. After installing the patch, it is important to log and observe access to the Web servers, and identify any suspicious activity. Normally, on our Web hosting infrastructure, we can view the version by looking at the PHP Info file:
We can see that this Web server is patched, as it is using Version 8.5.12. A scan of PHP sites for their version shows that there are still many sites that are at risk [here]:
GenAI finds bugs faster than humans
While in the past, humans have been used to identify bugs in code, it is increasingly GenAI models which are discovering bugs. For this, the PHP Foundation — and which maintains the PHP code — has been working with a number of GenAI companies to understand where there may be problems in their code. With this, the vulnerability was discovered by a human (a researcher known as Ryan A) and Anthropic’s Mythos model in mid-August, and was announced on 22 October 2026. The delay allowed many critical websites to be patched before the annoucement. Unfortunately, there was already buzz on social media and various forums that the vulnerabilities had been found — so the annoucement was brought forward in time.
Overall, these are bad vulnerabilities and where CVE-2026–109618 and CVE-2026–109618 are both rated with a 9.2 out of 10 for severity [here][here]:
So what?
The major problem here is possibly not the Website administrators who quickly patch their systems, but the millions of other web servers and systems which will not be updated — and which could be exploited in the near future. There is also disquiet about the vulnerability being leaked before it was officially announced, and about attempts to exploit Web servers that were found at least four days before the official annoucement. With this, there are already signs of multiple proof-of-concept code versions that were ready to be used.
One thing that may change is that the PHP Foundation may receive new funding to support its work, as it can now be seen as fundamental to the security of the Internet. This happened in the past with the HeartBleed bug, and which led to the OpenSSL Foundation being supported in locating and fixing bugs within the OpenSSL software library. With the rise of GenAI scanning, the number and severity of bugs found in critical software infrastructures is only going to increase, and so we need to support the finding and fixing of these bugs before they can be exploited by threat actors.