Браузери з вбудованим штучним інтелектом стають новою ціллю для атак, і історія з ІІ‑браузером Comet від Perplexity це наочно підтверджує. Компанія SquareX, що спеціалізується на безпеці браузерів, оприлюднила дослідження про критичну уразливість MCP API, яка дозволяла обійти пісочницю браузера та виконувати команди на пристрої користувача.
Як SquareX виявила уразливість у браузері Comet
За даними SquareX, проблема була пов’язана з малодокументованим MCP API chrome.perplexity.mcp.addStdioServer, доступним із вбудованих компонентів Comet. Дослідники встановили, що через цей API можливо ініціювати виконання локальних команд, минаючи звичні механізми ізоляції браузера. Компанія Perplexity вже випустила виправлення, однак публічно поставила під сумнів коректність висновків дослідження.
Прихований MCP API та роль розширень Agentic і Analytics
MCP (Model Context Protocol) — це протокол, який дозволяє ІІ‑моделям безпосередньо взаємодіяти з зовнішніми джерелами даних і локальним середовищем. У Comet цим протоколом користуються два вбудовані та невідключувані розширення — Agentic та Analytics. Вони не відображаються як стандартні доповнення браузера, проте мають розширені привілеї для роботи з MCP API.
Agentic відповідає за «агентські» автоматизовані дії від імені користувача, тоді як Analytics збирає телеметрію та відстежує активність Agentic. Формально їх взаємодія обмежена піддоменами perplexity.ai, однак саме поєднання привілейованого API та невидимих розширень створює значний архітектурний ризик для безпеки ІІ‑браузера.
Обхід пісочниці браузера через MCP: чому це критично
За оцінкою SquareX, MCP API дозволяв обійти браузерну пісочницю та запустити довільні команди в операційній системі без явного діалогу з користувачем. На відміну від класичних атак у браузері, де зазвичай йдеться про викрадення даних або сесійну підміну, тут мова йде про потенційне виконання довільного коду з усіма наслідками: шкідливе ПЗ, бекдори, шифрувальники тощо.
Сценарій атаки SquareX: extension stomping та запуск шифрувальника
Щоб продемонструвати ризики, дослідники застосували техніку extension stomping — підміну легітимного розширення його шкідливою копією. Вони створили розширення, яке маскується під штатний Analytics, і через нього змусили Agentic викликати MCP API. У контролюваному середовищі це дозволило запустити на тестовій машині варіант шифрувальника WannaCry, відомого масовими інцидентами у 2017 році.
SquareX наголошує, що це proof‑of‑concept, але в реальних умовах подібний ланцюжок міг бути реалізований через XSS на довірених піддоменах, атаки типу «людина посередині» (MitM) або компрометацію ланцюга поставок. У разі порушення цілісності інфраструктури perplexity.ai наслідки для всієї бази користувачів Comet могли б бути масштабними.
Реакція Perplexity: «фейкова» загроза та акцент на людському факторі
Perplexity у коментарях для ЗМІ назвала звіт SquareX «фейковим» та заявила, що описаний сценарій є штучним і не відображає реального ризику. Представники компанії стверджують, що для підміни вбудованого розширення знадобився б зловмисник з внутрішнім доступом до продакшн‑систем, а локальні MCP‑сервери та виконання команд начебто завжди вимагають підтвердження користувача.
Perplexity також повідомила, що не отримала повного технічного звіту від SquareX, що, за її словами, ускладнило процес відповідального розкриття уразливості. Водночас відеодемонстрація від SquareX дійсно містить низку ручних дій з боку користувача, що компанія використовує як аргумент на користь низької ймовірності практичної експлуатації.
Патч для Comet і відкриті питання до процесів безпеки
За інформацією SquareX, Perplexity була повідомлена про проблему 4 листопада 2025 року. Прямої відповіді дослідники нібито не отримали, однак нещодавно в Comet тихо з’явилося оновлення: при спробі експлуатації уразливості браузер тепер повертає помилку «Local MCP is not enabled», і продемонстрований раніше метод більше не працює.
SquareX оцінює це як позитивний результат, що підвищує рівень безпеки ІІ‑браузера. Водночас відсутність публічного сповіщення про усунення критичної уразливості і непрозора комунікація ставлять питання до зрілості процесів управління ризиками та вразливостями на боці Perplexity.
Архітектурні ризики ІІ‑браузерів та MCP: уроки для індустрії
Ситуація з Comet демонструє системний ризик підходу, коли привілейовані ІІ‑розширення поєднуються з потужними API, здатними виходити за межі пісочниці браузера. Навіть за обмеження доступу «довіреними» доменами будь‑який збій у ланцюгу довіри — від компрометації DNS до зламу CI/CD — перетворює таку архітектуру на привабливу мішень для атак.
Найкращі практики кібербезпеки вимагають прозорості вбудованих компонентів, можливості їх відключення, принципу найменших привілеїв та жорсткої сегментації прав доступу. Для MCP це означає чітке розмежування: які операції допускаються локально, які потребують багатофакторного підтвердження, а які взагалі не повинні бути доступні з браузера.
Рекомендації користувачам та розробникам ІІ‑браузерів
Користувачам ІІ‑браузерів, зокрема Comet, варто регулярно оновлювати програмне забезпечення, обережно ставитися до встановлення сторонніх розширень, перевіряти джерела завантажуваних файлів і використовувати сучасні рішення класу EDR/антивірус. Не менш важливі регулярні резервні копії та обмеження прав користувацьких облікових записів.
Розробникам ІІ‑браузерів слід закладати secure‑by‑design архітектуру: проводити threat modeling для MCP та агентських розширень, запускати bug bounty‑програми, детально документувати привілейовані API та фіксувати зміни безпеки в публічних журналах версій. Такий підхід підвищує довіру до продукту та зменшує ймовірність того, що критичні уразливості довго залишатимуться непоміченими.
Історія з MCP API в Comet показує, що розвиток ІІ‑функцій у браузерах неминуче відкриває нові вектори атак. Щоб зберегти баланс між зручністю та безпекою, варто регулярно переглядати налаштування захисту, цікавитися публічними звітами про уразливості та системно підвищувати рівень кібергігієни — як користувачам, так і розробникам ІТ‑рішень.
