의존성
이 태그가 달린 문서 11건
Brotli 취약점 CVE-2026-111497(Node2Shell): Node.js, Python, .NET 확인 방법과 업데이트 대상
2026년 10월 21일(미국 시간) Google은 공식 Brotli 라이브러리의 범위 밖 쓰기 취약점 CVE-2026-111497을 수정한 Brotli 1.2.1, 1.1.1, 1.0.10을 공개했습니다. Brotli 1.0.3–1.0.9, 1.1.0, 1.2.0이 영향을 받습니다. 조작된 Brotli 데이터를 압축 해제하면 메모리가 손상되어 크래시, 메모리 내용 노출, 경우에 따라 임의 코드 실행으로 이어질 수 있습니다. Google은 CVSS v4.0 기준 9.2로 평가했습니다. Node.js는 같은 날 22.23.4, 24.22.1, 26.12.1을 공개했고, 10월 22일에는 PyPI 패키지가 brotli 1.2.1과 brotlicffi 1.2.1.0에서 수정되었습니다. Microsoft는 10월 25일(미국 시간) .NET 8, 9, 10용 수정(8.0.33, 9.0.22, 10.0.14)을 공개했으며, Bun(1.4.4)과 Envoy도 수정을 배포했습니다. 일본의 컴퓨터 비상 대응팀인 JPCERT/CC는 10월 26일 Node2Shell과 HTTP2Shell이라는 별칭을 언급한 주의 환기를 발표했습니다. 많은 프로그램이 자체 Brotli 사본을 포함하므로, 운영체제의 라이브러리를 업데이트해도 공식 Node.js 빌드, PyPI의 Python wheel, 컨테이너 이미지, 단일 파일 실행 파일 안의 사본은 수정되지 않습니다. 10월 27일(미국 시간) CISA는 실제 악용 증거를 근거로 이 취약점을 KEV(Known Exploited Vulnerabilities) 카탈로그에 추가하고, 미국 연방 기관에 11월 10일까지 수정하도록 요구했습니다. CISA는 세부 내용을 공개하지 않았습니다. 한 위협 인텔리전스 기업은 Node.js 24.22.0을 노린 익스플로잇 트래픽을 관측했다고 보고했지만 그 트래픽은 해당 기업의 자체 시험에서 성공하지 못했으며, Microsoft는 여전히 이 결함을 악용되지 않은 것으로 표시하고 있습니다. 언론은 개념 증명(PoC) 코드가 공개되었다고 보도했습니다. 이 사이트의 결론: Node.js, Bun, Python 또는 .NET 서비스가 외부에서 받은 데이터를 압축 해제한다면 유지보수 시간을 기다리지 말고 오늘 업데이트한 뒤 컨테이너와 실행 파일을 다시 빌드하십시오. WordPress와 PHP 사이트: 보안 기업들은 11월 2일, 이것이 WordPress 코어, 플러그인, 테마의 결함이 아니므로 WordPress를 업데이트해도 해결되지 않는다고 설명합니다. WordPress는 Brotli를 포함하지 않고 운영체제의 라이브러리를 쓰므로, OS의 libbrotli 패키지를 업데이트하고 컨테이너를 다시 빌드하고 이후 PHP-FPM이나 Apache를 재시작하세요(재시작은 우리의 추가 조언입니다). 한 기업은 XML-RPC 핑백을 통한 코드 실행을 실험실에서 재현했으며, 11월 2일 기준 실제로 침해된 WordPress 사이트에 대한 공개 보고는 찾지 못했다고 밝혔습니다.
eMudhra(emSign) 중간 CA 키 유출: Python 사용자가 pip, certifi, uv와 관련해 해야 할 일
2026년 10월 17일, 인도 인증기관 eMudhra의 중간 인증서 8개(TLS용 6개)의 개인 키가 누구나 복구할 수 있을 만큼 부실하게 생성되었다는 보고가 나왔습니다. eMudhra는 10월 18일 8개 모두를 폐기했고, Chrome과 Firefox는 10월 17일 푸시 메커니즘을 통해 이들을 차단했습니다. 10월 20일 Mozilla는 상위 루트인 emSign ECC Root CA - G3에 대한 긴급 신뢰 제거를 결정했으며, Chrome은 10월 27일(태평양 시간) 이를 제거할 예정입니다. 브라우저는 보호되었지만, 브라우저 밖의 TLS 클라이언트는 자체 CA 목록이 업데이트되기 전까지 위조 인증서를 신뢰할 수 있습니다. Python에서는 pip가 항상 내장된 certifi를 읽기 때문에, OS 저장소가 수정된 후에도 구버전 pip는 계속 노출됩니다. Python 프로젝트는 10월 20일 공지(10월 22일까지 갱신)를 게시해, 최소 certifi 2026.10.19, pip 26.2.2, uv 0.13.4, sigstore 4.5.1, conda 26.9.4, pixi 0.82.1로 업그레이드하고 레이어 캐시 없이 컨테이너 이미지를 다시 빌드할 것을 요청했습니다. 10월 21일에는 pip 26.2.2를 포함한 Python 3.15.1, 3.14.9, 3.13.17을 배포했습니다. 새 pip를 포함하는 3.11 또는 3.12 릴리스는 없을 예정입니다. 이는 CPython의 코드 실행 취약점이 아닙니다. 네트워크 경로상의 공격자는 PyPI, python.org 및 기타 사이트로의 연결을 가짜 서버로 우회시킬 수 있습니다. 10월 24일 기준 악용 사례는 발표되지 않았습니다. 10월 22일 eMudhra는 글로벌 SSL/TLS 인증서 사업에서 철수하겠다고 밝혔습니다. 이 사이트의 견해: 모든 환경에서 pip를 26.2.2 이상으로, certifi를 2026.10.19 이상으로 업그레이드하고, Docker 이미지는 캐시 없이 다시 빌드하며, 잠금 파일의 certifi 고정 버전을 올리십시오.
TanStack, Nx Console, GitHub로 이어진 침해 연쇄 (2026년 5월): 개발자가 확인할 것
2026년 5월 11일 TanStack의 Router/Start 저장소의 배포 파이프라인이 악용돼 npm 패키지 42개, 84개 버전에 인증 정보를 훔치는 코드가 실렸다. 그중 하나를 설치한 Nx 기여자의 GitHub CLI 토큰이 탈취됐고, 5월 18일 변조된 Nx Console 확장(v18.95.0)이 공개됐다. 같은 날 GitHub는 악성 VS Code 확장으로 직원 기기가 침해돼 GitHub 내부 저장소가 유출됐다고 밝혔다. 세 사건 모두 정상 계정과 정상 배포 경로를 거쳤으므로, 방어는 탈취된 배포 인증 정보(토큰) 하나만으로 새 버전을 낼 수 없게 하는 것, 그리고 설정해 둔 안전장치가 실제로 동작하는지 확인하는 것이다.
Trivy 공급망 침해 (2026년 3월): CI에서 Trivy를 쓰고 있다면 할 일
2026년 3월 19일 Aqua Security가 개발하는 오픈소스 취약점 스캐너 Trivy의 악성 v0.69.4가 배포됐고, GitHub Actions의 trivy-action(태그 77개 중 76개)과 setup-trivy(태그 7개 전부)가 악성 커밋을 가리키도록 바뀌었다. Aqua에 따르면 악성 코드는 CI 러너에서 비밀값을 수집해 외부로 보냈고, 원인은 2월 말에 시작된 침해에서 탈취된 인증 정보였으며, 3월 1일의 교체가 한꺼번에 이뤄지지 않아 공격자가 계속 쓸 수 있었다. 이 사이트의 결론 = 교훈은 액션을 태그가 아니라 커밋 ID(SHA)로 고정하라는 것만이 아니다. SHA로 고정한 액션도 내부에서 다른 구성 요소를 태그로 부를 수 있고, 그 경로로 악성 버전이 들어온다. 유출된 인증 정보는 한꺼번에 교체해야 하며, 그렇지 않으면 공격자가 계속 쓸 수 있다. 스캐너는 배포용 비밀값이 없는 잡에서 돌린다.
Node.js 프로토타입 오염: 런타임이 책임지지 않는 범위와 내 코드에서 방어하는 법
프로토타입 오염은 외부 입력에 든 특수한 키가 대개 재귀 병합을 통해 JavaScript의 내장 프로토타입에 닿을 때 일어납니다. 결과는 두 가지입니다. 설정한 적 없는 속성이 곳곳에 나타나거나(권한·옵션 판정이 틀어짐), 내장 메서드가 사라져 관계없는 곳에서 앱이 죽습니다. 가장 중요한 것은 책임의 소재입니다. Node.js는 이것이 Node.js 코어의 취약점이 아니며 방어는 애플리케이션과 의존성 수준에서 해야 한다고 밝히고 있습니다. 업데이트를 기다려도 해결되지 않습니다.
OpenSSL이란? HTTPS 암호화를 처리하는 라이브러리와 안전하게 유지하는 법
OpenSSL은 HTTPS(TLS/SSL)와 암호화를 떠받치는 오픈소스 라이브러리입니다. 대부분의 사람은 직접 작성하지 않고 웹 서버, OS, 언어 런타임을 통해 물려받습니다. 그래서 버그 하나의 영향 범위가 매우 넓습니다(Heartbleed가 전형적인 사례). 방어법은 자신의 스택이 어떤 OpenSSL을 쓰는지 파악하고, 지원 종료(EOL) 버전을 돌리지 않으며, 기반 라이브러리도 CVE 감시에 포함하고, 신속하게 패치하는 것입니다. 이 사이트가 제공하는 인증서도 그 밑에서는 OpenSSL 계열 구현으로 암호화를 수행합니다.
의존성 CVE를 제대로 고치기: 스캔, 수정, 격리, 그리고 계속 감시
취약점 작업은 '고쳤다'고 끝나는 게 아니다. 완료 = 1) 스캔, 2) 수정, 3) 격리/인계, 4) 모니터링. 모니터링(매일 변화 탐지)이 갖춰지기 전까지는 미완이다 — 의존성은 내일 다시 취약해진다. 다음 배포가 덮어쓰는 완벽한 수정은 가치가 0이다. 소규모 팀은 두 규율로 안전을 지킨다: 자동 변화 탐지와 '로컬→push→배포'.
osv-scanner 설치와 사용법: 의존성의 CVE를 자동으로 찾아내기
osv-scanner는 락파일과 컨테이너를 스캔해 의존성의 CVE를 무료로 드러냅니다. 설치·실행·CI 연동을 짚고, npm/pnpm audit·Dependabot과 언제 쓸지도 비교합니다. 본 사이트의 견해: 어떤 도구가 맞는지는 당신의 환경에 달려 있습니다. 다중 생태계나 GitHub 비사용 프로젝트엔 osv-scanner를, 단일 npm 트리엔 번들된 pnpm audit을 쓰세요.
Log4Shell(CVE-2021-44228) — 로깅 라이브러리의 결함과, 사용 여부를 바로 확인할 수 없었던 이유
Log4j의 CVSS 10.0 버그. 핵심 문제는 전이 의존성, 즉 자신도 모르게 쓰던 라이브러리를 통해 영향을 받는 것이었습니다. 수동적인 로깅 경로가 공격 벡터가 되었습니다. SBOM, 머신 모니터링, 빠른 패치, 그리고 후속 CVE 추적이 교훈입니다.
XZ Utils 백도어(CVE-2024-3094) — 신뢰받던 공동 메인테이너에 의한 공급망 공격
신뢰받던 메인테이너가 xz에 백도어를 심은 공급망 공격. 한 엔지니어가 로그인이 느려진 것을 알아채 안정 배포 직전에 발견했습니다. 표적은 코드가 아니라 사람과 신뢰였습니다. 의존성을 최소화하고, 버전을 핀 고정하고, 재현 가능하게 빌드하고, 이상을 끝까지 쫓고, 메인테이너를 지원하십시오.
Next.js를 안전하게 운영하기: 공개된 CVE에 뒤처지지 않기
프레임워크 최대 위험은 방치된 공개 CVE다. 네 가지 실천으로 방어한다: 가동 중인 버전으로 판단, Dependabot/osv-scanner로 모니터링, 빠른 업데이트, 최소 권한 운영. 본 사이트의 견해: 인디 개발자에게 부족한 것은 보통 지식이 아니라 운영을 지속하는 방법이며, 속도보다 CVE를 놓치지 않는 시스템이 중요하다.