Een NAS voor toegang op afstand, een gepubliceerde containerpoort of een gateway die ooit tijdelijk is opengesteld: zulke diensten raken gemakkelijk uit beeld. Bij PHP2Shell tellen drie vragen: wat is bereikbaar, welke runtime verwerkt de webverzoeken en welke andere systemen kan die dienst bereiken?
De eerste twee artikelen behandelen de beveiligingssituatie rond PHP en onze reactie en inventarisatie met ondersteuning van AI. Hier gaat het om praktische controles voor bedrijven en particuliere NAS-beheerders. Een merknaam vervangt geen inventaris. Actuele firmware bewijst evenmin dat alle pakketten en draaiende containers zijn bijgewerkt.
PHP2Shell betreft de runtime die de webverzoeken werkelijk verwerkt
CVE-2026-109618 en CVE-2026-109619 kunnen uitvoering van code vóór aanmelding bij de applicatie mogelijk maken; beide krijgen een CVSS v4.0-score van 9,2. Het PHP-project publiceerde op 21 oktober 2026 de herstelde versies 8.2.35, 8.3.36, 8.4.27 en 8.5.12. Leveranciers kunnen eigen pakketten met teruggeporteerde correcties aanbieden. Het bijbehorende beveiligingsadvies is daarom bepalend, niet alleen het versienummer.
Een aanmeldpagina geeft hier niet automatisch zekerheid. Controleer de interpreter die de webverzoeken daadwerkelijk afhandelt, inclusief actieve werkprocessen. Een actuele PHP-versie op de opdrachtregel bewijst dat op zichzelf niet. Dat geldt voor gewone webservers én voor runtimes die in applicaties, appliances en images zijn meegeleverd.
Publieke bereikbaarheid omvat meer dan portforwarding
Neem IPv4 en IPv6, routerregels, UPnP, DDNS-namen, bestemmingen van reverse proxies, tunnels en via de cloud bemiddelde toegang op in de inventaris. Bepaal telkens de werkelijke toegangsroute: een publiek IP-adres is nog geen kwetsbare applicatie. Een relay van de fabrikant valt evenmin automatisch onder dezelfde aanvalsroute. Een vergeten regel kan juist een dienst bereikbaar maken die intern had moeten blijven.
Denk aan websites, CMS’en, klantportalen, hostingpanelen en interfaces voor back-up, monitoring en beheer. Hetzelfde geldt voor NAS-platforms, VoIP, camera’s, printers en besturingssystemen voor apparatuur. Apparaten zonder relevante PHP-component zijn niet automatisch door deze twee CVE’s getroffen. Hun publieke bereikbaarheid blijft wel een zinvolle beveiligingsvraag.
Synology: beoordeel besturingssysteem en pakketten afzonderlijk
Synology beperkt de impact tot bepaalde PHP-afhankelijke pakketten, waaronder Web Station, WordPress, Calendar en MailStation. De verklaring van 22 oktober noemt updates van PHP-pakketten voor DSM 7.4, 7.3 en uitdrukkelijk ook DSM 7.2, hoewel die DSM-versie het einde van de ondersteuning heeft bereikt. Voor eerdere DSM-versies adviseert de fabrikant de betrokken pakketten tijdelijk uit te schakelen.
PHP wordt via Package Center bijgewerkt; MailStation vereist daarnaast een handmatige pakketupdate. Voor het Synology-pakket PHP 7.3 vermeldt het advies geen oplossing. Het intern door DSM gebruikte PHP is volgens de fabrikant anders blootgesteld en bevat geen extern bereikbare modules. Ook de namen verdienen aandacht: het pakket IDrive van een derde partij is niet Synology Drive; Synology Drive wordt in de verklaring als niet getroffen genoemd.
Bij onofficiële DSM-installaties via XPEnology moet de combinatie van apparaat, loader, DSM en pakketten afzonderlijk worden onderzocht. Dit is geen regulier ondersteund Synology-totaalsysteem. Dat betekent niet dat updates nooit mogelijk zijn of dat iedere installatie kwetsbaar is. Onzekere onderhoudbaarheid is wel een reden om directe internettoegang te beperken en een betrouwbaar onderhoudbare omgeving te plannen.
QNAP: controleer de inmiddels gewijzigde status
Het QNAP-advies QSA-26-18 vermeldt sinds de actualisering van 24 oktober correcties voor verschillende QTS-, QuTS hero- en QuTScloud-takken. Andere genoemde applicaties staan nog op “Fixing”. Zowel “QNAP heeft nog geen patch” als “alles is opgelost” geeft dus een onjuist beeld. Het gaat om het concrete product, de versievertakking en de bijbehorende herstelde uitgave. PHP in applicaties van derden of eigen containers wordt niet automatisch door een QNAP-systeemupdate gerepareerd.
Bij containers zijn twee afzonderlijke vragen nodig
Ten eerste: is de runtime in de draaiende container hersteld? Een bijgewerkte host vervangt geen oud image. Basisimage, extra pakketten en de werkelijk actieve uitrol moeten op elkaar aansluiten. Een nieuw image in de lokale opslag helpt pas als de dienst ermee opnieuw is uitgerold en de functionele controle heeft doorstaan.
Ten tweede: welke rechten en netwerkpaden heeft de dienst? Docker-bridgenetwerken staan normaal uitgaande verbindingen toe; containers in hetzelfde bridgenetwerk kunnen onderling communiceren. Welke interne bestemmingen bereikbaar zijn, hangt onder meer af van routing en firewallregels. Een gecompromitteerde container neemt daardoor niet automatisch het hele LAN over. Gedeelde inloggegevens, onnodige hostmounts, extra privileges of een gekoppelde Docker-socket kunnen de gevolgen echter aanzienlijk vergroten. Eigen netwerken, gerichte regels voor uitgaand verkeer en minimale rechten vragen om concrete controles.
Zeven controles voor de volgende werkronde
- Toegang inventariseren: leg apparaten, applicaties, gepubliceerde poorten en bemiddelingsdiensten vast, met verantwoordelijken. Neem IPv6 en vergeten tijdelijke openstellingen mee.
- Runtimes vaststellen: inventariseer per dienst het besturingssysteem, pakketten, plug-ins en web-PHP. Controleer leveranciersadviezen en onderhoudsstatus.
- Herstellen en verifiëren: installeer geschikte updates of nieuwe images, herstart de betrokken diensten correct en controleer de werkelijk actieve versie.
- Blootstelling beperken: sluit onnodige publieke beheertoegang. Een VPN of vertrouwd beheernetwerk kan toegang beperken; ook daarachter blijven updates nodig.
- Paden en rechten testen: beperk toegang tot databases, NAS, back-ups en beheer tot wat nodig is. Wijzig regels beheerst en test daarna de legitieme applicaties.
- Sporen en herstel onderzoeken: beoordeel opvallende toegang, accounts en uitgaande verbindingen. Zorg voor onafhankelijke back-ups die tegen onbevoegde wijziging zijn beschermd en voor getest herstel; snapshots alleen zijn onvoldoende.
- Uitzonderingen opvolgen: documenteer systemen zonder beschikbare correctie met een verantwoordelijke, tijdelijke maatregel en plan voor vervanging of uitfasering.
Een patch sluit het incidentonderzoek niet automatisch af
Sophos verwijst naar een door Amazon Threat Intelligence waargenomen misbruikpoging op 17 oktober, nog vóór de publieke bekendmaking. Bij daadwerkelijk blootgestelde systemen moet eerdere activiteit daarom worden meegewogen. Een geslaagde update bewijst niet dat er voordien geen onbevoegde toegang was. Bij verdachte signalen is een geordende incidentaanpak nodig, met passende veiligstelling van sporen en gecontroleerd herstel.
PHP wijst sinds 23 oktober bovendien op een zeldzame extra situatie die afhangt van de configuratie voor sessie-uploadvoortgang. Actuele leveranciersinformatie blijft dus ook na de eerste update relevant. Algemene configuratiewijzigingen zonder inzicht in de gevolgen voor het gebruik zijn geen goede kortere route.
Wat niet publiek hoeft te zijn, hoort tot de controle niet publiek bereikbaar te zijn. Dat verkleint het aanvalsoppervlak en vervangt de correctie niet. DAXS helpt diensten in kaart te brengen, maatregelen te prioriteren en hun werking aantoonbaar te controleren. Bespreek uw concrete omgeving met ons.
Bronnen: PHP: beveiligingsmeldingen en herstelde versies · ENISA: PHP-applicaties vinden en blootstelling beperken · Synology: pakketten en DSM-versies · Synology-SA-26:14 · QNAP QSA-26-18: herstelstatus per product · Docker: eigenschappen van bridgenetwerken · Sophos: blootstelling, activiteit en incidentonderzoek · NCSC-NL: overzicht van PHP-afhankelijkheden · Red Hat: runtimes en teruggeporteerde correcties.
