PHP beveiligingschecklist: 8 stappen om kwetsbaarheden op te sporen en te verhelpen

php icon.
Hoofd van Engineering
Geverifieerde expert
Elk artikel op Innowise is geschreven door auteurs met praktijkervaring. Zij hebben niet alleen theoretische kennis van het onderwerp, maar delen ook inzichten uit concrete projecten.
7+ jaar ervaring
Geverifieerde expert
7+ jaar ervaring
Herman geeft leiding aan technische afdelingen en zet de processen, teamstructuren en technische normen op die nodig zijn om op te schalen. Zijn expertise omvat backend-systemen die zware belasting aankunnen, leveringsbeheer en leidinggeven aan technische teams.
Expertise
Systemen voor zware belasting Software architectuur Databases
Laten we praten

Belangrijkste inzichten

  • PHP2Shell moet dringend worden gepatcht. Op 21 oktober 2026 heeft PHP CVE-2026-109618 en CVE-2026-109619 verholpen. Beide zijn kritieke runtime-kwetsbaarheden (CVSS v4.0: 9,2) die het mogelijk maken om op afstand code uit te voeren zonder authenticatie.
  • Controleer de gepatchte versies. De eerste releases waarin de beveiligingslekken zijn verholpen zijn PHP 8.2.35, 8.3.36, 8.4.27 en 8.5.12. Linux-distributies bieden mogelijk dezelfde oplossingen via backported patches.
  • Geef prioriteit aan kwetsbare PHP-runtimes. Apache mod_php brengt het hoogste gerapporteerde risico met zich mee, maar PHP-FPM en andere webgerichte configuraties vereisen ook aandacht. Framework-updates en een Composer-audit lossen PHP2Shell niet op.
  • Blijf niet bij het patchen van PHP. Gebruik de checklist met acht stappen om afhankelijkheden, applicatiecode, serverinstellingen en andere beveiligingszwakheden te controleren.
  • Controleer of de oplossing in de productieomgeving werkt. Vraag uw team om een rapport waarin wordt aangegeven welke PHP-builds daadwerkelijk draaien, welke workloads zijn gepatcht en of er aanwijzingen zijn voor eerdere inbreuken.
Artikel samenvatten met AI

Volgens W3Techs, PHP wordt gebruikt door ongeveer 70% van de websites waarvan de servertaal bekend is. Omdat PHP zo wijdverbreid is, kan een kwetsbaarheid in de interpreter veel sites in gevaar brengen, zelfs als hun eigen code veilig is.

Op 21 oktober 2026 heeft het PHP-project noodpatches uitgebracht voor twee kritieke kwetsbaarheden, CVE-2026-109618 en CVE-2026-109619, gezamenlijk PHP2Shell genoemd. Beide kregen een score van 9,2 volgens CVSS v4.0 en maken het mogelijk om op afstand code uit te voeren zonder authenticatie. Deze kwetsbaarheden hebben invloed op het interne geheugen en de verwerking van verzoeken van PHP.

De eerste patches zijn uitgebracht in PHP 8.2.35, 8.3.36, 8.4.27 en 8.5.12. Als uw systeem een van de getroffen versies gebruikt, werk dan PHP onmiddellijk bij en zorg ervoor dat uw webserver de gepatchte versie draait. Maar daar mag het niet bij blijven. Voor teams die PHP-applicaties bouwen en onderhouden, waaronder Innowise’s PHP-ontwikkelings-specialisten, is de release van oktober ook een reden om afhankelijkheden, applicatiecode en serverinstellingen te herzien.

In deze handleiding laat ik je acht stappen zien om kwetsbaarheden in je PHP-omgeving op te sporen en te verhelpen, en om te controleren of je oplossingen in de productieomgeving werken.

Analyse door een expert: hoe PHP2Shell verschilt van een standaard CVE-afhankelijkheid

Een kwetsbaar Composer-pakket heeft invloed op de code die uw applicatie gebruikt. PHP2Shell is anders. Beide kwetsbaarheden zitten in de PHP-interpreter zelf, en een aanvaller kan ze activeren vóór Laravel, Symfony of een ander framework zelfs maar wordt gestart. Het bijwerken van CMS-plugins of Composer-afhankelijkheden lost PHP niet op, en composer audit detecteert deze kwetsbaarheden tijdens de uitvoering niet.

Het PHP-beveiligingsteam identificeert Apache mod_php als de configuratie met het hoogste risico voor CVE-2026-109618, met een aangetoonde aanval die werkt voordat de applicatiecode wordt uitgevoerd. PHP-FPM, CGI en andere webserverconfiguraties zijn ook kwetsbaar, hoewel de voorwaarden voor misbruik verschillen. Onderzoekers hebben ook aangetoond dat CVE-2026-109619 kan worden misbruikt tegen PHP-FPM.

Dit is wat er in elk geval misgaat:

CVEOorzaakWaarom teams hier aandacht aan moeten besteden
CVE-2026-109618Als PHP tijdens het verwerken van een verzoek onvoldoende geheugen heeft, kunnen sommige interne gegevens in een ongeldige toestand achterblijven. Wanneer PHP het mislukte verzoek opruimt, kan het die gegevens gebruiken.Als PHP tijdens het verwerken van een verzoek onvoldoende geheugen heeft, kunnen sommige interne gegevens in een ongeldige toestand achterblijven. Wanneer PHP het mislukte verzoek opruimt, kan het die gegevens gebruiken.
CVE-2026-109619Een PHP-worker kan een verwijzing behouden naar geheugen dat na een eerder verzoek is vrijgegeven. Wanneer de worker een ander verzoek verwerkt, kan hij proberen die oude verwijzing te gebruiken.Het probleem kan zich voordoen bij opeenvolgende verzoeken die door dezelfde worker worden verwerkt. Het controleren van afzonderlijke applicatieverzoeken zal dit niet per se aan het licht brengen.

Beide kwetsbaarheden kunnen leiden tot het op afstand uitvoeren van code zonder authenticatie. De oplossing hoort thuis in de PHP-runtime, niet in de afhankelijkheden van de applicatie.

Voor een uitgebreidere technische uitleg kunt u de beveiligingsadviezen van het PHP-project raadplegen voor CVE-2026-109618 en CVE-2026-109619.

Waar komen PHP-beveiligingslekken vandaan?

Zoals ik al eerder heb gezegd, lost het updaten van PHP een kwetsbaar Composer-pakket niet op, en zal een schone afhankelijkheidsscan geen problemen in je eigen code opsporen. Bij het beoordelen van een PHP-toepassing kijk ik naar vier bronnen van beveiligingsrisico’s, elk met hun eigen mogelijke gevolgen.

CategorieVoorbeeldenBelangrijkste risico
PHP-runtimeNiet-gepatchte PHP-versies, kwetsbaarheden in de interpreter, niet-ondersteunde versiesAanvallers maken misbruik van kwetsbaarheden in PHP zelf, ongeacht hoe veilig de applicatie is geschreven
Afhankelijkheden van derdenComposer-pakketten, CMS-plug-ins, frameworksKwetsbare code van derden stelt applicaties bloot aan aanvallen, zelfs als je eigen code veilig is
ToepassingscodeSQL-injectie, XSS, CSRF, onveilige deserialisatie, gebrekkige toegangscontroleDoor fouten in de code kunnen aanvallers mogelijk gegevens stelen, ongeoorloofde handelingen uitvoeren of de applicatie in gevaar brengen
Configuratie en infrastructuurOnveilige PHP-instellingen, blootgestelde bestanden, te ruime machtigingenDoor verkeerde configuraties kan gevoelige informatie openbaar worden of kunnen aanvallers meer toegang krijgen dan de bedoeling is

Pak de kwetsbaarheden in PHP aan voordat ze ernstiger worden

PHP beveiligingschecklist: 8 essentiële controles

Laten we vervolgens acht beveiligingscontroles doornemen die ik zou uitvoeren voor een bestaande PHP-toepassing. Ik zou beginnen met de PHP-runtime die live verzoeken verwerkt, en vervolgens de code, afhankelijkheden en configuratie controleren op problemen die niet alleen met een PHP-update kunnen worden opgelost.

Controleer je PHP-versie en beveiligingspatches

Bepaal eerst welke PHP-runtimes uw applicaties gebruiken: Apache mod_php, PHP-FPM, php-cgi, FrankenPHP of LiteSpeed. Houd rekening met afzonderlijke FPM-pools, containers, CLI-installaties, wachtrijverwerkers en geplande taken.

Vertrouw niet alleen op php -v of php –ini. php -v toont de CLI-versie, terwijl php –ini de configuratie ervan toont. Geen van beide bevestigt welke PHP-runtime de webverzoeken afhandelt.

Vergelijk de actieve runtime en de bijbehorende configuratie met de officiële PHP-advies, inclusief de getroffen versies en blootstellingsomstandigheden. Apache mod_php vertoont de grootste aangetoonde kwetsbaarheid voor PHP2Shell, inclusief een exploitpad voordat de applicatiecode wordt uitgevoerd. De kwetsbaarheid van PHP-FPM hangt af van de configuratie en uitvoeringspaden. Andere SAPI’s moeten ook worden beoordeeld, aangezien de SAPI op zichzelf niet bepaalt of een implementatie veilig is.

De eerste upstream-releases die beide oplossingen bevatten, waren:

PHP-takEerste stabiele versie
8.28.2.35
8.38.3.36
8.48.4.27
8.58.5.12

Deze versies staan vermeld in de PHP-beveiligingsadviezen voor CVE-2026-109618 en CVE-2026-109619. Controleer of er nieuwere beveiligingsupdates beschikbaar zijn voordat u de update uitvoert.

Controleer PHP-patches op Linux en in containers

Controleer de actieve runtime. Controleer de configuratie van uw webserver om te bepalen welke PHP-module, FPM-pool of ingebouwde SAPI de verzoeken afhandelt. Controleer de versie met behulp van diagnostische tools met beperkte toegang en verwijder daarna eventuele tijdelijke eindpunten. Maak phpinfo() of een versie-eindpunt nooit openbaar.

Controleer de geïnstalleerde pakketten. Op Ubuntu met PHP 8.3 tonen deze alleen-lezen commando's de geïnstalleerde pakketten en beschikbare versies:

dpkg-query -W 'php8.3*'
apt-cache policy php8.3-fpm

Pas de pakketnamen aan voor uw PHP-tak en vergelijk de geïnstalleerde versies met de beveiligingsmededeling of het wijzigingslogboek van de leverancier. Linux-leveranciers kunnen fixes terugporten naar oudere PHP-versies. Ubuntu vermeldt bijvoorbeeld deze gepatchte builds:

  • Ubuntu 24.04: 8.3.6-0ubuntu0.24.04.13

  • Ubuntu 22.04: 8.1.2-1ubuntu2.28

Beide bevatten de relevante fixes, ondanks hun lagere versienummers. Raadpleeg de Ubuntu-beveiligingsmededeling.

Breng de patch aan en implementeer opnieuw. Installeer de gepatchte pakketten. Noteer voor containers de digest van de actieve image, werk kwetsbare PHP-basisimages bij, bouw de werkbelasting opnieuw op en implementeer deze opnieuw, inclusief wachtrij-workers.

Controleer het resultaat. Start de getroffen PHP-workers opnieuw op of vervang ze en controleer of actieve processen en containers gebruikmaken van gepatchte builds of geverifieerde backports van leveranciers. Noteer pakketversies, digests van actieve images, details over het opnieuw opstarten en verificatieresultaten.

PHP 8.1 en eerdere versies worden upstream niet langer ondersteund, hoewel sommige leveranciers nog steeds beveiligingsbackports aanbieden. Controleer of uw geïnstalleerde build hieronder valt en voer een upgrade uit als dat niet het geval is. De beveiligingsondersteuning voor PHP 8.2 eindigt op 31 december 2026, dus combineer elke kortetermijnpatch met een upgradeplan. U kunt de volledige ondersteuningstermijn vinden in het PHP-ondersteuningsschema.

Audit-afhankelijkheden en -raamwerken

Begin met composer.lock. Hierin staan de pakketversies vermeld waarvan je applicatie afhankelijk is, inclusief de versies die indirect via andere pakketten zijn geïnstalleerd. Voer deze twee commando’s uit:

composer audit --locked
composer outdated

composer audit --locked controleert de vergrendelde versies aan de hand van bekende beveiligingsadviezen en kan verouderde pakketten markeren. composer outdated laat zien welke updates beschikbaar zijn, maar een verouderd pakket is niet per se kwetsbaar. Controleer ook de Laravel- of Symfony-adviezen, vooral als je frameworkversie niet langer wordt ondersteund.

Vergelijk de pakketten die in productie zijn geïmplementeerd met de versies in het gecontroleerde lock-bestand. Bewaar de auditresultaten en de inventaris van geïnstalleerde pakketten bij je releasegeschiedenis.

Als je kwetsbare pakketten aantreft, werk deze dan bij naar compatibele, gepatchte versies en test de betreffende functionaliteit. Vervang bibliotheken die geen beveiligingsupdates meer ontvangen. Als compatibiliteitsproblemen een upgrade van het framework in de weg staan, documenteer deze dan, evenals de benodigde migratiewerkzaamheden. Vergeet ook niet de CMS-plugins of bibliotheken die buiten Composer om zijn geïnstalleerd.

Een schone Composer-audit bevestigt niet dat PHP2Shell is verholpen. De audit controleert Composer-pakketten, terwijl PHP2Shell een afzonderlijke controle vereist van de PHP-interpreter en de bijbehorende patches. Gebruik SAST om de broncode te analyseren en DAST om de draaiende applicatie te testen, om de applicatie zelf te beoordelen.

Overzicht van PHP en serverconfiguraties

Controleer de PHP-instellingen die daadwerkelijk door uw webserver worden gebruikt, inclusief PHP-FPM-pool-overschrijvingen en geladen extensies. Houd er rekening mee dat php --ini de CLI-configuratie weergeeft, die kan afwijken van de live-applicatie.

Begin voor productieomgevingen met:

display_errors = Off
log_errors = On

Bewaar logbestanden buiten openbaar toegankelijke mappen en beperk de toegang ertoe. Verwijder openbare phpinfo()-pagina’s en debug-eindpunten, en controleer expose_php, onnodige extensies en bestandssysteemrechten.

Het uitschakelen van display_errors vermindert het vrijgeven van informatie, maar biedt geen bescherming tegen CVE-2026-109619. Het kwetsbare codepad kan worden uitgevoerd voordat PHP de foutmelding verwerkt.

Tijdelijke maatregelen wanneer PHP-patches vertraging oplopen

Als het patchen moet wachten, volg dan de officiële PHP-advies voor uw configuratie.

  • CVE-2026-109619: Schakel session.upload_progress.enabled uit en stel in PHP 8.5 fatal_error_backtraces=0 in. Pas deze instellingen toe vóór de verwerking van verzoeken via de server- of poolconfiguratie en start vervolgens de betrokken workers opnieuw op. Er kunnen nog andere exploitpaden overblijven.

  • CVE-2026-109618: Dwing memory_limit=-1 af op server- of poolniveau en start de betrokken workers opnieuw op. Hiermee wordt het voorspelbare PHP-foutpad met betrekking tot de geheugenlimiet verwijderd, maar blijven andere toewijzingsfouten mogelijk. Controleer de verzoeklimieten en de geheugenbeveiligingen van de host of container om het risico op denial-of-service-aanvallen te verminderen.

PHP heeft ook een afzonderlijk advies voor CVE-2026-115560 op 23 oktober. Het betreft applicaties die session.serialize_handler van php_binary of php_serialize naar php met behulp van ini_set() vóór session_start(), waarbij de voortgang van het uploaden is ingeschakeld. Getroffen installaties moeten de voortgang van het uploaden uitschakelen in afwachting van een oplossing.

Sluit een upgrade-abonnement af voor de verouderde PHP-apps waar uw bedrijf van afhankelijk is

Controleer op SQL-injectie, XSS en het uitvoeren van onveilige code

Als gebruikersinvoer niet goed wordt verwerkt, kunnen gevoelige gegevens worden blootgesteld of kunnen aanvallers kwaadaardige code uitvoeren. Ik raad je aan om code reviews te gebruiken om risicovolle invoerpaden op te sporen en SAST om mogelijke kwetsbaarheden te signaleren. Geautoriseerde DAST-tests controleren de draaiende applicatie, terwijl penetratietests helpen vaststellen welke zwakke plekken aanvallers zouden kunnen misbruiken. Apps die zijn gebouwd via vibe-coding kunnen dezelfde tekortkomingen vertonen en vereisen dezelfde controles.

SQL-injectie

SQL-injectie vindt plaats wanneer gebruikersinvoer de structuur van een databasequery wijzigt. Controleer hoe je applicatie queries opbouwt, met name in zoekformulieren en rapporten.

Om gebruikersinvoer gescheiden te houden van SQL-opdrachten, gebruikt u PDO-prepared statements:

$stmt = $pdo->prepare(
    'SELECT id FROM users WHERE email = :email'
);
$stmt->execute(['email' => $email]);

Met prepared statements worden gegevenswaarden gescheiden gehouden van SQL-syntaxis, zoals de plaatshouder :email in het voorbeeld doet. Maar plaatshouders kunnen geen tabel- of kolomnamen vertegenwoordigen. Als gebruikers bijvoorbeeld een rapport kunnen sorteren, selecteer dan de toegestane kolommen uit een lijst die in de applicatie is gedefinieerd. Test de betreffende query’s nadat u wijzigingen hebt aangebracht.

Cross-site scripting

Cross-site scripting (XSS) treedt op wanneer een applicatie onbetrouwbare gegevens weergeeft die een browser als code kan uitvoeren. Controleer PHP-sjablonen op gebruikersinvoer die zonder de juiste escaping wordt weergegeven, met name wanneer automatische escaping is uitgeschakeld.

Als uw applicatie bijvoorbeeld de naam van een gebruiker weergeeft als HTML-tekst, gebruik dan htmlspecialchars() om speciale tekens om te zetten, zodat de browser ze als tekst behandelt:

echo htmlspecialchars(
    $name,
    ENT_QUOTES | ENT_SUBSTITUTE,
    'UTF-8'
);

De juiste beveiliging hangt af van waar de gegevens verschijnen. JavaScript, URL’s en HTML-attributen vereisen contextspecifieke controles en codering. Als gebruikers opgemaakte HTML kunnen indienen, gebruik dan een HTML-sanitizer om onveilige elementen te verwijderen en tegelijkertijd de toegestane opmaak te behouden.

Onveilige code en uitvoering van opdrachten

Some PHP functions can execute system commands or PHP code. Check whether untrusted input reaches exec(), shell_exec(), or eval(). Also review dynamic file inclusion and the use of unserialize() with data from untrusted sources.

Where possible, use a PHP API instead of running a shell command. If you need to start an external program, specify the executable and pass its arguments separately. Here’s an example using Symfony Process:

use Symfony\Component\Process\Process;

// Validate $filePath against approved paths first.
$process = new Process([
    '/usr/bin/file',
    '--',
    $filePath
]);
$process->mustRun();

This example uses the file utility to identify a file’s type. Symfony Process passes $filePath as a separate argument rather than inserting it into a shell command string. You still need to validate the path, restrict the service account’s filesystem access, and allow only the operations your application requires.

Deserialization needs a separate check. Avoid passing untrusted data to unserialize(), even with allowed_classes restrictions. Where suitable, use JSON instead and validate the decoded values.

Overzicht van authenticatie, sessies en toegangscontrole

Begin met wachtwoorden. Deze mogen niet in leesbare vorm worden opgeslagen. Controleer of je applicatie gebruikmaakt van PHP’s password_hash() en password_verify(), of de overeenkomstige frameworkmethoden. Zoek naar oudere hash-code die mogelijk niet meer veilig is.

Controleer vervolgens wat er gebeurt wanneer iemand inlogt. De applicatie moet een nieuwe sessie-ID genereren, zodat een ID die vóór het inloggen is verkregen, niet opnieuw kan worden gebruikt om toegang te krijgen tot het account. Controleer de instellingen voor session.use_strict_mode en cookies, zoals Secure, HttpOnly en SameSite. Test het opnieuw genereren van de sessie-ID via je framework, ook wanneer er meerdere verzoeken tegelijk binnenkomen.

Test nu of gebruikers gegevens kunnen zien die niet van hen zijn. Maak twee testaccounts aan, elk met een eigen factuur. Log in op het eerste account en wijzig de factuur-ID in een verzoek naar die van het tweede account. De server moet de toegang weigeren, tenzij die gebruiker toestemming heeft.

Herhaal de test voor het bewerken van facturen, het downloaden van bestanden en API-verzoeken. Controleer of gewone gebruikers geen toegang hebben tot beheerdersfuncties. Ingelogd zijn geeft iemand niet automatisch toestemming om toegang te krijgen tot elk record. De server moet de rechten controleren voor elk verzoek naar een beveiligd record of API-eindpunt.

CSRF-beveiliging controleren

Bij een CSRF-aanval wordt de browser van een ingelogde gebruiker misleid om een actie uit te voeren waarvoor hij geen toestemming heeft gegeven, zoals het wijzigen van accountgegevens. Controleer om te beginnen formulieren en verzoeken waarmee gegevens worden gewijzigd, met name die welke via sessiecookies worden geauthenticeerd.

Controleer de CSRF-beveiliging in je Laravel- of Symfony-applicatie en kijk of er routes zijn uitgesloten. Test, waar tokenvalidatie van toepassing is, verzoeken met ontbrekende of ongeldige tokens. Controleer ook of vervalste verzoeken van een andere website geen gebruikersgegevens kunnen wijzigen. Controleer ook de SameSite-instelling voor sessiecookies.

In Laravel Blade voegt @csrf een verborgen tokenveld toe aan een formulier:


    @csrf
    

Er is een belangrijk detail in Laravel 13. De CSRF-middleware controleert eerst de Sec-Fetch-Site-header. Een verzoek van dezelfde oorsprong kan zonder token worden doorgelaten, terwijl andere verzoeken standaard terugvallen op tokenvalidatie. Laravel schakelt de CSRF-beveiliging tijdens geautomatiseerde tests ook standaard uit, dus zorg ervoor dat deze is ingeschakeld wanneer je deze beveiligingsmaatregelen test.

Voor API’s is de authenticatiemethode van belang. Een stateless API die gebruikmaakt van bearer-tokens in autorisatieheaders heeft over het algemeen te maken met andere CSRF-risico’s. Maar als je SPA afhankelijk is van sessiecookies, heeft deze nog steeds bescherming nodig tegen vervalste verzoeken.

Veilig bestanden uploaden en toegang tot bestanden

Het uploaden van bestanden vormt een veiligheidsrisico wanneer aanvallers uitvoerbare bestanden kunnen uploaden of toegang krijgen tot gegevens die ze niet mogen inzien. Controleer welke bestandstypen en -groottes je applicatie accepteert, waar de geüploade bestanden worden opgeslagen en wie ze kan downloaden. Test de upload- en downloadroutes op path traversal, zorg ervoor dat geüploade bestanden niet als PHP kunnen worden uitgevoerd, en controleer of .env, .git en back-upbestanden niet openbaar toegankelijk zijn.

Hieronder staat een PHP-voorbeeld dat het MIME-type van een geüpload bestand controleert en het opslaat onder een willekeurig gegenereerde naam:

if (($_FILES['file']['error'] ?? null) !== UPLOAD_ERR_OK) {
    throw new RuntimeException('Upload mislukt');
}

$tmp = $_FILES['file']['tmp_name'];
$allowed = ['image/jpeg' => 'jpg', 'image/png' => 'png'];
$mime = (new finfo(FILEINFO_MIME_TYPE))->file($tmp);

if (!isset($allowed[$mime])) {
    throw new RuntimeException('Niet-ondersteund bestandstype');
}

$name = bin2hex(random_bytes(16)) . '.' . $allowed[$mime];
$target = '/var/app/private-uploads/' . $name;

if (!move_uploaded_file($tmp, $target)) {
    throw new RuntimeException('Kan upload niet opslaan');
}

In dit voorbeeld wordt uitgegaan van het uploaden van één bestand en een bestaande, privé-map met de juiste machtigingen. De functie move_uploaded_file() van PHP bevestigt dat het bronbestand is geüpload via het HTTP POST-mechanisme

van PHP.

MIME-controle alleen is niet voldoende om uploads veilig te maken. Productiecode heeft ook door de server afgedwongen limieten voor bestandsgrootte, upload- en downloadrechten en validatie van de daadwerkelijke bestandsinhoud nodig. Codeer afbeeldingen waar nodig opnieuw en overweeg het scannen op malware voor uploads met een hoger risico. Bewaar bestanden waar mogelijk buiten de webroot, beperk de toegang tot het bestandssysteem en voorkom dat geüploade bestanden als PHP worden uitgevoerd.

Bescherm gevoelige gegevens en inloggegevens

Openbaar gemaakte databasewachtwoorden, API-sleutels en toegangstokens kunnen aanvallers toegang geven tot uw applicatie of gevoelige gegevens. Controleer uw broncode en Git-geschiedenis op deze geheimen. Tools zoals Gitleaks kunnen helpen bij het opsporen ervan. Zorg ervoor dat .env-bestanden niet in Git worden opgeslagen of via het web toegankelijk zijn. Controleer ook wie toegang heeft tot geheimen in CI/CD-pijplijnen, en controleer containerimages en applicatielogboeken op gevoelige informatie.

Bewaar geheimen in een geheimenbeheerder of een ander systeem met beperkte toegang, in plaats van in applicatiecode. Beperk wie ze kan bekijken of wijzigen, en geef elke applicatie alleen de rechten die nodig zijn.

Als een inloggegeven openbaar is geworden, trek deze dan in of vervang deze en werk de diensten bij die er gebruik van maken. Verwijder openbaar geworden kopieën, onderzoek of iemand deze zonder toestemming heeft gebruikt en voorkom dat geheimen in toekomstige logbestanden verschijnen. Het verwijderen van een geheim uit je code schakelt het niet uit en wist het ook niet uit oude Git-commits.

Laat een deskundige PHP-beveiligingsbeoordeling uitvoeren

Hoe je PHP-beveiligingsoplossingen

prioriteert, implementeert en controleert
01
Geef prioriteit aan kwetsbaarheden

Geef prioriteit aan systemen die blootstaan aan aanvallen. Weeg de CVSS-score af tegen de PHP SAPI, blootstelling aan het internet, bestaande beveiligingsmaatregelen en de impact op het bedrijf. Niet-gepatchte mod_php-workloads die in contact staan met het internet vereisen dringende aandacht, terwijl andere SAPI’s nog moeten worden beoordeeld.

02
Patches veilig installeren

Leg de getroffen applicaties, PHP-werkpools en de digests van containerimages vast. Test in de staging-omgeving en stel een herstelplan op vóór de implementatie. Breng patches aan op de getroffen pakketten of bouw de images opnieuw op, en start vervolgens alle getroffen workers opnieuw op of vervang ze. WAF-regels en configuratiemaatregelen kunnen de blootstelling aan specifieke exploitpaden verminderen. Ze brengen echter geen patch aan op de kwetsbare runtime.

03
Controleer of de maatregelen zijn uitgevoerd

Controleer welke PHP-build live-verzoeken verwerkt en controleer de patchstatus ervan, inclusief eventuele backports van de leverancier. Controleer of de betrokken workers opnieuw zijn opgestart of vervangen, voer regressietests uit en herhaal de eerder mislukte beveiligingscontrole. Houd de productieomgeving na de implementatie in de gaten op fouten.

04
Onderzoek of er sprake is van een inbreuk

Het installeren van een patch verhelpt de kwetsbaarheid. Eventuele eerdere inbreuken moeten nog worden onderzocht. Controleer de serverlogs, crashes van workers, onbekende bestanden en verdachte netwerkactiviteit. Bij mod_php kan PHP2Shell worden uitgevoerd voordat de logboekregistratie van de applicatie begint, waardoor een aanval niet kan worden uitgesloten op basis van schone frameworklogs. Meld waarschuwingssignalen aan het incidentresponsteam en bewaar het bewijsmateriaal.

05
Zorg voor veiligheid

Houd nieuwe kwetsbaarheden in PHP en de bijbehorende afhankelijkheden bij, en voeg beveiligingscontroles toe aan CI/CD. Baseer regelmatige beoordelingen op de blootstelling van de applicatie en het bedrijfsrisico, en voer een herbeoordeling uit na ingrijpende wijzigingen of kritieke onthullingen.

arrow-icon.arrow-icon.
01 Geef prioriteit aan kwetsbaarheden

Geef prioriteit aan systemen die blootstaan aan aanvallen. Weeg de CVSS-score af tegen de PHP SAPI, blootstelling aan het internet, bestaande beveiligingsmaatregelen en de impact op het bedrijf. Niet-gepatchte mod_php-workloads die in contact staan met het internet vereisen dringende aandacht, terwijl andere SAPI’s nog moeten worden beoordeeld.

arrow-icon.arrow-icon.
02 Patches veilig installeren

Leg de getroffen applicaties, PHP-werkpools en de digests van containerimages vast. Test in de staging-omgeving en stel een herstelplan op vóór de implementatie. Breng patches aan op de getroffen pakketten of bouw de images opnieuw op, en start vervolgens alle getroffen workers opnieuw op of vervang ze. WAF-regels en configuratiemaatregelen kunnen de blootstelling aan specifieke exploitpaden verminderen. Ze brengen echter geen patch aan op de kwetsbare runtime.

arrow-icon.arrow-icon.
03 Controleer of de maatregelen zijn uitgevoerd

Controleer welke PHP-build live-verzoeken verwerkt en controleer de patchstatus ervan, inclusief eventuele backports van de leverancier. Controleer of de betrokken workers opnieuw zijn opgestart of vervangen, voer regressietests uit en herhaal de eerder mislukte beveiligingscontrole. Houd de productieomgeving na de implementatie in de gaten op fouten.

arrow-icon.arrow-icon.
04 Onderzoek of er sprake is van een inbreuk

Het installeren van een patch verhelpt de kwetsbaarheid. Eventuele eerdere inbreuken moeten nog worden onderzocht. Controleer de serverlogs, crashes van workers, onbekende bestanden en verdachte netwerkactiviteit. Bij mod_php kan PHP2Shell worden uitgevoerd voordat de logboekregistratie van de applicatie begint, waardoor een aanval niet kan worden uitgesloten op basis van schone frameworklogs. Meld waarschuwingssignalen aan het incidentresponsteam en bewaar het bewijsmateriaal.

arrow-icon.arrow-icon.
05 Zorg voor veiligheid

Houd nieuwe kwetsbaarheden in PHP en de bijbehorende afhankelijkheden bij, en voeg beveiligingscontroles toe aan CI/CD. Baseer regelmatige beoordelingen op de blootstelling van de applicatie en het bedrijfsrisico, en voer een herbeoordeling uit na ingrijpende wijzigingen of kritieke onthullingen.

Praktijkvoorbeeld: een productie-patch die succesvol lijkt, maar dat niet is

Een Symfony-webshop draait op PHP 8.3 achter nginx en PHP-FPM. De beheerder werkt de OS-pakketten bij en voert php -v uit. Het commando toont een gepatchte versie, dus alles lijkt in orde. Maar php -v controleert alleen het PHP-binaire bestand op de opdrachtregel.

Verzoeken van klanten gaan nog steeds via nginx naar PHP-FPM-workers die vóór de update zijn gestart. Achtergrondtaken worden ook uitgevoerd in een aparte container met een kwetsbare PHP-basislaag. De pakketten zijn misschien wel bijgewerkt op de server, maar deze workloads draaien nog steeds de oude code.

PHP build checks for web, workers, and CLI.

Om de patch af te ronden, moet het team alle getroffen applicaties en workerpools identificeren, de FPM-workers opnieuw opstarten en de wachtrijcontainer opnieuw implementeren met een gepatchte image. Vervolgens moeten ze controleren of de actieve PHP-processen gebruikmaken van gecorrigeerde builds of geverifieerde backports van de leverancier.

Test het uitchecken en het uploaden van bestanden in de staging-omgeving, voer smoke-tests uit in de productieomgeving en herhaal de beveiligingscontroles die eerder zijn mislukt. Het implementatierapport moet de PHP SAPI bevatten die het webverkeer afhandelt, geverifieerde pakketversies of image-digests, bewijs van het herstarten en testen, en de verantwoordelijke.

Een geslaagde Composer-audit is geen bewijs dat PHP2Shell is verholpen. Dat commando controleert afhankelijkheden, niet de PHP-interpreter die webverzoeken verwerkt.

Controleer de gebruikers-ID van de PHP-worker, de mappen waarin hij schrijftoegang heeft, de gekoppelde geheimen, de databaserechten en de uitgaande netwerktoegang. Deze factoren bepalen of een aanvaller applicatiebestanden kan wijzigen, inloggegevens kan lezen of andere systemen kan bereiken. Het principe van minimale rechten en netwerksegmentatie kunnen de schade beperken als een worker gecompromitteerd raakt, maar het patchen van de interpreter blijft noodzakelijk.

php -v geeft de PHP-versie op de opdrachtregel weer, maar kan niet vaststellen welke interpreter het productieverkeer verwerkt of of langlopende workers nog steeds de kwetsbare build gebruiken. Met PHP2Shell controleren we eerst de actieve runtime en bekijken we vervolgens de afhankelijkheden en de applicatiecode. We beschouwen de herstelmaatregelen pas als voltooid nadat we hebben bevestigd dat de gepatchte versie daadwerkelijk productieverzoeken verwerkt.
Stanislav Kazanov, Head of GRC and Cybersecurity.
Stanislav Kazanov
Hoofd GRC, Cybersecurity & Duurzaamheid

Hoe Innowise u kan helpen bij het beveiligen van uw PHP-toepassingen

Bij Innowise brengen we PHP-ontwikkeling en beveiligingsexpertise samen. Onze meer dan 100 PHP-ontwikkelaars hebben meer dan 250 projecten opgeleverd, en onze meer dan 50 cyberbeveiligingsingenieurs helpen bij het opsporen en verhelpen van kwetsbaarheden. Ons werk wordt bovendien ondersteund door ISO/IEC 27001:2022- en ISO 9001:2015-certificeringen.

We controleren uw PHP-applicaties op beveiligingsproblemen, waaronder kwetsbare afhankelijkheden en verouderde componenten. Onze ontwikkelaars voeren de benodigde reparaties en upgrades uit, terwijl beveiligingsingenieurs de wijzigingen testen voordat ze worden vrijgegeven. Als u niet zeker weet waar u moet beginnen, kan ons IT-beveiligingsadvies team kan de risico’s beoordelen en helpen bij het stellen van prioriteiten voor de werkzaamheden.

ISO 27001 icon.
ISO-27017-2015.
ISO-27018 icon.
ISO 9001 icon.

Onze PHP-projecten

Herontwerp en heropbouw van de website van MedSpa Network
Innowise heeft de website van MedSpa Network opnieuw opgebouwd in WordPress, waardoor het team nu zelf de dagelijkse inhoudsupdates kan beheren.
2 maanden vanaf de start tot de lancering
3-5 leads per week, een stijging ten opzichte van 1 per maand
Bekijk de casestudy
Beoordeling door een klant
Bekijk de casestudy
Client review logo. Beoordeling door een klant
MedSpa Network website redesign and rebuild.
AI-bot voor de marketingcampagne van TBC Bank
Innowise heeft een tweetalige Telegram-bot ontwikkeld die met behulp van AI selfies genereert met de voetbalster die als merkambassadeur voor TBC Bank optreedt.
3,000 betrokken gebruikers
2 ondersteunde talen
Bekijk de casestudy
Beoordeling door een klant
Bekijk de casestudy
Client review logo. Beoordeling door een klant
AI Telegram bot..
Het vaststellen van de productstrategie voor het bitcoin-uitleenplatform van Bitlendex
Innowise heeft voor Bitlendex een verkenningsfase uitgevoerd en de klant daarbij geholpen om een productconcept in een vroeg stadium om te zetten in een gevalideerd bedrijfsmodel en een duidelijk omschreven MVP.
1 maand voor een uitgebreide verkenningsfase
Financieel adviessysteem voor Bonnfinanz
Innowise heeft Bonnfinanz geholpen bij het opzetten van een webgebaseerd advies- en administratiesysteem dat mobiel werken en directe interactie met de klant ondersteunt.
Laadplatform voor elektrische voertuigen met flexibele facturering
Innowise heeft bijgedragen aan de modernisering van het e-mobiliteitsplatform van SMART/LAB door de functionaliteiten op het gebied van facturering, betalingen, transactiebeheer en rapportage te verbeteren.
>50% snellere facturering en betalingsverwerking
Cloud-native DevOps-transformatie van FinXP
Innowise heeft FinXP geholpen bij het moderniseren van zijn infrastructuur voor financiële diensten door verouderde, op PHP gebaseerde API’s en applicaties te migreren naar een cloud-native architectuur.
11 apps verplaatst naar Azure App Service
100% Infrastructuur als code
Technische SEO voor e-commerceplatform
Innowise heeft cruciale technische SEO- en prestatieproblemen op het e-commerceplatform van Officine 08 aangepakt.
<500 ms responstijd van de server
5 maanden om het project af te ronden
Bekijk de casestudy
Beoordeling door een klant
Bekijk de casestudy
Client review logo. Beoordeling door een klant
Technische SEO voor e-commerceplatform.
Voortdurende ontwikkeling van een abonnementsplatform voor parfums
Innowise heeft Scentbird geholpen bij de uitbreiding van zijn abonnementsplatform om nieuwe winkelervaringen en internationale groei mogelijk te maken.
4 jarenlange ononderbroken steun
Bekijk de casestudy
Beoordeling door een klant
Bekijk de casestudy
Client review logo. Beoordeling door een klant
Continuous development of a fragrance subscription platform.
01 / 01
Close popup icon

Conclusie

PHP2Shell bracht een ernstig risico aan het licht in de PHP-interpreter zelf. Updates van frameworks en controles op afhankelijkheden lossen kwetsbaarheden op dat niveau niet op. Bedrijven moeten elke PHP-runtime identificeren die webverzoeken verwerkt, de beveiligingsupdates installeren en controleren of de productieservers de gepatchte versies draaien.

PHP-beveiliging vereist ook regelmatige controles van de applicatiecode, configuratie en toegangscontroles, met name na de bekendmaking van kritieke kwetsbaarheden of grote updates. Als u hulp nodig hebt bij het beoordelen van uw risico’s of het verifiëren van de oplossingen, Innowise’s IT-beveiligingsadvies- en cyberbeveiligingsbeoordelings-teams van Innowise kunnen u daarbij ondersteunen.

FAQ

Uw applicatie loopt mogelijk risico als uw server een PHP-versie draait die nog niet is gepatcht voor CVE-2026-109618 en CVE-2026-109619. Controleer welke PHP-versie daadwerkelijk wordt gebruikt en of uw hostingprovider de patches heeft toegepast. Apache mod_php heeft het hoogste bevestigde risico, maar PHP-FPM moet ook worden gecontroleerd. Aangezien de kwetsbaarheden in PHP zelf zitten, lost het updaten van WordPress of een ander framework deze niet op.

Er zijn oplossingen voor PHP2Shell beschikbaar in PHP 8.2.35, 8.3.36, 8.4.27 en 8.5.12. Sommige Linux-leveranciers hebben de patches teruggeport naar oudere versies, dus raadpleeg het advies van uw leverancier. Zorg ervoor dat uw actieve PHP-workers de gepatchte versie gebruiken. Installeer op Windows de bijgewerkte pakketten van 26 oktober die eindigen op -1; deze verhelpen ook een afzonderlijke Brotli-kwetsbaarheid.

Als u PHP niet meteen kunt updaten, beperk dan waar mogelijk de openbare toegang tot de getroffen applicaties. Voor sites die online moeten blijven, kan uw serverbeheerder tijdelijke maatregelen toepassen uit het PHP-beveiligingsadvies, zoals het beperken van de grootte van verzoeken of het uitschakelen van de voortgang van sessie-uploads. Test deze wijzigingen om er zeker van te zijn dat de site nog steeds werkt. Ze verminderen alleen het risico, dus het installeren van een gepatchte PHP-versie blijft dringend.

Nee. Het updaten van PHP verhelpt kwetsbaarheden in de PHP-runtime, maar lost geen beveiligingsproblemen op in uw applicatiecode, verouderde plug-ins of serverconfiguratie. U moet deze apart controleren en aanpakken.

Ik raad aan om PHP-toepassingen minstens één keer per maand te controleren op bekende kwetsbaarheden, en vaker bij systemen met een hoog risico. Houd PHP-beveiligingsadviezen en -afhankelijkheden continu in de gaten en plan grondigere controles in op basis van de blootstelling van uw applicatie en het bedrijfsrisico. Aanvullende tests zijn belangrijk na grote updates of wanneer kritieke kwetsbaarheden bekend worden gemaakt.

Raadpleeg PHP-beveiligingsadviezen en de bulletins van uw hostingprovider of besturingssysteemleverancier voor bekende kwetsbaarheden. Gebruik `composer audit --locked` om afhankelijkheden te controleren, voer statische analyse en codereview uit om problemen op applicatieniveau op te sporen, en gebruik OWASP ZAP om uw webapplicatie met toestemming te testen. Om beveiligingspatches te verifiëren, controleert u de PHP-versie die in productie draait en eventuele fixes die door uw leverancier zijn teruggeporteerd.

Ja. Updates kunnen compatibiliteitsproblemen veroorzaken met oudere code of extensies. Test ze eerst in de testomgeving voordat je je live-applicatie bijwerkt, en zorg dat je een herstelplan klaar hebt voor het geval er iets misgaat.

Breng de logbestanden van de reverse-proxy, Apache/nginx, PHP-FPM en EDR/host met elkaar in verband. Zoek naar crashes van workers, verdachte bestanden of processen, onverwacht uitgaand verkeer en tekenen van blootstelling van inloggegevens. Applicatielogbestanden kunnen PHP-runtime-exploits missen die plaatsvinden voordat het framework begint met loggen. Als u verdachte activiteiten ontdekt, start dan de incidentrespons en bewaar forensisch bewijsmateriaal.

Meer tonen Toon minder

Inhoudsopgave

Ontdek welke PHP-workloads als eerste een beveiligingsupdate nodig hebben

    Contacteer ons

    Boek een gesprek of vul het onderstaande formulier in en we nemen contact met u op zodra we uw aanvraag hebben verwerkt.

    Stuur ons een spraakbericht
    Documenten bijvoegen
    Bestand uploaden

    Je kunt 1 bestand van maximaal 2 MB bijvoegen. Geldige bestandsformaten: pdf, jpg, jpeg, png.

    Door op ‘Stuur’ te klikken, stemt u ermee in dat Innowise uw persoonsgegevens verwerkt volgens ons privacybeleid om u van relevante informatie te voorzien. Door uw telefoonnummer op te geven, gaat u ermee akkoord dat we contact met u opnemen via telefoongesprekken, sms en messaging-apps. Voor bellen, berichten en dataverbruik kunnen kosten in rekening worden gebracht.

    U kunt ons ook uw verzoek sturen
    naar contact@innowise.com
    Wat gebeurt er nu?
    1

    Zodra we uw aanvraag hebben ontvangen en verwerkt, nemen we contact met u op om de details van uw projectbehoeften te bespreken en tekenen we een NDA om vertrouwelijkheid te garanderen.

    2

    Na het bestuderen van uw wensen, behoeften en verwachtingen zal ons team een projectvoorstel opstellen met de omvang van het werk, de teamgrootte, de tijd en de geschatte kosten.

    3

    We zullen een afspraak met u maken om het aanbod te bespreken en de details vast te leggen.

    4

    Tot slot tekenen we een contract en gaan we meteen aan de slag met uw project.

    Meer diensten die we aanbieden

    arrow