One Week After PHP2shell: Exploitation, Global Response and Open Issues (October 2026 Update)

Key Points

• US CISA added both CVEs to KEV on 26 October (US time). Some product admin interfaces have been attacked, but no breached organization had been named as of 29 October
• The third CVE, CVE-2026-115560, is still unfixed even in the latest releases. Set session.upload_progress.enabled=0 (or keep it if already set) until the next regular release
• The fixed 8.4.27 / 8.5.12 releases have bugs such as a SimpleXML crash. The SimpleXML fix is due in the next release (date not set yet). Avoid rolling back
• Many agencies advise shutting down or isolating what you cannot update. In Japan, local governments and firms paused sites; most major shared hosts patched, old versions included
• Attack attempts have been seen since 17 October, before disclosure. Even if you have updated, check logs, files and processes from 17 October onward

About This Article

This article is a follow-up to "PHP, Node.js and Go Security Fixes (October 2026)", published on 22 October. See that article for how the vulnerabilities work, the fixed versions, and update steps per OS and environment.

For this article, we checked the information that the PHP project, public agencies in various countries, OS vendors, security firms, researchers and universities, hosting providers and product vendors published themselves between disclosure on 21 October 2026 and 29 October (JST), and summarized what we learned and what changed over the past week. We have left out anything we could find only in news reports and could not confirm.

The situation is still developing. For items marked "as of", check the latest status via the official links at the end before you start work.

The Past Week

Dates follow Japan time (JST) for Japanese organizations and, for organizations outside Japan, the publisher's own convention (US time or UTC).

• 17 October: Amazon's decoy systems (honeypots) observed traffic that appears to target this vulnerability, even before disclosure (Amazon announced this on 21 October)
• 20 October (UTC): The CVE IDs circulated together with a wrong rating (CVSS 10.0), and PHP published its pre-announcement early and moved the release from the 22nd to the 21st. The EU's CERT-EU issued an alert before the fix was released
• 21 October (evening, JST): PHP released 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35. WAF providers such as Cloudflare had enabled protection rules about 7–9 hours before the release
• 22 October: JPCERT/CC, IPA and JVN issued alerts. China's CNCERT also issued an alert, and South Korea raised its private-sector cyber crisis alert level. Japanese shared hosting providers carried out emergency maintenance
• 23 October: PHP announced a third vulnerability, CVE-2026-115560 (no fixed version yet). The US FBI also published an alert
• 24 October (UTC): Honeypot data published by a researcher showed code execution that appears to come from this vulnerability
• 26 October (US time): US CISA added both CVEs to KEV (its catalog of known exploited vulnerabilities). JPCERT/CC updated its alert
• 28–29 October: GreyNoise's honeypots also saw code execution. Product vendors keep releasing fixed versions

Exploitation: What Has Been Confirmed

US CISA adds it to its list of known exploited vulnerabilities

• On 26 October (US time), US CISA added CVE-2026-109618 and CVE-2026-109619 to the KEV catalog. KEV lists only vulnerabilities with evidence of real-world exploitation. US federal agencies must act by 29 October and check whether they have been compromised (a forensic investigation). Use in ransomware is listed as "unknown"
• CISA's alert says organizations that cannot update right away, or that run PHP 8.1 or older, should take systems that use PHP offline until they are fixed. It calls a WAF only a temporary defence. CISA has also published detection rules (SIGMA)
• On 22 October (UTC), US NVD lowered its CVSS v3.1 score for CVE-2026-109619 from 9.8 to 8.1. CVE-2026-109618 stays at 9.8. PHP's own rating (CVSS v4.0 9.2) is unchanged

Code execution on honeypots, and attack tools in circulation

• In honeypot data published by a researcher, a shell was launched directly from the Apache process 35 times on three honeypot servers on 24 October (UTC; early on the 25th in JST). The setup was PHP 8.4.26 with Apache + mod_php. The researcher says the environment was deliberately configured to make attacks more likely to succeed
• GreyNoise says it saw five cases between 28 and 29 October in which a honeypot server ran OS commands during attacks from a single IP address in Germany (as of 13:44 JST on 29 October)
• Observations by Delft University of Technology in the Netherlands found a Mirai-family DDoS bot and a backdoor written in Nim among the programs used in the attacks
• Large amounts of unverified exploit code (PoC) have been published on GitHub and elsewhere. VulnCheck says only a small fraction is genuine. South Korea's KISA warns that the "attack test code" in circulation often contains malware, and urges people not to run unverified code
• On the other hand, Sansec cites a researcher's analysis that "most public PoCs do not work against PHP in its standard configuration", and says large-scale exploitation is less likely than first expected. VulnCheck says it has built its own exploit that works against many versions on mod_php with default settings. Whether an attack succeeds depends heavily on the version, configuration and memory layout

Retracted reports, and what is still unconfirmed

• Sophos announced on 22 October (UTC) that it had "confirmed a successful attack", but corrected this the same day to "scanning, with no evidence of compromise". Palo Alto Networks' Unit 42 also withdrew, on the 25th (US time), an addendum from 23 October (US time) that linked an attack on a European government agency to PHP2shell, saying "a link to this CVE cannot be confirmed"
• As of 29 October, we could not find the name of any organization actually compromised through PHP2shell in primary sources. CrowdSec also says the number of publicly confirmed compromises up to 25 October is "zero"
• However, Palo Alto Networks says it has observed exploitation of internet-exposed management interfaces of its own product (PAN-OS) (see below)

Scale of observed attack traffic

• GreyNoise: about 240,000 sessions from 417 IP addresses between 21 and 29 October (of which about 210,000 were attack attempts)
• Delft University of Technology: about 73,000 attack requests from 664 IP addresses in 73 countries. The peak was the hour starting 23:00 (JST) on 26 October, with 8,179 requests
• Fastly: about 250,000 requests from tools carrying the name "PHP2shell" between 12:59 (JST) on 21 October, before disclosure, and the evening of the 22nd (JST; midday on the 22nd in UTC). About one third present themselves as defenders checking their own systems
• WP Engine says it blocked more than 1 million related requests at its WAF in 24 hours and has seen no successful attack
• According to Censys, about 4.18 million hosts on the internet run PHP (as of 23 October; this does not say whether they are patched)

Responses by Public Agencies Around the World

Japan

• JPCERT/CC (JPCERT-AT-2026-0033, published 22 October, updated 26 October): It says there are several reports of traffic attempting attacks, but that whether code execution succeeds depends on the version, environment and memory layout. The 26 October update added CVE-2026-115560 and mitigations. As clues to look for, it lists abnormal PHPSESSID values, memory limit errors or HTTP 500 after suspicious multipart/form-data requests, and unexpected crashes or restarts of PHP workers, and says that even if no traces are found, "you cannot conclude that you were not attacked"
• IPA (published 22 October, updated 27 October): It added the CISA KEV listing. It says it is not aware of any cases of attack damage in Japan. If you cannot update, it asks you to consider interim mitigations or access restrictions, and if even that is difficult, blocking connections from outside or stopping the service
• JVN (JVNVU#99905564, updated 28 October): It lists the status of Japanese vendors. Soliton Systems and FFRI Security say they have "affected products"
• Local governments: In Shiga Prefecture, 13 of 154 systems (6 of them at prefectural schools) were still offline as of noon on 26 October, and Minato City (Tokyo) suspended some functions of its website from late at night on 21 October and had partly restored them as of the 28th. Osaka City also suspended some services, and Fukuoka Prefecture restored all suspended functions of the prefectural website on the 23rd (some sites run by individual departments are still being handled). Minato City, Osaka City and Fukuoka Prefecture say no damage such as unauthorized access or data leaks has been found
• Companies: SoftBank temporarily suspended some of its corporate-customer websites and services for emergency maintenance. LINE WORKS says it used PHP only on its own website and finished its response on the 22nd

United States

• CISA: Besides the KEV listing and the alert above, it asks organizations to inventory where PHP is used, including in embedded products, and to deal first with anything exposed to the internet
• FBI (PSA I-102326-PSA, 23 October): It asks organizations that cannot update right away to take systems offline until mitigated, and, if compromised, to isolate them, preserve web and PHP logs, and report to the FBI

Europe

• EU: The European Commission, ENISA, CERT-EU, Europol and others issued a joint statement on 21 October, calling for identification and updating in cooperation with hosting providers, and for isolation of applications that cannot be updated. CERT-EU (Security Advisory 2026-018) issued its first version on 20 October, before the fix was released
• France (CERT-FR): In its 26 October update, it says it has observed attack attempts against certain PHP environments
• Germany (BSI): Alert level "3 / orange". It says some operators disconnected systems as a precaution, making several sites in Germany hard to reach. It has no reports of confirmed compromise in regulated sectors or the federal administration, but says automated attack attempts are occurring (version 1.2 of 22 October)
• United Kingdom (NCSC): It asks organizations to identify PHP, update it, apply interim mitigations, consider taking systems offline if they cannot act right away, and check for compromise and backdoors
• Netherlands: The government portals Overheid.nl and MijnOverheid.nl, the website of the public authentication service DigiD and others were taken offline as a precaution on 21 October. NCSC-NL keeps a list on GitHub of the status of products that embed PHP (as of 28 October: 757 products, of which 218 "vulnerable", 144 "fixed" and 354 "under investigation")

Asia-Pacific and Other Regions

• South Korea: At noon on 22 October, the Ministry of Science and ICT and KISA raised the private-sector cyber crisis alert from "Attention" to "Caution". KISA has published eight response steps, including inventorying servers at contractors, abandoned servers and test environments, changing DB, API and administrator credentials on servers that were exposed before patching, and not running unverified PoCs
• China: CNCERT issued an alert (CNTA-2026-0006) on 22 October and classified the issues as "high risk" under CNVD-2026-41674 / CNVD-2026-41675. Saying technical details and PoCs are widely available, it asks organizations to check their PHP use and update through official channels
• Hong Kong (HKCERT): It rates the risk as "extremely high" and says the vulnerabilities are being exploited. Its 27 October update added product information from F5, Citrix, Palo Alto Networks, QNAP, Cisco and others
• Singapore (CSA), India (CERT-In), Canada (CCCS), New Zealand (NCSC) and others have also issued alerts. The wording on exploitation differs by agency: Canada says "being exploited" based on public information, and India says "large-scale exploitation"

Responses from Service Providers and Product Vendors

Shared hosting in Japan

Most major shared hosting providers finished patching between 22 and 28 October (old versions on some older plans are not covered). Many of them have applied their own fixes even to old, end-of-life versions (5.x–8.1), but the displayed version number does not change (for example, ConoHa WING still shows 8.5.11). Even if WordPress "Site Health" or a similar tool shows an old version, check your provider's notices to see whether it has been patched.

• Xserver: Finished all target servers by 6:20 on 26 October. 8.2–8.5 were updated to the fixed versions, and 5.1–8.1 were patched without changing the version. As a precaution, it took its service site and control panel offline from 16:00 on the 21st and brought them back in stages from the 22nd (customer sites and email kept running)
• Lolipop: Applied the fixed versions for 8.2 and later, fixes prepared by the PHP developers for 7.4–8.1 and its own fixes for 5.3–7.3, and disabled session.upload_progress on all versions. On some servers, it stopped serving all sites from the early hours to early afternoon on the 22nd. It says it observed traffic that appeared to be attacks but found no unauthorized access
• ConoHa WING and Onamae.com Rental Server: Applied fixes to all versions (5.6.40–8.5.11) on 22 October. They say users do not need to do anything
• Sakura Rental Server: Finished patching all versions selectable in the control panel. It says users must handle any PHP they installed themselves
• KAGOYA: Finished updating its shared hosting as of 28 October. It says it does not recommend continuing to serve sites on unpatched PHP
• CPI: On many of its older shared and managed plans, the unpatched versions are "not covered" by the fix, and it recommends interim mitigations in php.ini or switching versions. It also urges users to check for unknown .php files and CMS administrator accounts they do not recognize
• mixhost: Finished patching all versions (5.2–8.5) on 22 October
• On VPS, cloud servers and other servers where users manage the OS themselves, users must do the updates themselves (Xserver, Sakura VPS, KAGOYA CLOUD VPS and others say the same)

Hosting and cloud outside Japan

• WordPress and other hosting: WP Engine, Kinsta, GoDaddy, Hostinger, SiteGround and Automattic (WordPress.com and others) all say they have finished patching or putting protection in place. WP Engine and Kinsta say they have seen no successful attacks. WordPress.org says WordPress itself does not need updating (the problem is in PHP)
• AWS: The Elastic Beanstalk PHP 8.2–8.5 platforms are patched. Lightsail has published new images (blueprints), but says running instances must be migrated to new instances. Lambda has no AWS-managed PHP runtime, so users must update and redeploy their custom runtimes and containers. The AWS WAF rule group for PHP (AWSManagedRulesPHPRuleSet) now defaults to version 2.4, but AWS itself says it is "not a substitute for updating"
• Microsoft Azure: The built-in PHP on App Service for Linux has been updated to fixed versions for the supported versions (8.2–8.5) (the Extended channel comes last; end-of-life versions get no fix). The built-in PHP on App Service for Windows is already out of support and will not be fixed. Older Alpine-based WordPress images in the Marketplace will not be fixed either, and users are advised to move to the Debian-based ones
• Google Cloud: App Engine standard and Cloud Run (including Cloud Run functions) with automatic updates enabled may be patched automatically (GCP-2026-070). Apigee says only customer-operated Drupal-based developer portals are affected (GCP-2026-072)
• OVHcloud: Shared hosting is updated automatically. Users update bare metal servers and VPS themselves

Chinese cloud providers and server control panels

• BT Panel (宝塔面板): The Linux and Windows editions offer 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35, and for the Linux edition it has also published its own fixed builds for end-of-life versions (8.1.35, 8.0.31, 7.4.34, 7.3.34, 7.2.35, 7.1.34, 7.0.34). 5.4–5.6 are still in testing. The Windows edition has no fix for 8.1 and older, only configuration mitigations. Refresh the software list, update PHP, then restart PHP
• Alibaba Cloud Linux: The fixed versions are php-5.4.16-48.2.al7 on Alibaba Cloud Linux 2, php-7.4.33-8.0.1.al8 on 3 and php-8.3.36-1.alnx4 on 4, or later. Alibaba Cloud warns that the output of php -v can differ from the PHP that actually runs in PHP-FPM, mod_php or containers
• Tencent Cloud and Huawei Cloud: Both have issued alerts: Tencent Cloud points to its WAF, cloud firewall and host security products, and Huawei Cloud to its WAF and cloud firewall. Huawei Cloud says in-the-wild exploitation has been found, but gives no details

Appliances and products that embed PHP

The management interfaces of firewalls, VPN appliances, NAS devices and similar products sometimes embed PHP, and updating the server OS or PHP does not fix it; you need the vendor's fixed version (such as firmware). Check each vendor's information.

• Palo Alto Networks (PAN-OS): Only the management interface (web UI and XML API, including data-plane interfaces with a management profile configured) is affected, and the company says it has observed exploitation of internet-exposed management interfaces. Fixed versions (hotfixes) have been rolling out since 25 October, with some scheduled for 29–30 October. GlobalProtect and Prisma Access are not affected
• Citrix NetScaler ADC / Gateway: Fixed versions (14.1-73.49 and later, 13.1-64.32 and later, and others) are published in CTX697263
• Cisco: Fixed in Expressway 15.5.21 and Duo Access Gateway 3.2.0. Cisco says it is not aware of exploitation against its products
• QNAP: QSA-26-18 publishes QTS 6.1.0.3656 / 5.2.11.3661 and others. QNAP urges users not to expose NAS devices directly to the internet
• Synology: Synology-SA-26:14 publishes fixed versions of each PHP package (for example, 8.2.35-0171 for PHP 8.2). PHP 7.3 is out of support and will not be fixed
• Sophos: It says its own products are not affected. However, it took an old licensing portal (MyUTM) that used affected PHP offline as a precaution
• Docker: The official images and Docker Hardened Images have been updated to fixed versions. Your own images built with FROM php:... stay old until you rebuild them

Updates Since Our 22 October Article (Availability of Fixes)

Fixed versions are now out for many of the items we listed as "not yet available" in the previous article. This is the status as of 29 October.

• packages.sury.org (arm64): Fixed arm64 builds of 8.2–8.5 (with 20261021 in the version) were published by 26 October (JST)
• Oracle Linux: php:8.2 (ELSA-2026-87072) and php:8.3 (ELSA-2026-87079) for OL9, and php:8.2 (ELSA-2026-87073) and php:7.4 (ELSA-2026-87080) for OL8, have been published. php:8.4 for OL9 is not out yet
• RHEL 9 php:8.4 module: Still no fixed version as of 29 October. Either switch streams to the fixed php:8.3 or php:8.2 (the PHP version changes, so test first), or apply the interim mitigations in Red Hat's RHSB-2026-013
• Additional Red Hat fixes: Since 23 October, fixes have been released for long-term support versions such as EUS and AUS. RHEL 7 (ELS) is affected only by CVE-2026-109619 and is fixed in php-5.4.16-48.el7_9.1
• winget: The PHP.PHP.8.4 and NTS packages have also been updated to fixed versions such as 8.4.27
• AWS Elastic Beanstalk: PHP 8.3 / 8.2 were also fixed on 22 October in AL2023 v4.13.13
• SUSE / openSUSE: On 22 October, fixes were also released for SLES 15 SP5 / SP6 (LTSS), SLES 16.0, Leap 16.0 and others (for example, php8 8.4.27-160000.1.1 on SLES 16.0 and Leap 16.0)
• Fedora: F43 (php 8.4.27-2.fc43) and F45 (php 8.5.12-1.fc45) have also reached stable
• Alpine Linux: In the previous article we wrote that "v3.23 and older will not be fixed", but fixed versions have since landed in v3.21–v3.23 as well (for example, php84 8.4.27-r0 on v3.23). v3.20 and older, which are out of support, will not be fixed
• Debian (paid ELTS): Fixes have also been released for php7.3 on Debian 10 (ELA-1854-1) and php7.0 on Debian 9 (ELA-1855-1)
• Still not fixed: The standard php in Amazon Linux 2 and php8.1 in Amazon Linux 2023 remain "no fix planned". You need to move to php8.2 or later

Newly Found Problems

Third vulnerability: CVE-2026-115560 (no fix yet)

• On 23 October, PHP announced another problem in the session upload progress feature that could lead to remote code execution (CVE-2026-115560). It is not fixed even in the 21 October releases (8.5.12 and the other latest versions)
• The conditions are narrow: the configuration file sets session.serialize_handler to php_binary or php_serialize, the application uses ini_set() to switch it to php before calling session_start(), and the upload progress feature is enabled. PHP itself calls this "unlikely"
• The mitigation is to set session.upload_progress.enabled=0 in php.ini or in the FPM pool configuration (php_admin_flag[session.upload_progress.enabled] = off) and restart every PHP worker. This is the same setting we described in the previous article as an interim mitigation for CVE-2026-109619, so if you have already set it, keep it in place. PHP says it will publish the fix and details in the next regular release
• This setting affects some applications that show upload progress. In PHP itself, there is also a proposal to disable it by default (GH-24648)
• As of 29 October, the official record for this CVE (on cve.org or NVD) has not been published yet
• Cloudflare says its existing WAF rules block this CVE, but not for sites that have changed session.upload_progress.name from the default

Bugs found in the fixed releases (regressions)

• SimpleXML crash (GH-24488): In 8.4.27 and 8.5.12, PHP can crash when garbage collection frees SimpleXML objects whose properties were read with get_object_vars(), an (array) cast or json_encode() (the PHP-FPM log shows exited on signal 6 or similar). The cause is a separate fix included in the same release, not the security fix itself. The fix is planned for 8.4.28 / 8.5.13, but no release date has been set. The WordPress hosting handbook urges not going back to the unfixed versions and notes that 8.3.36 does not have this bug
• Forced termination at the memory limit (GH-24492): When a process hits the new "hard memory limit" added by the security fix (by default twice memory_limit), it may exit with code 137 instead of raising the usual "Allowed memory size" error. This has been reported on 8.2–8.5 and is unresolved as of 29 October. If jobs that handle large data stop with a "Hard memory limit" message or exit code 137, suspect this
• Sessions disappear (GH-24493): In 8.5.12, the upload progress handling reportedly rejects some valid data and destroys the whole session (unresolved as of 29 October)
• As of 29 October, PHP has not announced release dates for 8.5.13 / 8.4.28

Windows rebuilds (Brotli)

• On 26 October, PHP published Windows builds 8.5.12-1 / 8.4.27-1 / 8.3.36-1 / 8.2.35-1, rebuilt with Brotli 1.2.1. This addresses the Brotli out-of-bounds write (CVE-2026-111497, covered in the Node.js section of the previous article)
• It only matters if you have enabled automatic decompression of HTTP responses in cURL (off by default). The PHP version itself does not change
• As of 29 October, the winget packages still point to the zip files from before the rebuild. If you need the rebuilt version, download it directly from php.net's Windows downloads
• On 27 October (US time), CISA also added CVE-2026-111497 to KEV

What to Check and Do Now

1. Is the fix really in effect?

• Using the steps in the previous article, check the package version and the PHP version actually running on the web side, and make sure you have fully restarted Apache and restarted PHP-FPM. Old processes keep running the old code
• Check that session.upload_progress.enabled is disabled. For the command-line PHP, php -r 'var_dump(ini_get("session.upload_progress.enabled"));' tells you, but the web side can use different settings, so check it with a temporary script, reachable only from an admin IP, that prints ini_get('session.upload_progress.enabled'), and delete the script right after
• Inventory products that embed PHP, such as firewalls, VPN appliances, NAS devices and business systems, and check the vendors' information. The NCSC-NL list (linked at the end) also helps

2. Are there signs of compromise? (from 17 October onward)

Because attempts were found before disclosure, Amazon recommends investigating at least from 17 October onward. The locations below are examples for Debian / Ubuntu (on RHEL family systems, read apache2 as httpd; where the log location differs, it is noted in each item).

• Shells or download tools started from web server or PHP processes: use ps -ef --forest to check whether the processes under apache2, httpd or php-fpm include sh, bash, curl, wget or similar
• Newly created or modified PHP files: sudo find /var/www -type f -name '*.php' -newermt 2026-10-17 -ls (use your document root if it is elsewhere)
• Crash records: sudo sh -c 'zgrep AH00051 /var/log/apache2/error.log*' (Apache child process crashes; /var/log/httpd/error_log* on RHEL family), sudo sh -c "zgrep 'exited on signal' /var/log/php8.4-fpm.log*" (PHP-FPM; adjust to the version you use, and /var/log/php-fpm/error.log* on RHEL family). Logs are rotated daily or weekly, so include the older logs too. Note that crash records also appear for reasons other than attacks, such as the SimpleXML bug above
• Large numbers of "Allowed memory size" errors or HTTP 500 right after suspicious multipart/form-data requests (a clue listed by JPCERT/CC)
• Connections of web server processes: sudo ss -tnp | grep -E 'apache2|httpd|php-fpm' (incoming connections to ports 80 / 443 on your own server are normal browsing; look for any other connections to destinations you do not recognize)
• Unfamiliar files or scheduled jobs: sudo find /tmp /var/tmp /dev/shm -newermt 2026-10-17 -ls (because of their systemd settings, Apache and similar services write under /tmp/systemd-private-*, so ls /tmp alone does not show these files. Sophos gives /tmp/nfs as an example of a trace), sudo crontab -u www-data -l (apache on RHEL family)
• Any CMS administrator accounts you do not recognize
• Even if you find no traces, you cannot be sure there was no attack (JPCERT/CC)

3. If you suspect a compromise

• Isolate the server from the network. KISA recommends isolating it without rebooting, to preserve evidence
• Preserve the web server and PHP logs, and contact JPCERT/CC in Japan, or your national CERT or law enforcement in other countries
• On servers that were exposed to the internet before patching, change credentials such as database credentials, API keys and administrator passwords (KISA)
• Do not use exploit code circulating online to test "whether my server can be attacked". Cases of such code containing malware have been reported

4. If you run an end-of-life version (8.1 or older)

• The PHP project has not released new versions for 8.1 and older; it has only published minimal fixes for 7.4 / 8.0 / 8.1 as source code. Many shared hosting providers have applied their own fixes, but on a VPS or your own servers you must handle this yourself
• Options for getting fixed packages include packages.sury.org (Debian / Ubuntu; fixes also for 7.4–8.1), Debian's paid ELTS, Ubuntu Pro (ESM) and BT Panel's own builds
• US CISA asks you to take systems running 8.1 or older offline until they are fixed. The real solution is to move to a newer version. Security support for PHP 8.2 ends on 31 December 2026, so KISA recommends 8.3 or later

Official Sources

• Previous article: PHP, Node.js and Go Security Fixes (October 2026)
• PHP: php.net announcements (including the CVE-2026-115560 notice and the Windows rebuilds), PHP Foundation write-up, GH-24488 (SimpleXML bug), GH-24492 (forced termination at the memory limit)
• Japan: JPCERT/CC alert, IPA emergency advisory, JVNVU#99905564
• United States: CISA alert, CISA KEV catalog, FBI PSA
• Europe: CERT-EU 2026-018, CERT-FR, UK NCSC, NCSC-NL product list
• Asia-Pacific: KISA response steps, CNCERT, HKCERT, Canada CCCS
• OS vendors: Red Hat RHSB-2026-013, Oracle Linux, SUSE, Amazon Linux, Alibaba Cloud Linux
• Cloud: AWS 2026-143-AWS, Azure App Service, Google Cloud security bulletins, BT Panel
• Shared hosting in Japan: Xserver, Lolipop, SAKURA internet, KAGOYA, CPI
• Appliance vendors: Palo Alto Networks, Citrix CTX697263, Cisco, QNAP QSA-26-18, Synology-SA-26:14
• Observation data: Amazon (pre-disclosure attempts), GreyNoise, Delft University of Technology, Censys

Disclaimer

This article is Two Sheep Co., Ltd.'s summary of public information as of 29 October 2026 and does not guarantee the behaviour or safety of any product. Always check each vendor's latest information before you start. The companies and organizations mentioned in this article are named to explain developments and do not indicate any business relationship with us. Company and product names are trademarks or registered trademarks of their respective owners.

If you need on-site work for servers in a data center, such as reboots, console access or hardware swaps, contact us about our remote hands service.