On October 21, 2026, PHP officially released a security update fixing two high-risk vulnerabilities that allow remote code execution (CVE-2026-109618, CVE-2026-109619). Over the past few days, multiple cloud platforms have been sending reminders to users, and some customers have also come to us with text messages asking: will our website be affected?
To put it directly: Not affected, no action required.
The official websites, mini-programs, and backend systems developed, hosted, and maintained by HOLYPro do not use PHP, and the trigger conditions for this vulnerability do not exist in these systems.
Why is the impact of this vulnerability so extensive?
The vulnerability is not located in the application code, but inside the PHP interpreter: one issue is that when an interrupt occurs due to memory exhaustion, the cleanup process mistakenly frees memory that still contains data left over from the previous request; the other is that the request's internal state is not cleaned up after being freed, and is mistakenly used by the next request in the same worker process. Both paths occur before application code executes, so no matter how well-written the program is, it cannot prevent it.
An attacker does not need an account or to log in; by crafting a specially designed request, they can execute arbitrary code on the server, with a CVSS score of 9.2. The China National Vulnerability Database (CNVD) rates it "High Risk", and the Ministry of Industry and Information Technology NVDB, EU CERT-EU, and UK NCSC have all issued warnings.
Affected ranges include multiple earlier versions of 8.2, 8.3, 8.4, and 8.5, as well as version 8.1 and earlier, and affect a large number of mainstream PHP-based systems such as WordPress, Drupal, Joomla, Magento, and Laravel. Government websites in multiple countries have taken the approach of temporarily going offline to avoid risk.
Why isn't our system in there?
HOLYPro's self-developed digital platform does not use PHP: the backend is Node.js + TypeScript, database access uses parameterized queries, the frontend is Vue, and deployment and database migrations are automated by our own scripts.
The SaaS website products we offer externally also do not use PHP; their tech stack is Java.
In other words, the trigger mechanism of these two vulnerabilities—the memory management of the PHP interpreter—does not exist in either of these two systems. This is not because we applied a temporary patch; it is because this component simply does not exist in our systems.
The boundaries also need to be made clear: the above refers to systems developed, hosted, and maintained by HOLYPro. If your company has other sites built earlier through outsourcing, built on third-party website-building platforms, or procured independently by other departments, they are outside the scope of our maintenance and require separate verification; the method is described in the next section.
If you have other PHP sites on hand, do a three-step self-check.
First, get a clear count of your sites. Official websites are easy to think of, but forums, online stores, old campaign pages, and special topic pages built by outsourcers are the easiest to miss.
Second, check versions in the right place. The command-line php -v shows the CLI version, while the website is often actually running a different one; to check the one the website is running, use php-fpm -v or the corresponding php-fpm8.x -v. CNVD has specifically pointed this out; inconsistency between the two is very common.
Third, don't focus only on the PHP version. If the site runs programs such as WordPress, Drupal, Joomla, or Magento, the programs themselves also have versions to keep track of. In addition, official support for 8.1 and earlier has ended, leaving only minimal source-level backported patches; we recommend migrating to a supported version as soon as possible.
If you're not sure what environment your site is running in, send us the domain name, and we'll take a look for you at no charge.
About the word safety
We won't claim we're absolutely secure. No company can afford to say that, and it wouldn't hold up anyway—every language has vulnerabilities, just in different shapes.
What we can state clearly are two concrete things: security advisories are on our daily monitoring list, with someone watching them rather than waiting for news pushes; and when an upgrade is needed, we can complete it within the window without breaking our clients' sites.
The most noteworthy thing about this incident is actually the timing: vulnerability information was leaked before the patch was released, and attackers struck just hours before the fixed version went live. From "knowing there's a hole" to "getting hit," the window may be only a few hours.
So when choosing a website-building solution, it's worth asking one more question: when a vulnerability appears in the future, who will apply the patch, how long will it take to finish, and will patching break the site?
If you have any questions, contact us anytime.