Home   2026-10-22 19:56:51

←

Amazon: hackers probeerden PHP-lekken al 4 dagen voor bekendmaking te misbruiken

Original article

De PHP2Shell-lekken waardoor woensdag veel websites preventief offline gingen, deden mogelijk al langer de ronde. Amazon zag op 17 oktober al pogingen om de lekken te misbruiken, vier dagen voordat ze bekend werden gemaakt.

Dit nieuws in het kort

  • Een threat actor probeerde de PHP2Shell-kwetsbaarheden afgelopen zaterdag al te misbruiken, zegt Amazon.
  • Dat was vier dagen voordat de kwetsbaarheden openbaar werden gemaakt, al is niet bekend hoe de aanvaller de lekken ontdekte.
  • Inmiddels wordt PHP2Shell grootschalig misbruikt, meldt Amazon.

Amazon Threat Intelligence identificeerde op zaterdag 17 oktober een PHP2Shell-exploitpoging met zijn beveiligingstool MadPot. Dat liet het bedrijf donderdag weten in een persbericht.

De poging was afkomstig van een IP-adres dat wordt gekoppeld aan een commercieel 'anonimiseringsnetwerk'. Volgens Amazon wijst zo'n aanval via een geanonimiseerd IP-adres op een threat actor. Dat is een persoon, groep of organisatie die probeert kwetsbaarheden uit te buiten om schade aan te richten.

Op het moment van de exploitpoging waren de lekken nog onder embargo. Hoe de aanvaller de kwetsbaarheden vroegtijdig ontdekte, is niet bekend.

PHP-gaten. Bron: Tweakers
De gaten in de scriptingtaal PHP werden woensdag openbaar gemaakt. Bron: Tweakers

Meer exploitpogingen sinds woensdag

Op woensdag zag Amazon verschillende andere pogingen om de lekken uit te buiten. De payloads en gebruikte infrastructuur verschilden steeds, wat suggereert dat meerdere partijen probeerden PHP2Shell uit te buiten.

Nadat PHP de patches woensdagmiddag publiceerde, verschenen binnen enkele uren nog meer proof-of-concepts om de kwetsbaarheden uit te buiten. Inmiddels wordt PHP2Shell 'grootschalig misbruikt' in het wild, aldus Amazon. Het bedrijf raadt gebruikers daarom aan om zo snel mogelijk te updaten.

Over PHP

PHP is een veelzijdige scriptingtaal die dynamische webpagina's kan aanmaken. Wereldwijd gebruikt 69,3 procent van alle websites PHP. PHP vormt de basis voor het veelgebruikte WordPress en zit ook in Joomla, Drupal, Magento en andere websoftware.

De impact van de kwetsbaarheden was daarom groot. Verschillende diensten en websites gingen uit voorzorg offline in afwachting van patches, waaronder Tweakers. We schreven woensdag een achtergrondverhaal over PHP, de PHP2Shell-kwetsbaarheden en de gevolgen ervan.

Tweakers neer
Ook Tweakers ging woensdag uit voorzorg offline vanwege PHP2Shell.

Door Daan van Monsjou

Nieuwsredacteur

Feedback • 22-10-2026 15:47
37 • submitter: perry

22-10-2026 • 15:47

37

Submitter: perry

Lees meer

Reacties (37)

Wel ironisch. Gisteren heel veel EC2 machines down moeten halen van klanten omdat de Amazon Linux 2023 repo's de PHP-update nog niet hadden. Die kwam vanochtend pas: https://github.com/amazonlinux/amazon-linux-2023/issues/1148. Absurd. AWS schijnt die update al minimaal een dag te hebben, maar zijn er veel te laat mee gekomen. Totaal geen communicatie in die thread door medewerkers, enkel "awaiting fix", en dat heeft dus meer dan 12 uur geduurd. Uiteindelijk vond ik het wachten mooi geweest en heb ik snel die applicatie in een container laten draaien. Dat was nog sneller ook. Nu alsnog backporten van container naar op de machine zelf de webapp draaien. :+ Wellicht toch maar afstappen van Amazon Linux 2023 (het is weliswaar Fedora-based, maar kritieke fixes moeten gewoon binnen een paar uur beschikbaar komen). In die GitHub thread staat ook dat andere fixes lang op zich moesten wachten.
offtopic:
Voordat ik allerlei spuitelven over mij heen krijg: ja, AWS en Amazon hebben niet dezelfde medewerkers, maar het is en blijft toch absurd lang wachten.

[Reactie gewijzigd door Anonymoussaurus op 22 oktober 2026 16:01]

Had je op AWS de WAF niet aan staan voor je machines met mitigerende firewall rules erin die het verkeer konden controleren? Ik zag in ieder geval dat Cloudflare in hun WAF oplossingen daarvoor bood gisteren dus zou verwachten bij Amazon hetzelfde? Het is een kwestie van dat vinkje aan te zetten toch en je hebt die extra beschermlaag?
Ik had gelezen dat experts en zelfs de PHP core developers hadden gezegd dat een WAF ook niet voldoende is totdat PHP is geüpdatet, tenzij er vanuit AWS een officieel filter was uitgebracht zoals ze gedaan hebben bij Cloudflare. En nee, ik/wij doen alles via Terraform, dus dan komt er wel wat meer bij kijken dan "even een vinkje aanzetten". ;)
Onze accountmanager bij Amazon stuurde de volgende adviezen vandaag, punt 3 is advies WAF te gebruiken indien patchen geen optie is (ik heb er verder geen mening over, maar als ze die optie aanbevelen, zal het vast helpen het risico te beperken, al is patchen altijd beter):
What we recommend you do now
  1. Identify every PHP-based system you run, including CMS platforms, third-party applications, appliances and hosting providers. Prioritize internet-facing systems.
  2. Apply the emergency patches now, starting with internet-facing systems.
  3. Isolate end-of-life PHP systems behind a WAF and network controls until they can be upgraded or retired.
  4. Enable detection for PHP processes spawning shells, which is the signature of exploitation.
  5. Contact your vendors and hosting providers to confirm when their patches will be available.
  6. Make sure your security and operations teams are on standby and ready to respond to incidents.
Ja klopt, maar zoals je al zegt is dat vandaag. Dat zullen ze vandaag wel hebben. Maar gisteravond heb ik alles binnen AWS al gepatcht.
Er zijn zoveel mirrors die slechts eenmaal per x uur door syncen. Naast de CDN’s die ook nog eens een delay erin kunnen hebben zitten. Het verbaast me helemaal niet.
Ja eenmaal per X uur is nogal wat anders dan 1x per 12 uur. Daarnaast ging dit niet om een sync; ze hadden de hele AMI én repo's niet geüpdatet. Dat heeft niks met het synchroniseren an sich te maken. Zelfs cPanel/WHM had de update binnen een uur, en dat is veel sneller dan ik had verwacht van cPanel/WHM, omdat ze niet echt bekend staan om hun rolling releases.

[Reactie gewijzigd door Anonymoussaurus op 22 oktober 2026 16:28]

Het heeft jaren open gestaan en wie weet is het jarenlang al misbruikt.
Ik zag vanuit de PHP Foundation diverse commentaren komen dat hoewel ze bekend waren met het lek, het vooralsnog heel moeilijk bleek een daadwerkelijke exploit ervoor te vinden die het kon misbruiken, tot de afgelopen dagen dus met hulp van AI.

Het lijkt me zeer sterk dat er dan al jaren misbruik gemaakt zou worden van de exploit, bovendien hadden we daar dan al veel eerder de gevolgen van gezien.
Dan ga je je afvragen hoe veel van die exploits zijn er nog meer?
Ja dat is best wel slordig. Ik verwachtte totaal geen snelheid van EasyApache, die kwakkelen doorgaans ook er achteraan met updates, maar die was er gewoon netjes rond 4u. Ongelooflijk dat AWS daar zo traag mee is.
Ik heb wat Ubuntu servers draaien en die heb ik even na 17 uur gepatched en toen stond de update al in de repos. Ik heb niet gecheckt of ze er al eerder waren maar een uur na het releasemoment stonden ze al op de NL mirrors.
Voor de Debian distro die ik gebruik op mijn VPS systemen was de update aanwezig op het moment van de officiele releasetijd zonder enige vertraging.
Zou dit een signaal kunnen zijn, dat 'toevallig bijna gelijktijdig' aan dezelfde bugs en exploits gewerkt wordt, dat AI, of de bedrijven er achter, informatie doorspeelt naar anderen?

Eerder ook dat wiskundige probleem dat OpenAI publiceerde vóór de onderzoekers die aan dat probleem werkten.
Heel simpel uitgangspunt, alles wat je in AI doet kan en zal dienen tot het verbeteren van die AI. We weten dat alle AI leveranciers hun LLM's getraind hebben op gestolen, gehackte en anderszins onterecht verkregen data. We weten dat bedrijven specifiek contracten sluiten om hun data buiten de LLM's proberen te houden nadat van Samsung strategische data op straat kwam te liggen, gelekt via AI modellen gebruikt door medewerkers.

Elke gratis AI account, de meeste goedkopere betaalde accounts, allen gebruiken de data voor verbetering van de AI modellen in hun algemene voorwaarden. Dus denk na wat je er in stopt. De vraag is AH beter dan jumbo is heel wat anders dan als je ingelogd bent met een bultje op je geslachtsdelen en uitlegt wie/wat je partners afgelopen week waren en waar je ondeugend was.
Zou dit een signaal kunnen zijn, dat 'toevallig bijna gelijktijdig' aan dezelfde bugs en exploits gewerkt wordt, dat AI, of de bedrijven er achter, informatie doorspeelt naar anderen?
Of nog simpeler: Insider informatie wordt door medewerkers van die bedrijven doorgespeeld aan buitenlandse inlichtingendiensten. Ook ASML heeft te maken gehad met (ex) medewerkers die informatie naar buitenlandse inlichtingendiensten hebben gelekt. Het zou naief zijn om te denken dat andere landen niet hun best doen om medewerkers te recruteren.
Dit is natuurlijk geen verrassing, ik ben benieuwd hoeveel gekke lekken er nog meer komen nu dat ze AI loslaten op elke letter code. Dit artikel is erg interessant https://blackoutmap.net/blog/php2shell
Hoe kun je de aanvallen nu herkennen in je webserver logs?
Je vind ze o.a op domeinniveau in de http (web)logs (dus de requests naar je website), zoek daarna maar is op shell.
Het zal ook wel bij anderen te vinden zijn maar bijvoorbeeld Sophos heeft in dit artikel gepubliceerd waarop je kunt zoeken in je logs om te zien of er pogingen op jou servers ondernomen zijn dit lek te misbruiken:

https://www.sophos.com/en-us/security-advisories/sophos-sa-20261021-php2shell
Kreeg er net weer 1 binnen...

IP is al bekend om de aanval. Als je m opzoekt is t gewoon een apache2 server. Zal wel automatisch zoeken.

85.11.167.243 - - [22/Oct/2026:14:59:03 +0200] "POST /index.php HTTP/1.1" 444 0 "-" "php2shell-109618"
Geef de domeinnaam maar dan laat ik je zien hoe je het terug vindt In de logs


Bericht niet serieus bedoeld
Vanmorgen tijdens het ontbijt zat ik Goedemorgen Nederland te kijken (want ja, bij gebrek aan beter) en daar zat zo'n veiligheidsexpert te vertellen over de php bug. Dat er inderdaad al signalen waren dat ze gebruikt werden. Mogelijk door overheden. Natuurlijk zijn het eerst de geheime diensten zoals Mossad, CIA, FSB en FBI die hier en daar een backdoor willen forceren zodat er overal en nergens weer informatie vergaard kan worden.
Lees net op Phoronix dat Trend Micro, heel per ongeluk natuurlijk, kernel vulnerabilities heeft gepubliceerd op de kernel mailing list, publiekelijk.

Het lijkt wel de nieuwe trend: bedrijven die maar al te graag laten weten dat ze als een van de eersten op de hoogte waren/sporen zagen van exploits. Beetje zoals die AI bedrijven vertellen over hoe gevaarlijk hun model zou zijn. Kijk dan hoe krachtig het is, het brak gewoon op eigen houtje uit zijn testomgeving!

Het lijkt me een goedkope manier om in de aandacht te komen waar geen consequenties aan hangen. Ze kunnen zich verschuilen achter "er waren geen regels voor" of "oeps, per ongeluk". Hopelijk zit ik er naast.
Ach, nu krijgen we de marketing-laag weer: wij wisten hier al n dagen vanaf! Koop MadPot!
Inmiddels wordt PHP2Shell 'grootschalig misbruikt' in het wild, aldus Amazon.
Ik heb nog geen werkende PoC gezien, wel veel lompe scanners. Lijkt me sterk dit. Vooralsnog deelt geen enkele niet-commerciële instelling deze mening. Maar goed...

[Reactie gewijzigd door eric.1 op 22 oktober 2026 15:59]

Misschien kun je beter de patch bekijken. Overtuig jezelf in plaats van te wachten tot iemand je een PoC toe gaat sturen.
Dat is het punt dus. Ik heb een deel ervan doorgenomen, en wat analyses gelezen van personen die meer PHP kennis bevatten. En daaruit komt juist dat het allemaal niet zo makkelijk te misbruiken valt. Ja, als je wat safe-guards uitzet en anders configuraties gebruikt waarmee je (kwetsbaarheid of niet) een vrij onveilig systeem hebt...dan wel ja.

Een commit van +5k aan niet-test code, door de gehele codebase heen, met een commit-history van een bedenkelijk niveau...alles wijst op "gevonden, geclassificeerd, en gefixt door LLM".

Ja...goed...
Mss zijn we het wel gewoon oneens, met gewoon parsen voordat je in PHP zit triggeren door het verwerken van headers is toch echt RCE. Dat je die LLM kiddies niet vertrouwd begrijp ik wel, wat je leest in berichten is helaas onleesbare jargon en vaak slop. Maar er zijn ook mensen die de ASAN (AddressSanitizer) output hebben gepost als screenshot van hun exploit (mogelijk gemaakt met ai, maar maakt dat uit? ze hebben dus exploits).
Dan zien we dat snel genoeg op het publieke domein verschijnen...:)
Wat dus de vraag oproept: hoe wist Amazon al vier dagen lang hoe je wat nu PHP2Shell heet kunt detecteren (m.a.w. hoe je de kwetsbaarheid uitbuit)?
Zo lees ik het niet. Het is niet dat het niet te detecteren was. Je ziet aanvallen binnenkomen maar weet niet precies waarvoor, maar je ziet wel dat ze zich op PHP richten.
Door terug te kijken in de logs neem ik aan, op het moment zelf zullen ze dit inderdaad nog niet aan deze PHP2Shell hebben kunnen linken.
Omdat ze ws onderdeel van de "responsible disclosure" groep zijn, net zoals andere grote PHP gebruikers/hosters. De tijdslijnen zijn nog veel langer, een paar maanden.
Normaliter ben je als feitelijk kleine totaal onbelangrijke site niet interessant genoeg om door een partij via moeilijk en moeizaam proces aangevallen te worden.
En zo ja, volstaat in 9 van 10 gevallen een soort van simpele cq vertragende fail2ban firewall waarbij je ook kunt laten kijken naar (verkeers)patronen in de weblog en veranderde bestanden.

AI en haar resources veranderen dat speelveld volledig met dat wat nog steeds (mogelijk) heel moeilijk/ingewikkeld was, nu wordt uitgerold door een kiddie die beschikt over een zooi tokens. Met dat die AI-agents zijn te zetten om de operatie uit te voeren.
Met als doel iets aan toegang te verkrijgen of een (vermomde) backdoor voor later te (kunnen) plaatsen.
Zal misschien wel jaren open hebben gestaan maar het goede is AI trekt de beerput nu wel open om het te fixen.
Dat deze fout erin zat was al vele jaren bekend, tegelijkertijd was ook duidelijk dat de complexiteit om het te exploiteren zodanig groot was dat er geen enorm risico aan zat totdat “AI” zich ermee ging bemoeien en er daadwerkelijk een method is gevonden om het te misbruiken.

Traditionele developers/hackers zouden hier zonder twijfel niet zomaar uitgekomen zijn.

Om te kunnen reageren moet je ingelogd zijn