Node.js/PHP CVE і відповідь Bubble: «без заявленого доступу до даних» — це нотатка платформи, а не дозвіл не перевіряти плагіни

23 жовтня 2026 року Bubble опублікував повідомлення про інцидент, пов'язаний із безпековими виправленнями у Node.js та PHP. Я читав його очима фаундера, який зараз збирає перший MVP на no-code або вайбкодить прототип. Такій людині треба швидко перевірити ідею, показати продукт першим клієнтам і піти з ним до інвесторів. Безпека сервісу для неї щось далеке. Аж до дня, коли платформа публікує офіційне сповіщення про свіжі вразливості. Про це окремо: Governance week: Cursor canvases vs.

На перший погляд текст заспокоює. Bubble пише, що знайшов «no way to use these vulnerabilities to access customer data or gain elevated privileges». Ознак експлуатації не зафіксовано: «no sign of exploitation since the disclosure». І користувачам нічого робити не треба: «No action is required from Bubble users».

Нетехнічний фаундер чує тут зелене світло: «Bubble розібрався, біжу далі». Я б так не робив. Тут легко помилитися в тому, як влаштований no-code.

Що насправді заявив Bubble і де проходить межа відповідальності

Bubble пояснив, як працює його середовище. Частини платформи працюють на Node.js. Команда перевірила безпекові бюлетені й розгорнула патчі. PHP на самій платформі Bubble взагалі не використовується. Ще платформа провела аудит критичних постачальників і заявила, що продовжує моніторинг. Про це окремо: bubble.io is down чи зламав.

Але це звіт виключно про власну інфраструктуру хостингу.

Подивіться на офіційну політику розкриття вразливостей (Vulnerability Disclosure Policy). У межах оцінки Bubble лише сам хостинг і софт, який компанія розробила сама. Сторонні плагіни («3rd-party plugins not developed by Bubble») там прямо винесені за ці межі.

У довідці Security описана модель спільної відповідальності (shared security responsibility) між Bubble, AWS та авторами застосунків. Хостинг закриває дірки в ядрі серверів. Логіка, облікові записи й налаштування вашого застосунку повністю на вас.

Чому сторонні плагіни та інтеграції залишаються під питанням

Коли швидко збираєш MVP з AI-підказками чи готовими блоками, майже напевно ставиш плагіни з маркетплейсу: платіжні модулі, UI-компоненти, конектори до сторонніх сервісів.

Якщо у вас немає технічного бекграунду, тримайте в голові три речі:

1. Плагіни можуть звертатися до сторонніх серверів. Якщо автор плагіна написав бекенд на PHP чи Node.js на власному окремому сервері, патч усередині Bubble його ніяк не захищає.
2. Спільнота дивиться на приватні API. У гілці форуму Bubble (PHP2Shell - Any impact on Bubble apps or services?) розробники пишуть, що потенційний ризик виникає саме через плагіни на приватних серверах або зовнішні PHP API. Це неофіційні застереження, але вектор вони показують чітко: хостинг Bubble ізольований, а ваші зовнішні зв'язки — ні.
3. «No action required» стосується лише рушія Bubble. Це не сертифікат того, що ваш застосунок, ключі доступу чи конфігурація плагінів автоматично стали безпечними.

Безпека MVP: що реально потрібно зробити перед релізом

Не намагайтеся «лікувати» рантайм платформи в редакторі. Доступу до серверів Bubble у вас немає, і він не потрібен. Захистіть те, на чому тримається довіра перших користувачів:

1. Налаштуйте Privacy Rules. Документація Bubble (Protecting data with privacy rules) називає правила приватності критично необхідними для захисту чутливих даних, бо вони виконуються на стороні сервера. Якщо у вашій базі немає Privacy Rules, будь-який відвідувач прочитає таблиці через браузер. Жоден патч Node.js на сервері платформи тут не допоможе.
2. Проведіть ревізію плагінів. Залиште в MVP лише ті модулі, без яких не перевірити гіпотезу. Закинуті експериментальні плагіни від невідомих розробників видаліть.
3. Ізолюйте секрети й API-ключі. Перевірте, що приватні ключі сервісів (Stripe, OpenAI, поштові шлюзи) не світяться на клієнтській стороні у workflows і плагінах. Про це окремо: Node.js/PHP CVE і відповідь Bubble:.

Те, що через вразливості платформи ніхто не дістався до даних клієнтів, — хороша новина для всієї екосистеми. Але перші клієнти оцінюватимуть не Bubble, а вас. І репутацію вашого стартапу визначить те, наскільки акуратно ви налаштували доступ до даних у власному продукті.