Критична вразливість CVE-2026-76504 у Cisco SD-WAN Manager: обхід аутентифікації через один закодований символ

Cisco опублікувала 30 вересня 2026 року критичний security advisory про вразливість CVE-2026-76504 у Cisco Catalyst SD-WAN Manager — централізованій консолі, з якої адміністратори керують усією SD-WAN-мережею підприємства. Один закодований символ у шляху HTTP-запиту дозволяє неавтентифікованому зловмиснику отримати доступ до API з правами адміністратора — без жодного пароля. Найгірше: вразливість уже активно експлуатується в реальних атаках.

Це той випадок, коли «проста» помилка обробки введення масштабується до повної компрометації корпоративної мережі. У цьому матеріалі розбираємо, як саме працює обхід аутентифікації, чому вразливість отримала максимальний бал критичності, які ознаки компрометації шукати в логах і як захиститися.

Що сталося

Cisco Catalyst SD-WAN Manager (раніше — SD-WAN vManage) — це головна панель керування SD-WAN-інфраструктурою. В одних розгортаннях вона моніторить і конфігурує кілька пристроїв, в інших — до кількох тисяч мережевих пристроїв з однієї консолі. Компрометація такого інструмента означає не втрату однієї машини, а потенційний контроль над усією мережею організації.

Вразливість отримала ідентифікатор CVE-2026-76504, класифікована як CWE-177 — Improper Handling of URL Encoding (некоректна обробка URL-кодування) — і оцінку CVSS 9.8 за шкалою Critical. За даними Cisco Product Security Incident Response Team (PSIRT), активну експлуатацію вразливості зафіксували у вересні 2026 року. Вектор атаки `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` означає максимально просту для зловмисника атаку з максимально тяжкими наслідками.

Показово, що проблему виявили не дослідники і не через баг-баунті, а під час розбору звичайного support-кейсу в Cisco Technical Assistance Center (TAC). Іншими словами, до моменту офіційного розкриття вразливість уже використовували в живих атаках проти реальних організацій. У бюлетені вказано bug ID CSCww79570, а сам advisory має статус Final версії 1.0.

Чому SD-WAN — і чому це важливо для бізнесу

SD-WAN (software-defined wide area network) — це підхід, який дозволяє будувати гнучкі, керовані програмно корпоративні мережі поверх різних каналів звʼязку: MPLS, звичайного інтернету, LTE/5G. Компанії обирають SD-WAN за зниження витрат, централізоване керування та швидке розгортання нових точок.

Але централізація має і зворотний бік: усі політики, маршрутизація, VPN-тунелі та правила безпеки сходяться в одному місці — у контролері та менеджері керування. Той, хто отримує контроль над менеджером, фактично отримує контроль над тим, як трафік організації рухається мережею. Саме тому мережеві консолі керування стають дедалі привабливішою ціллю для атакуючих: один успішний обхід аутентифікації може дати більше, ніж тижні фішингу на окремих співробітників.

Як працює обхід аутентифікації

Вразливість знаходиться в механізмі session-based authentication API менеджера. Суть у тому, що система некоректно обробляє URI-кодування (percent-encoding) у вхідному HTTP-запиті.

Практично це виглядає так. У системі є захищена кінцева точка аутентифікації — login-handler зі шляхом `/j_security_check`. Атакуючий надсилає запит, у якому один символ закодовано: замість `j` він передає `%6a` — це той самий символ «j», але в percent-encoded вигляді. Запит стає `POST /%6a_security_check`.

Через некоректну обробку кодування правило аутентифікації, яке мало б захищати цю кінцеву точку, не збігається з шаблоном і не спрацьовує. Запит проходить далі без перевірки облікових даних — і атакуючий отримує доступ до API з правами адміністратора.

Важлива деталь, яку підкреслює Cisco: у прикладі використано `%6a` лише для ілюстрації. Вразливість спрацьовує з будь-яким одним закодованим символом у запиті, тому пошук лише по `%6a` не дасть повної картини компрометації.

Ключовий факт: вразливість діє незалежно від конфігурації системи. Немає жодного тумблера чи налаштування, яке б прибрало експозицію, — вразливі всі розгортання, де встановлена уражена версія. Це відрізняє дану проблему від багатьох інших, де вразливість проявляється лише за певної конфігурації.

Чому це критично: CVSS 9.8 і масштаб наслідків

Оцінка CVSS 9.8 — це практично максимум шкали. Вона означає: атака йде по мережі, не потребує жодних привілеїв та взаємодії користувача, а наслідки — повна компрометація конфіденційності, цілісності та доступності.

Що це означає на практиці, коли зловмисник отримує адміністративний доступ до API:

• перегляд і зміна конфігурації всіх SD-WAN-пристроїв, якими керує цей екземпляр менеджера;
• створення нових облікових записів із повними правами;
• перегляд, зміна або видалення даних;
• установлення програм і подальше закріплення в інфраструктурі.

Це не «вразливість одного сервісу». Через консоль керування атакуючий може змінювати маршрутизацію, VPN-тунелі та політики безпеки, перехоплювати трафік або готувати ґрунт для повного виведення мережі з ладу. MITRE ATT&CK класифікує вектор як Initial Access (TA0001) через техніку Exploit Public-Facing Application (T1190) — тобто це точка входу, з якої починається повноцінна атака.

За оцінкою Центру інтернет-безпеки (CIS/MS-ISAC), рівень ризику для державних установ і бізнесу будь-якого розміру — високий (HIGH): вразливість не вимагає жодної попередньої підготовки та спрацьовує навіть на мінімально сконфігурованих системах. Лише для домашніх користувачів ризик оцінено як низький, оскільки такий продукт у них практично не зустрічається.

Ознаки компрометації: що шукати в логах

Cisco опублікувала конкретні індикатори компрометації (IoC). Оскільки атака проходить через запити до login-handler із закодованими символами, головна ознака — звернення до `j_security_check` від невідомих IP-адрес.

Перевірте два лог-файли:

1. `/var/log/nms/containers/service-proxy/serviceproxy-access.log` — шукайте записи до `j_security_check` від невідомих або неавторизованих IP-адрес.
2. `/var/log/nms/vmanage-server.log` — шукайте виклики `j_security_check` для користувачів, імена яких починаються з `viptela-reserved-`. Це системні службові акаунти, і їх поява в таких записах — сильний індикатор зловживання.

Приклад підозрілого запису з логу:

POST /%6a_security_check HTTP/1.1

Памʼятайте: такі записи можуть виникати й під час штатної роботи, тому Cisco радить звіряти знахідки зі звичайною поведінкою мережі, щоб уникати хибних спрацювань. Якщо ви виявили сліди — збережіть криміналістичні докази (команда `request admin-tech`) до оновлення і відкрийте кейс у Cisco TAC з ідентифікатором CVE-2026-76504 у темі. Чим довше зберігаються логи, тим більше шансів відновити повну картину інциденту, тому логування варто виводити на зовнішній сервер.

Які версії вразливі та як оновитися

Вразливі всі версії Cisco Catalyst SD-WAN Manager, незалежно від конфігурації. Workaround не існує — єдине повноцінне рішення це оновлення до фіксованого релізу.

Таблиця перших виправлених версій:

Для хмарного середовища Cisco SD-WAN Cloud (Cisco Managed) виправлення випущено в релізі 20.15.605 — дій від користувача не потрібно, патч уже застосовано на боці Cisco. Користувачі цієї версії можуть перевірити статус оновлення через функцію Help в інтерфейсі сервісу.

Оскільки експлуатація вже підтверджена, оновлення слід розглядати як термінове розгортання поза звичайним циклом патч-менеджменту, а не як рядове оновлення.

Як захиститися до оновлення

Поки оновлення не встановлено, Cisco рекомендує максимально зменшити експозицію системи:

• Обмежити доступ до менеджера з незахищених мереж, зокрема з інтернету.
• Якщо доступ з інтернету потрібен — дозволити його лише відомим довіреним хостам.
• Захистити Cisco Catalyst SD-WAN Control Components за фільтрувальним пристроєм (файрволом), в ідеалі — двошаровим, щоб кінцеві користувачі не підключалися безпосередньо до зовнішньої DMZ-зони.
• Надсилати логи на зовнішній сервер і зберігати їх достатньо довго, щоб можна було провести розслідування після інциденту.
• Змінити стандартний пароль адміністратора та створити окремі облікові записи за принципом найменших привілеїв.

Детальні рекомендації зібрано в Cisco Catalyst SD-WAN Hardening Guide. Окремо варто подбати про базову кібергігієну команди, яка адмініструє мережу, — навчання персоналу знижує ймовірність того, що інша вразливість чи фішинг стануть точкою входу. Докладніше про це — у нашому матеріалі «Кібербезпека: навчання та освіта».

Повний перелік захисних дій, які рекомендують Cisco та CIS/MS-ISAC, виглядає так:

• Сегментація мережі — фізично й логічно ізолюйте критичні системи, щоб консоль керування не була досяжною із загального периметра. Використовуйте DMZ для інтернет-сервісів.
• Принцип найменших привілеїв — запускайте сервіси без адміністративних прав і вимкніть або перейменуйте стандартні облікові записи.
• Інвентаризація службових акаунтів — ведіть реєстр сервісних акаунтів (як-от `viptela-reserved-*`) і регулярно перевіряйте, що всі вони авторизовані.
• Сканування вразливостей — регулярні автентифіковані та неавтентифіковані скани внутрішніх активів, щоб вчасно знаходити незалатані системи.
• Пентестування зовнішнього периметра — не рідше ніж раз на рік перевіряйте, чи можна з інтернету дістатися до критичних точок керування.
• Збереження доказів — до оновлення зніміть адміністративну діагностику на будь-якому експонованому екземплярі, щоб не втратити сліди можливої компрометації.

Уроки: консолі керування як привілейована ціль

Цей інцидент варто розглядати не як одиничну помилку одного вендора, а як частину ширшої тенденції. Консолі централізованого керування — чи то SD-WAN-менеджери, чи контролери мережевого доступу, чи оркестратори хмарної безпеки — мають спільну властивість: вони дають величезні повноваження з однієї точки. Це робить їх привабливою мішенню, а кожен обхід аутентифікації в такій системі одразу стає критичним.

Практичний висновок для команд безпеки простий: системи керування мережею слід ставитися до окремого класу активів із посиленим захистом. Це означає обовʼязкову сегментацію мережі, щоб консолі керування не були доступні із загального периметра, постійний моніторинг API-логів, регулярне пентестування зовнішнього периметра та готовність до термінового патчування без звичайних вікон обслуговування. Саме терміновість — ключовий урок: коли вразливість уже експлуатують «у дикій природі», звичний графік оновлень не працює.

Висновок

CVE-2026-76504 — чергове нагадування про те, наскільки небезпечними бувають «дрібні» помилки обробки введення. Один закодований символ у шляху запиту відкрив зловмисникам повний адміністративний доступ до консолі керування мережею — без пароля, без привілеїв, без взаємодії з користувачем.

Для українських компаній, які використовують Cisco SD-WAN, це прямий привід: перевірити версії, переглянути логи на наявність ознак компрометації та встановити оновлення. Оскільки workaround немає, зволікання означає ризик повної компрометації мережі. А якщо ви підозрюєте, що дані вашої організації вже могли потрапити у відкритий доступ, — перевірте це за допомогою нашого інструмента перевірки витоків.