Critical RCE у React та вразливість в OpenAI: чому безпека вашого продакшену під питанням
- Таїсія Красноштан
- 10 годин тому
- Читати 4 хв
Грудень приніс індустрії одразу кілька гучних оновлень: TypeScript 7 переходить на нативний компілятор та пришвидшує білди у 8-10 разів, AWS запускає Durable Functions — новий спосіб будувати довготривалі воркфлови прямо в Lambda, а спільнота React зіткнулася з критичною RCE-вразливістю у React Server Components.
У грудневому випуску High Bar Journal Макс Березанський, Tech Lead у Keiki з екосистеми Genesis, аналізує ключові тенденції, які вже впливають на daily-рутину інженерних команд.
Критична RCE-вразливість у React Server Components: терміново оновлюйтесь
У React Server Components виявили критичну RCE-вразливість CVE-2025-55182 із максимальним рейтингом CVSS 10.0. Дефект у механізмі декодування даних (payload) для React Server Functions дозволяє зловмиснику надсилати спеціально сформований HTTP-запит і виконувати довільний код на сервері без автентифікації.
Проблема зачіпає ключові RSC-пакети та низку популярних фреймворків, включно з Next.js, React Router (нестабільний RSC API), Vite RSC plugin, Parcel RSC, Redwood SDK та іншими. Патчі вже доступні — оновлення необхідно встановити негайно, навіть якщо ваш проєкт не викликає Server Functions напряму, але підтримує RSC.
Ця вразливість стала важливим попередженням для команд, які будують продукти на новому серверному стеку React: RSC усе ще перебуває на етапі формування виробничих практик, і подібні інциденти підсвічують, наскільки важливо оперативно оновлювати залежності й уважно стежити за рекомендаціями з безпеки.
AWS запускає Durable Functions: Lambda переходить у новий клас серверлесс-оркестрації
AWS представила Durable Functions for Lambda — можливість запускати складні, багатокрокові, довготривалі процеси без Step Functions та YAML-описів. Вперше Lambda отримує нативну stateful-модель, де вся логіка оркестрації описується у звичайному коді функції.
Durable Functions додають два ключові примітиви — step() та wait() — що дозволяють Lambda:
автоматично зберігати стан після кожного кроку;
призупиняти виконання на години, дні або навіть рік;
відновлюватися після перезапусків без втрати прогресу;
очікувати зовнішні події, колбеки чи результати API;
виконувати операції паралельно (parallel/map).
По суті, це нова модель написання бізнес-логіки: оркестрація не винесена в окремий сервіс, а живе прямо всередині Lambda, у тісному контакті з інфраструктурою AWS.
1. Lambda нарешті виходить за межу 15-хвилинного ліміту. Тепер тривалі задачі (модерація контенту, агентні LLM-процеси, довгі ML-пайплайни) можна виконувати без додаткових контейнерів або кластера Step Functions.
2. Це розблоковує LLM-та ML-workflow на Lambda. Завдяки паузам оплати за час простою (idle compute) можна запускати agent-ланцюжки, повільні LLM-кроки, зовнішні API-полінги та гібридні AI-інтеграції — що перетворює Lambda на зручний runtime для генеративних воркфловів.
3. Модель реентерабельності спрощує відновлення після збоїв. Функція може виконуватися багато разів для однієї й тієї ж задачі, а SDK сам відновить її на потрібному кроці. Це значно підвищує надійність у складних сценаріях.
4. Виклик Step Functions тепер не завжди виправданий. Durable Functions покривають 70-80% типових кейсів оркестрації, але без окремого YAML-опису, без зовнішнього state-engine та з меншими витратами.
Чому це важливо для команд розробки
Для багатьох команд, які поєднували Step Functions, SQS, DynamoDB і кілька Lambda для побудови навіть нескладних workflow, Durable Functions радикально спрощують архітектуру.Новий підхід дозволяє визначати стани безпосередньо в коді функції, а не через YAML-конфігурації, які були обмеженими й не завжди зручними.
Це суттєво підвищує автономність Lambda та наближає серверлесс до моделі «оркестрація як код».
TypeScript 7 переходить на нативний компілятор: білди стають у 8-10 разів швидшими
TypeScript оголосив про найбільше оновлення за всю історію: починаючи з версії 7, компілятор працюватиме не на JavaScript, а як нативний бінарник. Це майже повне «перезбирання» інструменту, яке дозволяє суттєво пришвидшити збірку великих проєктів та зменшити навантаження на CI/CD.
Компіляція стає паралельною, а не послідовною.
Збірки великих проєктів пришвидшуються у 8-10 разів.
Скорочується feedback loop у розробці.
Знижуються витрати на хмарні білди в CI/CD.
Для компаній із великими моно-репозиторіями або складними фронтенд-проєктами це не просто «приємний бонус» — це економія грошей і часу. Швидкі білди означають менше простоїв, швидші інтеграції та менше витрачених ресурсів у хмарі.
Що зміниться у самому TypeScript?
TypeScript 7 також вводить кілька нових правил, про які варто знати:
–strict увімкнено за замовчуванням — код доведеться типізувати акуратніше.
Скасовано підтримку–target es5 — мінімальна версія тепер ES2015.
Старі патерни JSDoc більше не працюватимуть, зокрема @enum та @constructor.
Старі інструменти не сумісні з новим компілятором — їх доведеться запускати окремо або оновлювати.
Microsoft заявила офіційно: версія 6.0 — остання на старому JS-компіляторі, далі — тільки нативна платформа.
TypeScript 7 — це не просто нова версія, а перехід у зовсім інший клас продуктивності.Це сильне оновлення, яке безпосередньо покращує досвід розробників. Якщо ваша команда працює з великими кодовими базами, складними білдами чи CI/CD у хмарі, це оновлення прямо вплине на швидкість розробки, вартість інфраструктури та зручність роботи розробників.
Вразливість в OpenAI Codex CLI
Check Point Research виявила серйозну вразливість в OpenAI Codex CLI, яка дозволяла зловмиснику виконувати довільні команди на машині розробника через звичайний git clone. OpenAI оперативно випустила патч у версії 0.23.0, який блокує небезпечну поведінку.
У чому полягав ризик?
Codex CLI автоматично завантажував локальні конфігурації через Model Context Protocol (MCP). Дослідники виявили, що:
.env у репозиторії міг перенаправити CODEX_HOME на локальну папку,
а ця папка могла містити шкідливу MCP-конфігурацію,
яка виконувалася одразу після запуску codex — без попередження та перевірки.
Це фактично робило будь-який репозиторій потенційним вектором supply-chain атаки: достатньо було, щоб розробник відкрив термінал і запустив Codex CLI.
Можливі наслідки атаки:
виконання довільного коду на машині розробника;
викрадення SSH-ключів, API-токенів та облікових даних;
доступ до приватних репозиторіїв і хмарних ресурсів;
компрометація CI/CD-пайплайнів;
ризики для бізнесу в регульованих галузях.
Це один із перших випадків, коли інструмент для ШI-розробки стає точкою входу у supply chain.
Після патчу, у версії 0.23.0 Codex CLI:
більше не дозволяє перенаправляти CODEX_HOME через .env;
блокує автоматичне виконання локальних MCP-конфігурацій;
не довіряє проектним конфігам за замовчуванням.
Починаючи з версії 0.23.0, використовувати Codex CLI безпечно.Вразливість повністю закрито, а механізм завантаження конфігурацій став набагато стійкішим.
Командам рекомендується:
оновити Codex CLI до актуальної версії;
перевірити CI/CD, де CLI міг використовуватись;
переглянути політику довіри до локальних конфігів у інших інструментах.