Veel websites bij hosters van Yourhosting zijn nog steeds offline door 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 (87)

[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]

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

[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]

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

[HostMan]

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

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

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

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

[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

[Opperpanter2]

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

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

[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 😇.

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

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

[Janneman1965]

Nou, Versio kan er ook wat van.

[PBro]

Volgens het artikel is Versio onderdeel van YourHosting.

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

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

[Keypunchie]

Tjsa, wat zegt je SLA, denk ik dan?

Dit is zo'n situatie waarin dat echt het verschil maakt of je prioriteit krijgt. Of niet.

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

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

[jugger naut]

Een hoop hosting bedrijven gebruiken CloudLinux, waarvan de patch zeker niet om 16.00 beschikbaar was gisteren. Meer dan 18 uur is dus wat overdreven. Wellicht dat ze deze patch bedoelen.

https://cloudlinux.statuspage.io/incidents/zl0vt1yq3dj5

[Reactie gewijzigd door jugger naut op 22 oktober 2026 11:04]

[Xilonz]

We zien dat het voor heel veel partijen een uitdaging was om alle packages te publiceren en te distribueren.

Vimexx was vannacht rond 00.00 klaar omdat de CloudLinux updates op zich lieten wachten en het uren duurde voordat ze alles binnen hadden.
Docker WordPress images werden rond 20.00 beschikbaar
Docker PHP Images werden rond 19:30 beschikbaar.
Kinsta (een Premium WordPress-specifieke host) was pas om 10:30 helemaal klaar en begonnen gisteren rond 20.00 te patchen.

Etc. in ieder geval dus ruim 4 uur na de patch beschikbaar kwam.

Het geeft in ieder geval aan dat:
1) Tweakers het heel goed voor elkaar heeft met zo'n sysadmin
2) We moeten overwegen of de huidige infrastructuur en afhankelijkheden wel voldoen aan de nieuwe verwachtingen.

[Hansie9999]

bij onze host one.com was het gisteren snel in orde,

Heb dan ineens ook maar onze PHP van 8.3 ook geupgrade naar 8.5 (en laatste nieuwe versie met de patch natuurlijk)