Лабораторії, які полегшують злам програмного забезпечення, також продають інструменти захисту. Цьомісячні інциденти безпеки показують, чому цю бізнес-модель слід перевіряти — і чому відповіддю не може бути ще одна чорна скринька з більшим рахунком за API.
В індустрії ШІ формується незручний рекламний аргумент: моделі стають достатньо потужними, щоб знаходити щілини у вашій інфраструктурі, тож, мабуть, їх слід використовувати й для герметизації цих щілин.
Рахунок за це я називаю Податок на безпеку ШІ. Це більше, ніж плата за підписку. Сюди входять інженерний час, витрати на інференс, екстрене виправлення та операційна складність, потрібні, щоб не відставати від машин, які безперервно досліджують програмне забезпечення. Малі команди платять ночами й вихідними. Великі організації — ще одним рівнем інфраструктури безпеки.
Жовтневі інциденти роблять таку перспективу конкретною. Вони також полегшують надто охайну історію: одна глобальна хвиля атак ШІ, один іноземний винуватець, один постачальник із ліками. Докази підтримують цікавіший висновок. Старі помилки, порушена довіра, викрадені облікові дані та дедалі спроможніші агенти взаємодіють. Причина в них не однакова.
Матеріал перевірено 24 жовтня 2026 року. Це аналіз основних інцидентів і родин вразливостей Linux, пов’язаних із цією хвилею, а не вичерпний каталог усіх CVE Linux. Дати нижче розрізняють первинне розкриття та відновлення уваги. Деталі інцидентів і статус виправлень постачальників можуть змінюватися.
Насичений місяць і кілька різних збоїв
21 жовтня PHP випустила екстрені виправлення для двох вразливостей віддаленого виконання коду без автентифікації: CVE-2026-109618 і CVE-2026-109619, обидві з оцінкою 9.2. Одна стосується пошкодження пам’яті під час обробки її нестачі, інша — застарілого стану запиту. Це проблеми середовища виконання, тож виправити лише код застосунку недостатньо. рекомендація CERT-EU визначає уражені гілки та терміновість.
Тут є задокументований зв’язок із ШІ. OpenAI повідомляє, що У дослідженні Calif використала GPT-5.6 Sol, а Wiz незалежно повідомила про обидві вади. Супроводжувачі PHP очолили виправлення та випуск. Заслуга належить скоординованій роботі людей і моделей, а не чатботу, що діяв самостійно.
Перші випуски з виправленнями — PHP 8.5.12, 8.4.27, 8.3.36 і 8.2.35. Постачальники дистрибутивів можуть бекпортувати виправлення під іншими версіями пакетів. Важливо, що CERT-EU оновила рекомендацію 23 жовтня й додала CVE-2026-115560, третя проблема RCE, пов’язана з незвичною конфігурацією. PHP вважала ризик малоймовірним і не запланувала екстрений випуск; рекомендація містить тимчасовий спосіб зменшити ризик. Розповідь, застигла на оголошенні про виправлення в середу, вже буде неповною. Перевірте офіційні випуски PHP та поточні рекомендації постачальника.
Історія Linux більша за один лячний заголовок
На найновіші повідомлення про критичні вразливості ядра варто звернути увагу. Словаччина CSIRT попередив 23 жовтня про оприлюднені звіти щодо вразливостей, зокрема дві проблеми файлового сервера KSMBD з оцінкою 9.0: ZDI-CAN-33549 і ZDI-CAN-33774. Передумови різні: одна проблема стосується SMB Direct/RDMA, інша — диспетчеризації протоколу та шляху запису, пов’язаного з доступом до спільного ресурсу. Експозиція залежить від фактично використовуваної служби й конфігурації. Власний перелік ZDI підтверджує ідентифікатори й оцінки.
На момент публікації рекомендації ці два звіти не не мають ідентифікатори CVE. Ця відмінність важлива. Критична проблема не стає нешкідливою, поки очікує на CVE, а критична оцінка не доводить, що кожна машина Linux вразлива. Адміністраторам слід обмежити доступ до уражених служб і відстежувати фактичний статус виправлень у своєму дистрибутиві.
Є й критичний призначено CVE у недавньому обговоренні Linux: CVE-2025-39682, вада в шляху отримання TLS ядра. NVD наводить оцінку 9.8 і посилання CISA на відомий випадок експлуатації. Її вперше опублікували у вересні 2025 року, а не відкрили цього жовтня. Red Hat інакше оцінює свої продукти, що показує, чому універсальна оцінка й практична оцінка експозиції постачальника можуть не збігатися.
Це лише частина актуальної картини Linux:
Copy Fail — CVE-2026-31431
Виявлення за допомогою ШІ вади кешу сторінок ядра, оприлюднене 29 квітня. Воно дає змогу локально підвищити привілеї в уражених ядрах. Віддаленому зловмиснику все одно потрібен початковий шлях до локального виконання. Повідомлення дослідника.
Dirty Frag / Fragnesia — CVE-2026-43284, CVE-2026-43500, CVE-2026-46300
Пов’язані проблеми підвищення привілеїв у кеші сторінок розкрили в травні. Мережеві компоненти та конфігурація впливають на досяжність; розслідування Microsoft відрізняє спостережену активність від непідтвердженої експлуатації окремих варіантів. Розслідування Microsoft.
CrackArmor
Дев’ять вразливостей AppArmor, представлених одинадцятьма CVE на рівні виправлень. Ubuntu описує вимоги до локального користувача й різний вплив у різних випусках, зокрема обхід політик і підвищення привілеїв. Повна матриця Ubuntu.
Четвірка мережевих проблем — DirtyAH6, TUNderflow, PPPoEject, DiagSpill
CVE-2026-80844, CVE-2026-81000, CVE-2026-68121 і CVE-2026-74469. Вересневі матеріали описують шляхи локального root із різними вимогами до namespace, capability і модулів. Бюлетень Red Hat.
Vghost — CVE-2026-74580
Вада vhost може дозволити локальне підвищення привілеїв і створити ризик виходу з VM у певних конфігураціях. У рекомендації Tencent прямо сказано, що перевірене середовище CVM не було вразливим до шляху виходу з VM. Рекомендація Tencent.
Інші шляхи ядра — CVE-2026-53266, CVE-2025-39964
Перша проблема стосується SNAT в ebtables за певних правил bridge; друга — паралельного запису AF_ALG. Вимоги й наслідки різняться. Оцінка SNAT; Оцінка AF_ALG.
Практичний висновок — розрізняти віддалений вхід з що відбувається після входу. Уразливість локального root може мати катастрофічні наслідки на спільному сервері, build runner або хості агента, навіть якщо вона не дає будь-якому відвідувачу з інтернету ввійти в систему. Початкову точку доступу може дати вада застосунку чи викрадений обліковий запис. Якщо сприймати кожен заголовок про ядро як універсальне віддалене захоплення, можна не помітити системи, які потребують уваги насамперед.
Замок може відмовити, навіть якщо шифрування не зламане
Інцидент із сертифікатами — це інший тип збою. Mozilla повідомляє, що 17 жовтня отримала звіт про компрометацію приватних ключів восьми проміжних сертифікатів eMudhra. Зловмисник, який може перехопити з’єднання, потенційно використає шахрайськи видані сертифікати, щоб видати себе за сайт. Того вечора Mozilla заблокувала відповідні сертифікати через OneCRL, а згодом оновила Firefox і компоненти сховища довіри. У відповіді також записано подальше виправлення Android.
Ключ підпису центру сертифікації дає право засвідчувати ідентичності. Його компрометація атакує це рішення щодо довіри. Це не означає, що хтось математично зламав шифрування TLS. Звіт Mozilla також не доводить, що компрометацію спричинила LLM.
Проблеми OpenSSL теж належать до цієї картини, але їх не слід плутати з інцидентом CA. Вересневий набір рекомендацій охоплює обробку розширень X.509, виснаження ресурсів під час обробки сертифікатів, QUIC та інші дефекти криптографічної бібліотеки. Індекс рекомендацій OpenSSL розділяє уражені версії та рівень серйозності. Зловмисний сертифікат може виявити програмну помилку, навіть якщо йому ніколи не слід довіряти.
Випуск безпеки Node.js від 21 жовтня поєднує ці рівні: оновлює вбудовані дані CA для eMudhra та окремо виправляє DNS, перевірку імені хоста TLS й інші проблеми середовища виконання. Вада декодера Brotli, CVE-2026-111497, може спричинити пошкодження пам’яті та віддалене виконання коду, коли застосунок обробляє стиснені дані, надані зловмисником; проєкт відзначає дослідників OpenAI Codex Security. повідомлення безпеки Node оцінює найсерйозніші проблеми як High. Опубліковані виправлені випуски: 26.12.1, 24.22.1 і 22.23.4. Офіційний архів випусків.
Ключі API стають стратегічним ресурсом
Компрометація LiteLLM особливо наочно показує проблему облікових даних. Зловмисний пакет 1.107.0 потрапив до публічних реєстрів 21 жовтня. Microsoft виявила хуки запуску Python, які могли активувати збирач облікових даних без явного імпорту LiteLLM застосунком. Ключі постачальників моделей були лише частиною значно ширшого набору цілей, до якого входили облікові дані розробників і хмари. Тому видалення одного пакета не відновлює довіру до машини. Розслідування Microsoft пояснює наслідки експозиції та відновлення.
Пізніше розслідування LiteLLM пов’язує компрометацію upstream із відкритим master key, який не відкликали, а далі — з доступом до потужних облікових даних розробників і процесу випуску. Також повідомляється про намагання отримати upstream-токени API для інференсу. Офіційний опис інциденту виправляє деякі ранні припущення. Це нагадування стежити за розслідуванням, а не зберігати перше пояснення, що стало вірусним.
Облікові дані ШІ тепер можуть купити більше, ніж фальшивий рахунок за хмару. Вони дають доступ до міркування, допомоги з програмуванням і місця, де можна приховати діяльність іншого оператора. Якщо доступ перепродали, законний власник облікового запису може нести витрати та ризик санкцій, поки можливістю користується хтось інший. Щоб встановити, хто купив певний викрадений ключ і як його використав, усе ще потрібні докази.
Що свідчать докази про китайські лабораторії
Є задокументовані підстави непокоїтися про несанкціоновану дистиляцію. У вересневому звіті Anthropic описує кампанії, які приписує лабораторіям із Китаю, і пояснює, як proxy-сервіси можуть використовувати шахрайські акаунти, викрадені платіжні дані та викрадені API-облікові дані для надання доступу. Той самий звіт описує зловмисні операції за допомогою ШІ від різних типів суб’єктів, а не однієї національної групи. Це атрибутовані висновки Anthropic, а не незалежний вердикт щодо кожного ймовірного учасника. Прочитайте звіт про загрози.
У розкритті від 30 вересня OpenAI приписує основну групу кампанії вилучення міркувань особам, пов’язаним із Moonshot AI. Важливо, що, за її словами, кампанія не зламала шифрування, не скомпрометувала базу даних і не отримала прямого доступу до збережених розмов користувачів. Її механізмом була маніпуляція взаємодіями з моделлю. Звіт OpenAI не слід переказувати як інший тип порушення.
NSA, FBI і CISA також у вересні спільно попередили про промислову дистиляцію компаніями ШІ з Китаю. Оголошення урядової рекомендації підтверджує, що це серйозна, публічно задокументована проблема. Дистиляція й надалі є легітимною технікою навчання; питання стосуються дозволу, доступу та способу отримання даних.
Моя оцінка: викрадені облікові дані для інференсу та несанкціонована дистиляція є реальною частиною економіки загроз. Наведені джерела не доводять, що китайські лабораторії організували помилки PHP, компрометацію ключа eMudhra, розкриття KSMBD чи атаку на LiteLLM. Щоб об’єднати ці події в одну кампанію, потрібні докази зв’язку між операторами, інфраструктурою або використанням викрадених даних. Спільні стимули є приводом для розслідування, а не заміною атрибуції.
Коли інша сторона може запустити рій
Важлива зміна — економічна. Модель може перевіряти код, пропонувати тести й допомагати досліджувати результати. У складі агента, що використовує інструменти, вона може повторювати цикл. Якщо запустити багато агентів паралельно, оператор може одночасно перевіряти кілька гіпотез. Це не означає, що кожна спроба правильна або кожна ціль вразлива. Це робить тривале розслідування дешевшим.
Конкретний приклад захисту є в Звіт OpenAI про стримування від 23 жовтня. Компанія описує групи агентів, які тестують спеціально створені копії її інфраструктури з доступом до джерел і конфігурацій, моніторингом та обмеженими цілями. Вона повідомляє про вихід із VM та проблеми ізоляції, а також роботу над проблемами ядра, зокрема CVE-2026-74753, CVE-2026-80521 і CVE-2026-80841. Ці контрольовані експерименти не доводять, що непідконтрольний публічний бот може зламати будь-який сервер. Вони показують, чому захисники серйозно ставляться до постійного тестування за допомогою машин.
Для невеликого оператора це змінює переваги непомітності. Коли перевірка ще одного хоста коштує мало, невідомість захищає слабше. Зловмисник може продовжувати спроби, поки ваша команда займається своєю роботою. Захист має скоротити шлях від надійного сигналу до підтвердженого виправлення, а не просто генерувати більше сповіщень.
Корисним оборонним агентам потрібні межі
На мою думку, перший корисний агент безпеки — ретельний дослідник. Він картографує розгорнуте ПЗ і доступні служби, зіставляє рекомендації з реальним середовищем і готує докази, на які може відреагувати супроводжувач. Друга роль — перевіряти запропоноване виправлення в одноразовому середовищі. Жодній ролі не потрібні необмежені облікові дані production.
Послідовність упровадження має бути продуманою:
- Спостерігайте: збирайте інвентар, версії та журнали з вузьким доступом лише для читання.
- Перевірте: з’ясуйте, чи наявний і доступний вразливий шлях коду. Самого рядка версії може бути недостатньо, щоб помітити бекпорт виправлення дистрибутивом.
- Тестуйте: відтворюйте й перевіряйте у контрольованій копії, а бюджет і межі застосовуйте поза моделлю.
- Зміна: вимагайте погодження для суттєвих дій у production, а потім використовуйте поетапне розгортання та перевірений відкат.
- Виміряйте: перевірте систему, що працює, збережені докази, стан служби та чи справді зменшилася експозиція.
Журнали, заявки й файли репозиторіїв можуть містити текст під контролем зловмисника. Захисник, який вважає цей текст авторитетним, сам стає поверхнею атаки. Обмежені ідентичності, ізольовані інструменти, обмежений мережевий доступ і незалежно забезпечені правила дій важливі навіть тоді, коли модель звучить упевнено. Швидше міркування не робить широкі дозволи безпечнішими.
Лабораторія продає можливість. Потім продає щит.
Тут бізнес-модель стає незручною. Ті самі компанії, які розробляють можливості для здешевлення атак, позиціонують ці можливості як необхідні інструменти захисту. Клієнти можуть постійно платити за керування ризиком, який прискорює сама категорія продуктів.
За цим занепокоєнням стоїть реальна комерційна структура. В оголошенні Glasswing Anthropic пообіцяла до 100 млн доларів кредитів на моделі та 4 млн доларів пожертв організаціям безпеки відкритого коду; також описала платне використання після попередньої підтримки. У жовтні чинні учасники Glasswing переходили до розширеної Cyber Verification Program. Сторінка програми є водночас серйозною оборонною ініціативою та частиною ринку передових можливостей безпеки.
Назвати це податком на безпеку ШІ не означає стверджувати, що лабораторії винайшли давні помилки чи навмисно організували атаки. Йдеться про стимул: із поширенням потужних моделей може зрости попит на захист за допомогою моделей, а постачальники можливостей можуть отримати ці витрати. Громадськість має мати змогу перевіряти обмеження доступу, ціни, заяви про безпеку та докази того, що обіцяний захист працює.
Є справедливий контраргумент. Оборонні дослідження можуть перетворити тимчасову перевагу у виявленні на постійні публічні виправлення, які захищають і тих, хто не купує підписку на модель. Ця користь реальна. Вона є аргументом оцінювати галузь за впровадженими виправленнями й безпечнішими типовими налаштуваннями, а не вважати страх чи оптимізм достатнім доказом.
Вузьке місце — усе після виявлення
Моделі можуть генерувати висновки швидше, ніж супроводжувачі встигають їх перевіряти. На чітко датованому знімку за 2 жовтня панель Anthropic повідомляла про 6 157 розкритих знахідок у 591 проєкті та 516 відомих upstream-виправлень. Панель застерігає, що підрахунки мають різні етапи перевірки, а кількість патчів не показує, наскільки широко їх установили. Методологія не менш важлива за число в заголовку.
Висновок не в тому, щоб відняти ці числа й оголосити тисячі вразливих серверів без виправлень. Виявлення, підтвердження, upstream-виправлення та розгортання — окремі завдання. Фінансування лише першого перекладає роботу на тих, хто відповідає за решту.
Я віддаю перевагу ринку безпеки, який платить за результати: відтворювані звіти, спроможність супроводжувачів, публічні виправлення, зручні шляхи оновлення й незалежно перевірене стримування. Клієнти мають могти передати докази іншому постачальнику. Малим супроводжувачам не потрібен корпоративний контракт на ШІ, щоб захищати популярну бібліотеку.
У наступну епоху безпеки, імовірно, моделі стежитимуть за моделями, а агенти перевірятимуть захист інших агентів. Але стійкий захист не може цілком залежати від того, хто здатен оплатити найбільший рій. Потрібні також менш відкриті інфраструктури, менш привілейовані облікові дані, програмне забезпечення, що безпечніше відмовляє, і люди, уповноважені діяти на підставі надійних доказів.
Питання вже не лише в тому, чи може ШІ знайти дірку. Важливо, хто отримає виправлення, хто контролюватиме захист і кому надійде рахунок.
Примітка редакції: у статті відокремлено підтверджені повідомлення про інциденти, атрибуцію постачальників та аналіз автора. Концептуальні ілюстрації створено за допомогою ChatGPT; інфографіку підготовлено за пов’язаними записами. Для цієї статті експлойт не запускали на живій системі. Перед діями ознайомтеся з актуальною рекомендацією для вашого точного продукту й конфігурації.
