--- title: "Wat is CVE? Uitleg en betekenis | Keurig Online" description: "CVE (Common Vulnerabilities and Exposures) is een openbare lijst die elk bekend beveiligingslek een eigen, vast nummer geeft." canonical: https://www.keurigonline.nl/begrippenlijst/cve last_modified: 2025-12-18 --- [Terug naar begrippenlijst](https://www.keurigonline.nl/begrippenlijst) # CVE CVE (Common Vulnerabilities and Exposures) is een openbare lijst die elk bekend beveiligingslek een eigen, vast nummer geeft. Actueel: [PHP-lek PHP2Shell (session.upload\_progress): status en wat je moet doen](https://www.keurigonline.nl/blog/php-kwetsbaarheid-session-upload-progress) Een CVE (Common Vulnerabilities and Exposures) is een vast nummer voor een openbaar bekend beveiligingslek, zoals CVE-2021-44228 voor het Log4Shell-lek in Java-software. Dankzij dat nummer weten softwaremakers, beveiligers en hostingbedrijven zeker dat ze over hetzelfde lek praten, ook als het in het nieuws een bijnaam krijgt. Het nummer bestaat uit het jaar en een volgnummer. Sinds 2015 mag dat volgnummer langer zijn dan vier cijfers, omdat vier cijfers, dus hooguit 9.999 lekken per jaar, niet meer genoeg waren. De nummers worden uitgegeven door CVE Numbering Authorities (CNA's): softwaremakers, beveiligingsbedrijven en coördinatoren die het CVE-programma daarvoor heeft erkend. Bij elk nummer hoort een record met een korte beschrijving en verwijzingen naar adviezen en reparaties. Een CVE-nummer zegt niets over hoe ernstig een lek is. Daarvoor bestaat de CVSS-score, die meestal naast het nummer staat. Ook kleine lekken krijgen een nummer, dus een XSS-lek in een WordPress-plugin kan net zo goed een CVE hebben als een lek in PHP zelf. Een voorbeeld: in oktober 2026 repareerde het PHP-team twee kritieke lekken, CVE-2026-109618 en CVE-2026-109619. Met die nummers zoek je op of jouw software geraakt is en of je leverancier al een reparatie heeft. Beheer je zelf een server, dan is het nummer extra handig, omdat een gerepareerde PHP-versie vaak hetzelfde versienummer houdt. Je zoekt dan het CVE-nummer in de changelog van het pakket, bijvoorbeeld met rpm -q --changelog alt-php74-common. ## Geschiedenis David Mann en Steven Christey van de Amerikaanse non-profit MITRE beschreven het idee in januari 1999 in de paper *Towards a Common Enumeration of Vulnerabilities*. Uit hun werkgroep kwamen de eerste 321 records voort, en in september 1999 ging de lijst openbaar ([CVE-geschiedenis](https://www.cve.org/About/History)). Belangrijke mijlpalen: - **1999:** De CVE-lijst gaat openbaar met 321 records - **2005:** De rol van CVE Numbering Authority (CNA) wordt formeel vastgelegd - **2015:** Nieuwe notatie: het volgnummer mag langer zijn dan vier cijfers ([Wikipedia](https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures)) - **2021:** Log4Shell krijgt [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) en de maximale CVSS-score van 10,0 - **2025:** Het contract van MITRE met de Amerikaanse overheid dreigt in april af te lopen en wordt op het laatste moment met elf maanden verlengd ## Bronnen 1. **CVE Program** - [Overview: About the CVE Program](https://www.cve.org/About/Overview) 2. **CVE Program** - [History of the CVE Program](https://www.cve.org/About/History) 3. **Wikipedia** - [Common Vulnerabilities and Exposures](https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures) 4. **NIST NVD (2021)** - [CVE-2021-44228 Detail](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) 5. **PHP (2026)** - [Security advisory: critical remote code execution vulnerabilities](https://www.php.net/archive/2026.php) ## Gerelateerde artikelen Beveiliging 22 okt 2026 [CVE-2026-109618 en -109619: de technische deepdive](https://www.keurigonline.nl/blog/php-lek-cve-2026-109618-deepdive) **Samenvatting: de techniek achter onze aanpak van CVE-2026-109618 en -109619** Beide lekken zitten in de PHP-engine, nog vóór de code van een site draait. Hoe groot het risico is, hangt af van de SAPI: mod\_php was het bevestigde doelwit, PHP-FPM en LiteSpeed draaien PHP in aparte processen. Wij zetten `session.upload_progress` uit op elke PHP-build, maten na dat ook de draaiende processen de instelling gebruikten, lieten Imunify360 het aanvalspatroon blokkeren en installeerden de vendor-builds zodra ze verschenen. Omdat het versienummer na de fix vaak gelijk blijft, controleerden we elke binary op de symbolen die de fix meebrengt. Beveiliging 22 okt 2026 [Het PHP-lek van 21 oktober: wat we deden en waarom we online bleven](https://www.keurigonline.nl/blog/php-lek-terugblik) Op 21 oktober kwamen twee kritieke lekken in PHP naar buiten, inmiddels bekend als PHP2Shell. Veel hosters haalden hun servers offline. Wij hebben dat niet gedaan. We schermden het lek dezelfde ochtend af met meerdere lagen beveiliging, en installeerden elke update van PHP, DirectAdmin en CloudLinux zodra die verscheen. Op 22 oktober om 02:16 uur draaiden al onze servers op de gerepareerde PHP-versies. We zien in ons netwerk geen sporen van misbruik. Bekijk de tijdlijn **Alleen weten of je iets moet doen?** Lees [de status van het PHP-lek en ons advies](https://www.keurigonline.nl/blog/php-kwetsbaarheid-session-upload-progress). **Meer techniek?** Configuraties, versies en hoe je een PHP-build zelf controleert, staan in [de technische deep dive over CVE-2026-109618](https://www.keurigonline.nl/blog/php-lek-cve-2026-109618-deepdive). Een kritiek lek in PHP raakt bijna elke website. WordPress, WooCommerce, Joomla en de meeste webwinkels draaien erop. Toen het PHP-team op dinsdag 20 oktober een beveiligingsupdate aankondigde voor twee lekken met een CVSS-score van 9,2, wisten we dat de dagen daarna spannend zouden worden. Blog 21 okt 2026 [PHP-lek PHP2Shell (session.upload\_progress): status en wat je moet doen](https://www.keurigonline.nl/blog/php-kwetsbaarheid-session-upload-progress) Al onze servers zijn bijgewerkt. Op 21 oktober hebben we het lek overdag eerst afgeschermd, en vanaf 16:10 uur de officiële PHP-update geïnstalleerd. In de nacht naar 22 oktober volgden de laatste servers en de oudere PHP-versies. Om 02:16 uur was alles klaar. We zien in ons netwerk geen sporen van misbruik. - **Terugblik:** wat we deden en waarom we online bleven, lees je in [onze terugblik: waarom we online bleven](https://www.keurigonline.nl/blog/php-lek-terugblik). - **Technische deepdive:** configuraties, versies en hoe je een PHP-build zelf controleert, staan in [de technische deep dive over CVE-2026-109618](https://www.keurigonline.nl/blog/php-lek-cve-2026-109618-deepdive). - **Je hoeft niets te doen.** Werkt je website, dan is alles in orde. Heb je problemen? Vul dan het contactformulier in op [onze contactpagina](https://www.keurigonline.nl/contact).