On October 21, 2026, the PHP development team fixed two critical vulnerabilities, collectively known as "PHP2Shell," that could allow arbitrary code to be executed remotely without authentication. But Amazon's threat intelligence team had already observed exploitation attempts four days earlier, on October 17. On an ordinary web server, an administrator can simply update PHP. On a NAS (network-attached storage) device, however, PHP is built into the operating system, and owners may not be able to update it themselves. For these devices, what determines when the vulnerability is closed is not the date PHP itself was patched, but the date the vendor ships its update. QNAP, which uses PHP in its OS's web-related functions, had still not given a release date for a fixed version as of October 23, six days after the earliest exploitation attempt confirmed by Amazon.
To understand the problem, it helps to distinguish where PHP is used inside a NAS and what update options each vendor offers. Comparing each company's security advisories and response timing shows that, even for the same vulnerabilities, the measures available to owners differ considerably.
Where PHP is embedded in a NAS determines how it can be fixed
The two flaws are CVE-2026-109618 and CVE-2026-109619, fixed in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Advisories from QNAP and Asustor classify both as critical, with a CVSS v4.0 score of 9.2. According to the PHP development team's official announcement, configuration changes can restrict some attack paths, but fully eliminating the vulnerabilities requires updating to a fixed version. On October 21, the US Cybersecurity and Infrastructure Security Agency (CISA) also urged prompt updates and advised taking systems that cannot be updated offline.
Both flaws involve memory management as PHP handles web requests. In CVE-2026-109618, if processing is interrupted by a memory shortage, cleanup begins before the initialization of internal request data is complete, so invalid data may be treated as valid. In CVE-2026-109619, an internal state referring to freed memory remains, and the same worker (a PHP processing process) uses that state on the next request. In both cases, exploitation can succeed before an application's authentication logic runs, so a login feature alone does not protect against them. The Netherlands' National Cyber Security Centre (NCSC) has also pointed to the impact on products where PHP is embedded in devices or admin consoles and administrators cannot update it directly.
How PHP is built into a NAS differs by vendor. Synology's security advisory lists affected products including PHP 7.3–8.4 packages, Mail Station, and Synology Calendar. The company assesses the risk of exploitation as very low for the PHP built into the OS, since it has no externally accessible functionality. Synology has released fixed versions of the affected packages, which owners can update through Package Center and other means. However, it says it will not provide a fix for PHP 7.3, which has reached end of support.
Asustor's security advisory "AS-2026-023" explains that products where PHP was additionally installed on the ADM operating system are affected. The company recommends stopping Web Server until a fixed version is available, giving users a way to reduce attack paths themselves. In such configurations, stopping the affected web service can at least suppress attacks that go through that service.
QNAP, by contrast, states explicitly that PHP is used in the OS's web-related functions and in multiple applications. Its security advisory "QSA-26-18" cautions that stopping the built-in web server does not protect the web admin interface. In other words, even if owners shut down additional web services, attack paths involving the OS-side PHP may remain. The most effective measure until a fixed version is available is therefore to avoid exposing the NAS directly to the internet. QNAP also recommends stopping unneeded apps and the web server as additional mitigations, but because those steps do not protect the admin interface, it asks owners to prioritize network-level access restrictions.
QNAP further explains that PHP inside containers running on Container Station, and in third-party applications, is outside the scope of its own updates. Applying an OS fix does not automatically fix PHP inside containers. In such environments, owners must separately apply fixes published by the container image or application provider.
The October 17 exploitation attempts reveal differences in NAS vendor response
The period NAS owners need to examine begins not on October 21, when the PHP fixes were released, but on October 17, when exploitation was first attempted. According to Amazon's investigation report, the company's honeypot, MadPot, observed traffic attempting to exploit PHP2Shell on October 17, four days before the vulnerabilities were made public. Amazon recommends checking for suspicious traffic going back to at least that date. Using that date as the starting point, a timeline comparing the PHP team's and NAS vendors' responses looks like this:
| Date | Event | Source |
|---|---|---|
| Oct. 17 | Amazon's MadPot honeypot observes the earliest PHP2Shell exploitation attempt known to the company | Amazon |
| Oct. 21 | The PHP team releases fixed versions for four release series at 14:00 UTC (23:00 Japan time) | PHP, Amazon |
| Oct. 22 | Synology publishes its advisory and points to fixed versions of PHP packages and other components | Synology |
| Oct. 22 | QNAP publishes its advisory. The fix status for affected products is "Fixing," with no release date for a fixed version | QNAP |
| Oct. 22 | Asustor publishes its advisory. Status for ADM 4.1–4.3 and 5.0/5.1 is "Ongoing" | Asustor |
Note: Based on information published by each company as of October 23, 2026.
From the earliest exploitation attempt confirmed by Amazon to October 22, when Synology pointed to fixed versions, was five days. QNAP and Asustor also published advisories the same day, but as of October 23 had not disclosed release dates for fixed versions. The products QNAP acknowledged as affected include operating systems such as QTS, QuTS hero, and QuTScloud, along with multiple applications. The fix status of every listed product is "Fixing," and the fixed-version column reads "To be announced." Even after PHP itself was patched, NAS owners remain in a situation of waiting for vendor updates.
The three companies' advisories were all published on October 22, but the availability of fixes and workarounds differs. Synology points to fixed versions for the affected packages, and Asustor recommends stopping Web Server. With QNAP, stopping the built-in web server does not protect the web admin interface, making network-level access restrictions important. All three are addressing the vulnerabilities, but the extent to which owners can reduce attack paths themselves varies.
The concern is not limited to these three companies. According to AppleInsider, TerraMaster also replied on Reddit on October 22 that it was investigating the issue and working on a fix. This followed an owner's report that PHP 7.4.33 was running in the web admin interface of the F2-425. However, it has not been confirmed whether PHP2Shell can actually be exploited in this configuration, and the mere fact that an old version of PHP is running does not mean a system can be compromised.
Comparing with Japanese rental server providers makes the difference in response clearer. According to Sakura Internet's official maintenance record, the company began PHP update work at 23:00 on October 21 and completed it at 6:30 the next day, October 22 — seven and a half hours after the PHP fixes were released at 23:00 Japan time. The company separately announced that it had completed its response to the vulnerabilities for all PHP versions selectable from the admin consoles of its rental servers and other services. In services where the provider manages PHP, the provider's update can also fix users' environments, whereas with a NAS, the vendor must publish an update and the owner must then apply it.
Amazon argues that for critical vulnerabilities in internet-facing systems, the time to apply fixes or mitigations should be measured in hours rather than days. Conventional deadlines of 7 or 30 days may not keep pace with attackers. Owners of QNAP products can implement mitigations such as blocking direct access from the internet without waiting for a fixed version. But fixing the PHP embedded in the OS itself depends on the vendor, and since no release date has been given, it is impossible to estimate concretely how long it will take to complete the update.
Why NAS admin interfaces should not be exposed, even without confirmed exploitation
That said, a high severity score does not mean every affected NAS can be easily taken over. QNAP says it has received no reports of exploitation targeting its products. And according to SecurityWeek, Jake Knott, head of threat intelligence at security firm watchTowr, noted that among the widely circulating exploit code after disclosure, some did not work properly, some only checked for differences in response time, and some only crashed the target system. The code the company examined did not achieve remote code execution (RCE). Amazon also says it is unclear whether the exploitation attempts observed in its honeypot would succeed on real systems.
However, the fact that some circulating exploit code was incomplete is not the same as the vulnerabilities being unexploitable. The PHP team has demonstrated that, in environments using Apache's mod_php, an unauthenticated attack can succeed before application code runs. On the other hand, the CVSS v4.0 assessment rates attack complexity as "high" and lists attack requirements as "present," meaning the environment and conditions affect whether an attack actually succeeds. Judging the likelihood of any individual NAS being compromised from the CVSS 9.2 figure alone is therefore not appropriate.
Caution is also needed in how the response period is counted. October 17 to 21 was a coordinated disclosure period during which details of the vulnerabilities and fixes were withheld. According to the PHP Foundation's explanation, patches had been provided in advance to distributors and others, but public release was set for 14:00 UTC on October 21. In practice, some distributors released fixed versions earlier than planned, but users in general could obtain fixed versions only after the official release on the 21st. Taking October 21 as the starting point, Synology's pointer to fixed versions came the next day, and the status of QNAP and Asustor as of October 23 corresponds to the second day after release.
Still, the reason for using October 17 as the baseline is not to evaluate vendors' response speed but to determine the period in which to look for signs of compromise. Amazon points out that because exploitation attempts existed before the official release, checking only logs from the release date onward is insufficient. The six days from October 17 to 23 therefore do not mean QNAP spent six days on a fix. They mean that PHP-related services reachable from outside during this period should be examined for past traffic and suspicious activity.
The problem is that there is no way to know when the dangerous state will end until the vendor's fixed version is released. Amazon notes that AI-assisted code analysis is lowering the cost of building working exploit code from patch diffs and security advisories. Moving to attack within hours, or even minutes, of technical information being published is becoming possible, so rapid response is needed even after fixes are released. In addition, according to a Censys survey cited by SecurityWeek, of roughly 2.58 million internet-facing hosts as of October 21, the PHP version could be identified on about 1.58 million, and about 1.57 million of those were running unpatched versions. This is a tally based on externally visible version information and does not measure the likelihood that attacks on individual systems will succeed, but it illustrates how many targets attackers can search for.
Given this, QNAP itself urges owners, as the most effective measure until a fixed version is released, not to expose devices directly to the internet. The greatest risk is for NAS devices whose web admin interface or PHP-using web services are reachable from the internet. A configuration reachable only from within the LAN makes direct external attack less likely. However, QNAP also cautions that this does not prevent attacks routed through an already compromised device on the LAN.
Owners of QNAP products should follow the company's guidance: first disable port forwarding and UPnP on the router, and stop unneeded myQNAPcloud Link and public services. When using the NAS remotely, they should connect via VPN rather than exposing the web admin interface directly. Admin ports — the default 8080 and 443, as well as any changed ports — should be restricted to access from trusted local networks or the VPN. Stopping unneeded PHP-related apps and the built-in web server also helps reduce the attack surface, but network-level restrictions remain necessary to protect the admin interface.
In addition, owners should check for signs of past compromise. QNAP recommends checking for suspicious logins and access with QuLog Center and scanning with Security Center and Malware Remover. Following Amazon's advisory, the logs examined should go back to at least October 17. If compromise is suspected, QNAP advises disconnecting the device from the network, changing passwords, and contacting support.
The key thing to watch is how QNAP's security advisory "QSA-26-18" is updated. Once the fixed-version column changes from "To be announced" to specific version numbers, owners can move to the stage of closing the vulnerability through an update. And if later investigation confirms that the web admin interface cannot serve as an attack path, the risk assessment for that interface would change. Even after a vendor releases a fix, however, the vulnerability remains until the owner applies it.
Furthermore, even after the NAS itself is updated, PHP embedded in containers on Container Station and in third-party apps must be checked separately. Components whose update path has been lost because support has ended, like PHP 7.3, for which Synology will not provide a fix, also require attention. Completing the response to PHP2Shell means identifying every instance of PHP running on the NAS, not just the OS, and confirming the fix status of each. Restricting access while waiting for vendor updates, and then finding the old PHP that remains afterward, will be the key tasks for keeping a NAS running safely.