Новини кібербезпеки серпень 2026, частина 1: SQLi 10.0 у Metabase, зеро-дей у драйвері Windows і атака на npm
- 39 хвилин тому
- Читати 8 хв
Новини кібербезпеки першої половини серпня 2026 склалися навколо однієї теми – атакували не периметр, а те, чому команди звикли довіряти: BI-платформу з обліковими даними до підключених до неї джерел, щомісячний пакет оновлень Windows, реєстр npm, ключі доступу без пароля та навіть процес вибору цілей, який тепер частково виконує ШІ. Це перша з двох частин добірки «новини кібербезпеки серпень 2026»: нижче – п'ять перевірених сюжетів за 1–14 серпня з посиланнями на першоджерела.
Metabase: SQL-ін'єкція з оцінкою 10.0, яку вже використали проти реальних компаній
6 серпня 2026 року Metabase повідомила про інцидент безпеки: зловмисник застосував зеро-дей SQL-ін'єкцію проти Metabase Cloud. Вразливість отримала ідентифікатор CVE-2026-72898 з оцінкою CVSS 10.0 – ін'єкція експлуатується через API скидання пароля й дозволяє неавтентифікованому віддаленому атакувальнику виконувати довільні SQL-запити в базі застосунку та отримати права адміністратора. 11 серпня CISA внесла CVE-2026-72898 до каталогу Known Exploited Vulnerabilities, встановивши федеральним агентствам термін усунення до 14 серпня.
Ключова деталь – не сама оцінка, а що саме зберігає Metabase. Це BI-платформа, яка тримає облікові дані підключення до тих джерел, які були під'єднані до конкретного розгортання. Компрометація сервера Metabase означає компрометацію всього, до чого дотягувався саме цей інстанс.
Наслідки вже задокументовані. 8 серпня компанія n8n повідомила, що через цю вразливість зловмисник звернувся до 136 записів користувачів self-hosted і n8n Cloud, а в оновленні від 11 серпня уточнила розбивку після форензики: 12 записів отримано підтверджено (з них 5 містили імена, email і bcrypt-хеші паролів n8n Cloud), ще 62 записи з іменами та email могли бути отримані – встановити, які саме, неможливо, бо запити повертали недетермінований набір рядків, – а решта 62 записи не містили чутливої інформації. n8n ротувала потенційно скомпрометовані облікові дані, зв'язалася з усіма, кого стосуються перші три групи, та повідомила берлінського уповноваженого із захисту даних.
Що це означає для практика. Інвентаризація «другорядних» внутрішніх сервісів – BI, дашборди, адмінки – має бути такою ж суворою, як для периметрових систем: сервіс без бізнес-критичності може мати критичні секрети. Після оновлення Metabase логіка робіт не завершується: потрібно вважати скомпрометованими всі облікові дані підключень, які зберігав сервер, і перевірити журнали на аномальні запити до API скидання пароля. Це саме та навичка – побудувати детект на подію, а не лише закрити CVE, – яку відпрацьовують на курсі SOC-аналітика CSA.
Patch Tuesday за серпень: 398 CVE і один зеро-дей, який експлуатують просто зараз
11 серпня Microsoft випустила щомісячний пакет оновлень. За незалежним підрахунком Zero Day Initiative, реліз закриває 398 нових CVE, з них 62 – критичні. Але єдина вразливість, яку Microsoft позначила як таку, що вже використовується в атаках, – CVE-2026-68820 з відносно скромною оцінкою CVSS 7.0. Це use-after-free у afd.sys, драйвері Ancillary Function Driver for WinSock, тобто в ядерному компоненті мережевого стека Windows. Вразливість дає підвищення привілеїв до SYSTEM для атакувальника, який уже виконує код на машині. Check Point Research, яка й повідомила про вразливість Microsoft, пов'язує експлуатацію з північнокорейською групою Lazarus і її кампанією «Operation Dream Job»: фальшиві пропозиції роботи для компаній оборонного, аерокосмічного й дронового секторів, після початкового виконання коду – розгортання нової версії руткіта FudModule. За даними Check Point, група використовувала цей зеро-дей із початку липня. Microsoft публічної атрибуції не робила.
Окремо в релізі є чотири вразливості з CVSS 9.8, які не потребують від жертви нічого – ні облікового запису, ні кліку: CVE-2026-62878 у Windows DNS Server (переповнення стекового буфера; ZDI описує сам технічний стан як «wormable», що не означає існування черв'яка), CVE-2026-62893 у Windows Deployment Services, CVE-2026-62815 у Microsoft QUIC та CVE-2026-59124 у HPC Pack. Жодна з них не була позначена як експлуатована на момент виходу оновлень. Серпневий реліз також закриває другу половину ланцюжка для локального SharePoint: липневий CVE-2026-55040 (обхід автентифікації, 9.1) плюс серпневий CVE-2026-63520 (виконання коду).
Що це означає для практика. Оцінка CVSS – не черга на встановлення патчів. Вразливість на 7.0, яку вже використовують, важливіша за чотири «дев'ятки», яких ніхто не торкався, а пріоритет для решти визначається тим, чи встановлений вразливий сервіс і чи доступний він із мережі. Практичний порядок: спершу закрити те, що експлуатують, далі – відкриті назовні DNS, WDS, QUIC і HPC, і лише потім звірити, що на локальних фермах SharePoint стоять обидва оновлення, липневе й серпневе.
Атака на npm: 2 234 отруєні версії у 444 пакетах, з валідним підписом
4 серпня в реєстрі npm з'явився реліз keyv@6.0.0 із preinstall -скриптом, який запускав викрадач облікових даних у середовищах розробників і CI. За даними SafeDep, кампанія охопила 2 234 отруєні версії в 444 іменах пакетів, опублікованих з облікових даних дванадцяти організацій – серед них Cacheable, Qlik, Deliveroo, ServiceTitan, Picsart і Ornikar. Перша отруєна публікація зафіксована о 09:35 UTC, остання – о 13:18 UTC, причому вісім організацій потрапили під публікації у вузькому вікні між 10:12 і 10:46 UTC. Корисне навантаження збирало токени GitHub, npm, хмарні ключі, секрети Vault і Kubernetes, дані баз та приватні ключі, зчитувало пам'ять runner-ів GitHub Actions і мало власний механізм публікації пакетів під викраденою ідентичністю.
Щодо самого слова «черв'як» варто бути точним. SafeDep називає кампанію npm-черв'яком, і Aikido відносить її до сімейства Shai-Hulud, але SafeDep окремо зазначає: щільність таймінгу й характер публікацій підтримують гіпотезу автоматичного поширення, і ця гіпотеза лишається висновком за непрямими ознаками – ініціюючу функцію не відновлено, а частину пакетів опубліковано з прямих облікових записів. Скільки саме облікових записів було скомпрометовано, з наявних даних встановити не можна.
Найнеприємніша деталь стосується довіри до підписів: отруєний реліз Keyv ніс валідні атестації OIDC і SLSA, бо пройшов через легітимний release-workflow проєкту в GitHub Actions. Атестація коректно підтверджувала процес збірки – але не те, що у збірку зайшов безпечний код. Окремим вектором стали hook-и репозиторію для Claude Code і VS Code, здатні виконати навантаження після того, як користувач довіряє робочому простору.
Що це означає для практика. Будь-яка робоча станція чи CI-раннер, що виконали уражену версію, вважаються скомпрометованими за обліковими даними – і перевіряти треба lock-файли та фактично встановлені версії, а не поточні теги latest. SafeDep окремо попереджає: спершу приберіть встановлений зловмисником «спостерігач за відкликанням токенів», і лише потім ротуйте ключі, інакше ротація сама запустить обробник атакувальника. Такий порядок дій – стримування, ерадикація, потім відновлення – відпрацьовується на курсі з реагування на інциденти ECIH.
Unit 42: ШІ-агент обрав цілі за хвилини – і зупинився об коректну конфігурацію
Головне в цьому сюжеті варто сказати одразу: жодна з автономних спроб не дала підтвердженої компрометації. Palo Alto Networks Unit 42 задокументувала кампанію китайськомовного зловмисника під псевдонімами knaithe та KnYuan, який під'єднав DeepSeek до відкритого фреймворку Hermes Agent і використав його як наступального оператора проти пристроїв, доступних з інтернету. Загалом актор намагався атакувати понад 460 цілей, поєднуючи автономні й ручні техніки, – але підтверджений вплив дала саме ручна частина.
В автономній сесії 7 травня 2026 року агент після однієї команди в Telegram працював без втручання оператора: перебрав десять продуктових сімейств, шукав свіжі PoC на GitHub, через FOFA знайшов 84 доступні інстанси Langflow і взявся за CVE-2026-33017. Далі він сам дійшов висновку, що доступні інстанси не мають ані публічного ідентифікатора флоу, ані автологіну, потрібних для експлуатації, записав у власних нотатках «stuck» і без людини переключився на n8n, де FOFA показала понад 647 000 інстансів, доступних з інтернету. Там усе завершилося так само: атака не спрацювала. Для контрасту, у ручних операціях той самий актор досяг реального результату – Unit 42 повідомляє про ексфільтрацію даних із трьох організацій через CVE-2026-3055 у Citrix NetScaler і виконання команд на 11 інстансах Marimo через CVE-2026-39987.
Кампанію знайшли завдяки помилці самого зловмисника: Hermes випадково підняв вебсервер із домашнього каталогу й відкрив середовище атакувальника – ключі API, скрипти експлойтів, списки цілей, історію шелу та логи роботи ШІ. Unit 42 формулює висновок стримано: спостережувана кампанія мала обмежений вплив, але робочий процес підтверджує наскрізну автономну наступальну спроможність. Тому рамки «перша автономна кібератака» варто уникати – показове тут не первородство, а швидкість: система виконала за хвилини роботу, яка зазвичай потребує сотень годин ручного аналізу цілей. Одну з вразливостей, яку використовували в цій активності, – CVE-2026-34486 в Apache Tomcat (CVSS 7.5) – CISA додала до каталогу KEV 5 серпня разом із Langflow CVE-2026-9198 (CVSS 9.8) та обходом автентифікації в N-able N-central.
Що це означає для практика. Автономного агента зупинила не детекція, а конфігурація: обидві цілі встояли тому, що були коректно налаштовані, а не тому, що хтось помітив атаку й відреагував. Це найкорисніший висновок місяця – базовий гардінг досі працює навіть проти автоматизованого зловмисника, який може без паузи перебирати рутинні варіанти. Але водночас зникає фора: якщо розвідка й підбір експлойта коштують атакувальнику хвилини, розрахунок «встигнемо пропатчити наступного тижня» більше не працює.
Passkeys без пароля, але не без ризику: три сценарії Unit 42 проти Google Password Manager
Unit 42 описала три техніки – Pass-ta-key, Silver Pass-ta-key і Golden Pass-ta-key – проти хмарного автентифікатора Google Password Manager у Chrome на Windows із TPM. Криптографію вони не ламають: атаки націлені на код навколо ключа – як Chrome зберігає ключі пристрою, як переоформлює пристрій після втрати цього стану і чи перевіряє сайт факт верифікації користувача взагалі. Результат – можливість тихо отримати валідне твердження автентифікації, зареєструвати підконтрольний атакувальнику ключ верифікації або витягти 32-байтовий Security Domain Secret, яким розшифровуються синхронізовані приватні ключі passkey.
Важливе застереження, яке варто читати разом із заголовками: усі три шляхи – посткомпрометаційні, кожен починається зі шкідливого коду, що вже виконується на пристрої жертви. CVE не призначено; за словами дослідника Palo Alto Networks Арі Ольштейна, Google рідко видає CVE на проблеми, що вимагають попередньої компрометації пристрою шкідливим ПЗ. Демонстрації розроблялися проти Chrome 142. GitHub перевірку прапорця User Verified виконував коректно; eBay приймав тестове твердження, доки не виправив валідацію після розкриття.
Що це означає для практика. Passkey усувають фішинг облікових даних, але не роблять скомпрометований ендпоінт безпечним – модель загроз має це враховувати. Для власних сервісів: встановлюйте userVerification: required і перевіряйте повернутий біт UV, а не лише параметр запиту. Для розслідувань: після інциденту з викраденням даних треба вміти встановити, які саме секрети були в пам'яті процесу й що з ними зробили, – а окремою проблемою лишається те, що користувач не має способу перевірити, чи був його Security Domain Secret експонований, і чи зміна PIN знецінює вже вкрадений секрет.
Новини кібербезпеки серпень 2026, частина 1: підсумок
П'ять сюжетів першої половини серпня складаються в одну думку: контроль, який ви не інвентаризували, вас не захищає. BI-платформа виявилася сховищем облікових даних до всього, до чого дотягувався її інстанс. Валідний SLSA-підпис підтвердив збірку, але не безпеку коду. Оцінка 7.0 виявилася терміновішою за чотири 9.8. Passkey усунули фішинг, але не компрометацію ендпоінта.
І тут же – добра практична новина в цьому сюжеті: автономного ШІ-агента в кампанії Unit 42 зупинила не система виявлення, а те, що цілі були правильно налаштовані. Розвідка, яка раніше давала фору в кілька днів, тепер займає хвилини, тож ставка на «встигнемо відреагувати» слабшає – а ставка на конфігурацію, навпаки, працює.
Якщо в команді видно розрив між «ми знаємо про вразливість» і «ми вміємо її виявити, стримати й розслідувати» – закривати його краще практикою. Повний каталог курсів ISSP Training Center охоплює мережевий захист, SOC, реагування на інциденти, форензику та наступальну безпеку; підібрати програму під конкретні ролі в команді можна, написавши на training@issp.com.
