The two critical PHP bugs we wrote about last week turned out to be a NAS problem. Your NAS runs PHP whether or not you ever thought of it that way, and the vendors have landed in very different places.
Synology shipped fixes. QNAP, as of October 23, had not given a date.
Where each vendor is
Synology (advisory SA-26-14, October 22) has fixes in Package Center for the PHP 7.3 to 8.4 packages, Mail Station and Synology Calendar. It rates the PHP built into DSM itself as very low risk, on the grounds that it has no externally accessible functionality. The exposure is the packages that serve PHP, not the base OS.
One asterisk: PHP 7.3 is not getting fixed, because it’s past end of support. If something on your box still runs it, the answer is to move off it, not to wait.
QNAP (QSA-26-18, October 22) lists affected products as “Fixing” with the fixed version “To be announced”. QNAP says it has no reports of exploitation targeting its products.
The detail that matters on QNAP: stopping the built-in web server does not protect the admin interface. The obvious mitigation doesn’t cover the thing you most want covered.
Asustor (AS-2026-023, October 22) is “Ongoing” across ADM 4.1 to 4.3 and 5.0/5.1, and recommends stopping the Web Server until a fix exists. TerraMaster said on October 22 it was investigating, after an owner found PHP 7.4.33 serving the admin interface on an F2-425.
The timeline is tight
PHP released its fixes at 14:00 UTC on October 21. Vendor advisories landed on the 22nd. Amazon’s honeypot recorded the earliest known exploitation attempt on October 17, four days before the patches existed.
So the window where attackers had this and defenders didn’t is a matter of record rather than theory, and the vendors who are still writing their fix are inside it now.
What to do, by box
Synology: open Package Center and update everything PHP-related, plus Mail Station and Synology Calendar if you run them. Check whether anything still depends on PHP 7.3.
QNAP, Asustor, TerraMaster: there is no patch to apply yet, so this is entirely about reachability. QNAP’s own guidance is the right shape and worth following whoever made your NAS:
- Turn off port forwarding and UPnP on your router.
- Stop myQNAPcloud Link and any public services you don’t need.
- Restrict the admin ports, 8080 and 443 by default, to your local network or a VPN.
- Use a VPN for remote access rather than exposing the admin interface.
- Stop PHP-based apps you aren’t using.
- Check QuLog Center for odd logins and run Security Center and Malware Remover. Go back through logs to at least October 17.
Note that QNAP’s own first recommendation is a VPN rather than its remote access product. We published a guide on exactly that this week, and it is a strange feeling to have the vendor’s advisory agree with it this precisely.
Everyone: PHP inside Container Station or Docker is outside your vendor’s update scope entirely. Those containers are yours to patch, and nobody is going to send you an advisory about them.
Where we land
This is the appliance problem again, and it’s the second time this month we’ve landed on it.
You didn’t choose to run PHP. It arrived inside a product sold as something you set up once and ignore, bundled with a web interface you use twice a year. When a critical bug lands in it, you can’t patch it yourself, because the vendor owns that layer. You wait.
Synology’s position looks good here, and the reason is mostly architectural: it kept the OS’s PHP away from anything externally reachable, so a critical PHP bug became a package update rather than an emergency. That’s a design decision made years before this bug existed, paying off now.
QNAP’s users are waiting on a date. The only lever they have is the one that was always available, which is making sure the thing isn’t reachable in the first place.
Sources: XenoSpectrum’s comparison of the vendor advisories, AppleInsider on the patch gap.