phpMyFAQ CVE-2026-111911: przejęcie konta przez WebAuthn. CVE przyszło dwa tygodnie po poprawce i opisuje jeden z kilkunastu problemów tego wydania

17 października 2026 VulnCheck opublikował CVE-2026-111911 dla phpMyFAQ: nieuwierzytelniony napastnik mógł dopisać własny klucz WebAuthn (passkey) do cudzego konta i zalogować się na nie z pominięciem hasła i TOTP. Ocena: 9.8 w CVSS 3.1 i 9.3 w CVSS 4.0. Poprawka jest jednak w wersji 4.1.9 z 3 października. Tego samego dnia producent zamknął kilkanaście innych problemów opisanych w GHSA, które CVE nie mają. Skaner oparty na CVE widzi więc jeden finding z celem „4.1.9”, choć właściwym celem jest 4.1.10. Do tego podatna ścieżka wymaga włączenia funkcji, która według zgłaszającego jest domyślnie wyłączona.

Na czym polega błąd

Rejestracja klucza WebAuthn to operacja na koncie: dopisuje nowy sposób logowania. W phpMyFAQ 4.0.0–4.1.8 endpointy rejestracji przyjmowały nazwę istniejącego użytkownika od anonimowej sesji, nie sprawdzały, czy wywołujący jest właścicielem konta, i nie weryfikowały wyzwania (challenge) wydanego przez serwer. Akceptowały też atestację typu fmt=none. Skutek opisany w GHSA: klucz napastnika zostaje zapisany na koncie ofiary, także administratora. Przetrwa zmianę hasła, a logowanie przez WebAuthn w ogóle nie sprawdza ustawienia TOTP. Szczegółów wykonania tu nie powtarzam. Dla obrony wystarczy wiedzieć, że atak nie wymaga interakcji ofiary i zostawia trwały ślad w danych konta.

GHSA-rg9h wskazuje też na rodowód błędu. Wcześniejsza poprawka (GHSA-w22q-m2fm-x9f4 / CVE-2026-27836, naprawiona w 4.0.18) zabezpieczyła tworzenie nowych kont przez WebAuthn, ale nie zablokowała dopisywania klucza, gdy podana nazwa należała do istniejącego konta. To kolejny przypadek z serii „patched” nie znaczy „naprawione”: jeśli w rejestrze zamknąłeś CVE-2026-27836 na 4.0.18, ta sama klasa ataku nadal działała.

CVE dwa tygodnie po poprawce. I tylko jedno

Producent publikuje zgłoszenia przez GitHub Security Advisories i własne komunikaty, ale numerów CVE dla nich nie przydziela. CVE-2026-111911 przydzielił VulnCheck, niezależny CNA, dwa tygodnie po wydaniu poprawki. Na liście GHSA projektu z 3 października jest kilkanaście pozycji dotyczących gałęzi 4.1 (stan z 20.10.2026), w tym kilka „high”. Według komunikatu producenta są wśród nich: pominięcie drugiego składnika przy logowaniu przez Keycloak i Microsoft Entra ID, przejęcie lokalnego konta przez zmienny claim preferred_username w Entra ID, niejawne łączenie kont w Keycloak, zmiana adresu e-mail bez podania hasła i wyciek sekretu TOTP innych użytkowników przez API administracyjne. Żadna z tych pozycji nie miała 20 października numeru CVE w GHSA.

Konsekwencja dla VM: jeśli Twój proces startuje od CVE, phpMyFAQ 4.1.8 wyglądał do 17 października na czysty, a od 17 października wygląda na problem z jednym CVE i celem „4.1.9”. Oba obrazy są błędne. Dla projektów, które publikują głównie przez GHSA, potrzebne jest źródło spoza NVD: feed GHSA (OSV), subskrypcja komunikatów producenta albo monitoring wydań. Ten sam problem opisywałem przy Nextcloud z Collabora CODE, gdzie poprawka wyprzedziła CVE o miesiąc.

Warunek konfiguracyjny: argument do VEX, ale nie do wstrzymania aktualizacji

Wektor CNA ma AT:N, czyli brak warunków wstępnych. Tymczasem GHSA-g6cq wymienia jako warunek włączenie security.enableWebAuthnSupport, które jest domyślnie wyłączone. Rekord CVE tego nie odnotowuje. Dla instancji z wyłączonym WebAuthn rzeczywiste ryzyko tego CVE jest znacznie niższe niż 9.8.

Ostrożność wobec argumentu „u nas tego nie włączaliśmy” jest zdrowa, ale tutaj warunek jest w GHSA nazwany wprost, więc da się go sprawdzić, a nie tylko zadeklarować. Proponuję taki podział:

• WebAuthn wyłączony (sprawdzona wartość w konfiguracji, nie deklaracja): dla CVE-2026-111911 możesz wystawić VEX ze statusem not_affected i uzasadnieniem w rodzaju „wymaga konfiguracji” (w CycloneDX: requires_configuration). Zapisz datę i sposób weryfikacji. Ktoś może tę funkcję włączyć jutro.
• WebAuthn włączony: Critical bez dyskusji, do tego przegląd kluczy (niżej).
• W obu przypadkach aktualizacja do 4.1.10. VEX dotyczy jednego CVE. Pozostałe problemy z 3 i 9 października nie zależą od WebAuthn, a część dotyczy SSO, które w firmowych wdrożeniach jest częstsze niż passkeys.

Wersja docelowa i gałąź EOL

4.1.10 jest celem, bo zamyka także problemy z 9 października. Dodam jeden szczegół z polityki wsparcia producenta: gałąź 4.0.x jest EOL od 12 marca 2026, a 4.1.x ma wsparcie do 12 marca 2027. CVE obejmuje wersje od 4.0.0, więc instalacje 4.0.x są podatne bez poprawki w gałęzi. Migracja do 4.1 wymaga PHP 8.3 lub nowszego, co dla starszych serwerów oznacza zmianę platformy, a nie zwykły ticket. Zapisz to jako finding EOL z własnym terminem, tak jak opisywałem przy UpTrain.

Po aktualizacji: klucze zostają

Poprawka blokuje dopisywanie nowych kluczy. Nie usuwa kluczy dopisanych wcześniej. GHSA podkreśla, że wstrzyknięte poświadczenie zostaje na koncie, dopóki ktoś go jawnie nie usunie. Jeśli WebAuthn był włączony, a instancja była osiągalna z internetu:

1. Przejrzyj klucze WebAuthn przypisane do kont uprzywilejowanych (administratorzy, redaktorzy). Według GHSA-rg9h klucze trafiają do danych konta (pole webauthnkeys). Klucz, którego właściciel konta nie rozpoznaje, to sygnał incydentu.
2. Przejrzyj logi serwera WWW pod kątem wywołań endpointów rejestracji WebAuthn z anonimowych sesji. Same endpointy wynikają z GHSA. Nie podaję ich jako sygnatury, bo każde wdrożenie loguje inaczej.
3. Po każdym podejrzeniu: unieważnij sesje, usuń nieznane klucze, sprawdź zmiany w treściach i konfiguracji. Przy okazji zweryfikuj adresy e-mail kont, bo jeden z problemów z 3.10 pozwalał je zmieniać bez hasła.

Co powinien zrobić VE

1. Inwentarz wszystkich instancji phpMyFAQ (także obrazy kontenerów i środowiska testowe) z wersją i wartością security.enableWebAuthnSupport.
2. Jeden ticket na produkt, nie na CVE: cel 4.1.10, uzasadnienie: CVE-2026-111911 plus advisory z 3.10 i 9.10. Bez tego po kolejnym CVE od zewnętrznego CNA otworzysz ticket ponownie.
3. VEX dla CVE-2026-111911 tylko tam, gdzie WebAuthn jest sprawdzalnie wyłączony. Aktualizacji nie wstrzymuj.
4. 4.0.x: finding EOL z planem migracji (PHP 8.3+).
5. Źródła sygnałów: dodaj GHSA projektu do monitoringu. Dla phpMyFAQ samo NVD nie wystarczy.

Powiązane na blogu

• pgAdmin 9.17 i trzy incomplete fixy — kiedy „patched” nie znaczy „naprawione”
• Zitadel: fala podatności w systemie tożsamości — błędy w ścieżkach uwierzytelniania jako jeden pakiet
• Nextcloud + Collabora CODE — poprawka miesiąc przed CVE
• UpTrain: EOL jako finding — gdy gałąź nie dostanie poprawki
• Apache FreeMarker — co powinien opisywać VEX

Źródła

• CVE.org — CVE-2026-111911 (CNA VulnCheck, CWE-287, zakres 4.0.0 do <4.1.9, CVSS 4.0 i 3.1) — cve.org
• NVD — CVE-2026-111911 (status Deferred) — nvd.nist.gov
• GitHub — GHSA-g6cq-6rqg-6c9p (WebAuthn credential injection, warunki, w tym niedomyślne enableWebAuthnSupport) — github.com
• GitHub — GHSA-rg9h-f29v-xhxr (WebAuthn enrollment, związek z GHSA-w22q-m2fm-x9f4 / CVE-2026-27836) — github.com
• GitHub — lista security advisories projektu phpMyFAQ — github.com
• phpMyFAQ — Security Advisory 2026-10-03 (≤ 4.1.8, Critical, lista problemów) — phpmyfaq.de
• phpMyFAQ — Security Advisory 2026-10-09 (≤ 4.1.9, High, wersje 4.1.10 i 4.2.0-beta.2) — phpmyfaq.de
• phpMyFAQ — strona pobierania (4.1.10 z 09.10.2026 jako wersja stabilna, wymagania PHP 8.3+) — phpmyfaq.de
• phpMyFAQ — polityka bezpieczeństwa i wsparcia (4.1.x do 2027-03-12, 4.0.x EOL 2026-03-12) — phpmyfaq.de
• CISA Known Exploited Vulnerabilities Catalog (brak CVE-2026-111911 w wersji 2026.10.21) — cisa.gov

Nota redakcyjna: wpis powstał na podstawie szkicu VMRT Radar z 19 października 2026 i został zweryfikowany ze źródłami pierwotnymi 20 października 2026 (ok. 19:15 CEST): rekord CVE.org (CNA VulnCheck, daty, CWE-287, zakres wersji, wektory CVSS), NVD API 2.0 (status „Deferred”), GHSA-g6cq-6rqg-6c9p i GHSA-rg9h-f29v-xhxr oraz lista GHSA projektu przez GitHub API (daty publikacji, puste pole CVE, warunki), komunikaty producenta z 03.10 i 09.10.2026, strona pobierania i polityka wsparcia phpMyFAQ, katalog CISA KEV 2026.10.16 (brak wpisu) i API EPSS (0,00422). 22 października 2026 (ok. 22:40 CEST) ponownie sprawdziłem KEV: w katalogu 2026.10.21 nadal brak wpisu. Względem szkicu poprawiłem opis warunku: według GHSA atak wymaga niedomyślnego włączenia WebAuthn, więc konfigurację da się sprawdzić i użyć w VEX. Dodałem też datę poprawki (4.1.9 z 03.10), EOL gałęzi 4.0.x i rodowód z CVE-2026-27836. Nie potwierdziłem: wykorzystania w atakach ani masowego skanowania, tego, czy któreś gotowe obrazy lub dystrybucje włączają WebAuthn domyślnie, czy gałąź 4.0.x dostała jakikolwiek backport ani czy pozostałe GHSA dostaną numery CVE. Liczba GHSA („kilkanaście”) odnosi się do listy z 20.10.2026 i może się zmienić. Podział na VEX i ticket oraz zalecenia po aktualizacji to oceny autora.