Trender i CVE-publiceringen

47 802 CVE-poster publicerades 2025, en ökning med 20 % jämfört med året innan. 2026 har redan nått 88 746 med månader kvar.

Volymen har ökat varje år sedan CVE-programmet startade, men tillväxttakten förändrades kraftigt 2026. Använd diagrammet ovan för att se trenden per månad, kvartal eller år.

På den här sidan. Diagrammet och siffrorna ovan är CVE-statistik som byggs om dagligen från CVE-programmets repo cvelistV5, samma källa som CVE-programmet publicerar från.

De täcker publiceringsvolym efter CVSS-allvarlighetsgrad, efter tilldelande organisation och per vecka, månad, kvartal eller år, tillsammans med de senaste kritiska posterna. För detaljer om en enskild sårbarhet, följ en identifierare vidare till cve.org.

Tre saker händer samtidigt, och de publicerade posterna kan inte skilja dem åt.

Fler organisationer kan nu tilldela CVE-id:n, så sårbarheter som tidigare aldrig registrerades tas nu med. Automatiserad och AI-stödd sårbarhetsupptäckt har ökat hur mycket en enskild forskare kan hitta. Och CISA:s berikningsprogram har fyllt på detaljer i äldre poster, vilket ändrar historiska siffror i efterhand.

Ett stigande antal CVE:er är därför inte i sig ett bevis på att programvara blir mindre säker.

En CNA är en organisation som har behörighet att tilldela CVE-id:n och publicera poster inom sitt eget område, oftast sina egna produkter. 497 CNA:er förekommer i den här datan.

Leverantörer, projekt med öppen källkod, bug bounty-plattformar och nationella CERT fungerar alla som CNA:er. Störst här är mitre, med 39 586 poster. Eftersom en enskild CNA som ändrar sin process kan flytta totalsiffrorna märkbart kan du i diagrammet filtrera på en organisation i taget.

CVSS poängsätter en sårbarhet från 0,0 till 10,0 och delar in den i band: Låg (0,1-3,9), Medel (4,0-6,9), Hög (7,0-8,9) och Kritisk (9,0-10,0).

Poängen beskriver inneboende tekniska egenskaper, till exempel hur sårbarheten nås och vad den komprometterar. Den är inte ett mått på hur stor risken är för en viss organisation.

18.0% av posterna som publicerats sedan 2020 saknar CVSS-poäng i både CNA:ns egna data och CISA:s berikning.

Poängsättning krävdes inte under större delen av CVE-programmets historia. Täckningen förbättras brant från 2023 och framåt och är nu nästan heltäckande, så det att Okänd-bandet i diagrammet krymper speglar en ändrad rapporteringspraxis, inte någon förändring i själva sårbarheterna. En analys som ignorerar poster utan poäng underskattar äldre år.

En sårbarhet är en brist i programvara. En CVE är en offentlig identifierare som tilldelas ett specifikt, offentliggjort fall av en sådan brist.

De flesta sårbarheter får aldrig någon CVE: de hittas och åtgärdas internt, eller så faller de utanför alla CNA:ers område. CVE-antal mäter därför aktiviteten kring offentliggörande, inte hur många brister som faktiskt finns.

Varje siffra bygger på CVE-programmets officiella repo cvelistV5, med ögonblicksbilden tagen 31 okt. 2026 UTC.

Poster räknas efter publiceringsdatum och inte efter året i CVE-id:t, eftersom ungefär en femtedel av posterna publiceras ett annat år än det som identifieraren anger. Avvisade och återkallade poster räknas inte med.

Inte i sig. En Kritisk sårbarhet i en komponent du levererar men aldrig anropar kan vara mindre brådskande än en Medel i ditt publika API.

Verklig prioritering kräver att du vet om den berörda komponenten finns i din programvara, om den sårbara koden går att nå och om sårbarheten utnyttjas. CVSS svarar inte på något av det.

CRA kräver att tillverkare hanterar sårbarheter under produktens hela supportperiod, rapporterar aktivt utnyttjade sårbarheter till ENISA inom 24 timmar från att de fått kännedom om dem och håller den tekniska dokumentationen aktuell.

Dessa skyldigheter växer med volymen i det här diagrammet. Att triagera tiotusentals nya poster per år mot din egen programvara är inte realistiskt att göra manuellt, och därför förutsätter CRA i praktiken en SBOM och en automatiserad matchningsprocess.

Du behöver en korrekt inventering av vad din programvara innehåller och därefter löpande matchning av inventeringen mot CVE-flödet.

CRACI genererar en SBOM från ditt bygge, matchar den mot nya CVE-poster när de publiceras och visar bara de säkerhetsmeddelanden som når kod du faktiskt levererar, tillsammans med dokumentationen som CRA förväntar sig att du sparar.

Se hur sårbarhetsuppföljning fungerar i praktiken.