Fortinet poinformował 24 grudnia 2025 r., że zaobserwował „ostatnie nadużycia” pięcioletniej luki bezpieczeństwa w module SSL VPN FortiOS, która w określonych konfiguracjach pozwala ominąć dwuskładnikowe uwierzytelnianie (2FA). Chodzi o lukę oznaczoną jako CVE-2020-12812 (CVSS 5.2) — błąd niewłaściwej weryfikacji, powodujący, że użytkownik może zalogować się bez wymaganego drugiego czynnika, jeśli nazwa użytkownika zostanie wpisana z inną wielkością liter.
W skrócie: problem wynika z niespójnego traktowania wielkości liter między lokalnymi wpisami użytkowników na urządzeniu FortiGate a zdalnym katalogiem LDAP. Gdy w ustawieniach lokalnych włączone jest 2FA, a jednocześnie typ uwierzytelniania użytkownika odwołuje się do zdalnego źródła (np. LDAP), FortiGate może nie dopasować logowania zawierającego odmienne użycie wielkich i małych liter do lokalnego wpisu użytkownika. W takiej sytuacji urządzenie zaczyna sprawdzać inne skonfigurowane metody uwierzytelniania i może zakończyć proces pomyślną autoryzacją przeciwko LDAP bez wymogu 2FA.
Luka była już przedmiotem aktywnej eksploatacji w warunkach produkcyjnych przez różne grupy przestępcze, a administracja USA wymieniła ją wśród wielu słabości wykorzystywanych w atakach na urządzenia brzegowe w 2021 roku. Fortinet pierwotnie opisał problem w lipcu 2020 r., a obecne ostrzeżenie wskazuje na odnowione nadużycia wobec konstrukcji logowania, która pozwala na obejście zabezpieczeń w określonych scenariuszach konfiguracji.
Aby skutecznie wywołać opisane obejście uwierzytelniania, muszą być spełnione wszystkie poniższe warunki:
- na FortiGate istnieją lokalne wpisy użytkowników z włączonym 2FA, które odwołują się z powrotem do LDAP;
- ci sami użytkownicy muszą być członkami jednej lub więcej grup na serwerze LDAP;
- co najmniej jedna z grup LDAP, do której należą użytkownicy z 2FA, musi być skonfigurowana na FortiGate i używana w polityce uwierzytelniania (np. dla użytkowników administracyjnych, SSL VPN lub IPSEC VPN).
Gdy wymienione warunki są spełnione, zachowanie FortiGate powoduje, że wpisy LDAP użytkowników z włączonym 2FA są uwierzytelniane bezpośrednio przeciwko LDAP, zamiast weryfikacji lokalnej z 2FA. Fortinet tłumaczy to przykładem: jeśli lokalny użytkownik ma nazwę dokładnie „jsmith”, to próba logowania z wpisem „Jsmith”, „jSmith”, „JSmith”, „jsmiTh” lub inną kombinacją wielkości liter nie będzie dopasowana do lokalnego wpisu. W takiej sytuacji FortiGate przeszukuje pozostałe skonfigurowane opcje uwierzytelniania; znajdzie skonfigurowaną drugorzędną grupę (np. „Auth-Group”), zapyta LDAP i — jeśli dane uwierzytelniające są poprawne — zgodzi się na autoryzację, pomijając ustawienia lokalne, w tym 2FA i blokady konta.
W praktyce oznacza to możliwość zalogowania się użytkowników administracyjnych lub VPN bez wymagania drugiego czynnika, jeśli atakujący zna hasło i wykorzysta różnicę w traktowaniu wielkości liter. W lipcu 2020 r. Fortinet wydał poprawki w wersjach FortiOS 6.0.10, 6.2.4 i 6.4.1, które eliminowały opisywane zachowanie. Organizacje, które nie zainstalowały tych poprawek, mogą zastosować tymczasową konfigurację zapobiegającą obejściu uwierzytelniania, wykonując dla wszystkich lokalnych kont poniższe polecenie:
set username-case-sensitivity disable
Dla klientów korzystających z nowszych wersji FortiOS (6.0.13, 6.2.10, 6.4.7, 7.0.1 lub nowszych) zalecana jest inna komenda konfiguracyjna:
set username-sensitivity disable
Fortinet wyjaśnia, że po wyłączeniu czułości na wielkość liter urządzenie będzie traktować kombinacje liter takie jak jsmith, JSmith czy JSMITH jako równoważne, co zapobiega przełączaniu się na błędnie skonfigurowane grupy LDAP i w rezultacie blokuje opisane obejście. Dodatkową opcją ograniczającą ryzyko jest usunięcie drugorzędnej grupy LDAP, jeśli nie jest ona niezbędna — w takim przypadku nie będzie możliwości autoryzacji przez grupę LDAP i logowanie nie powiodłoby się, gdy nazwa użytkownika nie pasuje dokładnie do lokalnego wpisu.
W opublikowanej informacji Fortinet nie podał szczegółów dotyczących technik ataku ani nie potwierdził, czy zaobserwowane incydenty zakończyły się pomyślnym przejęciem dostępu. Firma zaleca klientom, którzy wykryją dowody na uwierzytelnianie administratorów lub użytkowników VPN bez 2FA, skontaktowanie się z zespołem wsparcia oraz zresetowanie wszystkich odpowiednich poświadczeń.