Kritieke cPanel-kwetsbaarheid misbruikt vanaf 44.000 IP's

Kritieke cPanel-kwetsbaarheid misbruikt vanaf 44.000 IP's

Op 28 april 2026 bracht cPanel een spoedbeveiligingsupdate uit voor CVE-2026-41940, een kritieke kwetsbaarheid in cPanel & WHM waarmee de authenticatie kan worden omzeild. De fout heeft een CVSS-score van 9,8 en stelt aanvallers zonder authenticatie in staat om op afstand beheerderstoegang op rootniveau te krijgen tot de Web Host Manager-interface (WHM), via een CRLF-injectie in combinatie met een race condition bij sessiebestanden. Wereldwijd draaien naar schatting meer dan 70 miljoen domeinen op cPanel; daarmee behoort de reikwijdte van deze kwetsbaarheid tot de grootste in de geschiedenis van hostinginfrastructuur.

Al vanaf 23 februari 2026 is actief misbruik bevestigd, meer dan twee maanden voordat de officiële patch verscheen. Toen het beveiligingsadvies werd gepubliceerd, had The Shadowserver Foundation 44.000 unieke IP-adressen waargenomen die kwetsbare cPanel-installaties scanden, aftastten of actief misbruikten. Een openbaar proof-of-concept-framework met de naam "cPanelSniper" maakte de kwetsbaarheid in korte tijd inzetbaar als wapen, met geautomatiseerd massaal scannen, het plaatsen van backdoors en de installatie van ransomware in gedeelde hostingomgevingen.

Wat er is gebeurd

De kwetsbaarheid zit in cpsrvd, de servicedaemon van cPanel die het inloggen en het sessiebeheer afhandelt. Concreet is de manier waarop de module Session.pm Authorization-headers in HTTP-verzoeken verwerkt, vatbaar voor CRLF-injectie (Carriage Return Line Feed). Een aanvaller kan willekeurige sleutel-waardeparen, zoals user=root, hasroot=1 en tfa_verified=1, rechtstreeks in de sessieopslag op de server injecteren.

Een tweede fout verergert de eerste: cPanel slaat sessiegegevens zowel in een ruw tekstbestand als in een JSON-cache op, en door een race condition tussen die twee schrijfacties blijven de door de aanvaller geïnjecteerde gegevens bewaard en worden ze door de authenticatielaag vertrouwd. Door de cookie whostmgrsession zo te manipuleren dat die naar het vergiftigde sessiebestand verwijst, omzeilt de aanvaller alle authenticatiecontroles, inclusief tweefactorauthenticatie, en krijgt hij een volledig geauthenticeerde rootsessie. Er zijn geen geldige inloggegevens, geen eerdere toegang en geen interactie van gebruikers nodig.

cPanel bracht op 28 april 2026 patches uit voor alle ondersteunde versies na 11.40. CISA nam CVE-2026-41940 op in zijn KEV-catalogus (Known Exploited Vulnerabilities), waardoor federale instanties verplicht zijn de kwetsbaarheid binnen de voorgeschreven termijn te verhelpen.

Welke gegevens zijn buitgemaakt

Op gecompromitteerde servers kregen aanvallers volledige beheerderscontrole, waardoor alles wat op de machine werd gehost toegankelijk was. Incidentresponsteams die datalekken in verband met CVE-2026-41940 onderzoeken, melden de exfiltratie van:

  • Websitedatabases en broncode

    Aanvallers dumpten MySQL- en PostgreSQL-databases met klantgegevens, inloggegevens, betaalinformatie en bedrijfskritische applicatiegegevens van alle accounts die op de gecompromitteerde servers werden gehost.

  • E-mailarchieven en inloggegevens

    Volledige mailboxinhoud, SMTP-inloggegevens en adresboeken werden buitgemaakt. Verschillende bevestigde phishingcampagnes zijn herleid tot inloggegevens die via deze kwetsbaarheid zijn gestolen.

  • Privésleutels voor SSL/TLS

    Privésleutels van certificaten die op gecompromitteerde servers waren opgeslagen, werden ontvreemd. Dat maakt man-in-the-middle-aanvallen mogelijk op domeinen die hun certificaten nog niet hebben ingetrokken en opnieuw hebben laten uitgeven.

  • Inloggegevens en API-sleutels op serverniveau

    SSH-sleutels van root, API-tokens van cloudproviders, inloggegevens voor DNS-beheer en toegang tot back-upsystemen lagen allemaal binnen bereik zodra roottoegang tot WHM was verkregen.

In gedeelde hostingomgevingen draaien op één gecompromitteerde server doorgaans honderden tot duizenden onafhankelijke websites en accounts. Elk account op een getroffen server moet als volledig gecompromitteerd worden beschouwd, ongeacht de beveiligingspraktijken voor dat afzonderlijke account.

Hoe zulke aanvallen verlopen

De aanvalsketen begint met verkenning. Aanvallers zoeken naar servers die WHM op poort 2087 of cPanel op poort 2083 openstellen. Met service-fingerprinting stellen zij vast dat het doelwit een kwetsbare cPanel-versie draait. Het framework cPanelSniper automatiseert deze hele fase en verwerkt duizenden doelwitten per uur.

Zodra een doelwit is gevonden, stuurt de aanvaller een speciaal opgesteld HTTP-verzoek naar het inlogendpoint van WHM. Dat verzoek bevat een kwaadaardige Authorization-header met CRLF-reeksen die sessieattributen in het sessiebestand op de server injecteren. De geïnjecteerde attributen verlenen authenticatie op rootniveau. Vervolgens stuurt de aanvaller een tweede verzoek met een cookie whostmgrsession die naar de vergiftigde sessie verwijst. De server valideert de sessie, vindt de geïnjecteerde root-inloggegevens en geeft een volledig geauthenticeerde WHM-interface terug.

Wat er na het binnendringen gebeurt, hangt af van het motief van de aanvaller. Ransomware-operators versleutelen alle gehoste gegevens en eisen losgeld per server of per account. Dreigingsactoren met spionage als motief richten blijvende backdoors in via cronjobs, aangepaste systeembinaries of webshells die over de gehoste accounts worden verspreid. Cryptojackingcampagnes installeren miningsoftware die de rekenkracht van de server benut. In verschillende bevestigde gevallen gebruikten aanvallers hun toegang om het metadata-endpoint van de cloudprovider van de server te bereiken en van daaruit door te dringen in de bredere infrastructuur van de hostingprovider.

Waarom dit bestuurders aangaat

cPanel is het dominante beheerpaneel voor webhosting, met naar schatting 70 miljoen domeinen op honderdduizenden servers wereldwijd. Anders dan kwetsbaarheden in afzonderlijke applicaties, die één site treffen, raakt een compromittering van cPanel elke website, elke database, elk e-mailaccount en elke dienst die op die server wordt gehost. Voor hostingproviders kan één ongepatchte server leiden tot een gelijktijdig datalek bij elke klant op die machine.

Doordat de kwetsbaarheid twee maanden als zero-day werd misbruikt, van eind februari tot eind april 2026, kunnen servers die op de dag van de bekendmaking zijn gepatcht al gecompromitteerd zijn. Patchen alleen volstaat niet zonder een parallel forensisch onderzoek dat vaststelt of er in de periode vóór de patch toegang tot de server is verkregen. Organisaties die op externe hostingproviders vertrouwen, kunnen er niet van uitgaan dat hun provider snel heeft gepatcht of heeft onderzocht of er eerder een compromittering heeft plaatsgevonden.

Ransomware voegt daar directe financiële druk aan toe. Aanvallers eisen losgeld per server, en bij gedeelde hosting behoren ook bedrijven tot de slachtoffers die geen directe relatie hebben met de hostinginfrastructuur en geen zicht hebben op de patchstatus van de onderliggende server. De regulatoire risico's op grond van de AVG, PCI DSS en sectorspecifieke kaders zijn aanzienlijk wanneer klantgegevens op gecompromitteerde servers persoonsgegevens, betaalgegevens of medische dossiers bevatten.

Wat u nu moet doen

  1. Installeer de spoedpatch onmiddellijk

    Werk alle installaties van cPanel & WHM bij naar de nieuwste gepatchte versie die op 28 april 2026 is uitgebracht. Controleer of de update goed is toegepast door de versiestring van cPanel in WHM te bekijken. Als automatische updates waren uitgeschakeld of uitgesteld, behandel de server dan als mogelijk gecompromitteerd en start een forensisch onderzoek.

  2. Onderzoek of de server al eerder is gecompromitteerd

    Patchen maakt een bestaande compromittering niet ongedaan. Controleer de map /var/cpanel/sessions/raw op sessiebestanden met geïnjecteerde attributen zoals hasroot=1 of tfa_verified=1 uit onbekende bronnen. Doorzoek de toegangslogs van WHM op authenticatiegebeurtenissen vanaf onverwachte IP-adressen. Controleer alle gehoste accounts op nieuw aangemaakte cPanel-accounts, gewijzigde cronjobs, onbekende geautoriseerde SSH-sleutels en webshells.

  3. Beperk de blootstelling van beheerpoorten

    Blokkeer op de netwerkfirewall inkomend verkeer vanaf het openbare internet naar de poorten 2083, 2087, 2095 en 2096. Vereis een VPN of een IP-allowlist voor alle beheerderstoegang tot de interfaces van WHM en cPanel. Deze ene maatregel neemt de aanvalsvector op afstand volledig weg.

  4. Vervang alle inloggegevens

    Ga ervan uit dat alle inloggegevens die op de server zijn opgeslagen of via de server toegankelijk zijn, gecompromitteerd zijn. Vervang rootwachtwoorden, wachtwoorden van cPanel-accounts, database-inloggegevens, e-mailwachtwoorden, SSH-sleutels, SSL/TLS-certificaten, API-tokens en alle inloggegevens van externe diensten die op de server zijn geconfigureerd. Vraag gehoste klanten om hun eigen inloggegevens op applicatieniveau te vervangen.

  5. Voer een volledige beveiligingsbeoordeling uit

    Schakel een team voor penetratietesten in om te controleren of de patch correct is toegepast, of er geen blijvende backdoors achterblijven en of de serverconfiguratie geen extra aanvalsoppervlak blootstelt. Voor organisaties die gevoelige gegevens hosten, is een security code review van de maatwerkapplicaties op de server aan te raden, om vast te stellen of door aanvallers geplaatste code in de broncode van applicaties achterblijft.

Prangende vragen

  • Is mijn server gecompromitteerd voordat de patch uitkwam?

    Als op uw server op enig moment tussen 23 februari en 28 april 2026 een ongepatchte versie van cPanel & WHM draaide met poort 2083 of 2087 bereikbaar vanaf het internet, is er een aanzienlijke kans op compromittering. Actief misbruik is in deze periode bevestigd. Alleen een forensisch onderzoek van sessiebestanden, toegangslogs en systeemintegriteit kan uitwijzen of er een compromittering heeft plaatsgevonden.

  • Beschermt tweefactorauthenticatie tegen deze kwetsbaarheid?

    Nee. Met de CRLF-injectie kunnen aanvallers tfa_verified=1 rechtstreeks in het sessiebestand injecteren, waardoor tweefactorauthenticatie volledig wordt omzeild. De sessie wordt gemarkeerd alsof de 2FA-verificatie is voltooid, zonder dat die verificatie ooit heeft plaatsgevonden. Dit is geen zwakte van 2FA zelf, maar van de sessiebeheerlaag die eraan voorafgaat.

  • Ik maak gebruik van een hostingprovider. Ben ik getroffen?

    Als uw hostingprovider cPanel gebruikt om uw account te beheren, kunt u getroffen zijn, ongeacht uw eigen beveiligingspraktijken. Neem rechtstreeks contact op met uw hostingprovider om na te gaan of de patch is geïnstalleerd en of er forensisch onderzoek is gedaan naar de periode van misbruik vóór de patch. Als de provider niet beide kan bevestigen, overweeg dan gevoelige workloads te migreren naar infrastructuur die u zelf beheert.

  • Worden beheerde cPanel-installaties automatisch gepatcht?

    cPanel-servers met automatische updates ontvingen de patch kort na de release van 28 april. Veel productieservers schakelen automatische updates echter bewust uit om de stabiliteit te waarborgen, en die vereisen handmatige actie. Controleer uw updateconfiguratie en huidige versie via de interface "Upgrade to Latest Version" in WHM.

Belangrijkste inzichten

CVE-2026-41940 is een worstcasescenario voor gedeelde hostinginfrastructuur: roottoegang zonder authenticatie tot de beheerinterface van het meest gebruikte hostingbeheerpaneel ter wereld, twee maanden lang actief misbruikt als zero-day voordat er een patch beschikbaar was. De combinatie van uiterst eenvoudig misbruik, een enorm aanvalsoppervlak en bevestigde inzet van ransomware maakt dit tot een van de meest ingrijpende kwetsbaarheden in hostinginfrastructuur van de afgelopen jaren.

Patchen is noodzakelijk, maar niet voldoende. Elke organisatie die cPanel gebruikt, moet de patchstatus controleren, onderzoeken of er eerder een compromittering heeft plaatsgevonden, alle inloggegevens vervangen en de blootstelling van beheerinterfaces beperken tot vertrouwde netwerken. Organisaties die op externe hosting vertrouwen, moeten de reactie van hun provider rechtstreeks verifiëren. De aanname "mijn hostingprovider regelt de beveiliging" is geen verdedigbaar standpunt wanneer juist het beheerpaneel van die provider de aanvalsvector was.