9h05 ▪ 5 min read ▪ by Luc Jose A.
Summarize this article with:
The PHP project asks administrators to update their servers after the discovery of two vulnerabilities that can lead to remote code execution. The alert concerns a language very present on the Web, but the 70% figure mentioned in the press does not correspond to the number of sites actually vulnerable.
In brief
- PHP fixes two critical vulnerabilities that could allow remote code execution.
- These vulnerabilities exploit memory management errors and internal state of the language.
- The 70 % figure refers to the popularity of PHP, not the proportion of vulnerable sites.
- The risk level depends on the PHP version used and server configuration.
- Administrators must install the patches and restart the affected services.
Two vulnerabilities can lead to code execution
The PHP team released several security updates on October 22. Its warning leaves little room for doubt: “critical remote code execution vulnerabilities: update now”. Remote code execution, or RCE, can allow a hacker to run commands on a server without having legitimate access.
The two main vulnerabilities affect the memory management and internal state of PHP. However, their exploitation depends on specific technical conditions. This is therefore not a universal attack that would automatically compromise every site built with this language.
The two critical vulnerabilities rely on different mechanisms :
- The first, referenced GHSA-w8hw-w9fx-j79w, exploits a memory corruption caused when PHP runs out of memory during certain operations. The program can then retain incomplete data before reusing them at the process shutdown ;
- The second, identified as GHSA-6wmf-4rv5-p3rp, relies on a global state that has become obsolete. A first operation leaves information in memory, then another request reuses it as if it were still valid.
In both cases, a hacker must succeed in triggering a particular sequence of operations. Official opinions however mention a risk of code execution, which explains the urgency level retained by the PHP project.
The published patches also cover several less critical vulnerabilities. They include a bypass of PHP-FPM access restrictions with certain IPv6 addresses, an error in TLS certificate verification, and a memory overflow in the OpenSSL component. Issues affecting Phar archives, the SOAP protocol, and the native MySQL driver have also been fixed.
The 70% figure does not designate vulnerable sites
PHP powers a considerable share of sites whose server language is known. It is notably behind WordPress, Drupal, Joomla, and many custom-designed applications. This widespread use explains why a critical flaw in its engine quickly raises significant concern.
Claiming that 70% of the Internet is at risk remains inaccurate. This percentage measures the general usage of PHP, not the proportion of servers running a vulnerable version. It also does not account for systems already patched, different configurations, or the conditions necessary for each attack.
A site may use WordPress without being directly exposed to these two vulnerabilities. According to on-chain analysis, the risk depends on the PHP version installed by the host, active extensions, and how requests are handled. Several sites hosted on the same infrastructure may also share a PHP engine already updated.
The situation is more concerning for servers using an old and unsupported branch. These installations no longer receive official patches. They can thus accumulate new vulnerabilities along with flaws discovered in previous years.
An update and a restart remain essential
Administrators must install the latest security version available for their PHP branch. A simple file modification is not always enough: PHP-FPM services, Apache, or other affected processes must be restarted to load the patched engine.
An inventory must also cover command line interfaces, scheduled tasks, and containers. A server can indeed use multiple PHP versions in parallel. Fixing the main site’s version does not necessarily protect an old internal tool or a container image rarely updated.
Clients of shared hosting can check the active version in their admin area or ask their provider for confirmation. They generally do not have the rights needed to apply the patch themselves on the system.
No massive exploitation of these two vulnerabilities has been established in the official notices consulted. This absence does not reduce the urgency though. Publishing technical details facilitates their study by researchers, but also by hackers. The safest measure remains a quick update, accompanied by checking server logs to detect possible unusual behaviors.
Maximize your Cointribune experience with our "Read to Earn" program! For every article you read, earn points and access exclusive rewards. Sign up now and start earning benefits.
Join the program
A
A
Luc Jose A.
Diplômé de Sciences Po Toulouse et titulaire d'une certification consultant blockchain délivrée par Alyra, j'ai rejoint l'aventure Cointribune en 2019. Convaincu du potentiel de la blockchain pour transformer de nombreux secteurs de l'économie, j'ai pris l'engagement de sensibiliser et d'informer le grand public sur cet écosystème en constante évolution. Mon objectif est de permettre à chacun de mieux comprendre la blockchain et de saisir les opportunités qu'elle offre. Je m'efforce chaque jour de fournir une analyse objective de l'actualité, de décrypter les tendances du marché, de relayer les dernières innovations technologiques et de mettre en perspective les enjeux économiques et sociétaux de cette révolution en marche.
DISCLAIMER
The views, thoughts, and opinions expressed in this article belong solely to the author, and should not be taken as investment advice. Do your own research before taking any investment decisions.