A NAS used for remote access, a published container port or a gateway once opened temporarily: these services are easily overlooked. With PHP2Shell, three questions matter: what is reachable, which runtime handles web requests, and what other systems can that service reach?
The first two articles in this series cover the PHP security situation and our response and using AI to support an inventory review. This article focuses on practical checks for businesses and private NAS operators. A brand name cannot replace an inventory. Nor does current firmware prove that every package and running container has been updated.
PHP2Shell concerns the runtime actually serving web requests
CVE-2026-109618 and CVE-2026-109619 can allow code execution before application authentication; each has a CVSS v4.0 score of 9.2. On 21 October 2026, the PHP project released the fixed versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Vendors may provide their own corrected packages with backported changes. The relevant advisory therefore matters more than a version number alone.
A login page does not automatically make a system safe here. Check the interpreter that actually processes web requests, including running workers. An up-to-date command-line PHP version cannot establish that on its own. This applies to conventional web servers and to runtimes bundled into applications, appliances and images.
Public exposure can extend beyond port forwarding
The inventory should include IPv4 and IPv6, router rules, UPnP, DDNS names, reverse-proxy destinations, tunnels and cloud-mediated remote access. Establish the actual access path in each case: a public IP address is not itself a vulnerable application. A vendor relay is not automatically exposed to the same attack path either. Conversely, a forgotten rule can expose a service that was intended to remain internal.
Include websites, content management systems, customer portals, hosting panels, and backup, monitoring and administration interfaces. The same applies to NAS platforms, VoIP systems, cameras, printers and control gateways. Devices without a relevant PHP component are not automatically affected by these two CVEs. Their public accessibility is still worth reviewing.
Synology: assess the operating system and packages separately
Synology limits the impact to certain PHP-dependent packages, including Web Station, WordPress, Calendar and MailStation. Its statement of 22 October lists PHP package updates for DSM 7.4, 7.3 and explicitly DSM 7.2, even though that DSM version has reached end of life. For earlier DSM versions, the vendor recommends temporarily disabling affected packages.
PHP is updated through Package Center; MailStation also requires a manual package update. The advisory lists no fix for Synology’s PHP 7.3 package. According to the vendor, the PHP used internally by DSM has a different exposure profile and no externally accessible modules. Names matter too: the third-party package IDrive is not Synology Drive; the statement identifies Synology Drive as unaffected.
For unofficial DSM installations using XPEnology, assess the combination of device, loader, DSM and packages individually. This does not constitute a normally supported Synology system. That does not mean updates are never possible or that every such installation is vulnerable. Uncertain update support is, however, a good reason to restrict direct internet access and plan for reliably maintainable operation.
QNAP: check the status that has changed since the initial announcement
Since its update of 24 October, QNAP advisory QSA-26-18 lists fixes for several QTS, QuTS hero and QuTScloud branches. Other listed applications remain marked “Fixing”. Neither “QNAP has no patch yet” nor “everything is resolved” accurately describes that situation. Check the specific product, its version branch and the corresponding fixed release. PHP in third-party applications or custom containers is not automatically repaired by a QNAP system update.
Containers raise two separate questions
First: is the runtime in the running container fixed? Updating the host does not replace an old image. The base image, additional packages and actual running deployment must match. Having a new image available locally only helps once the service has been redeployed with the corrected version and has passed functional checks.
Second: what permissions and network paths does the service have? Docker bridge networks generally allow outbound connections, and containers on the same bridge network can communicate with one another. Access to internal destinations depends, among other things, on routing and firewall rules. A compromised container therefore does not automatically take over the entire LAN. Shared credentials, unnecessary host mounts, additional privileges or a mounted Docker socket can nevertheless increase the consequences substantially. Separate networks, targeted egress rules and minimal permissions require a concrete review.
Seven checks for the next work session
- Inventory access paths: document devices, applications, published ports and intermediary services, with named owners. Include IPv6 and forgotten temporary rules.
- Identify runtimes: record the operating system, packages, plugins and web PHP for each service. Check vendor guidance and maintenance status.
- Fix and verify: apply suitable updates or new images, restart affected services properly and check the version actually in use.
- Reduce exposure: close unnecessary public administration access. A VPN or trusted administration network can restrict access; updates are still required behind it.
- Test paths and permissions: limit database, NAS, backup and management access to what is needed. Change rules safely and then check legitimate applications.
- Review evidence and recovery: assess unusual access, accounts and outbound connections. Maintain independent backups protected against unauthorised changes and test restoration; snapshots alone are not a substitute.
- Track exceptions: document systems without an available fix, with an owner, interim measure and replacement or retirement plan.
A patch does not automatically complete an incident review
Sophos refers to an exploitation attempt observed by Amazon Threat Intelligence as early as 17 October, before public disclosure. For systems that were actually exposed, earlier activity therefore belongs in the assessment too. A successful update does not prove that no unauthorised access occurred beforehand. Where there are signs of compromise, use an organised incident response with appropriate evidence preservation and controlled recovery.
Since 23 October, PHP has also highlighted a rare, configuration-dependent additional case involving session upload progress. Current vendor guidance therefore remains relevant after the first update. Broad configuration changes made without understanding their operational effects are a poor shortcut.
If a service does not need to be public, keep it inaccessible from the internet until it has been assessed. This reduces the attack surface and does not replace a fix. DAXS helps identify services, prioritise measures and check their effectiveness with clear evidence. Discuss your environment with us.
Sources: PHP: security advisories and fixed versions · ENISA: identify PHP applications and restrict exposure · Synology: affected packages and DSM versions · Synology-SA-26:14 · QNAP QSA-26-18: product-specific fix status · Docker: bridge network behaviour · Sophos: exposure, activity and incident review · NCSC-NL: overview of PHP dependencies · Red Hat: runtimes, backports and additional guidance.
