# Blog: PHP2Shell, serverbeveiliging en noodhulp

> Blog over PHP2Shell en serverbeveiliging: situatie, hosting, detectie, hardening, veilig ontwikkelen, management en beslissingshulp.

Bron: https://phpsos.de/nl/blog/  
Stand: 25-10-2026  
Aanbieder: PHP SOS, PHP-noodhulp en serverbeveiliging. Directe hulp via WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wij%20hebben%20hulp%20nodig%20met%20onze%20PHP-server.%20Bedrijf%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

Duiding van de situatie, handleidingen voor beheerders en beslissingshulp voor de directie. Gesorteerd per thema, elk artikel met bronnen.

- [PHP2Shell: wat bewezen is en wat niet](https://phpsos.de/nl/blog/php2shell-was-belegt-ist/): Een factcheck over PHP2Shell: welke uitspraken uit primaire bronnen komen, welke uit mediaberichten en welke beweringen geen stand houden.
- [Waarom het PHP-lek vóór de patch bekend werd](https://phpsos.de/nl/blog/php-luecke-vorzeitig-bekannt/): Volgens berichten werden details over PHP2Shell openbaar vóór het einde van het embargo. Wij leggen het verloop uit en wat dit betekent voor uw patchplanning.
- [Overheden halen websites van het net: wat bedrijven ervan leren](https://phpsos.de/nl/blog/behoerden-webseiten-offline/): Mainz, de deelstaatregering van Hessen en het BKA haalden websites preventief van het net. Wat bedrijven hieruit voor hun eigen beslissing kunnen leren.
- [BSI-waarschuwingsniveau Oranje: wat de indeling betekent](https://phpsos.de/nl/blog/bsi-warnstufe-orange-erklaert/): Het BSI deelt PHP2Shell in op 3 / Oranje. Wat de schaal wel en niet zegt, en hoe bedrijven de indeling vertalen naar beslissingen.
- [Wat CERT-EU en CERT-Bund over PHP2Shell adviseren](https://phpsos.de/nl/blog/cert-eu-empfehlungen-php/): De officiële instanties zijn het eens: direct patchen, anders isoleren. Wij vergelijken de adviezen en laten zien hoe isoleren er in de praktijk uitziet.
- [Cloudflare-beschermingsregels tegen PHP2Shell: wat ze doen en wat niet](https://phpsos.de/nl/blog/cloudflare-waf-php2shell/): Cloudflare heeft vroeg beschermingsregels tegen PHP2Shell uitgerold. Waarom dat helpt, waarom het de PHP-update toch niet vervangt en welke instellingen u moet controleren.
- [22,6 miljoen blootgestelde instanties: cijfers juist inschatten](https://phpsos.de/nl/blog/exponierte-instanzen-einordnen/): Unit 42, CybelAngel en anderen noemen zeer uiteenlopende cijfers over PHP2Shell. Wij leggen uit wat er is geteld en welk cijfer voor u echt telt.
- [PHP2Shell in vijf minuten: briefing voor de directie](https://phpsos.de/nl/blog/php2shell-briefing-geschaeftsfuehrung/): Het PHP-beveiligingslek PHP2Shell op één pagina voor besluitvormers: situatie, risico, vijf vragen aan de IT en de beslissingen voor vandaag.
- [Het PHP-beveiligingslek eenvoudig uitgelegd](https://phpsos.de/nl/blog/php-luecke-einfach-erklaert/): PHP2Shell voor niet-technici: met alledaagse beelden, een klein woordenlijstje en drie typische uitgangssituaties, wat u als website-beheerder moet doen.
- [PHP2Shell: 15 vragen van hostingklanten](https://phpsos.de/nl/blog/fragen-von-hosting-kunden/): Staat uw website bij een hostingprovider en wilt u weten wat u bij PHP2Shell zelf moet doen? Hier de 15 meest gestelde vragen met korte antwoorden.
- [Waarom een WordPress-update niet helpt tegen PHP2Shell](https://phpsos.de/nl/blog/warum-wordpress-update-nicht-hilft/): Veel beheerders hebben na de krantenkoppen WordPress bijgewerkt en voelen zich veilig. Waarom dat bij PHP2Shell niets uithaalt en wat er in plaats daarvan telt.
- [PHP2Shell en Log4Shell: wat de lekken gemeen hebben](https://phpsos.de/nl/blog/php2shell-und-log4shell/): Velen vergelijken PHP2Shell met Log4Shell uit 2021. Wat de vergelijking waard is, waar ze mank gaat en welke lessen van toen vandaag helpen.
- [Massascans naar ongepatcht PHP: zo verlopen geautomatiseerde aanvallen](https://phpsos.de/nl/blog/automatisierte-massenscans/): Na PHP2Shell doorzoeken aanvallers het internet geautomatiseerd naar kwetsbare servers. Hoe dat verloopt, waarom omvang geen rol speelt en wat u beschermt.
- [Het tijdvenster tussen patch en aanval](https://phpsos.de/nl/blog/zeitfenster-patch-angriff/): Bij PHP2Shell waren er aanvalspogingen al vóór de patch. Wij leggen de fasen van het tijdvenster uit, hoe u uw eigen venster meet en hoe u het verkort.
- [Na PHP2Shell: waarom meer meldingen waarschijnlijk zijn](https://phpsos.de/nl/blog/weitere-php-meldungen/): PHP2Shell is met de patch van 21 oktober niet afgesloten. Waarom vervolgmeldingen te verwachten zijn en hoe u uw team erop instelt.
- [PHP2Shell: het situatiebeeld van de eerste week](https://phpsos.de/nl/blog/lagebild-erste-woche/): Een week na de eerste waargenomen aanvalspoging: de stand van patches, overheidswaarschuwingen, aanvallen en uitschakelingen, netjes naar bronnen gescheiden.
- [Gevaarlijke valse tips over PHP2Shell die nu rondgaan](https://phpsos.de/nl/blog/gefaehrliche-falschtipps/): Cookies blokkeren, foutmeldingen verbergen, alleen het CMS bijwerken: negen adviezen over PHP2Shell die schijnveiligheid geven, en wat echt telt.
- [PHP-versie wijzigen in het klantenmenu van de hosting](https://phpsos.de/nl/blog/php-version-hosting-aendern/): Hoe u in het klantenmenu van uw hostingprovider de PHP-versie omzet, welke versie u kiest en wat u vooraf en achteraf controleert.
- [Debian en Ubuntu: is mijn PHP-pakket gepatcht?](https://phpsos.de/nl/blog/debian-ubuntu-paket-gepatcht/): Welke PHP-pakketten Debian en Ubuntu tegen PHP2Shell hebben gecorrigeerd, hoe u de geïnstalleerde stand exact vergelijkt en waaraan het bewijs strandt.
- [RHEL, AlmaLinux en Rocky Linux: PHP-patch controleren](https://phpsos.de/nl/blog/rhel-almalinux-rocky-php/): Wat Red Hat over PHP2Shell heeft gepubliceerd, hoe u op RHEL en de nabouwen de pakketstand aantoont en waarom een reload niet volstaat.
- [De sury.org-repository: PHP-pakketten uit een externe bron](https://phpsos.de/nl/blog/sury-repository-php/): Veel Debian- en Ubuntu-servers betrekken PHP uit de sury-repository. Wat dat na PHP2Shell betekent voor updates, bewijs en oude PHP-versies.
- [De Remi-repository: PHP op RHEL-systemen actueel houden](https://phpsos.de/nl/blog/remi-repository-php/): Remi levert actuele PHP-versies voor de RHEL-familie, als module of parallel te installeren. Zo controleert u de stand na PHP2Shell en voorkomt u vergeten takken.
- [Waarom php -v na de update hetzelfde nummer toont](https://phpsos.de/nl/blog/php-v-zeigt-alte-nummer/): De update is gelopen, maar php -v meldt de oude versie. Meestal is dat een backport en geen fout. Zo onderscheidt u onschuldige van echte problemen.
- [CVE-nummers aantonen in de pakket-changelog](https://phpsos.de/nl/blog/cve-im-changelog-nachweisen/): Wie een PHP-patch moet aantonen aan directie, auditors of verzekeraars, heeft meer nodig dan een versienummer. Zo wordt de changelog-vermelding een bewijs.
- [Hoster wisselen na een beveiligingsincident: waar op letten?](https://phpsos.de/nl/blog/hoster-wechseln-nach-vorfall/): Na een incident is de wens naar een nieuwe hoster begrijpelijk. Opdat de aanvaller niet meeverhuist, komt het aan op volgorde en keuze.
- [Meerdere PHP-versies op één server: patch elke versie afzonderlijk](https://phpsos.de/nl/blog/mehrere-php-versionen-server/): Op veel servers draaien drie, vier of meer PHP-installaties naast elkaar. Na PHP2Shell moet elke installatie worden gevonden, bijgewerkt en herstart.
- [Oude PHP-versies in het hostingpaneel uitschakelen](https://phpsos.de/nl/blog/alte-php-versionen-abschalten/): PHP2Shell is een goede aanleiding om oude PHP-versies kwijt te raken. Zo gaat u in drie fasen te werk, zodat geen website en geen cronjob ongemerkt uitvalt.
- [Plesk: PHP-handlers begrijpen (FPM, FastCGI, Apache-module)](https://phpsos.de/nl/blog/plesk-php-handler/): Welke PHP-handler Plesk voor een website gebruikt, bepaalt isolatie, configuratie en risico. Een vergelijking met het oog op PHP2Shell.
- [CloudLinux en alt-php: wat hostingklanten moeten weten](https://phpsos.de/nl/blog/cloudlinux-alt-php/): Op CloudLinux-servers draaien websites vaak met eigen alt-php-pakketten. Elke versie heeft haar eigen patch nodig, en alleen de serverbeheerder kan die inspelen.
- [PHP op NAS, firewalls en appliances: de vergeten systemen](https://phpsos.de/nl/blog/php-auf-nas-und-appliances/): Niet alleen webservers gebruiken PHP. Ook NAS-systemen, firewalls en vakapparatuur met een webinterface kunnen getroffen zijn. Patchen kan daar meestal alleen de fabrikant, de bereikbaarheid regelt u zelf.
- [PHP bij cloud- en PaaS-aanbieders: wie patcht de runtime?](https://phpsos.de/nl/blog/paas-php-laufzeit/): Op platformdiensten hangt de PHP-patch af van het bedrijfsmodel. Beslissend is de runtime die werkelijk levert, niet de lokale omgeving of de applicatiecode.
- [Officiële PHP Docker-images: tags, digests en herbouw](https://phpsos.de/nl/blog/offizielle-php-docker-images/): Een tag van de officiële PHP-image is een verwijzing die na verloop van tijd naar nieuwe standen schuift. Wie weet wat tag, variant en digest betekenen, kiest de juiste image en kan de patchstand aantonen.
- [CI/CD: PHP-images automatisch opnieuw bouwen](https://phpsos.de/nl/blog/php-images-in-ci-neu-bauen/): Een image veroudert ook zonder codewijziging. Met tijdgestuurde builds, een versiecontrole en uitrol via digest komen PHP-patches betrouwbaar in productie.
- [Langetermijnondersteuning voor oude PHP-versies: opties en grenzen](https://phpsos.de/nl/blog/langzeitsupport-alte-php-versionen/): Wie niet meteen kan overstappen van PHP 8.1 of ouder, vindt langetermijnondersteuning bij distributies, externe aanbieders en commerciële diensten. Wat die wegen bieden, wat u schriftelijk nodig hebt en waar de grenzen liggen.
- [PHP onder Windows bijwerken](https://phpsos.de/nl/blog/php-unter-windows-aktualisieren/): Onder Windows bestaat geen automatische PHP-update. Wie de juiste variant kiest, de download controleert en alle processen herstart, brengt de PHP2Shell-patch netjes op elke computer.
- [Waarschuwingssignaal: de webserver start een shell](https://phpsos.de/nl/blog/webserver-startet-shell/): Start een PHP-FPM- of webserverproces een shell, dan is dat een van de sterkste waarschuwingssignalen voor een inbraak. Zo controleert u de procesboom, plaatst u uitzonderingen en bewaakt u het patroon blijvend.
- [Verdachte processen op Linux-servers vinden](https://phpsos.de/nl/blog/verdaechtige-prozesse-linux/): Schadelijke processen vermommen zich met onschuldige namen, draaien vanuit tijdelijke mappen of vanuit verwijderde bestanden. Met enkele lezende opdrachten vindt u afwijkingen en plaatst u ze.
- [Verborgen cronjobs als achterdeur herkennen](https://phpsos.de/nl/blog/cronjobs-als-hintertuer/): Aanvallers gebruiken geplande taken om na een opschoning terug te keren. Zo controleert u crontabs, cron-mappen, systemd-timers en at-opdrachten volledig en herkent u verdachte vermeldingen.
- [Onlangs gewijzigde bestanden op de webserver vinden](https://phpsos.de/nl/blog/geaenderte-dateien-finden/): Na een mogelijke inbraak telt wat er op de server is veranderd. Zo zoekt u op tijdvensters, gebruikt u mtime en ctime juist en vergelijkt u met pakketten, Git en back-ups.
- [PHP-bestanden in de uploadmap: vindplaatsen juist duiden](https://phpsos.de/nl/blog/php-dateien-im-upload-ordner/): Een PHP-bestand in de uploadmap is bijna altijd een alarmteken, maar niet elk is schadelijke code. Zo beoordeelt u de vondst zonder sporen te vernietigen en stelt u vast of iemand het heeft aangeroepen.
- [Versluierde PHP-code herkennen](https://phpsos.de/nl/blog/verschleierter-php-code/): Onleesbare PHP-code met eval en base64_decode is een klassiek teken van ingebrachte schadelijke code. Welke patronen u zoekt, hoe u ze ongevaarlijk vindt en wanneer versluiering legitiem is.
- [Uitgaande verbindingen van een server controleren](https://phpsos.de/nl/blog/ausgehende-verbindungen-pruefen/): Een webserver antwoordt vooral op verzoeken. Bouwt hij zelf verbindingen naar onbekende doelen op, dan kan dat aansturing door aanvallers of gegevensuitstroom betekenen. Zo controleert en beperkt u uitgaand verkeer.
- [Vreemde beheerdersaccounts in CMS en server vinden](https://phpsos.de/nl/blog/fremde-admin-konten-finden/): Een onbekende beheerder is vaak de eenvoudigste achterdeur. Zo zoekt u laag voor laag naar vreemde accounts, ook naar accounts die de interface verbergt.
- [Onbekende SSH-sleutels vinden en verwijderen](https://phpsos.de/nl/blog/ssh-schluessel-pruefen/): Een ingebrachte SSH-sleutel opent aanvallers de deur, ook als alle wachtwoorden zijn gewijzigd. Zo vindt u elk authorized_keys-bestand en controleert u elke vermelding.
- [Cryptominer op de webserver: tekenen en aanpak](https://phpsos.de/nl/blog/kryptominer-auf-dem-server/): Permanent volle CPU zonder dat er meer bezoekers komen: dat kan een cryptominer zijn. Zo controleert u de belasting, vindt u het proces en zijn herstartmechanismen en gaat u ordelijk te werk.
- [De server verstuurt spam: oorzaken vinden](https://phpsos.de/nl/blog/server-verschickt-spam/): Onbezorgbare mails, blokkadelijsten, klachten: als de eigen server spam verstuurt, zit er meestal een script of een gekaapt postvak achter. Zo vindt u de bron.
- [SEO-spam en vreemde pagina's in de Google-index](https://phpsos.de/nl/blog/seo-spam-im-google-index/): Opeens ranken pagina's over medicijnen of merkproducten onder uw domein. Zo vindt u uit waar de SEO-spam vandaan komt en krijgt u hem weer uit de index.
- [De website stuurt door naar vreemde sites](https://phpsos.de/nl/blog/website-leitet-um/): Bezoekers belanden op prijsvragen of dubieuze webwinkels, maar u ziet zelf niets? Zo vindt u de laag waarin de doorverwijzing zit en verhelpt u haar.
- [Bewijs veiligstellen voordat u de server opnieuw opzet](https://phpsos.de/nl/blog/beweise-sichern-vor-neuinstallation/): Een herinstallatie verwijdert de aanvaller, maar ook alle sporen. Wie vooraf een uur in het veiligstellen van bewijs steekt, kan later zeggen wat er is gebeurd.
- [De tijdlijn van een incident opstellen](https://phpsos.de/nl/blog/zeitleiste-eines-vorfalls/): Wanneer kwam de aanvaller, wat deed hij, wanneer werd het opgemerkt? Een zuivere tijdlijn beantwoordt die vragen en is de basis voor meldingen, verzekering en rapport.
- [CMS-kernbestanden vergelijken met het origineel](https://phpsos.de/nl/blog/cms-kerndateien-vergleichen/): De vergelijking met een schoon origineel toont elk gewijzigd bestand, ongeacht of een scanner het kent. Zo bouwt u de controle op voor WordPress, Composer-projecten en systeempakketten.
- [De database controleren op ingebrachte code](https://phpsos.de/nl/blog/datenbank-auf-schadcode-pruefen/): Wie alleen bestanden controleert, mist de helft. Zo doorzoekt u inhoud, instellingen, triggers en accounts van de database op ingebrachte code, alleen-lezen en op een kopie.
- [Malwarescanners voor websites: wat ze wel en niet vinden](https://phpsos.de/nl/blog/grenzen-von-malware-scannern/): De scanner meldt niets, dus alles goed? Niet per se. Welke soorten websitescanners er zijn, wat elke scanner ziet en wat ze principieel niet kan zien.
- [PHP-FPM-pools per website isoleren](https://phpsos.de/nl/blog/php-fpm-pools-isolieren/): Een eigen pool per website is het begin, niet het einde. Zo controleert u bestaande pools en verhardt u sockets, extensies, statuspagina's, resources en logs.
- [memory_limit juist instellen](https://phpsos.de/nl/blog/memory-limit-richtig-setzen/): memory_limit begrenst het geheugen per PHP-verzoek. Na PHP2Shell adviseert php.net tijdelijk het tegenovergestelde. Wat geldt in normaal bedrijf, in de overgang en na de update.
- [post_max_size en upload_max_filesize zinvol beperken](https://phpsos.de/nl/blog/post-max-size-upload-limits/): Uploadgrenzen werken op drie plaatsen: in de webserver, in PHP en in de applicatie. Zo stelt u de waarden op elkaar af, ook met de overbruggingswaarden van php.net bij PHP2Shell.
- [session.upload_progress uitschakelen: juist en blijvend](https://phpsos.de/nl/blog/session-upload-progress-abschalten/): De remedie tegen CVE-2026-115560 en een van de PHP2Shell-overbruggingsmaatregelen is snel ingesteld. Om te blijven werken moet ze op de juiste plek staan, vergrendeld zijn en na elke update opnieuw worden gecontroleerd.
- [expose_php en Server-header: versiegegevens verbergen](https://phpsos.de/nl/blog/expose-php-versionsangaben/): PHP, Nginx en Apache noemen standaard hun versienummer in elk antwoord. Dat beschermt niet tegen aanvallen, maar geeft scanners een handige lijst met doelwitten. Zo schakelt u het uit en houdt u toch het overzicht.
- [display_errors off: foutuitvoer in productie uitschakelen](https://phpsos.de/nl/blog/display-errors-produktion/): Zichtbare PHP-foutmeldingen verraden paden, databasenamen en versies. Zo schakelt u ze uit in PHP, in het framework en in de webserver, zonder de fouten uit het oog te verliezen.
- [php_admin_value: instellingen tegen overschrijven vergrendelen](https://phpsos.de/nl/blog/php-admin-value-sperren/): Een beveiligingsinstelling helpt weinig als de applicatie haar met één regel code weer wijzigt. Met php_admin_value en php_admin_flag legt u waarden voor PHP-FPM en Apache bindend vast.
- [Geheugengrenzen instellen met systemd en cgroups](https://phpsos.de/nl/blog/speichergrenzen-systemd-cgroups/): php.net adviseert als PHP2Shell-overbruggingsmaatregel memory_limit=-1 en een geheugengrens buiten PHP. Zo stelt u die grens in met systemd en cgroups, zonder dat één worker de hele service meesleept.
- [Nginx veilig configureren voor PHP](https://phpsos.de/nl/blog/nginx-fuer-php-absichern/): De meeste zwakke plekken in Nginx-opstellingen voor PHP zitten niet in Nginx, maar in enkele regels van de PHP-location. Zo configureert u de overdracht aan PHP-FPM zodat alleen gewenste scripts worden uitgevoerd.
- [Apache veilig configureren voor PHP](https://phpsos.de/nl/blog/apache-fuer-php-absichern/): Apache is flexibel en precies dat maakt hem gevoelig voor verkeerde configuratie. Zo koppelt u PHP via PHP-FPM, sluit u .htaccess als achterdeur en stelt u de belangrijkste kernopties veilig in.
- [PHP-uitvoering in uploadmappen verbieden](https://phpsos.de/nl/blog/php-in-uploads-verbieten/): Een webshell heeft twee dingen nodig: een map waarin ze kan worden geschreven en een server die haar uitvoert. Zo ontneemt u haar het tweede, en wel in elke beschrijfbare map, niet alleen in uploads.
- [Uploadverzoeken aan de rand filteren: kansen en risico's](https://phpsos.de/nl/blog/upload-anfragen-am-rand-filtern/): Vakauteurs stellen voor uploadverzoeken buiten echte uploadpaden bij de proxy te blokkeren tot PHP is gepatcht. Dat kan helpen, maar ook formulieren en bestellingen lamleggen. Zo gaat u gecontroleerd te werk.
- [ModSecurity en het OWASP Core Rule Set inzetten](https://phpsos.de/nl/blog/modsecurity-owasp-crs/): Een eigen Web Application Firewall met ModSecurity en het OWASP Core Rule Set is gratis en krachtig, maar geen vanzelfsprekendheid. Zo kiest u de engine, start u zonder uitval en stemt u de regels af.
- [Fail2ban voor webservers instellen](https://phpsos.de/nl/blog/fail2ban-fuer-webserver/): Fail2ban blokkeert adressen die in de logs herhaaldelijk opvallen. Voor webservers heeft het kant-en-klare filters en met enkele regels voegt u eigen toe. Zo stelt u het in zonder uzelf of uw klanten buiten te sluiten.
- [Firewall voor webservers: alleen noodzakelijke poorten openen](https://phpsos.de/nl/blog/firewall-fuer-webserver/): Een webserver heeft naar buiten meestal maar twee poorten nodig. Toch luisteren op veel servers databases, PHP-FPM of beheeromgevingen op internet. Zo vindt u open diensten en sluit u wat niet nodig is.
- [Automatische beveiligingsupdates op Linux-servers](https://phpsos.de/nl/blog/automatische-sicherheitsupdates/): Volgens berichten leverden distributies PHP-backports deels nog op 21 oktober 2026 uit, de dag van de patches. Wie automatische beveiligingsupdates gebruikte, had ze snel op de server. Om ook te werken zijn herstarts, externe bronnen en controle nodig.
- [Least privilege: de rechten van de webservergebruiker](https://phpsos.de/nl/blog/rechte-des-webserver-benutzers/): Binnengesmokkelde code draait met de rechten van de webservergebruiker. Wat dit account mag, bepaalt hoe ver een aanvaller komt. Zo beperkt u shell, sudo, cron, database en bestandssysteem tot het noodzakelijke.
- [Beheeromgevingen afschermen met IP-whitelist, VPN of extra beveiliging](https://phpsos.de/nl/blog/admin-bereiche-abschirmen/): Waarom de backend van een website niet voor de hele wereld bereikbaar hoeft te zijn en hoe u hem afschermt met een IP-whitelist, VPN of voorgeschakelde aanmelding zonder uzelf buiten te sluiten.
- [TLS en HTTPS correct configureren](https://phpsos.de/nl/blog/tls-https-richtig-konfigurieren/): Welke TLS-versies en cipher suites een webserver tegenwoordig hoort aan te bieden, waarop de aanbevelingen zijn gebaseerd en hoe u Nginx, Apache en uitgaande PHP-verbindingen controleert.
- [CIS-benchmarks en BSI-bouwstenen voor webservers](https://phpsos.de/nl/blog/cis-benchmarks-bsi-bausteine/): Welke hardeningstandaarden er zijn voor Linux-webservers, hoe CIS-benchmarks en IT-Grundschutz-bouwstenen verschillen en hoe u daarvan een controleerbare richtlijn voor uw PHP-servers maakt.
- [Wachtwoorden in PHP veilig opslaan: password_hash correct gebruiken](https://phpsos.de/nl/blog/passwoerter-in-php-speichern/): Hoe ontwikkelaars wachtwoorden in PHP opslaan met password_hash en password_verify, de passende methode kiezen en oude MD5- of SHA-1-hashes vervangen zonder wachtwoordreset voor alle gebruikers.
- [CSRF-bescherming in PHP-applicaties](https://phpsos.de/nl/blog/csrf-schutz-php/): Hoe ontwikkelaars cross-site request forgery in PHP-applicaties voorkomen: tokens voor elk wijzigend verzoek, herkomstcontrole in de header en SameSite-cookies als extra laag.
- [Invoer in PHP valideren en filteren met filter_var](https://phpsos.de/nl/blog/eingaben-validieren-php/): Hoe ontwikkelaars invoer in PHP controleren met filter_var, filter_input_array en toegestane waardenlijsten, welke filters verouderd zijn en waarom validatie prepared statements en uitvoercodering niet vervangt.
- [Command injection in PHP voorkomen](https://phpsos.de/nl/blog/command-injection-php/): Hoe ontwikkelaars command injection in PHP vermijden: systeemopdrachten vervangen door PHP-functies, proc_open zonder shell gebruiken, argumenten controleren en gevaarlijke plekken in bestaande code vinden.
- [Server-side request forgery (SSRF) in PHP voorkomen](https://phpsos.de/nl/blog/ssrf-in-php/): Hoe ontwikkelaars voorkomen dat een PHP-applicatie in opdracht van vreemden interne systemen bevraagt: lijsten met toegestane doelen, protocolbeperking, controle van het omgezette adres en grenzen in het netwerk.
- [XML external entities (XXE) in PHP voorkomen](https://phpsos.de/nl/blog/xxe-in-php/): Hoe ontwikkelaars XML in PHP veilig verwerken: standaardgedrag van libxml, riskante opties zoals LIBXML_NOENT, bescherming met entity-loader en LIBXML_NO_XXE en typische verborgen XML-invoerpunten.
- [Type juggling in PHP: losse vergelijkingen als beveiligingsrisico](https://phpsos.de/nl/blog/type-juggling-php/): Waarom losse vergelijkingen met == in PHP tot beveiligingslekken kunnen leiden, wat er met PHP 8.0 is veranderd en hoe u vergelijkingen in logins, tokens en machtigingen robuust schrijft.
- [Veilige willekeurige getallen en tokens in PHP met random_bytes](https://phpsos.de/nl/blog/sichere-tokens-php/): Hoe ontwikkelaars in PHP tokens voor wachtwoordlinks, API-sleutels en eenmalige codes genereren: cryptografisch veilige bronnen, voldoende lengte, opslag als hash en beperkte geldigheid.
- [Toegangsgegevens en .env-bestanden correct beveiligen](https://phpsos.de/nl/blog/env-dateien-schuetzen/): Hoe u databasewachtwoorden, API-sleutels en andere geheimen in PHP-projecten beveiligt: .env-bestanden buiten de webroot, blokkades in de webserver, strikte rechten en ordelijke vervanging na een incident.
- [Openbare .git-map: een onderschat datalek](https://phpsos.de/nl/blog/git-ordner-oeffentlich/): Waarom een via Git uitgerolde webroot de volledige broncode inclusief geschiedenis kan prijsgeven, hoe u dat controleert, meteen blokkeert en de deployment blijvend zonder .git-map opbouwt.
- [Back-upbestanden in de webroot: .zip, .sql en .bak](https://phpsos.de/nl/blog/backup-dateien-im-webroot/): Waarom database-dumps, archieven en reservekopieën in de openbare map tot de meest voorkomende datalekken behoren, hoe u ze vindt, blokkeert en uitzoekt of ze zijn opgehaald.
- [phpinfo()-bestanden: waarom ze moeten verdwijnen](https://phpsos.de/nl/blog/phpinfo-dateien-entfernen/): Na PHP2Shell maken veel beheerders snel een info.php aan. Waarom zulke bestanden een datalek zijn, hoe u ze vindt en welke controlewegen beter zijn.
- [Afhankelijkheden actueel houden: Composer, npm en plug-ins](https://phpsos.de/nl/blog/abhaengigkeiten-aktuell-halten/): Een project bestaat uit drie pakketwerelden: Composer, npm en CMS-plug-ins. Hoe u ze alle drie actueel houdt met een vast ritme, duidelijke verantwoordelijkheid en tests.
- [Beveiligings-code-review voor PHP-projecten](https://phpsos.de/nl/blog/sicherheits-code-review-php/): Hoe teams de eigen PHP-code gericht doorlichten op beveiligingslekken: soorten reviews, kritieke functies, zinvolle hulpmiddelen en een checklist.
- [Veilig loggen: fouten registreren zonder datalek](https://phpsos.de/nl/blog/sicher-loggen-php/): Logboeken helpen bij foutopsporing en forensisch onderzoek, maar worden snel zelf een datalek. Wat PHP-applicaties moeten loggen, wat nooit en hoe u logboeken beschermt.
- [REST-API's in PHP beveiligen](https://phpsos.de/nl/blog/rest-api-php-absichern/): Interfaces zijn vaak slechter beschermd dan de website ervoor. De belangrijkste regels voor REST-API's in PHP, van objectmachtiging tot snelheidsbeperking.
- [Contracten met IT-dienstverleners: beveiligingsplichten helder regelen](https://phpsos.de/nl/blog/dienstleistervertrag-sicherheit/): PHP2Shell heeft laten zien hoe vaak onduidelijk is wie moet patchen. Welke beveiligingsplichten in contracten met bureau, hostingprovider en IT-dienstverlener horen.
- [Verwerking in opdracht wanneer dienstverleners bij servers kunnen](https://phpsos.de/nl/blog/auftragsverarbeitung-serverzugriff/): Wie externen toegang geeft tot servers met klantgegevens, heeft meestal een verwerkersovereenkomst nodig. Wat art. 28 AVG eist en hoe u toegang in noodgevallen privacyconform organiseert.
- [Kwetsbaarhedenbeheer voor het mkb](https://phpsos.de/nl/blog/schwachstellenmanagement-mittelstand/): Geen enkel mkb-bedrijf kan elke melding meteen afhandelen. Een slank circuit van registreren, beoordelen, beslissen en aantonen zorgt dat het belangrijkste als eerste gebeurt.
- [Weten wat er draait: inventaris van alle websites en servers](https://phpsos.de/nl/blog/inventar-websites-server/): Bij PHP2Shell struikelden veel bedrijven niet over de patch, maar over de vraag waar PHP eigenlijk draait. Zo bouwt u een inventaris van alle websites en servers op.
- [Patchbeheer als proces in plaats van brandweer](https://phpsos.de/nl/blog/patch-management-prozess/): Wie alleen patcht als het brandt, verliest in een noodgeval tijd. Hoe een patchbeheerproces met vaste klassen, vensters en bewijsstukken routine en noodgeval verbindt.
- [Noodcontacten: wie moet wanneer worden geïnformeerd?](https://phpsos.de/nl/blog/notfallkontakte-liste/): In een noodgeval telt wie u bereikt en wanneer. Hoe u een lijst van IT-noodcontacten opbouwt, met aanleidingen, vervangers en de gegevens die elk telefoontje nodig heeft.
- [Wat een gehackte server kost: de kostenposten](https://phpsos.de/nl/blog/kostenposten-eines-hacks/): Een gehackte webserver veroorzaakt meer kosten dan alleen het herstel. Welke kostenposten er zijn en hoe u met eigen cijfers een budget voor preventie onderbouwt.
- [Klanten informeren na een incident](https://phpsos.de/nl/blog/kunden-nach-vorfall-informieren/): Verplicht of vrijwillig: hoe u na een incident beslist wie u informeert, welke kanalen veilig zijn en hoe uw klantenservice is voorbereid.
- [De toeleveringsketen op het web: bureau, hoster, plug-inaanbieder](https://phpsos.de/nl/blog/lieferkette-agentur-hoster/): PHP2Shell liet zien hoeveel schakels er tussen een patch en uw website liggen. Hoe u de keten van uw website kent, beveiligt en uitval van afzonderlijke schakels opvangt.
- [Veiligheidsbewustzijn voor beheerders en redacteuren: security awareness in het webteam](https://phpsos.de/nl/blog/sicherheitsbewusstsein-redaktion/): Wie websites onderhoudt, beslist dagelijks over beveiliging, vaak zonder het te merken. Zo traint u beheerders en redacteuren op maat van hun rol en zonder sheetsslag.
- [Noodoefening aan tafel: een webserverincident doorspelen](https://phpsos.de/nl/blog/notfalluebung-am-tisch/): Een oefening aan tafel kost een middag en laat zien of uw noodplan standhoudt. Hier vindt u een kant-en-klaar draaiboek voor een incident op een PHP-webserver.
- [ISO 27001 en TISAX: wat webservers raakt](https://phpsos.de/nl/blog/iso-27001-tisax-webserver/): Wie een ISMS volgens ISO 27001 beheert of een TISAX-label heeft, moet webservers meenemen. Hier staat welke eisen ze raken en welk bewijs na PHP2Shell telt.
- [VdS 10000: informatiebeveiliging voor kleine en middelgrote bedrijven](https://phpsos.de/nl/blog/vds-10000-kmu/): De VdS 10000 is een slank kader voor informatiebeveiliging in het mkb. Wat ze vraagt, wat in 2025 nieuw kwam en wat dat voor websites en webservers betekent.
- [Lessons learned: beter worden na het incident](https://phpsos.de/nl/blog/lessons-learned-nach-vorfall/): Na het incident is voor het volgende. Een gestructureerde nabespreking zonder schuldvraag maakt van een slechte week meetbare vooruitgang.
- [Patchen, uitschakelen of afwachten? Een beslishulp bij het PHP-lek](https://phpsos.de/nl/blog/patchen-abschalten-abwarten/): Bij een kritiek PHP-lek moeten verantwoordelijken snel beslissen. Deze hulp ordent de drie opties, noemt criteria en laat zien wanneer afwachten verdedigbaar is.
- [WAF of update: waarom u beide nodig hebt](https://phpsos.de/nl/blog/waf-oder-update/): Een Web Application Firewall kan aanvallen onderscheppen, maar dicht geen lek in de PHP-interpreter. Wanneer een WAF helpt, waar ze ophoudt en hoe u beide zinvol combineert.
- [Server opnieuw opzetten of opschonen? De beslissing na een besmetting](https://phpsos.de/nl/blog/neu-aufsetzen-oder-bereinigen/): Na een inbraak staan twee wegen open: de server opschonen of opnieuw opbouwen. Welke criteria beslissen, en waarom de volgorde belangrijker is dan de keuze.
- [Zelf oplossen of een dienstverlener inschakelen? Een eerlijke afweging](https://phpsos.de/nl/blog/selbst-beheben-oder-dienstleister/): Niet elke beveiligingssituatie vraagt externe hulp. Met deze criteria en een korte zelftest beslist u of uw team PHP2Shell alleen aankan of ondersteuning nodig heeft.
- [Een IT-beveiligingsdienstverlener kiezen: 12 vragen vóór de opdracht](https://phpsos.de/nl/blog/sicherheitsdienstleister-auswaehlen/): Onder tijdsdruk een goede beveiligingsdienstverlener vinden is lastig. Deze twaalf vragen helpen offertes zakelijk te vergelijken zonder in reclamebeloften te trappen.
- [Managed hosting of eigen server? De beveiligingsvergelijking](https://phpsos.de/nl/blog/managed-oder-eigener-server/): PHP2Shell was een stresstest voor elk bedrijfsmodel. De vergelijking laat zien wanneer managed hosting veiliger is, wanneer de eigen server, en welke mengvormen zich bewijzen.
- [PHP-upgrade of backport? De keuze voor oude systemen](https://phpsos.de/nl/blog/php-upgrade-oder-backport/): Voor oude PHP-versies zijn er na PHP2Shell meerdere wegen: distributiebackport, externe bron, broncodepatch, langetermijnondersteuning of upgrade. Wat elke weg waard is en hoe lang hij draagt.
- [Na de hack het CMS wisselen? Wanneer het helpt en wanneer niet](https://phpsos.de/nl/blog/cms-wechsel-nach-hack/): Na een inbraak is het vertrouwen in het CMS vaak weg. Toch lost een nieuw systeem zelden de eigenlijke oorzaak op. Wanneer de wissel zinvol is en hoe hij netjes lukt.
- [Statische websites: minder PHP, minder aanvalsoppervlak](https://phpsos.de/nl/blog/statische-website-alternative/): Een statische website levert kant-en-klare HTML-bestanden uit en heeft geen PHP op de server nodig. Dat verkleint het aanvalsoppervlak aanzienlijk, maar brengt eigen grenzen en plichten mee.
- [Pentest, bug bounty of kwetsbaarhedenscan? De passende toetsmethode kiezen](https://phpsos.de/nl/blog/pentest-bugbounty-scan/): Scan, penetratietest en bug bounty toetsen websites op totaal verschillende wijze. Wat elke methode levert, waar ze tekortschiet en welke volgorde bij uw bedrijf past.