Fortinet schakelt SSO van FortiCloud uit na een 0-day: de kwetsbaarheid die de cloud-identiteit tot ‘sleutel in het slot’ maakt

De beslissing was zo snel als ongewöhnlijk: Fortinet heeft tijdelijk het eenmalig inloggen (SSO) van FortiCloud gedeactiveerd nadat actief misbruik werd bevestigd van een zero-day kwetsbaarheid die verschillende van hun meest gebruikte producten treft. De kwetsbaarheid, door de fabrikant aangeduid als FG-IR-26-060 en geregistreerd als CVE-2026-24858, stelt een aanvaller met een FortiCloud-account en een geregistreerd apparaat in staat om in te loggen op gekoppelde apparaten van andere accounts, mits het FortiCloud SSO op die apparaten geactiveerd is.

Dit incident onderstreept een onderliggend probleem dat security teams steeds meer bezighoudt: het gemak van cloudbeheer en SSO kan een kritisch aanvalspunt worden wanneer authenticatie-functies de facto veranderen in een “VIP-pas” voor infrastructuurbeheer. De fout wordt geclassificeerd als authenticatie-omissie via alternatieve routes of kanalen (CWE-288), een bekende categorie, maar bijzonder gevaarlijk wanneer het gecombineerd wordt met beheerrechten.

Wat maakt deze zero-day anders: het is geen geïsoleerde bug, maar een patroon

Volgens de analyse van Fortinet vertoont het incident gelijkenissen met de golf van december 2025 gerelateerd aan bypasses van SSO (CVE-2025-59718 en CVE-2025-59719), maar met een belangrijk verschil: in januari werden gevallen ontdekt waarin onrechtmatige toegang plaatsvond op apparaten die al waren geüpdatet naar de nieuwste versie op het moment van de aanval, wat wijst op een nieuwe exploitatie-route.

De fabrikant verduidelijkte ook een aanvankelijke bezorgdheid: hoewel aanvankelijk gedacht werd dat het breder impact had op SAML-implementaties, bevestigde het dat de kwetsbaarheid specifiek betrekking heeft op FortiCloud SSO en niet op derden Identity Providers (IdP) of FortiAuthenticator. Deze precisering is cruciaal in omgevingen met federatieve identiteiten, waar niet elk SSO gelijk is.

Tijdlijn: frauduleuze accounts, SSO uitgeschakeld en heractivering met “versieblokkering”

De respons versnelde zich binnen enkele dagen:

  • 22–23 januari 2026: Fortinet schakelde de FortiCloud-accounts uit die tijdens de aanvallen werden gebruikt, volgens hun eigen “tijdlijn”.
  • 26 januari 2026: de fabrikant deactiveerde FortiCloud SSO om misbruik te beperken.
  • 27 januari 2026: de dienst werd hersteld, maar met een belangrijke wijziging: FortiCloud SSO accepteerde geen inlogpogingen meer van devices met kwetsbare versies, waardoor organisaties gedwongen werden te updaten om de authenticatie door te laten gaan.

Parallel hieraan publiceerde CISA een waarschuwing over lopende exploits, en volgens de gegevens van het NVD werd op 27 januari 2026 de CVE toegevoegd aan de KEV-katalogus met een deadline voor mitigatie op 30 januari 2026 voor federale instanties, een duidelijk teken van urgentie.

Aangedane producten en versies: patchen per tak, geen enkele “knop”

De technische adviezen beschrijven een breed bereik, vooral wanneer het SSO van FortiCloud geactiveerd is. In de praktijk is de last voor operaties dat het updaten afhankelijk is van de geïnstalleerde tak van de software.

Volgens de waarschuwing van INCIBE omvatten aanbevolen routes onder andere:

  • FortiOS: update naar 7.6.6 of hoger; 7.4.11 of hoger; 7.2.13 of hoger; 7.0.19 of hoger.
  • FortiManager: 7.6.6+, 7.4.10+, 7.2.13+, 7.0.16+.
  • FortiAnalyzer: 7.6.6+, 7.4.10+, 7.2.12+, 7.0.16+.
  • FortiProxy: 7.6.6+, 7.4.13+; in takken 7.2/7.0 wordt aanbevolen migreren naar een gereviseerde versie.

Bovendien vermeldt de NVD-database (NIST) dat ook FortiWeb getroffen is in verschillende versies (8.0.0–8.0.3, 7.6.0–7.6.6, 7.4.0–7.4.11), wat wijst op een algemeen probleem binnen het ecosysteem wanneer cloud-gebaseerde authenticatie betrokken is.

Aanwijzers van compromittering: het spoor dat het incident achterlaat, maar het kan “legitiem” lijken

Een van de lastige aspecten van dit incident is dat het initiële spoor kan worden verward met een geldige toegang: een login via SSO gevolgd door administratieve acties.

Fortinet deelde concrete indicatoren: twee accounts die werden gebruikt bij het inloggen, meerdere IP-adressen (onder andere beschermd door Cloudflare) en herhaalde patronen van aanmaak van lokale admin-accounts voor persistentie. Daarnaast werden voorbeelden van logs gepubliceerd met event-identifiers voor “admin login successful” en “object attribute configured”, typische signalen dat een nieuwe beheerder werd toegevoegd.

Operatieel risico ligt niet alleen bij het controlen van het apparaat: sommige rapporten beschrijven dat aanvallers configuraties hebben gedownload, wat bijzonder ernstig is omdat dit “kaartje” gevoelige informatie kan blootleggen zoals regels, VPN-instellingen, segmentatie, routes en authenticatiemechanismen. gespecialiseerde media spraken over geautomatiseerde campagnes en een hoog aantal potentieel getroffen endpoints.

Wat prioriteit moet krijgen voor IT- en security-teams

In een technologische omgeving is de kernboodschap simpel: het gaat hier niet alleen om het “patchen wanneer er een kwetsbaarheid is”. Het gaat om het minimaliseren van het aanvalsevenement en het snel stoppen van het risico, vooral omdat het om beheerrechten gaat.

Enkele praktische maatregelen op basis van officiële aanbevelingen:

  1. Controleren of FortiCloud SSO actief is op rand- en beheersystemen. Indien niet strikt noodzakelijk, tijdelijk uitschakelen terwijl een update wordt gepland.
  2. Updaten volgens tak naar de juiste fixversies (of migreren indien geen directe patch beschikbaar is), vooral voor kwetsbare en extern beheerde systemen.
  3. Controleren van beheerdersaccounts (lokaal en remote) om onverwachte aanpassingen, profielwijzigingen en SSO-toegangen buiten kantooruren te detecteren.
  4. Beperken van beheer-activiteiten (bijvoorbeeld via “local-in” policies, trusted IP-lijsten en minimaliseren van openbaar toegankelijke diensten), een basisstrategie die opnieuw relevant wordt in situaties waar gecentraliseerde identiteiten worden aangevallen.
  5. Bij vermoedens van compromittering: credentials wisselen, integraties met VPN/LDAP controleren en de integriteit van de configuraties toetsen voordat men op het apparaat vertrouwt.

De les voor 2026: cloud-identiteit als cruciale infrastructuur

Deze case onderstreept een gedachte die verder gaat dan Fortinet: wanneer een fabrikant cloudgebaseerde SSO een “sluiproute” maakt door het gebruiksgemak te verhogen, wint de sector in snelheid… maar vergroot het ook het risico. En wanneer zich een bypass voordoet, wordt het incident systemisch: het beïnvloedt niet slechts één machine, maar een wijze van opereren.

De eigen respons — het uitzetten van SSO op provider-niveau en heractiveren met versiesloten — toont de beweging tussen veiligheid, bedrijfskontin’lliteit en controle door de fabrikant. Voor veel organisaties is de onmiddellijke uitdaging technisch van aard (patchen en auditen), maar strategisch ligt de uitdaging in het ontwerpen van workflows die blijven functioneren, zelfs wanneer het centrale “brein” van cloud-authenticatie tijdelijk uitvalt.


Veelgestelde vragen

Hoe controleer ik of FortiCloud SSO actief is en waarom is dat zo kritiek bij CVE-2026-24858?
Omdat de beschreven exploitactiviteit wordt ausgelokt wanneer de beheerlogin via FortiCloud SSO actief is. De waarschuwingen raden aan dit expliciet te controleren, aangezien het tijdens registratie per ongeluk kan blijven ingeschakeld als de desbetreffende optie niet wordt uitgezet.

Welke versies van FortiOS moeten minimaal worden geïnstalleerd om FG-IR-26-060 te mitigeren?
Dat hangt af van de tak: de publieke richtlijnen noemen onder andere versies als 7.6.6, 7.4.11, 7.2.13 of 7.0.19 (of hoger), evenals vergelijkbare versies voor FortiManager en FortiAnalyzer.

Welke logs kunnen wijzen op misbruik van SSO en het aanmaken van admin-accounts voor persistentie?
Fortinet heeft indicatoren en voorbeeldlogs gedeeld die linken aan SSO-login en het toevoegen van lokale beheerders. Het is aanbevolen om logboekgegevens te correleren: “SSO-inlog” + “aanmaak admin” + “configuratie-export/download”.

Waarom heeft CISA de urgentie verhoogd en wat betekenen de datums in de KEV-katalogus?
Volgens NVD werd de CVE op 27 januari 2026 toegevoegd aan KEV en werd een mitigatiedeadline vastgesteld op 30 januari 2026 voor federale organisaties, wat wijst op actieve exploitatie en hoge prioriteit voor snelle mitigatie.

Bron: Fortinet schakelt FortiCloud SSO uit

Scroll naar boven