Om ditt företag driver en SonicWall-brandvägg, eller om ni lägger ut IT-driften på en leverantör av hanterade IT-tjänster (MSP) som loggar in på distans för att hålla era system patchade och säkerhetskopierade, har ni två separata skäl att ringa ett samtal den här veckan. Båda handlar om sårbarheter som angripare utnyttjar just nu, inte teoretiska risker i ett leverantörsmeddelande som ingen läser. Ingetdera kräver att ni blir säkerhetsexperter. Det som krävs är att ni ställer specifika frågor och förväntar er specifika svar — datum, versionsnummer, bekräftelser — inte lugnande ord.

Här är vad som händer med vardera problemet, samt en checklista ni kan kopiera, klistra in och skicka till den som sköter ert nätverk.

Problem 1: Er SonicWall-brandvägg (CVE-2026-15409 och CVE-2026-15410)

SonicWall offentliggjorde och patchade två sårbarheter den 14 juli 2026 — men enligt företagets egen tidslinje hade angripare redan utnyttjat dem i ungefär tre veckor innan de offentliggjordes. Det betyder att "patchat nu" och "säkert nu" inte automatiskt är samma sak för en enhet som stod exponerad mot internet under det fönstret.

Den hotaktör som oftast nämns i samband med denna sårbarhetskedja är INC, en ransomware-as-a-service-verksamhet som forskare på Rapid7 beskriver som en av de mest aktiva grupperna i sitt slag i världen just nu (även om inte alla attacker som utnyttjar dessa brister definitivt har kopplats till just INC — andra opportunistiska angripare är nästan säkert inblandade också). Separat rapporterade säkerhetsföretaget Huntress om en snabb våg av attacker där 30 SonicWall-kunder komprometterades på mindre än två dygn. Detta är ingen risk som bygger sig upp långsamt.

Det finns även relevant historik här: SonicWall har tidigare offentliggjort en incident där en statsstödd grupp stal brandväggskonfigurationsfiler från alla SonicWall-kunder som använde dess molnbaserade säkerhetskopieringsfunktion. En stulen konfigurationsfil kan innehålla lokala kontouppgifter och VPN-inställningar. Om er brandväggs konfiguration någonsin säkerhetskopierades till SonicWalls molntjänst innan den incidenten var under kontroll, upphäver inte en patchning av de nuvarande bristerna det som redan exponerats — uppgifter från den konfigurationen kan fortfarande behöva bytas ut.

Checklista att skicka till er IT-leverantör eller MSP:

  • "Vilken SonicWall-modell och firmwareversion kör vi för närvarande, och åtgärdar den versionen CVE-2026-15409 och CVE-2026-15410?" (Be dem bekräfta mot SonicWalls egen säkerhetsbulletin — acceptera inte "vi kör senaste versionen" utan ett faktiskt versionsnummer.)
  • "Vilket datum applicerade vi patchen?" Om det var efter den 14 juli 2026, be dem gå igenom loggarna för de föregående veckorna efter tecken på obehörig åtkomst — oväntade administratörsinloggningar, nya lokala konton eller SSLVPN-sessioner från okända IP-adresser.
  • "Var vår SSLVPN- eller fjärråtkomstportal exponerad mot internet under det fönstret?" Om ja, begär en tvingad lösenordsåterställning för varje konto som autentiserar genom den, inte bara en patch.
  • "Har vår brandväggskonfiguration någonsin säkerhetskopierats till SonicWalls molntjänst, och om så är fallet, har uppgifterna i den konfigurationsfilen bytts ut sedan dess?"
  • "Har ni aktiverat multifaktorautentisering på alla fjärråtkomstkonton via brandväggen?" Om inte, be dem aktivera det den här veckan.

Problem 2: Er MSP:s verktyg för fjärrhantering (CVE-2026-18577 i N-able N-central)

Det här är annorlunda eftersom det inte är er egen utrustning — det är ett verktyg som er IT-leverantör kan använda för att hantera dussintals eller hundratals kundföretag, eventuellt inklusive ert eget, från en central konsol. N-able N-central är en sådan plattform, och CISA (den amerikanska myndigheten för cybersäkerhet och infrastruktursäkerhet) lade till en sårbarhet i den — CVE-2026-18577, med allvarlighetsgrad 8,2 av 10 — i sin katalog över kända utnyttjade sårbarheter efter att ha bekräftat aktivt utnyttjande sedan den 31 juli 2026. Bristen sägs göra det möjligt för en angripare att få full administrativ åtkomst till själva N-central-konsolen.

Det spelar roll på grund av vad en angripare kan göra därifrån. Huntress rapporterade att lyckade attacker spred sig från den komprometterade konsolen vidare in i de slutpunkter som hanterades genom den — vilket innebär att ett intrång i MSP:ns verktyg kan bli ett intrång i era system utan att en angripare någonsin riktar in sig på er direkt. Huntress upptäckte också att angripare skapade Cloudflare-tunnlar på komprometterade system, en teknik som ger dem en varaktig, krypterad väg tillbaka in som kan se ut som vanlig webbtrafik för en brandvägg.

Ni behöver inte veta om er specifika leverantör använder N-central. Ni behöver fråga, och fråga bredare än bara det ena produktnamnet.

Checklista att skicka till er IT-leverantör eller MSP:

  • "Använder ni N-able N-central, eller någon annan N-able-produkt, för att hantera våra system?" Om ja: "Är den patchad mot CVE-2026-18577, och från vilket datum?"
  • "Har ni granskat administratörskontons aktivitet och åtkomstloggar på er hanteringskonsol sedan den 31 juli 2026, efter något ni inte kan förklara?"
  • "Har ni specifikt kontrollerat våra system efter oväntade utgående anslutningar — särskilt Cloudflare-tunnelprocesser (som ibland visas som 'cloudflared') eller tunneldomäner som ni inte själva har konfigurerat?"
  • "Har några nya lokala administratörskonton, schemalagda uppgifter eller policyer för fjärrhantering pushats ut till våra system som ni inte kan härleda till ert eget team?"
  • "Om ni inte använder N-central, vilket verktyg för fjärrhantering använder ni i stället, och har det haft några sårbarheter som nyligen lagts till i CISA:s katalog över kända utnyttjade sårbarheter?"

Vad ni ska göra med svaren

En bra IT-leverantör svarar på dessa frågor med datum och detaljer, ofta inom en dag, eftersom de redan bör känna till den här informationen eller snabbt kunna ta fram den från loggarna. Ett vagt svar — "vi har koll på det", "våra system är säkra", inga datum som erbjuds — är i sig användbar information: det säger er att det här samtalet måste tas igen, skriftligt, med en tydlig deadline.

Om ni hanterar er egen SonicWall utan en MSP gäller checklistan ovan fortfarande direkt för er — logga in i hanteringskonsolen själva, kontrollera firmwareversionen och kontrollera SonicWalls bulletinsida för den version som åtgärdar båda CVE:erna.

Ingen av dessa brister kräver att du river ut en leverantör eller säger upp en leverantör. De kräver bekräftelse på att den specifika luckan har täppts till och att ingenting tog sig igenom medan den var öppen. Ställ frågorna, ta reda på datumen, och lägg in en påminnelse i kalendern om att fråga igen nästa gång en leverantör avslöjar något som "aktivt utnyttjas". Det kommer att hända igen.