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

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 effectiefste 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 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-nasapparaat. Bron: QNAP

Reacties (94)

[Jermaine]

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]

[CPM]

Het kan prima draaien, alleen moet je het niet beschikbaar maken naar internet. Enige nuance is daarin wel op zijn plek.

[R.G]

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?

[Goldwing1973]

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.

[R.G]

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?

[Goldwing1973]

Maar je draait de proxy in de docker, en die opent een “deur” naar de server die php draait, dus de docker container is gewoon veilig, en doet precies wat ‘m opgedragen wordt, stuur verkeer door.

Even een voorbeeld wat zou kunnen gebeuren, het apparaat waar PHP op draait wordt gehacked, ze downloaden een VPN cliënt, starten die en laten die verbinding maken met de hackers, vervolgens downloaden en starten ze een telnet server waar geen wachtwoord gebruikt wordt, via de VPN telnetten ze naar jouw machine waar je PHP op draait en poof ze zitten binnen je netwerk zonder verder iets met de docker container te maken te hebben.

Op het moment dat de proxy server een bug zou hebben waardoor hackers binnen zouden kunnen komen, dan is het een ander verhaal, dan zitten ze “opgesloten” in de docker container.

[Reactie gewijzigd door Goldwing1973 op 23 oktober 2026 09:10]

[R.G]

Niet mogelijjk toch? Want hoe Komen ze in aanraking met PHP uberhaupt die poorten zijn dicht? Het gaat rechtsteeeks naar docker container poort? Waar zie jij dat ze php benaderen en de docker is in isolation?

Dus hoe zetten ze telnet en VPN op zonder root rechten uberhaupt?

Als ze php exploit, gebruiken Dan krijgen ze SSH root?

[Goldwing1973]

Ik heb net geprobeerd uit te leggen hoe ze in aanraking komen met PHP, jij zet via de docker container met de PROXY de deur zelf open.

Nee, ze zullen geen rout krijgen zolang de webserver die php draait niet op root draait (Apache draait meestal op de user www-data of www met beperkte rechten) maar dan nog kan je applicaties downloaden en starten via dit lek en dan kan je proberen om de webserver te hacken vanuit binnenuit om root te bemachtigen of je gaat het netwerk afscannen op slecht beveiligde (IoT) devices.

[WargamingPlayer]

Lijst is niet up to date. Zo staan er producten op welke gisteren gewoon een patch hebben gehad.

[Ohmarinus]

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

[Sanderluc]

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]

[stefanvanvliet]

Ben benieuwd of dit ook voor het merk synology geld. Heb gisteren voor de zekerheid die van mij uitgezet.

[Mr.Analog]

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]

[Vhond]

Is er ook online een overzicht beschikbaar van welke Synology packages er gebruik maken van PHP?

[Mr.Analog]

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]

[McOrmick]

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]

[peter4209]

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 :-)

[Vhond]

Bedankt voor je input

[Craysv2]

Synology Surveillance Station ook geloof ik ?

[alexbl69]

Gebruik Hyper Backup en Surveillance Station maar er is geen PHP pakket geïnstalleerd.

[Mr.Analog]

Ik moest even zoeken waarom, maar geld voor DSM 7.2 en ouder. Zie tevens de reactie hieronder.

[Riddle007]

Photos draait voor zover ik weet op node, niet op PHP.

[Mr.Analog]

Nieuwere versies maken idd geen gebruik meer van PHP, installaties van voor DSM 7 maken wel gebruik van PHP.

[4Reload]

Hier kan je alles vinden vanuit Synology

https://www.synology.com/en-us/security/advisory/Synology_SA_26_14

[McOrmick]

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.

[McOrmick]

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]

[Vhond]

Bedankt.

[limboroger]

*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.

[DarkTemple]

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]

[Remy!!!!]

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.

[limboroger]

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.

[Remy!!!!]

Graag gedaan, ik wist het tot een uur geleden ook niet... Maar wel fijn dat we nu iig weer (een soort van) veilig zijn.

[old_spice]

Fijn, bedankt voor de tip. Wel heel raar dat Synology dit niet gewoon zelf pusht.

[Skix_Aces]

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.

[disheaver]

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.

[ASS-Ware]

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.

[wjn]

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.)

[ASS-Ware]

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?

[wjn]

Ik wel, maar miljoenen of meer gebruikers ongetwijfeld niet. Die hebben gewoon 1 netwerk en kunnen alle apparaten elkaar en internet naar lieve lust bezoeken.

Ander topic, ik moet nog uitzoeken of mijn camera's ook (een versie van) php gebruiken voor de interface. IP-Camera's die ik al ongeveer 10 jaar heb, krijgen sowieso geen updates meer. Alhoewel ze op een apart VLAN zitten (en inderdaad op poort en ip niveau met de NAS kunnen connecten), blijft het toch een risico. Je zou haast teruggaan naar domme coax camera's...

[NBK]

Tweakers kunnen dat meestal wel in hun netwerk maar er zullen zat mensen zijn die net aan weten hoe ze een poort moeten forwarden of die UPnP gebruiken om van buitenaf bij hun camara's te komen.

Hoeveel van dit soort apparatuur zal kwetsbaar zijn? Gaat niet alleen om NAS en camara's maar alles met een ethernet stekkertje of wifi.

[Reactie gewijzigd door NBK op 23 oktober 2026 12:25]

[slijkie]

Heb er tailscale op draaien, zonder tailscale is de NAS niet benaderbaar. In mijn geval een QNAP.

[DeFeCt]

https://community.synology.com/enu/forum/18/post/231457

[phubert]

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.

[Geim]

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/

[Gunner]

Wat een overdreven sensatiestuk. Daarbij wordt vanuitgegaan dat als je een website draait op je synology je ook gelijk een PHP-probleem hebt.

[Geim]

Tsja, hij probeert zichzelf natuurlijk te verkopen en daar kun je gewoon aan voorbij lezen, maar wat interessanter is of hij een oplossing aanbiedt.

[spaceboy]

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.

[FiberSam]

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.

[pOZOR jED]

Ook zonder PHP een top advies!

[spaceboy]

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.

[The Zep Man]

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]

[phubert]

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!

[CPM]

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]

[jotheman]

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"

[R.G]

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?

[CPM]

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.

[R.G]

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?

[CPM]

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]

[R.G]

Thx

[p0linskie]

Voor mensen met truenas die zich dit nu ook afvragen. Truenas webpagina gebruikt geen php


https://security.truenas....tatements/php2shell-2026/

[Krulliebol]

Maar dan kun je er alsnog diensten op draaien die wel php gebruiken.

[p0linskie]

Dat is correct

[SilentDecode]

Kijk! Goed om te weten. Mijn QNAP draait inderdaad TrueNAS.

[!GN!T!ON]

Ik mag toch hopen dat je die pagina niet zo open aan het internet hebt hangen, of het nu wel of geen PHP gebruikt.

[p0linskie]

Nee, maar ik weetdat er genoeg hobbyisten zijn die truenas community editie gebruiken die het wellicht wel hebben. Bandaar dat ik dit heb opgezocht. Ik heb hem zelf achter een vpn hangen😉

[!GN!T!ON]

[Sonicfreak]

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

[PsiTweaker]

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]

[Racer89]

Toevallig vorige maand een QNAP erbij gepakt. Ik kon eigenlijk niet echt op internet vinden of deze nu veilig is door direct toegang te geven bijvoorbeeld via een poort open zetten of de VPN wat er standaard bij zit. Op de meeste sites wat ik kon vinden werd het afgeraden om te gebruiken. Ik heb dit dus ook niet gedaan, en gebruik deze via een eigen VPN. Achteraf ook een goede keuze geweest.

Wat mij hier persoonlijk aan opvalt, is dat er telkens van alle fabrikanten wordt gecommuniceerd dat er een lek is, of dat het niet veilig is. Echter als het probleem is opgelost vind je dat nooit ergens duidelijk terug. Ik heb zelf geen ICT achtergrond, en ik vind de afweging maken wat nu wel of wat nu niet veilig is best moeilijk soms. Je probeert het allemaal zo veilig mogelijk te maken. Alleen is het op deze manier best ingewikkeld soms.

[Meneer Den Uyl]

Altijd updaten, dan zit je goed.

[Rallye]

Wel bijzonder dat QNAP dit als “critical” beoordeelt maar niet even een mail stuurt…….

[ChiLLeR]

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.

[WargamingPlayer]

De packages voor Synology staan gewoon klaar.

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

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

[ChiLLeR]

Ik zie het... maar in de Package Center van DSM staat geen optie 'update', daar staat gewoon nog 'Nieuwste online versie: 8.4.19'...

[WargamingPlayer]

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]