Supply Chain атака на npm: Shai-Hulud — угроза, которая заражает проекты

Недавняя атака на экосистему npm под названием Shai-Hulud привлекла внимание разработчиков по всему миру. Это масштабная supply chain атака, которая затронула более 500 пакетов, включая популярные библиотеки, такие как ngx-toastr, tinycolor, react-jsonschema-form-extras и пакеты от CrowdStrike.

❌ Заражённые пакеты содержат вредоносный скрипт bundle.js. Этот скрипт запускает TruffleHog для поиска секретных данных, таких как GitHub токены, NPM ключи или AWS креды, и отправляет их на внешний сервер. Дополнительно создаётся вредоносный workflow в папке .github/workflows, который будет автоматически запускаться при каждом CI-процессе. В итоге, атака действует как червь, распространяясь через каждый новый пакет, заражая downstream-проекты.

ℹ️ Что делать разработчикам

• Проверить проекты на наличие заражённых версий пакетов
• Ротировать npm-токены, GitHub PAT и облачные креды, чтобы минимизировать последствия
• Аудитировать CI/CD конфигурации для выявления подозрительных изменений
• Обновлять пакеты только из доверенных источников, избегать использования сомнительных версий

📌 Supply chain атаки становятся всё более изощрёнными и опасными. Ранее мы переживали только за typosquatting, а теперь столкнулись с реальными «npm-червями», которые могут заразить проекты на всех уровнях. Если вы работаете с публичными пакетами, регулярный аудит зависимостей и CI/CD — теперь часть обязательной практики.

🚪 Frontender's notes

⭐️ Что нового в Chrome DevTools 2025?

Никто не может отрицать, что Chrome DevTools стал незаменимым инструментом для фронтенд-разработчиков. В последние обновления DevTools добавили несколько фич, которые действительно меняют картину и значительно упрощают повседневную работу.

➕ Performance Insights 2.0

Раньше для того, чтобы понять, почему страница тормозит, нам приходилось долго и упорно искать узкие места, но теперь Chrome стал намного умнее. В новой версии DevTools есть подробный анализ производительности, который не только показывает графики, но и дает точные рекомендации.

✅ Что изменилось

— Chrome теперь подскажет, какие узлы тормозят перерисовку
— Вы увидите проблемы с reflow и repaint без необходимости вручную искать их в графиках
— Появились рекомендации, как сократить количество лишних рендеров, что позволяет улучшить производительность без глубоких исследований

➕ Новый инспектор анимаций

С анимациями стало неразрывно связано большинство интерфейсов, и теперь DevTools имеет свою вкладку для их отладки. Это полезная фича для тех, кто работает с динамическими эффектами на страницах.

✅ Что можно делать теперь

— Замедлять анимации и визуализировать их таймлайн
— Сравнивать разные keyframes и анализировать, как анимация ведет себя на разных этапах
— Проверять кривые Безье и анализировать плавность переходов без сторонних инструментов, таких как Lottie Inspector

➕ Подсветка больших DOM-узлов и CSS Scope Debugging

— Когда в DOM появляются элементы с тысячами дочерних узлов, это может привести к огромным задержкам. Теперь DevTools подскажет, где именно могут возникать лаги, если структура DOM слишком громоздкая.

— С появлением новых фич в CSS (например, :scope и scoped-стилей), стало сложнее отслеживать, какие правила применяются к конкретному элементу. В DevTools теперь можно легко фильтровать стили по scope.

📌 В общем, эти обновления в Chrome DevTools — это неплохая помощь для тех кто работает с крупными и сложными интерфейсами.

🚪 Frontender's notes

Баланс: pet-проекты vs работа

Каждый разработчик хоть раз ловил себя на мысли: “Хочу сделать свой проект. Но после работы нет ни сил, ни желания писать код.”
И вот тут начинается борьба между желанием развиваться и желанием просто отдохнуть.

✅ Pet-проекты — это топливо для роста.
Ты пробуешь новые технологии без дедлайнов, без легаси и без код-ревью с “а зачем тут вообще useMemo?”.
Это та самая зона, где возвращается интерес к разработке, особенно когда на работе монотонные задачи.

Но.

🙅‍♂️ Pet-проект не должен превращаться во вторую работу.
Если ты после 8 часов продакшена садишься за ещё 4 часа кода — это не развитие, это выгорание в красивой обёртке.

И так: как найти баланс?:

🔘 Делай pet-проекты короткими и законченными.
Маленький тул или демо — лучше, чем вечный “стартап мечты”.
🔘 Ставь себе ограничение по времени.
Например, кодишь только 2 вечера в неделю.
🔘 Не чувствуй вины, если не делаешь ничего.
Отдых — тоже часть продуктивности.
Мой личный опыт:
Pet-проекты реально помогают не терять интерес к коду.
Но только когда они не конкурируют с отдыхом, а заменяют бессмысленный скролл YouTube чем-то, что тебя вдохновляет.

Итог:
Работа — даёт стабильность.
Pet-проекты — дают развитие.
Отдых — даёт энергию, чтобы выдержать первые два пункта.

Главное — не забывать, что кодить “в кайф” иногда важнее, чем кодить “всё время”.

⚡️ Анти-паттерны больших фронтенд-проектов

Большие фронтенд-проекты не рушатся из-за одной ошибки. Чаще всего их «убивают» мелкие, но системные ошибки в архитектуре, которые приводят к бесконечным поломкам. Давайте рассмотрим самые частые анти-паттерны, с которыми сталкиваются реальные команды.

ℹ️ «Глобальное всё»

Когда всё в проекте глобальное: стили, состояния, утилиты. Это создаёт цепочку зависимостей, и любая правка может привести к непредсказуемым поломкам.

Решение: строгое разделение на модули, использование неймспейсов и изоляция слоёв. Это поможет избежать нежелательных побочных эффектов и сделает код более предсказуемым.

ℹ️ «Компоненты-монолиты»

Когда в коде все компоненты отвечают за UI, бизнес-логику, запросы, валидацию и управление состоянием, это может привести к тому, что код станет сложным для тестирования, переиспользования и чтения.

Решение: Для улучшения структуры и поддерживаемости кода необходимо разделить его на слои: UI, управление состоянием, доменная логика и взаимодействие с API.

ℹ️ «Push-архитектура»

Каждый компонент тянет данные сам и вот тут начинается хаос: дублирование запросов, гонки условий, зависимости на каждом шагу.

Решение: централизованный слой данных. Используйте query-клиенты, сервисы или модели для эффективного управления данными.

ℹ️ «Секретные зависимости»

Компоненты, которые используют скрытые зависимости, такие как localStorage, window, сторонние сервисы или скрытые контексты, не указаны явно.

Решение: всегда документируйте зависимости и явно описывайте их в коде. Это упростит тестирование и переносимость компонентов.

ℹ️ «Тяжёлые re-render цепочки»

Когда один компонент меняет state, и пол-страницы перерисовывается, вызывая лаги и замедление интерфейса.

Решение: используйте signals, selectors и fine-grained реактивность. Архитектурная изоляция поможет минимизировать лишние ререндеры.

ℹ️ «Всё через Redux / Context / глобальный стор»

Когда вы храните глобальный стейт там, где он должен быть локальным. В итоге глобальное состояние становится тяжёлым и трудным для управления.

Решение: минимизируйте использование глобального стейта. Локальные состояния должны храниться локально.

ℹ️ «Типизация по настроению»

Когда часть кода типизирована, а часть — нет, или используется any. В итоге типизация не защищает, а мешает.

Решение: установите единые правила типизации и используйте строгий линтинг для соблюдения этих правил.

ℹ️ «Сложность вместо простоты»

Когда для решения простых задач используются сложные абстракции, кастомные DI, самописные хуки и роутеры, что усложняет поддержку кода.

Решение: используйте стандартные подходы и решения, не усложняйте систему без нужды. Простейшие функции могут быть более чем достаточны.

ℹ️ «Отсутствие архитектурных границ»

Когда компоненты могут импортировать что угодно и откуда угодно, проект превращается в клубок зависимостей, которые сложно отслеживать.

Решение: используйте feature-sliced или modular архитектуру, следите за слоями, внедрите статический анализ зависимостей и запретите пересечения между слоями.

📌 Большие проекты не рушатся на раз-два. Они как бы потихоньку «гниют», но если у вас хорошая архитектура, дисциплина и вы регулярно что-то улучшаете, то можно избежать многих проблем.

🚪 Frontender's notes

Критическая уязвимость в React Server Components (CVSS 10.0). Рекомендуется обновление

🚨 React-команда официально сообщила о серьёзной проблеме безопасности в React Server Components.
Уязвимость позволяет выполнить произвольный код на сервере без аутентификации — достаточно отправить специально сформированный HTTP-запрос.

Даже если вы не используете React Server Functions напрямую — вы всё равно можете быть уязвимы, если ваш проект поддерживает React Server Components.

Уязвимость получила идентификатор CVE-2025-55182, оценку CVSS 10.0, и затрагивает версии 19.0, 19.1.0, 19.1.1 и 19.2.0 следующих пакетов:

react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack

🔘Что делать прямо сейчас

Патч уже опубликован. Нужно обновиться на версии: 19.0.1, 19.1.2, 19.2.1.
Если ваш React-код вообще не работает на сервере, или вы не используете фреймворки/бандлеры с поддержкой RSC, то вы не затронуты.

Некоторые экосистемы зависели от уязвимых пакетов. В зоне риска:

Next.js
React Router (нестабильные RSC-API)
Waku
@parcel/rsc
@vitejs/plugin-rsc
Redwood SDK

Команда React работает с хостинг-провайдерами, и временные смягчения уже включены.
Но на них рассчитывать нельзя — обновляться всё равно нужно.

🔘В чём суть уязвимости

React Server Functions позволяют клиенту вызывать функции на сервере. На стороне клиента вызов превращается в HTTP-запрос, который React затем десериализует и мапит на вызов серверной функции.

Проблема — в том, как React декодирует payload от клиента.
Атакующий может создать вредоносный HTTP-запрос, который при десериализации приводит к удалённому выполнению кода.

Подробности раскроют позже, когда обновления будут полностью раскатаны.

🔘Инструкция по обновлению Next.js

Установите патч в рамках вашей версии:

npm install next@15.0.5
npm install next@15.1.9
npm install next@15.2.6
npm install next@15.3.6
npm install next@15.4.8
npm install next@15.5.7
npm install next@16.0.7

Если вы сидите на 14.3.0-canary.77 или выше — откатитесь на стабильную 14.x:

npm install next@14

React Router (нестабильные RSC API)

Обновите зависимости:

npm install react@latest
npm install react-dom@latest
npm install react-server-dom-parcel@latest
npm install react-server-dom-webpack@latest
npm install @vitejs/plugin-rsc@latest

Expo
См. changelog на expo.dev.

Redwood SDK
npm install rwsdk@latest
npm install react@latest react-dom@latest react-server-dom-webpack@latest

Waku
npm install react@latest react-dom@latest react-server-dom-webpack@latest waku@latest

Vite RSC
npm install react@latest react-dom@latest @vitejs/plugin-rsc@latest

Parcel RSC
npm install react@latest react-dom@latest react-server-dom-parcel@latest

Turbopack RSC
npm install react@latest react-dom@latest react-server-dom-turbopack@latest

Webpack RSC
npm install react@latest react-dom@latest react-server-dom-webpack@latest

📅 Таймлайн

29 ноября — уязвимость найденa и отправленa в Meta Bug Bounty.
30 ноября — Meta подтвердила и начала работать над фиксом с командой React.
1 декабря — фикc готов, идёт работа с хостингами и OSS-проекта́ми над валидацией и mitigations.
3 декабря — патч опубликован, уязвимость раскрыта публично.

📍 Ссылка на оригинал статьи...