Home   2026-10-22 19:56:51

←

QNAP adviseert gebruikers nassystemen van internet te halen vanwege PHP-gaten

Original article

De twee kritieke kwetsbaarheden in PHP die woensdag openbaar zijn gemaakt raken niet alleen websites, maar ook nasapparaten. Fabrikant QNAP adviseert gebruikers een dag nadat PHP2Shell uitkwam hun nassystemen te ontkoppelen van internet. QNAP werkt aan updates voor zijn software.

Totdat fixes voor QNAP-producten beschikbaar zijn, is het volgens de leverancier het beste om apparaten offline te houden. Dat is 'de meest effectieve bescherming', stelt QNAP in een beveiligingsadvies van donderdag 22 oktober. In dat bericht geeft het bedrijf ook tips om blootstelling aan de twee grote PHP-gaten te beperken. Aanvallers kunnen daarmee systemen overnemen. De aangereikte stappen verhelpen de kwetsbaarheden niet, waarschuwt QNAP.

Ontkoppelen en deels uitschakelen

Het bedrijf adviseert klanten is om hun nasapparaten te ontkoppelen van internet. Daarbij moeten ze ook portforwarding in hun routers uitschakelen, Universal Plug and Play (UPnP) op nassystemen uitzetten, de link met clouddiensten van QNAP uitschakelen en draaiende onlinediensten op nasapparaten depubliceren in myQNAPcloud. Toegang tot nasapparaten kan nog wel via een virtual private network (vpn), aldus QNAP.

Naast bovenstaande tips kunnen gebruikers ook de toegang beperken tot alleen vertrouwde netwerken. Verder is het verstandig om op PHP gebaseerde diensten en apps op QNAP-producten tijdelijk stop te zetten. Die laatste stap beschermt de webbeheerinterface echter niet, geeft QNAP aan.

'Meteen installeren'

Het bedrijf werkt nu aan updates voor de software in zijn apparaten. Het gaat onder meer om nassystemen, clouddiensten voor nasback-up, QNAP's cloudapp voor het delen van notities, en opslagapparaten voor videosurveillancecamera's. Patches voor PHP kwamen gistermiddag uit. QNAP komt 'zo snel mogelijk' met updates voor zijn opslagsoftware, maar noemt geen tijdspad. Klanten moeten de fixes na de release meteen installeren.

TS-h686 NAS-apparaat. Bron: QNAP
TS-h686-nasapparaat. Bron: QNAP

Door Jasper Bakker

Nieuwsredacteur

Feedback • 22-10-2026 12:43
76 • submitter: thomskipsp

22-10-2026 • 12:43

76

Submitter: thomskipsp

Lees meer

Reacties (76)

Niet alleen QNAP, maar vele andere merken van hardware die bij jou en mij thuis kan staan worden genoemd in deze repo van het NCSC. Zeker het lezen waard, of beter nog, om het toe te voegen aan dit of een los artikel?

https://github.com/NCSC-NL/php2shell/blob/main/software/software_list.md

[Reactie gewijzigd door Jermaine op 22 oktober 2026 13:39]

Het kan prima draaien, alleen moet je het niet beschikbaar maken naar internet. Enige nuance is daarin wel op zijn plek.
Andere vraag, als je dan een reverse proxy op je nas laat draaien en deze beschikbaar maakt via 443 maar reverse proxy draait in een docker op de nas ben je dan ook de ... ?

Of is dit wel veilig?
Ik zou zeggen, nee, want de php applicatie en de uitvoer ervan gebeurd nog steeds op de NAS.

Een proxy is precies wat z’n naam is, hij stuurt door.
Hmm wat nu ? Denk je echt dat php dan gekraakt wordt en ze dan toegangspoort vrij zijn?

Volgens mij is die docker Isolatie en niks met php te maken?
Lijst is niet up to date. Zo staan er producten op welke gisteren gewoon een patch hebben gehad.
Hoe makkelijk kan die PHP2Shell uitgebuit worden? Zijn er al tweakers die dit bij hun eigen software hebben geprobeerd? Dit geeft mij enigszins geruststelling, of niet…

Ik zelf kwam niet zo ver door een te strict ingestelde safeguards van Claude op “cyber”. En terecht. Dus ik wacht de resultaten wel af…

De vraag is of dit wel ethisch is om te vragen, gezien de ernst van het lek. En onveilige software dat op grote schaal nog ergens kan draaien op bijvoorbeeld mensen hun homelabs…

Ik zat zelfs al te denken of er misschien mensen zijn die straks doormiddel van deze exploit mensen hun software kunnen patchen op afstand, of ervoor kunnen zorgen dat de exploit niet uitgebuit kan worden. Misschien ook niet ethisch, maar ik was wel benieuwd…

[Reactie gewijzigd door Sanderluc op 22 oktober 2026 15:05]

Met de kanttekening dat dit gaat over 'potentieel' problematisch. Zoals in de titel van de pagina:
List of software with PHP dependency potentially affected by php2shell CVEs
Ben benieuwd of dit ook voor het merk synology geld. Heb gisteren voor de zekerheid die van mij uitgezet.
DSM zelf niet, maar er zijn installaties binnen packets die wel PHP gebruiken. Als je deze hebt geinstalleerd dat zijn deze kwetsbaar. Je kunt package center checken en kijken welke geinstalleerd staat.

*Hyper back-up gebruikt bijvoorbeeld PHP

[Reactie gewijzigd door Mr.Analog op 22 oktober 2026 12:58]

Is er ook online een overzicht beschikbaar van welke Synology packages er gebruik maken van PHP?
Kon ik zo helaas niet vinden, maar de obvious ones zijn natuurlijk:
  • Web Station
  • PHPMyadmin
  • Wordpress
Maar minder logische applicaties zijn
  • Calender
  • Contact*
  • Photos*
  • Mail
  • en dus Hyper Back Up*
Dit is te checken door te kijken wat geinstalleerd staat in package center kun je zoeken op PHP. Als je klikt op uninstall geeft synology aan welke applicatie hier van afhankelijk zijn. Als hier een installatie zichtbaar is weet je iedergeval zeker dat je het op het systeem hebt staan.

*Aanvulling: voor DSM 7.2 en ouder, Photo's DSM7.0 en ouder

[Reactie gewijzigd door Mr.Analog op 22 oktober 2026 14:47]

Er staan bijgewerkte PHP packages klaar voor 8.2,8.3 en 8.4: https://www.synology.com/en-global/support/download/DS918+?version=7.4#packages
7.4 staat er nu nog niet bij.
edit:
PHP 7.4 is ook bijgewerkt, maar voor DSM 7.2. Lijkt niet beschikbaar voor DSM 7.4.

[Reactie gewijzigd door McOrmick op 22 oktober 2026 14:43]

Weet iemand een reden waarom deze nog niet via package center beschikbaar zijn?

Je kan ze natuurlijk handmatig downloaden en installeren, maar via package center bereikt Synology natuurlijk veel meer gebruikers/apparaten. En het is minder werk :-)
Bedankt voor je input
Synology Surveillance Station ook geloof ik ?
Gebruik Hyper Backup en Surveillance Station maar er is geen PHP pakket geïnstalleerd.
Ik moest even zoeken waarom, maar geld voor DSM 7.2 en ouder. Zie tevens de reactie hieronder.
Photos draait voor zover ik weet op node, niet op PHP.
Nieuwere versies maken idd geen gebruik meer van PHP, installaties van voor DSM 7 maken wel gebruik van PHP.
Niet alles; ze zetten er niet bij dat de gepatchte PHP packages via https://www.synology.com/en-us/support/download verkregen moeten worden aangezien ze nog niet zijn bijgewerkt via de DSM Package Manager.
Zeker; hier.
Affected Products
Product Severity Fixed Release Availability

Synology Calendar Critical Upgrade to 3.0.4-21435 or above.
Mail Station Critical Upgrade to 30000002.3.19-20333 or above.
PHP 7.3 Critical No fix will be provided as this version has reached end of life.
PHP 7.4 Critical Upgrade to 7.4.33-0131 or above.
PHP 8.0 Critical Upgrade to 8.0.30-0122 or above.
PHP 8.1 Critical Upgrade to 8.1.34-0120 or above.
PHP 8.2 Critical Upgrade to 8.2.35-0171 or above.
PHP 8.3 Critical Upgrade to 8.3.36-0051 or above.
PHP 8.4 Critical Upgrade to 8.4.27-0051 or above.
edit:
Voor PHP 8.x (DSM 7.x) zijn inmiddels packages gereleased via https://www.synology.com/en-global/support/download/ ... Voor DSM 7.2 is ook PHP 7.4 bijgewerkt.

[Reactie gewijzigd door McOrmick op 22 oktober 2026 14:42]

*Hyper back-up gebruikt bijvoorbeeld PHP
Ligt er kennelijk aan op welke versie van DSM je zit.

Hyperbackup gebruikt in elk geval PHP 7.4 wanneer je op DSM 7.2.xx zit. Ik wilde deze legacy PHP verwijderen kreeg de melding dat Hyperbackup dan ook zou verdwijnen.

Toen ik gisteren mijn modernste Synology opwaardeerde naar DSM 7.4.1 werd PHP 7.4 vanzelf verwijderd na de verplicht update van Hyperbackup.

Mijn oudere Synology kan niet verder dan DSM 7.1 maar heeft geen Hyperbackup nodig.
Raar. Net nog gekeken, maar ik heb php niet geinstalleerd staan op mijn Synology, maar gebruik wel Hyper backup. Is DSM 7.4.xx


Zie nu dat je hetzelfde had ontdekt, namelijk afhankelijk van welke DSM versie je hebt.

[Reactie gewijzigd door DarkTemple op 22 oktober 2026 13:31]

Geen idee hoe oud je 'oudere' Synology is, maar heb je al gekeken of je de update via hun site kan downloaden?
Via DSM - Configuratischerm - bijwerken, kon ik niet verder dan DSM 7.1, maar via de site kwam ik erachter dat ik gewoon DSM 7.4 kan downloaden en installeren.
Dank voor de tip! Ik zie het inderdaad dat mijn DS918+ via https://www.synology.com/nl-nl/support/download ook gewoon nog DSM 7.4.1 ondersteunt, terwijl via de automatische update deze niet wordt aangeboden en blijft steken op DSM 7.1.
Graag gedaan, ik wist het tot een uur geleden ook niet... Maar wel fijn dat we nu iig weer (een soort van) veilig zijn.
Als je er remote niet bij kan ben je in principe al beschermd. Mijn synology draait volledig lokaal, en ik kan er alleen remote bij via een VPN. Is sowieso een stuk veiliger, ongeacht deze bug of niet.
Uiteraard is dit veiliger, maar ook lokaal heb je nog steeds wel risico. IoT devices die gecomprimeerd zijn maar wel toegang hebben tot de NAS, een bekende die je wifi code heeft.
Uiteraard is dit veiliger, maar ook lokaal heb je nog steeds wel risico. IoT devices die gecomprimeerd zijn maar wel toegang hebben tot de NAS, een bekende die je wifi code heeft.
IOT devices of gasten met toegang tot je NAS is sowieso vragen om problemen.
Camera's??

Synology Surveillance Centre maakt daarmee connectie.

(Voor de duidelijkheid, in mijn geval zitten camera's in een apart VLAN zonder internet toegang en alleen de Synology [op IP] kan gegevens opvragen. De camera's kan dus niet zelfstandig contact maken met andere apparaten, behalve in hetzelfde VLAN. Ik kan me voorstellen dat niet iedereen zoiets opzet, als ze Surveillance Centre gebruiken.)
Camera's??
Synology Surveillance Centre maakt daarmee connectie.
Die zet je toch in een apart VLAN en vervolgens open je alleen de poorten die nodig zijn om de camera's te laten connecten met de NAS?
Heb er tailscale op draaien, zonder tailscale is de NAS niet benaderbaar. In mijn geval een QNAP.
Gisteravond kreeg ik een melding dat er een update klaar stond om mijn Synology te updaten. In deze update zaten veiligheid updates maar geen verwijzing naar de PHP CVE's.
Marius heeft daar een stukje over geschreven. Geen flauw idee of dit een goed advies is. Ik heb de webservices uitgezet.

https://mariushosting.com/synology-mitigating-php2shell-cve-2026-109618-cve-2026-109619/
Wat een overdreven sensatiestuk. Daarbij wordt vanuitgegaan dat als je een website draait op je synology je ook gelijk een PHP-probleem hebt.
Tsja, hij probeert zichzelf natuurlijk te verkopen en daar kun je gewoon aan voorbij lezen, maar wat interessanter is of hij een oplossing aanbiedt.
Het ligt er helemaal aan wat jij hebt draaien óp die Synology. Het boeit geen kont of www.synology.com wel of niet PHP gebruikt. Als jij iets op je NAS hebt draaien waar php wordt gebruikt heb je dat probleem. En of die NAS is gebouwd met technologie van TrueNAS, oom Hans, de handige buurjongen of Synology is echt niet relevant.
En dat klopt dus niet. Je hebt alleen een probleem als je PHP app WAN facing is. Dus bijvoorbeeld Synology Hyperbackup DSM <=7.2 gebruikt wel PHP, maar als die app niet bereikbaar is vanaf WAN heb je geen probleem. Dat zegt Synology zelf ook. Het gaat in de praktijk om Synology Webserver, waar vaak PHP bij gebruikt wordt. Maar ook MailStation.
Ook zonder PHP een top advies!
Precies dit. Los van elke soort wel of niet gevonden vulnerability: denk na over wat je waarom online hebt staan waar je vanaf buitenshuis bij wilt kunnen. Als je écht een usecase hebt, werk dan met VPN.

Je hoeft hiervoor niet te wachten tot er een kwetsbaarheid ergens gevonden wordt.
Als je écht een usecase hebt, werk dan met VPN.
VPN, WAF met hardened authenticatieportaal ervoor, mTLS, ...

Het belangrijkste is dat, buiten hardened zaken om, zo min mogelijk direct blootgesteld wordt aan het internet. Zo is er geen reden om bijvoorbeeld een webmail client direct op het internet aan te bieden. Dat kan ook achter een hardened authenticatieportaal.

[Reactie gewijzigd door The Zep Man op 22 oktober 2026 14:20]

QNAP ligt al jaren onder vuur als het gaat om veiligheid van apparaten aangesloten rechtstreeks op internet. In mijn ervaring met QNAP, vooral het geen wat er voor moet zorgen dat je veiligheid zou krijgen "QuFirewall" is diep teleurstellend. Om uiteindelijk veiligheid te bereiken heb ik "ondergronds" in de CLI via autorun.sh de iptables zelf moeten laden.

NAS van buiten bereiken? VPN!
Voor mensen met truenas die zich dit nu ook afvragen. Truenas webpagina gebruikt geen php


https://security.truenas....tatements/php2shell-2026/
Maar dan kun je er alsnog diensten op draaien die wel php gebruiken.
Kijk! Goed om te weten. Mijn QNAP draait inderdaad TrueNAS.
Synology is aan het onderzoeken of hun producten ook vatbaar zijn en werkt aan updates.

PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 | Synology Community
Het bedrijf adviseert klanten is om hun nasapparaten te ontkoppelen van internet. Daarbij moeten ze ook portforwarding in hun routers uitschakelen, Universal Plug and Play (UPnP) op nassystemen uitzetten, de link met clouddiensten van QNAP uitschakelen en draaiende onlinediensten op nasapparaten depubliceren in myQNAPcloud.

Ontkoppelen van internet: juist.

Port forwarding uitschakelen: euh what? Want? Als er niets meer draait hoeft dat dus niet.

UPnP uitzetten: dat had je al eerder moeten doen.

Link met clouddiensten uit: euh, waarom dan?

Draaiende onlinediensten op nasapparaten depubliceren in myQNAPcloud: ?????

Ik begrijp dat je alle diensten die PHP gebruiken op je NAS en die beschikbaar zijn gemaakt aan internet moet uitzetten, die zijn kwetsbaar. Maar waarom die andere dingen dan? Uitgaand verkeer is niet kwetsbaar. Alles wat naar een server praat van Qnap is uitgaand verkeer. Wat mis ik hier?

[Reactie gewijzigd door CPM op 22 oktober 2026 14:03]

Dit dus idd, vreemde aanbeveling.

Meer on de trant van: "zet voor de zekerheid maar ff alles uit, dan weten we iig zeker dat er geen risico is"
Waarom upnp uitzetten, dat is ontzettend handig ga jij dan in je router allemaal forwads voor elke game console lopen doen/

Upnp is tegenwoordig veilig zolang je weet wat je doet en nieuwe versies zijn best oke toch?
Die "handigheid" komt met risico's. Je moet het maar willen, elke willekeurig device kan gaten schieten in je firewall zonder enige controle. Mij niet gezien, hoe makkelijk ook, ik maak die groepjes + regel(s) wel aan desnoods in hun eigen vlan.
Ja ik snap het maar in een family huishouden is het niet te doen?

Dnek aan tieners die games Willen spelen, consoles, apps op mobiel.

Moet Ik Dan voor Elke app game service handmatig port forwarding doen naar dat ene ip en die ips wissleen?

Dus het is onbegonnen week in praktijk? Is hier geen oplossing voor?
Mijn advies: Inventariseer eerst eens welke devices UPnP écht nodig hebben en waarom dan precies. Welke functionaliteit werkt niet als je het uit zet (ja gewoon uitzetten zonder de rest te informeren). Je noemt namelijk een hele hoop dingen op waarvan ik mij niet kan voorstellen dat ze UPnP nodig hebben. En de oplossing is simpel, apart vlan voor die meuk die het wel nodig heeft en/of aparte rules.

Moet Ik Dan voor Elke app game service handmatig port forwarding doen naar dat ene ip en die ips wissleen?

Zie mijn antwoord hierboven. Er bestaat ook zoiets als dhcp reservations, groepen in een firewall, groepen voor poorten etc.

Maar goed, je moet je er wel in verdiepen. En als je functies aanzet waarvan er genoeg artikelen zijn op internet die het afraden dan moet je jezelf afvragen of je vertrouwt op "maar met een laatste versie ben je veilig toch", en dan met name UPnP.

I rest my case. Succes!

[Reactie gewijzigd door CPM op 22 oktober 2026 22:27]

Goed dat men daar nu duidelijkheid over schept, maar is dat niet iets te laat en had men gelijktijdig ( of direct erna i.v.m. websites down ) met de PHP-down-melding moeten acteren ?

[Reactie gewijzigd door PsiTweaker op 22 oktober 2026 14:13]

Dit leest als een headline van De Speld... Maar ze zijn serieus :?
Een NAS direct aan internet hangen is altijd een slecht idee geweest.
Wat is het verschil met iets als NextCloud? Dat is toch ook een "NAS" en dat hangt de halve wereld aan het internet.

Alles gaat en staat bij hoe goed je de voorkant hebt geregeld, en dat je snel zooi patched.
Heb na dit probleem meteen webstation uitgezet. Het duurt zo lang voordat Synology een package update doet voor php. Nu gewoon php-Apache in een docker container. Via Cloudflare tunnel erop en klaar. Kan ik zelf updaten wanneer nodig en geen expose direct naar het internet.
De packages voor Synology staan gewoon klaar.

Hier: https://archive.synology.com/download/Package

[Reactie gewijzigd door WargamingPlayer op 22 oktober 2026 14:40]

Ik zie het... maar in de Package Center van DSM staat geen optie 'update', daar staat gewoon nog 'Nieuwste online versie: 8.4.19'...
Klopt, dit zijn dan ook emergency updates voor verschillende PHP versies. Deze moet je handmatig bijwerken.

https://www.synology.com/nl-nl/security/advisory/Synology_SA_26_14

Meer informatie over specifieke packages:

https://mariushosting.com/synology-mitigating-php2shell-cve-2026-109618-cve-2026-109619/

[Reactie gewijzigd door WargamingPlayer op 22 oktober 2026 16:30]

Och, webstation kan ik toch al niet draaien omdat ik port 443 en 80 nodig heb voor mijn Swag Docker container om mijn LetsEncrypt certificaat te vernieuwen.
Aangezien het dan nodig is om tijdens het vernieuwen die 2 poorten open te hebben, mogen ze niet in gebruik zijn op de NAS.
Misschien had ik andere poorten kunnen gebruiken, want ik moet toch port forwarden, maar vond het toch niet echt veilig om Webstation te draaien op mijn NAS dus een tijd geleden eraf gegooid. Er staat nog wel PHP op dus vanavond maar even kijken wat er nog geupdate moet worden.

Om te kunnen reageren moet je ingelogd zijn