Node.js를 넘어선 Brotli 취약점, 어디까지 점검하고 디코딩은 끌 수 있나

취약점의 범위는 런타임을 넘어섭니다

'Node2Shell: Node.js Brotli 취약점으로 원격 코드 실행 가능 (CVE-2026-111497)'은 Node.js의 Brotli 디코더가 조작된 입력을 처리할 때 메모리 범위를 벗어나 쓸 수 있다고 설명합니다. 입력은 Express 5·body-parser 2.x가 받는 Brotli 압축 요청, 외부 서버의 응답을 자동으로 푸는 fetch(), 또는 node:zlib을 통한 직접 디코딩에서 들어올 수 있습니다. Node.js는 22.23.4, 24.22.1, 26.12.1로 업데이트하도록 안내하며, Bun도 1.4.4 이상이 수정 버전이라고 밝힙니다.

'Node2Shell 취약점, Python의 Brotli·brotlicffi 패키지에도 영향'은 결함이 Node.js에만 한정되지 않는 이유로 공유 C 디코더를 듭니다. 이 글에 따르면 PyPI의 Brotli와 brotlicffi도 취약한 디코더를 포함하며, 각각 1.2.1과 1.2.1.0이 수정 버전입니다. Brotli가 설치된 환경에서 urllib3·requests, httpx의 brotli 추가 기능, aiohttp 등이 외부 응답을 자동으로 해제할 수 있고, 요청 본문을 해제하는 서버도 영향을 받을 수 있다고 설명합니다.

두 글은 같은 디코더 결함을 다루지만 확인할 대상은 다릅니다. Node.js 대응은 런타임과 컨테이너 이미지의 버전 확인·재배포를 요구하는 반면, Python 쪽은 패키지 버전을 확인하고 해당 패키지가 포함된 이미지나 휠도 갱신하라고 안내합니다. Python 글은 당시 스캐너가 두 패키지를 경고하지 않을 수 있다고 지적합니다. 심각도 표현도 Node.js 글은 ‘high’, Python 글은 CVSS 9.2 ‘Critical’로 각각 전하므로, 한쪽의 등급으로 다른 쪽의 평가를 대체할 수는 없습니다.

패치와 기능 비활성화는 같은 대응이 아닙니다

'브로틀리와 작별할 때인가? 구글 압축 라이브러리의 보안 난맥상'은 이번 결함뿐 아니라 과거 압축 폭탄 대응 과정의 문서화 부족과 수정 배포 지연을 들어 Brotli의 유지·배포 관행을 비판합니다. 이는 해당 글 작성자의 평가입니다. 앞의 두 글이 수정된 런타임이나 패키지로 업데이트하라고 안내하는 것과 달리, 이 글은 Brotli 지원 자체가 필요한지 검토하자는 관점을 더합니다.

다만 기능을 끄는 선택지는 서비스가 Brotli를 쓰지 않아도 되는지에 따라 달라집니다. Bugsink 글은 Python Sentry SDK가 Brotli로 보낸 메시지를 받기 때문에 디코딩을 완전히 없애기는 쉽지 않다고 설명하고, 자체 호스팅 사용자가 필요하지 않을 경우를 위해 기능을 끄는 옵션을 추가하고 있다고 밝힙니다. Node.js 글도 Brotli 요청을 엣지에서 거부하는 조치는 외부 서버에서 가져오는 Brotli 응답까지 막지 못하며, 취약점을 제거하는 방법은 런타임 업데이트라고 선을 긋습니다. 따라서 디코딩 비활성화는 사용 경로를 줄이는 선택지이지, 모든 환경에서 패치를 대신한다고 볼 수 없습니다.