Вразливість високого рівня небезпеки в Node.js-пакеті urllib може передати заголовки автентифікації іншому origin, коли застосунок автоматично переходить за HTTP-редиректом. CVE-2026-55553 зачіпає urllib до версії 4.9.0 включно та стару гілку 2.x до 2.44.0 включно. Виправлення вийшли у версіях 4.9.1 і 2.44.1.
Йдеться про npm-клієнт urllib для Node.js, а не про стандартну бібліотеку Python urllib чи Python-пакет urllib3. Наявність уразливої версії сама по собі не доводить витік: застосунок має надіслати додані викликачем облікові дані, перейти за редиректом і потрапити до іншої схеми, хоста або порту.
Кого стосується CVE-2026-55553?
Розробникам і адміністраторам потрібно перевірити Node.js-сервіси, workers, інструменти збирання й автоматизацію, які використовують urllib прямо або через іншу залежність. Найвищий ризик мають запити з bearer-токенами, cookies, proxy credentials, API-ключами чи іншими власними заголовками автентифікації, якщо клієнт автоматично переходить за редиректами.
| Установлена версія | Ризик і потрібна дія |
|---|---|
urllib від 3.0.0 до 4.9.0 | Уразлива. Оновіть до 4.9.1 або новішої. |
urllib 2.44.0 або старіша | Уразлива стара гілка. Оновіть до 2.44.1 або після перевірки сумісності перейдіть на підтримувану гілку 4.x. |
Python urllib або urllib3 | Ця CVE їх не стосується. Перевіряйте ці проєкти за їхніми власними бюлетенями. |
Запустіть npm ls urllib у кожному розгорнутому проєкті та перевірте точну версію у lockfile. Залежність може бути транзитивною, тому пакет іноді присутній, хоча його немає у верхньому рівні package.json.
Як редирект може розкрити облікові дані
За даними бюлетеня, під час переходу за редиректом urllib повторно використовував початкові параметри запиту. До виправлення редирект на інший origin міг зберегти заголовки Authorization, Cookie, Proxy-Authorization, x-api-key, x-auth-token і x-access-token.
Реалістичний сценарій починається з автентифікованого запиту до надійного API партнера. Якщо endpoint, проміжний вузол, неправильно налаштований CDN або upstream open redirect поверне адресу, яку контролює інша сторона, уразливий клієнт може відправити туди початкові заголовки. Дія кінцевого користувача не потрібна, але зловмиснику все одно потрібен шлях редиректу через межу довіри застосунку.
Це проблема конфіденційності, а не доказ віддаленого виконання коду чи зламаного npm-релізу. GitHub оцінив її як high severity із CVSS 3.1 на рівні 7,5. У публічному бюлетені немає повідомлення про активну експлуатацію.
Що потрібно зробити розробникам
- Визначте точний шлях залежності. Перевірте production services, workers, CI jobs та внутрішні інструменти командою
npm ls urllib. Запишіть пряму або транзитивну батьківську залежність і фактичну версію у lockfile. - Оновіть уразливу гілку. Для 4.x потрібна щонайменше 4.9.1, для старої 2.x — щонайменше 2.44.1. Зберіть проєкт із перевіреного lockfile і протестуйте редиректи, proxy та автентифікацію до розгортання.
- Знайдіть міждоменні редиректи. Визначте виклики, які поєднують автоматичні редиректи з обліковими даними. Зміну схеми, hostname або порту вважайте зміною origin, навіть якщо обидві адреси належать одному постачальнику.
- Перевірте докази до масової ротації. Збережіть application, proxy, DNS, egress і partner logs за можливий період витоку. Шукайте перенаправлені запити до неочікуваних origin, але не додавайте самі секрети до нових журналів.
- Відкличте облікові дані, які могли перетнути межу. Якщо журнали підтверджують або переконливо вказують, що запит із credential headers дістався недовіреного origin, вимкніть відповідний token, cookie, API key або proxy credential. Перевірте подальше використання й зміни пов’язаного облікового запису. Оновлення пакета не відкликає секрет, який уже витік.
- Обмежте редиректи як додатковий захист. Поки не оновлені всі deployments, вимкніть автоматичні редиректи там, де це можливо, або дозволяйте лише явно схвалені destination origins. Формуйте sensitive headers окремо для кожної адреси замість перенесення одного набору через межі довіри.
Якщо API-ключ міг витекти, інструкція з реагування на викрадення API-ключів пояснює, як зберегти дані про використання, відкликати значення та перевірити, хто може створити новий ключ. Для витоку секретів через залежності чекліст щодо Keyv-хробака у npm показує, чому прямих залежностей і поточного стану registry недостатньо для оцінки проєкту.
Чого не слід припускати
- Уразлива версія
urllibпідтверджує можливість витоку, але не доводить, що редирект або передавання облікових даних уже сталися. - HTTPS захищає запит під час передавання, але не робить контрольований зловмисником destination origin дозволеним одержувачем.
- Ротація всіх секретів організації без визначення шляху редиректу може знищити корисні докази й спричинити зайві збої.
- Чистий результат перевірки endpoint на malware не визначає, чи серверний HTTP-клієнт відправив заголовок іншому origin.
Джерела
- Проєкт node-modules. «urllib: Cross-origin redirects preserve credential-bearing request headers, leading to potential credential leakage». GitHub Security Advisory GHSA-hq3h-g68c-hp78, опубліковано 25 серпня 2026 року. Первинний бюлетень.
- Програма CVE. «CVE-2026-55553». CVE Record, опубліковано 25 серпня 2026 року; дата звернення: 25 серпня 2026 року. Уражені версії та оцінка CVSS.
