Veel websites bij hosters van Yourhosting zijn nog steeds offline om PHP-bug

Veel websites die worden gehost bij hostingdiensten die onder Yourhosting vallen, zijn nog steeds niet online na het PHP-lek van gisteren. Het bedrijf zegt dat in de loop van de ochtend gebeurt. Een fix voor PHP2Shell is inmiddels al meer dan 18 uur beschikbaar.

Veel tweakers klagen op het forum over de diensten van onder andere Versio, een van de grotere hostingpartijen van Yourhosting. Ook bij andere hostingpartijen zoals Flexwebhosting zijn er problemen. Bij veel van die hostingpartijen zijn zelfs de homepages offline.

De problemen lijken te gelden voor de meeste hostingproviders die onder Yourhosting vallen. Yourhosting kocht de afgelopen jaren veel kleinere hosters op. De statuspagina van Yourhosting bevestigt de problemen. Yourhosting noemt daarin onder andere zichzelf, maar ook Argeweb, De Heeg, RealHosting, SoHosted, Vevida en VIP Internet. De problemen lijken voor te komen in zowel resellerhosting als in dedicated hostingpakketten en vps-diensten.

Veel websites die bij die partijen worden gehost, zijn niet bereikbaar. Dat komt door het lek in PHP van woensdag, waardoor veel websites (waaronder Tweakers) preventief offline werden gehaald. Veel hostingpartijen haalden toen ook diensten van klanten offline om die te beschermen.

Maar waar de PHP-patch bij de meeste grote sites wel is doorgevoerd, geldt dat niet voor Yourhosting-pakketten. "Afgelopen nacht zijn de officiële beveiligingsupdates voor PHP uitgebracht", zegt Yourhosting. Dat klopt niet: de patch kwam iets voor 16.00 uur Nederlandse tijd al online. "Onze technische teams zijn druk bezig met het installeren van de beveiligingsupdates. Daarna zetten we onze systemen stap voor stap weer aan. Zoals we gisteren hebben aangegeven, doen we dat pas wanneer het veilig is voor jou. We controleren daarom eerst zorgvuldig of alles goed werkt."

Yourhosting zegt in een update dat 'de eerste websites inmiddels weer bereikbaar zijn'. "De overige websites zetten we stap voor stap weer online", zegt het bedrijf.

Reacties (159)

[MoonRaven]

Dat PHP een update uitlevert betekent niet dat iedereen het meteen kan doorvoeren. Plesk had binnen een uur voor Linux een update met de nieuwe php versies, maar Windows duurde nog vele uren voordat daar een update voor was. Dan heb je ook nog docker containers waar php in zit ingebouwd, zoals een nextcloud, freshrss, etc. Dat is ook iets waar je op moet wachten. Ja, de patch was iets voor 4 uur beschikbaar, maar dat betekent niet dat het opeens gefixt is.

Ik heb zelf voor onze klanten de update gister avond nog uitgevoerd en de php versies naar ondersteunde versies gezet. Maar dat gaat om tientallen sites, niet duizenden. Nu bezig met een check om te zien of alles nog veilig is, wij vermoeden van wel, maar controleren is beter.

[Kevinp]

Trans Ip heeft alle versies die ze ondersteunen gepatched. Ik heb zelf ook maar de php versie verhoogd naar iets wat ondersteund word officieel

[Davy de Vries]

Ondanks dat de patch er al om 15:20 (Nederlandse tijd) was. Betekent niet dat dit meteen een oplossing is voor een hosting of bedrijf. Ik vind het volgende dan ook wat kort door de bocht:

Dat klopt niet: de patch kwam iets voor 16.00 uur Nederlandse tijd al online.

Wij hebben bijvoorbeeld gewacht op de officiële docker images, voor ons k8s platform.

- De eerste merge was pas om 16:19
- Toen moest het nog naar docker-library/official-images En deze is pas merged om 17:16

[Reactie gewijzigd door Davy de Vries op 22 oktober 2026 11:01]

[TijsZonderH]

Nee vooruit, maar dan heb je het over een verschil van een paar uur. Niet over 'vannacht', zoals Yourhosting het zelf zegt.

[esdeboer]

Als ze van cloudlinux afhankelijk waren, die hadden de laatste versies ook pas om 00.05 UTC https://cloudlinux.statuspage.io/incidents/zl0vt1yq3dj5 , dat is toch vannacht, weliswaar in de UK,

antagonist had ze bijvoorbeeld ook pas om 02:52 https://status.antagonist.nl/event/1908/

[SunnieNL]

Dan moet je het in je melding als hoster beter omschrijven. De patch voor het probleem was om 1600u al uit. Dat jij afhankelijk bent van een 3de partij die het eerst moet doorvoeren in hun systemen voordat jij het weer kan doorvoeren doet daar niet aan af. Sterker nog, dat is een risico in jouw supply chain waar je eens heel goed naar moet kijken. Zeker als hoster.

[joshua043]

Ook niet helemaal waar, toch?

Van wat ik begrepen heb waren er sowieso grotere leveranciers die eerder toegang kregen tot de patches. Zo kon ik mijn DirectAdmin server al vlak voor 17:00 upgraden met een patch van DA zelf.

Maar onze servers hosten we, vanwege het gebruik van Laravel, op de daarvoor aangeraden OS (Ubuntu). Hoe het met de PHP versie zit waarmee Ubuntu released wordt weet ik niet, maar omdat we gebruik maken van Ondrej's PPA om op een server PHP projecten te kunnen upgraden waren we afhankelijk van die builds en die kwamen pas om 20:00.

Dus je hebt als hoster zeker niet alle touwtjes in handen om te bepalen waar jij in die keten terecht komt. De keuze voor een bepaald OS of controlpanel kan prima heel bewust gemaakt worden met de jammere kanttekening dat je in deze gevallen pas later kunt gaan patchen.

[SunnieNL]

Ik zeg ook niet dat je als hoster alle touwtjes in de handen hebt, maar je wel juist moet kunnen verklaren waarom het zo lang duurt. Dat de patch (die er eerder was) niet wordt doorgevoerd of vertraagd wordt doorgevoerd in jouw supplychain kun je dan gewoon aangeven. Dan kan Tweakers als nieuwssite dat ook veel beter aangeven.

Als hoster besluit je ook om te kiezen voor bepaalde technieken. Daar zit een risico aan. Als hoster weet je precies wat je SLA is voor kritieke patches, dat onderhandel je immers uit of ga je mee akkoord. Die zouden dan ook weer moeten matchen met je EULA.

Als zo'n kritieke patch zo lang duurt om door te voeren in je supply chain en jij daarop de beslissing maakt om alle websites gewoon down te brengen, dan vind ik dat je als hoster wel eens goed mag gaan nadenken of dat niet beter kan en moet. Want als je dat als hoster niet doet, doen je klanten dat wel. Zeker gezien die ook zien dat andere hosters het wel veel sneller hebben doorgevoerd.

[Reactie gewijzigd door SunnieNL op 22 oktober 2026 12:49]

[joshua043]

De verklaring van YourHosting is ook niet helemaal feitelijk juist, dat ben ik met je eens.

Ik heb om 12:00 de eerste mailing gedaan dat we uit voorzorg offline gaan en de situatie even afwachten. Om 17:00 een vervolgmailing met de daadwerkelijke impact en dat we in afwachting waren van de builds en tussen 23:30 en 03:00 vannacht waren alle updates afgerond en iedereen weer online.

Natuurlijk kies ikzelf voor deze opzet en door deze situatie gaan we ook intern kijken in hoeverre we "Multi PHP" servers nog willen gebruiken. Want hadden we dat niet gedaan dan waren de updates via de officiële Ubuntu kanalen eerder toepasbaar geweest.

Wij hosten managed voor onze klanten overigens, wij verkopen geen hostingpakketjes zoals YourHosting dat doet. We hebben binnen 12 uur na het uitkomen van de patches alle 180 sites die we draaien weer in de lucht gekregen.

Het verschil in SLA bepaalt dan trouwens inderdaad ook een hoop. Sommige klanten hebben niet gekozen voor actief onderhoud en die kwamen dus later pas online. Klanten die dat wel doen draaiden al op actuele (een vps voor enkel hun project(en)) servers waarbij de updates sneller klaar waren. Maar dat zijn keuzes van de klant en dus niet alles is geheel op de hoster te verhalen.

Ik doe er in elk geval genoeg aan om ook de sites van klanten die niet voor onderhoud kiezen zo veilig mogelijk online te houden. Dat is mijn taak ook. Maar als je bewust kiest voor een legacy account dan leg ik je ook heel goed uit wat de risico's daarvan kunnen zijn.

[Reactie gewijzigd door joshua043 op 22 oktober 2026 13:20]

[mocean]

Echt bizar, dan hangt je hele bedrijf aan 1 gast te heten 'Ondrej Sury' die hopelijk de boel patcht, upload en dan ook nog bidden dat zijn server niet onderuit gaat (ging ie wel een paar keer).

En als Ondrej dan op vakantie is of erger, dan heb je geen plan? Zelf compilen als de devs dat nog kunnen ...

[Thijzer]

Ik kan er zo een paar bij naam noemen,

Linus Torvalds

Guido van Rossum

Daniel Stenberg

Fabrice Bellard

Ze hebben wel hun peers, en contingency plan, dus the show must go on.. zonder hun is het internet een andere plek.

[joshua043]

Het is niet zo dat mijn bedrijf onderuit gaat als Ondrej stopt. Het maakt het wel even spannend en druk waarschijnlijk.

Alles wat inmiddels al gebuild is en draait blijft draaien, alleen updates zouden dan niet meer verschijnen. Dat betekent dat ik ofwel terug moet naar Ubuntu met gebundelde PHP versies en dus vanuit officiële kanalen moet updaten en/of dat sommige projecten die we onderhouden bijgewerkt en verhuist moeten worden naar nieuwe servers.

Het kan (en zal) veel werk zijn, maar zeker geen end-of-the-world scenario.

Ook na gisteren zie ik nog geen reden om wat we doen anders aan te pakken. Het heeft mijn ogen op sommige vlakken wel geopend, maar ik sta nog steeds achter de infrastructuur zoals we die hebben gekozen en achter de manier waarop we dit voor iedereen hebben aangepakt.

Mijn bedrijf hangt ook af van één leverancier voor servers (Hetzner), weliswaar met goede back-up constructies die ook off-site gaan. Maar daar zou ik me meer zorgen om kunnen maken dan om Ondrej. Ik gun hem van harte dat er een mooi aantal mensen naar aanleiding van gisteren een bijdrage aan zijn Patreon (https://www.patreon.com/cw/oerdnj) zijn gaan doen.

[Reactie gewijzigd door joshua043 op 22 oktober 2026 14:52]

[GertMenkel]

Als bedrijf bepaal ze zelf welke software je draait, het is niet dat er iemand is die stiekem PHP op je server installeert.

Als je bedrijf ervoor kiest om hun hele product afhankelijk te maken van de vrijwillige activiteiten van Ondřej Surý (die naar wat ik vernomen had tijdens dit hele drama nog op vakantie was ook), is dat een risico waarvoor je gekozen hebt. Het is niet iets dat je spontaan overkomt. Je hebt als hoster wel degelijk de touwtjes in handen om te bepalen waar jij in die keten terecht komt, alleen je bedrijf heeft ervoor gekozen het risico te lopen dat ze dagen of weken moeten wachten als Ondrej ooit in het ziekenhuis ligt.

De versies die Ubuntu gratis voor je onderhoudt:

Trusty (14.04): php5
Xenial (16.04): php7.0
Bionic (18.04): php7.2
Focal (20.04): php7.4
Jammy (22.04): php8.1
Noble (24.04): php8.3
Resolute (26.04): php8.5
Stonking (26.10): php8.5

PHP onderhoudt momenteel 8.2, 8.3, 8.4, en 8.5. Oudere versies krijgen soms wat patches uit goede wil, maar daar kun je niet van uit gaan.

Dat zijn de versies, die overigens wel snel gepatcht waren, die officieel gratis voor je onderhouden worden als je Ubuntu gebruikt. Als je ervoor kiest andere bronnen te gebruiken (bijvoorbeeld omdat je jaren achterloopt met je PHP-versies) kun je zelf bepalen waar je in de keten zit voor fixes, maar krijg je die fixes niet van Canonical of PHP zelf.

[joshua043]

Helemaal mee eens! En dat is ook een leerzaam moment geweest, ik was tot gisteren namelijk helemaal niet op de hoogte dat één persoon verantwoordelijk was voor het draaiende houden van mijn oudere Ubuntu servers en PHP7.4+ sites. En dat heeft Ondrej overigens gisteren ook één (en ik mag hopen nog heel wat meer) nieuwe Patreon opgeleverd.

Heel veel legacy hebben we niet lopen (Van de 180 sites 8x 7.4 - 2x 8.0 - 1x 8.1). Na gistermiddag tijdens het offline halen waren dat nog drie 7.4 sites en de rest was bijgewerkt naar 8.2.

Ook hier is het wat te makkelijk om dat weer op de hoster af te schuiven. Mijn klanten kiezen voor een onderhoudsvorm waarbij ik de voor- en nadelen (in mijn ogen) duidelijk uitleg. Die 7.4 klanten hebben bewust niet voor onderhoud gekozen vanwege de kosten en het kan mij niet kwalijk worden genomen dat ik dat niet kosteloos ga doen natuurlijk.

In elk geval wel een situatie die weer wat inzicht heeft geboden. Nu iedereen weer probleemloos online is kunnen we gaan kijken in hoeverre het verstandig is om enkel de bij Ubuntu geleverde PHP versie te blijven. Voordeel is dat deze patches sneller beschikbaar zijn, maar het eerlijke nadeel is ook dat het softwareonderhoud dat we doen voor onze klanten gigantisch toeneemt want er komt ook een verhuizing van de elke applicatie bij kijken en daar komt een prijsverhoging bij kijken die ik liever niemand voorschotel.

Ik vind dat ik als hoster verantwoordelijk ben voor het uitleggen van de opties die we bieden in de vorm van het onderhoud. De klant maakt de keuze en dat kan in deze situaties verschillende soorten uitkomsten hebben.

[Reactie gewijzigd door joshua043 op 22 oktober 2026 13:23]

[Bedge85]

ik was tot gisteren namelijk helemaal niet op de hoogte dat één persoon verantwoordelijk was voor het draaiende houden van mijn oudere Ubuntu servers en PHP7.4+ sites.

Ik denk dat je onderschat hoeveel opensource projecten die belangrijk zijn voor het internet maar door een enkel persoon wordt onderhouden. Visueel ziet dat er zo uit : https://xkcd.com/2347/

[joshua043]

Van een aantal was ik me wel bewust, maar zoals vaak pas vanaf het moment dat het in het nieuws komt (curl bijvoorbeeld). Als ik nu zie wat bij een server update allemaal langs komt dan denk ik dat ik meer namen van packages zie die ik niet dan wel ken.

[BeosBeing]

https://xkcd.com/2347/

Dat is een mooie.

[Sappig]

De packages van Ondrej Sury waren vanaf 15.45 al beschikbaar (via https://packages.sury.org/php).

[joshua043]

Dat waren, als ik me niet vergis, Debian builds. Van wat ik begreep gaan die altijd sneller. De Ubuntu releases waren er pas in de avond.

[Erulezz]

Voor Ubuntu waren ze er al meteen, heb om 17.00 alles bijgewerkt op Ubuntu 24.04/26.04 van de sury repository.

[joshua043]

Geen idee wat ik dan verkeerd heb gedaan, ik kreeg echt pas na 20:00 groen licht op mijn servers om een patch te installeren.

[Websmurf]

Nee hoor, Ubuntu ook.

Had mijn servers allemaal om 15:55 weer online met de geüpdatet versies van php

[xoniq]

Zo kon ik mijn DirectAdmin server al vlak voor 17:00 upgraden met een patch van DA zelf.

Met een kleine tweak (pre-fetchen van de patches) kon je dat 16:00 al doen zonder te wachten op de DA repos zelf. Ik had alles om half 5 up to date en up and running.

[joshua043]

Thanks voor tip! Daar ga ik straks nog even naar kijken.

[Bas-w]

Ik kon mijn Ubuntu om 16:45 updaten, maar kreeg de indruk dat ze het wel gefaseerd uitrolden om hun eigen servers te ontzien. Op de website stond dat de updates al eerder beschikbaar waren.

[joshua043]

Vreemd. Hoor hier in de comments ook meerdere tijden. Ik had een klein scriptje draaien op een van de servers die de cache refreshten en kreeg echt pas na 20:00 uur nieuwe versies te zien.

Wat wel zou kunnen is dat ik niet opgelet heb en dit op een ARM server heb gedaan.

Hoe dan ook: het is gelukt en we hebben het overleeft :-)

[Bas-w]

In mijn geval was het ook een ARM server, dus daar lag het ook niet aan.

[HollowGamer]

Dat is niet waar, die images moeten herbouwt worden en dan opnieuw worden deployed (ook naar mirrors).

Het is echt niet gek dat je dan 12-24 uur verder bent.

[Bedge85]

Sterker nog, dat is een risico in jouw supply chain waar je eens heel goed naar moet kijken.

Dit is hindsight bias. In deze situatie blijkt nu dat de supply chain niet snel genoeg te reageren. Alleen bij het kiezen van een software leverancier spelen er gewoon enorm veel requirements waar rekening mee gehouden moet worden. Het is altijd makkelijker om met het vingertje te wijzen.

[SunnieNL]

Ja, en dat doen hosters ook door te zeggen 'de patch was er pas om middernacht'. Dat is met het vingertje wijzen. "sorry, ik kan er niets aan doen ik bern afhankelijk van 3 andere partijen". Jawel, jij hebt gekozen voor die techniek toch? Je had ook voor een andere infra kunnen kiezen en was je mogelijk sneller geholpen.

Maar ik begrijp dat jij de requirement "hoe snel wordt een kritieke patch geleverd aan ons zodat wij niet down hoeven en al onze klanten offline moeten brengen" niet heel hoog op het lijstje had staan.

CBW / NIS2 zegt niet voor niets eens goed naar je supplychain te kijken. Wat zijn de risico's en mitigeer die zo mogelijk in je SLA met deze partijen. Dus een kritieke patch moet geleverd worden in x tijd. Tel daar de tijd bovenop die je zelf nodig hebt zo'n patch uit te rollen in je omgeving. Dat is de tijd die in de EULA/SLA naar klanten gaat zodat zij een bewuste en goede keuze kunnen maken.

Klanten gaan echt wel vragen stellen als dit allemaal te lang heeft geduurd. Zij zijn ook verplicht te kijken naar hun supplychain. Zij kijken ook naar dit risico. En nu dit gebeurd is, al helemaal.

Als jij kiest voor een onderdeel in je supply chain en dat onderdeel is vervolgens afhankelijk van een ander onderdeel dat weer afhankelijk is van weer een ander onderdeel (php patch -> docker -> wordpress dock -> servers van host) , dan moet je dat echt wel in kaart hebben als hoster en er over nagedacht heben.

Maargoed, denk dat klanten van Yourhosting wel wakker geschud zijn en hun risico gaan bepalen en of deze hoster dan nog wel in hun supplychain past.

[Reactie gewijzigd door SunnieNL op 22 oktober 2026 15:51]

[ZinloosGeweldig]

Je maakt over het algemeen juist gebruik van een trusted vendor die je binaries voor je bouwt in plaats van zelf github te rawdoggen om supply chain risico's te verminderen. Je hoeft namelijk én niet zelf github te rawdoggen, én zulke vendors krijgen de patch vaak al eerder onder embargo, zodat ze klaar kunnen zijn voor een coordinated release.

Dat gezegd, was CloudLinux rijkelijk laat, of hadden ze de patch niet eerder onder embargo verkregen. Beide geen dingen die voor je spreken als Vendor.

Dus ja, wélke vendor je gebruikt is wel een ding om naar te kijken. Het is verder volledig correct dat als je PHP van CloudLinux gebruikt, er voor jou pas een patch gereleased is als CloudLinux hun build vrijgeeft.

[n9iels]

Maar Antgonist heeft dus wel de moeite genomen om door te werken (en hopelijk personeel hiervoor goed beloond). Bij yourhosting zijn ze om 17:00 naar huis gegaan volgensmij zonder ook maar iets te zeggen.

[Reactie gewijzigd door n9iels op 22 oktober 2026 12:47]

[HostMan]

De meeste providers gebruiken tegenwoordig CloudLinux, daar klopt de uitspraak 'vannacht' wel, helaas kwamen de patches echt pas midden in de nacht beschikbaar.

[renevanh]

Vimexx gebruikt ook CloudLinux en mijn hosting is gisteren om 20:29 geupdate.

CloudLinux heeft alleen lopen klooien met versienummers. Ze zeggen dat 8.4.26 de updates bevat (officiele versie is 8.4.27). Maar hopen dat dat klopt...

[HostMan]

Je mag me vertrouwen wanneer ik zeg dat dat klopt :-).

CloudLinux heeft in plaats van de nieuwe update uit te brengen, de meest recente oude versie gepatched.

Alle PHP versies van CloudLinux zijn veilig, ook als het versienummer nog 8.4.26 is.

Mocht je dit zelf willen controleren kun je een PHPinfo bestand aanmaken en deze openen, dan zie je de tijd en datum van de build staan, dat zal 21 oktober in de middag zijn.

[renevanh]

Dat is de uitleg van CloudLinux inderdaad.

Ik begrijp alleen niet waarom. Nu krijgen hosters ontzettend veel vragen van klanten hierover, terwijl dat onnodig is. Had er gewoon 8.4.27 van gemaakt, scheelt je helpdesk uren aan steeds dezelfde vragen beantwoorden.

[MoonRaven]

Plesk voor Windows had pas na 10 uur 's avonds een update. Ik weet niet wat voor applicaties zij gebruiken, het kan dus wel zo zijn, al kan het zeker zijn dat ze overdrijven.

[jozuf]

In RHEL word vaak remisrepo gebruikt, en daar gaven ze al aan pas vandaag een package te leveren.

[joshua043]

Ik was zelf voor mijn eigen klanten (20 servers) en eentje van een externe klant pas om 03:30 vannacht klaar. De releases voor Ubuntu zijn als het goed is rond 20:00 beschikbaar gekomen. In de eerste uren waren ook veel problemen met apt-get updates bijvoorbeeld door de hoeveelheid mensen die ermee bezig was, pas later in de nacht ging alles soepel en snel.

Neemt niet weg dat de berichtgeving van YourHosting niet helemaal juist is natuurlijk. De officiële waren er inderdaad vlak voor 16:00 al, maar de bruikbare releases voor de meeste hosters waren pas beschikbaar tussen 17:00 en ergens vannacht.

[sdk1985]

Nee vooruit, maar dan heb je het over een verschil van een paar uur. Niet over 'vannacht', zoals Yourhosting het zelf zegt.

Normaal zal ik het niet persé snel opnemen voor yourhosting maar an sich is dat wel waar. Cloudlinux was behoorlijk traag met de updates voor alt-php, ze beloofden binnen 5 uur. Uiteindelijk kwam er op 22 october 00:07 UTC (dat is dus 2:07 in Nederland) de alt-php 5.2-5.6, 7.0-7.4 and 8.0-8.5 naar stable.

Er kwam al eerder een 'ELS ALT PHP repository', dat was rond 22:29 UTC.

CloudLinux OS 7, 8 and 9
1. Make sure the server is registered with CLN (this file must exist):
ls /etc/sysconfig/rhn/jwt.token || rhnreg_ks --activationkey <YOUR-KEY> --force

2. CloudLinux OS 8, 9 only: make sure cloudlinux-release is recent enough to provide the ELS ALT PHP repository package (8.10-16 or newer on CloudLinux OS 8, 9.8-3 or newer on CloudLinux OS 9).
Otherwise, the next step fails with No match for argument: els-php-release.

Update it and check the version; the update may need to run more than once to reach the latest version:
dnf update -y cloudlinux-release
rpm -q cloudlinux-release

3. Add the ELS ALT PHP repository:
CloudLinux OS 7: yum install -y els-php-release
CloudLinux OS 8, 9: dnf install -y els-php-release

4. Keep regular updates working even if the repository becomes unreachable:
CloudLinux OS 7: yum-config-manager --save --setopt=php-els.skip_if_unavailable=true
CloudLinux OS 8, 9: dnf config-manager --save --setopt=php-els.skip_if_unavailable=True

5. Check access to the repository (the output must include "Metadata cache created"):
CloudLinux OS 7: yum --disablerepo='*' --enablerepo=php-els makecache
CloudLinux OS 8, 9: dnf --disablerepo='*' --enablerepo=php-els makecache

6. Update alt-php:
CloudLinux OS 7: yum update -y 'alt-php*'
CloudLinux OS 8, 9: dnf upgrade -y 'alt-php*'

Posted 12 hours ago. Oct 21, 2026 - 22:29 UTC

In zomertijd is dat alsnog 00:29 in de nacht van 22 oktober. Toen kon je daadwerkelijk starten met updaten.

Verschilt overigens enorm per configuratie en niet persé of je cloudlinux gebruikt of niet. Als ik hier kijk dan konden systemen met cloudlinux en php-fpm hier om 16:00 direct updaten en konden systemen die de cloudlinux selector gebruiken waar hun alt-php bij hoort pas vannacht updaten via die extra repository.

Ondertussen schijnt alles in stable te zitten, maar dat is dus pas sinds een uur (11:21).

[Reactie gewijzigd door sdk1985 op 22 oktober 2026 13:03]

[henk717]

Hoe zit dit met oude PHP versies? Dergelijke hosts draaien vaak PHP5 en nieuwer. Hoe laat waren de patches voor PHP5 beschikbaar via bijvoorbeeld TuxCare?

[Asitis]

Saillant detail dat Adobe hun Commerce projecten ook vannacht om 5u pas heeft gepatched. Zonder betekenisvolle communicatie vooraf..

[WargamingPlayer]

Suse en OpenSuse hadden zelfs gisteren avond om 22:00 nog geen updates beschikbaar, niet omdat ze er niet waren, maar vanwege testen, builden, testen en toen werkte om onduidelijke redenen het synchroniseren van repo’s niet waardoor vanmorgen pas updates beschikbaar kwamen.

Het is niet zo zwart-wit allemaal. Je kan je als Distributeur van een OS niet veroorloven dat er een fout in je distributie zit doordat er zaken omvallen.

Het is nog complexer want ook alle afhankelijkheden moeten getest worden als je die in je distributie mee neemt.

Daarom heeft bijvoorbeeld Grommunio er gisteren avond voor gekozen om niet te wachten op Leap 16 updates maar zelf php-fpm mee te packagen.

[Tweakez]

15:20 is niet helemaal waar, die patch was er toen nog niet. Om 15:45 was pas de website van php.net geupdatet en de repos (default ubuntu, debian whatever) hadden nog geen geüpdatet packages. Ik heb uiteindelijk (omdat docker ook achterliep met packages) een eigen build gemaakt en dat ging prima en deze ochtend dat weer vervangen voor de originele packages die niet vanuit source gemaakt zijn. Tis allemaal niet zo moeilijk.

[Kees]

Net even terug gekeken in mijn shell; om 15:45:11 ging mijn 'apt update' van 0 naar 36 packages. Toen waren de nieuwe packages van Ondrej Sury dus beschikbaar.

De aankondiging op de php website stond toen al zo'n 20 minuten online.

[TD-er]

Die was trouwens wel op sommige momenten onbereikbaar.

Heb zelf namelijk tussen 22h en 23h een paar keer gehad dat ik ze niet binnen kon halen.

[Tweakez]

Hier was ik elke minuut de php.net site aan het refreshen om 15:45 ging die bij mij van 'we are working on it' naar de hier is de fixes.. da's best vreemd dan? Zou er dan ergens iets van caching tussen zitten? Ik heb om 15:45 inderdaad zelf wel direct de update(s) op al mijn machines kunnen doen dus wat dat betreft wel op één lijn haha!

[Tozz]

Debian had om iets van 15.53 de update ook. Die patches zijn best gecoordineerd gegaan. Het is niet zo dat Debian pas kon patchen toen PHP de fix had uitgebracht.

Een aantal partijen zijn wel erg traag geweest met het uitbrengen van patches, waaronder bv. RedHat die pas om een uur of 6 in de avond (NL tijd) uberhaupt melding maakte van een probleem.

[Groentjuh]

Versio gebruikt DirectAdmin. Die had al eerder de patches aangeleverd gekregen, zodat DirectAdmin (en ook WHM/Cpanel) daar zeer snel en gemakkelijk.

Vooral Cpanel had dit op diverse servers gewoon zeer rap voor elkaar. Waarbij ik een server voorbij zag komen met:

[2026-10-21 15:41:02 +0200]   An expedited package update is available. Updating packages from EA4.

Van wat ik lees was ook bij DirectAdmin de patch direct beschikbaar, maar was daar wel handmatige actie benodigd is. DirectAdmin moet bijgewerkt worden (gebeurd automatisch) en daarna moest PHP in de DirectAdmin omgeving opnieuw gecompileerd worden en dan zijn alle PHP versies daarop bijgewerkt. PHP versies ouder dan 7.4 kwamen echter pas later beschikbaar kwam, dus voor de DirectAdmin system mocht je nog een keer rond... Hosters zullen het met DirectAdmin best wel een beetje druk hebben.

[Reactie gewijzigd door Groentjuh op 22 oktober 2026 11:42]

[zx9r_mario]

Patches voor DA waren gisteren om 16u al gelijk beschikbaar.

[Groentjuh]

Voor PHP 8.5, 8.4, 8.3, 8.2, 8.1, 8.0, 7.4 binnen DirectAdmin was gelijk een patch beschikbaar, maar PHP 7.3 - 5.6 binnen DirectAdmin was pas later een patch (bron #1 en #2).

[Reactie gewijzigd door Groentjuh op 22 oktober 2026 12:41]

[SirQuack]

Dat een hoster inderdaad niet om 15:21 al weer online is met gepatchte content is te verwachten, maar ook voor Docker: de nieuwste (edit: meest recent geuploade) php libary package van 8.5.12 was om 03:05 uur online.

Dat een van de grootste hosters dan pas rond 10 uur sites weer online krijgt, vind ik wel beschamelijk.

[Reactie gewijzigd door SirQuack op 22 oktober 2026 10:58]

[RobertMe]

de nieuwste (edit: meest recent geuploade) php libary package van 8.5.12 was om 03:05 uur online.

De meest recente, zoals je aangeeft.

Hoewel ze wat issues hadden met het builden en pushen van de officiële images stonden deze rond een uur of 7 (NL tijd) op Docker Hub. Zie ook hier op GitHub.

Waarbij ook niet vergeten moet worden dat het php Docker image uit de community is. Dit image wordt niet onderhouden door de PHP devs zelf. En, zeer waarschijnlijk, hebben zij ook geen vroege toegang tot de release / patches gehad. Zoals meerdere distributies wel al eerder toegang hadden tot de release en/of patches en dus al om 4 uur klaar konden zitten om de packages in hun apt/rpm/... repo te zetten. Terwijl de maintainers van het Docker image netjes hebben moeten wachten op de officiële release.

En v.w.b. dat tijdstip om 3 uur 's nachts: dat kan ook een algemene rebuild zijn. Bv een update van het base image (vaak Debian of Alpine) waarna ook weer alle (officiële / Docker maintained) images automatisch gerebuild worden.
Zo zie ik zelf dat elke dag dat er een nieuw image van debian:trixie is dat postgresql:18 ook een update heeft. Die laatste zal dus debian:trixie als base hebben en automatisch rebuilden.

[lwmxynedtodth]

Er wordt in de berichtgeving over het uitbrengen van de patch vergeten dat veel omgevingen afhankelijk zijn van officiële packages van package repositories. Zo zijn er voor Debian bijvoorbeeld al geupdate packages, maar voor RHEL nog niet. Ook voor de onofficiële Remi repository is nog geen nieuwe package. Niet elke beheerder zal de mogelijkheid hebben om PHP te compileren vanaf de source, wat feitelijk de patch van ~ 16:00 was.

[SirQuack]

Zo zijn er voor Debian bijvoorbeeld al geupdate packages, maar voor RHEL nog niet. Ook voor de onofficiële Remi repository is nog geen nieuwe package.

Remi heeft de packagelijst anders al sinds gisteren bijgewerkt; als ik https://rpms.remirepo.net/enterprise/8/php82/x86_64/repoview/ moet geloven.

[blinchik]

Gisteren tot 3u vannacht bezig geweest vooraleer ik alle patches heb kunnen downloaden omdat het zo traag ging of ik timeouts kreeg.

Dan locaal patches zitten distributen om ze niet op elke host afzonderlijk te moeten downloaden.

En er volgen nog zaken waar php embedded is. Fortigate heeft bv aangekondigd dat er vandaag een emergency update uitkomt. PHP staat niet gespecifieerd, maar het lijkt uiteraard vreemd mocht het er niet mee te maken hebben.

[Tozz]

De Fortinet update komt voor een groot aantal producten, een flink aantal daarvan gebruiken geen PHP (waaronder bijvoorbeeld FortiGate). Ik denk dat de PHP bug maar een kleine rol heeft in die Fortinet patch

[jb044]

Klopt, geloof dat het eerst was: morgen zijn jullie de eerste maar dat die soep toch maar niet zo opgediend werd en er daarna vrij snel updated packages voor de diverse php versies van REMI kwamen. Stuk sneller iig dan voor de diverse docker containers met php die ik gebruik en bij mij toch wel voor wat frustratie zorgde toen ik om 21.00 nog steeds niet klaar was

[Strebor]

Ik was gisteren erg onder de indruk van sury.org. Ik gebruik die op een grote groep servers (Allemaal Debian 12 en nieuwer) om verschillende PHP versies te kunnen gebruiken per virtual host op een machine. Ik heb ook een paar afgeschermde legacy systemen die zelfs nog PHP5.6 draaien. Gistermiddag kregen alle PHP versies die Sury beschikbaar stelt de nodige updates om de twee CVE's te verhelpen. Niet alleen PHP 8.2 en nieuwer (de ondersteunde versies). Maar ook PHP 8.1 helemaal terug naar 5.6 werden voorzien van backported security updates. Dus voor 18:00 waren al mijn servers gepatcht.

[onok]

Het is echt extreem om nu nog 5.6 te draaien. Ik zou jezelf eens goed achter de oren krabben

[Strebor]

Haha, daar jeukt het niet.

Zoals ik zei, de machine is volledig afgeschermd (van internet en grootste gedeelte van het netwerk). Geen productie en de machine staat meestal uit zelfs.
Alles op productie is 8.2 en hoger

[WhiteDog]

Het is open-source, als iemand alle relevante security updates wil backporten en de boel hardenen dan moet dat gewoon kunnen 😇.

[SH4D3H]

Eens! Het heeft nog ruim een uur geduurd (wat overigens nog steeds heel snel was) voor deze PR om de official docker images te updaten werd gemerged. En daarna heb ik tot, ik dacht, ongeveer 6 uur moeten wachten tot ik ze ook daadwerkelijk kon pullen. En dan begint het (intern) testen. Voor de meeste projecten was het dus echt niet mogelijk om om 4 uur alweer online te zijn.

[GertMenkel]

Direct om 4 uur zou behoorlijk snel zijn, maar Debian had de pakketten klaar staan, dus als je de PHP-image van Docker zelf zou bouwen, zou je minuten later de patches hebben.

Ik snap wel dat niet iedereen voor één dagje zo'n tijdelijke workaround zou willen toevoegen, maar dit was een kwestie van willen, niet een kwestie van "niet mogelijk".

[Bas_f]

PHP had van te voren de patches al gedistribueerd naar de diverse Linux-distributies en die onafhankelijke repo's, waaronder Sury. Voor 16.00 uur had ik met een gewone update van mijn OS de nieuwe versie al binnen.

Dat RHEL het nog niet heeft is bijzonder slordig. Zeker van zo'n grote distro waar een groot bedrijf achter zit. Nou kan het wel zijn dat RHEL de patches heeft gebackport, maar daar lijkt niet op.

[DDX]

Geen idee wat de bron was dat RHEL geen patches had.
Kijk ik naar Almalinux blog hierover :

https://almalinux.org/blo...6-109618-cve-2026-109619/

'Red Hat has released a fix only for the php:7.4 stream on RHEL 8'
'2026-10-21 17:50 UTC: Patched PHP packages available in almalinux-testing for every PHP stream on AlmaLinux 8, 9, and 10, including retired streams. The php:7.4 fix on AlmaLinux 8, a rebuild of Red Hat’s update, released directly to production. Added package versions and testing instructions, and updated the post title.'

Dus RHEL patch voor 7.4 was gisteren iig al beschikbaar.

[Opperpanter2]

En voor arm64 is er ook lang niet voor alle versies al een patch, atlhans niet in de gratis repositories.

[GS3315]

Er wordt in de berichtgeving over het uitbrengen van de patch vergeten dat veel omgevingen afhankelijk zijn van officiële packages van package repositories.

Veel omgevingen maar niet alle. Een groot deel van de webhosters maakt gebruik van Plesk of DirectAdmin die gisterenmiddag om 16:10 de meest recente (gepatchte) PHP versies online hadden staan. Later op de avond had DirectAdmin zelfs updates met gepatchte PHP 7.x versies.

Volgens mij gebruikt een webhoster over het algemeen niet de kant en klare PHP die vanuit de repositories komen.

[letsserve]

Bij ons komen de PHP packages uit de standaard Plesk en/of de Cloudlinux repositories. Alleen op maatwerk servers willen we wel eens afwijken, maar meestal staan op deze servers geen controlpanel. ;-)

[GertMenkel]

De patch van 16:00 was een binary, beschikbaar op verschillende platforms. Dat was zo gecoordineerd juist zodat iedereen patches had (eigenlijk zou men nog een dag langer hebben om patches te maken, maar diverse partijen hebben hun afspraken geschonden dus de release moest naar voren worden gehaald).

Als je afhankelijk bent van trage partijen dan is dat natuurlijk heel onhandig, maar als je product "het draaien van PHP" is en je geen invloed hebt op PHP omdat je dat hebt uitbesteed aan een andere partij, vraag ik me toch af waar je klanten dan zoveel voor betalen. De stroomkosten zijn echt de prijs van de gemiddelde hoster niet waard en de kennis en kunde om PHP voor je bij te houden ligt blijkbaar ook extern.

[n9iels]

Ik vind het erg opvallend hoe verschillend hosting partijen reageren. MijnDomein heeft bijvoorbeeld al vrij vroeg alle websites van klanten offline gehaald totdat er een patch was. YourHosting deed dit pas rond 16:00 en mijn website is sinds deze ochtend weer beschikbaar. Persoonlijk moet ik ook zeggen dat de communicatie van YourHosting waardeloos is. Ik kreeg pas rond 19:10 een mail dat ze mijn website offline hadden gehaald en de status pagina was sinds 17:10 live en pas deze ochtend bijgewerkt.

[Reactie gewijzigd door n9iels op 22 oktober 2026 11:21]

[krietjur]

Ik zit bij Neostrado (nu Versio). Totaal geen communicatie, geen enkele mail gehad. Ook de website van Neostrada lag plat.

[foxforgames]

Ik zit bij neostrada voor mijn domains (moet nog overstappen) maar ik kreeg gewoon emails hierover.

[MornixRS]

Mee eens. De communicatie is een groter probleem dan het wachten op de oplossing. Die was rijkelijk laat. Onze webshops die voorheen bij Sohosted zaten waren vanochtend nog steeds niet online. Een linkje in de mail naar de statuspagina was ook prettig geweest.

[Hardwareseller]

Cloudlinux (wat partijen als Vimexx o.a.) veelal gebruiken kwam pas met de officiele patches sinds 00.30 publiek (zie: https://cloudlinux.statuspage.io/incidents/zl0vt1yq3dj5).

Wij (Exonet) hebben omdat we zelf alles compile/builden en versiebeheer doen, wel al alles om 15.30 kunnen beginnen met patchen gisteren. Ook nog patches gemaakt later voor 5.6-7.3. Dat scheelt in dit soort situaties enorm.

Neemt niet weg dat het alsnog vrij laat is dat het nu pas wordt toegepast bij de YourOnline partijen, desondanks de reden.

Veel succes verder gewenst aan de engineers vandaag die er druk mee zijn nog!

[Yarisken]

Gewoon uit nieuwsgierigheid, hoe maak je die patches voor 5.6 als die niet officieel uitkomen wegens geen support ?

[mrdemc]

Volgens mij geldt dat alleen voor de alt-php versies, de reguliere versies waren vrij snel beschikbaar gisteren op cloudlinux omgeving. howel lastig voor php 8.1 en lager is dat natuurlijk logisch dat er even tijd zit tussen het publiceren van een aangepaste build van oudere versies die hun hele OTAP straat door moeten.

[vandermark]

Ik baal er flink van...
Via Plesk heb ik mijn websites 'opgeschort' en een custom foutmelding klaar gezet die uitleg gaf en verwees naar nos.nl voor meer info.

Zet yourhosting alles zelf uit, zonder uitleg voor bezoekers, wat een slechte zet & communicatie...
En het duurt ook nog eens erg lang.

[Bergieberg]

Inderdaad dat er geen boodschap kwam stoort mij ook erg. Ik snap dat dat misschien technisch lastig was, maar toch.. alles pats boem en er uit. Ik heb het via cloudflare een foutmelding klaar gezet in de hoop dat die klanten nog weer later terugkomen, maar hoe dan ook loopt iedereen omzet mis.

[jurgen1976]

Dit hoeft natuurlijk technisch niet lastig te zijn. Wij hebben op onze hosting omgevingen gewoon een WAF draaien welke we centraal beheren. Met daarin een "kill switch" voor situaties als deze. De kill switch blokkeert simpelweg al het http(s) verkeer en serveert in plaats daarvan een eenvoudige html pagina met een wederom centraal beheert uitleg tekstje

Het hoeft niet moeilijk te zijn

[Bergieberg]

Als het je vakgebied is ja. Een huis bouwen is ook technisch gezien niet lastig..

[jurgen1976]

Maar in dit geval hoop ik dat het bij yourhosting hun vakgebied is

[Bergieberg]

haha ja het zal hun vakgebied zijn, maar alles wat onder de Versio paraplu komt wordt poep, dus wie weet

[Janneman1965]

Nou, Versio kan er ook wat van.

[PBro]

Volgens het artikel is Versio onderdeel van YourHosting.

[TheDutchCow]

Wij zitten met onze servers (managed) bij Proxhost. Die hadden direct al een mitigation toegepast en direct nadat de patches beschikbaar kwamen, hebben zij direct alles geüpdatet. Erg fijn. Vroeger zaten we bij vuurwerk en daarna bij Yourhosting; blij dat ik bij die partijen niet meer zit. Vuurwerk is ook ter ziele gegaan.

[HostMan]

Dat klinkt fijn, maar direct nadat de details over de kwetsbaarheden bekend werden gemaakt werd duidelijk dat de mitigaties die daarvoor bekend waren niet voldoende waren om de server te beschermen tegen deze kwetsbaarheden.

Je servers zijn dus gewoon (danwel in mindere mate) kwetsbaar geweest tot de update was uitgevoerd.

[TheDutchCow]

En nadeel heeft z’n voordeel..

[Krulliebol]

Van welk voordeel is hier dan sprake?

[willemb2]

Ik heb 2 jaar geleden bij een bizarre prijsverhoging Yourhosting/Sohosted ingeruild voor Cloud86. Die hadden PHP 8.2 en hoger gisteren rond 20:00 op alle servers gepatched. Daarvoor hadden ze al iets met mod-rewrite rules gedaan. Dat gaat mij boven de pet, dus ik heb maar op de patch gewacht. Was eigenlijk wel leuk om het oude platte HTML ambacht weer eens op te frissen voor een tijdelijke pagina.

Hun control panel is Plesk, wat ook op PHP draait. Daar is pas vanmorgen vroeg een patch voor uitgekomen.

[bartjuhhdidam]

Wij zitten ook met de meeste sites bij Cloud86, prima communicatie vanuit hun kant en een groot deel van de sites van ons waren rond 8u alweer in de lucht, de anderen rond 22u. (Managed).

Als ik dan nu lees dat deze YH-sites vanochtend pas in de lucht waren, ben ik blij met C86 haah

[dakathefox]

Naast de absurde prijsstijgingen bij alle partijen uit de TWS-stal, zou dit voor menig klant toch ook wel een aanleiding moeten zijn om je biezen te pakken en weg te gaan.