Nya KEV-poster gör gamla fel till ett aktuellt driftärende
CISA lade den 8 oktober 2026 till CVE-2015-5477 i ISC BIND och CVE-2016-3081 i Apache Struts i sin katalog över kända exploaterade sårbarheter, KEV. Förändringen är alltså ett nytt prioriteringsunderlag, inte nyupptäckta programfel eller nyutgivna patchar. Båda posterna har åtgärdsdatum den 11 oktober i katalogen. Det datumet ska inte beskrivas som en allmän svensk lagstadgad deadline.
LabOps IT:s åtgärdsprioritet är Akut för berörda, exponerade installationer. Ett gammalt CVE-nummer är inget skydd för en gammal tjänst. Samtidigt innebär katalogposten inte att alla moderna Linuxservrar, DNS-tjänster eller Javaapplikationer är sårbara. Komponenten, versionen, leverantörens eventuella bakport och den relevanta konfigurationen måste identifieras.
Den aktuella KEV-katalogen anger även andra nytillkomna äldre fel. Den här artikeln avgränsas till DNS och Javawebbapplikationer: två centrala tjänstetyper som ofta har beroenden utanför den server där de körs. Vi redovisar inga egna angreppstester och inga instruktioner för exploatering.
BIND: DNS-tillgänglighet, inte bekräftat rootövertagande
ISC:s bulletin om CVE-2015-5477 beskriver felaktig hantering av TKEY-frågor som kan få named-processen att avslutas. Konsekvensen är överbelastningsangrepp eller tjänsteavbrott, inte den kodexekvering eller det rootövertagande som ibland sammanblandas med kritiska Linuxfel. Både rekursiva och auktoritativa DNS-servrar kan beröras.
Bulletinen listar BIND 9.1.0–9.8.x, 9.9.0–9.9.7-P1 och 9.10.0–9.10.2-P2 som berörda. Historiska rättningar är 9.9.7-P2 och 9.10.2-P3. Dessa är gränser för just detta fel, inte rekommenderade installationsmål år 2026. Välj en fortfarande supportad leverans med dokumenterad rättning.
ISC klassificerar felet som Critical och anger CVSS 2.0: 7,8. Versionsnumret på CVSS är viktigt: siffran ska inte ommärkas till ett modernt CVSS 3.1- eller 4.0-värde. ISC anger ingen workaround. Bulletinens varning är också att ACL:er och tjänstens begränsningsinställningar inte hindrar den aktuella felhanteringen, eftersom den sker före dessa kontroller.
För driftteam blir första frågan därför var DNS faktiskt körs. LabOps IT rekommenderar att även undersöka äldre appliances och interna integrationssystem, men deras berördhet måste bekräftas av respektive leverantör. Att produkten kan innehålla BIND räcker inte för att fastställa samma versionsgräns eller patchpaket.
Struts: särskild funktion öppnar för kodexekvering
Apache Struts bulletin S2-032 gäller CVE-2016-3081 och möjlig fjärrkörning av kod när Dynamic Method Invocation, DMI, är aktiverat. Apache anger maximal klassning Important. Någon CVSS-poäng anges inte på den granskade bulletinsidan; artikeln tillskriver därför inte Apache ett påhittat värde.
Den angivna berörda omfattningen är Struts 2.3.20–2.3.28, med undantag för 2.3.20.3 och 2.3.24.3. Historiska rättningar är 2.3.20.3, 2.3.24.3 och 2.3.28.1. Bulletinens åtgärd är att stänga av DMI om möjligt eller uppgradera. Inte heller här bör en gammal rättad version användas som ett generellt mål för en modernisering.
LabOps IT rekommenderar att koppla varje träff till den applikation som äger biblioteket. Java på servern är inte bevis för Struts, och Struts i ett gammalt utvecklingsarkiv är inte samma sak som ett exponerat körande system. Kontrollera byggunderlag, driftsatt paket och faktisk konfiguration tillsammans.
En ändring av DMI bör hanteras av applikationsägaren och testas mot godkända funktioner. Det är en rekommenderad driftkontroll, inte en garanti om att avstängningen fungerar utan verksamhetspåverkan i varje installation. Undvik breda konfigurationsändringar utan att först veta vilka applikationsflöden som behöver behållas.
Känd exploatering och PoC är olika uppgifter
KEV-registreringen ger stöd för att båda sårbarheterna är kända för att ha exploaterats. Den bevisar inte ett pågående intrång i läsarens miljö, beskriver inte en specifik ny kampanj och fastställer inte vilken dag ett visst angrepp skedde. Katalogen markerar känd användning i ransomwarekampanjer som Unknown för dessa poster.
ISC uppger dessutom att offentlig PoC-kod hade rapporterats redan i den historiska bulletinen. LabOps IT har inte hämtat eller funktionstestat den koden. För Struts har en fungerande offentlig PoC inte verifierats i denna körning. Dessa begränsningar förändrar inte CISA:s KEV-status, men behöver finnas kvar i rapporteringen.
Vid misstänkt intrång bör incidenthanteringen hållas åtskild från den vanliga patchprocessen. Dokumentera observationer och låt ansvarig säkerhetsfunktion besluta om bevarande och utredning. En installerad rättning är inte i sig ett bevis för att tidigare aktivitet har utretts eller att ett system är återställt till betrodd status.
Från inventering till verifierad tjänst
Illustrationen visar LabOps IT:s rekommenderade arbetsflöde, inte en angreppskedja. Inventeringen delar upp underlaget i BIND och Struts, varefter respektive leverantörs rättning eller avgränsade skyddsåtgärd följs av funktionstest och dokumentation.
Börja med ett kort register: tjänst, systemägare, komponentversion, paketkälla, exponeringsväg och underlag som visar rättningsstatus. Markera okänd status som okänd. Ett lägre versionsnummer kan vara rättat genom en distributionsbakport, medan en egenbyggd applikation kan bära med sig ett gammalt bibliotek trots uppdaterat operativsystem.
Planera sedan underhållet utifrån beroendena. För DNS rekommenderar vi att kontrollera alternativa resolvrar och auktoritativ redundans innan en tjänst ändras. För webbapplikationen behöver teamet ett representativt funktionstest och en överenskommen hantering om ändringen bryter ett nödvändigt flöde. Artikeln lovar inte avbrottsfri patchning.
Efter förändringen ska faktisk tjänst och faktisk rättning verifieras var för sig. Ett lyckat installationskommando räcker inte som facit. Kontrollera leverantörens paketstatus, att avsedda DNS-frågor eller applikationsfunktioner fungerar och att övervakningen åter är meningsfull. Spara både resultat och kvarvarande avvikelser.
LabOps IT:s bedömning
Det nya nyhetsvärdet är att känd exploatering nu påverkar prioriteringen av två äldre komponentfel. För exponerade, berörda system är vår prioritet Akut. För en verifierat rättad eller ej berörd installation räcker dokumenterad uppföljning; ingen nöduppgradering bör göras enbart på grund av ett produktnamn.
Vår slutsats är att prioritera identifiering och leverantörsstyrd åtgärd, inte att återinstallera historiska patchversioner eller genomföra angreppsprov. Särskilt DNS-avbrott kan få stor praktisk betydelse utan att någon får rootåtkomst. Skilj därför tillgänglighetsrisk, kodexekvering, exploateringsstatus och lokal exponering i ändringsbeslutet.
