En rättning för agentens inloggning
Hermes Agent 0.21.6 publicerades den 8 oktober 2026. Releasen innehåller en rättning för native-inloggningen i dashboarden. Dagen efter publicerade Tenable säkerhetsrapporten TRA-2026-65 om samma problem. Kombinationen av tillgänglig rättning och en offentlig teknisk rapport gör detta till en konkret uppdateringsnyhet för miljöer som använder Hermes Agent, inte ett allmänt påstående om att AI-modeller kan ta över servrar.
Hermes Agent är programvaran som bygger agentmiljön. Den ska inte blandas ihop med modellfamiljer som också heter Hermes. Felet finns i hanteringen av inloggning och återkopplingsadresser, inte i modellens vikter eller inferens. Ett byte av språkmodell rättar därför inte denna brist.
För LabOps IT:s läsare är huvudfrågan vilken installation som faktiskt kör dashboardens berörda autentiseringsflöde. En lokal klient, en container och en hanterad tjänst kan ha olika uppgraderingsvägar. Versionsetiketten i ett inventariesystem behöver knytas till den aktiva programvaran innan ett ändringsärende kan stängas.
Sessionsövertagande, inte automatiskt root
Tenable beskriver hur olika URL-tolkningar i server och webbläsare kunde leda till att en inloggningskod skickades till fel mottagare efter en riktig inloggning. Rapportens konsekvens är sessionsövertagande. Leverantörens rättningsbesked bekräftar att native-inloggningen kunde skicka koder till en återkopplingsadress som inte var loopback.
Det innebär en risk för kontots session och de behörigheter som följer med den. Det är däremot inte ett verifierat generellt rootfel i Linux eller ett belägg för att alla anslutna system automatiskt blir komprometterade. Agentens verkliga åtkomst till verktyg, data och andra tjänster behöver bedömas separat.
Rapporten kräver en inloggningssituation med användarinteraktion i den redovisade CVSS-bedömningen. Artikeln redovisar inga payloads eller instruktioner för att framkalla felet. Fokus ligger på att identifiera berörd programvara och verifiera rättning.
Officiell bedömning och kvarvarande osäkerhet
Tenable klassificerar rapporten som High. Den anger CVSS v3-poäng 8,8 och CVSS v4-poäng 8,6. Sidans separata fält för CVSS v3-vektor är inte konsekvent med vektorn som står intill poängen. Vi återger därför poängen som forskarens uppgift och bygger inte ett eget exakt betyg på det motsägelsefulla fältet.
De granskade källorna innehåller ingen bekräftelse på aktiv exploatering i verkliga angrepp. Tenable beskriver reproduktion i sin undersökning, vilket inte är samma sak som att angrepp har observerats hos kunder. LabOps IT har inte hämtat eller testat exploateringskod.
Inget CVE-nummer har fastställts i denna granskning; TRA-2026-65 används som bulletinreferens. Ransomwarekoppling, omfattning av eventuell missbrukad åtkomst och lokala intrång är inte verifierade. Dessa begränsningar ska följa med uppdateringsbeslutet och inte döljas bakom ordet sessionsövertagande.
Version och leveranskanal måste kontrolleras
Tenable anger Hermes Agent före 0.21.6 som berört och rekommenderar 0.21.6 eller senare. Leverantörens release innehåller den aktuella inloggningsrättningen. Den länkade ändringen sammanfogades den 1 oktober, medan den märkta releasen publicerades den 8 oktober. Kodändringens datum och tidpunkten då ett versionsmärkt paket finns är alltså olika saker.
Releasen omfattar GitHub-taggen och Docker-avbildningen och beskrivs som en stabil märkt leverans för Docker och Hermes Cloud. Samtidigt säger releaseinformationen att skrivbordsappen, Termux-paketen och Microsoft Store ligger kvar på sina dåvarande byggen tills nästa paketerade release.
Det går därför inte att ge rådet att en uppdateringsknapp i varje klient automatiskt installerar denna rättning. För en paketerad klient eller en leverantörshanterad tjänst behöver den ansvarige verifiera vilken agentkomponent som körs och om ändringen verkligen finns med. En annan produkt med liknande namn ska inte märkas som berörd utan identifiering.
Ett avgränsat kontrollflöde
LabOps IT rekommenderar fyra beslutspunkter: inventera leveransen, bedöm exponering och kontoåtkomst, uppdatera till en dokumenterat rättad leverans och verifiera både aktiv version och inloggningsfunktion. Det är en arbetsordning för försvar och ändringshantering, inte en beskrivning av ett angrepp.
Inventeringen bör dokumentera ägare, installationsmetod, versionsreferens och om dashboardens native-inloggning används. För containers behöver driftteamet koppla den körande instansen till rätt avbildning, inte bara kontrollera vilken fil som senast laddades ned. För källinstallationer behöver den använda revisionen kunna spåras.
Bedöm därefter vilka resurser kontot får använda. En agent med begränsad läsåtkomst har en annan konsekvensbild än en som kan ändra driftkonfiguration. Principen är att granska befintliga behörigheter, inte att prova sårbarheten mot ett produktionskonto.
Uppdatering och driftpåverkan
För en berörd installation är rådet att planera en skyndsam uppdatering via den egna leveranskanalens dokumenterade metod. Säkerhetskopiera nödvändig konfiguration och dokumentera hur tjänsten återställs om funktionstester inte godkänns. Vi har inte verifierat en universell workaround som ersätter rättningen.
Releasen samlar många ändringar sedan föregående version. Ett stort förändringsfönster gör det särskilt viktigt att testa de integrationer som den egna miljön faktiskt använder. En lyckad start av processen visar inte att verktygsanslutningar, autentisering och schemalagda agentjobb fungerar som avsett.
Planera eventuell omstart och avbrott för pågående jobb. Källorna fastställer inget generellt avbrottsfritt uppgraderingsförfarande för alla installationer. Testa efteråt normal inloggning och dokumenterad lokal återkoppling, utan att genomföra exploateringsförsök.
Vid misstänkt kontomissbruk behövs organisationens incidenthantering: bevara underlag och granska sessioner, kontoaktivitet och åtkomst enligt egna rutiner. Att rätta programvaran återkallar inte automatiskt redan missbrukade behörigheter. Credential- och sessionshantering måste bedömas som en separat incidentåtgärd.
LabOps IT:s bedömning
Åtgärdsprioriteten är Hög för en verifierat berörd installation med relevant inloggningsflöde. Rättning finns och ett sessionsövertagande kan påverka en agent med omfattande åtkomst. Vi klassar inte nyheten som Akut på grund av aktiv exploatering, eftersom sådan exploatering inte har bekräftats i underlaget.
Planerad kontroll passar en installation där rättningen redan verifierats eller där den berörda komponenten dokumenterat inte används. Om incidentindikatorer finns ska organisationens incidentprioritering styra, oberoende av artikelns generella bedömning.
Det viktigaste är att skilja modellval från plattformsunderhåll. Ett modernt modellnamn eller en uppdaterad operativsystemskärna säger inget om agentens inloggningskod. Verifiera den körande agentleveransen och dess åtkomst innan säkerhetsärendet avslutas.