PHP2Shell вас не зачепив? Перевірте Next.js і Node.js

Крок 1: спитати, на чому працює застосунок, і в якій версії на проді

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

Так знайшлась неочевидна проблема: у налаштуваннях стояло Node.js «20 або вище». Node 20 уже без підтримки, а за офіційним оголошенням Node.js непідтримувані версії завжди вважаються вразливими й виправлень не отримують. Якби прод працював на 20-й гілці, автор цього не помітив би. Рішення: зафіксувати прод на 24-й гілці. Виправлені версії жовтневого релізу: 22.23.4, 24.22.1, 26.12.1.

Далі йде перевірка релевантності, поки без змін: Я бачив новину про вразливість X. Перевір офіційні оголошення розробників компонентів цього застосунку, скажи, чи це нас стосується, і дай URL джерел. Поки нічого не змінюй. Агент оцінив, що три діри в Next.js 16.3.8 за такого використання «не впливають або майже не впливають». Оновитись він усе одно радив, бо невикористані функції іноді працюють у фоні. Next.js в оголошенні теж закликає оновлюватись, навіть якщо схожих функцій у вас немає.

Крок 2: оновлення лише через локальну перевірку

Агент запропонував чотири дії: оновити Next.js, зафіксувати Node на 24, оновити dev-інструменти, перевірити все на тестових даних. Автор відповів одним рядком: 1–4, будь ласка. У результаті Next.js оновився з 16.3.8 до 16.4.3, React — з 19.2.4 до 19.2.9. Що перевірити перед продом:

• логін, створення замовлення, список, вивантаження звітів — на тестових, не реальних даних;
• що без логіну дані отримати не можна;
• що зміни можна відкотити;
• після деплою — ззовні: екрани відкриваються, запит даних без логіну відхиляється.

Першу перевірку автор зробив ще 8 жовтня, запитом про загальну безпеку. Тоді після оновлення компонентів кількість попереджень про вразливості на проді впала з 10 до 1. Лишилось попередження рівня medium, яке, за оцінкою, до цього сценарію не застосовне.

Крок 3: розібрати дозволи, а не чистити одразу

Кожне «Don't ask again» зберігається в .claude/settings.local.json і діє для подальшої роботи в цій папці. У проєкті накопичилось 60 дозволів: читання широкої частини диска, запуск будь-яких програм, push у GitHub і видалення файлів без запиту. Правил заборони не було жодного (у глобальних налаштуваннях їх було 5). Документація перевіряє правила в порядку заборона → підтвердження → дозвіл, тож заборона спрацює навіть за наявного дозволу.

Автор не дав змінювати налаштування одразу й попросив план «до/після»: Покажи поточні дозволи Claude Code для цієї папки і план після чистки, поруч. Розділи на «лишити», «питати щоразу», «заборонити», з причинами. Поки нічого не змінюй.

• лишити: щоденні операції, зокрема лише читання;
• питати щоразу: push у GitHub, видалення, додавання компонентів;
• заборонити: читання файлів із секретами й даними проду, зміну агентом власних дозволів.

Коли автор написав «Approved» з іншого екрана, Claude Code нічого не переписав: зміну дозволів він чекав підтвердити саме там. Для регулярного аудиту документація радить /permissions, а перед пушем є /security-review.

Де прийом ламається

Заборони на читання й запис працюють для файлових інструментів Claude і команд на кшталт cat. Вони не спрацьовують, коли Python- чи Node-скрипт відкриває файл опосередковано. Закрити це на рівні ОС може sandbox, але на нативному Windows він не підтримується, лише через WSL 2. Тому надійніше не тримати секрети й клієнтські дані в робочій папці взагалі, а в чаті маскувати імена й суми. Решта шарів: приватний репозиторій, правило проти секретних файлів у GitHub, 2FA для GitHub і хостингу.

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