에스코어 인사이트
원문에 앞서 국내 개발·보안 조직이 함께 점검할 만한 사항을 간단히 정리했습니다.
•
보유 여부보다 도달 가능성 확인: Log4j가 존재한다는 사실만으로 위험을 판단하지 말고, 외부에서 전달된 Java 직렬화 데이터를 실제로 역직렬화하는 경로와 수신기가 있는지 먼저 확인합니다.
•
레거시 역직렬화 경로 제거: 직렬화된 LogEvent 수신기나 오래된 소켓 기반 로깅 경로가 남아 있다면 JSON이나 syslog 같은 지원되는 방식으로 전환하고, 불가피한 경우 해당 수신기에 대한 접근을 엄격히 제한합니다.
•
AI 보안 제보의 운영 영향 검증: AI가 재현 가능한 보안 동작을 찾아냈더라도 도달 가능성, 전제 조건, 프로젝트가 어디까지 안전을 보장하는지 확인한 뒤 실제 취약점과 운영 위험을 구분합니다.
Sonatype 원문 번역
요약
•
•
Sonatype은 현재 이 동작을 명확한 Log4j 취약점으로 보지 않습니다. Apache 역시 신뢰할 수 없는 데이터를 역직렬화하는 것 자체가 위험하다고 경고하며, 해당 필터가 이를 완전히 차단하는 보안 장치는 아니라고 설명합니다.
•
실제 악용에는 일반적이지 않은 레거시 방식의 애플리케이션 동작이 필요합니다. 애플리케이션이 신뢰할 수 없는 출처에서 Java로 직렬화된 Log4j 이벤트를 받아 역직렬화해야 하고, 공격자가 해당 경로에 접근할 수 있어야 하며, JVM에 악용 가능한 가젯이 이미 존재해야 합니다.
•
이번 분석은 AI 에이전트가 생성했으며, 유지관리자와 연구자, 방어 담당자가 도달 가능성과 전제 조건, 프로젝트가 보장하는 범위와 실제 영향을 충분히 확인하기 전에 공개되었습니다. 따라서 기술적인 발견 자체뿐 아니라 공개 과정도 중요한 보안 문제로 볼 필요가 있습니다.
보고의 근거가 된 우회 동작은 실제로 존재하는 것으로 보입니다. 다만 이를 "새로운 치명적 Log4j RCE"라고 규정할 수 있는지는 불분명합니다.
현재 분석에 따르면 FilteredObjectInputStream 우회는 오래된 Java 역직렬화 과정에서 발생하며, Log4j는 애초에 이 경로의 보안을 보장하지 않습니다. 이 역직렬화 경로에 도달하려면 애플리케이션이 신뢰할 수 없을 수 있는 출처에서 직렬화된 Log4j 이벤트를 받아 역직렬화해야 합니다. 현대적인 환경에서는 흔하지 않은 동작이며 Apache도 명시적으로 권장하지 않습니다.
Sonatype은 고객이 애플리케이션에서 의도적으로 안전하지 않은 이 역직렬화 방식을 사용하고 있는지 확인할 수 있도록 sonatype-2026-006746 어드바이저리를 공개했습니다. sonatype-2026-006746 어드바이저리는 해당 동작을 Log4j 자체의 취약점으로 분류하지 않습니다.
이번 공개 과정에는 또 다른 문제가 있습니다. AI가 생성한 보안 분석이 실제 중요성을 충분히 검증하기 전에 얼마나 빠르게 공개될 수 있는가 하는 점입니다.
심층 방어용 제어를 우회하는 동작
Apache Log4j에 제출된 한 보고서는 FilteredObjectInputStream이 역직렬화를 허용하는 클래스를 제한하는 방식을 우회하는 방법을 설명했습니다.
문제의 핵심은 java.rmi.MarshalledObject입니다. 이 클래스는 다른 직렬화 객체를 내부에 담을 수 있습니다. 보고된 방식에서는 내부 객체가 나중에 다시 역직렬화될 때 FilteredObjectInputStream의 검사를 거치지 않아, 결과적으로 클래스 허용 목록을 우회할 수 있습니다. 독립 연구자들은 Log4j 2.26.1에서 이 동작을 재현했습니다.
우회 동작은 실제로 존재하지만 Apache는 해당 필터만으로 안전을 보장할 수 있다고 보지 않습니다. Apache의 가이드는 신뢰할 수 없는 데이터를 역직렬화하는 것 자체가 안전하지 않으며, 이러한 보안 강화 기능은 위험을 일부 줄여줄 뿐이라고 설명합니다. 입력 데이터의 신뢰성을 확보하는 책임은 애플리케이션에 있습니다.
이후 Log4j 프로젝트 관리자는 원래 GitHub 이슈에 답변하면서, 해당 보고서를 "이미 알려진 보안상 비이슈를 독립적으로 다시 발견한 것"이라고 평가했습니다. 이어 FilteredObjectInputStream은 안전을 보장하는 장치가 아니라, 보안을 보완하기 위한 추가 방어 수단이라고 설명했습니다.
따라서 이번 사례는 보안 강화 조치의 빈틈을 보여주지만, 반드시 Log4j 자체의 취약점을 의미하는 것은 아닙니다.
Log4Shell과는 다르다
Log4Shell은 일반적인 로깅 동작만으로도 발동되는 경우가 많았습니다. 이번 동작은 그렇지 않습니다.
Log4j가 일반적인 로깅 과정에서 외부 데이터를 임의로 받아 역직렬화하는 것은 아닙니다. 이번 문제가 발생하려면 애플리케이션이 Java로 직렬화된 Log4j LogEvent 객체를 직접 받아 역직렬화하도록 구성되어 있어야 합니다. 따라서 일반적인 로깅 기능만 사용하는 환경에서는 이 문제가 발생하지 않습니다.
현재 분석으로는 코드 실행이 가능하려면 다음 조건이 모두 충족되어야 하는 것으로 보입니다.
1.
애플리케이션이 Java로 직렬화된 Log4j 이벤트를 처리합니다.
2.
공격자가 애플리케이션의 Log4j 이벤트 수신부로 직렬화 데이터를 전송할 수 있습니다.
3.
JVM에 악용 가능한 역직렬화 가젯이 이미 존재합니다.
따라서 먼저 살펴야 할 것은 애플리케이션 아키텍처의 문제이지, 모든 Log4j가 취약하다는 식의 일반적인 문제는 아닙니다.
직렬화 기반 로깅이 점차 레거시 방식이 되고 있다는 점도 중요합니다. 이 방식은 Log4j 1.x에서 더 널리 사용됐지만 Log4j 2.x에서는 사용이 축소되고 권장되지 않았으며, Log4j 3.x에서는 직렬화 지원이 제거될 예정입니다.
애플리케이션이 Java로 직렬화된 Log4j 이벤트를 역직렬화하지 않는다면 이번에 보고된 우회 방식이 실제 공격으로 이어질 가능성은 낮습니다.
Sonatype이 계속 추적하는 이유
Sonatype Guide가 sonatype-2026-006746을 계속 추적하는 이유는, Log4j 유지관리자가 이번 우회를 제품 취약점으로 보지 않더라도 특정 환경에서는 이와 관련된 애플리케이션 동작이 실제 위험으로 이어질 수 있기 때문입니다.
Sonatype은 일반적인 취약점으로 분류하기 어렵더라도, 특정 조건에서 실제 위험을 일으킬 수 있는 소프트웨어 동작이라면 별도의 Sonatype ID를 부여해 추적합니다.
이번 어드바이저리는 조직이 애플리케이션에서 문서상 지원되지만 안전하지 않은 것으로 알려진 역직렬화 방식을 사용하고 있는지 확인할 수 있도록 돕기 위한 것입니다.
이 차이를 구분해야 하는 이유는 이번 분석과 관련해 Log4j 자체의 패치가 나오지 않을 수도 있기 때문입니다. 실제 위험이 애플리케이션에서 신뢰할 수 없는 Java 직렬화 데이터를 받아들이는 데서 비롯된다면, 단순히 Log4j를 업그레이드하는 것만으로는 문제를 해결할 수 없습니다.
더 적절한 대응은 해당 역직렬화 패턴이 실제 환경에 존재하는지 확인한 뒤, 가능하다면 Java 역직렬화를 사용하지 않는 방식으로 전환하는 것입니다.
조직이 확인해야 할 사항
팀은 Log4j가 어디에 쓰이고 있는지만 확인할 것이 아니라, 실제로 공격 가능한 경로가 존재하는지를 먼저 살펴야 합니다.
다음 항목이 환경에 존재하는지 확인하세요.
•
Java로 직렬화된 LogEvent 수신기
•
오래된 소켓 서버, 로깅 브리지 또는 샘플 코드를 바탕으로 만든 구현
•
네트워크나 그 밖의 신뢰할 수 없는 출처에서 Java 직렬화 데이터를 받는 커스텀 소프트웨어
•
신뢰할 수 없는 입력을 대상으로 새로운 ObjectInputStream을 생성하는 애플리케이션 코드. 위험한 역직렬화 패턴이 존재할 가능성을 강하게 시사합니다.
•
악용 가능한 역직렬화 가젯 체인을 제공할 수 있는 서드파티 라이브러리
•
JSON이나 syslog 같은 더 안전한 형식으로 교체할 수 있는 레거시 로깅 경로
일반적인 Log4j 로깅과 Java 직렬화를 사용하지 않는 전송 방식은 처리 경로가 다릅니다. 따라서 시스템에 Log4j가 포함돼 있다는 이유만으로 이번 문제의 영향을 받는다고 볼 수는 없습니다.
직렬화 기반 로깅이 계속 필요하다면 해당 수신기에 대한 접근을 제한하고 신뢰할 수 없는 데이터가 수신기에 전달되지 않도록 해야 합니다.
가능한 경우에는 Log4j의 가이드에 따라 Java 역직렬화를 완전히 제거하고 JSON 기반 로깅처럼 완전히 지원되는 대안을 사용해야 합니다.
더 큰 변화: AI가 취약점 공개 방식을 바꾸고 있다
이번 분석을 AI 에이전트가 만들어냈다는 사실은 부수적인 요소가 아닙니다.
기술적으로 재현 가능한 결과가 공개되면 매우 빠르게 퍼질 수 있습니다. 유지관리자와 연구자, 방어 담당자가 해당 코드 경로가 현실적으로 도달 가능한지, 악용에 어떤 전제 조건이 필요한지, 프로젝트가 실제로 보장한다고 밝힌 보안 범위를 벗어나는 동작인지 충분히 확인하기도 전에 확산될 수 있습니다.
AI가 취약점 연구를 가속할수록 이런 구분은 더욱 중요해질 것입니다.
널리 사용되는 오픈소스에서 드물지만 실제로 재현되는 예외적인 동작을 찾아내는 능력은 앞으로 크게 향상될 것입니다. 문제는 실제 악용 가능성이나 필요한 조건, 프로젝트가 보장하는 보안 범위를 충분히 따져보지 않은 채 이런 사례를 모두 "치명적 RCE"로 규정하는 경우입니다. 그렇게 되면 방어 조직은 기술적으로 틀리지는 않지만 실제 대응 판단을 흐리는 경보에 압도될 수 있습니다.
발견 속도가 빨라지면 실제로 대응이 필요한 보안 문제도 더 빠르게 찾아낼 수 있습니다. 반면 충분한 검증이 이뤄지기 전에 불완전하거나 필요한 정보가 빠진 분석이 빠르게 퍼져, 실제 위험도를 판단하기 어려워질 수도 있습니다.
기술적으로 가능하다는 것과 운영상 위험하다는 것은 다르다
보고된 Log4j 동작은 실제로 재현되는 만큼, 보안상 확인이 필요한 사안입니다.
하지만 실험실 환경에서 코드 실행을 구성할 수 있다는 사실과 제품 전반에서 광범위하게 악용 가능한 취약점이 존재한다는 사실은 같지 않습니다.
먼저 애플리케이션이 신뢰할 수 없는 출처에서 들어온 Java 객체를 역직렬화해야 합니다. Log4j는 이런 방식을 명시적으로 경고합니다. 관련 동작은 현대적인 환경에서 흔하지 않으며, 실제 악용에는 추가 조건이 필요합니다. 또한 Log4j 유지관리자는 이러한 부분적인 보안 강화 도구의 우회를 프로젝트 취약점으로 보지 않는다고 명확히 밝히고 있습니다.
Sonatype이 Log4j 전체를 취약하다고 표시하지 않고 어드바이저리를 통해 해당 동작을 추적하는 이유도 여기에 있습니다.
방어 조직이 취할 수 있는 실질적인 조치는 명확합니다. 환경에 이런 레거시 역직렬화 패턴이 있는지 확인하고, 가능한 경우 JSON처럼 지원되는 대안으로 교체해야 합니다. 아직 제거할 수 없다면 해당 역직렬화 경로에 대한 접근을 엄격히 제한해야 합니다.
핵심은 기술적으로 재현 가능한 분석을 무시하라는 것이 아닙니다. 방어 담당자가 기술적으로 가능한 것과 운영 환경에서 실제 의미가 있는 위험을 구분할 수 있을 만큼 충분한 맥락을 확보해야 한다는 것입니다.
에스코어는 Sonatype 공식 파트너로서 소프트웨어 공급망 보안 및 오픈소스 거버넌스 구축을 지원합니다.
도입이나 구축이 필요하시면 언제든 문의해 주세요.
지원 솔루션: Nexus Repository · Repository Firewall · Lifecycle · Sonatype Guide