- Den kritiske sårbarheten CVE-2026-21643 i FortiClientEMS 7.4.4 tillater SQL-injeksjon og mulig fjernutførelse av kode uten autentisering.
- Sårbarheten er relatert til usikker håndtering av HTTP Site-headeren i mellomprogramvaren, som kan utnyttes via det offentlige endepunktet /api/v1/init_consts.
- Utnyttelsen kan føre til fullstendig kompromittering av administrasjonsdatabasen, tyveri av påloggingsinformasjon og endring av policyer distribuert til alle endepunkter.
- Tiltakene innebærer å oppgradere til FortiClientEMS 7.4.5 eller høyere, deaktivere flerbrukermodus hvis den ikke kan oppdateres umiddelbart, og begrense tilgangen til administrasjonskonsollen.
Sikkerheten til plattformer for endepunktadministrasjon har blitt et kritisk problem for mange selskaper, og det siste klare eksemplet er Fortinet og deres FortiClient Endpoint Management Server (EMS)-løsning. I de siste månedene har det blitt oppdaget en kritisk SQL-injeksjonssårbarhet som påvirker en veldig spesifikk versjon av produktet, noe som har skapt betydelig oppstyr i nettsikkerhetsmiljøet.
I denne artikkelen skal vi rolig gå gjennom hva som skjer med det kritiske SQL-injeksjonssårbarheten i Fortinet , hvordan CVE-2026-21643-sårbarheten fungerer, hvilken reell innvirkning den har på organisasjoner, hvordan den utnyttes i praksis, og fremfor alt hvilke hastetiltak og tiltak på mellomlang sikt du bør implementere hvis du administrerer infrastrukturer basert på FortiClientEMS eller lignende produkter.
Konteksten til CVE-2026-21643-sårbarheten i FortiClientEMS
Sårbarheten CVE-2026-21643 har blitt klassifisert som kritisk , med en CVSS-score fra 9.1 til 9.8 ifølge ulike kilder, noe som plasserer den praktisk talt på det høyeste alvorlighetsnivået. Feilen ligger i FortiClient Endpoint Management Server (EMS), plattformen som selskaper bruker til å distribuere og administrere FortiClient-agenter på sine brukerenheter.
Problemet påvirker spesifikt FortiClientEMS versjon 7.4.4 av 7.4-grenen når flerleietakermodus (funksjonaliteten «Sites») er aktivert. Versjon 8.0 og 7.2, samt FortiEMS Cloud-instanser, påvirkes ikke av denne feilen, så Fortinet har fokusert alle anbefalinger for tiltak mot miljøer som fortsatt bruker versjon 7.4.4 lokalt.
Denne SQL-injeksjonen skjer på grunn av feilaktig nøytralisering av spesielle elementer i SQL-setninger , klassifisert under CWE-89. I praksis tillater den en uautorisert ekstern angriper å sende spesiallagde HTTP-forespørsler og føre til at serveren utfører vilkårlige SQL-kommandoer, noe som kan resultere i ekstern kodekjøring (RCE) med databasebrukerens rettigheter.
Fortinets sikkerhetsråd indikerer at sårbarheten ligger i FortiClientEMS GUI-komponent , nærmere bestemt webgrensesnittet som administratorer bruker til å administrere og overvåke endepunkter. Dette betyr at enhver instans med et internettilgjengelig grensesnitt blir et hovedmål for angripere.
Hvordan kritisk SQL-injeksjon oppstår i Fortinet
Roten til problemet er knyttet til en større refaktorering av mellomvare i FortiClientEMS 7.4.4 . Under denne koderevisjonen endret utviklerne hvordan applikasjonen håndterer tilkoblinger til PostgreSQL-databasen og leietakerruting, noe som utilsiktet introduserte en feil i tilkoblingsfilen.
I denne nye logikken sender serveren direkte HTTP-overskrift Site til en konsultasjon search_path av PostgreSQLMålet var å velge skjemaet som tilsvarer hver leietaker basert på denne overskriften, men det store problemet er at mellomprogramvaren ikke utfører riktig validering eller sanering av den verdien.
Som et resultat kan en angriper ødelegge det tiltenkte strengformatet og legge sin egen ondsinnede nyttelast inn i SQL-setningen, og injisere vilkårlige kommandoer som databasen vil kjøre med de høye rettighetene som tjenestebrukeren har konfigurert i den virtuelle Fortinet-maskinen.
Risikoen forsterkes ytterligere fordi denne sårbare mellomprogramvaren kjøres før noen autentiseringskontroller . Med andre ord er det ikke nødvendig å logge inn eller ha påloggingsinformasjon: det er nok å bare sende en manipulert HTTPS-forespørsel med en modifisert Site-header for å forsøke å utnytte sårbarheten.
Dette mønsteret passer perfekt til et CVSS 3.1-scenario med AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H , der angrepet ankommer via nettverket, har lav kompleksitet, ikke krever forhåndsrettigheter eller brukerinteraksjon, og fullstendig kompromitterer konfidensialiteten, integriteten og tilgjengeligheten til det berørte systemet.
Angrepsvektor: endepunkt /api/v1/init_consts og nettstedsheader
Sikkerhetsforskere, som teamet til Bishop Fox, har forklart at den mest praktiske angrepsvektoren finnes ved endepunktet. offentlig tilgjengelig /api/v1/init_consts, en FortiClientEMS API-rute som brukes under initialisering av grensesnittet.
Angripere kan først bruke dette endepunktet til å Sjekk om flerleietakermodus er aktivertHvis de oppdager at Sites-funksjonaliteten er aktivert, fortsetter de med å injisere SQL-nyttelaster gjennom HTTP-headeren. Site, og utnytter det faktum at verdien overføres uten å rense setningen search_path.
Dette endepunktet har flere designfeil: for det første mangler det hastighetsbegrensende mekanismer og spesifikke brute-force-forsvar; for det andre returnerer det direkte feilmeldinger generert av PostgreSQL i responsteksten. Dette gjør livet mye enklere for en angriper.
Ved å motta disse feilene så eksplisitt, kan en ondsinnet aktør utføre feilbaserte utvinningsteknikker i én enkelt forespørsel , uten å måtte ty til de mye tregere, tidsbaserte injeksjonene. Dette gjør at opplistingen av sensitive tabeller, kolonner og data kan gå ekstremt raskt.
Hvis utnyttelsen lykkes, oppnår angriperen et scenario med fullstendig kompromittering av endepunktsadministrasjonsdatabasen . Siden databasebrukeren kjører med PostgreSQL-superbrukerrettigheter, kan de ikke bare eksfiltrere informasjon, men også eskalere til ekstern kodekjøring på det underliggende operativsystemet.
Reell innvirkning på organisasjonen og administrerte endepunkter
Virkningen av denne sårbarheten går langt utover en enkel datalekkasje. Muligheten til å kjøre vilkårlig SQL på FortiClientEMS-databasen lar angripere stjele administratorpassord, digitale sertifikater og komplette oversikter over enheter koblet til plattformen.
Med det tilgangsnivået kan en trusselaktør endre sikkerhetspolicyer og distribuere skadelige konfigurasjoner til alle administrerte endepunkter. Dette åpner døren for komplekse scenarier der organisasjonens egne sikkerhetsagenter blir en angrepsvektor inn i det interne nettverket.
Videre påvirker kompromitteringen av administrasjonsdatabasen også konfidensialiteten til lagrede data (f.eks. informasjon om brukere, utstyr, retningslinjer og sertifikater), integriteten (endring av regler, maler og tildelinger) og tilgjengeligheten (mulig sletting av data eller sabotasje av administrasjonsserveren).
Denne trusselen passer inn i den stadig vanligere trenden med angrep mot kantenheter og administrasjonssystemer , som er høyt verdsatt av nettkriminelle fordi de fungerer som informasjonsknutepunkter og kontrollerer store mengder endepunkter.
Av alle de ovennevnte grunnene har Fortinet klassifisert denne sårbarheten som kritisk, og sikkerhetsbyråer og -firmaer anbefaler å behandle enhver eksponert FortiClientEMS 7.4.4-instans som en maksimal risikofaktor inntil det motsatte er bevist.
Aktiv utnyttelse og eksponeringsområde
Selv om noen innledende rapporter indikerte at det ikke var oppdaget noen aktiv utnyttelse, bekreftet forskere fra firmaet Defused faktiske angrep som utnyttet CVE-2026-21643 bare fire dager før sårbarheten ble offentliggjort.
Data samlet inn av organisasjoner som Shadowserver viser at omtrent 2.000 FortiClientEMS-instanser var direkte eksponert for internett på overvåkingstidspunktet. USA ledet statistikken med rundt 756 sårbare servere, etterfulgt av Europa med over 680. Shodan oppdaget også mer enn 1.000 offentlig tilgjengelige FortiClientEMS-webgrensesnitt, mange sannsynligvis uoppdaterte.
Den offisielle NIST-registeroppføringen for CVE-2026-21643 støtter denne ekstreme alvorlighetsgraden, og viser en AV:N/AC:L/PR:N/UI:N-vektor med høy innvirkning på C, I og A. Dette innebærer at enhver FortiClientEMS 7.4.4-server med et åpent webgrensesnitt kan bli fullstendig kompromittert uten at angriperen trenger påloggingsinformasjon eller må overbevise noen bruker om å klikke på noe.
Defused rapporterte disse utnyttelsene 28. mars, og bemerket også at sårbarheten til tross for dette ennå ikke var oppført i CISAs KEV-katalog (kjente utnyttede sårbarheter) eller andre offentlige lister over aktivt utnyttede feil, noe som vanligvis skjer i disse første utnyttelsesvinduene.
På den annen side hadde Fortinet allerede gitt ut den korrigerende oppdateringen i februar med versjon 7.4.5, noe som tydeliggjør det tilbakevendende mønsteret innen cybersikkerhet: det er et betydelig tidsgap mellom tilgjengeligheten av oppdateringen og den faktiske distribusjonen i produksjon, en periode der angripere utnytter det til å kompromittere systemer som fortsatt ikke er oppdatert.
Indikatorer for kompromittering og tegn på angrep
For administratorer som administrerer FortiClientEMS, er det avgjørende å forstå ledetrådene som et potensielt utnyttelsesforsøk etterlater. Viktige indikatorer på kompromittering (IoC-er) inkluderer følgende:
Først fremhever de uvanlig lange responstider, fra 5 til over 20 sekunder, på endepunktene /api/v1/auth/signin o /api/v1/init_consts, som vist i tilgangsloggene til Apache eller en annen webserver som ligger foran.
Det er også et varseltegn å se Gjentatte HTTP 500-svar fra samme IP-adresse mot endepunktet /api/v1/init_constsDette mønsteret kan indikere at en angriper finjusterer SQL-injeksjonsnyttelastene sine gjennom prøving og feiling inntil de finner en som fungerer og ikke genererer feil.
I tillegg er det verdt å se i PostgreSQL-feilloggene. konsultasjoner search_path med enkle anførselstegn, semikolon eller SQL-nøkkelord som SELECT, INSERT o UPDATE utenfor den forventede konteksten. Denne typen spor peker vanligvis direkte på et forsøk på å manipulere nettstedsoverskriften.
Som et tiltak bør enhver FortiClientEMS 7.4.4-server som har blitt eksponert for internett uten skikkelige oppdateringer, behandles som potensielt kompromittert . Dette innebærer å isolere den fra nettverket, utføre en detaljert rettsmedisinsk analyse (database, operativsystem og logger), og planlegge en kontrollert rekonstruksjon av miljøet hvis det finnes bevis på inntrenging.
Umiddelbar avbøtning og offisiell løsning fra Fortinet
Det primære tiltaket for å redusere sikkerhetsproblemet er klart: oppdater FortiClientEMS 7.4.4 til versjon 7.4.5 eller høyere så snart som mulig. Fortinet rettet sårbarheten ved å erstatte strenginterpolering i spørringen med riktig håndtering av parameteriserte identifikatorer og sikker escape av input fra Site-headeren.
Versjon 8.0 og 7.2, samt FortiEMS Cloud, krever ikke ytterligere handling , ettersom de ikke er berørt av denne spesifikke sårbarheten. Likevel er det fortsatt lurt å gjennomgå internetteksponeringen og tilgangskonfigurasjonene dine, fordi angrepsflaten til administrasjonskonsoller alltid bør minimeres.
For team som av driftsmessige årsaker ikke kan installere oppdateringen umiddelbart, anbefaler noen forskere en midlertidig løsning: deaktivering av funksjonaliteten «Sites» for flere leietakere . Denne handlingen forhindrer kjøring av den sårbare kodebanen som er koblet til Site-headeren, noe som reduserer antallet utnyttbare alternativer betydelig.
På samme måte er det viktig å begrense nettilgang til EMS-administrasjonsgrensesnittet til kun klarerte interne nettverk . Ideelt sett bør konsollen plasseres bak et VPN eller en nulltillitsmekanisme, og aldri være direkte eksponert for internett, bortsett fra i svært eksepsjonelle og skikkelig sikrede tilfeller.
I tillegg anbefales det å gjennomgå og styrke brannmurregler og eventuelle WAF-er foran FortiClientEMS , bruke filtre som blokkerer typiske SQL-injeksjonsmønstre i HTTP-overskrifter, spesielt i Site-overskriften, og overvåke nøye eventuelle avvikende API-forespørsler.
Gode sikkerhetsrutiner utover oppdateringen
Utover å bare implementere oppdateringer og spesifikke tiltak, gjør denne hendelsen det klart at sårbarhetshåndtering må være en kontinuerlig prosess , ikke bare en engangsreaksjon på en leverandørrådgivning. Organisasjoner som er avhengige av plattformer for endepunktadministrasjon og nettverkssikkerhetsløsninger, bør styrke strategien sin på flere fronter.
På den ene siden er det viktig å ha en oppdatert oversikt over eiendeler og versjoner , slik at når en kritisk CVE publiseres, er det mulig å identifisere på få minutter hvilke systemer som er sårbare og prioritere oppdateringen av dem i henhold til eksponeringsnivå og kritiskhet.
På den annen side er det tilrådelig å velge periodiske penetrasjonstester og arkitekturgjennomganger som ikke bare validerer robustheten til selve produktet, men også hvordan det distribueres: nettverkssegmentering, separasjon av administrasjonsplan, tilgangsbegrensninger, sentralisert loggovervåking og deteksjon av unormal oppførsel.
Fra et utviklingsperspektiv demonstrerer denne casen igjen viktigheten av å anvende sikre utviklingspraksiser og regresjonstesting når det utføres en dyp refaktorering av mellomvare eller kritiske komponenter. Forbedringer av ytelse eller skalerbarhet kan ikke ledsages av et tilbakeskritt i slike grunnleggende mekanismer som rensing av inndata.
Selskaper som spesialiserer seg på cybersikkerhet og sikker utvikling tilbyr koderevisjon, penetrasjonstesting og konsulenttjenester som er spesielt utviklet for å oppdage disse sårbarhetene før de når produksjon. I miljøer som kombinerer lokal infrastruktur, sky og edge-enheter, utgjør det ofte hele forskjellen å stole på eksterne eksperter.
Til slutt, på styrings- og forretningsnivå, er det svært nyttig å ha dashbord og forretningsintelligens som tillater visualisering av tilstanden til sårbarheter, eksponering av administrasjonsgrensesnitt og den potensielle virkningen av en kritisk feil på organisasjonens prosesser. Denne tilnærmingen forenkler prioritering av investeringer og rettferdiggjøring av forebyggende tiltak som ved første øyekast kan virke kostbare, men som sparer mange problemer på mellomlang sikt.
Kombinasjonen av en alvorlig designfeil, en stor angrepsflate og den vanlige forsinkelsen i oppdateringer gjør CVE-2026-21643 til et lærebokeksempel på hvorfor sikkerhet i administrasjonskonsoller aldri bør undervurderes. Enhver organisasjon som bruker FortiClientEMS eller lignende løsninger, bør ta denne hendelsen som en vekker for å gjennomgå sikkerhetstilstanden sin, akselerere oppdateringssyklusene og styrke forsvaret rundt administrasjonsplattformene før nok et nulldagssårbarhet eller SQL-injeksjon setter dem i en ulempe igjen.
