Kort gezegd: Heeft uw PHP-server problemen en wilt u direct met een expert spreken, bel ons dan of stuur een bericht via WhatsApp. Bent u getroffen? Bel ons. Wij helpen. Wij stellen op afstand vast of er een storing, een foutieve configuratie of een aanval achter zit, en nemen het over vanaf het eerste bericht, tot het incident is afgerond en gedocumenteerd.
Verwijder nu niets en zet niets opnieuw op. Ook een herstart of rollback kan sporen uitwissen. Vertel ons eerst wat u ziet. Meld uw noodgeval, daarna bepalen we de volgende stap.
Bent u getroffen? Deze storingen zijn een zaak voor ons
Niet elke storing is een aanval, maar in deze dagen loont het om te kijken. Neem contact op als zich bij uw PHP-systeem het volgende voordoet:
- PHP-processen of de webserver vallen uit, starten steeds opnieuw of worden door het systeem beëindigd (exitstatus 137).
- De belasting stijgt zonder aanwijsbare reden of het geheugen loopt vol.
- Pagina's leveren lege antwoorden, 500-fouten of foutmeldingen die er eerder niet waren.
- Onder de webserver of PHP-FPM draaien processen die een shell starten.
- In de upload- of cachemap staan PHP-bestanden die u niet kent.
- Na een PHP-update werkt een toepassing niet meer.
- Uw hostingprovider heeft de toegang geblokkeerd of de site uitgeschakeld.
Het verschil tussen storing en aanval blijkt meestal pas uit de logboeken. Eerste aanwijzingen waar het op aankomt, beschrijft het artikel Webserver start een shell.
Wat u nu direct doet
- Observeer voordat u ingrijpt. Noteer tijdstip, foutmeldingen en wat er het laatst is gewijzigd (update, plugin, configuratie).
- Zet de logboeken veilig. Kopieer webserver-, PHP- en systeemlogboeken weg voordat ze roteren. De vakpers adviseert logboeken vanaf 20-10-2026 te bewaren.
- Herstart niet blind. Een herstart verhelpt sommige storingen, maar vernietigt vluchtige sporen. Herstart als de bedrijfsvoering het vereist, en noteer wat u hebt gedaan.
- Weeg de bereikbaarheid af. Vermoedt u een aanval, dan is afschermen of uitschakelen vaak juist. Het BSI adviseert dat als een update niet direct mogelijk is.
- Stel de PHP-versie vast.
php -vtoont de versie, maar niet altijd die van de webserver-runtime. - Bel of schrijf. Hoe preciezer u de situatie kunt schetsen, hoe sneller wij bij de kern zijn.
Hoe helpt PHP SOS concreet?
Wij werken op afstand, zonder reistijd, in heel Duitsland en Europa.
- Situatie opnemen: In het eerste gesprek luisteren we en vragen gericht door: systemen, PHP-uitvoeringsmodus, tijdstip, laatste wijzigingen. Daarna weet u of wij een storing of een vermoeden van een aanval zien.
- Veiligstellen en dichten: Wij zetten de toestand veilig, verhelpen de oorzaak en dichten zo nodig het lek met update, herstart en tussentijdse maatregelen.
- Controleren en opschonen: Blijkt er een inbraak, dan verwijderen we schadelijke code en controleren we toegangen en geheimen. Anders documenteren we de oorzaak en laten we de bedrijfsvoering schoon doordraaien.
- Beveiligen en rapporteren: U krijgt een kort rapport en aanbevelingen, zodat de storing zich niet herhaalt.
Zit er meer achter, dan gaan we over naar de noodhulp bij een gehackte website of naar gestructureerde Incident Response.
Geheugen, uitval en de nieuwe limiet
Sinds de beveiligingsreleases van 21-10-2026 (8.5.12, 8.4.27, 8.3.36, 8.2.35) bestaat de directive memory_hard_limit_percent. Sindsdien is memory_limit een zachte grens. Zonder eigen instelling geldt als harde grens het dubbele van memory_limit tot 1G, daarboven memory_limit plus 1G. Wordt die overschreden, dan eindigt het proces direct met exitstatus 137. Een omgeving die vóór de update dicht tegen de limiet zat, kan daardoor plotseling uitval vertonen. Dat is geen aanval, maar een gevolg van de correctie, en de oplossing is de toepassing of de limiet netjes aan te passen, niet de update terug te draaien.
Omgekeerd geldt: wie gecrashte processen ziet en nog niet is gepatcht, moet dat niet als toeval afdoen, want het lek CVE-2026-109618 hangt samen met een out-of-memory-toestand. Of dat bij u een rol speelt, tonen de logboeken. Achtergronden over geheugenbeheer vindt u onder Out-of-memory in PHP, mogelijke tekenen van inbraak onder Verdachte processen onder Linux.
Als de hostingprovider ingrijpt
Sommige aanbieders blokkeren accounts of halen sites preventief offline. Dat betekent niet automatisch dat u bent gehackt, maar kan een gevolg zijn van opvallende zaken. Vraag naar de reden en het tijdstip, vraag om de logboeken en leg vast wat de aanbieder eist. Wij stemmen af met uw hostingprovider als u dat wenst. Het is zinvol vooraf te bepalen wie bij de aanbieder beslissingen mag nemen en of daar logboeken van de server beschikbaar zijn die u zelf niet kunt inzien. Zulke gegevens, bijvoorbeeld toegangen op netwerkniveau, kunnen later doorslaggevend zijn om het tijdstip van een mogelijke inbraak af te bakenen.
Wat u ons het best kunt sturen
- korte beschrijving: wat is uitgevallen of opvallend, sinds wanneer?
- soort systeem (eigen server, hostingpakket, container) en hostingprovider
- uitvoer van
php -v, uitvoeringsmodus en webserver, voor zover bekend - foutmeldingen of fragmenten uit de logboeken
- tijdstip van de laatste PHP-update en laatste wijzigingen
- contactpersoon met beslissingsbevoegdheid voor herstarts
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 spreekt met een vast aanspreekpunt in plaats van met een ticketsysteem. Wij werken op afstand, documenteren wat we zien en doen, en zeggen openlijk wat aangetoond is en wat niet. Voor acute gevallen rond het lek is er bovendien de PHP2Shell-noodhulp.
Bent u getroffen? Bel ons. Wij helpen.
Heeft uw PHP-server problemen, wacht dan niet op de volgende uitval. Bel ons of stuur een bericht via WhatsApp. Wij nemen het over vanaf het eerste bericht. Meld nu uw noodgeval.
Veelgestelde vragen
Mijn PHP-server is plotseling traag of crasht: is dat een aanval?
Niet per se. Storingen hebben vaak banale oorzaken, zoals te weinig geheugen, een foutieve update of overbelasting. Pas een blik in logboeken en processen laat zien of het een aanval is; waarschuwingssignalen zijn bijvoorbeeld shellprocessen onder de webserver of onbekende nieuwe PHP-bestanden.
Wat betekent exitstatus 137 bij PHP-processen?
Status 137 staat voor een direct beëindigd proces. Volgens de PHP-handleiding eindigt een proces met 137 als het de harde geheugengrens van de nieuwe directive memory_hard_limit_percent overschrijdt; het kan echter ook door het systeem wegens geheugentekort zijn beëindigd. De oorzaak blijkt uit de logboeken.
Kan ik met een expert bellen voordat ik iets wijzig?
Ja, daar is de noodhulp precies voor. Bel ons of stuur een bericht via WhatsApp en beschrijf wat u opvalt. Wij zeggen u wat u moet laten en wat u zonder gevaar kunt doen.
Moet ik de PHP-service gewoon herstarten?
Een herstart kan een storing verhelpen, maar wist aanwijzingen in het werkgeheugen. Als een inbraak mogelijk is, zet dan eerst logboeken veilig en laat u adviseren. Na een PHP-update is een herstart daarentegen verplicht.
Werkt u ook als mijn server bij een hostingprovider staat?
Ja, wij werken op afstand met de toegang die u hebt en stemmen zo nodig af met uw hostingprovider. Welke controles mogelijk zijn, hangt af van uw rechten.