Hvis virksomheten din bruker en SonicWall-brannmur, eller hvis du setter ut IT-driften til en leverandør av administrerte tjenester (MSP) som logger inn eksternt for å holde systemene dine oppdatert og sikkerhetskopiert, har du to separate grunner til å ta en telefon denne uken. Begge gjelder sårbarheter som angripere utnytter akkurat nå, ikke teoretiske risikoer i et leverandørvarsel ingen leser. Ingen av dem krever at du blir sikkerhetsekspert. Det krever at du stiller konkrete spørsmål og forventer konkrete svar — datoer, versjonsnumre, bekreftelser — ikke forsikringer.

Her er hva som skjer med hver av dem, samt en sjekkliste du kan kopiere, lime inn og sende til den som administrerer nettverket ditt.

Problem 1: SonicWall-brannmuren din (CVE-2026-15409 og CVE-2026-15410)

SonicWall offentliggjorde og rettet to sårbarheter 14. juli 2026 — men ifølge selskapets egen tidslinje hadde angripere allerede utnyttet dem i omtrent tre uker før offentliggjøringen. Det betyr at «oppdatert nå» og «sikker nå» ikke automatisk er det samme for en enhet som var eksponert mot internett i dette tidsrommet.

Trusselaktøren som oftest nevnes i forbindelse med denne sårbarhetskjeden, er INC, en løsepengevirus-som-tjeneste-operasjon som forskere hos Rapid7 beskriver som en av de mest aktive gruppene av sitt slag globalt akkurat nå (selv om ikke alle angrep som bruker disse sårbarhetene, definitivt er knyttet spesifikt til INC — andre opportunistiske angripere er nesten helt sikkert også involvert). Separat rapporterte sikkerhetsselskapet Huntress om en rask angrepsbølge der 30 SonicWall-kunder ble kompromittert på under to dager. Dette er ikke en risiko som utvikler seg sakte.

Det finnes også relevant historikk her: SonicWall offentliggjorde tidligere en hendelse der en statsstøttet gruppe stjal brannmurkonfigurasjonsfiler fra alle SonicWall-kunder som brukte selskapets funksjon for sikkerhetskopiering i skyen. En stjålet konfigurasjonsfil kan inneholde legitimasjon for lokale kontoer og VPN-innstillinger. Hvis brannmurkonfigurasjonen din noen gang ble sikkerhetskopiert til SonicWalls skytjeneste før hendelsen ble stanset, opphever ikke oppdatering av de aktuelle sårbarhetene det som allerede var eksponert — legitimasjon fra denne konfigurasjonen kan fortsatt måtte roteres.

Sjekkliste du kan sende til IT-leverandøren eller MSP-en din:

  • «Hvilken SonicWall-modell og fastvareversjon kjører vi for øyeblikket, og utbedrer denne versjonen CVE-2026-15409 og CVE-2026-15410?» (Be dem bekrefte dette mot SonicWalls eget varsel — ikke godta «vi har den nyeste versjonen» uten et versjonsnummer.)
  • «Hvilken dato installerte vi oppdateringen?» Hvis det var etter 14. juli 2026, bør du be dem kontrollere logger som dekker de foregående ukene, for tegn på uautorisert tilgang — uventede administratorinnlogginger, nye lokale kontoer eller SSLVPN-økter fra ukjente IP-adresser.
  • «Var SSLVPN- eller fjernaksessportalen vår eksponert mot internett i dette tidsrommet?» Hvis svaret er ja, bør du be om en tvungen tilbakestilling av passordet for hver konto som autentiserer gjennom den, ikke bare en oppdatering.
  • «Ble brannmurkonfigurasjonen vår noen gang sikkerhetskopiert til SonicWalls skytjeneste, og hvis ja, har legitimasjonen i denne konfigurasjonsfilen blitt rotert siden?»
  • «Har dere aktivert flerfaktorautentisering for alle kontoer med fjernaksess gjennom brannmuren?» Hvis ikke, bør du be dem slå det på denne uken.

Problem 2: MSP-ens verktøy for fjernadministrasjon (CVE-2026-18577 i N-able N-central)

Dette er annerledes fordi det ikke er utstyret ditt — det er et verktøy IT-leverandøren din kan bruke til å administrere dusinvis eller hundrevis av kundebedrifter, inkludert muligens din, fra én sentral konsoll. N-able N-central er en slik plattform, og CISA (det amerikanske direktoratet for cybersikkerhet og infrastruktursikkerhet) la en sårbarhet i den — CVE-2026-18577, med alvorlighetsgrad 8,2 av 10 — til i katalogen sin over kjente utnyttede sårbarheter etter å ha bekreftet aktiv utnyttelse siden 31. juli 2026. Sårbarheten skal angivelig gjøre det mulig for en angriper å få full administratortilgang til selve N-central-konsollen.

Det er viktig på grunn av hva en angriper kan gjøre derfra. Huntress rapporterte at vellykkede angrep gikk videre fra den kompromitterte konsollen til endepunktene som ble administrert gjennom den — noe som betyr at et brudd på MSP-ens verktøy kan bli et brudd på systemene dine uten at en angriper noen gang retter seg direkte mot deg. Huntress fant også at angripere opprettet Cloudflare-tunneler på kompromitterte systemer, en teknikk som gir dem en vedvarende, kryptert vei tilbake som kan se ut som vanlig webtrafikk for en brannmur.

Du trenger ikke å vite om den spesifikke leverandøren din bruker N-central. Du må spørre, og spørre bredere enn bare om navnet på dette ene produktet.

Sjekkliste du kan sende til IT-leverandøren eller MSP-en din:

  • «Bruker dere N-able N-central eller et annet N-able-produkt til å administrere systemene våre?» Hvis ja: «Er det oppdatert mot CVE-2026-18577, og fra hvilken dato?»
  • «Har dere gjennomgått aktiviteten til administratorkontoer og tilgangsloggene på administrasjonskonsollen deres siden 31. juli 2026, med tanke på noe dere ikke kan forklare?»
  • «Har dere undersøkt systemene våre spesifikt for uventede utgående forbindelser — særlig Cloudflare-tunnelprosesser (som noen ganger vises som «cloudflared») eller tunneldomener dere ikke har konfigurert?»
  • «Har det blitt sendt nye lokale administratorkontoer, planlagte oppgaver eller fjernadministrasjonspolicyer til systemene våre som dere ikke kan knytte til deres eget team?»
  • «Hvis dere ikke bruker N-central, hvilket verktøy for fjernadministrasjon bruker dere i stedet, og har det nylig fått noen sårbarheter lagt til i CISA-katalogen over kjente utnyttede sårbarheter?»

Hva du skal gjøre med svarene

En god IT-leverandør vil svare på disse spørsmålene med datoer og detaljer, ofte innen én dag, fordi de allerede bør kjenne til denne informasjonen eller raskt kunne hente den ut fra logger. Et vagt svar — «vi har kontroll», «systemene våre er sikre», ingen datoer oppgitt — er i seg selv nyttig informasjon: Det forteller deg at denne samtalen må tas opp igjen, skriftlig, med en fastsatt frist.

Hvis du administrerer din egen SonicWall uten en MSP, gjelder sjekklisten ovenfor fortsatt direkte for deg — logg selv inn på administrasjonskonsollen, kontroller fastvareversjonen og sjekk SonicWalls side med varsler for versjonen som utbedrer begge CVE-ene.

Ingen av disse svakhetene krever at du kvitter deg med en leverandør eller sier opp en tjenesteleverandør. De krever bekreftelse på at det konkrete sikkerhetshullet er lukket, og at ingenting slapp gjennom mens det var åpent. Still spørsmålene, få datoene, og legg inn en påminnelse i kalenderen om å spørre igjen neste gang en leverandør opplyser at noe blir «aktivt utnyttet». Det vil skje igjen.