OpenSSL retter høy alvorlig feil funnet med AI-hjelp

AI finner nå feil i den kryptografiske grunnmuren

OpenSSL publiserte 9. juni en sikkerhetsoppdatering med 18 CVE-er. Den viktigste er CVE-2026-45447, en høy alvorlighetsgrad i PKCS7_verify() som kan utløses av en spesiallaget PKCS#7- eller S/MIME-signert melding. OpenSSL skriver at feilen kan gi krasj, heap-korrupsjon og i enkelte applikasjonsmiljøer mulig fjernkjøring av kode.

Det tekniske poenget er smalt. Det operative poenget er bredt. OpenSSL ligger under enorme deler av virksomheters programvare, integrasjoner, klienter, servere og sikkerhetsprodukter. Når et sårbarhetssett på dette nivået lander, er det ikke en sak for kryptonerdens backlog. Det er patch-styring, leverandørstyring og eksponering mot programvare som kanskje ikke engang er synlig i toppnivå-inventaret.

Saken får en ekstra dimensjon fordi OpenSSL selv krediterer flere funn til sikkerhetsforskere hos Anthropic og ett funn til Thai Duong i samarbeid med Claude og Anthropic Research. SecurityWeek peker på det samme: halvparten av feilene i denne runden er knyttet til rapportører fra Anthropic, og CVE-2026-45447 er en av de sjeldne høy-alvorlige OpenSSL-feilene de siste årene.

Dette er et tidlig, konkret tegn på hvordan AI endrer sårbarhetsøkonomien. Modellene brukes ikke bare til å skrive kode raskere. De brukes også til å finne svakheter i kodebaser som mange selskaper har bygget tillit på i årevis. Det er bra når funnene går gjennom ansvarlig rapportering. Det er mindre behagelig når den samme metodikken gradvis blir billigere og mer tilgjengelig.

Hva OpenSSL faktisk har rettet

CVE-2026-45447 gjelder applikasjoner som behandler PKCS#7 eller S/MIME-signerte meldinger med OpenSSLs PKCS#7-API-er. OpenSSL presiserer at applikasjoner som bruker CMS-API-ene for denne behandlingen ikke er berørt av akkurat denne feilen. FIPS-modulene i 4.0, 3.6, 3.5, 3.4 og 3.0 er heller ikke berørt, fordi den sårbare koden ligger utenfor FIPS-modulgrensen.

Berørte versjoner er likevel brede: OpenSSL 4.0, 3.6, 3.5, 3.4, 3.0, 1.1.1 og 1.0.2. OpenSSL ber brukere oppgradere til 4.0.1, 3.6.3, 3.5.7, 3.4.6, 3.0.21, 1.1.1zh eller 1.0.2zq, avhengig av gren. De to eldste grenene gjelder premium support-kunder.

Resten av adviseringen er heller ikke kosmetikk. Blant de moderate feilene er svakheter i CMS AuthEnvelopedData-behandling som kan gi integritetsbypass eller nøkkel-ekvivalent funksjonalitet i enkelte scenarier. OpenSSL retter også flere QUIC-relaterte tjenestenekt-svakheter, en OCSP-stapling double-free, problemer i sertifikathåndtering og flere lavere alvorlighetsgrader. Til sammen peker listen mot et klassisk problem: kryptobiblioteker er ikke én funksjon, men en stor overflate av gamle formater, nye protokoller, klientlogikk og serverlogikk.

For norske virksomheter er ikke spørsmålet bare om OpenSSL er installert på egne Linux-servere. Spørsmålet er hvilke produkter, containere, appliances, klienter, integrasjoner og tredjepartsleveranser som har bundlet sårbare versjoner. Det er her SBOM, sårbarhetsskanning og krav til leverandørrespons skiller driftbar sikkerhet fra ønsketenkning.

Lederpoenget: patching blir en AI-akselerert disiplin

AI-assistert sårbarhetsfunn gjør patch-vinduet mer strategisk. Når forskere med gode intensjoner kan finne flere feil raskere, kan også offensive miljøer gjøre mer med samme type verktøy. Det betyr ikke at alle feil straks blir masseutnyttet. Det betyr at tiden mellom offentlig advisering, proof-of-concept og opportunistisk scanning fortsetter å krympe.

CISO-er bør derfor behandle denne typen saker som en test på tre ting. Først: finner organisasjonen berørt OpenSSL-bruk raskt, også i tredjepartsprogramvare? Deretter: finnes det en risikobasert prioritering for tjenester som behandler S/MIME, PKCS#7, CMS, QUIC eller sertifikatrelatert trafikk? Til slutt: kan ledelsen få et svar som er bedre enn «vi har bedt drift sjekke»?

CIO-er bør lese dette som enda et datapunkt i overgangen fra manuell sårbarhetsforvaltning til kontinuerlig eksponeringsstyring. AI gjør ikke bare utvikling raskere. Den gjør også revisjon av kode, fuzzing, analyse og utnyttelsesarbeid billigere. Da holder det dårlig å styre patching med månedlige møter og regneark som ikke vet hva som faktisk kjører.

Styret trenger ikke kunne PKCS7_verify(). Men styret bør kunne spørre om virksomheten har oversikt over kryptografiske komponenter, om kritiske leverandører har SLA for sikkerhetsoppdateringer, og om sikkerhetsteamet kan verifisere eksponering i produksjon uten å vente på neste kvartalsrapport.

Hva bør gjøres nå

Virksomheter bør først kartlegge OpenSSL-versjoner i eksternt eksponerte tjenester, e-post- og meldingsrelaterte systemer, sikkerhetsgatewayer, klientprogramvare og containere. Deretter bør oppgraderinger prioriteres mot komponenter som prosesserer signerte meldinger, sertifikater eller TLS/QUIC-trafikk.

Det er også verdt å bruke saken som en øvelse i leverandørdialog. Be kritiske leverandører svare konkret på om de bruker OpenSSL-grenene som er berørt, hvilken oppgraderingsversjon de går til, og når fiksen er ute i deres produkt. Hvis svaret er uklart, er det en leverandørrisiko, ikke bare en teknisk detalj.

Til slutt bør sikkerhetsteam følge med på distribusjonenes egne pakkeråd. OpenSSLs upstream-versjon og operativsystemleverandørens backportede pakkeversjon er ikke alltid samme tall. Det viktige er ikke kosmetisk versjonsnummer. Det viktige er om CVE-ene faktisk er lukket i pakken som er i drift.

Kilder og medier

Primærkilde: OpenSSL Security Advisory, 9. juni 2026: https://openssl-library.org/news/secadv/20260609.txt

Kildekreditering: OpenSSL oppgir CVE-er, berørte versjoner, oppgraderingsmål og kreditering av rapportører, inkludert Anthropic/Claude-relaterte funn. SecurityWeek er brukt som sekundær bransjekilde for kontekst om alvorlighetsgrad og AI-kreditering: https://www.securityweek.com/openssl-patches-high-severity-vulnerability-found-with-ai/

Thumbnail: OpenAI Image 2 / hogby.ai