Po přesměrování na adresu se jménem a heslem poslal curl lístek Kerberos cizímu serveru

Když server odpoví přesměrováním jinam, curl za ním jde, ale přihlašovací údaje si nechá u sebe. Je to jeho vlastní pojistka a dokumentace volby CURLOPT_UNRESTRICTED_AUTH ji popisuje doslova: dokud se nezapne, knihovna „neposílá vlastní ani vnitřně vytvořené hlavičky Authorization: a Cookie: v požadavcích na jiné hostitele, než jaký byl v původní adrese“ (překlad z anglického originálu). Za jiného hostitele se počítá i změna schématu nebo čísla portu. Na příkazové řádce tutéž pojistku vypíná přepínač --location-trusted.

Ve dvou vydáních ta pojistka nedržela. Projekt to 14. října popsal v oznámení k chybě CVE-2026-94265 a týž den vydal opravenou verzi 8.23.0. Útočníkovi stačilo poslat přesměrování na adresu, ve které stojí jméno a heslo, a curl se na jeho serveru přihlásil protokolem Kerberos pod totožností toho, kdo ho spustil.

Podmínka se ptala na špatnou věc

Celou chybu drží jediný řádek v souboru lib/http.c, který rozhoduje, jestli se mají vůbec sestavovat ověřovací hlavičky:

if(data->state.creds || Curl_auth_allowed_to_host(data))

Levá strana se ptá, jestli jsou po ruce nějaké přihlašovací údaje. Pravá strana se ptá, jestli je klient pořád na původním stroji. Mezi nimi je ale „nebo“, takže stačilo splnit jednu z podmínek. Nálezce Joshua Rogers z Aisle Research to ve svém hlášení na HackerOne shrnul tak, že podmínka se ptá „mám nějaké přihlašovací údaje?“ ve chvíli, kdy se má ptát „jsem pořád na původním stroji?“ (překlad z anglického originálu).

Postup útoku má pět kroků:

1. Uživatel spustí curl --negotiate -L http://intranet/ a žádné heslo nezadává, protože Kerberos pracuje s lístkem, který už v systému je.
2. Server intranet odpoví přesměrováním na http://bob:alice@utocnik.example/.
3. curl správně zahodí údaje uživatele, protože se změnil stroj. Jenže vzápětí si z adresy útočníka vytáhne dvojici bob:alice a uloží si ji. Tahle cesta žádnou kontrolu původu nemá.
4. Podmínka vidí uložené údaje, projde levou stranou a na kontrolu původu se už nikdo nezeptá.
5. Spustí se větev pro Negotiate. Ta bob:alice zahodí, protože je nepotřebuje, a vyžádá si u distribučního centra klíčů nový lístek. Jméno služby přitom skládá z aktuální adresy, tedy z útočníkova jména.

Rogers na tom upozorňuje na jednu zvláštnost: přihlašovací údaj, který se nikdy nepoužije, odemkne ověření, které žádné přihlašovací údaje nepotřebuje. Jediný úkol dvojice bob:alice je nebýt prázdná.

Co útočník dostane

Výsledkem není přeposlaná hlavička z prvního serveru, ale celé nové přihlášení provedené na cizí účet. Útočník drží dlouhodobý klíč ke službě, na kterou přesměroval, takže si lístek rozšifruje a zjistí z něj ověřenou totožnost oběti. Rozsah úniku proto není omezený tím, co klient poslal předtím.

Dvě další možné dohry nálezce v hlášení zmiňuje, ale výslovně píše, že je nepředvedl, a nejsou proto ani ve známce závažnosti: se zapnutou volbou CURLOPT_GSSAPI_DELEGATION je lístek přeposílatelný dál a na Windows s rozhraním SSPI se u neznámé služby přechází na NTLM, který se dá přehrát jinam.

Sám projekt curl hodnotí chybu jako nízkou a vede ji pod označením CWE-200, tedy vyzrazení citlivé informace neoprávněné straně. Kdo nemůže hned povýšit, má podle oznámení buď nasadit samotnou opravu, nebo při použití Negotiate nenásledovat přesměrování.

Jak se to ověřilo

Hlášení obsahuje skript, který postaví jednorázovou kerberovskou doménu nad MIT krb5, přihlásí v ní uživatele a spustí proti dvěma místním serverům jediný příkaz curlu. Obě varianty jsou shodné, liší se jen tím, jestli v přesměrování stojí jméno s heslem. S ním dostal server útočníka hlavičku Negotiate o 1 060 znacích a v lístku stála služba HTTP/attacker.poc.test v doméně POC.TEST. Bez něj nepřišla žádná hlavička.

Koho se to týká

Zranitelné jsou verze 8.21.0 z 24. června a 8.22.0 z 2. září, nic staršího a nic novějšího. Mez zdola určuje commit z 11. května, který přesunul přihlašovací údaje do společné struktury Curl_creds a sáhl přitom na sedmačtyřicet souborů. Právě s ním se do podmínky dostala levá strana.

Linuxové distribuce vyvázly různě. Debian u sebe eviduje jako zranitelný jen balíček 8.22.0-1 ve vývojové větvi forky; ve větvi sid je už 8.23.0-1 a stabilní trixie s bookwormem mají starší curl, ve kterém vadný kód není.

Oprava sáhla i na NTLM

Opravný commit z 21. září má deset přidaných řádků a jmenuje se „http: only enable Negotiate/NTLM to allowed origins“. Do větve pro Negotiate přidává chybějící volání Curl_auth_allowed_to_host(). U NTLM je zásah větší, protože tam kontrola původu nebyla vůbec žádná; nově se hlavička sestaví jen pro proxy nebo pro povolený původ.

Od nahlášení k opravě to trvalo tři dny: Rogers chybu poslal 18. září a patch, který projekt nakonec převzal, napsal taky on. Mezi opravou a veřejným oznámením pak uplynuly tři týdny, protože se vydání sladilo s dalšími chybami.

Zbytek vydání

S verzí 8.23.0 vyšly ještě tři další záznamy. CVE-2026-94266 vracelo v CURLINFO_EFFECTIVE_URL adresu i s přihlašovacími údaji, které v zadané ani v cílové adrese nebyly. CVE-2026-107928 čte u sestavení s GnuTLS paměť za odesílacím zásobníkem, když knihovna po zablokovaném zápisu ohlásí víc odeslaných bajtů, než kolik jich dostala. A CVE-2026-107929 nepočítalo vazbu na konkrétní rozhraní do klíče, podle kterého se znovu používají spojení, takže přenos mohl odejít z jiné zdrojové adresy, než jaká se žádala. Stejné vydání zároveň zahodilo podporu protokolu SMB.

Zdroje

• curl: Authorization: Negotiate sent to foreign origin (CVE-2026-94265)
• HackerOne: hlášení 4040551 včetně postupu ověření
• curl: Changes in 8.23.0
• GitHub: opravný commit 557a52f
• Debian Security Tracker: CVE-2026-94265
• libcurl: CURLOPT_UNRESTRICTED_AUTH