Nuclei CVE-skanning: 12 Steg mot CISA KEV [2026]

Nya CVE-nummer dyker upp varje vecka, och de flesta säkerhetsteam i Norden hinner inte testa mer än en bråkdel av dem manuellt. Det är precis det problemet ProjectDiscoverys skanner Nuclei löser: ett kommandoradsverktyg som kör tusentals YAML-baserade testmallar mot dina egna mål och talar om exakt vilka sårbarheter som faktiskt går att utnyttja, inte bara vilka portar som är öppna. För team som redan jobbar efter NIS2-kraven eller en intern patchrutin blir det skillnaden mellan att gissa och att faktiskt veta.

Den här guiden går igenom hela flödet: installation, första skanningen, filtrering på CVE och allvarlighetsgrad, matchning mot CISA:s katalog över aktivt utnyttjade sårbarheter (KEV) och ett färdigt skanningsprojekt du kan köra i produktion. Allt är testat mot Nuclei v3.11.1 och mallpaketet nuclei-templates v10.5.0, som släpptes 5 oktober 2026.

Vad är Nuclei och varför används det så mycket just nu?

Nuclei beskrivs av ProjectDiscovery som en community-driven skanner för sårbarheter, felkonfigurationer, exponerade tjänster, teknikidentifiering, API:er, nätverk, DNS och molnkonfigurationer. Allt bygger på ett eget YAML-format där varje test, kallat en mall (template), beskriver exakt vad som ska skickas till målet och vilket svar som räknas som en träff. Det gör verktyget snabbt att utöka: när en ny sårbarhet publiceras kan en säkerhetsforskare skriva en mall på några minuter istället för att vänta på en leverantörsuppdatering.

Mallarkivet nuclei-templates har vuxit till nästan 12 000 filer, mer exakt 11 997 mallar fördelade över 873 mappar enligt den senaste sammanställningen av repositoriet 2026. Det är community-bidrag från bug bounty-jägare och sårbarhetsanalytiker, och enligt ProjectDiscovery läggs det löpande till detektioner för trendande CVE:er och sårbarheter som redan utnyttjas aktivt i det fria. Det är den direkta kopplingen till verklig exploatering, snarare än teoretiska brister, som gör Nuclei relevant för team som redan jobbar med CISA:s KEV-katalog eller motsvarande nationella varningslistor i Norden.

Ett konkret exempel är IngressNightmare, CVE-2025-1974, en sårbarhet i Ingress NGINX som fick patchade versioner 1.12.1 och 1.11.5. ProjectDiscovery publicerade både interna och publika mallar för den strax efter att bristen blev offentlig i mars 2025, vilket gav team som redan körde Nuclei en snabb väg till att se om de var exponerade innan patchning hunnit rullas ut överallt.

Så är en Nuclei-mall uppbyggd

Innan vi installerar något är det värt att förstå vad en mall faktiskt innehåller, eftersom hela poängen med Nuclei är att mallarna är läsbara och redigerbara utan att du behöver skriva ett eget skanningsverktyg från grunden. En mall är en YAML-fil med metadata, ett matchningsvillkor och en eller flera förfrågningar som ska skickas till målet.

id: exempel-exponerad-admin-panel

info:
  name: Exponerad administrationspanel
  author: sakerhetsteam
  severity: medium
  tags: exposed-panel,misconfig

http:
  - method: GET
    path:
      - "{{BaseURL}}/admin/login"
    matchers:
      - type: word
        words:
          - "Logga in som administratör"
        condition: and

Fältet info styr metadata som allvarlighetsgrad och taggar, vilket är exakt det som flaggorna -tags och -severity filtrerar på senare i den här guiden. Blocket http beskriver själva testet: vilken sökväg som ska anropas och vilket textmönster i svaret som räknas som en träff. Mallar för specifika CVE:er följer samma struktur, men pekar oftast mot en känd sårbar parameter, ett specifikt svarsmönster eller en versionssträng som avslöjar en oparchad komponent.

Det är den här enkelheten som förklarar hur mallbiblioteket har kunnat växa till nästan 12 000 filer på så kort tid. En säkerhetsforskare som hittar ett nytt sätt att identifiera en sårbarhet behöver inte lära sig ett helt skanningsramverk, det räcker att beskriva begäran och svaret i YAML och skicka in ett pull request till projektet.

Utöver textmatchning (word) stödjer mallformatet även matchare baserade på statuskod, svarstid och reguljära uttryck, vilket gör det möjligt att skriva precisa tester för allt från en enkel exponerad inloggningssida till en tidsbaserad sårbarhet som bara syns genom att svaret tar påtagligt längre tid än normalt. Den flexibiliteten är en stor del av varför Nuclei fungerar lika bra för enkla konfigurationskontroller som för mer tekniskt krävande CVE-detektioner.

ProjectDiscovery och communityn bakom verktyget

Nuclei utvecklas av ProjectDiscovery, som också står bakom flera andra kända säkerhetsverktyg för rekognosering och sårbarhetsjakt. Modellen är öppen källkod för både skannern och mallbiblioteket, vilket skiljer sig från kommersiella sårbarhetshanteringsplattformar där testlogiken oftast är stängd och bara leverantören kan uppdatera den. I praktiken betyder det att vem som helst, inklusive ert eget säkerhetsteam, kan läsa exakt vad en mall testar innan den körs mot en produktionsmiljö.

Den öppna modellen har en baksida värd att nämna: kvaliteten på mallarna varierar eftersom de kommer från ett brett community snarare än ett enskilt kvalitetssäkrat team. De mallar som är kopplade till ett specifikt, namngivet CVE-nummer brukar hålla hög precision eftersom de testar mot en känd, dokumenterad brist. Bredare mallar för generella felkonfigurationer kan däremot ge fler falska positiva, vilket är ytterligare ett skäl att alltid verifiera kritiska fynd manuellt innan de eskaleras internt.

Förutsättningar och versioner

Innan du börjar, se till att du har följande på plats. Guiden är skriven mot de versioner som gällde i oktober 2026, men kommandona nedan fungerar likartat på senare utgåvor eftersom Nuclei har en stabil flagguppsättning.

Nuclei v3.11.1 (släppt 8 augusti 2026) eller senare.
nuclei-templates v10.5.0 (släppt 5 oktober 2026) eller senare, uppdateras separat från själva skannern.
En Linux-, macOS- eller WSL2-miljö med terminalåtkomst. Nuclei kan även köras i Docker.
Go-toolchain om du vill bygga från källkod, alternativt Homebrew (macOS/Linux) eller Docker om du vill slippa kompilera själv.
Utgående nätverksåtkomst till de mål du ska testa, och skriftligt godkännande att skanna dem.
Grundläggande kommandoradsvana samt (för de senare stegen) jq installerat för att läsa JSON-utdata.

Den sista punkten är inte en formalitet. Att köra aktiva sårbarhetstester mot system du inte äger eller saknar tillstånd för kan falla under dataintrångsbestämmelserna i brottsbalken i Sverige och motsvarande lagstiftning i övriga Norden. Håll dig till din egen infrastruktur, en avgränsad testmiljö eller mål där du har ett undertecknat pentest-avtal.

Tänk också igenom var skanningen ska köras ifrån. En skanning från en bärbar dator på ett kontorsnätverk kan se annorlunda ut än en skanning från en molnserver, eftersom målet kan ha olika brandväggsregler beroende på varifrån trafiken kommer. För kontinuerlig drift är det vanligt att lägga Nuclei i en dedikerad säkerhetsmiljö, till exempel en liten VM eller container som bara har de rättigheter som krävs för att nå de godkända målen, och inget annat.

Steg 1: Installera Nuclei

Det finns tre praktiska vägar in: Go, Homebrew eller Docker. Välj den som matchar hur ditt team redan hanterar verktyg.

# Installation via Go
go install -v github.com/projectdiscovery/nuclei/v3/cmd/[email protected]

# Installation via Homebrew (macOS/Linux)
brew install nuclei

# Köra direkt via Docker utan lokal installation
docker run --rm projectdiscovery/nuclei:latest -version

Go-varianten lägger binären i $GOPATH/bin, så se till att den mappen finns i din PATH-variabel. Docker-varianten är smidigast om du redan orkestrerar skanningar i containrar eller i en CI-pipeline och inte vill underhålla en lokal Go-installation.

Steg 2: Verifiera installationen

Kontrollera alltid att du faktiskt har den version du tror innan du börjar skanna, särskilt i ett team där flera personer kör samma pipeline.

nuclei -version

Förväntad utdata för den här guiden:

Nuclei Engine Version: v3.11.1

Om kommandot inte hittas, eller om versionen avviker kraftigt från den du installerade, hoppa till felsökningsavsnittet längre ner innan du fortsätter. Att jaga sårbarheter med en skanner som inte startar korrekt är bortkastad tid.

Steg 3: Hämta och uppdatera nuclei-templates

Mallarna är separerade från skannern och uppdateras på sin egen takt. I 2026 har releasetakten varit stadig: v10.4.2 kom 15 april, v10.4.3 den 5 maj, v10.4.6 den 16 juli och v10.5.0 den 5 oktober. Mellan april och maj lades 226 nya mallar till som täckte 123 CVE:er, varav ett tiotal redan var under aktiv exploatering. Oktoberutgåvan v10.5.0 la till ytterligare 123 mallar för 85 CVE:er, med 15 förstagångsbidrag från nya community-medlemmar.

# Hämta senaste mallpaketet
nuclei -update-templates

# Kontrollera vilken mallversion som är installerad
nuclei -templates-version

Förväntad utdata:

Current nuclei-templates version: v10.5.0

Kör detta kommando regelbundet, till exempel en gång per dag i en cron-tjärning. En skanner som rapporterar att allt är rent bara därför att mallbiblioteket är fyra månader gammalt är farligare än ingen skanning alls, eftersom det skapar falsk trygghet.

Steg 4: Kör din första skanning

Med skanner och mallar på plats är det tid för det enklaste möjliga testet: ett enda mål.

nuclei -u https://test.example.se

Nuclei kör då en bred uppsättning mallar mot målet, från teknikidentifiering till kontroller av exponerade administrationspaneler och kända CVE:er, och skriver resultaten direkt i terminalen. Byt alltid ut exempeladressen mot ett mål du äger eller har tillstånd att testa innan du kör kommandot på riktigt.

Exempel på utdata

[tech-detect] [http] [info] test.example.se [nginx]
[ssl-issuer] [ssl] [info] test.example.se [Let's Encrypt]
[exposed-panel:grafana] [http] [medium] https://test.example.se/login
[CVE-2025-1974] [http] [critical] https://test.example.se [ingress-nginx]

Formatet är: mallnamn, protokoll, allvarlighetsgrad och sedan den exakta URL eller det exakta värdet som matchade. Det gör det enkelt att sortera listan efter allvarlighetsgrad direkt i terminalen eller i ett skript.

Steg 5: Skanna flera mål från en lista

I verkligheten har de flesta organisationer fler än ett system att hålla koll på. Lägg alla godkända mål i en textfil, ett per rad.

# targets.txt
https://app.example.se
https://api.example.se
https://admin.example.se

# Kör skanningen mot hela listan
nuclei -l targets.txt

Håll den här filen under versionskontroll och koppla den till din tillgångsinventering (asset inventory). Om ett system tas bort från listan ska det också tas bort från skanningsschemat, annars riskerar teamet att samla på sig gamla mål som ingen längre äger eller ansvarar för.

Steg 6: Spara resultat i JSON Lines för vidare bearbetning

Terminalutskrift är bra för en snabb titt, men om resultaten ska in i ett SOC-verktyg, ett CMDB eller ett ärendesystem behöver du maskinläsbart format.

nuclei -l targets.txt -jsonl -o nuclei-results.jsonl

Varje rad i filen blir ett eget JSON-objekt med fält för mallnamn, allvarlighetsgrad, matchad URL, tidsstämpel och ofta en kort beskrivning. Det går att läsa filen rad för rad med jq och bygga egna varningar, till exempel ett filter som bara reagerar på allvarlighetsgraden critical och skickar den vidare till en webhook.

Steg 7: Filtrera på CVE-taggar och allvarlighetsgrad

Att köra alla nästan 12 000 mallar mot varje mål varje dag är sällan rätt prioritering. De flesta team vill istället snäva in till det som faktiskt spelar roll just nu: kända CVE:er med hög allvarlighetsgrad.

# Kör bara mallar taggade som CVE
nuclei -l targets.txt -tags cve

# Begränsa till kritisk och hög allvarlighetsgrad
nuclei -l targets.txt -severity critical,high

# Kombinera: CVE-mallar med hög allvarlighetsgrad
nuclei -l targets.txt -tags cve -severity critical,high -jsonl -o cve-findings.jsonl

Den sista kombinationen är ofta den som körs dagligen i produktion, medan en bredare skanning med alla mallar kan sparas till en veckovis eller månadsvis genomgång. Det ger ett rimligt mellanläge mellan snabb upptäckt av det som brinner mest och djupare kartläggning över tid.

Steg 8: Hitta och köra en specifik CVE-mall

Ibland vet du redan exakt vilken sårbarhet du letar efter, till exempel efter en ny säkerhetsbulletin. Då kan du söka upp och köra en enskild mall istället för hela biblioteket.

# Sök efter en specifik CVE i det lokala mallbiblioteket
find ~/.config/nuclei-templates -type f | grep CVE-2025-1974

# Kör precis den mallen mot ett mål
nuclei -u https://test.example.se \
  -t ~/.config/nuclei-templates/http/cves/2025/CVE-2025-1974.yaml

Det här är exakt den typen av riktade test som gjorde IngressNightmare-fallet så användbart som exempel: när ProjectDiscovery publicerade mallen för CVE-2025-1974 kunde team som redan hade Nuclei installerat gå från “vi hörde om en ny sårbarhet” till “vi vet om vi är exponerade” på minuter, istället för att vänta på nästa schemalagda genomlysning.

Steg 9: Matcha fynd mot CISA:s KEV-katalog

Nuclei är inte tänkt att ersätta CISA:s katalog över kända, aktivt utnyttjade sårbarheter (Known Exploited Vulnerabilities, KEV). Det är istället ett verktyg för att snabbt se om just era system matchar något som redan finns listat där. Enligt en sammanställning från februari 2026 täcker omkring 1 496 mallar i nuclei-templates sårbarheter som finns med i KEV-katalogen, men det finns ingen garanti att varje enskild KEV-post har en motsvarande mall, så täckningen ska ses som ett komplement, inte en fullständig spegling.

Ett fungerande arbetsflöde för ett nordiskt säkerhetsteam ser ut ungefär så här:

Importera den aktuella CISA KEV-katalogen till ert sårbarhetshanteringssystem.
Matcha CVE-identifierarna i KEV mot vilka mallar som finns i nuclei-templates.
Kör endast godkända mallar mot externt exponerade, auktoriserade tillgångar.
Exportera JSONL-resultaten till SOC-verktyget, CMDB:n eller ärendesystemet.
Prioritera fynd där CVE:n både finns i er tillgångsinventering och är listad i KEV.

Den femte punkten är den viktigaste. En sårbarhet som är känd, aktivt utnyttjad och faktiskt finns i din miljö ska alltid gå före en teoretisk brist som bara syns i en skanningsrapport.

Steg 10: Håll hastigheten under kontroll

En skanning som skickar tusentals förfrågningar i sekunden kan belasta målservern, trigga webbapplikationsbrandväggar eller i värsta fall orsaka en oavsiktlig tjänstestörning. Nuclei har inbyggda kontroller för det.

# Begränsa till 50 förfrågningar per sekund
nuclei -l targets.txt -rate-limit 50

# Styr hur många mål som bearbetas parallellt
nuclei -l targets.txt -bulk-size 10

# Styr hur många mallar som körs parallellt per mål
nuclei -l targets.txt -concurrency 15

# Kör tyst, bara skriv ut faktiska träffar
nuclei -l targets.txt -silent

I en nordisk produktionsmiljö är det nästan alltid bättre att skanna långsammare och säkrare än snabbt och destruktivt. Kombinera hastighetsbegränsning med en tydlig tillgångsinventering så att ni aldrig av misstag skannar ett system som ligger utanför scopet, till exempel en tredjepartsleverantörs infrastruktur bakom samma domän.

Steg 11: Bygg ett komplett skanningsprojekt

Nu sätter vi ihop allt till ett skript som en säkerhetsfunktion faktiskt kan schemalägga. Flödet är: läs in godkända mål, kör en CVE/KEV-fokuserad skanning med rimlig hastighetsbegränsning, räkna kritiska och höga fynd med jq, och avsluta med en tydlig statusrad som går att koppla till larm.

#!/usr/bin/env bash
# daglig-sarbarhetsskanning.sh
set -euo pipefail

TARGETS="targets.txt"
DATUM=$(date +%Y-%m-%d)
UTDATA="nuclei-resultat-${DATUM}.jsonl"

echo "Uppdaterar mallbibliotek..."
nuclei -update-templates

echo "Kör CVE- och KEV-fokuserad skanning mot $(wc -l < "$TARGETS") mål..."
nuclei -l "$TARGETS" \
  -tags cve \
  -severity critical,high \
  -rate-limit 50 \
  -bulk-size 10 \
  -concurrency 15 \
  -jsonl -o "$UTDATA" \
  -silent

ANTAL_KRITISKA=$(grep -c '"severity":"critical"' "$UTDATA" || true)
ANTAL_HOGA=$(grep -c '"severity":"high"' "$UTDATA" || true)

echo "Klart. Kritiska fynd: ${ANTAL_KRITISKA}, Höga fynd: ${ANTAL_HOGA}"

if [ "$ANTAL_KRITISKA" -gt 0 ]; then
  echo "VARNING: kritiska fynd upptäckta, se $UTDATA"
  exit 2
fi

Skriptet avslutar med felkod 2 om något kritiskt hittas, vilket gör det enkelt att koppla till ett larmsystem eller en CI-pipeline som misslyckar bygget när en kritisk sårbarhet dyker upp. Spara resultatfilerna med datumstämpel så att ni kan jämföra trender över tid, till exempel om antalet höga fynd minskar efter en patchrunda.

Skriptet går att bygga ut ytterligare genom att lägga till ett steg som skickar en kort sammanfattning till en Slack- eller Teams-webhook när ANTAL_KRITISKA är större än noll, så att hela säkerhetsteamet ser larmet direkt i sin vanliga kommunikationskanal istället för att behöva logga in och läsa en loggfil manuellt. Många väljer också att låta skriptet bifoga de tre eller fem allvarligaste fynden i själva meddelandet, så att mottagaren kan börja agera innan de hunnit öppna hela JSONL-filen.

Steg 12: Automatisera med cron eller CI/CD

Ett manuellt körs-när-jag-kommer-ihåg-skript blir aldrig en del av den dagliga driften. Lägg in det i cron eller i er CI/CD-pipeline istället.

# Kör skanningen varje natt klockan 02:30
30 2 * * * /opt/sakerhet/daglig-sarbarhetsskanning.sh >> /var/log/nuclei-cron.log 2>&1

I en GitHub Actions-pipeline fungerar samma princip, men själva schemaläggningen och artefakthanteringen sköts av CI-plattformen istället för av en server ni underhåller själva.

name: Daglig sarbarhetsskanning

on:
  schedule:
    - cron: "30 2 * * *"
  workflow_dispatch: {}

jobs:
  nuclei-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Installera Nuclei
        run: go install -v github.com/projectdiscovery/nuclei/v3/cmd/[email protected]

      - name: Kör skanning
        run: |
          nuclei -update-templates
          nuclei -l targets.txt -tags cve -severity critical,high \
            -rate-limit 50 -jsonl -o resultat.jsonl -silent

      - name: Arkivera resultat
        uses: actions/upload-artifact@v4
        with:
          name: nuclei-resultat
          path: resultat.jsonl

Arkivera JSONL-filen som en artefakt och låt pipeline-status reflektera om kritiska fynd upptäcktes, till exempel genom att skriptet avslutar med en felkod när allvarlighetsgraden critical förekommer. Det ger säkerhetsteamet en historik att slå upp utan att behöva logga in på en enskild server, och gör det möjligt att koppla skanningsresultat direkt till befintliga larmkanaler i Slack eller Teams via CI-plattformens egna integrationer.

Skanna API:er med autentisering och anpassade headers

Många av de mest känsliga systemen i en organisation är inte offentliga webbsidor utan interna eller partnerexponerade API:er som kräver autentisering. Nuclei hanterar det genom att låta er skicka med egna HTTP-headers, till exempel en bärartoken, på samma sätt som ni skulle göra med curl.

# Skanna ett API med en bärartoken i Authorization-headern
nuclei -u https://api.example.se/v1 \
  -H "Authorization: Bearer DIN-TESTTOKEN" \
  -tags cve,exposed-panel \
  -severity critical,high

# Flera headers kan läggas till genom att upprepa flaggan
nuclei -u https://api.example.se/v1 \
  -H "Authorization: Bearer DIN-TESTTOKEN" \
  -H "X-Nordic-Tenant: test" \
  -jsonl -o api-resultat.jsonl

Använd alltid en separat testtoken med lägsta möjliga behörighet för den här typen av skanning, aldrig en produktionsanvändares faktiska inloggningsuppgifter. Ett API som kräver autentisering för att överhuvudtaget svara är annars svårt att testa meningsfullt, eftersom de flesta mallar aldrig ens kommer förbi inloggningskontrollen och ni riskerar att tro att systemet är säkrare än det faktiskt är.

API:er är ofta känsligare för hög förfrågningsvolym än vanliga webbsidor, särskilt om de har strikta kvoter per nyckel eller backend-tjänster som inte är byggda för att hantera skanningstrafik. Sänk -rate-limit ytterligare jämfört med en vanlig webbskanning, och stäm av med API-ägaren i förväg om det finns en separat testmiljö som kan användas istället för produktions-API:et.

Skriv en egen mall för interna system

Publika CVE-mallar täcker bara sårbarheter som redan är kända och publicerade. Interna system, egenutvecklade API:er och specialbyggda admin-gränssnitt får aldrig ett eget CVE-nummer, men de kan fortfarande ha allvarliga brister som ett team vill kontrollera varje dag. Lösningen är att skriva en egen mall och lägga den i en separat, intern mallmapp.

# Lägg egna mallar i en separat mapp
mkdir -p ~/nuclei-interna-mallar

# Kör både det publika biblioteket och den interna mappen
nuclei -l targets.txt \
  -t ~/.config/nuclei-templates/ \
  -t ~/nuclei-interna-mallar/ \
  -severity critical,high \
  -jsonl -o alla-resultat.jsonl

Genom att hålla interna mallar separerade från det publika community-biblioteket blir det enkelt att uppdatera det publika biblioteket med -update-templates utan att råka skriva över eller blanda ihop det med egna, verksamhetsspecifika kontroller. Namnge gärna de interna mallarna efter system eller team, till exempel interna-system/lonesystem-admin-check.yaml, så att det alltid är tydligt vem som äger testet och vem som ska kontaktas om det börjar ge falska positiva.

Kom ihåg regeln från och med Nuclei v3.11.0: om en egen mall använder javascript:-protokollet för mer avancerad logik måste den signeras digitalt innan den körs. Det är en medveten säkerhetsspärr från ProjectDiscovery för att förhindra att skadlig kod smygs in via en mall som ser ut som en vanlig sårbarhetskontroll.

Prioritera fynd med CVSS, EPSS och KEV tillsammans

En lista med hundra "kritiska" fynd är inte användbar om alla hundra ser lika akuta ut. De flesta mogna säkerhetsfunktioner kombinerar tre separata signaler för att avgöra vad som ska åtgärdas först: CVSS-poängen som beskriver hur allvarlig sårbarheten är tekniskt, EPSS-sannolikheten som uppskattar hur troligt det är att den utnyttjas inom en snar framtid, och närvaro i CISA:s KEV-katalog som bekräftar att utnyttjande redan sker aktivt i verkligheten.

Nucleis JSONL-utdata ger er allvarlighetsgrad och mallnamn, vilket räcker för att slå upp CVE-numret mot externa källor för CVSS och EPSS. Ett enkelt sätt att strukturera prioriteringen är att alltid flytta ett fynd till toppen av kön om det uppfyller alla tre villkoren: hög CVSS-poäng, hög EPSS-sannolikhet och bekräftad KEV-status. Fynd som bara uppfyller ett av villkoren kan vänta till nästa patchfönster, medan fynd som uppfyller alla tre bör hanteras samma dag de upptäcks, oavsett hur full veckoplaneringen redan är.

Den här typen av trevägsprioritering löser också ett vanligt internt problem: att utvecklingsteam och säkerhetsteam är oense om vad som egentligen är akut. Genom att alltid kunna visa vilka tre kriterier som låg bakom en eskalering, snarare än att bara säga "skannern sa kritiskt", blir diskussionen om vad som ska fixas först betydligt kortare och mindre känslostyrd.

Nuclei jämfört med Nmap och OpenVAS/Greenbone

Nuclei konkurrerar inte riktigt med Nmap eller OpenVAS, det kompletterar dem. Nmap svarar på frågan "vad finns där ute", OpenVAS/Greenbone svarar på "vilka kända sårbarheter har vi generellt", och Nuclei svarar på "matchar något av det här mot en specifik, ofta aktivt utnyttjad, sårbarhet just nu".

Egenskap	Nuclei	Nmap	OpenVAS/Greenbone
Primär modell	Mallbaserad detektion av sårbarheter och exponering	Nätverksupptäckt, portskanning, tjänsteidentifiering	Bred sårbarhetshantering
Detektionslogik	Community-underhållna YAML-mallar	NSE-skript och tjänsteprober	Leverantörsunderhållna tester och flöden
Bäst lämpad för	Snabba web-, API-, moln- och CVE-kontroller	Tillgångsupptäckt och nätverksinventering	Autentiserad och oautentiserad sårbarhetsbedömning
CVE-arbetsflöde	Starkt när en aktuell mall finns, hundratals CVE:er per 2026-utgåva	Möjligt via egna NSE-skript, men inte huvudmodellen	Byggt för bredare sårbarhetstäckning och rapportering
KEV-arbetsflöde	Cirka 1 496 mallar med KEV-täckning enligt februari 2026-data	Kräver i regel egna skript	Stöder prioritering via egen sårbarhetsdatabas
Anpassning	YAML-DSL och community pull requests	NSE/Lua-skript	Scannerkonfiguration och flöden
Hastighet/automation	Optimerat för högvolyms, repeterbara kontroller	Mycket bra för upptäckt och inventering	Mer tungrott, passar central sårbarhetshantering

En rimlig skanningskedja för de flesta nordiska organisationer blir därför: tillgångsinventering, följt av Nmap för upptäckt, därefter Nuclei för CVE- och KEV-fokuserade kontroller, och slutligen OpenVAS eller Greenbone för en bredare, autentiserad genomlysning och rapportering innan resultaten går vidare till åtgärd och omtest. Ingen av de tre ersätter de andra två. Nmap utan Nuclei ger er en karta utan att veta vilka hus på kartan som har olåsta dörrar, och Nuclei utan ett föregående Nmap-steg riskerar att missa tillgångar som aldrig hamnade i målfilen från första början.

Snabbreferens: de viktigaste CLI-flaggorna

Som en samlad referens till alla flaggor som använts i stegen ovan, användbar att ha öppen i en flik medan ni bygger ert eget skanningsskript.

Flagga	Funktion	Exempel
`-u`	Skanna ett enskilt mål	`nuclei -u https://exempel.se`
`-l`	Läs mål från en fil	`nuclei -l targets.txt`
`-t`	Kör en specifik mall eller mapp	`nuclei -t cves/2025/CVE-2025-1974.yaml`
`-tags`	Filtrera mallar på tagg	`nuclei -tags cve`
`-severity`	Filtrera på allvarlighetsgrad	`nuclei -severity critical,high`
`-jsonl -o`	Spara resultat i JSON Lines-format	`nuclei -jsonl -o resultat.jsonl`
`-rate-limit`	Begränsa förfrågningar per sekund	`nuclei -rate-limit 50`
`-bulk-size`	Styr antal parallella mål	`nuclei -bulk-size 10`
`-concurrency`	Styr antal parallella mallar per mål	`nuclei -concurrency 15`
`-H`	Lägg till en anpassad HTTP-header	`nuclei -H "Authorization: Bearer TOKEN"`
`-update-templates`	Hämta senaste mallpaketet	`nuclei -update-templates`
`-silent`	Visa bara faktiska träffar	`nuclei -l targets.txt -silent`

Vanliga fallgropar

Skanna utan skriftligt tillstånd. Även en "bara en snabb titt"-skanning mot ett system ni inte äger kan vara olagligt. Ha alltid ett dokumenterat godkännande innan ni kör mot produktionssystem eller tredjepartsdomäner.
Glömma att uppdatera mallarna. Skannern och mallpaketet är separata komponenter. En fyra månader gammal mallversion missar nya KEV-tillägg helt, trots att binären rapporterar att allt gick bra.
Tro att mallarnas täckning är fullständig. Mallbiblioteket matchar inte varje post i CISA:s KEV-katalog. Behandla det som ett komplement till autentiserad skanning, inte en ersättning.
Köra utan hastighetsbegränsning. En aggressiv skanning utan -rate-limit kan belasta eller störa produktionstjänster, särskilt mot äldre infrastruktur som inte är byggd för hög förfrågningsvolym.
Blind tillit till varje fynd. Mallar kan ge falska positiva, särskilt vid otydliga svarsmönster. Verifiera manuellt innan ett "kritiskt" fynd skickas vidare som ett incidentlarm.
Köra osignerade JavaScript-mallar okontrollerat. Sedan Nuclei v3.11.0 måste egna mallar som använder javascript:-protokollet signeras digitalt innan de körs, en säkerhetsspärr som finns där av en anledning.
Blanda ihop skanningsmål mellan miljöer. Om samma målfil används för både test- och produktionsmiljö utan tydlig märkning riskerar ni att en destruktiv kontroll av misstag körs mot en live-tjänst istället för en sandlåda.
Lämna resultatfiler oskyddade. En JSONL-fil full av kritiska sårbarheter är i sig en känslig tillgång. Lagra den med samma åtkomstkontroll som ni skulle använda för annan säkerhetskänslig dokumentation, inte i en delad mapp som alla i organisationen kan läsa.

Felsökning: 10 vanliga problem och lösningar

"command not found: nuclei": Binären hittas inte i PATH. Kontrollera att $GOPATH/bin (vid Go-installation) eller Homebrews binärmapp finns med i din skal-konfiguration, och öppna en ny terminal efter installationen.
Skanningen hänger utan att avsluta: Oftast beror det på ett mål som svarar extremt långsamt eller inte svarar alls. Sänk -bulk-size och -concurrency, eller lägg till en explicit timeout-flagga för att undvika att enskilda mål blockerar hela körningen.
"no templates provided for scan": Mallbiblioteket är inte nedladdat eller sökvägen är fel. Kör nuclei -update-templates igen och kontrollera att mappen ~/.config/nuclei-templates faktiskt innehåller filer.
Versionsmissmatch mellan skanner och mallar: Vissa nyare mallar använder funktioner som bara finns i senare skannerversioner. Uppgradera både nuclei och nuclei-templates samtidigt istället för att bara köra -update-templates.
Många falska positiva på ett specifikt mål: Kontrollera om målet har en webbapplikationsbrandvägg som returnerar generiska 200-svar för allt, vilket lurar mallar som letar efter specifika strängar i svaret. Testa med -severity critical först för att minska bruset.
Docker-containern kan inte nå målet: Kontrollera nätverksläge (--network host kan behövas i vissa miljöer) och att eventuell DNS-upplösning fungerar inuti containern.
JSONL-filen går inte att läsa med jq: Kontrollera att skanningen verkligen avslutades (ingen avbruten körning mitt i en skrivning), och att filen inte blandar vanlig terminalutskrift med JSONL om -silent glömts bort.
Skanningen blockeras helt av målets skydd: Om ett mål aktivt blockerar skannerns IP-adress efter några sekunder, sänk -rate-limit drastiskt och kör om, eller kontakta målets administratör i förväg så att skanningen kan vitlistas under testfönstret.
Byggfel vid installation via Go: Kontrollera att du har en tillräckligt ny Go-version installerad och att modul-cachen inte är korrupt. Rensa cachen med go clean -modcache och försök installera om.
Resultaten skiljer sig mellan två kollegors körningar mot samma mål: Jämför både nuclei -version och nuclei -templates-version på båda maskinerna. Olika mallversioner ger olika täckning även om skannerversionen är identisk.

Avancerade tips för produktionsmiljöer

När grunderna sitter är nästa steg att göra skanningen till en pålitlig del av säkerhetsarbetet snarare än ett engångsexperiment. Några saker som gör störst skillnad i praktiken:

Skriv egna mallar för interna system. YAML-formatet är öppet, och interna applikationer som aldrig får en publik CVE kan fortfarande få en skräddarsydd mall för kända konfigurationsbrister, byggd av era egna säkerhetstekniker snarare än väntad på en extern leverantör.
Signera JavaScript-baserade mallar korrekt. Eftersom v3.11.0 kräver digital signering för javascript:-mallar bör ni bygga signeringssteget in i er mallpublicering från start, inte som en eftertanke när en körning plötsligt vägrar och ingen i teamet minns varför.
Separera "daglig CVE/KEV-koll" från "fullständig genomlysning". Kör den snäva, hastighetsbegränsade varianten varje dag och en bredare körning med alla relevanta mallar en gång per vecka eller månad, så att den dagliga driften inte blir för tung för att faktiskt köras varje dag.
Arkivera JSONL-historik. Att kunna visa att antalet kritiska fynd gick från tio till noll efter en patchrunda är ovärderligt i en NIS2-revision eller ett ledningsmöte, och det kräver bara att ni behåller filerna istället för att skriva över dem varje dag.
Koppla fynd till tillgångsägare, inte bara till domännamn. Ett fynd på api.example.se är bara användbart om det finns en tydlig mottagare som kan agera på det inom en rimlig tidsram. Utan en ägare blir även ett kritiskt fynd en post i en lista som ingen känner ansvar för.

Mät framsteg genom att jämföra skanningar över tid

En enskild skanning säger bara hur läget ser ut just nu. Värdet växer när ni börjar jämföra resultat från vecka till vecka och kan visa att antalet kritiska fynd faktiskt minskar efter en patchrunda, eller att ett specifikt system återkommande dyker upp i rapporterna trots upprepade åtgärdsförsök. Eftersom varje körning redan sparas som en datumstämplad JSONL-fil i exemplet tidigare i guiden, är nästa steg bara att räkna och jämföra.

# Räkna kritiska och höga fynd per datumstämplad fil
for fil in nuclei-resultat-*.jsonl; do
  kritiska=$(jq -c 'select(.info.severity=="critical")' "$fil" | wc -l)
  hoga=$(jq -c 'select(.info.severity=="high")' "$fil" | wc -l)
  echo "$fil: kritiska=$kritiska höga=$hoga"
done

# Lista vilka mål som förekommer i flest körningar med kritiska fynd
jq -r 'select(.info.severity=="critical") | .host' nuclei-resultat-*.jsonl | sort | uniq -c | sort -rn

Det andra kommandot är särskilt användbart i en NIS2-kontext, eftersom det snabbt pekar ut vilka system som gång på gång dyker upp i de allvarligaste fynden. Ett system som ligger kvar på listan vecka efter vecka är oftast ett tecken på att åtgärden fastnat i en kö någonstans, inte att sårbarheten faktiskt är svår att fixa. Den typen av återkommande mönster är exakt det som en ledningsgrupp eller revisor brukar fråga efter när de vill se att sårbarhetshanteringen fungerar i praktiken och inte bara producerar rapporter som ingen följer upp.

Det är också värt att spara den här historiken utanför den enskilda skanningsservern. En enkel lösning är att skicka varje datumstämplad JSONL-fil till ett centralt loggsystem eller en objektlagringshink, så att historiken överlever även om servern som kör själva skanningen någon gång måste bytas ut eller byggas om från grunden.

Vanliga frågor om Nuclei

Är det lagligt att köra Nuclei mot vilken webbplats som helst?

Nej. Aktiv sårbarhetsskanning utan tillstånd kan räknas som dataintrång enligt svensk och nordisk lagstiftning. Kör bara mot system ni äger, en kontrollerad testmiljö eller mål där ni har ett skriftligt avtal som täcker säkerhetstestning.

Kostar Nuclei något att använda?

Skannern och mallbiblioteket nuclei-templates är fritt tillgängliga som öppen källkod från ProjectDiscovery. Kostnaden ligger i stället i driftstid: att hålla mallar uppdaterade, bygga pipelines, verifiera fynd manuellt och analysera resultat över tid. För de flesta organisationer är det personaltiden, inte licenskostnaden, som avgör hur mycket värde man får ut av verktyget.

Hur ofta uppdateras nuclei-templates?

Under 2026 har releaser kommit med några veckors till ett par månaders mellanrum, med exempel som v10.4.2 (15 april), v10.4.3 (5 maj), v10.4.6 (16 juli) och v10.5.0 (5 oktober). Kör -update-templates dagligen för att inte missa nya tillägg.

Ersätter Nuclei ett verktyg som Nmap eller OpenVAS?

Nej, de kompletterar varandra. Nmap hittar och identifierar tjänster, Nuclei kontrollerar specifika kända sårbarheter och felkonfigurationer, och OpenVAS/Greenbone ger en bredare, mer formell sårbarhetsbedömning. De flesta team kör alla tre i en kedja.

Täcker Nuclei-mallarna hela CISA KEV-katalogen?

Inte helt. En sammanställning från februari 2026 visade cirka 1 496 mallar med KEV-koppling, men det finns ingen garanti att varje enskild KEV-post har en motsvarande mall. Behandla Nuclei som ett snabbt kompletterande kontrollverktyg, inte som den enda källan till sanning om KEV-exponering. Fortsätt därför att importera och läsa den officiella KEV-katalogen direkt, och använd Nuclei-skanningen som ett sätt att snabbt se vilka av de posterna som faktiskt berör er egen miljö.

Kan jag lita helt på resultaten utan manuell verifiering?

Nej. Precis som alla automatiserade skannrar kan Nuclei ge falska positiva, särskilt mot mål med ovanliga svarsmönster eller skyddsmekanismer som brandväggar på applikationsnivå. Kritiska fynd bör alltid verifieras manuellt innan de eskaleras som en bekräftad incident.

Fungerar Nuclei mot API:er och molnkonfigurationer, inte bara webbplatser?

Ja. ProjectDiscovery beskriver Nuclei som ett verktyg som täcker sårbarheter, felkonfigurationer, exponerade tjänster, API:er, nätverk, DNS och molnkonfigurationer, inte bara klassiska webbsårbarheter. Mallbiblioteket har kategorier specifikt för det.

Vad gör jag om en skanning orsakar problem hos målet?

Stoppa skanningen omedelbart, sänk -rate-limit och -concurrency drastiskt för framtida körningar, och informera systemägaren. Dokumentera incidenten som en del av er testprocess så att samma mål kan testas säkrare nästa gång.

Behöver vi ett dedikerat pentest-team för att komma igång?

Nej. Grundflödet i den här guiden, installation, uppdatering av mallar och en CVE/KEV-filtrerad skanning, kan skötas av en vanlig drift- eller säkerhetsingenjör. Ett dedikerat pentest-team blir mer relevant när organisationen vill skriva avancerade egna mallar, verifiera komplexa fynd manuellt eller genomföra fullskaliga penetrationstester utöver den löpande skanningen.

Nuclei: Skanna CVE och CISA KEV i 12 Steg, 75 Min [2026]