PHP2Shell op Synology: Hoe we zes sites in één dag hebben gepatcht

PHP2Shell PHP2Shell is de naam die de industrie heeft gekozen voor CVE-2026-109618 en CVE-2026-109619, twee kritieke kwetsbaarheden in de PHP-engine zelf die het mogelijk maken om op afstand code uit te voeren zonder authenticatie. Details lekten uit op 20 oktober 2026, een dag voor de gecoördineerde openbaarmaking, en het PHP-project bracht op 21 oktober noodupdates uit. Omdat de bug zich in de interpreter bevindt en niet in een applicatie, heeft het patchen van WordPress, Joomla of MediaWiki geen enkel effect. De enige echte oplossing is een nieuwe PHP-build. We beheren zes openbare WordPress-sites op Synology-hardware en PHP2Shell betekende dat ze allemaal in dezelfde week opnieuw moesten worden gebouwd. Deze handleiding beschrijft wat de bug precies inhoudt, hoe je deze kunt patchen op DSM via Package Center, hoe je ermee omgaat als je site in een container draait, en de ongemakkelijke vergelijking tussen wat Synology heeft geleverd en wat andere NAS-leveranciers tot nu toe hebben bereikt.

SynoPower Club-punt:Onze zes sites werden binnen één werkdag na de publicatie van het PHP2Shell-advies gepatcht. Dit was niet te danken aan heldendaden, maar aan het feit dat Synology op dezelfde dag als het advies gecorrigeerde pakketten publiceerde. Synology-SA-26:14 werd op 22 oktober uitgebracht met de status 'Opgelost' en een complete tabel met gecorrigeerde versies tot en met PHP 7.4. Op dezelfde dag publiceerde QNAP QSA-26-18 met de status 'Wordt nog bekendgemaakt' bij elke gecorrigeerde versie. ASUSTOR reageerde hierop door de verouderde PHP-versie uit App Central te verwijderen in plaats van deze te patchen. Als u een openbare website op een NAS host, is dit verschil geen marketingtruc. Het is het verschil tussen een pakket bijwerken en uw site offline halen terwijl u wacht.

Wat is PHP2Shell en waarom is het anders?

PHP2Shell is niet één enkele bug, maar een cluster van gerelateerde geheugenveiligheidsproblemen in de manier waarop PHP geheugen vrijgeeft na een verzoek dat niet meer voldoende geheugen heeft. PHP gebruikt longjmp() Om fatale fouten, waaronder geheugenproblemen, te voorkomen, slaat deze sprong de opschooncode over die de engine normaal gesproken terug zou brengen naar een bekende staat. Een deel van die staat is globaal en blijft behouden bij het volgende verzoek dat door hetzelfde workerproces wordt verwerkt.

CVE-2026-109618 betreft het geheugenprobleem. Een speciaal geconstrueerde HTTP-aanvraag overschrijdt de geheugenlimiet terwijl de aanvraaggegevens nog maar gedeeltelijk zijn geïnitialiseerd, waardoor de opschoonroutine structuren doorloopt die nooit zijn voltooid. CVE-2026-109619 betreft het probleem van gebruik na vrijgave: globale statusinformatie die verwijst naar vrijgegeven aanvraaggeheugen kan worden gelezen door een latere aanvraag op dezelfde worker, waardoor de bug leidt tot code-executie of het openbaar maken van geheugen.

Twee eigenschappen maken PHP2Shell erger dan de gebruikelijke PHP-waarschuwing. Ten eerste is het pre-authenticatie. Beide kwetsbaarheden treden op voordat er authenticatie op applicatieniveau plaatsvindt, dus een loginmuur, een lidmaatschapsplugin of een beheerderswachtwoord biedt geen bescherming. Ten tweede lekt de variant met geheugenlekken het geheugen van workerprocessen, waardoor een PHP-worker op een WordPress-site databasegegevens, API-tokens en betaalsleutels kan opslaan. Een succesvolle leesbewerking hoeft niet eens tot code-executie te leiden om je week te verpesten.

De twee PHP2Shell CVE's kregen een CVSS-score van 9,2 op CVSS v4.0 van het PHP-beveiligingsteam. Synology gaf ze een score van 9,8 op CVSS v3.1 in hun eigen advies. Verschillende schalen, dezelfde conclusie. De meldingen over exploitatie zijn gemengd: watchTowr meldt pogingen tot aanvallen op hun honeypot-netwerk, terwijl Bitdefender op het moment van schrijven niets in hun telemetrie heeft gerapporteerd en QNAP aangeeft geen meldingen te hebben ontvangen van exploitatie gericht op QNAP-producten.

PHP2Shell versus een normale WordPress-exploit

De meeste beveiligingslekken op openbare WordPress-sites zitten in plugins. Het patroon is bekend: een plugin bevat een defect REST-eindpunt, een scanner vindt het, je werkt de plugin bij en het lek is gedicht. PHP2Shell doorbreekt deze gewoonte volledig, waardoor het controleren van plugins hier overbodig is.

Aspect	Typische plugin CVE	PHP2Shell
Waar het insect leeft	Applicatiecode (plugin of thema)	De PHP-interpreter zelf
Wie kan het in gang zetten?	Vaak is een abonnee- of beheerdersrol vereist.	Niemand. Pre-authenticatie, voordat de applicatielogica wordt uitgevoerd.
Helpt het om WordPress bij te werken?	Meestal wel	Nee. Core- en plugin-updates zijn irrelevant.
Houdt een WAF (Wife Acceptance Factor) daar een einde aan?	Meestal geldt dat zodra een regel bestaat	Gedeeltelijk. Regels voor de vorm van verzoeken missen het OOM-pad.
Wat lost het probleem nu eigenlijk op?	Plugin-update	Een nieuwe PHP-build, verder niets.
Explosieradius	Eén website, één functie	Alle PHP-sites op de server, allemaal tegelijk.

Die laatste regel is de reden waarom PHP2Shell een volledige werkdag werd in plaats van een middagje. Een enkel gedeeld PHP-pakket op een NAS kan achter een dozijn virtuele Web Station-hosts staan, en een enkele containerimage kan de basis vormen voor meerdere websites. Patchen gebeurt niet per website, maar per runtime, en je moet alle runtimes inventariseren voordat je kunt zeggen dat er iets is gedaan.

Hoe u kunt zien of uw NAS is blootgesteld

Om te bepalen of PHP2Shell een kwetsbaarheid veroorzaakt, moet je eerst twee verschillende vragen onderscheiden. Bevat de server een kwetsbare PHP-build en is die build bereikbaar vanaf internet? Synology maakt dit onderscheid expliciet: DSM levert een interne PHP-component die door het besturingssysteem wordt gebruikt, en Synology stelt dat deze geen extern toegankelijke modules bevat en daarom geen kwetsbaar aanvalsoppervlak heeft. Het risico dat aan die component wordt toegekend is minimaal, en de patch is gepland voor een latere DSM-release, zodat kwetsbaarheidsscans deze component niet meer zullen detecteren.

De pakketten die relevant zijn voor PHP2Shell zijn de pakketten die PHP beschikbaar maken voor het web. Synology noemt Calendar, IDrive, Joomla, KodExplorer, MailStation, MediaWiki, phpMyAdmin, vtigerCRM, Web Station en WordPress. Als je een van deze pakketten hebt geïnstalleerd en bereikbaar is, val je binnen het toepassingsgebied.

Controleer de versies direct in plaats van te vertrouwen op een dashboard. In Package Center wordt de versie van de geïnstalleerde PHP-pakketten weergegeven op de tegel, en de updatemelding vermeldt de beoogde build. Vraag het vanuit een shell rechtstreeks aan de runtime:

# Synology PHP-pakket (pas het pad aan naar de versie die u gebruikt) /volume1/@appstore/PHP8.2/usr/local/bin/php -v # Een gecontaineriseerde site docker exec php -v

De reden om aan te dringen op php -v Bij het controleren van PHP2Shell blijkt dat elk ander signaal onjuist is. De build-output kan succes melden terwijl een gecachede laag wordt hergebruikt, een dashboard kan een pakket als actueel weergeven terwijl de actieve worker dat niet is, en een HTTP-antwoordheader kan door een CDN worden gestript voordat je deze ooit te zien krijgt. Twee van onze zes sites werden door hun beheerschermen als gezond gerapporteerd, terwijl ze nog steeds een ongepatchte interpreter gebruikten.

PHP2Shell patchen op Synology in 4 stappen

Voor een Web Station-site op DSM is de volledige PHP2Shell-oplossing een update van het Package Center. Synology publiceert PHP-beveiligingsupdates voor DSM 7.4, 7.3 en 7.2, en na de PHP-pakketupdates worden de afhankelijke pakketten opnieuw opgestart, wat het probleem oplost. Mail Station is de gedocumenteerde uitzondering en vereist een eigen handmatige update.

De bovenstaande schermafbeelding is afkomstig van een van onze eigen machines, de ochtend na het PHP2Shell-advies. Merk op dat het paneel 'Wat is nieuw' de upstream-versie direct vermeldt, zodat u de build-achtervoeging Synology kunt vergelijken met de PHP-release zonder te hoeven gissen. Synology Calendar verschijnt in dezelfde update-lijst onder versie 3.0.4-21435, wat precies de versie is waar het advies naar verwijst.

Een valkuil in PHP2Shell die het vermelden waard is voor Web Station-gebruikers: een DSM-machine kan meerdere PHP-branches tegelijk geïnstalleerd hebben, en elke virtuele host is gekoppeld aan een profiel. Het bijwerken van het standaardprofiel helpt niet als een site aan een andere branch is gekoppeld. Inventariseer eerst de profielen, werk ze allemaal bij en controleer vervolgens de koppeling van elke site onder Webservice.

Welke DSM-pakketten worden beïnvloed?

De melding over Synology op PHP2Shell is beperkter dan de paniek suggereerde. Alleen systemen die bepaalde PHP-afhankelijke pakketten gebruiken, worden getroffen, en Synology Drive is daar expliciet niet één van. IDrive staat wel op de lijst, maar is software van derden.

• Webgericht en met de hoogste prioriteit. Web Station, WordPress, Joomla, MediaWiki, vtigerCRM, KodExplorer en phpMyAdmin. Deze bieden PHP aan iedereen die ze kan bereiken.
• E-mail en agenda. Mail Station moet handmatig worden bijgewerkt na het PHP-pakket. Synology Calendar heeft een eigen vaste buildversie 3.0.4-21435.
• De interne component van de DSM. Aanwezig maar niet extern bereikbaar, patch uitgesteld naar een latere DSM-release, risico beoordeeld als minimaal door Synology.
• Containers zijn niet afgedekt. Een PHP-runtime in Container Manager is volledig naar uw wens aan te passen. Geen enkele pakketupdate zal deze beïnvloeden, wat de meest voorkomende reden is waarom NAS-gebruikers denken dat ze klaar zijn, terwijl dat niet het geval is.

Als u nog steeds een DSM-versie gebruikt die ouder is dan 7.2, raadt Synology aan de betreffende pakketten tijdelijk uit te schakelen totdat er een gepatchte versie beschikbaar is. DSM 7.2 zelf wordt in de verklaring als 'end of life' aangemerkt, hoewel deze versie wel deze PHP-updates heeft ontvangen.

Het lastigste geval voor PHP2Shell is PHP 7.3 en ouder. Synology zal 7.3 niet repareren omdat deze branch niet meer wordt ondersteund en de ontwikkelaars van de upstream-versie helemaal niets hebben gepubliceerd voor 7.3 en eerder. Linux-distributies hebben backports uitgebracht voor sommige oudere versies, maar een PHP-pakket van Synology is geen distributiepakket. Als een website 7.3 of 5.6 nodig heeft om te draaien, komt er geen patch en zijn de enige opties om de website over te zetten naar een ondersteunde branch, deze achter een WAF te plaatsen of de website offline te halen.

Hoe eigenaren van containerwebsites omgaan met PHP2Shell

Vijf van onze zes websites draaien WordPress in Docker in plaats van Web Station, en dat is waar PHP2Shell interessant wordt, omdat Package Center je dan niet kan helpen. De runtime is wat de image bevat, en het opnieuw opbouwen van een image is niet hetzelfde als het bijwerken ervan.

De eerste PHP2Shell-fout die we tegenkwamen, en die waarschijnlijk ook andere gebruikers zal treffen, is dat bij het opnieuw opbouwen van een aangepaste image de in de cache opgeslagen basislaag opnieuw wordt gebruikt. Een niet-vastgezette VAN De tag betekent niet per se 'vers'. Een van onze images was vier dagen eerder opnieuw opgebouwd en bevatte nog steeds een PHP-build uit juli 2025, meer dan een jaar achter op de beveiligingsupdates, omdat Docker niet gedwongen was de basisimage opnieuw op te halen.

# Fout: hergebruikt stilzwijgend de lokaal opgeslagen basislaag: `docker build -t mysite .` # Juist: haalt altijd de basisimage opnieuw op: `docker build --pull -t mysite .` # Start vervolgens alleen de service die je wilt starten, zonder slapende gerelateerde services te starten: `docker compose up -d --no-deps wordpress` # En controleer wat er echt toe doet: `docker exec wordpress php -v`

De tweede PHP2Shell-fout is vervelender omdat deze een succesmelding geeft. Het doorsturen van de build-output via een pipe is nodig. staart Dit verbergt een buildfout, omdat de exitcode van een pipeline hoort bij de laatste opdracht erin. set -e wordt nooit uitgevoerd. De compose-stap maakt vervolgens de container opnieuw aan op basis van de oude image, print "Started" en je verlaat een ongepatchte site die eruitziet alsof hij net is geïmplementeerd. Controleer het buildresultaat afzonderlijk en verifieer met php -v daarna.

Twee kleine opmerkingen. Tag de oude image voordat je hem opnieuw opbouwt, want een image behoudt zijn tag en biedt je een gratis terugdraaipunt dat veel goedkoper is dan een snapshot. En verwacht niet dat een image-update de applicatie zal upgraden: het officiële WordPress image entrypoint kopieert kernbestanden alleen wanneer de document root leeg is, dus het opnieuw aanmaken van een container op een nieuwere image laat een bestaande installatie precies op dezelfde plek achter. We hebben dit bevestigd op een staging-omgeving voordat we de productieomgeving aanraakten, en de WordPress-versie is niet gewijzigd.

Waarom het uitschakelen van session.upload_progress slechts de helft van het probleem oplost

De PHP2Shell-oplossing die momenteel in omloop is voor machines die niet gepatcht kunnen worden, is om het volgende in te stellen: sessie.upload_progress.enabled = 0, En op DSM vind je dat in Web Station onder Script Language Settings, in het tabblad Core van het PHP-profiel. Het is de moeite waard om te doen. Het is geen oplossing, en het verschil is belangrijk.

Het pad voor het uploaden van sessiegegevens is slechts één van de manieren waarop het probleem zich kan voordoen. De variant waarbij geheugen wordt vrijgegeven, wordt bereikt via de normale afhandeling van multipart-verzoeken en vereist de sessiefunctie helemaal niet. Het uitschakelen van deze functie laat die mogelijkheid dus open. Het PHP-project heeft zelf aangegeven dat er geen volledige oplossingen zijn en dat updaten de enige veilige oplossing is. Imunify360 meldt dat er momenteel geen regel is die het pad voor geheugenproblemen van CVE-2026-109618 blokkeert, en Elastic merkt op dat de instelling voor het uploaden van sessiegegevens de bevestigde paden sluit, maar niet elke variant.

Je zult ook zien geheugenlimiet = -1 Er werd gesuggereerd, vanuit de logica dat de bug wordt veroorzaakt door een geheugenprobleem. Beschouw dat als een compromis, niet als een winst. Het verwijderen van de limiet op een openbare webserver verandert de ene foutmodus in een andere, en op een NAS met een gedeeld geheugenbudget zorgt het ervoor dat de workerpool de hele machine overbelast.

Edge filtering is de PHP2Shell-laag die echt iets toevoegt, omdat het onversleuteld verkeer ziet en je router niet. Cloudflare heeft beheerde regels voor PHP2Shell geïmplementeerd, AWS heeft dekking voor CVE-2026-109619 toegevoegd in versie 2.3 van de PHP-beheerde regelgroep, en Azure Front Door heeft regel 99006001 uitgebracht, die standaard is uitgeschakeld. Er bestaan communityregels voor Snort en Suricata op GitHub, maar de officiële Snort- en Emerging Threats-regelsets waren op het moment van schrijven nog niet gepubliceerd, dus een NAS-inbraakpreventiefunctie zal je hier niet redden. Het kan sowieso geen TLS-verkeer lezen.

Welke NAS-leverancier heeft daadwerkelijk een oplossing uitgebracht?

Dit is het deel van het PHP2Shell-verhaal dat van invloed zou moeten zijn op uw aankoopbeslissing. De officiële PHP-versie werd op 21 oktober uitgebracht. Hieronder ziet u de positie van de vier belangrijkste NAS-leveranciers voor consumenten en semi-professionele gebruikers de volgende dag, zoals die is overgenomen uit hun eigen adviespagina's en niet uit berichtgeving.

Leverancier	Advies	Status	Opgeloste versies gepubliceerd
Synologie	Synology-SA-26:14, 22 okt 2026	Opgelost	Ja. Elk filiaal van PHP 7,4 tot 8,4, plus kalender en poststation.
QNAP	QSA-26-18, 22 okt 2026	Repareren	Nee. Op elke regel staat: Wordt nog bekendgemaakt.
ASUSTOR	Uitfasering van Legacy PHP, 22 oktober 2026	Pensioen, geen pleister.	Nee. PHP 7, 7.3, 7.4 en 8.1 zijn verwijderd uit App Central.
UGREEN	Geen gevonden	Onbekend	Er is geen advies gevonden voor UGOS Pro.

Synology publiceerde op dezelfde dag als het advies een complete PHP2Shell-versietabel en markeerde het advies als 'Opgelost'. Een DSM-gebruiker die het las, kon diezelfde middag nog actie ondernemen: Package Center openen, op 'Bijwerken' klikken en controleren. Dat is het volledige herstelproces en daarom waren onze Web Station-machines binnen enkele minuten klaar in plaats van dagen.

QNAP publiceerde op dezelfde datum een lijst met getroffen producten, waaronder QTS 6.1.0, QTS 5.2.11 en ouder, QuTS hero h6.1.0, h6.0.x en h5.2.11 en ouder, QuTScloud c5.2.9 en ouder, Note Station 3, QNE ADRA, QVR Surveillance op ARM32-modellen en TVR OS. Al deze producten hebben de status 'Oplossen', maar er is geen definitieve versie beschikbaar. Omdat de PHP-runtime onderdeel is van de QTS-webcomponenten, is er geen apart pakket om te updaten. De oplossing moet daarom via een firmware-update worden doorgevoerd.

QNAP biedt PHP2Shell-slachtoffers in de tussentijd een lijst met maatregelen om de beveiliging te verbeteren. Het is de moeite waard om deze lijst aandachtig te lezen, gezien de aanbevelingen die erin staan: schakel port forwarding en UPnP op de router uit, verwijder myQNAPcloud-services uit het openbare netwerk, verplaats externe toegang achter een VPN, beperk de beheerpoorten tot vertrouwde subnetten, stop PHP-gebaseerde applicaties die u niet nodig hebt, schakel de ingebouwde webserver uit indien deze niet in gebruik is en controleer QuLog Center op tekenen van inbreuk. Dit is verstandig advies voor een apparaat zonder updates. Voor iedereen die een openbare website host, is het tevens een verzoek om de website offline te halen.

ASUSTOR koos een derde weg. In hun bericht van 22 oktober, getiteld "Legacy PHP Retirement Announcement", worden PHP 7, PHP 7.3, PHP 7.4 en PHP 8.1 per direct verwijderd uit App Central. Het bedrijf adviseert gebruikers om belangrijke gegevens te back-uppen en adviseert hen om voortaan alleen nog PHP 8.3 of 8.4 te gebruiken. De redenering hierachter is begrijpelijk, aangezien de ontwikkelaars alleen patches uitbrengen voor versies 8.2 en later. Het gevolg voor gebruikers die een oude PHP-applicatie draaien, is dat de runtime uit de store verdwijnt in plaats van dat er een oplossing wordt gevonden. ASUSTOR meldt bovendien niet dat er een gepatchte versie van 8.3 of 8.4 beschikbaar is. In tegenstelling tot Synology, dat wél een gepatchte versie van 7.4 (7.4.33-0131) heeft uitgebracht, juist voor de gebruikers die ASUSTOR nu wil laten migreren.

Voor UGREEN konden we geen enkel PHP2Shell-advies vinden voor UGOS Pro. De afwezigheid van een openbare verklaring is geen bewijs dat een product kwetsbaar is, en UGOS Pro levert mogelijk simpelweg geen webgebaseerde PHP-runtime mee. Maar als eigenaar is stilte geen antwoord waarop je kunt reageren, en dat is op zich ook een vorm van risico.

Dit alles maakt Synology niet perfect. Het lost PHP 7.3 niet op, het markeert DSM 7.2 als niet langer ondersteund en de interne PHP-component wordt nog steeds ingepland in plaats van gepatcht. Het punt is echter specifieker en nuttiger dan een argument over merknaam: op de dag dat een pre-authenticatiebug voor het uitvoeren van code op afstand in de PHP-engine opdook, maakte één leverancier van de oplossing een knop in Package Center, terwijl de anderen er een wachtspel van maakten.

Waar vind je meer officiële bronnen?

PHP2Shell bestaat op het moment van schrijven nog maar twee dagen en de situatie is nog in ontwikkeling, dus raadpleeg primaire bronnen in plaats van samenvattingen. Er is nog geen officiële video-inhoud van de leveranciers, dus de onderstaande lijst is documentatie en geen stapsgewijze handleiding.

• Synology-SA-26:14 Dit is de gezaghebbende versietabel. Controleer deze nogmaals voordat u de patch installeert, aangezien de adviezen worden herzien.
• De Synology PSIRT-verklaring Een lijst met de getroffen pakketten wordt opgesteld en de interne DSM-component en de uitzondering voor het poststation worden uitgelegd.
• De upstream GitHub-adviezen GHSA-w8hw-w9fx-j79w en GHSA-6wmf-4rv5-p3rp zijn gekoppeld aan het Synology-advies en beschrijven het gedrag van de engine in plaats van de vendor-package.
• QNAP QSA-26-18 Dit is de pagina waar een gecorrigeerde firmwareversie verschijnt als je QTS of QuTS Hero gebruikt. Het is de pagina die je in de gaten moet houden, niet een nieuwsartikel.
• Uw eigen pakketcentrum geeft het laatste woord over wat er is geïnstalleerd. Het advies geeft de beoogde configuratie weer, de tegel laat zien wat u daadwerkelijk hebt, en alleen dat is correct. php -v Vertelt je wat er draait.

Voor meer informatie over het draaien van openbare websites op virtuele Synology-machines, raadpleeg onze handleiding over Het verplaatsen van een Docker-stack tussen VDSM-gasten. Dit beschrijft de snapshot- en rollback-procedures die ervoor zorgden dat deze noodsituatie te overleven was.

Beperkingen en beveiligingsinformatie van PHP2Shell

Het patchen van PHP2Shell is eenvoudig op DSM, maar lastiger op alle andere platforms. Daarom is het goed om een paar beperkingen duidelijk te vermelden voordat je de klus als voltooid beschouwt.

Een update van het PHP2Shell-pakket is geen site-audit. Het updaten van PHP dicht het lek vanaf dat moment, maar als de server tussen 20 en 22 oktober via internet bereikbaar was, was dat terwijl er een werkende exploit openbaar was. Controleer de logbestanden op een onverwacht hoog POST-volume, zoek naar bestanden die in beschrijfbare mappen zijn verschenen en roteer alle inloggegevens die een PHP-worker mogelijk in bezit had. De variant met geheugenlekken maakt het roteren van inloggegevens een redelijke voorzorgsmaatregel in plaats van paranoia.

De PHP2Shell-verificatie moet zich richten op de actieve interpreter. Dashboards, buildlogs en responseheaders faalden allemaal minstens één keer tijdens deze ronde. Een CDN kan de header verwijderen die de versie zou aangeven, een build kan succes melden terwijl een gecachede laag wordt hergebruikt, en een pakkettegel kan de huidige versie weergeven terwijl een oude worker nog steeds actief is. php -v Binnenin het apparaat dat de verzoeken verwerkt, worden ze afgehandeld.

Containers vallen niet onder de PHP2Shell-adviezen van de leveranciers. Dit is belangrijk om te benadrukken, omdat het de meest voorkomende oorzaak is van een vals gevoel van veiligheid op een NAS. Als uw site in Container Manager draait, zegt het feit dat Package Center meldt dat alles up-to-date is, niets over uw site. Hetzelfde geldt voor elke applicatie van derden die zijn eigen runtime bundelt.

Configuratiemaatregelen zijn per definitie slechts gedeeltelijk. Het uitschakelen van de voortgangsbalk voor sessie-uploads helpt, het verwijderen van de geheugenlimiet ruilt het ene risico in voor het andere, en een inbraakpreventiefunctie van de router kan geen TLS-verkeer inspecteren dat elders eindigt. Beschouw dit alles als tijdwinst terwijl u werkt aan een echte patch, niet als een vervanging ervan.

Runtimeversies die het einde van hun levenscyclus hebben bereikt, hebben helemaal geen PHP2Shell-pad meer. PHP 7.3 en eerdere versies ontvingen geen ondersteuning meer van upstream en ook niet van Synology. Als een website daadwerkelijk een niet-ondersteunde versie nodig heeft, is de keuze tussen migratie, isolatie of verwijdering van het openbare internet. Er is geen vierde optie, en doen alsof dat wel zo is, zorgt ervoor dat een verouderde website de toegangspoort wordt tot alle andere websites op dezelfde server.

Tot slot, houd het advies in de gaten in plaats van de nieuwsberichten. Synology heeft SA-26:14 als opgelost gemarkeerd en binnen zes minuten na publicatie eenmaal herzien. QNAP heeft aangegeven dat QSA-26-18 zal worden bijgewerkt zodra er gecorrigeerde versies beschikbaar komen. Beide pagina's zullen veranderen en de versienummers in dit artikel zijn de versies die op 22 oktober 2026 zijn gepubliceerd.

Referenties

• Synology-SA-26:14 PHP2Shell-beveiligingsadvies, gepubliceerd op 22 oktober 2026, status Opgelost, met vaste versies voor PHP 7.4 tot en met 8.4.
• Verklaring van Synology over PHP2Shell-kwetsbaarheden, de PSIRT-nota met een overzicht van de getroffen pakketten en de DSM-dekking.
• QNAP QSA-26-18, Status: Oplossen, lijst met getroffen producten en bijbehorende gecorrigeerde versies: Wordt nog bekendgemaakt.
• ASUSTOR Legacy PHP-uitfasering aangekondigd, waarbij PHP 7, 7.3, 7.4 en 8.1 uit App Central worden verwijderd.
• Help Net Security met de upstream PHP2Shell-releases., Dit omvat PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35, evenals de broncode-backports voor oudere versies.

Veelgestelde vragen