Практическая проверка jsonata по GHSA-2943-5xfg-gq5f: диапазон версий, безопасный локальный fixture, критерии PASS/FAIL/Unknown, stop-rule и пакет данных для поддержки без production-секретов.
Что именно проверить в jsonata
Прямой ответ для владельца jsonata: не ищите подтверждение по одному баннеру или общему журналу. Проблема формулируется так: приложение принимает пользовательские выражения и не знает, достаточно ли одной фильтрации строки. Сначала установите provenance зависимости, затем воспроизведите только безопасную границу на одноразовом контексте. Короткий ответ: для jsonata сначала подтвердите фактическую зависимость и границу «npm/jsonata >= 2.0.0, < 2.2.1; первая исправленная версия — 2.2.1». Затем выполните только обратимую проверку на синтетических данных: подтвердить 2.2.1, инвентаризировать точки приёма выражений и проверить разрешённые функции без воспроизведения RCE. Результат считается доказанным лишь при рабочем positive control, явном PASS/FAIL/Unknown и отсутствии побочных изменений. Оценка severity critical взята из GHSA-2943-5xfg-gq5f; локальный статус остаётся Unknown до инвентаризации и control-теста.
Попадает ли сборка jsonata в затронутую границу
Опорный объект — не сервер целиком, а конкретная зависимость npm/jsonata. Reviewed boundary: «npm/jsonata >= 2.0.0, < 2.2.1; первая исправленная версия — 2.2.1». Проверьте lock, manifest контейнера и фактический загруженный модуль; расхождение между ними фиксируйте отдельно. После этого установите конфигурационную достижимость механизма из GHSA-2943-5xfg-gq5f. Не считайте обновление завершённым, пока не совпали source provenance, resolved version и runtime path. Если хотя бы один элемент не наблюдаем, сохраните `Unknown` и передайте владельцу сборки.
Как провести обратимый тест для GHSA-2943-5xfg-gq5f
Постройте fixture вокруг отдельной пользовательской боли, а не вокруг демонстрации уязвимости. Рабочая формулировка: подтвердить 2.2.1, инвентаризировать точки приёма выражений и проверить разрешённые функции без воспроизведения RCE. Материал сохраняет безэксплуатационная карта входов, доверия и разрешённых функций с критериями остановки. Подготовьте пару минимальных локальных fixture: обычный корректный ввод и один синтетический пограничный вариант, который описан в advisory. Данные не должны содержать исполняемую нагрузку, сетевые адреса третьих лиц, реальные письма, ключи или пользовательские объекты. Положительный контроль подтверждает, что разрешённая ветка функционирует; отрицательный — что конкретная граница закрыта. Сохраните hash входа, версию harness и нулевые счётчики побочных действий. Повторять сценарий на production после локального причинного результата не нужно.
Какие наблюдения означают PASS, FAIL или Unknown
Сведите доказательства по слоям: source boundary, локальная сборка, достижимость, test harness, наблюдаемый результат. Сравните выбранную ветку парсера, нормализованный результат, тип ошибки, число созданных объектов и отсутствие побочного выполнения. Сохраняйте hash fixture и версию зависимости, но не сам чувствительный ввод. PASS: обычный control сохраняет ожидаемое поведение, пограничный ввод безопасно отклоняется или нормализуется согласно исправлению, побочных эффектов нет. FAIL: нарушается заявленная граница. UNKNOWN: fixture не достигает нужной ветки либо сборка не подтверждена. Такой формат показывает, где именно появилась неопределённость. Если версия исправлена, но control не достигает нужной функции, нельзя объявлять PASS. Если отрицательный ввод отклонён до компонента внешним фильтром, это компенсация, а не доказательство исправления библиотеки.
Что делать после проверки jsonata
Закрытие задачи требует не только нового номера версии. Нужны исходный inventory, подтверждённый источник релиза, повторный control и результат read-back. Исправленная граница начинается с 2.2.1. Не переносите fixture в production и не расширяйте его до эксплуатационного примера; если для вывода нужен реальный секрет или внешний target, остановитесь. Передавайте в поддержку только package, digest, минимальную конфигурацию, тип fixture, решение и ссылки; секреты и полные production-логи исключите. Если upstream и локальное наблюдение расходятся, статус остаётся Unknown до ответа maintainer.
Какой пакет доказательств сохранить для GHSA-2943-5xfg-gq5f
Evidence-карта этой проверки начинается не с общего списка полей, а с отдельной боли: приложение принимает пользовательские выражения и не знает, достаточно ли одной фильтрации строки. Проверяемая гипотеза формулируется как «подтвердить 2.2.1, инвентаризировать точки приёма выражений и проверить разрешённые функции без воспроизведения RCE». Её практический результат — безэксплуатационная карта входов, доверия и разрешённых функций с критериями остановки. Причина не объединять страницу с соседним advisory: Отдельная версия и механизм GHSA-2943-5xfg-gq5f: JSONata vulnerable to Arbitrary Code Execution via crafted JSONata expressions. Ответ строится вокруг конкретной границы пакета jsonata и не заменяется общим советом по обновлению. В карточке GHSA-2943-5xfg-gq5f сохраните точное имя npm/jsonata, resolved version, digest или commit, состояние функции, границу «>= 2.0.0, < 2.2.1 → 2.2.1», дату fixture, hash синтетического ввода и отдельные результаты positive и negative control. Поля наблюдения зависят от механизма категории `parser`: для границы доступа важны владелец и неизменность объекта; для парсера — нормализованный результат и отсутствие выполнения; для resource-case — время, память и доступность следующего запроса. Содержание входа, токены, адреса, полные логи и пользовательские данные не прикладывайте. Итоговая строка должна позволить другому специалисту повторить решение именно для jsonata, не получая доступ к production. Если upstream summary, локальная сборка и результат fixture расходятся, запишите расхождение дословно как Unknown и передайте его maintainer; не заменяйте отсутствующее доказательство предположением о том, что обновление «скорее всего» достаточно.
Материал подготовлен редакцией VOne с помощью ИИ; версионные границы, прямые источники, безопасный fixture, критерии решения, privacy-ограничения и отсутствие рекламных обещаний перепроверены человеком.
Источники и проверка
- GitHub Reviewed Advisory GHSA-2943-5xfg-gq5f проверено 2026-08-31
- Upstream security source for jsonata проверено 2026-08-31
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.