Check your website's PHP version today, because two remote code execution flaws now have patches

Your website, or the one your shop pays someone to run, very likely runs on PHP (the programming language behind WordPress, Magento and many shopping and news sites). On October 21, 2026, the PHP team published a security advisory about two severe vulnerabilities that let a stranger run code on the server without logging in, along with patches. Your job today is to find out which version your site runs and to ask the right person whether it has been patched.

The weekly roundup weekly-roundup-2026-w44 (October 26) already mentioned the PHP patch and the October 23 configuration line; this article adds the steps for checking your version and a sample message to your provider.

Five steps, in order

An example built for this article: Hoa sells household goods on a WordPress website managed by Tuan, an outside web developer, on a shared hosting plan.

1. Ask whoever manages the site, or open your hosting provider’s control panel, to learn which PHP version the site runs. WordPress shows this under Site Health (the Info tab). If you have SSH access (command-line login to the server), type php -v; that shows the version used on the command line, which can differ from the one the web uses, so check it against the control panel.
2. Compare the number you see with the patched versions in the PHP team’s announcement: 8.5.12, 8.4.27, 8.3.36, 8.2.35, or a higher release in the same branch. If yours is lower, or is 8.1 or older, go to step 3.
3. Send your hosting provider or site manager a short message: “Which PHP version does my site run? Is there a fix for CVE-2026-109618 and CVE-2026-109619 yet? If I am on PHP 8.1 or older, do you have a backported fix for the old version, or must I move to a newer one? After upgrading, have you set session.upload_progress.enabled=0 as the PHP team recommended on October 23?” The third question matters because an old version number may already have been patched with the number unchanged, and only the provider can tell you.
4. Write down the answer and the date you received it. If they promise an upgrade, ask for a specific date and ask them to back up the site first, because an old plugin (an add-on for WordPress) may not run on the new PHP.
5. After the upgrade, repeat step 1. You pass when the new version number is on the list in step 2, the home page, cart and login page still open normally, and the provider confirms that session.upload_progress.enabled is off, or confirms that the application does not change session.serialize_handler at runtime.

Background for these steps: according to the announcement on php.net, the two vulnerabilities are CVE-2026-109618 (a CVE is a shared identifier for one security flaw; use it when you ask your provider. This one comes from an out-of-memory condition that leaves request data half-initialized, after which cleanup treats the corrupted data as valid) and CVE-2026-109619 (state data owned by one request is left behind after its memory is freed, and a later request uses it by mistake). Both allow RCE (remote code execution) without authentication. The PHP team writes that all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed (different ways a server runs PHP), and that the risk is highest for mod_php, where they have a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs.

PHP 8.1 and older no longer receive updates from the project; the PHP team says some Linux distributions and long-term-support vendors provide their own backported fixes, and the team also provided minimal source backports for PHP 7.4, 8.0 and 8.1 for people who build from source.

According to the newspaper Tuoi Tre, citing Reuters and the South China Morning Post, many government agencies took their websites offline while waiting for the patch, and the two flaws were found by cybersecurity companies with AI assistance. Wiz, one of those companies, estimates that PHP runs about 70% of websites worldwide.

On October 21 the PHP team said that only updating is a complete fix; the temporary measures only reduce the attack paths. On October 23 the team advised turning off session.upload_progress.enabled until the next regular bugfix release, to block a rare remote-code-execution path even on patched versions. That flaw occurs only when an application sets session.serialize_handler to php_binary or php_serialize and then switches it to php at runtime with ini_set() before session_start(), while session upload progress is still on; if you turned it off on October 21, leave it as it is, with nothing more to do. A server administrator can set memory_limit=-1 at server level so applications cannot override it, set a low post_max_size (8M if the site does not accept uploads, 32M if it does), and turn off session.upload_progress.enabled and restart every PHP process. The full list, including web-server limits, is in the original advisory; do not change these yourself unless you administer the server.

If your provider does not answer within the day, or says your plan runs PHP 8.1 or older with no backported fix, ask about upgrading or switching providers, and consider temporarily closing pages with logins or payments while you wait. That is this article’s own suggestion, not advice from the PHP team.

Sources

1. php.net, “Security advisory: Critical remote code execution vulnerabilities, update now” (October 21, 2026) — primary source for the two CVEs, the patched versions, who is affected and the temporary measures, plus the “Informational advisory: Session upload progress” entry of October 23, 2026 on the same page; this is the PHP project’s official announcement.
2. Tuoi Tre, “Lỗ hổng bảo mật do AI phát hiện khiến loạt website chính phủ nhiều nước ngừng hoạt động” (October 22, 2026) — reports agencies taking sites offline, AI assistance in finding the flaws and Wiz’s 70% estimate, citing Reuters and the South China Morning Post.
3. Wiz Research blog, “PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet” (October 21, 2026) — the Wiz Research blog page lists the PHP2Shell post of October 21, 2026 by Sagi Tzadik, Shir Tamari, Nir Ohfeld and Tomer Schwartz; source of the 70% estimate.