Fastjson 1.x CVE-2026-16723: 패치 없는 RCE 취약점, 실제 공격 확인과 2.x 마이그레이션 가이드

취약점 개요 및 발생 배경

2026년 7월 25일자로 공개된 The Hacker News 보도에 따르면, 보안 기업 ThreatBook과 Imperva가 Alibaba의 자바용 JSON 파싱 라이브러리 Fastjson 1.x에서 발생하는 원격 코드 실행(RCE) 취약점이 실제 공격에 악용되고 있음을 공동 확인했습니다. 해당 취약점은 CVE-2026-16723으로 추적되며, Alibaba 자체 평가에서 CVSS 9.0이라는 만점에 가까운 위험 등급을 부여받은 것으로 알려져 있습니다.

CVE-2026-16723과 CVSS 9.0의 의미

본 취약점은 AutoType과 같은 디시리얼라이제이션 경로에서 발생하는 결함을 기반으로 하며, 공격자가 서버 도달 가능한 HTTP 엔드포인트에 정제되지 않은 JSON 요청을 전송하는 것만으로 임의의 자바 코드를 실행할 수 있습니다. CVSS 9.0은 네트워크 기반 공격, 낮은 공격 복잡도, 인증 불필요, 기밀성·무결성·가용성 모두에 대한 높은 영향도를 반영한 수치로, 실제 환경에서 매우 위험한 등급으로 분류됩니다.

위협 분석: 실제 공격에 악용 중인 시나리오

ThreatBook과 Imperva가 공동으로 발표한 탐지 사례에 따르면, 공격자는 인터넷에 노출된 Spring Boot 애플리케이션의 API 엔드포인트를 대상으로 악의적인 JSON 페이로드를 전송하고 있습니다. 별도의 인증 절차가 없는 공개 경로를 이용한다는 점에서 사전 인증(Pre-auth) 기반의 무차별 공격이 가능하며, 웹 애플리케이션 방화벽(WAF) 우회 기법까지 결합된 사례가 일부 관찰된 것으로 보고되었습니다.

레퍼런스 체인 공격 구조 (정보 유출 + 서버 측 결함)

공개된 분석 내용을 근거로 작성하면, 본 공격은 단순한 단일 취약점 악용이 아니라 두 단계의 체인형 공격으로 구성됩니다. 첫 단계에서는 ORM 매핑 정보나 내부 클래스 경로 등 서버의 메타데이터를 유출하고, 두 번째 단계에서 확보한 정보를 바탕으로 디시리얼라이제이션 대상 클래스를 정확히 지정하여 RCE를 확정하는 흐름으로 파악됩니다. 따라서 탐지 시그니처가 정보 유출 단계에서부터 발생함에도 불구하고, 보안팀이 이를 단순한 정보 노출 사례로 분류해 후속 단계의 RCE를 놓치는 사례가 발생 가능한 것으로 보입니다.

기업 환경에 미치는 즉각적 영향

국내 기업 레거시 시스템에는 Fastjson 1.x가 유지되고 있는 사례가 있으며, Spring Boot 기반의 사내 API 게이트웨이, B2B 연동 모듈, 고객 포털 등이 잠재적 공격 표면이 될 수 있습니다. 본문은 1차 출처인 The Hacker News 기사와 ThreatBook의 공식 분석 페이지를 교차 확인하여 작성되었습니다.

공격 성공 시 자바 프로세스 권한으로 인한 확산 가능성

본 취약점이 특히 위험한 이유는 Fastjson 1.x가 자바 프로세스 내부에서 디시리얼라이제이션을 수행하기 때문에, 공격 성공 시 획득되는 권한이 웹 애플리케이션 컨테이너의 운영 계정이라는 점입니다. 컨테이너 또는 가상 머신에서 운영되는 경우에는 프로세스 격리 수준에 따라 kubectl, docker exec, 내부 관리 API 등수평 이동(Lateral Movement)에 즉시 활용될 수 있으며, 클라우드 워크로드의 IAM 자격 증명이 환경 변수나 메타데이터 서비스를 통해 노출되는 경우 계정 탈취로 이어질 가능성도 배제할 수 없는 것으로 분석됩니다.

긴급 대응 가이드

Fastjson 1.x 라인에 대한 공식 패치가 제공되지 않는 현재 상황에서는 임시 완화가 아닌 라이브러리 자체의 전환이 가장 안전한 선택입니다. 다음 표는 노출 시점에 따른 우선순위별 대응 절차를 정리한 것입니다.

Fastjson 2.x 마이그레이션 시 점검 사항

Fastjson 2.x는 1.x와 비교하여 기본 AutoType 정책이 safeMode로 강화되었으며, 패키지 경로와 클래스 호환성에서 일부 차이가 존재합니다. 마이그레이션 단계에서는 다음과 같은 항목들이 중점적으로 점검되어야 할 것으로 권고됩니다.

• JSON.toJSONString, JSON.parseObject 등 주요 API 호출부의 동작 회귀 테스트
• 커스텀 Serializer/Deserializer 구현 코드의 2.x 호환성 확인
• AutoType 활성화 구간의 허용 화이트리스트 재정의 및 검증
• 빌드 파이프라인에서 1.x 잔존 여부를 차단하는 의존성 잠금(Lock) 적용

공급망 보안 관점에서의 교훈

본 사안은 단일 라이브러리의 취약점을 넘어, 기업의 의존성 관리 체계 전반에 대한 점검 필요성을 제기합니다. 레거시 라이브러리는 사용자 코드베이스에서 잊혀져 가지만, 정기적인 SBOM 갱신과 외부 위협 정보와의 매칭이 이루어지지 않는다면 패치 부재의 고위험 취약점이 영구적으로 잔존하게 됩니다.

SBOM과 의존성 취약점 점검 체계 강화

장기적으로는 위협 정보 기반의 자동 검사 체계를 기존 CI/CD 파이프라인에 통합하는 것이 권고됩니다. 즉, 빌드 단계에서 NVD 및 ThreatBook의 위협 인텔리전스 피드를 기반으로 Fastjson 1.x와 같이 이미 지원 종료된 라이브러리를 사용하는 빌드를 차단 규칙으로 거부하도록 구성해야 합니다. 또한 취약점 발견 시 평균 대응 시간(MTTR)을 단축하기 위해, 운영팀과 개발팀 간의 취약점 공유 채널과 책임 소유자가 사전에 정의되어 있어야 할 것으로 분석됩니다.