요약
압축 형식 Brotli의 디코더 결함이 Node.js를 넘어 파이썬과 여러 HTTP 도구로 번졌습니다.
보안 업체 아이키도 시큐리티가 Node.js가 Node2Shell로 공개한 CVE-2026-111497의 영향 범위를 정리했습니다. 구글 Brotli 디코더의 메모리 범위 밖 쓰기 결함으로, GitHub은 CVSS 9.2(치명)로 평가했습니다.
왜 중요한가
- 코드에서 Brotli를 직접 쓰지 않아도 설치만 돼 있으면 requests, httpx, aiohttp 같은 HTTP 클라이언트가 자동으로 씁니다.
- 악성 클라이언트는 서버를, 악성 서버는 압축 응답을 받는 클라이언트를 노릴 수 있어 공격 방향이 양쪽으로 열려 있습니다.
- 10월 23일 기준 pip-audit, Dependabot, Safety가 취약한 PyPI 버전을 잡지 못해 의존성 스캐너만 믿을 수 없습니다.
핵심 내용
- 블록 전환을 처리하는 함수가 형식 오류와 입력 부족을 구분하지 못해, 조작된 스트림이 낡은 상태로 디코딩을 이어 가게 만듭니다.
- 수정판은 Brotli 1.2.1, brotlicffi 1.2.1.0, Node.js 24.22.1 등이며 Bun, Envoy, Istio도 패치를 냈습니다.
- 웹훅, URL 미리보기, 크롤러처럼 외부 서버에 요청하는 서비스와 압축된 요청 본문을 받는 서비스부터 고치라고 권했습니다.
- 패치가 늦어지면 프록시에서 Content-Encoding에 br이 붙은 요청을 막고, 외부 호출에서는 br 응답을 디코딩 전에 거부하라고 했습니다.
- 오픈AI는 2월에 이 버그를 찾았다고 밝혔지만, 당시 고친 원인은 보안 문제로 인식되지 않아 이번에야 릴리스에 실렸습니다.
HN 반응
- HTTP2Shell이라는 이름이 지나치게 넓고 선정적이라는 비판이 많았고, HTTP 없이 Brotli를 풀어도 터지니 Broccoli2Shell이 낫다는 의견도 나왔습니다.
- 요청 본문을 Brotli로 받는 서버가 실제로 드물다는 반론에, 서버가 이를 조용히 지원하는 경우가 있어 리버스 프록시에서 막았다는 경험담이 맞섰습니다.
HTTP2Shell이라는 이름을 지은 사람은 인공지능이든 진짜 지능이든 지능이라곤 하나도 안 썼나 보네요.
너무 무의미하고 범위도 넓은 데다, 실제 문제를 전혀 설명하지 못해요. 뒤에 아무것도 없는 HTTP 서버는 아마 영향이 없을 텐데, 왜 HTTP가 욕을 먹어야 하죠?
차라리 Exploit Pro Max라고 부르지 그랬어요...
LLM이 초반의 이해를 바탕으로 세션, 이슈, PR 이름을 짓고는 나중에 갱신하지 않는 경우, 다들 한 번쯤 보셨을 겁니다.
AI는 제목을 검토해 달라는 요청을 받지 않고, 경험도 없고 생각도 하지 않으니 당연히 그걸 짚어 내지 못합니다.
요즘은 사람이 아무것도 검토하지 않으니 당연히 아무도 잡아내지 못하고요.
추가: AI는 "글쓰기"를 아무리 잘해도, 글쓰기 자체는 형편없고 특히 이름 짓기는 더 형편없습니다. 한번은 AI가 클라이언트 이름을 OpenAICompatibleEmbeddingClient로 지었어요. "야아아... "compatible"은 당연히 깔려 있는 거 아냐? 누가 이런 식으로 이름을 지어?!"
OpenAI 자체 API뿐 아니라 OpenAI 호환 임베딩 API를 제공하는 다른 서비스도 지원한다는 뜻이잖아요. 합리적인 이름 같은데요!
LLM 기반 AI는 사람이 관찰한 행동을 종합한 결과물입니다.
근데 그게 우리의 현재 패러다임과 시너지를 낼 수 있나요?
서술적인 타입 이름은 좋은 겁니다. 저는 그 이름이 그렇게 나쁘지 않다고 보지만, LLM이 가끔 도를 넘는 건 맞습니다.
더 나은 이름은 Konduktsemmel입니다. 오스트리아에서 장례식(Kondukt) 때 먹는 빵(Semmel)이라는 뜻이에요. Brotli랑도 어울리지 않나요?
(사실 장례식에서는 케이크를 먹고 커피를 마시지만, 오스트리아 일부 지역에서는 여전히 그렇게 부릅니다.)
선정적으로 보이는 게 목적이었던 것 같아요.
OpenAI가 지을 법한 이름이네요. 앤트로픽이 Mythos라고 지은 것처럼요.
저는 같은 취약점을 다룬 Broccoli2Shell이라는 이름과 사이트가 훨씬 좋습니다: https://broccoli2shell.com/ . 우선, Brotli를 직접 디코딩하는 경우라면 HTTP 없이도 이 취약점을 건드릴 수 있을 거라고 거의 확신합니다. HTTP는 그게 가장 흔히 나오는 경우일 뿐이고요.
요즘은 왜 심각한 취약점마다 귀여운 이름과 웹사이트가 붙죠? 그 사이트 비용은 누가 내는 건가요?
작은 정적 웹사이트는 사실상 공짜예요(Cloudflare, GCP 무료 구간 등).
도메인은 공짜가 아니죠.
아뇨, 공짜 맞습니다. 원하는 도메인이 공짜가 아닐 뿐이에요.
GitHub.io 도메인, workers.dev 도메인 같은 건 전부 무료 도메인입니다.
일부 스타트업의 가입 혜택을 영리하게 (또는 악용해서) 쓰면 나중에 다른 곳으로 이전할 수 있는 무료 도메인을 받을 수도 있는데, 요즘은 그런 곳 찾기가 더 어렵습니다.
진지하게 말해서, 악당들은 이런 걸 항상 알아냅니다.
그렇긴 한데, 도메인은 의미가 있는 1년 동안 10~20달러 넘게 들지는 않잖아요.
\o/
대가를 바라지 않고 도움이 되는 웹사이트를 만들어 준 사심 없는 분께 저는 불만이 전혀 없는데요!
그 사람들은 명성을 바라고, 실제보다 상황을 더 나쁘게 보이게 만들기도 합니다.
정확히 어떻게 "실제보다 더 나쁘게 보이게" 한다는 거죠? 문제가 뭔지... 보여 줘서요?
이 링크를 콕 집어서 한 말은 아니고, 보통 심각도를 실제보다 더 심각하게 부풀린다는 얘기입니다. 일종의 선정주의가 흔히 쓰이거든요.
아니요, 그렇지 않아요. 사이트에는 작성자가 적혀 있지 않으니 명성은 애초에 해당이 없고, 이 버그가 어느 정도로 평가됐는지("GitHub는 9.2 Critical(CVSS 4.0), Node.js는 High로 평가")도 맨 위에 정확히 밝혀 두었습니다.
맨 끝에 이름이 나와 있고 "우리"라는 표현도 있어요. 하지만 말씀드렸듯이 이 페이지 하나를 두고 한 말이 아니라 일반론이었습니다. 이런 걸 만드는 대부분보다는 훨씬 낫습니다.
짜증나고 아이러니한 일이에요. 이 정보의 혜택을 가장 많이 볼 대기업들이 새로 등록된 도메인을 차단하니까요.
저는 위험한 RCE 버그랑 무해한 RCE 버그를 맨날 헷갈린다니까요.
2월에 보고되고 수정까지 됐는데 아무도 중요성을 못 알아본 게 어떻게 된 건지 궁금하네요. AI 자동화에 운전대를 잡은 사람이 아무도 없었던 경우일까요?
OpenAI가 2월에 이걸 발견했다는 주장의 출처를 못 찾겠어요. 기사가 링크한 출처(OpenAI의 트윗)에는 그런 말이 없습니다.
저한테 놀라운 건, 이렇게 쓰임새가 모호한 기능인데도 이 중 상당수가 응답 본문뿐 아니라 요청 본문의 brotli 압축까지 구현하고 있다는 점입니다.
어쨌든 이 선정적인 분위기가 슬슬 짜증납니다. 패치하고 넘어가세요.
추가: 사실 온갖 호들갑 사이에서, 이 중 몇 개가 일반적인 설정에서 brotli로 압축된 요청 본문을 실제로 지원하는지, 아니면 brotli를 다른 용도로 쓰는 건지(그것도 나쁘긴 하지만 훨씬 덜 치명적입니다) 기사만 봐서는 알기 어렵습니다.
문제는 서버들이 brotli를 "조용히" 지원한다는 점이라고 봅니다. 아무도 안 쓰는데도 공격자는 그 기능을 악용할 수 있으니까요.
그래서 임시 조치로 저는 리버스 프록시에서 이걸 막고 있습니다.
근데 그게 정말 사실인가요?
node는 body parser를 켜면 지원하는 것 같습니다.
그 밖에 인바운드 요청에서 이걸 지원한다는 문서는 찾기가 힘드네요.
물론 다른 시나리오에서도 악용할 수 있겠지만, 취약한 서버에 그냥 접속하면 되는 게 아니라 공격자가 먼저 프로그램이 자기가 고른 서버로 아웃바운드 요청을 보내게 만들어야 한다면 취약점의 심각도는 훨씬 낮아집니다.
content-encoding 헤더에서 brotli 인코딩을 식별해 nginx에서 막는다는 발상입니다. 그러면 node의 취약한 brotli 파서까지 도달하지 않을 거예요.
제 자산이 악성 서버에 접속하지 않기를 바랍니다. 그렇다면 그땐 정말 문제가 되겠죠.
Asp.Net은 "UseRequestDecompression"이나 "UseResponseCompression"을 쓰면 Brotli 지원이 추가됩니다.
다만 DotNet은 자체 C# Brotli 구현을 갖고 있어요.