Gemini 4 Carbon: коли найсильніші шукачі вразливостей спершу дістаються державам

Google представила Gemini 4 Carbon, модель, яка, за власними даними компанії, значно випереджає попередницю в пошуку та експлуатації вразливостей. Першими її отримують спецслужби США, згодом обрані захисники, а для всіх інших дати немає. Тут розібрано, що підтверджено, що залишається лише заявою виробника і що компанії та виробники в Європі можуть змінити в циклах патчів і процесах перевірки.

28 жовтня 2026 року Google представила Gemini 4 Carbon, лише через чотири тижні після Gemini 4 Argon. Показники продуктивності в анонсі є даними виробника, і ззовні їх перевірити не можна. Цікавіший порядок, у якому модель мають розповсюджувати: спочатку державні органи, потім обрані захисники, а дата для всіх відсутня. За день до анонсу Google, 27 жовтня 2026 року, Anthropic також опублікувала звіт, у якому неопублікована дослідницька модель нібито побудувала п'ять ланцюжків експлойтів. За даними Anthropic і The Hacker News, усі п'ять уже виправлено, хоча для випадку з Android немає публічного запису, а у випадку з Windows прив'язка незрозуміла.

Спершу описано дані бенчмарків та їхні межі, потім етапи доступу і питання, що ця асиметрія означає для організацій за межами США. Далі йдуть ланцюжки Anthropic зі станом патчів, наслідки для циклів патчів і виробників програмного забезпечення та список практичних кроків, серед них перевірка Linux-сервера. Ситуація може швидко змінюватися.

Gemini 4 Carbon: що заявляє Google і що можна перевірити

Дані про Gemini 4 Carbon походять від Google і з публікацій про це.

За словами Google, Carbon досягає в бенчмарку Exploitgym майже 55 відсотків, Argon мав 42 відсотки і цим трохи поступався конкурентній моделі GPT-6 Astra. У бенчмарку SEC-bench Pro Carbon має понад 88 відсотків і, згідно з повідомленням, випереджає цього конкурента. Для CWE-bench, тесту на усунення вразливостей, названо 71 відсоток. Бенчмарк при цьому — це стандартизований набір завдань, на якому моделі вимірюють у порівнянний спосіб. Як саме побудовано ці три тести, тут не перевірялося. Тому опис свідомо обмежується тим, що сказано в повідомленні.

Інші твердження також походять від Google: досі жодна спроба prompt injection не була успішною, тобто маніпуляції моделлю за допомогою підкинутих інструкцій. Крім того, модель менше галюцинує і частіше ставить уточнювальні запитання. Незалежних вимірювань щодо цього немає. Принагідно названо ціни: 4 долари США за мільйон вхідних токенів і 20 доларів США за мільйон вихідних токенів, на старті зі знижкою 50 відсотків. За нинішніми мірками це в порівнянні недешево, але – якщо брати абсолютні значення – і не надто дорого.

Значення бенчмарків відповідають на вузьке питання: наскільки добре модель розв'язує підготовлені завдання? Наскільки добре вона працює в програмному забезпеченні, що історично склалося, з особливими випадками, застарілим кодом і нечіткими зонами відповідальності, вони показують лише обмежено. Тому для оцінки досить тверезого прочитання. Якщо цифри Google правдиві, відрив від попередниці в експлуатації вразливостей був би великим. Чи так само це буде на практиці, стане зрозуміло лише тоді, коли модель зможуть протестувати треті сторони.

Поетапний доступ: спершу спецслужби, потім Fairwind, згодом усі

Справді нове в Gemini 4 Carbon — шлях до користувача. Схоже, Google виконує вказівку Білого дому спершу робити нові моделі ШІ доступними лише для спецслужб США та обраних користувачів. Звідси випливають три етапи.

Перший етап — спецслужби США та схвалені ними користувачі. Чи і як вони використовують модель, не підтверджено. Підтверджено лише передбачений порядок. Другий етап — програма Fairwind, через яку поступово мають долучатися обрані кіберзахисники та інші довірені партнери. Третій етап — широка публіка. Google обіцяє доступність «незабаром», але дати не називає. У випадку Argon від презентації до відкриття для платних користувачів минуло два тижні.

Як працює Fairwind, описує Google DeepMind на сторінці програми. Згадано понад 650 партнерів. Брати участь можуть уряди та національні кіберагенції, оператори критичної інфраструктури, ключові технологічні платформи та академічні лабораторії. Заявників перевіряють. Серед іншого вимагаються стійка до фішингу багатофакторна автентифікація, журналювання та оборонне використання, передавання третім особам заборонено. Однак на сторінці як модель названо Argon, а не Carbon. Чи діють для Carbon ті самі умови, невідомо. Правил для Європи сторінка не наводить.

Для європейських компаній із цього випливає асиметрія, яка насамперед є питанням часу. Держави та великі платформи отримують потужні інструменти раніше, ніж середній бізнес і виробники. Наскільки довгим буде цей розрив, не знає ніхто. Можна розділити два питання: хто вирішує щодо доступу і що з цього випливає для організацій, які до кола не входять? Схоже, вирішує Білий дім. Організаціям за межами США залишається чекати й налаштуватися так, щоб перевага інших завдала якомога менше шкоди.

Контраргумент заслуговує на увагу. Поетапний доступ може обмежити зловживання, а захисники з раннім доступом, можливо, знайдуть помилки раніше за зловмисників. Відкритим залишається питання, чи отримають зловмисники порівнянні можливості деінде, наприклад в інших постачальників або з вільно доступними моделями. Це не підтверджено, це було б спекуляцією. Для планування досить зауваження, що припущення про тривалу перевагу захисників ризиковані.

Організації без права доступу, згідно зі сторінкою Fairwind, можуть використовувати інструмент CodeMender з публічно доступними моделями. Тут це самостійно не тестувалося. Але це показує, що й без доступу до найвищого етапу існують шляхи до пошуку помилок за допомогою ШІ.

Що показала Anthropic: п'ять ланцюжків експлойтів і стан їхніх патчів

Експлойт — це фрагмент коду, який використовує вразливість. Ланцюжок експлойтів поєднує кілька вразливостей, щоб із дрібної помилки вийшла повноцінна атака. Frontier Red Team компанії Anthropic описує 27 жовтня 2026 року, що неопублікована внутрішня дослідницька модель із початковими інструкціями та незначною участю людей побудувала робочі ланцюжки. Модель не названо, і це не Carbon. Але обидва повідомлення вказують в одному напрямку

П'ять випадків в огляді, щоразу за даними названих джерел:

• Chrome: досить відкрити сторінку, щоб виконати код поза пісочницею. Пісочниця (sandbox) — це захисний шар, що відокремлює вебвміст від решти системи. Ланцюжок поєднує чотири вразливості, серед них помилки пам'яті в рушії JavaScript V8, race condition (помилка, що залежить від часової послідовності паралельних процесів) і use-after-free (доступ до вже звільненої пам'яті). Anthropic повідомила про 62 CVE, тобто публічно пронумеровані записи про вразливості, усі критичні або високі, серед них, за даними Anthropic, 13 виходів із пісочниці. Виправлення міститься в Chrome 156.
• Safari: доступ на читання і запис до пам'яті браузера, Same-Origin-Policy обходиться. За даними The Hacker News, виправлено в iOS та iPadOS 26.5.2.
• Android: доступ до даних заблокованого, викраденого Pixel 9 через USB. Потрібен фізичний доступ. За даними Anthropic, Google усунула вразливість, публічного запису, за даними The Hacker News, не знайдено.
• Windows: denial-of-service через HTTP/3. Anthropic описує вразливість у ядрі, The Hacker News посилається на CVE, в описі якої названо HTTP.sys. Прив'язка незрозуміла.
• Linux: команди від імені root через мережу, без автентифікації, якщо працює MPTCP-listener. MPTCP (Multipath TCP) дає змогу одному з'єднанню використовувати кілька мережевих шляхів одночасно. За даними Anthropic, обхід KASLR, захисту за допомогою випадкових адрес пам'яті в ядрі, тривав 48 хвилин, після чого знадобилося ще п'ять хвилин до root-shell. Названо CVE-2026-98432 із CVSS 9,8, значенням у найвищому діапазоні шкали серйозності від 0 до 10. Виправлення, за даними джерел, є в основній гілці Linux з 15 жовтня 2026 року.

Щодо Linux-ланцюжка потрібні застереження. Anthropic пов'язує ланцюжок із вразливістю MPTCP і називає CVE-2026-98432. Проте Debian Security Tracker описує ту саму CVE як помилку в коді IPv4-TCP, а саме як use-after-free під час переходу від сокета запиту до дочірнього сокета. Тож зв'язок між CVE і MPTCP поки що походить лише з публікації Anthropic. Можливо, описи неповні або ланцюжок зачіпає кілька помилок. Це не підтверджено.

Для оцінки важливі три обмеження. По-перше, частку людської праці не розписано. Що модель зробила самостійно, ззовні перевірити не можна, видно лише патчі виробників. По-друге, число на кшталт 62 CVE показує масштаб, але не автоматично експлуатацію в реальних умовах. Ознак цього в прочитаних текстах немає. По-третє, дані щодо Chrome 156 (20.10.2026) і версії Apple доступні лише через The Hacker News, первинні джерела не відкривалися.

Цикл патчів: коли вразливості знаходять швидше, ніж розповсюджують виправлення

Знайти вразливість — лише частина циклу. Патчинг відбувається децентралізовано: виробники публікують виправлення, дистрибутиви пакують їх, оператори встановлюють. Кожен етап потребує часу. Якщо моделі знаходять більше вразливостей швидше і швидше виводять експлойти з опублікованих виправлень, вікно між виправленням і експлуатацією скорочується. Таке виведення з виправлення називається patch diffing: порівняння старого й нового коду показує, де була помилка.

Федеральне кіберагентство Німеччини вважає, що наразі перевага на боці зловмисників. Експлойти сьогодні з'являються за хвилини чи години. Для підприємств без власного Security Operations Center, тобто без цілодобового моніторингу, це означає: класифікувати повідомлення за терміновістю і мати напоготові екстрений шлях. Як такий процес може виглядати в перші хвилини, показує план дій на перші 60 хвилин у разі ransomware.

З випадків Anthropic випливають два наслідки. Перший стосується обсягу: один-єдиний реліз браузера містив виправлення для 62 повідомлених CVE. Другий стосується темпу: виправлення для Linux потрапило в основну гілку 15 жовтня 2026 року, пакети дистрибутивів вийшли згодом, а коли вони потраплять на сервер, залежить від оператора. Як швидко з'являються експлойти після виправлення, нещодавно було видно і на прикладі вразливості PHP2Shell.

Звідси можна вивести такі рекомендації:

• Регулярний цикл для операційних систем і браузерів скоротити, наприклад щотижня замість щомісяця.
• Автоматичні оновлення браузерів примусово вмикати, а не залишати їх на розсуд окремих користувачів.
• Створити другу доріжку для екстрених випадків, яка обходиться без раунду погодження змін.
• Системи з доступом до інтернету обробляти першими, терміни вимірювати в днях, а не тижнях.

Вразливість, яку модель за години перетворює на експлойт, не чекає на наступний Patch Tuesday.

Виробники ПЗ у Європі: що змінюється в розробці та повідомленнях

Виробники водночас є отримувачами й мішенню таких знахідок. За власним звітом, Anthropic застосовувала скоординоване розкриття з терміном 90 днів і додатковими 45 днями. Це передбачає, що виробники можуть приймати повідомлення, оцінювати їх і швидко виправляти. Сюди належать легко знайдений контакт для повідомлень про безпеку, наприклад через файл security.txt, ресурси для оцінки, виправлення також для старіших stable-гілок і ритм релізів, що допускає дрібні виправлення.

З правового погляду важливий Cyber Resilience Act. За даними Європейської комісії, обов'язки повідомляти про активно експлуатовані вразливості діють з 11 вересня 2026 року, решта основних обов'язків — з 11 грудня 2027 року. Точні строки в тексті закону тут не перевірялися, тому їх не наведено.

Відкритим залишається питання, чи отримають європейські виробники такий самий доступ до оборонних моделей. Наразі є альтернативи: перевірити програми інших постачальників, використовувати вільно доступні інструменти й вбудувати сканування коду у власний конвеєр. Власний висновок: варто виходити з того, що програмне забезпечення перевірятимуть потужні моделі. Хто шукає першим, знаходить помилки раніше за третіх осіб.

Що компанії можуть зробити зараз: Linux-сервери, інвентаризація, терміни патчів

Команди є стандартними інструментами, і перед застосуванням у продуктивному середовищі їх слід перевірити у власному оточенні.

Перевірити Multipath TCP

Згідно з документацією ядра, MPTCP вмикається за запитом (opt-in): застосунки мають запитувати його через тип сокета IPPROTO_MPTCP. Але його можна примусово ввімкнути й ззовні, наприклад інструментом mptcpize. Приклад: починаючи з Go 1.24, listener-и, створені через net.ListenConfig, у Linux за замовчуванням використовують MPTCP. Тож чи може сервер бути вразливим, залежить від запущеного програмного забезпечення. Перемикач net.mptcp.enabled діє для кожного мережевого простору імен (network namespace) окремо і за замовчуванням має значення 1.

Кроки перевірки на сервері:

sysctl net.mptcp.enabled
ss -Mlnp
uname -r
dpkg -l 'linux-image*'
apt policy linux-image-amd64

Перша команда показує перемикач, друга виводить сокети MPTCP, що прослуховують, разом із процесом (опція -M показує лише MPTCP-сокети, для назв процесів потрібні права root), третя — версію запущеного ядра. Дві останні команди (для Debian і похідних систем) показують встановлені пакети ядра та їхню версію. Якщо там працює сервіс на Go, він може з'явитися як MPTCP-listener. Якщо ключа sysctl net.mptcp.enabled немає, ядро не підтримує MPTCP.

Через незрозумілу прив'язку CVE недостатньо просто вимкнути MPTCP. Вирішальним є стан ядра, точніше версія пакета встановленого ядра. Звірка для кожного дистрибутива відрізняється: дистрибутиви часто переносять виправлення в старіші ядра (backport), тому вивід uname -r сам по собі (наприклад 6.1.x) нічого не каже про стан виправлення. Визначальною є версія пакета в бюлетені безпеки відповідного дистрибутива. Debian Security Tracker називає виправленими для bookworm версії 6.1.190-1 (Security) або 6.12.113-1~deb12u1, для trixie 6.12.113-1 і для forky 7.2.12-1. Це стан за даними трекера, і в день впровадження його слід перевірити заново. Сторінки безпеки Ubuntu, Red Hat і SUSE не відкривалися, їх потрібно перевірити самостійно. Після оновлення ядра потрібне перезавантаження, крім випадків із live patching.

Браузери, операційні системи, інвентаризація

• Браузери: Chrome до версії 156 або вище, iOS та iPadOS до 26.5.2 або вище, встановити оновлення Windows. Примусово застосовувати політики оновлень у системі керування пристроями.
• Терміни: браузери й операційні системи з доступом до інтернету першими, терміни в днях. Цифри є орієнтиром.
• Інвентаризація: без переліку активів ніхто не знає, яке ядро працює на якому сервері і чи існує MPTCP-listener. Перелік є основою будь-якого швидкого патчингу.

ШІ на боці захисників: сканування коду в pull request

Pull request — це пропозиція змін до вихідного коду, яку перевіряють перед прийняттям. Сканування коду в pull request дає змогу автоматично додатково перевіряти кожну зміну моделлю. Це доповнює статичний аналіз і людське рев'ю, але не замінює їх. Знахідки мають оцінювати люди, адже хибні спрацювання звичні й забирають час.

Типові налаштування — сканування під час кожного pull request, блокування при критичних знахідках і документування винятків. Захист даних і конфіденційність слід з'ясувати заздалегідь: вихідний код передається постачальнику. Варто перевірити договір і Zero Data Retention, тобто зобов'язання не зберігати вхідні дані. Сторінка Fairwind згадує цю опцію для Argon у Gemini Enterprise. Рекомендації щодо продукту тут свідомо не наводяться.

Погляд ззовні

Перевірка вебсайту показує, які сервіси й технології вебсайт розкриває назовні. Security-Checks доповнюють це видимими недоліками конфігурації. Ні те, ні інше не замінює оновлень ядра чи перевірки коду, але дає погляд ззовні, такий, який мав би і зловмисник.

Висновок: вигравати час, а не наздоганяти інструменти

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

Відкритими залишаються дата для широкої публіки, правила для Європи та незалежне вимірювання заяв Google, за якими варто й далі стежити.