Разработчик Firefox перепутал два символа — и подарил хакерам RCE-уязвимость в движке JavaScript
NewsMakerКак один неправильный символ довел Mozilla до истерики.
В движке JavaScript SpiderMonkey, который используется в Mozilla Firefox, нашли критическую уязвимость удалённого выполнения кода (RCE) . Источник оказался почти анекдотическим: одна опечатка в один символ в коде сборщика мусора для WebAssembly, где разработчик поставил побитовое AND & вместо побитового OR |.
Ошибка находилась в реализации сборки мусора WebAssembly и появилась после рефакторинга метаданных массивов WebAssembly. Уязвимость внесли коммитом fcc2f20e35ec от 19 января 2026 года в файле js/src/wasm/WasmGcObject.cpp. Проблемная строка выглядела так:
В движке JavaScript SpiderMonkey, который используется в Mozilla Firefox, нашли критическую уязвимость удалённого выполнения кода (RCE) . Источник оказался почти анекдотическим: одна опечатка в один символ в коде сборщика мусора для WebAssembly, где разработчик поставил побитовое AND & вместо побитового OR |.
Ошибка находилась в реализации сборки мусора WebAssembly и появилась после рефакторинга метаданных массивов WebAssembly. Уязвимость внесли коммитом fcc2f20e35ec от 19 января 2026 года в файле js/src/wasm/WasmGcObject.cpp. Проблемная строка выглядела так:
oolHeaderOld->word = uintptr_t(oolHeaderNew) & 1;oolHeaderOld->word = uintptr_t(oolHeaderNew) | 1;Было полезно? Не теряйте нас!
Подпишитесь, чтобы ничего не пропустить
Подпишитесь, чтобы ничего не пропустить
Опечатка затронула функцию WasmArrayObject:
bj_moved(). Она вызывается, когда сборщик мусора перемещает массивы WebAssembly из одного места в памяти в другое. Для массивов типа out-of-line данные лежат отдельно от «объектной оболочки», в отдельном буфере. При переносе такого массива старый буфер должен получать forwarding pointer, указатель-переадресацию на новый адрес данных. Такой указатель отличают от обычного заголовка простым трюком: выставляют младший бит в 1. Это нужно, чтобы JIT-компилятор Ion (оптимизирующий компилятор SpiderMonkey) мог быстро понять, что перед ним не обычный заголовок, а именно переадресация.
Из-за нулевого значения forwarding pointer начинала ломаться логика распознавания формата массива. В isDataInline() проверка устроена так:
Важная деталь: уязвимость проявлялась только в WebAssembly-функциях, которые успел оптимизировать Ion. В Baseline-компиляторе такого механизма обновления кадров стека при moving GC нет, поэтому там баг не триггерился.
Уязвимость обнаружил исследователь по никнейму Erge. Он изучал исходники Firefox 149 Nightly, подбирая идеи для задания в CTF, и сумел довести ошибку до выполнения кода внутри renderer-процесса Firefox.
Дальше Erge собрал proof-of-concept, который превращал логическую ошибку в полноценный захват управления. Цепочка выглядела так:
Ключевой момент для практического риска: уязвимость затрагивала только Firefox 149 Nightly и не дошла до релизных веток. То есть пользователи стабильных версий не получили этот баг через обычные обновления, а окно для массовой эксплуатации осталось закрытым.
bj_moved(). Она вызывается, когда сборщик мусора перемещает массивы WebAssembly из одного места в памяти в другое. Для массивов типа out-of-line данные лежат отдельно от «объектной оболочки», в отдельном буфере. При переносе такого массива старый буфер должен получать forwarding pointer, указатель-переадресацию на новый адрес данных. Такой указатель отличают от обычного заголовка простым трюком: выставляют младший бит в 1. Это нужно, чтобы JIT-компилятор Ion (оптимизирующий компилятор SpiderMonkey) мог быстро понять, что перед ним не обычный заголовок, а именно переадресация. Из-за нулевого значения forwarding pointer начинала ломаться логика распознавания формата массива. В isDataInline() проверка устроена так:
(headerWord & 1) == 0Важная деталь: уязвимость проявлялась только в WebAssembly-функциях, которые успел оптимизировать Ion. В Baseline-компиляторе такого механизма обновления кадров стека при moving GC нет, поэтому там баг не триггерился.
Уязвимость обнаружил исследователь по никнейму Erge. Он изучал исходники Firefox 149 Nightly, подбирая идеи для задания в CTF, и сумел довести ошибку до выполнения кода внутри renderer-процесса Firefox.
Дальше Erge собрал proof-of-concept, который превращал логическую ошибку в полноценный захват управления. Цепочка выглядела так:
- Провоцировалась «малая» сборка мусора (minor GC), при переносе массива в заголовок старого буфера попадал ноль вместо forwarding pointer.
- В wasm::Instance::updateFrameForMovingGC (часть Ion) массив из-за нуля распознавался как inline.
- Вместо нового адреса данных функция возвращала старый адрес, из-за чего кадры стека не обновлялись под перенос.
- Ion продолжал работать со старой областью памяти, хотя она уже освобождена, возникало use-after-free (UAF) .
- Дальше шёл heap spraying: исследователь «засорял» кучу значениями вроде 0x41414141, чтобы занять освобождённые блоки контролируемыми данными.
- За счёт контроля базы OOL-массива получались примитивы произвольного чтения и записи.
- Для обхода ASLR использовался спрей объектов, содержащих указатели с относительной адресацией, привязанные к относительным адресам внутри бинарника, что позволяло восстановить нужные смещения.
- Затем перезаписывался vtable, чтобы перехватить поток выполнения (hijack RIP) и вызвать произвольные системные команды.
- В финале эксплойт вызывал system() и поднимал shell, запускав /bin/sh.
Ключевой момент для практического риска: уязвимость затрагивала только Firefox 149 Nightly и не дошла до релизных веток. То есть пользователи стабильных версий не получили этот баг через обычные обновления, а окно для массовой эксплуатации осталось закрытым.