Hvis din virksomhed bruger en SonicWall-firewall, eller hvis du outsourcer IT til en managed service provider (MSP), der logger ind eksternt for at holde dine systemer opdaterede og sikkerhedskopierede, har du to separate grunde til at foretage et telefonopkald i denne uge. Begge handler om sårbarheder, som angribere udnytter lige nu, ikke teoretiske risici i en leverandørbulletin, som ingen læser. Ingen af delene kræver, at du bliver sikkerhedsekspert. Det kræver, at du stiller specifikke spørgsmål og forventer specifikke svar — datoer, versionsnumre, bekræftelser — ikke beroligende forsikringer.

Her er, hvad der sker med hver af dem, samt en tjekliste, du kan kopiere, indsætte og sende til den, der administrerer dit netværk.

Problem 1: Din SonicWall-firewall (CVE-2026-15409 og CVE-2026-15410)

SonicWall offentliggjorde og rettede to sårbarheder den 14. juli 2026 — men ifølge virksomhedens egen tidslinje havde angribere allerede udnyttet dem i omkring tre uger før den offentlige offentliggørelse. Det betyder, at »rettet nu« og »sikker nu« ikke automatisk er det samme for en enhed, der var eksponeret mod internettet i det tidsrum.

Den trusselsaktør, der mest konsekvent nævnes i forbindelse med denne sårbarhedskæde, er INC, en ransomware-as-a-service-operation, som forskere hos Rapid7 beskriver som en af de mest aktive grupper af sin slags globalt lige nu (selvom ikke alle angreb, der bruger disse fejl, definitivt er blevet knyttet specifikt til INC — andre opportunistiske angribere er næsten helt sikkert også involveret). Separat rapporterede sikkerhedsvirksomheden Huntress om en hurtigt fremadskridende bølge, hvor 30 SonicWall-kunder blev kompromitteret på under to dage. Dette er ikke en langsomt udviklende risiko.

Der er også relevant historik her: SonicWall offentliggjorde tidligere en hændelse, hvor en statssponsoreret gruppe stjal firewall-konfigurationsfiler fra alle SonicWall-kunder, der brugte virksomhedens cloud-backupfunktion. En stjålet konfigurationsfil kan indeholde legitimationsoplysninger til lokale konti og VPN-indstillinger. Hvis din firewalls konfiguration nogensinde blev sikkerhedskopieret til SonicWalls cloudtjeneste, før hændelsen blev inddæmmet, ophæver en rettelse af de aktuelle fejl ikke det, der allerede var blevet eksponeret — legitimationsoplysninger fra konfigurationen skal muligvis stadig udskiftes.

Tjekliste, der skal sendes til din IT-leverandør eller MSP:

  • »Hvilken SonicWall-model og firmwareversion kører vi med i øjeblikket, og afhjælper den version CVE-2026-15409 og CVE-2026-15410?« (Bed dem bekræfte det ud fra SonicWalls egen vejledning — accepter ikke »vi har den seneste version« uden et versionsnummer.)
  • »Hvilken dato installerede vi rettelsen?« Hvis det var efter den 14. juli 2026, så bed dem kontrollere logfiler, der dækker de foregående uger, for tegn på uautoriseret adgang — uventede administratorlogin, nye lokale konti eller SSLVPN-sessioner fra ukendte IP-adresser.
  • »Var vores SSLVPN- eller fjernadgangsportal eksponeret mod internettet i det tidsrum?« Hvis ja, så bed om en tvungen nulstilling af adgangskoden for alle konti, der godkendes gennem den, ikke kun en rettelse.
  • »Blev vores firewall-konfiguration nogensinde sikkerhedskopieret til SonicWalls cloudtjeneste, og hvis ja, er legitimationsoplysningerne i den konfigurationsfil blevet udskiftet siden?«
  • »Har I aktiveret multifaktorgodkendelse på alle fjernadgangskonti gennem firewallen?« Hvis ikke, så bed dem slå det til i denne uge.

Problem 2: Din MSP's værktøj til fjernadministration (CVE-2026-18577 i N-able N-central)

Dette er anderledes, fordi det ikke er dit udstyr — det er et værktøj, som din IT-leverandør måske bruger til at administrere snesevis eller hundredvis af kunders virksomheder, muligvis også din, fra én central konsol. N-able N-central er en sådan platform, og CISA (den amerikanske cybersikkerheds- og infrastruktursikkerhedsmyndighed) tilføjede en sårbarhed i den — CVE-2026-18577, vurderet til 8,2 ud af 10 i alvorlighed — til sit katalog over kendte udnyttede sårbarheder efter at have bekræftet aktiv udnyttelse siden den 31. juli 2026. Fejlen giver angiveligt en angriber mulighed for at opnå fuld administrativ adgang til selve N-central-konsollen.

Det er vigtigt på grund af, hvad en angriber kan gøre derfra. Huntress rapporterede, at vellykkede angreb bevægede sig fra den kompromitterede konsol videre til de slutpunkter, der blev administreret gennem den — hvilket betyder, at et brud på MSP'ens værktøj kan blive til et brud på dine systemer, uden at en angriber nogensinde målretter dig direkte. Huntress fandt også, at angribere oprettede Cloudflare-tunneler på kompromitterede systemer, en teknik, der giver dem en vedvarende, krypteret vej tilbage, som kan ligne almindelig webtrafik for en firewall.

Du behøver ikke vide, om din specifikke leverandør bruger N-central. Du skal spørge — og spørge bredere end blot om dette ene produktnavn.

Tjekliste, der skal sendes til din IT-leverandør eller MSP:

  • »Bruger I N-able N-central eller et andet N-able-produkt til at administrere vores systemer?« Hvis ja: »Er det rettet mod CVE-2026-18577, og fra hvilken dato?«
  • »Har I gennemgået aktiviteten på administratorkonti og adgangslogfilerne på jeres administrationskonsol siden den 31. juli 2026 for noget, I ikke kan forklare?«
  • »Har I specifikt kontrolleret vores systemer for uventede udgående forbindelser — især Cloudflare-tunnelprocesser (som nogle gange vises som ’cloudflared’) eller tunneldomæner, som I ikke selv har oprettet?«
  • »Er der blevet skubbet nye lokale administratorkonti, planlagte opgaver eller fjernadministrationspolitikker ud til vores systemer, som I ikke kan tilskrive jeres eget team?«
  • »Hvis I ikke bruger N-central, hvilket værktøj til fjernadministration bruger I så i stedet, og er der for nylig blevet tilføjet sårbarheder i det til CISA's katalog over kendte udnyttede sårbarheder?«

Hvad du skal gøre med svarene

En god IT-leverandør vil besvare disse spørgsmål med datoer og detaljer, ofte inden for en dag, fordi de allerede bør kende disse oplysninger eller hurtigt kunne hente dem fra logfilerne. Et vagt svar — »vi har styr på det«, »vores systemer er sikre«, ingen tilbudte datoer — er i sig selv nyttig information: Det fortæller dig, at denne samtale skal tages igen, skriftligt og med en deadline.

Hvis du selv administrerer din SonicWall uden en MSP, gælder ovenstående tjekliste stadig direkte for dig — log selv ind på administrationskonsollen, kontrollér firmwareversionen, og tjek SonicWalls vejledningsside for den version, der afhjælper begge CVE'er.

Ingen af disse mangler kræver, at du river en leverandør ud eller fyrer en tjenesteudbyder. De kræver bekræftelse af, at det specifikke hul er blevet lukket, og at ingen slap igennem det, mens det stod åbent. Stil spørgsmålene, få datoerne, og læg en påmindelse i din kalender om at spørge igen, næste gang en leverandør oplyser, at noget er »aktivt udnyttet«. Det vil ske igen.