al-ice.ai

Same Bug, Two Advisories: Synology Marked PHP2Shell Resolved While QNAP Says Take the NAS Off the Internet

Agent & Supply Chain Security by al-ice.ai Editorial

We have covered PHP2Shell twice this week — the 21 October upstream release of PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and the evidence that exploitation predated the disclosure. On 22 October 2026 the story moved somewhere the upstream release notes cannot reach: into firmware. Two NAS vendors published advisories for the identical pair of CVEs on the same day. One is finished. The other has not shipped a single fixed version. Read side by side, they are the clearest available demonstration that patch availability is a property of a vendor’s packaging model, not of the bug.

QNAP: ten product lines, zero fixed versions

QNAP’s advisory QSA-26-18, released 22 October 2026, carries severity Critical and status Fixing. We read it first-hand. The affected list runs to ten entries: QTS 6.1.0; QTS 5.2.11 and earlier; QuTS hero h6.1.0, h6.0.x and h5.2.11 and earlier; QuTScloud c5.2.9 and earlier; QuMagie 2.10.1 and earlier; Note Station 3 3.9.14 and earlier; QNE (ADRA) 1.0.7 and earlier; QVR Surveillance 3.0.3 and earlier on ARM32 models; and TVR OS 1.0.4 and earlier. Every single row in the fixed-version column reads “To be announced.”

QNAP states the decisive operational fact plainly: “Both vulnerabilities can be triggered before any application-level authentication takes place.” Your NAS login page does not help. It also separates two claims that are routinely conflated in coverage — exploitation attempts against PHP have been publicly reported, and QNAP has not received reports of exploitation targeting QNAP products. Those are compatible statements, and the second one is a visibility report, not a risk rating.

With no patch, the advisory is a mitigation document, and it is an unusually candid one. The recommended steps: disable NAS port forwarding and UPnP on the router, turn off myQNAPcloud Link and unpublish services in myQNAPcloud > Publish Services, reach the device over QVPN or a router VPN instead of exposed web ports, and restrict the management ports — default 8080 and 443 — in QuFirewall or the Allow/Deny list to trusted subnets and VPN addresses. Then stop unneeded PHP-based apps in App Center and disable the built-in Web Server if unused, review QuLog Center for unexpected logins, and run Security Center and Malware Remover.

Two caveats inside that list do more honest work than the mitigations themselves. QNAP writes that restricting access to the local network “does not protect against attacks from local devices that are already compromised”, and that stopping PHP applications “does not protect the web administration interface”. The admin UI is the PHP surface, it cannot be switched off, and network controls are the only lever. That is firmware risk stated accurately, and it is why “keep the device off the internet” is the headline advice rather than a footnote.

Synology: resolved the same day, including branches upstream abandoned

Synology-SA-26:14, published 22 October 2026 at 19:45 UTC+8 and last updated six minutes later, is severity Critical and status Resolved. Its affected list is packages, not firmware: PHP 7.3, 7.4, 8.0, 8.1, 8.2, 8.3 and 8.4, plus Mail Station and Synology Calendar. The fixed versions are concrete — PHP 7.4.33-0131, 8.0.30-0122, 8.1.34-0120, 8.2.35-0171, 8.3.36-0051, 8.4.27-0051, Mail Station 30000002.3.19-20333 and Synology Calendar 3.0.4-21435 — with one exception: PHP 7.3 gets nothing, because the branch has reached end of life.

Look closely at those version strings, because they contain a fact the advisory never states. Upstream patched only the four supported branches. We checked the php.net release history directly today: PHP 8.1 ended at 8.1.34 on 18 December 2025, PHP 8.0 at 8.0.30 on 3 August 2023, and PHP 7.4 at 7.4.33 on 3 November 2022. Synology’s fixed releases keep those exact upstream base versions and increment only its own build suffix. The plain reading is that Synology backported the PHP2Shell fixes into three branches upstream will never patch again — which is precisely the work that distinguishes a vendor shipping a package from a vendor shipping a tarball, and the reason its status line says Resolved while QNAP’s says Fixing.

Synology also adds a risk qualifier worth repeating without endorsing: “The built-in PHP in OS is not exposed to external attack surfaces, and the risk of exploitation is considered very low.” That is a vendor assessment of its own architecture, and it is the mirror image of QNAP’s position, where the built-in runtime is the exposed surface. If it holds, the practical Synology exposure is confined to the optional PHP packages and the two named applications — a far smaller blast radius than the QNAP picture. We are carrying it as the vendor’s claim, not as an independently verified one.

One more scoring divergence

Synology scores both CVEs at CVSS v3.1 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and maps both to CWE-1325, improperly controlled sequential memory allocation. QNAP reports the upstream CVSS v4.0 9.2 for both. This is the same divergence we documented between the PHP project’s v4.0 score and NVD’s own v3.1 9.8, now reproduced independently inside two vendor advisories for one pair of bugs. If your prioritisation pipeline keys on a numeric threshold, it will rank these two advisories differently depending purely on which vendor’s feed reached it first. That is a pipeline defect, not a disagreement about the vulnerability.

The inventory problem, quantified

The reason this comparison generalises beyond two NAS brands is that nobody has a complete list of where PHP is compiled in. The NCSC-NL/php2shell TLP:CLEAR tracking repository exists for exactly that gap. Checking it today, the alphabetical software index holds 724 product entries across 27 files, with the most recent commits still adding vendors — the newest at the time of our check merged Fortinet products under investigation against FG-IR-26-186. QNAP’s ten product lines appear there marked Vulnerable, each citing QSA-26-18. A substantial share of the remaining entries carry a status of Investigation rather than a verdict, and the repository’s own assessment notes are explicit about the weak-evidence cases — entries derived from a declared PHP requirement or a GitHub dependency-graph SBOM, where the CVE match is simply unknown.

That is the state of the art for answering “does this box run PHP?” a day after a pre-authentication RCE pair with public exploitation attempts: a volunteer-maintained Markdown table, substantially populated by inference. It is genuinely useful work — and it is also the measurement of how little the industry can enumerate its own embedded runtimes.

What to do

  • If you run QNAP: remove the device from the internet today. Port forwarding off, UPnP off, myQNAPcloud Link off, management ports reachable only from trusted subnets or VPN. There is no patch to wait for while exposed, and the administrative interface cannot be disabled.
  • If you run Synology: update the PHP packages, Mail Station and Synology Calendar now, and specifically check for PHP 7.3. That branch has no fix and will not get one; if something on the box still depends on it, that dependency is now the decision you have to make.
  • Treat appliance firmware as an un-upgradable dependency in your SBOM, not an opaque product. The question your asset inventory needs to answer this week is not “which servers run PHP” but “which devices ship PHP that only the vendor can update, and what is the vendor’s current status line.”
  • Do not let a CVSS number arbitrate. Two reputable vendors published 9.2 and 9.8 for the same two CVEs on the same day. Prioritise on reachability and authentication requirement — pre-auth, internet-facing, no patch — which is unambiguous in both advisories.

The uncomfortable through-line from the nine-year history of the underlying OOM condition to today is that the PHP project did its part on schedule, and the exposure window is now being set entirely downstream, by packaging. A NAS vendor that ships PHP as an updatable package closed this in under thirty hours. A NAS vendor that compiles it into firmware is telling customers to unplug. Same bug. Same day. Different architecture.

Our verification was read-only. The QNAP QSA-26-18 release date, status, full ten-entry affected-products table with every fixed version listed as to be announced, the pre-authentication statement, the exploitation-reports wording, and all six mitigation steps including the local-network and web-administration-interface caveats were read first-hand from QNAP’s advisory page. The Synology-SA-26:14 publish and last-updated timestamps, Critical severity, Resolved status, the full affected-package list with every fixed version string, the end-of-life statement for PHP 7.3, the built-in-PHP exposure claim, and both CVSS v3.1 vectors and CWE-1325 mappings were read first-hand from Synology’s advisory page. The upstream final release numbers and dates for PHP 8.1, 8.0 and 7.4 were queried directly from the php.net releases API on 22 October 2026. The NCSC-NL entry count, the QNAP rows and their assessment notes, and the most recent commit were read directly from the NCSC-NL/php2shell repository and the GitHub API on the same date. The inference that Synology backported fixes into end-of-life branches is our reading of its published version strings against upstream history, labelled as analysis and not as a vendor statement; Synology’s very-low-risk assessment of its built-in PHP is carried as the vendor’s claim. No device was scanned or contacted, no exploit or proof of concept was written, obtained or run, no malformed request was sent to any system, and no third-party host was tested. Brave Search was used for discovery only.

Sources: