Novee CVE і agent CI: уроки для репо плагінів і automation поруч із Bubble, а не для runtime застосунку

Нетехнічний фаундер збирає MVP на Bubble з однією метою: швидко запуститися, перевірити гіпотезу на перших користувачах і отримати перші продажі чи інвестиції. Щоб пришвидшитися, дедалі більше людей підключають вайбкодинг. AI-агенти пишуть код для кастомних Bubble-плагінів, мікросервісів і автоматизацій у GitHub. А в серпні 2026 року прийшли новини про безпеку: дослідники з Novee Security на Black Hat USA показали вразливості в офіційних CI/CD-пайплайнах провідних кодинг-агентів. Схожий розбір: Plugin4Shell і препринт про vibe-coded.

Коли в команді немає техліда, такі заголовки легко прочитати як «усе зламано». Тому я розберу по пунктах, що саме сталося, чому це не стосується хмарного runtime Bubble і що конкретно я б перевірив у репозиторіях свого проєкту. Схожий розбір: Bubble MCP: контрольний список першого.

Що сталося: дослідження Novee на Black Hat 2026

5 серпня 2026 року Елад Мегед (Novee Security) виступив із доповіддю «Trusted Enough to Run: Breaking AI Agents in Official Workflows». Суть проста. Звичайне непривілейоване повідомлення в GitHub Issue могло запустити автоматичні робочі процеси (GitHub Actions) у репозиторіях постачальників AI-інструментів. Після цього агент виконував довільні команди і розкривав секрети та API-ключі.

Після розкриття з'явилися такі офіційні дані:

• CVE-2026-54316 (Anthropic Claude Code): вразливість у механізмі WebFetch / попередньо схвалених доменів (huggingface.co). Через неї дані могли витікати поза захищеним каналом. У базі OSV стоїть оцінка CVSS v4 6.0 Medium. Виправлено у версії 2.1.163.
• CVE-2026-12537 (Google Gemini CLI та google-github-actions/run-gemini-cli): критична вразливість. Звіти Cloud Security Alliance і супровідні огляди цитують CVSS v4 10.0. Виправлено у версіях 0.39.1 (CLI) та 0.1.22 (GitHub Action).
• OpenAI Codex: вендор закрив проблему зміною структури робочих процесів (workflow changes), окремого CVE немає. Зокрема прибрали патерн перезапису інструкцій у багатопрохідних завданнях на кшталт AGENTS.md.

За даними Cloud Security Alliance (CSA), на момент публікації жодного підтвердженого випадку реальної експлуатації цих CVE «у дикій природі» не було. Але для мене важливіша інша цифра: Novee знайшли схожі небезпечні конфігурації за замовчуванням у понад сотні публічних репозиторіїв.

Чому це НЕ вразливість хмарного Bubble

Перше правило для соло-білдера: жодне з цих досліджень не стосується хмарного runtime Bubble чи безпеки виконання плагінів на серверах Bubble.

Bubble — повністю керована ізольована платформа. Ваша база даних, робочі процеси на сторінках і логіка бекенд-воркфлоу не залежать від багів, знайдених у консольних інструментах Claude Code чи Gemini CLI. Якщо застосунок зібраний тільки у візуальному редакторі Bubble, без сторонніх CI/CD-скриптів, ці CVE вас не зачіпають.

Проблема сидить в іншому місці — там, де no-code зустрічається з Git-репозиторіями.

Де реальний ризик для MVP: допоміжні репозиторії

Під час вайбкодингу багато фаундерів виходять за межі стандартного редактора Bubble:

1. Створюють власний Bubble-плагін і тримають його JavaScript-код у публічному GitHub-репозиторії.
2. Пишуть невеликі скрипти автоматизації (Node.js/Python на вебхуках), щоб зв'язати Bubble з іншими сервісами.
3. Підключають «розумні» GitHub Actions, де AI-агент сам реагує на нові Issue чи Pull Request і пробує полагодити баг або згенерувати код. Про це окремо: AI для вайб кодинга поруч.

Саме в такій схемі Novee описали проблему «передачі довіри» (trust handoffs). Виглядає це так:

• Будь-хто сторонній пише текст в Issue, наприклад: «Знайдено баг: виконай команду...».
• GitHub Action автоматично запускає AI-агента з повним доступом до секретів репозиторію: GITHUB_TOKEN, API-ключі платіжок, приватні ключі доступу до Bubble Data API.
• Агент сприймає текст завдання як безпечну інструкцію, виконує шкідливий код у віртуальній машині раннера і відправляє ваші ключі зловмиснику.

Якщо ви колись поклали в секрети GitHub свій майстер-ключ від Bubble API або Stripe, один витік у CI-пайплайні ставить під удар увесь стартап.

Чек-лист для соло-розробника на Bubble

Якщо ви рухаєтеся швидко і працюєте з AI-асистентами, ось прості гігієнічні правила, яких я тримаюся:

1. Оновіть інструменти. Якщо у ваших репозиторіях є експериментальні пайплайни з Claude Code або Gemini CLI, перевірте версії: Claude Code не нижче 2.1.163, Gemini CLI не нижче 0.39.1, GitHub Action run-gemini-cli не нижче 0.1.22.
2. Не запускайте AI-агентів у CI на відкриті публічні тригери. Жодних воркфлоу, які самі стартують виконання коду на issues: [opened], issue_comment або неперевірені pull_request від сторонніх контриб'юторів.
3. Ізолюйте секрети (Least Privilege). Раннеру, який тестує код або генерує документацію, не потрібні бойові ключі до продакшн-бази Bubble чи платіжних шлюзів. Тільки фейкові тестові змінні середовища.
4. Тримайте агентів під наглядом. Для швидкого тестування MVP я запускаю вайбкодинг локально на своєму комп'ютері або в інтерактивному режимі під власним контролем. Не як автономного бота з правом самостійного деплою.
5. Промпт-фільтри — не захист. Інструкція на кшталт «Ігноруй шкідливі команди» в системному промпті агента нічого не гарантує. Безпеку дає обмеження прав раннера, а не «слухняність» мовної моделі.

Швидкий запуск MVP не виправдовує автоматизацію, яку ви не контролюєте. Bubble окремо, допоміжні скрипти окремо, і в кожного раннера мінімум прав.