Kort gezegd: Als u vermoedt dat uw server via PHP2Shell is gehackt, neem dan nu contact op. Bent u getroffen? Bel ons. Wij helpen. Vanaf het eerste bericht nemen wij de beheersing over, zetten we de sporen veilig, dichten we het lek, verwijderen we schadelijke code en documenteren we het incident tot het is afgerond.
Verwijder nu niets en zet niets opnieuw op. Verwijderde bestanden en overschreven logboeken zijn de sporen waaruit blijkt of en hoe iemand is binnengedrongen. Haal de server zo nodig van het netwerk, maar laat hem verder ongewijzigd. Meld uw noodgeval, dan vertellen wij u de volgende stap.
Bent u getroffen? Aanwijzingen dat PHP2Shell al is gebruikt
PHP2Shell is de naam voor twee kritieke kwetsbaarheden in PHP zelf, waarmee aanvallers zonder inloggen op afstand schadelijke code kunnen uitvoeren. Een eenduidige vingerafdruk bestaat tot nu toe niet. Daarom telt wat de server doet, niet wat een scanner vindt. Aanwijzingen voor een inbraak zijn:
- Webserver- of PHP-FPM-processen die een shell zoals
shofbashstarten. Dat is een sterk waarschuwingssignaal. - Nieuwe of gewijzigde PHP-bestanden in upload-, cache- of tempmappen die niemand heeft aangemaakt.
- Cronjobs, services of SSH-sleutels die u niet kent.
- Uitgaande verbindingen naar onbekende bestemmingen, plotseling hoge belasting of ongebruikelijk dataverkeer.
- Verzoeken in de logboeken vanaf 17-10-2026, vooral opvallende uploads en sessieverzoeken vóór het installeren van de patch.
- Meldingen van de hostingprovider, browser of zoekmachine over spam, malware of doorverwijzingen.
Meer daarover vindt u onder Ben ik al gecompromitteerd?. Ontbreekt elke aanwijzing, dan is dat geen bewijs voor een schone server. Het betekent alleen dat er tot nu toe niets is opgevallen.
Wat u nu direct doet
- Verander niets. Verwijder geen bestanden, herstel geen back-up en installeer niets opnieuw voordat er een kopie is gemaakt.
- Zet de logboeken veilig. Vraag uw hostingprovider of IT-afdeling om toegangs-, fout- en systeemlogboeken niet te overschrijven. De vakpers adviseert logboeken vanaf 20-10-2026 te bewaren.
- Beslis over de bereikbaarheid. Als er gegevens kunnen weglekken of bezoekers gevaar lopen, haal de site dan van het netwerk of zet hem in onderhoudsmodus.
- Verzamel de toegangen. Noteer wie toegang heeft tot server, beheerpaneel, CMS en database. Wachtwoorden wijzigt u pas na overleg en vanaf een schoon apparaat.
- Informeer de betrokkenen. Directie, functionaris voor gegevensbescherming en, bij een bestaande polis, de verzekeraar.
- Bel of schrijf ons. Hoe eerder wij de situatie kennen, hoe meer er aantoonbaar blijft.
Hoe helpt PHP SOS concreet?
Wij werken op afstand, zonder reistijd, in heel Duitsland en Europa.
- Situatie opnemen: Wij stellen vast welke systemen draaien, welke PHP-uitvoeringsmodus in gebruik is, wat is opgevallen en welke gegevens getroffen kunnen zijn.
- Veiligstellen en dichten: Wij zetten bestanden, database en logboeken veilig en leggen de toestand vast vóór elke wijziging. Daarna dichten we het lek met de patch of, als die nog niet mogelijk is, met tussentijdse maatregelen, en herstarten we alle PHP-processen.
- Controleren en opschonen: Wij zoeken naar webshells, achterdeuren, cronjobs en vreemde toegangen en verwijderen ze, of bouwen de omgeving opnieuw op uit betrouwbare bronnen. De aanpak staat beschreven in Malware en webshells laten verwijderen.
- Beveiligen en rapporteren: Wij vervangen de getroffen geheimen, voeren aanvullende beschermingsmaatregelen door en leveren een rapport dat onderscheid maakt tussen aangetoond, waarschijnlijk en onbekend.
Groeit het incident uit tot meer dan één server, dan gaan we over op gestructureerde Incident Response. Zijn bewijzen nodig die voor de rechter standhouden, dan schakelen we IT-forensisch onderzoek in.
Waarom een patch alleen na een aanval niet volstaat
De kwetsbaarheden zitten in de PHP-interpreter, niet in het CMS. Het PHP-project heeft op 21-10-2026 de versies 8.5.12, 8.4.27, 8.3.36 en 8.2.35 uitgebracht. Wie daarna heeft bijgewerkt en alle workers heeft herstart, is langs deze weg beschermd tegen nieuwe aanvallen. Wat een aanvaller eerder heeft achtergelaten, blijft echter staan: een webshell, een extra account, een geplande taak. Juist daarom zijn de dagen tussen 17 en 21 oktober bijzonder belangrijk.
Daar komt een tweede punt bij: een webshell is vaak slechts de eerste stap. Wie op de webserver code kon uitvoeren, kon ook configuratiebestanden lezen en daaruit toegangsgegevens voor database, e-mail en API's overnemen. Die geheimen moeten worden vervangen, anders blijft de deur open, ook al is PHP gepatcht. Hoe u bestanden en tijdstippen zinvol controleert, beschrijft de gids over het herkennen van webshells.
Meldplicht en documentatie
Als persoonsgegevens getroffen kunnen zijn, kan een melding aan de toezichthouder binnen 72 uur nodig worden. De klok loopt vanaf het moment van kennisname, niet vanaf de afronding van het onderzoek. Of uw geval meldingsplichtig is, beslist uw functionaris voor gegevensbescherming of een advocaat; rechtsadvies geven wij niet. Onze documentatie levert daarvoor de basis. Meer over de termijn staat onder AVG-meldplicht binnen 72 uur, de stappen daarna in de checklist na een hack.
Wat u ons het best kunt sturen
- Beschrijving van wat sinds wanneer opvalt en wie het heeft opgemerkt
- Soort server: eigen server, managed server of hostingpakket, plus de hostingprovider
- Resultaat van
php -ven, indien bekend, de uitvoeringsmodus (PHP-FPM, mod_php, LiteSpeed) - Tijdstip van de PHP-update, als die al is geïnstalleerd
- Toegang tot de server of toestemming om met uw hostingprovider te spreken
- Contactpersoon met beslissingsbevoegdheid voor uitschakelen en herstarten
Waarom PHP SOS
Wij werken Made in Germany en zijn met ons partnernetwerk van cyberprofessionals al meer dan 25 jaar gespecialiseerd in IT-beveiliging. U hebt één aanspreekpunt dat u vanaf het eerste bericht tot de afronding begeleidt. Alles wat wij doen wordt gedocumenteerd, zodat u het kunt aantonen tegenover directie, verzekeraar en autoriteiten. Wij beloven niets wat niemand kan waarmaken: ontbreken er logboeken, dan zeggen we dat openlijk, en we benoemen wat aangetoond is en wat een vermoeden blijft.
Bent u getroffen? Bel ons. Wij helpen.
Wacht niet tot het vermoeden zekerheid wordt. Bel ons of stuur een bericht via WhatsApp. Wij nemen het over vanaf het eerste bericht en blijven erbij tot het incident is afgerond en gedocumenteerd. Meld nu uw noodgeval.
Veelgestelde vragen
Is het genoeg om PHP bij te werken als mijn server misschien al is gehackt?
Nee. De update dicht het lek, maar verwijdert geen malware die er al is ingebracht en bewijst niet dat er daarvoor niets is gebeurd. Na de patch moet de server worden gecontroleerd op sporen van een inbraak.
Hoe herken ik een geslaagde PHP2Shell-aanval?
Er zijn geen gepubliceerde, bevestigde Indicators of Compromise. Detectie berust op gedrag: webserverprocessen die een shell starten, nieuwe PHP-bestanden in upload- of cachemappen, onbekende cronjobs of SSH-sleutels en opvallende uitgaande verbindingen.
Moet ik de server van het netwerk halen als ik een inbraak vermoed?
Dat is vaak juist, want het BSI (de Duitse federale dienst voor informatiebeveiliging) adviseert zelfs als een update niet direct mogelijk is om de webserver tijdelijk van het netwerk te halen. Belangrijk is dat u daarbij niets verwijdert en logboeken en bestanden bewaart, zodat het incident kan worden opgehelderd.
Moet ik na een PHP2Shell-aanval de toezichthouder voor gegevensbescherming informeren?
Als persoonsgegevens getroffen kunnen zijn, kan een melding binnen 72 uur nodig zijn. U beslist daarover samen met uw functionaris voor gegevensbescherming of een advocaat; wij leveren daarvoor de technische feiten.
Zijn er echt al servers via PHP2Shell gehackt?
Volgens berichten in de media waren er vanaf 17-10-2026 de eerste waargenomen aanvalspogingen, en Cloudflare meldde waargenomen aanvalspogingen. Het BSI meldde aanvankelijk geen bevestigde geslaagde aanvallen op brede schaal. In een concreet geval is dat alleen op de server zelf vast te stellen.