Cisco ISE Zero-Day отримує оцінку 10.0 CVSS — CISA фіксує активну експлуатацію

У середу, 17 вересня, Cisco випустила патч для zero-day вразливості з оцінкою 10.0 CVSS у своєму Identity Services Engine, і того ж дня CISA додала її до каталогу Known Exploited Vulnerabilities. Одночасне внесення до KEV — це головний сигнал: експлуатація не є теоретичною, і захисники мали практично нульове вікно між розкриттям інформації та вказівкою розглядати це як активний інцидент.

Математика тут має зупинити платформні команди. CVE-2026-76460 — це третій обхід автентифікації в API з максимальною або близькою до максимальної оцінкою CVSS, який Cisco випустила за сім місяців: 10.0 у лютому в зоні SD-WAN Manager (CVE-2026-20129 з оцінкою 9.8), 10.0 у Secure Workload (CVE-2026-20223) у травні, і тепер 10.0 в ISE. Три збіги з однаковим типом уразливості — це закономірність, а не випадковість.

Що сталося

Згідно з Dark Reading, CVE-2026-76460 — це обхід автентифікації в API-ендпоінті Cisco Identity Services Engine, продукту, який Cisco позиціонує як рішення для контролю мережевого доступу та zero-trust. У власному повідомленні Cisco першопричиною названо «недостатній контроль автентифікації» в API-ендпоінті ISE, а експлуатація описана як надсилання спеціально сформованого запиту до цього ендпоінту для обходу веб-інтерфейсу управління.

Успішна експлуатація надає неавтентифікованому віддаленому зловмиснику права root та можливість виконання команд. Без облікових даних, без взаємодії з користувачем, без будь-яких передумов конфігурації: вразливість стосується ISE та ISE-PIC незалежно від налаштувань пристрою. Cisco випустила патчі для версій 3.1–3.5. Версія 3.0 знаходиться на стадії завершення підтримки і не отримає виправлення; відповідним клієнтам рекомендовано перейти на новішу версію.

Рішення CISA додати CVE до каталогу KEV того ж дня, коли вразливість була розкрита, заслуговує на увагу. Федеральні цивільні відомства тепер мають жорсткий дедлайн для усунення. Зазвичай це відбувається після певного вікна спостережуваної експлуатації в реальних умовах; тут це відбулося одночасно з розкриттям, що означає: CISA мала телеметрію або достовірні звіти ще до публічного виходу патча.

Cisco також розкрила та виправила кілька інших помилок в ISE та ISE-PIC зі схожими проблемами автентифікації API. Компанія не відповіла на запит Dark Reading щодо коментарів. Того, чого ми не знаємо — а це важливо, — хто саме експлуатує вразливість і в якому масштабі. Верхня межа кількості жертв — це фактично вся встановлена база ISE версій 3.1–3.5 за вирахуванням тих, хто встановив патч протягом 48 годин, а для корпоративної identity-інфраструктури цей показник історично невеликий.

Технічна анатомія

Механізм тривіальний — і це якраз і є проблемою. Йоганнес Ульріх, засновник SANS Internet Storm Center, сказав Dark Reading, що «відсутність автентифікації для API-ендпоінтів — це загальногалузева проблема», і вказав на конкретну патологію: «API, які раніше не були безпосередньо доступні ззовні, тепер відкриті, і в процесі цього належний контроль автентифікації та доступу пропускається». Це «легко трапляється, коли більш розширені API відкриваються для підтримки сучасніших інтерфейсів веб-застосунків».

У термінах розробки: внутрішній RPC або ендпоінт лише для адміністраторів переходить на поверхню публічного API, щоб живити новий дашборд, односторінковий застосунок або хук автоматизації. Middleware автентифікації, яке захищало стару поверхню, не завжди переноситься разом. У монолітних продуктах з десятиліттями накопиченого коду маршрутизації питання про те, чи виконується конкретний обробник після перевірки сесії чи до неї, стає питанням, на яке ніхто не може відповісти, не читаючи конфіг роутера рядок за рядком. Це територія OWASP Broken Access Control, яка є категорією ризику №1 для веб-застосунків уже кілька років поспіль.

Масштаб наслідків — це те, що перетворює цей баг із серйозного на системний. ISE — не листовий вузол. Емма Стівенс, старший радник із розвідки загроз у Bitsight, написала в аналітичній записці компанії, що ISE «допомагає визначати, які користувачі та пристрої можуть підключатися до мережі та до чого вони можуть отримати доступ після підключення», а «root-доступ до цієї інфраструктури може створювати ризики для видимості, цілісності та доступності в набагато ширшому середовищі». Ульріх висловив ту саму думку більш прямо: інші API Cisco використовують ISE для прийняття рішень щодо автентифікації та контролю доступу, тому компрометація ISE дозволяє зловмиснику вимкнути рішення, отримати доступ до мереж, які воно захищає, або видавати себе за інші хости. Його аналогія: «Це як замінити охоронця будівлі самозванцем».

Існує більш неприємний ефект другого порядку. Повідомлення Cisco зазначає, що успішна експлуатація дає зловмисникам можливість видаляти або приховувати докази експлуатації та індикатори компрометації на самому пристрої. Саме тому компанія прямо рекомендує перевіряти мережеві логи та логи брандмауера поза межами ураженого пристрою на предмет несподіваних завантажень на зовнішні IP-адреси або завантажень зі шкідливих. Будь-яка форензика, яка спирається виключно на власні логи ISE після компрометації, є ненадійною за своєю природою. Джерело не розкриває, чи зберігають пропатчені екземпляри форензичні артефакти до-патчової експлуатації, а це важливо, адже респондентам потрібно знати, чи взагалі можна провести аудит вікна вразливості.

Хто під ударом

Будь-хто, хто використовує ISE версій 3.1–3.5 як площину контролю ідентифікації для корпоративної мережі, перебуває в безпосередній зоні ураження, а це великий сегмент: ISE є стандартним вибором у компаніях із переважно Cisco-інфраструктурою, тобто у великих банків, телекомунікаційних операторів, систем охорони здоров'я, державних органів та будь-яких регульованих підприємств, що стандартизували мережу Cisco за останнє десятиліття. Клієнти на версії 3.0 у гіршому становищі: патча не буде, тому вони отримують проєкт оновлення в аварійні строки.

Для команд платформ iGaming і fintech, які використовують ISE для NAC у корпоративних мережах (а не у виробничих), ризик пов'язаний менше з платіжними рейками і більше з латеральним переміщенням. Зловмисник із root-доступом до ISE може перейти в будь-який мережевий сегмент, доступ до якого арбітрує ISE, включно з адміністративними VLAN, jump-хостами та площинами управління виробничою інфраструктурою. У регульованих галузях це перетворює помилку контролю мережевого доступу на обов'язкову розмову про розкриття інформації про порушення.

Оператори криптокастодіальної та DeFi-інфраструктури, які запускають середовища cold-signing за Cisco NAC, повинні розглядати це як подію валідації сегментації, а не подію встановлення патча. Якщо ISE визначає, які ендпоінти мають доступ до вашої мережі управління HSM, межа довіри, яку ви вважали існуючою, не існувала протягом вікна експлуатації.

Ad-tech та корпоративний SaaS із Cisco identity-інфраструктурою в штаб-квартирі або в колокаційних центрах стикаються з тоншою проблемою: їхні SOC-дашборди, імовірно, довіряють подіям автентифікації, що надходять з ISE. Будь-яка логіка виявлення, яка стверджує «користувач X автентифікувався через ISE, тому ця сесія є легітимною», тимчасово ненадійна. Невідомим тут залишається кількість downstream-правил SIEM, які неявно спираються на твердження ISE; я б оцінив це як «більше, ніж команда безпеки зараз задокументувала».

Картина на 90 днів: очікуйте принаймні одного публічно розкритого порушення, пов'язаного з цим CVE, до кінця Q4 2026, і очікуйте, що конкуренти Cisco (Aruba ClearPass, Fortinet FortiNAC та різні постачальники zero-trust overlay) будуть використовувати це в корпоративних циклах продажів протягом першої половини 2027 року.

Сценарій дій для команд безпеки

Спочатку патч, потім перевірка. Cisco випустила виправлення для ISE та ISE-PIC версій 3.1–3.5. Версія 3.0 потребує оновлення, а не патча, і це проєкт, а не задача в трекері змін. Cisco пропонує часткове пом'якшення через infrastructure access control lists (iACLs), які обмежують доступ до вразливого API-ендпоінту, але компанія сама говорить, що пом'якшення є тимчасовими. Не вважайте iACL кінцевою точкою.

Припускайте компрометацію до встановлення патча, якщо ваш інтерфейс управління ISE був доступний з чогось ширшого, ніж захищена адміністративна підмережа. Оскільки логи на самому пристрої можуть бути підроблені після експлуатації, збирайте кореляційні докази з upstream-брандмауерів, колекторів netflow та будь-яких зовнішніх syslog-призначень. Шукайте конкретно несподівані вихідні завантаження з ISE-апліансів та вхідні з'єднання з IP-адрес поза вашими звичайними адміністративними джерелами.

Змініть усе, що знала ISE. Якщо ISE зберігала спільні секрети RADIUS, ключі TACACS, матеріали довіри PKI або API-облікові дані для downstream-інтеграцій, вважайте їх скомпрометованими протягом вікна вразливості. Це нудна, дорога робота, яку більшість команд пропустить і пізніше про це пошкодує.

Звіртеся із записом CVE на MITRE та переконайтеся, що ваш інвентар активів відображає кожен екземпляр ISE та ISE-PIC, включно з тими, що працюють у лабораторних, DR та придбаних дочірніх середовищах, яких ніхто не торкався два роки. Саме в тіньових розгортаннях ISE ця вразливість живе найдовше.

Прогноз: якщо ця експлуатація настільки активна, як випливає з одночасного внесення CISA до KEV, ми повинні побачити принаймні одну атрибуцію відомому загрозливому актору та одне обов'язкове розкриття, ініційоване KEV, від федерального агентства США протягом 60 днів. Якщо цього не станеться до середини листопада, активність була вужчою, ніж свідчили дії CISA.

Ключові висновки

• CVE-2026-76460 — це неавтентифікований віддалений root-доступ до Cisco ISE з оцінкою 10.0 CVSS, що активно експлуатується; патч вийшов 17 вересня з одночасним внесенням до KEV каталогу CISA.
• Це третій обхід автентифікації API від Cisco з максимальною або близькою до максимальної оцінкою CVSS у 2026 році — після CVE-2026-20223 (Secure Workload, 10.0, травень) та CVE-2026-20129 (SD-WAN Manager, 9.8, лютий). Закономірність, а не випадковість.
• Компрометація ISE має каскадний ефект: інші API Cisco покладаються на неї для прийняття рішень щодо автентифікації, тому root-доступ до ISE підриває довіру в кожному мережевому сегменті, яким вона управляє.
• Форензичні логи на самому пристрої ненадійні після експлуатації. Розслідуйте з upstream-брандмауерів та зовнішніх log-призначень, а не з самого апліансу.
• Перевірна межа: якщо одночасне внесення до KEV відображає реальний масштаб експлуатації, очікуйте іменної атрибуції або федерального розкриття протягом 60 днів. Відсутність будь-якого з них до середини листопада означатиме, що активність була вужчою, ніж було сигналізовано.