- Den kritiska sårbarheten CVE-2026-21643 i FortiClientEMS 7.4.4 möjliggör SQL-injektion och eventuell fjärrkörning av kod utan autentisering.
- Sårbarheten är relaterad till den osäkra hanteringen av HTTP Site-headern i mellanprogramvaran, som kan utnyttjas via den publika slutpunkten /api/v1/init_consts.
- Utnyttjandet kan resultera i total kompromiss med hanteringsdatabasen, stöld av autentiseringsuppgifter och modifiering av policyer som distribueras till alla slutpunkter.
- Åtgärderna innebär att uppgradera till FortiClientEMS 7.4.5 eller högre, inaktivera flerklientläge om det inte kan uppdateras omedelbart och begränsa åtkomsten till administrationskonsolen.
Säkerheten för endpoint management-plattformar har blivit en kritisk fråga för många företag, och det senaste tydliga exemplet är Fortinet och deras FortiClient Endpoint Management Server (EMS)-lösning. Under de senaste månaderna har en kritisk SQL-injektionssårbarhet upptäckts som påverkar en mycket specifik version av produkten, vilket har skapat stor uppmärksamhet inom cybersäkerhetsgemenskapen.
I den här artikeln kommer vi att lugnt och lugnt gå igenom vad som händer med den kritiska SQL-injektionssårbarheten i Fortinet , hur sårbarheten CVE-2026-21643 fungerar, vilken verklig inverkan den har på organisationer, hur den utnyttjas i praktiken och framför allt vilka brådskande och medellångsiktiga åtgärder du bör implementera om du hanterar infrastrukturer baserade på FortiClientEMS eller liknande produkter.
Kontext för sårbarheten CVE-2026-21643 i FortiClientEMS
Sårbarheten CVE-2026-21643 har klassificerats som kritisk , med en CVSS-poäng som sträcker sig från 9.1 till 9.8 enligt olika källor, vilket placerar den på praktiskt taget högsta allvarlighetsgraden. Felet finns i FortiClient Endpoint Management Server (EMS), plattformen som företag använder för att distribuera och hantera FortiClient-agenter på sina användarenheter.
Mer specifikt påverkar problemet FortiClientEMS version 7.4.4 av 7.4-grenen när flerklientläge (funktionen "Sites") är aktiverat. Versionerna 8.0 och 7.2, såväl som FortiEMS Cloud-instanser, påverkas inte av den här buggen, så Fortinet har fokuserat alla rekommendationer för åtgärdsåtgärder på miljöer som fortfarande använder version 7.4.4 lokalt.
Denna SQL-injektion sker på grund av felaktig neutralisering av specialelement i SQL-satser , klassificerade under CWE-89. I praktiken tillåter den en oautentiserad fjärrangripare att skicka specialutformade HTTP-förfrågningar och få servern att köra godtyckliga SQL-kommandon, vilket kan resultera i fjärrkodkörning (RCE) med databasanvändarens privilegier.
Fortinets säkerhetsmeddelanden indikerar att sårbarheten ligger i FortiClientEMS GUI-komponent , närmare bestämt webbgränssnittet som administratörer använder för att hantera och övervaka slutpunkter. Det innebär att alla instanser med ett internetåtkomligt gränssnitt blir ett primärt mål för angripare.
Hur kritisk SQL-injektion uppstår i Fortinet
Roten till problemet är kopplad till en större omstrukturering av mellanprogramvaran i FortiClientEMS 7.4.4 . Under denna kodrevision ändrade utvecklarna hur applikationen hanterar anslutningar till PostgreSQL-databasen och routning av hyresgäster, vilket oavsiktligt introducerade en bugg i anslutningsfilen.
I den här nya logiken skickar servern direkt vidare HTTP-rubrik Site till en konsultation search_path av PostgreSQLMålet var att välja det schema som motsvarar varje hyresgäst baserat på den här rubriken, men det stora problemet är att mellanprogramvaran inte utför korrekt validering eller sanering av det värdet.
Som ett resultat kan en angripare bryta det avsedda strängformatet och smyga in sin egen skadliga nyttolast i SQL-satsen, vilket injicerar godtyckliga kommandon som databasen kommer att köra med de höga behörigheter som tjänstanvändaren har konfigurerat i den virtuella Fortinet-maskinen.
Risken förstärks ytterligare eftersom denna sårbara mellanprogramvara körs innan några autentiseringskontroller har genomförts . Med andra ord finns det inget behov av att logga in eller ha inloggningsuppgifter: det räcker med att skicka en manipulerad HTTPS-begäran med en modifierad webbplatsrubrik för att försöka utnyttja sårbarheten.
Detta mönster passar perfekt in i ett CVSS 3.1-scenario med AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H , där attacken anländer via nätverk, har låg komplexitet, inte kräver förhandsbehörigheter eller användarinteraktion och fullständigt äventyrar det drabbade systemets sekretess, integritet och tillgänglighet.
Attackvektor: endpoint /api/v1/init_consts och Site header
Säkerhetsforskare, som Bishop Fox team, har förklarat att den mest praktiska attackvektorn finns vid slutpunkten. allmänt tillgänglig /api/v1/init_consts, en FortiClientEMS API-rutt som används under gränssnittsinitiering.
Angripare kan först använda denna slutpunkt för att Kontrollera om flerhyresgästläge är aktiveratOm de upptäcker att Sites-funktionen är aktiverad fortsätter de att injicera SQL-nyttolaster via HTTP-headern. Site, och utnyttjar det faktum att värdet överförs utan rensning till meningen search_path.
Denna slutpunkt har flera designfel: för det första saknar den hastighetsbegränsande mekanismer och specifika brute-force-försvar; för det andra returnerar den direkt felmeddelanden genererade av PostgreSQL i svarstexten. Detta gör livet mycket enklare för en angripare.
Genom att ta emot dessa fel så explicit kan en illvillig aktör utföra felbaserade extraktionstekniker i en enda begäran , utan att behöva tillgripa de mycket långsammare, tidsbaserade injektionerna. Detta möjliggör extremt snabb uppräkning av känsliga tabeller, kolumner och data.
Om exploiten lyckas uppnår angriparen ett scenario där slutpunktshanteringsdatabasen fullständigt komprometteras . Eftersom databasanvändaren kör med PostgreSQL-superanvändarbehörigheter kan de inte bara exfiltrera information utan också eskalera till fjärrkodkörning på det underliggande operativsystemet.
Verklig påverkan på organisationen och hanterade slutpunkter
Effekten av denna sårbarhet går långt bortom en enkel dataläcka. Möjligheten att köra godtycklig SQL på FortiClientEMS-databasen gör det möjligt för angripare att stjäla administratörslösenord, digitala certifikat och kompletta inventeringar av enheter anslutna till plattformen.
Med den åtkomstnivån kan en hotaktör ändra säkerhetspolicyer och distribuera skadliga konfigurationer till alla hanterade slutpunkter. Detta öppnar dörren för komplexa scenarier där organisationens egna säkerhetsagenter blir en attackvektor in i det interna nätverket.
Dessutom påverkar komprometteringen av hanteringsdatabasen även sekretessen för lagrade data (t.ex. information om användare, utrustning, policyer och certifikat), integriteten (ändring av regler, mallar och tilldelningar) och tillgängligheten (möjlig radering av data eller sabotage av administrationsservern).
Detta hot passar in i den allt vanligare trenden med attacker mot edge-enheter och hanteringssystem , vilka är högt värderade av cyberbrottslingar eftersom de fungerar som informationshubbar och kontrollerar stora volymer av endpoints.
Av alla ovanstående skäl har Fortinet klassificerat denna sårbarhet som kritisk, och säkerhetsmyndigheter och företag rekommenderar att alla exponerade FortiClientEMS 7.4.4-instanser behandlas som en tillgång med maximal risk tills motsatsen bevisas.
Aktivt utnyttjande och exponeringsområde
Även om vissa inledande rapporter indikerade att ingen aktiv exploatering hade upptäckts, bekräftade forskare från företaget Defused faktiska attacker som utnyttjade CVE-2026-21643 bara fyra dagar innan sårbarheten offentliggjordes.
Data som samlats in av organisationer som Shadowserver visar att cirka 2 000 FortiClientEMS-instanser var direkt exponerade för internet vid tidpunkten för övervakningen. USA ledde statistiken med cirka 756 sårbara servrar, följt av Europa med över 680. Shodan upptäckte också mer än 1 000 offentligt tillgängliga FortiClientEMS-webbgränssnitt, många troligen omatchade.
Den officiella NIST-registerposten för CVE-2026-21643 stöder denna extrema allvarlighetsgrad och visar en AV:N/AC:L/PR:N/UI:N-vektor med hög påverkan på C, I och A. Detta innebär att vilken FortiClientEMS 7.4.4-server som helst med ett öppet webbgränssnitt kan komprometteras helt utan att angriparen behöver inloggningsuppgifter eller övertyga någon användare att klicka på något.
Defused rapporterade dessa exploateringar den 28 mars och noterade också att sårbarheten trots detta ännu inte listades i CISA:s KEV-katalog (Known Exploited Vulnerabilities) eller andra offentliga listor över aktivt utnyttjade brister, något som vanligtvis händer under dessa initiala exploateringsfönster.
Å andra sidan släppte Fortinet redan den korrigerande patchen i februari med version 7.4.5, vilket tydliggör det återkommande mönstret inom cybersäkerhet: det finns ett betydande tidsgap mellan tillgängligheten av fixen och dess faktiska driftsättning i produktion, en period under vilken angripare utnyttjar den för att kompromettera system som fortfarande inte är uppdaterade.
Indikatorer på kompromiss och tecken på attack
För administratörer som hanterar FortiClientEMS är det avgörande att förstå de ledtrådar som ett potentiellt utnyttjandeförsök lämnar. Viktiga indikatorer på kompromisser (IoCs) inkluderar följande:
Först lyfter de fram ovanligt långa svarstider, från 5 till över 20 sekunder, på slutpunkterna /api/v1/auth/signin o /api/v1/init_consts, som det ses i åtkomstloggarna för Apache eller en annan webbserver som ligger framför.
Det är också ett varningstecken att se Upprepade HTTP 500-svar från samma IP-adress mot slutpunkten /api/v1/init_constsDet här mönstret kan tyda på att en angripare finjusterar sina SQL-injektionsnyttolaster genom trial and error tills de hittar en som fungerar och inte genererar fel.
Dessutom är det värt att titta i PostgreSQL-felloggarna. konsultationer search_path med enkla citattecken, semikolon eller SQL-nyckelord som SELECT, INSERT o UPDATE utanför det förväntade sammanhanget. Denna typ av spår pekar vanligtvis direkt på ett försök att manipulera webbplatsens rubrik.
Som en åtgärd bör alla FortiClientEMS 7.4.4-servrar som har exponerats för internet utan korrekta uppdateringar behandlas som potentiellt komprometterade . Detta innebär att isolera den från nätverket, utföra en detaljerad forensisk analys (databas, operativsystem och loggar) och planera en kontrollerad rekonstruktion av miljön om bevis på intrång hittas.
Omedelbar begränsning och officiell lösning från Fortinet
Den primära åtgärden är tydlig: uppdatera FortiClientEMS 7.4.4 till version 7.4.5 eller högre så snart som möjligt. Fortinet åtgärdade sårbarheten genom att ersätta stränginterpolering i frågan med korrekt hantering av parametriserade identifierare och säkert escape-inmatning från Site-headern.
Version 8.0 och 7.2, såväl som FortiEMS Cloud, kräver inga ytterligare åtgärder , eftersom de inte påverkas av just denna sårbarhet. Ändå är det fortfarande en bra idé att granska din internetexponering och åtkomstkonfigurationer, eftersom attackytan för hanteringskonsoler alltid bör minimeras.
För team som av operativa skäl inte kan installera patchen omedelbart rekommenderar vissa forskare en tillfällig åtgärd: att inaktivera funktionen "Sites" för flera hyresgäster . Denna åtgärd förhindrar körningen av den sårbara kodsökvägen som är länkad till Site-headern, vilket avsevärt minskar antalet utnyttjandemöjligheter.
På samma sätt är det viktigt att begränsa webbåtkomsten till EMS-hanteringsgränssnittet till endast betrodda interna nätverk . Helst bör konsolen placeras bakom ett VPN eller en nolltrust-åtkomstmekanism och aldrig lämnas direkt exponerad för internet förutom i mycket exceptionella och korrekt säkrade fall.
Dessutom är det lämpligt att granska och stärka brandväggsregler och eventuella WAF:er framför FortiClientEMS , tillämpa filter som blockerar typiska SQL-injektionsmönster i HTTP-headers, särskilt i Site-headern, och noggrant övervaka eventuella avvikande API-förfrågningar.
Goda säkerhetsrutiner utöver patchen
Utöver att bara implementera patchar och specifika åtgärder, gör denna incident det tydligt att sårbarhetshantering måste vara en kontinuerlig process , inte bara en engångsreaktion på en leverantörsrekommendation. Organisationer som förlitar sig på plattformar för endpoint management och nätverkssäkerhetslösningar bör stärka sin strategi på flera fronter.
Å ena sidan är det viktigt att ha en aktuell inventering av tillgångar och versioner , så att det, när en kritisk CVE publiceras, är möjligt att på några minuter identifiera vilka system som är sårbara och prioritera deras uppdateringar utifrån exponeringsnivå och kritiskhet.
Å andra sidan är det lämpligt att välja regelbundna penetrationstester och arkitekturgranskningar som validerar inte bara produktens robusthet, utan även hur den distribueras: nätverkssegmentering, separering av hanteringsplan, åtkomstbegränsningar, centraliserad loggövervakning och detektering av avvikande beteenden.
Ur ett utvecklingsperspektiv visar detta fall återigen vikten av att tillämpa säkra utvecklingsmetoder och regressionstestning närhelst en djupgående omstrukturering av mellanprogramvara eller kritiska komponenter utförs. Prestanda- eller skalbarhetsförbättringar kan inte åtföljas av ett steg bakåt i sådana grundläggande mekanismer som sanering av indata.
Företag som specialiserar sig på cybersäkerhet och säker utveckling erbjuder kodgranskning, penetrationstester och konsulttjänster som är särskilt utformade för att upptäcka dessa sårbarheter innan de når produktion. I miljöer som kombinerar lokal infrastruktur, moln och edge-enheter gör det ofta hela skillnaden att förlita sig på externa experter.
Slutligen, på styrnings- och affärsnivåer, är det mycket användbart att ha dashboards och business intelligence som möjliggör visualisering av sårbarheter, exponering av ledningsgränssnitt och den potentiella effekten av ett kritiskt fel på organisationens processer. Denna metod underlättar prioritering av investeringar och motivering av förebyggande åtgärder som vid första anblicken kan verka kostsamma, men som sparar många problem på medellång sikt.
Kombinationen av ett allvarligt designfel, en stor attackyta och den vanliga förseningen i patchning gör CVE-2026-21643 till ett läroboksexempel på varför säkerhet i hanteringskonsoler aldrig bör underskattas. Alla organisationer som använder FortiClientEMS eller liknande lösningar bör ta denna incident som en väckarklocka för att se över sin säkerhetsställning, accelerera sina uppdateringscykler och stärka försvaret kring sina hanteringsplattformar innan ytterligare en nolldagssårbarhet eller SQL-injektion försätter dem i en nackdel igen.
