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