Ivanti har offentliggjort och åtgärdat två kritiska säkerhetsbrister som påverkar Ivanti Endpoint Manager Mobile (EPMM) och som har utnyttjats aktivt i nolldagsattacker. Bristerna, som har spårats som CVE-2026-1281 och CVE-2026-1340, möjliggör obehörig fjärrkörning av kod och har CVSS-poäng på 9,8, vilket placerar dem bland de allvarligaste sårbarhetsklasserna. En av sårbarheterna har lagts till i CISA:s KEV-katalog (Known Exploited Vulnerabilities), vilket avsevärt ökar behovet av att åtgärda sårbarheterna, särskilt i federala miljöer i USA.
Dessa sårbarheter gör det möjligt för angripare att kompromissa med exponerade EPMM-apparater utan giltiga inloggningsuppgifter, vilket potentiellt kan ge full kontroll över system som hanterar och lagrar känsliga data om mobila enheter och företagskonfigurationer.
Översikt över sårbarheter
CVE-2026-1281 och CVE-2026-1340 är kodinjektionssårbarheter i Ivanti EPMM som gör det möjligt för angripare att utföra godtyckliga kommandon på distans och utan autentisering. Problemen härrör från felaktig hantering av indata i funktionerna In-House Application Distribution och Android File Transfer Configuration i EPMM. Lyckad exploatering resulterar i direkt exekvering av kod på själva apparaten, vilket skapar ett högrisk-scenario med tanke på EPMM:s privilegierade roll i företagsmiljöer.
Sårbarheterna påverkar flera supporterade versioner av Ivanti EPMM, inklusive versionerna 12.5.x, 12.6.x och 12.7.x. Ivanti har släppt RPM-baserade tillfälliga korrigeringar för berörda versioner; dessa korrigeringar kvarstår dock inte genom versionsuppgraderingar och måste tillämpas igen om apparaten uppdateras. En permanent korrigering förväntas med lanseringen av EPMM version 12.8.0.0, planerad till senare under Q1 2026.
Viktigt att notera är att Ivanti har meddelat att inga andra Ivanti-produkter påverkas av dessa sårbarheter, inklusive Ivanti Neurons för MDM, Ivanti Endpoint Manager (EPM) och Ivanti Sentry.
Exploatering och risk efter kompromettering
Ivanti har bekräftat att ett begränsat antal kunder aktivt utnyttjades före offentliggörandet, även om företaget noterade att det för närvarande saknar tillräcklig insyn i hotaktörernas verktyg och infrastruktur för att publicera tillförlitliga atomiska indikatorer på kompromisser. Baserat på historiska attacker mot tidigare EPMM-sårbarheter bedömer Ivanti att angripare vanligtvis etablerar persistens genom webbskal eller omvända skal som distribueras direkt på den komprometterade apparaten.
När ett EPMM-system har äventyrats får angriparna möjlighet att exekvera godtycklig kod, få tillgång till känsliga data relaterade till hanterade enheter och potentiellt svänga i sidled till anslutna företagsmiljöer. Eftersom EPMM-apparater ofta befinner sig i skärningspunkten mellan identitet, enhetshantering och nätverksåtkomst kan en framgångsrik kompromettering få kaskadmässiga säkerhetsimplikationer långt bortom själva apparaten.
Vägledning för detektering
Med tanke på bristen på detaljerade indikatorer förlitar sig detekteringen för närvarande på logganalys och konfigurationsgranskning. Ivanti rekommenderar kunder att inspektera Apache-åtkomstloggar i /var/log/httpd/https-access_log för misstänkta förfrågningar som riktar sig till sårbara slutpunkter. Förfrågningar som returnerar HTTP 404-svar, snarare än de förväntade 200-svaren som är förknippade med legitim användning, kan indikera försök eller framgångsrik exploatering. Ivanti har tillhandahållit ett reguljärt uttryck för att hjälpa till med att identifiera sådana poster och rekommenderar att man korrelerar fynd med tidsstämplar och källans IP-adresser.
Utöver logganalys uppmuntras organisationer att granska EPMM:s administrativa konton för obehöriga ändringar, undersöka autentiseringskonfigurationer som LDAP och SSO samt granska nyskapade eller modifierade enhetspolicyer och pushade applikationer. Oväntade ändringar i nätverks- eller VPN-konfigurationen som distribueras via EPMM bör också behandlas som potentiella indikatorer på intrång.
Vad du bör göra
Organisationer som kör Ivanti EPMM bör behandla dessa sårbarheter som en omedelbar risk med hög allvarlighetsgrad. Den första prioriteringen bör vara att tillämpa lämpliga Ivanti-utgivna RPM-patchar på alla berörda EPMM-instanser, med förståelsen att dessa patchar måste tillämpas på nytt efter varje versionsuppgradering tills EPMM 12.8.0.0 distribueras. EPMM-apparater som vetter mot Internet bör betraktas som särskilt riskfyllda och prioriteras i enlighet med detta.
Parallellt med patchningen bör teamen göra en grundlig genomgång av Apache-åtkomstloggar och EPMM-konfigurationsinställningar för att identifiera eventuella tecken på exploatering. Eftersom Ivanti inte rekommenderar att man försöker rengöra en komprometterad apparat manuellt, bör varje indikation på framgångsrik exploatering utlösa en fullständig återställningsprocess. Detta innebär att apparaten återställs från en känd bra säkerhetskopia som tagits före komprometteringen eller att en ny EPMM-instans byggs och rena data migreras till den.
Efter återställning bör organisationer anta att uppgifter har exponerats och vidta korrigerande åtgärder genom att återställa alla lokala EPMM-kontolösenord, rotera LDAP- och Kerberos-tjänstkontouppgifter och återkalla och ersätta alla offentliga certifikat som används av EPMM-apparaten. Ytterligare granskning bör tillämpas på anslutna system och tjänster för tecken på lateral rörelse, särskilt i miljöer där EPMM integreras med identitets- eller nätverksåtkomstkontroller.
Slutligen bör säkerhetsteamen uppdatera sina playbooks för sårbarhetshantering och incidenthantering så att EPMM och liknande infrastrukturapparater uttryckligen inkluderas som högvärdiga mål. Kontinuerlig övervakning av avvikande utgående aktivitet från EPMM-system och proaktiv validering av säkerhetskopior kommer att bidra till att minska uppehållstiden och begränsa effekterna om framtida exploateringsförsök inträffar.
Om du är orolig för något av de hot som beskrivs i den här bulletinen eller behöver hjälp med att avgöra vilka åtgärder du bör vidta för att skydda dig mot de mest väsentliga hoten mot din organisation, vänligen kontakta din kontoansvarige, eller alternativtkontaktaoss för att ta redapå hur du kan skydda din organisation.