WERELDWIJDE PANIEK: Grote cyberaanvallen wereldwijd na cruciaal lek #2

quote:

Op woensdag 21 oktober 2026 15:00 schreef Whiskers2009 het volgende:

[..]
Ja, maar daar hebben Danny & co weinig actief voor hoeven doen toch? Dat heeft Cloudflare zelf opgepakt voor hun klanten. Of heb ik ergens iets verkeerd begrepen?

quote:

Op woensdag 21 oktober 2026 14:58 schreef Troel het volgende:

[..]
Misschien wordt achter de schermen wel gewerkt aan een uitgeklede frontpage, ik ben er niet bij, dus voor mij is het gissen.

quote:

Op woensdag 21 oktober 2026 15:01 schreef raptorix het volgende:

[..]
Wat ik gezien heb is dat je een aantal extra rules moet activeren in het controlpanel.

quote:

Op woensdag 21 oktober 2026 15:04 schreef Hiddendoe het volgende:
Ik had vanmorgen ook wat problemen bij het inloggen bij mijn bank.

quote:

Op woensdag 21 oktober 2026 15:05 schreef beefkeek het volgende:

[..]
Cloudflare heeft een paar uur geleden een nieuwe WAF ruleset gepubliceerd (https://developers.cloudflare.com/changelog/product/waf/)

Cloudflare (Dane Knecht - CTO Cloudflare) heeft hierover gepost:
[ twitter ]

Dus het staat standaard aan, mits je de config niet aangepast hebt waardoor je nieuwe rules moet checken voor ze actief worden.

quote:

Op woensdag 21 oktober 2026 15:04 schreef Hiddendoe het volgende:
Ik had vanmorgen ook wat problemen bij het inloggen bij mijn bank.

quote:

Op woensdag 21 oktober 2026 15:06 schreef CarbonC het volgende:

[..]
Aan de ene kant: fijn. Aan de andere kant: waarom moet zowat al het internetverkeer via Cloudflare?

quote:

Op woensdag 21 oktober 2026 15:01 schreef Whiskers2009 het volgende:
Er mag een #2 in de TT

quote:

Op woensdag 21 oktober 2026 15:06 schreef CarbonC het volgende:

[..]
Aan de ene kant: fijn. Aan de andere kant: waarom moet zowat al het internetverkeer via Cloudflare?

quote:

Op woensdag 21 oktober 2026 15:06 schreef RipCity het volgende:
Allerlei sites down maar op nr1: een goksite Zegt wat over de Nederlanders

[ link | afbeelding ]

quote:

Op woensdag 21 oktober 2026 15:09 schreef Wrapster het volgende:

[..]
Omdat het helaas nodig is ivm DDOS aanvallen. Cloudflare is ooit opgezet om dat soort ongein tegen te houden maar bied tegenwoordig veel meer functionaliteit dan alleen dat.

quote:

Op woensdag 21 oktober 2026 15:09 schreef beefkeek het volgende:

[..]
Cloudflare wordt door veel bedrijven vooral gebruikt als DDOS preventie en firewalling. Een denial of service is eigenlijk een hele grote bak internetverkeer naar je website sturen, meer dan de website aan kan waardoor hij onbereikbaar wordt.

Door de website achter een dienst als Cloudflare te plaatsen wordt die DDOS aanval door Cloudflare opgevangen ipv door je eigen servers. Zij hebben veel meer capaciteit tot hun beschikking waardoor ze die tijdelijke piek op kunnen vangen. Brian Krebs (KrebsOn Security) heeft een aantal hele grote DDOS aanvallen gehad en ze met dit soort diensten afgevangen, daar staan wel leuke uitleggen over: https://krebsonsecurity.c(...)ecord-6-3-tbps-ddos/

Tegenwoordig heeft Cloudflare een flinke hoeveelheid extra diensten om je website te beveiligen, zoals dit (WAF = Web Application Firewall, die inspecteert het verkeer voor het naar de server gaat).

Er zijn wel een aantal europese alternatieven, maar niets van de schaal van Cloudflare.

Offtopic maar wel een leuk gebbetje: In 2016 had je het Mirai botnet, wat onveilige IOT devices op 't internet zocht en onderdeel van een botnet maakte. Slimme koelkasten waren hier heel populair in en zijn uiteindelijk een grote bron van DDOS aanvallen geweest

quote:

Op woensdag 21 oktober 2026 14:32 schreef raptorix het volgende:

[..]
Het is in principe geen Wordpress issue he

SPOILER

Om spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.

quote:

How to do patchwork. A simple tutorial.

Bekijk deze YouTube-video

quote:

Op woensdag 21 oktober 2026 15:06 schreef beefkeek het volgende:

[..]
Als het Revolut was, dat kwam door de Google Cloud outage van gisteren.

quote:

Op woensdag 21 oktober 2026 15:18 schreef Hiddendoe het volgende:

[..]
Geen idee waar het aan lag. PC afgezet. Opnieuw opgestart. Geen problemen meer.
Toch raak je wel een beetje in paniek. Met die dagenlange hack van AH.
Elk denkbaar horrorscenario is nu mogelijk.

quote:

Buitenland lijkt minder te reageren
Wie zoekt naar buitenlandse sites, kan daar meestal terecht. Dat is opvallend, omdat PHP wereldwijd wordt gebruikt en Nederlandse sites massaal offline gaan. Volgens Corine Schipper-Derkse van het Nationaal Cyber Security Centrum wordt daar waarschijnlijk "een andere risicoanalyse" gemaakt.

quote:

Op woensdag 21 oktober 2026 15:21 schreef Benny het volgende:
Nu.nl liveblog:
[..]
Nederland paniekland

quote:

Op woensdag 21 oktober 2026 15:25 schreef drakin het volgende:
Hyves doet het

quote:

Op woensdag 21 oktober 2026 15:25 schreef drakin het volgende:
Hyves doet het

quote:

Op woensdag 21 oktober 2026 15:28 schreef Wrapster het volgende:

[..]
Gelukkig maar.

quote:

Op woensdag 21 oktober 2026 15:21 schreef Benny het volgende:
Nu.nl liveblog:
[..]
Nederland paniekland

quote:

Op woensdag 21 oktober 2026 15:18 schreef Troel het volgende:

[..]
Gewoon uitloggen, computer uitzetten en het volgend jaar nog een keer proberen

quote:

Nederland massaal in de rij voor verwachte PHP-patch: ‘Je weet maar nooit’

Nederlanders nemen de dreiging rond het wereldwijde PHP-lek uiterst serieus. In het hele land staan inmiddels lange rijen, in afwachting van de patch die om 16:00 wordt verwacht.

Sommigen hebben dekens meegenomen, anderen hebben in stilte afscheid genomen van hun dierbaren. Vooral onder seniore internetgebruikers is de spanning voelbaar.


‘Ik heb mijn wachtwoorden aan mijn kleinkinderen gegeven en mijn browsergeschiedenis laten wissen,’ aldus een 84-jarige man, die sinds vanochtend vooraan in de rij staat.

De overheid roept iedereen op kalm te blijven, maar benadrukt dat niemand weet wat er gebeurt als de patch uitblijft of niet adequaat blijkt. Daarnaast wordt dringend geadviseerd nergens meer op te klikken, ook niet als uw kleinkind zegt dat het veilig is.

quote:

Op woensdag 21 oktober 2026 15:37 schreef PzKpfw het volgende:
Wel bijzonder dat twee van dit soort cruciale lekken schijnbaar jaren hebben bestaan en nooit eerder zijn ontdekt/misbruikt.

quote:

Op woensdag 21 oktober 2026 15:41 schreef BeriBeri het volgende:
Tweakers is ook offline

quote:

Op woensdag 21 oktober 2026 15:37 schreef PzKpfw het volgende:
Wel bijzonder dat twee van dit soort cruciale lekken schijnbaar jaren hebben bestaan en nooit eerder zijn ontdekt/misbruikt.

quote:

Op woensdag 21 oktober 2026 15:37 schreef Regilio_ het volgende:
Hamas Nederland (The Rights Forum) gooit website ook van het dak.

quote:

Op woensdag 21 oktober 2026 15:42 schreef Saekerhett het volgende:

[..]
Schijnt dat de twin towers ook ingestort zijn.

quote:

Op woensdag 21 oktober 2026 15:41 schreef Tengano het volgende:

[..]

quote:

Op woensdag 21 oktober 2026 15:48 schreef phpmystyle het volgende:
Wanneer zijn de meeste websites weer online? Het begint mij nu ook te irriteren

quote:

Op woensdag 21 oktober 2026 15:50 schreef alpeko het volgende:
Tweakers weer up?

quote:

Op woensdag 21 oktober 2026 15:50 schreef alpeko het volgende:
Tweakers weer up?

quote:

Een programmeertaal is een taal waarmee je een computer vertelt wat hij moet doen. Net zoals je taal gebruikt om met mensen te communiceren, gebruiken programmeurs programmeertalen om websites, apps en software te bouwen.

quote:

Op woensdag 21 oktober 2026 15:49 schreef Zipportal het volgende:
PHPklok overtreden. @:coco

quote:

Op woensdag 21 oktober 2026 15:51 schreef superniger het volgende:
Cybermannetje vanavond bij VI.

quote:

Op woensdag 21 oktober 2026 15:50 schreef Perrin het volgende:

[..]
Terwijl het toch jouw stijl is.

quote:

Op woensdag 21 oktober 2026 15:51 schreef superniger het volgende:
Cybermannetje vanavond bij VI.

quote:

Op woensdag 21 oktober 2026 15:51 schreef superniger het volgende:
Cybermannetje vanavond bij VI.

quote:

Op woensdag 21 oktober 2026 15:54 schreef phpmystyle het volgende:

[..]
Die van de Burg?
Mijn moeder weet nog meer van IT dan die kalende adhd'er.

quote:

Op woensdag 21 oktober 2026 15:55 schreef Zipportal het volgende:
Dave Maasland

quote:

Op woensdag 21 oktober 2026 15:54 schreef phpmystyle het volgende:

[..]
Die van de Burg?
Mijn moeder weet nog meer van IT dan die kalende adhd'er.

quote:

Op woensdag 21 oktober 2026 15:53 schreef alpeko het volgende:

[..]
Was uw website stuk

quote:

Op woensdag 21 oktober 2026 15:54 schreef phpmystyle het volgende:

[..]
Die van de Burg?
Mijn moeder weet nog meer van IT dan die kalende adhd'er.

quote:

Op woensdag 21 oktober 2026 15:59 schreef raptorix het volgende:

[..]
Ik durf te zeggen dat hij meer van IT weet dan jij.

quote:

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.

Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.

The vulnerabilities:

RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.
RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.
How to update:

Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Source downloads are on our downloads page. Windows source and binaries are on the same page.
Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.
PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version.
If you rely on the volunteer-maintained rpms.remirepo.net, we urge you to switch to distribution packages or build from source, so you can immediately apply updates. The repo will not have updates today.
Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.
If you cannot update immediately: while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.

RCE via OOM corruption (CVE-2026-109618):

Set memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
Set a low post_max_size. For applications that don't require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.
Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.
RCE via stale global state (CVE-2026-109619):

Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.
On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help.
Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing and cleanup.
The advisories linked above have the full technical details.

quote:

For installations that cannot update, setting and enforcing memory_limit=-1 administratively is the primary configuration mitigation. It removes the predictable per-request limit that enables the confirmed exploit with a controllable OOM. This is not a complete mitigation. If mmap() or another underlying allocation fails, PHP can still use longjmp() while incomplete request memory is reachable. Restart every PHP worker and confirm that no pool, directory or application setting restores a finite PHP memory limit.

quote:

For PHP 8.5 installations that cannot update, set fatal_error_backtraces=0 administratively and restart every worker. This removes the producer used by the confirmed RCE case. It does not cover other request-owned global or extension state.

quote:

Op woensdag 21 oktober 2026 15:55 schreef Zipportal het volgende:

[..]
Dave Maasland

quote:

Op woensdag 21 oktober 2026 15:41 schreef Tengano het volgende:

[..]

quote:

Over the past two months, we led a coalition of maintainers, researchers, and security providers to address critical vulnerabilities in PHP, an open-source programming language used to run websites and web applications. Calif identified a critical flaw using GPT‑5.6 Sol as part of our Patch the Planet⁠(opens in a new window) initiative, with Wiz also independently discovering and reporting both vulnerabilities. PHP’s maintainers led the fixes and release, with our teams and partners like Wiz, Cloudflare, and others contributing research, technical support, and coordination to prepare protections ahead of disclosure.

For organizations using PHP, the priority now is applying the fixes. We’re sharing a PHP version checker and we will be launching an accompanying Codex skill to help operators identify potentially vulnerable PHP versions and, alongside PHP’s and their providers’ guidance, determine which updates apply.

Given the severity of these flaws and PHP’s widespread use, we consider this one of the most impactful security issues in recent memory. It highlights how AI can uncover security flaws with internet-scale impact, but the same capabilities can also help attackers rapidly develop offensive tools and exploits.

To our knowledge, frontier AI found these vulnerabilities before attackers did, opening a Defender’s Window for maintainers and security providers to prepare fixes and protections ahead of disclosure.

quote:

Op woensdag 21 oktober 2026 16:22 schreef beefkeek het volgende:
- laat ook maar, is 't niet waard -

quote:

Op woensdag 21 oktober 2026 16:31 schreef Firuze60 het volgende:
Als digibeet begrijp ik dat het allemaal wel meeviel? Had mij al voorbereid om eens eindelijk die ongelezen papieren boeken maar eens te gaan lezen.

quote:

Op woensdag 21 oktober 2026 16:33 schreef raptorix het volgende:

[..]
De update is heel simpel, maar doe je het niet dan valt het ook niet mee, je zal de komende tijd heel wat sites zien die gehacked zijn vermoed ik

quote:

Op woensdag 21 oktober 2026 14:39 schreef Zipportal het volgende:
FOK servers langs het spoor doen het nog. @:rambodirk

quote:

Op woensdag 21 oktober 2026 16:35 schreef beefkeek het volgende:

[..]

Dit laat (jammer genoeg) vooral zien hoeveel websites hun zootje niet op orde hebben.

quote:

Op woensdag 21 oktober 2026 16:35 schreef beefkeek het volgende:

[..]
Het komt wel aardig overeen met wat ik eerder aangaf. Als je AppArmor of SELinux gebruikt en een gebruikersaccount met beperkte rechten zonder interactieve shell gebruikt is het effect hiervan beperkt.

Dit laat (jammer genoeg) vooral zien hoeveel websites hun zootje niet op orde hebben. Ik ben benieuwd waarom veel van de websites besloten hebben op zwart te gaan, want de informatie die tot nu toe beschikbaar is laat niet echt zien dat 't echt nodig was.

quote:

Well patching for PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. is actually quite easy. Source downloads are on our downloads page. Windows source and binaries are on the same page. Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version. If you rely on the volunteer-maintained rpms.remirepo.net, we urge you to switch to distribution packages or build from source, so you can immediately apply updates. The repo will not have updates today. Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.


Set memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path. Set a low post_max_size. For applications that don't require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length. Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure. Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants. On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only. Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help. Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing cleanup and you're good to go.

quote:

Op woensdag 21 oktober 2026 16:42 schreef raptorix het volgende:

[..]
Veel organisaties hebben ook geen goede CMDB met wat er gebruikt word, hoewel we die hier hebben is er toch nog voor de zekerheid alles langsgelopen, mijn manager op vrije dag had het er maar druk mee
Maar goed kan me het ook wel voorstellen, als ik CEO was, en ik zou moeten kiezen voor 1% dat de kans dat je gehacked word, of een paar uurtjes down dan zou ik het wel weten, het is ook een stukje PR: KIJK wij doen alles aan security.

quote:

Op woensdag 21 oktober 2026 16:47 schreef beefkeek het volgende:

[..]
Shodan heeft eerder vandaag ~900k websites gevonden die hun PHP versie adverteerden en die lager dan 8.1 was. Die is eind vorig jaar end of life gegaan. Dat vind ik best zorgelijk.

Ik weet het niet. Ik vond de beschikbare informatie van php.net en andere onderzoekers ook wel heel summier. php.net gooit zo'n boodschap eruit zonder eruit te gooien welke workarounds of mitigaties er mogelijk zijn. Ik heb ook veel informatie via andere partijen als leveranciers enzo gekregen, maar dit had gewoon op de php.net website moeten staan.

quote:

Op woensdag 21 oktober 2026 16:51 schreef raptorix het volgende:

[..]
Ja, als je bij grotere organisaties rondloopt die wat minder mature zijn zie je allemaal van die spookapplicaties draaien, waarvan vaak niemand weet of het nog gebruikt word, of van die dingen die tijdelijk zijn neergezet, het zijn er natuurlijk veel meer omdat de meest beheerders de versie headers uit zetten, weet niet of Shodan op een andere manier ook checked, maar goed.

quote:

De ontwikkelaars van PHP hebben twee patches beschikbaar gesteld. Die zijn gemaakt om de ontdekte kwetsbaarheden te dichten. Beheerders van websites hebben het dringende advies gekregen om de reparaties zo snel mogelijk door te voeren. Daarna kunnen veel sites weer online, is de verwachting.

Of de problemen daarmee direct verholpen zijn? ,,Dat denk ik niet eerlijk gezegd", zei directeur van het NCSC Corine Schipper-Derkse eerder al om de verwachtingen te temperen. ,,Het zal even duren voordat de patch is aangebracht. En dan zal er ook nog controle nodig zijn. Maar er wordt heel hard aan gewerkt om de overlast zo veel mogelijk te beperken."

Websites kunnen na het doorvoeren van de belangrijke update om de kwetsbaarheden van PHP op te lossen, mogelijk niet allemaal direct weer online, volgens Schipper-Derkse. ,,Sommige websites kunnen een knop omzetten, maar voor andere websites kan het langer duren. Dat is afhankelijk van welke versie ze gebruiken."

quote:

Op woensdag 21 oktober 2026 16:29 schreef Tengano het volgende:

[..]

quote:

Op woensdag 21 oktober 2026 16:10 schreef beefkeek het volgende:
@:The-BFG De enige dag in de geschiedenis dat het meeste van het internet op de meest recente PHP versie zal draaien

quote:

Op woensdag 21 oktober 2026 17:07 schreef Nattekat het volgende:

[..]
Hij dacht dat ik een verontschuldiging aan ging bieden ofzo. Had het al genegeerd, dus het was in ieder geval wederzijds

quote:

Op woensdag 21 oktober 2026 17:09 schreef beefkeek het volgende:

[..]
Fijn dat we het erover eens zijn dat je onzinopmerking nergens voor nodig was.

quote:

Op woensdag 21 oktober 2026 17:12 schreef Nattekat het volgende:

[..]
Ja nou ga je er alsnog op in

quote:

Op woensdag 21 oktober 2026 16:51 schreef raptorix het volgende:

[..]
Ja, als je bij grotere organisaties rondloopt die wat minder mature zijn zie je allemaal van die spookapplicaties draaien, waarvan vaak niemand weet of het nog gebruikt word, of van die dingen die tijdelijk zijn neergezet, het zijn er natuurlijk veel meer omdat de meest beheerders de versie headers uit zetten, weet niet of Shodan op een andere manier ook checked, maar goed.

quote:

Op woensdag 21 oktober 2026 17:14 schreef The-BFG het volgende:

[..]
Lol, ik zie het bij bijvoorbeeld de overheid al gebeuren dat iemand ff een VM met PHP in Azure heeft opgespind om er een rooster-tool voor bijv. standby-diensten neer te plempen.

Natuurlijk publiek beschikbaar, want dan konden collega's thuis er ook bij zonder die lastige VPN verbinding..

quote:

Op woensdag 21 oktober 2026 15:51 schreef Caland het volgende:

[..]
En omakutjes.nl?

@:de_boswachter

quote:

Op woensdag 21 oktober 2026 14:22 schreef koemleit het volgende:

[..]
is dat zo? dit is toch heel makkelijk te negeren? (tot je de Sjaak bent)

quote:

Op woensdag 21 oktober 2026 16:42 schreef raptorix het volgende:

[..]

Maar goed kan me het ook wel voorstellen, als ik CEO was, en ik zou moeten kiezen voor 1% dat de kans dat je gehacked word, of een paar uurtjes down dan zou ik het wel weten, het is ook een stukje PR: KIJK wij doen alles aan security.

quote:

Op woensdag 21 oktober 2026 18:45 schreef Middelpunt het volgende:

[..]
1% kans dat je gehacked word loop je altijd wel. Als je bij elk paniek bericht de boel uit zet, gaat het allemaal compleet onwerkbaar worden. Er zijn dagelijks duizenden kwetsbaarheden, ook vele met een hoge score. Bij iedere dreiging uit voorzorg alles uitzetten is dus echt geen optie. Maar je wilt er uiteraard ook niet te lang mee wachten.
Het lijkt me best moeilijk als je dit soort besluiten moet nemen.
In dit geval was het misschien wel goede PR (zeker als je een van de eerste was die actie ondernam), maar dat is ook vooral omdat het duidelijk was dat het heel veel bedrijven treft.
Als het om een specifiekere kwetsbaarheid gaat die niet iedereen raakt, is de perceptie vaak heel anders en krijg je vooral commentaar dat je de beveiliging niet op orde had.
De AH heeft ook 'uit voorzorg' de boel down gebracht. Ik geloof niet dat het hen veel goede PR heeft opgebracht.

De voornaamste reden dat er vandaag zoveel paniek was (zover ik het begrijp) komt doordat het gaat om iets wat op 70% van alle publieke websites draait. En dat was uitgelekt hoe je het kunt misbruiken, waardoor het voor criminelen relatief eenvoudig is om er mee aan de haal te gaan.
Als iets lek is, maar niemand weet waar het lek zit, is het risico immers een stuk lager.

quote:

Op woensdag 21 oktober 2026 18:45 schreef Middelpunt het volgende:

[..]
1% kans dat je gehacked word loop je altijd wel. Als je bij elk paniek bericht de boel uit zet, gaat het allemaal compleet onwerkbaar worden. Er zijn dagelijks duizenden kwetsbaarheden, ook vele met een hoge score. Bij iedere dreiging uit voorzorg alles uitzetten is dus echt geen optie. Maar je wilt er uiteraard ook niet te lang mee wachten.
Het lijkt me best moeilijk als je dit soort besluiten moet nemen.
In dit geval was het misschien wel goede PR (zeker als je een van de eerste was die actie ondernam), maar dat is ook vooral omdat het duidelijk was dat het heel veel bedrijven treft.
Als het om een specifiekere kwetsbaarheid gaat die niet iedereen raakt, is de perceptie vaak heel anders en krijg je vooral commentaar dat je de beveiliging niet op orde had.
De AH heeft ook 'uit voorzorg' de boel down gebracht. Ik geloof niet dat het hen veel goede PR heeft opgebracht.

De voornaamste reden dat er vandaag zoveel paniek was (zover ik het begrijp) komt doordat het gaat om iets wat op 70% van alle publieke websites draait. En dat was uitgelekt hoe je het kunt misbruiken, waardoor het voor criminelen relatief eenvoudig is om er mee aan de haal te gaan.
Als iets lek is, maar niemand weet waar het lek zit, is het risico immers een stuk lager.

quote:

Op woensdag 21 oktober 2026 18:49 schreef halfway het volgende:
Dat wordt wat als A.I een kwantumcomputer gaat hacken.

.

quote:

Op woensdag 21 oktober 2026 18:20 schreef Perrin het volgende:
Stukje paniek.

[ x ]

quote:

Op woensdag 21 oktober 2026 20:32 schreef voetbalmanager2 het volgende:

[..]
[ x ]

quote:

Op woensdag 21 oktober 2026 20:29 schreef raptorix het volgende:

[..]
Nee 1% loop je niet als je je boel echt op orde hebt, ik en een aantal anderen hier in het topic werken bij organisaties die hun security dermate op orde hebben, dat die kans eerder rond de 1/1000e procent gaat, dat komt door de defense in depth strategie, dus je gaat op alle ringen verdedigen, het lek waarbij het hier om gaat zijn websites die open en bloot aan het internet hangen.

quote:

Op woensdag 21 oktober 2026 20:48 schreef Adames het volgende:

[..]
Ja daarom ging zelfs het ncsc offline.

quote:

Onze excuses, we zijn tijdelijk offline

Er is een kritieke kwetsbaarheid ontdekt in PHP, een programmeertaal die veel wordt gebruikt voor websites en online applicaties. Om onze systemen te beschermen, hebben we besloten om een aantal diensten, waaronder bnnvara.nl tijdelijk offline te halen.

We werken aan de benodigde beveiligingsmaatregelen. Kom vooral morgen weer even langs!

quote:

Op woensdag 21 oktober 2026 20:51 schreef raptorix het volgende:

[..]
Zelfs het NCSC
Je beseft dat die mongolen deze 9-10 vulnerability niet eens op hun advisory list hadden staan? Niet gister, Niet vandaag. Ga mij alsjeblieft even niet de les lezen ja.

Hier staat er nog steeds niet bij: https://advisories.ncsc.nl/

quote:

Op woensdag 21 oktober 2026 21:09 schreef Adames het volgende:

[..]
Staat er gewoon op

Je kan best kritiek hebben op het ncsc maar als je ze weg zet als mongolen en ondertussen met boude statements als gewoon je security op orde hebben op een public facing website dan is er niks aan de hand, kan ik je weinig serieus nemen.

quote:

Op woensdag 21 oktober 2026 21:11 schreef -XOR- het volgende:
PHP

quote:

Op woensdag 21 oktober 2026 21:15 schreef Monolith het volgende:

[..]
Voegt niets toe als programmeertaal en al helemaal niet als user.

quote:

Op woensdag 21 oktober 2026 21:14 schreef raptorix het volgende:

[..]
Dan hebben ze hem zeer recent toegevoegt, hij stond er eerder niet op. Voor jouw informatie ik zit al mijn hele leven in IT security, dus ik denk enigzins recht van spreken te hebben. Iedereen weet tegenwoordig met de huidige stand van AI dat snelheid King is, die slakken bij NCSC hadden niet eens een fallback geregeld als communicitatie kanaal, weet je toevallig iets over Cyber resilience? Daar hebben dit soort jokers hun mond over vol, maar ze hebben dus zelf niks geregeld, en vallen dus 0,0 serieus te nemen.

quote:

Op woensdag 21 oktober 2026 21:24 schreef Adames het volgende:

[..]
Nou toevallig, ik zit ook in Cyber Security en ik heb een andere mening.

Het is een risico afweging. Ik vind het ook wat overdreven om alle websites offline te halen, maar zeker zulke publieke websites worden gewoon een enorm doelwit en je staat enorm voor lul als je website wordt gepakt door een groot lek.
En groot is het, dat beaam je zelf ook. De kans dat het nog tamelijk onbekende lek ergens op een tamelijk complexe website misbruikt kan worden is groter dan die 0,1% die jij schetst.

Als de website dan maar een matig bedrijfsdoel heeft, dan trek je hem inderdaad maar offline en wacht je een paar uur op de patch.

quote:

Op woensdag 21 oktober 2026 21:11 schreef -XOR- het volgende:
PHP

quote:

Op woensdag 21 oktober 2026 21:24 schreef Adames het volgende:

[..]
Nou toevallig, ik zit ook in Cyber Security en ik heb een andere mening.

Het is een risico afweging. Ik vind het ook wat overdreven om alle websites offline te halen, maar zeker zulke publieke websites worden gewoon een enorm doelwit en je staat enorm voor lul als je website wordt gepakt door een groot lek.
En groot is het, dat beaam je zelf ook. De kans dat het nog tamelijk onbekende lek ergens op een tamelijk complexe website misbruikt kan worden is groter dan die 0,1% die jij schetst.

Als de website dan maar een matig bedrijfsdoel heeft, dan trek je hem inderdaad maar offline en wacht je een paar uur op de patch.

quote:

Op woensdag 21 oktober 2026 21:29 schreef Firuze60 het volgende:

[..]
Met mijn digibete logica denk ik dan ook, waar maak je je druk om als je een site hebt zonder een economisch belang als die een paar dagen plat ligt.

quote:

Op woensdag 21 oktober 2026 21:30 schreef ChevyCaprice het volgende:

[..]
Wat is mis met PHP

Is goeie manier om dynamische pagina's te maken

quote:

Op woensdag 21 oktober 2026 21:31 schreef raptorix het volgende:

[..]
We hebben het hier over het officiele instituut dat Nederland moet informeren wat te doen.

quote:

Op woensdag 21 oktober 2026 21:18 schreef Discombobulate het volgende:
Zit er echt op te wachten dat A.I.'s kwetsbaarheden kunnen vinden of zelfstandig kunnen hacken. We hadden laatst immers die hack door een A.I. Dat kan nog vele malen erger en we kunnen zelf de gevolgen niet overzien.

Ik denk dat dat moment snel gaat komen.

quote:

Op woensdag 21 oktober 2026 21:33 schreef Firuze60 het volgende:

[..]
Huh? Welk Nederland? Dat cybersecurity platform?

quote:

Op woensdag 21 oktober 2026 21:34 schreef beefkeek het volgende:

[..]
Deze kwetsbaarheid is (grotendeels) gevonden door AI

quote:

Op woensdag 21 oktober 2026 21:35 schreef raptorix het volgende:

[..]
Sorry las je bericht verkeerd.

quote:

Op woensdag 21 oktober 2026 21:37 schreef Firuze60 het volgende:

[..]
Nee, ik die van jou, jij doelde op NSCS toch?

quote:

Op woensdag 21 oktober 2026 21:18 schreef Discombobulate het volgende:
Zit er echt op te wachten dat A.I.'s kwetsbaarheden kunnen vinden of zelfstandig kunnen hacken. We hadden laatst immers die hack door een A.I. Dat kan nog vele malen erger en we kunnen zelf de gevolgen niet overzien.

Ik denk dat dat moment snel gaat komen.

quote:

Op woensdag 21 oktober 2026 21:36 schreef raptorix het volgende:

[..]
Het zou me trouwens ook niet verbazen als deze kwetsbaarheid gevonden is tijdens een "opdrachtje" en dat ze het verpakt hebben als: Kijk eens hoe keurig wij zijn, we hebben een gevaarlijk lek gevonden.

quote:

Op woensdag 21 oktober 2026 21:31 schreef raptorix het volgende:

[..]
We hebben het hier over het officiele instituut dat Nederland moet informeren wat te doen.

quote:

Op woensdag 21 oktober 2026 21:40 schreef Adames het volgende:

[..]
Grappig dat je zegt dat ze Mongolen zijn en tegelijkertijd heel Nederland afhankelijk van hun info.

quote:

Op woensdag 21 oktober 2026 21:38 schreef raptorix het volgende:

[..]
Ik bedoelde meer, dat het onacceptabel is dat hun website niet beschikbaar meer is.

quote:

Op woensdag 21 oktober 2026 21:39 schreef beefkeek het volgende:

[..]
Nee er is bewust gezocht naar kwetsbaarheden in PHP doordat het zo wijdverspreid is. Wiz heeft er een goede blog over: https://www.wiz.io/blog/php2shell-php-rce

quote:

Op woensdag 21 oktober 2026 21:47 schreef beefkeek het volgende:

[..]
Ik vind wel dat dit duidelijk heeft gemaakt dat die weerbaarheid ook niet digitale middelen moet omvatten. Op het moment dat er iets als dit aan de hand is en de meeste informatievoorziening ligt plat heb je geen (eenvoudige) manier je bevolking te bereiken.

Nu is dat voor een issue als dit ook niet direct nodig, maar als er een grote kwetsbaarheid misbruikt zou worden en alles wat nu gecontroleerd plat ging ongecontroleerd zou zijn geweest, hoe ga je dan nog communiceren met de overheid? Hoe kun je nog bij je geld, verzekering etc?

Cyberweerbaarheid heeft het NCSC inderdaad zijn mond vol van, maar daar hoort ook offline bij.

quote:

Op woensdag 21 oktober 2026 21:49 schreef The-BFG het volgende:

[..]
Ik las ergens dat de ontwikkelaars van PHP al een aantal jaren een vermoeden hadden dat er een lek in zat. Alleen werdt men het niet eens over de oplossing.

Was wel een nieuws website dus vermoedelijk is daar ook iets niet helemaal goed gegaan om eea begrijpbaar te maken voor leken.

quote:

Op woensdag 21 oktober 2026 21:49 schreef raptorix het volgende:

[..]
Ken daar mooi voorbeeld van, XS4ALL had heel lang een storing pagina op ik meen RTL Teletekst.
Overigens is deze oplossing er wel, Regionale Radiozenders, deze hebben de officieel functie, misschien dat ze daar gebruik van kunnen maken

quote:

Op woensdag 21 oktober 2026 22:01 schreef George_of_the_Jungle het volgende:
De hele dag hier in het VK niks erover. BBC plaatste pas rond 18u een artikel erover. Maar daar stond dan wel in dat ze een deel van hun eigen websites offline hadden gehaald. Ook websites van (lokale) overheden plat. Maar dus niks op grote nieuwssites erover. Alleen een bericht op de site van het National cyber security Center, om klaar te staan om je sites onmiddellijk te updaten als de patch er is, en als je dat niet kunt je site offline te halen. Maar wij kijkt daar nu op? En in NL was het overal de headliner met liveblogs etc. Bizar om zo'n verschil te zien.

quote:

Op woensdag 21 oktober 2026 22:01 schreef Chandler het volgende:
Moet wel zeggen dat ik niet vaak zie dat ICTers allemaal zo hard aan't werk zijn!

Heb al verschillende meldingen van bedrijven gehad dat ze het probleem hebben opgelost!

quote:

Op woensdag 21 oktober 2026 21:53 schreef beefkeek het volgende:

[..]
Ja, maar dat is voor crisiscommunicatie. Ik bedoel iets wat laagdrempeligers. Vrijwel alles moet online nu, maar wat is het offline alternatief? Wat is de BCP?

quote:

Op woensdag 21 oktober 2026 22:01 schreef George_of_the_Jungle het volgende:
De hele dag hier in het VK niks erover. BBC plaatste pas rond 18u een artikel erover. Maar daar stond dan wel in dat ze een deel van hun eigen websites offline hadden gehaald. Ook websites van (lokale) overheden plat. Maar dus niks op grote nieuwssites erover. Alleen een bericht op de site van het National cyber security Center, om klaar te staan om je sites onmiddellijk te updaten als de patch er is, en als je dat niet kunt je site offline te halen. Maar wij kijkt daar nu op? En in NL was het overal de headliner met liveblogs etc. Bizar om zo'n verschil te zien.

quote:

Op woensdag 21 oktober 2026 22:30 schreef beefkeek het volgende:

[..]
NCSC UK communiceert veel direct met bedrijven. Daarnaast zijn de UK Cyber Essentials en Cyber Assessment Framework best wel gedetailleerd in hun eisen, waar veel van de (potentiële) mitigaties al in die frameworks genoemd werden. Zij maakten zich in elk geval een stuk minder zorgen.

Iemand noemde het hier al eerder, ik denk dat de situatie rondom de AH hier meegespeeld heeft. Het zal ook geholpen hebben dat mensen best begripvol waren, dus dat de publieke opinie rondom even down zijn best positief was.

quote:

Op woensdag 21 oktober 2026 22:30 schreef beefkeek het volgende:

[..]
NCSC UK communiceert veel direct met bedrijven. Daarnaast zijn de UK Cyber Essentials en Cyber Assessment Framework best wel gedetailleerd in hun eisen, waar veel van de (potentiële) mitigaties al in die frameworks genoemd werden. Zij maakten zich in elk geval een stuk minder zorgen.

Iemand noemde het hier al eerder, ik denk dat de situatie rondom de AH hier meegespeeld heeft. Het zal ook geholpen hebben dat mensen best begripvol waren, dus dat de publieke opinie rondom even down zijn best positief was.

quote:

Op woensdag 21 oktober 2026 21:34 schreef beefkeek het volgende:

[..]
Deze kwetsbaarheid is (grotendeels) gevonden door AI

quote:

In 2024, PHP underwent its first external security audit in years. The PHP Foundation secured funding from the Sovereign Tech Agency to organize this audit through OSTIF, and it was carried out by Quarkslab. While fixing one of the issues Quarkslab reported, a PHP core developer contracted by the PHP Foundation found the first signs of the OOM problem behind CVE-2026-109618. In 2024, a potential exploit for the OOM problem was theorized, but no concrete vectors were found and other concrete issues with clear impact overshadowed these concerns.

To fix the OOM problem, the PHP security team developed several competing approaches, but each came with its own trade-offs: backward compatibility breaks, new denial-of-service potential, or requiring changes to many third-party extensions which seemed impossible to coordinate. The PHP security team, operating on consensus, struggled to choose between these and feared the repercussions of shipping the wrong choice. Combined with the lack of a known path to remote code execution and the small team of core developers with the necessary deep knowledge of the engine occupied with many responsibilities, this decision process caused work on a fix to stall and restart repeatedly over months. We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources. The security team has since started changing its processes, and that work continues, so that decisions can be made by majority and compromises are encouraged.

Building a sustainable professional security organization

Over the last months the way PHP security work is organized has changed considerably. In May 2026, the PHP Foundation created the Ecosystem Security Team, which works alongside the PHP security team on triage, coordination, and hardening. Volker Dusch's work as AI Security Engineer in Residence at the PHP Foundation has significantly improved communication and collaboration between the PHP security team and the Foundation. Alexandre Daubois joined the PHP Foundation in July to help the PHP security team triage, handle, and fix security reports and Daniel Scherzer joined in September to take on hardening work.

Earlier this year, we worked with Alpha-Omega to scan PHP with Anthropic's Claude Mythos. But since the Mythos scan, we have added other tools, including OpenAI's Daybreak Red for validating reports and exploits, alongside sanitizer builds and reproduction environments that match our CI on every platform PHP supports.

The PHP Foundation got the PHP project into the Patch the Planet program, as part of which security firm Calif began an audit of PHP on July 30th, 2026. On August 11th researcher Ryan A at Calif reported an unconditional remote code execution with the same root cause as the OOM problem we had found in 2024. OpenAI independently reported the same root cause on the same day, followed by further attack vectors from OpenAI on September 18th and from Wiz on August 24th. More recently, Trail of Bits has also been auditing PHP. The reports from Calif, OpenAI, and Wiz made the full impact of the OOM problem clear, and from August 11th onward, fixing it became the top priority for all of the PHP Foundation's team working on security. Without the Foundation’s funding it would have been impossible to have multiple people work on this issue full time, eventually through weekends and around the clock to coordinate and communicate with other involved parties.

The growth of AI-assisted research also means the PHP security team receives far more reports than before. As Alexandre Daubois described last week in How the PHP Security Team Handles Your Reports, the team has published 15 CVEs since July 1st and worked through more than 100 reports that turned out to be invalid, duplicates, or not reproducible. AI helps the team validate reports and group reports sharing the same root cause, but a person makes every call and works on every patch.

quote:

Op woensdag 21 oktober 2026 23:14 schreef Chillegast het volgende:

[..]
Niet helemaal. Deze kwetsbaarheid was al bekend sinds 2024. Maar destijds werd het vooral als een theoretisch risico gezien omdat niemand er nog in geslaagd was er misbruik van te maken.

Andere meer concrete dreigingen kregen meer prioriteit. Bovendien bleken alle pogingen om iets aan die kwetsbaarheid te doen ook weer een hoop problemen op te leveren.

Fast forward naar nu: Met GPT-6 als hulpje blijkt deze exploit nu wel uit te buiten. In feite heeft AI het security team achterhaald.

Overigens blijken de kwetsbaarheden al sinds een jaar of 10 te bestaan.
[..]
https://thephp.foundation(...)hening-php-security/

quote:

Op donderdag 22 oktober 2026 08:04 schreef Troel het volgende:
Wat ik het meest bijzondere vind is dat ik van mijn hostingpartij vanochtendvroeg hoorde dat alles geupdate was, maar dat er nog php 8.5.11 draait in plaats van de 8.5.12 die de oplossing geeft voor dit probleem.

Alles maar weer offline dus.

quote:

Op donderdag 22 oktober 2026 08:27 schreef alpeko het volgende:

[..]
Wees blij. Bij mijn hoster kwam ik gister nog altijd niet verder dan 8.0 die sowieso niet gepatched is. 8.0 is al jaren EOL.

quote:

Op donderdag 22 oktober 2026 08:29 schreef Troel het volgende:

[..]
Maar 'nog altijd niet' geeft aan dat je dat weet, dus dan kun je toch op zoek naar een andere partij? Of denk ik nu te simpel

quote:

Op donderdag 22 oktober 2026 08:31 schreef alpeko het volgende:

[..]
Nee je denkt zeker niet te simpel Luiheid denk ik. Het is ook maar een hobby site waar weinig mee deed. Maar om even aan te geven hoe laks sommige hostingpartijen zijn. En hun klanten. Waaronder ik zelf Qua werk is het een ander verhaal hoor maar dat is geen php uiteraard.

quote:

Waarom zie ik toch oudere versie-nummers van PHP?
Antagonist maakt gebruik van enterprise software waarbij betrouwbaarheid en veiligheid boven nieuwe onvoldoende getest functionaliteit gaat. We draaien hierdoor oudere bewezen versies, met aanvullende security patches. Indien je enkel naar versie-nummers kijkt kan je hierdoor een (oudere) versie-nummer zien dan je zou verwachten. Kijk je echter naar de BuildDate van de software zul je zien dat deze wel actueel is.

quote:

Op donderdag 22 oktober 2026 10:01 schreef William_Papadin het volgende:
[ x ]

quote:

Op donderdag 22 oktober 2026 10:04 schreef Since2003 het volgende:
Was dus toch fophef.

quote:

Op donderdag 22 oktober 2026 10:01 schreef William_Papadin het volgende:
[ x ]

quote:

Op woensdag 21 oktober 2026 22:50 schreef FlippingCoin het volgende:

[..]
Wat voor al dan niet potentiële migraties?

quote:

Websites across world hit by millions of attempts to exploit PHP code flaw

Websites around the world have been hit by millions of attempts to exploit a recently discovered vulnerability in their code, cybersecurity companies have said, as the US National Security Agency warned the flaw could allow attackers to take control of web servers, steal data and disrupt services.
[..]
In an update overnight on Wednesday, and into Thursday, Matthew Prince, the chief executive of cybersecurity company Cloudflare, said the company saw tens of thousands of attempts to exploit the weakness in the 45 minutes after the problem was announced, rising to “hundreds of thousands within two hours, and millions now”.

Amazon Threat Intelligence, another cybersecurity company, added that PHP2Shell, as the vulnerability is known, was “now being broadly exploited in the wild” and said it identified several attempts from multiple actors to test ways to capitalise on the vulnerability before the fix was released by the PHP developers on Wednesday.

Cloudflare also said that in the 10 hours before it was publicly announced, it saw thousands of attempts to exploit the vulnerability, amid concern over the handling of the alert, with one cybersecurity expert, Prof Alan Woodward, saying the flaw was revealed a day before the patch was released, and that “somebody let the cat out of the bag”.
[..]
Criminal groups, state-sponsored hackers, or crypto miners might “nest” themselves into exposed sites using this PHP vulnerability, and then exploit those resources for their own aims. A hacking group could use an exposed site’s IP address to launch attacks that could not then be traced back to it. Crypto miners could use a server’s computing power to run their energy-intensive calculations for free.

It is unclear at what scale this has been done, said Woźniak, and many sites would not even be aware of it.
[..]

quote:

Op donderdag 22 oktober 2026 14:02 schreef crystal_meth het volgende:

[..]
https://www.theguardian.c(...)xploit-php-code-flaw

quote:

Op woensdag 21 oktober 2026 22:40 schreef raptorix het volgende:

[..]
Ja dat was ik, doet me herinneren aan dat ik in 1999 bij een groot marketing bureau werkte, die gaven destijds de case als Iglo Spinazie op (kun je op Googlen), in de jaren 80 gingen er een paar babies dood doordat er een fout in de fabriek was, Iglo ontkende het heel hard wat hun enorme schade opleverde, als ze gewoon direct onderzoek hadden gedaan en open waren geweest hadden ze juist vertrouwen gewonnen, nu kostte dat ze een enorme deuk in reputatie en financieele schade.

quote:

Op woensdag 21 oktober 2026 22:40 schreef raptorix het volgende:

[..]
Ja dat was ik, doet me herinneren aan dat ik in 1999 bij een groot marketing bureau werkte, die gaven destijds de case als Iglo Spinazie op (kun je op Googlen), in de jaren 80 gingen er een paar babies dood doordat er een fout in de fabriek was, Iglo ontkende het heel hard wat hun enorme schade opleverde, als ze gewoon direct onderzoek hadden gedaan en open waren geweest hadden ze juist vertrouwen gewonnen, nu kostte dat ze een enorme deuk in reputatie en financieele schade.

quote:

Op woensdag 21 oktober 2026 22:30 schreef beefkeek het volgende:

[..]
NCSC UK communiceert veel direct met bedrijven. Daarnaast zijn de UK Cyber Essentials en Cyber Assessment Framework best wel gedetailleerd in hun eisen, waar veel van de (potentiële) mitigaties al in die frameworks genoemd werden. Zij maakten zich in elk geval een stuk minder zorgen.

Iemand noemde het hier al eerder, ik denk dat de situatie rondom de AH hier meegespeeld heeft. Het zal ook geholpen hebben dat mensen best begripvol waren, dus dat de publieke opinie rondom even down zijn best positief was.

quote:

Achteraf is het altijd makkelijk praten, zegt cybersecurity-expert Matthijs Koot. „Het rommelige traject heeft wel bijgedragen aan de paniek en de chaos. Maar ook zonder alle ruis is het vaak even rennen en gillen voordat alles gepatcht is. Als het lek inderdaad lastig uit te buiten is, dan is dat een meevaller, want alles wees op het tegendeel: het aanvalsverkeer dat Cloudflare al vroeg zag en de hoge scores die de kwetsbaarheid kreeg toegekend.”

We zijn door het oog van de naald gekropen, zegt Koot. „Het verschijnen van exploit code voordat de patch er is, is een horrorscenario. ”

quote:

Op donderdag 22 oktober 2026 14:19 schreef beefkeek het volgende:

[..]
Tja, als bedrijven nu nog niet gepatched hebben hebben ze 't ook wel een beetje aan zichzelf te danken. Het is niet alsof het als een verrassing komt.

quote:

Op donderdag 22 oktober 2026 08:27 schreef alpeko het volgende:

[..]
Wees blij. Bij mijn hoster kwam ik gister nog altijd niet verder dan 8.0 die sowieso niet gepatched is. 8.0 is al jaren EOL. Ze hebben de stekker er uiteindelijk zelf maar uitgetrokken. En nog steeds.

quote:

Op vrijdag 23 oktober 2026 07:51 schreef Wrapster het volgende:

[..]
Voor Debian based OS'en zou je in dit geval de repo's van Surý kunnen gebruiken, die is druk bezig alles te backporten. Ik gebruik in het geval van PHP sowieso de Sury repo's gezien updates veel sneller beschikbaar zijn dan via Ubuntu zelf.