2026년 5월, Redis의 블로킹 클라이언트 처리 코드에서 발생한 use-after-free 취약점 CVE-2026-23479가 패치되었다. 해당 취약점은 인증된 사용자가 특정 조건에서 Redis 서버가 실행되는 호스트 시스템에서 원격 코드 실행(RCE)을 유발할 수 있는 취약점이다.
CVE-2026-23479는 Redis 7.2.0에서 도입된 이후 8.6.3 패치가 배포되기 전까지 약 2년간 안정 버전에 남아 있었으며, 자율형 AI 보안 도구의 검증 과정에서 발견된 사례로 알려졌다. 무인증 취약점은 아니지만, Redis가 외부에 노출되어 있거나 애플리케이션 계정에 넓은 권한이 부여된 환경에서는 실제 공격 표면으로 이어질 수 있다.
본 글에서는 CVE-2026-23479의 기술적 원인을 살펴보고, Criminal IP를 통해 인터넷에 노출된 Redis 자산과 취약 가능 인스턴스를 확인하는 방법을 분석한다.
CVE-2026-23479 취약점 개요
| 항목 | 내용 |
|---|---|
| 취약점 ID | CVE-2026-23479 |
| 영향 제품 | Redis / redis-server |
| 영향 버전 | Redis 7.2.0 이상 8.6.3 미만 |
| 취약점 유형 | Use-After-Free |
| 공격 조건 | 인증된 공격자 필요 |
| CVSS 점수 | NVD CVSS 3.1 기준 8.8 High / Redis CVSS 4.0 기준 7.7 High |
| 패치 버전 | 7.2.14, 7.4.9, 8.2.6, 8.4.3, 8.6.3 |
CVE-2026-23479의 영향 범위는 Redis 7.2.0 이상 8.6.3 미만이다. 따라서 특정 버전 하나만 점검하기보다 운영 중인 Redis 브랜치가 권장 패치 버전에 도달했는지를 기준으로 확인해야 한다.
CVE-2026-23479의 기술적 원인: unblock client flow와 Use-After-Free
Redis는 일부 명령을 처리할 때 클라이언트를 일시적으로 대기 상태에 둘 수 있다. 예를 들어 list, stream, sorted set 등에서 특정 데이터나 조건이 준비될 때까지 요청을 보류한 뒤, 조건이 충족되면 blocked client를 다시 실행 흐름으로 되돌린다.
CVE-2026-23479는 이 재개 과정에서 client 객체의 수명 관리가 어긋나면서 발생한다. Redis의 unblock client flow는 blocked client를 다시 처리하는 과정에서 processCommandAndResetClient를 호출한다. 그러나 특정 조건에서 client 객체가 해제된 뒤에도 기존 포인터가 다시 참조될 수 있으며, 이로 인해 use-after-free 상태가 발생할 수 있다.
Use-after-free는 해제된 메모리 영역을 프로그램이 여전히 유효한 객체처럼 사용하는 취약점이다. 이 경우 공격자는 Redis의 blocking command 처리 흐름을 조작해 비정상적인 메모리 재사용 상태를 만들고, 조건에 따라 Redis 프로세스 권한에서 코드 실행을 시도할 수 있다.
이 취약점의 핵심은 blocked client가 해제되고 다시 처리되는 과정에서 객체 상태가 정확히 반영되지 않는다는 점이다. 따라서 취약 버전 사용 여부뿐 아니라, Redis 계정에 부여된 명령 권한과 데이터 쓰기 권한도 실제 위험도에 영향을 줄 수 있다.
취약점이 2년간 숨겨진 이유
공개 분석에 따르면 이 버그는 processCommandAndResetClient 함수의 리턴값이 평소에는 검사하지 않아도 무방한 맥락이 대부분이었기 때문에, 코드 리뷰 과정에서 포착되기 어려웠다. 특정 메모리 압박 조건(maxmemory-clients 한계 초과)과 블로킹 명령 타이밍이 동시에 맞아야만 발동하는 구조여서, 일반적인 기능 테스트나 리뷰로는 재현이 어렵다. Xint Code가 이 취약점을 발견한 것은 자율형 AI 보안 도구가 대규모 코드베이스에서 복잡한 조건 체인을 분석하는 데 유효함을 보여주는 사례로 평가된다.
공격 흐름: 외부 노출 Redis에서 RCE로 이어질 수 있는 경로
CVE-2026-23479는 인증된 공격자를 전제로 한다. 그러나 외부에 노출된 Redis 인스턴스에서는 약한 인증 정보, 공유 계정, 과도한 ACL 권한, 오래된 버전이 결합되며 실제 공격 조건이 충족될 수 있다.
공격 흐름은 다음과 같이 정리할 수 있다.
- 공격자는 인터넷 스캔을 통해 외부에 노출된 Redis 인스턴스를 식별
- 배너 정보, 포트, 버전, 인증 요구 여부를 기준으로 취약 가능 자산을 선별
- 유출된 계정, 약한 인증 정보, 과도한 권한이 부여된 애플리케이션 계정을 통해 Redis 세션을 확보
- XREAD BLOCK 등의 블로킹 명령과 MULTI/EXEC를 조합해 eviction 타이밍을 조작, unblockClientOnKey 내에서 use-after-free 조건을 유도
- Redis 프로세스 권한에서 코드 실행을 시도
- 이후 세션 데이터, 캐시 데이터, 내부 서비스 정보, 애플리케이션 연결 정보를 수집하거나 동일 호스트의 다른 서비스로 이동을 시도
이 흐름에서 중요한 지점은 취약점 자체보다 Redis가 운영되는 위치와 권한 구조다. Redis가 내부 서비스와 밀접하게 연결되어 있고, 동일 IP에 여러 관리·웹 서비스가 함께 노출되어 있다면 침해 이후의 영향 범위가 커질 수 있다.
Redis 노출 자산 분석
Criminal IP Asset Search를 활용하면 인터넷에 노출된 Redis 자산을 검색하고, 서비스 포트, 배너 정보, 버전 정보, 취약점 매핑 여부를 기준으로 위험 자산을 식별할 수 있다.
Criminal IP 검색 쿼리: product: Redis
Criminal IP에서 product 필터로 Redis를 검색한 결과, 2026년 6월 기준 약 74,000개의 Redis 관련 자산이 확인된다. 이는 Redis가 여전히 대규모로 인터넷상에서 식별 가능한 상태로 운영되고 있음을 보여준다.
Redis의 기본 서비스 포트는 6379번이다. Redis가 6379번 포트로 외부에 열려 있거나, 동일 IP에서 SSH, 웹 관리 페이지, 데이터베이스, 모니터링 도구가 함께 노출되어 있다면 단일 취약점 이상의 복합 위험으로 평가해야 한다.
CVE-2026-23479 취약 자산 검색
CVE-2026-23479와 매핑된 Redis 자산을 확인하기 위해 다음 쿼리를 사용할 수 있다.
Criminal IP 검색 쿼리: cve_id: CVE-2026-23479
Criminal IP Asset Search로 cve_id 필터를 사용해 CVE-2026-23479 취약점 영향을 받는 인스턴스를 확인한 결과, 2026년 6월기준 16,090건의 취약한 자산이 발견되었다. 조직은 이 검색 결과를 통해 외부에 노출된 Redis 인스턴스 중 해당 취약점의 영향을 받을 가능성이 있는 자산을 우선적으로 식별할 수 있다.
상위 국가 분포를 보면 일본 4,772건, 미국 2,970건, 중국 1,886건, 프랑스 1,134건, 독일 873건 순으로 확인된다. 이는 취약 가능 Redis 자산이 일부 지역에만 집중된 것이 아니라, 주요 클라우드 및 호스팅 인프라 전반에 분산되어 있음을 시사한다.
CVE 기반 검색 결과는 배너 정보, 버전 식별 가능 여부, 취약점 데이터베이스 매핑 상태에 따라 달라질 수 있다. 따라서 검색 결과는 “확인된 취약 가능 자산”을 우선 분류하는 기준으로 활용하고, 내부 자산 목록과 Redis 실제 버전을 대조하는 절차가 필요하다.
Redis 버전 취약 자산 확인
CVE-2026-23479는 Redis 7.2.0 이상 8.6.3 미만 버전에 영향을 준다. 이 중 Redis 8.6.2는 8.6.x 계열에서 패치 직전 버전이기 때문에 대표적인 취약 버전으로 볼 수 있다.
Criminal IP 검색 쿼리: redis_version:8.6.2
Criminal IP에서는 redis_version 필터를 활용해 특정 Redis 버전으로 식별된 자산을 검색할 수 있다.
검색 결과, 2,166건의 자산이 확인되었다. 해당 자산들은 CVE-2026-23479의 영향 범위에 포함되므로 해당 버전으로 운영 중인 자산이 외부에 노출되어 있다면 우선적으로 8.6.3 이상 또는 각 브랜치별 패치 버전으로 업데이트해야 한다.
브랜치별 권장 패치 버전은 다음과 같다.
| Redis 브랜치 | 영향 버전 | 권장 패치 버전 |
|---|---|---|
| 7.2.x | 7.2.0 ~ 7.2.13 | 7.2.14 이상 |
| 7.4.x | 7.4.0 ~ 7.4.8 | 7.4.9 이상 |
| 8.2.x | 8.2.0 ~ 8.2.5 | 8.2.6 이상 |
| 8.4.x | 8.4.0 ~ 8.4.2 | 8.4.3 이상 |
| 8.6.x | 8.6.0 ~ 8.6.2 | 8.6.3 이상 |
IP Report로 확인하는 Redis 자산의 복합 위험
Criminal IP의 IP Report에서는 특정 Redis 자산의 열린 포트, 서비스 배너, 취약점, 위험도, 호스팅 정보 등을 종합적으로 확인할 수 있다.
예시 자산에서는 Inbound 위험도가 Dangerous 80.0%로 표시되었으며, 총 12개의 오픈 포트와 18개의 취약점이 확인되었다. Redis 기본 포트인 6379번뿐 아니라 SSH, HTTP/HTTPS, 3000번대, 5000번대, 8000번대, 9000번대 서비스 포트가 함께 노출되어 있어 단일 Redis 서비스 이상의 복합 노출 상태로 볼 수 있다.
취약점 목록에서는 CVE-2026-23479뿐 아니라 2025년에 공개된 Redis RCE 취약점 RediShell(CVE-2025-49844)도 함께 확인되었다. 이는 Redis 자산이 신규 CVE 하나만의 문제가 아니라, 과거 취약점이 누적된 상태로 외부에 노출될 수 있음을 보여준다.
따라서 Redis 자산 점검은 “6379번 포트가 열려 있는가”를 확인하는 수준에서 끝나서는 안 된다. 동일 IP에서 함께 노출된 서비스, 누적된 CVE, 호스팅 환경, 원격 접근 가능 여부를 함께 확인해야 실제 공격 표면을 평가할 수 있다.
대응 권장 사항
- Redis 패치 적용
가장 우선적인 대응은 Redis를 패치 버전으로 업데이트하는 것이다. 운영 중인 Redis 브랜치에 따라 7.2.14, 7.4.9, 8.2.6, 8.4.3, 8.6.3 이상 버전 적용 여부를 확인해야 한다.
Redis Cloud 고객의 경우 관리형 서비스 업데이트로 이미 패치가 적용됐을 수 있으므로 클라우드 제공자에 확인하는 것이 좋다. - Redis 외부 노출 차단
Redis는 일반적으로 외부 인터넷에 직접 공개될 필요가 낮은 서비스다. 방화벽, 보안 그룹, 네트워크 ACL을 점검해 6379번 포트가 공인 IP에서 접근 가능한 상태인지 확인해야 한다. 외부 접근이 필요하지 않은 Redis 인스턴스는 내부 네트워크, VPN, 프라이빗 서브넷 등 제한된 경로에서만 접근되도록 구성해야 한다. - Redis ACL 및 명령 권한 점검
CVE-2026-23479는 인증된 공격자를 전제로 하므로 계정 권한 구성이 중요하다. XREAD BLOCK, BLPOP, BRPOP, CONFIG, EVAL 등의 명령과 광범위한 read/write 권한이 애플리케이션 계정에 함께 부여되어 있다면 공격 조건이 더 쉽게 충족될 수 있다. 서비스 계정에는 필요한 최소 권한만 부여하고, 운영자 계정과 애플리케이션 계정을 분리해야 한다. - 인증 정보 및 기본 계정 점검
Redis 인스턴스가 인증을 요구하더라도 약한 비밀번호나 장기간 공유된 계정이 사용된다면 공격 가능성은 남는다. 기본 계정 사용 여부, 유출된 비밀번호 재사용 여부, 퇴사자 또는 외주 계정 잔존 여부를 점검하고, 필요한 경우 Redis 인증 정보를 교체해야 한다. - Criminal IP과 같은 솔루션을 활한 지속적 모니터링
패치 이후에도 Redis 자산은 운영 변경, 클라우드 보안 그룹 오류, 테스트 인스턴스 방치 등으로 다시 외부에 노출될 수 있다. Criminal IP Asset Search의 product, cve_id, redis_version 등의 필터를 활용하면 외부에 노출된 Redis 자산, 취약점 매핑 자산, 특정 취약 버전 자산을 지속적으로 점검할 수 있다.
FAQ
Q1. CVE-2026-23479는 무인증 RCE 취약점인가요?
아닙니다. CVE-2026-23479는 인증된 공격자를 전제로 하는 RCE 취약점입니다. 다만 외부에 노출된 Redis 인스턴스에서 약한 인증 정보, 공유 계정, 과도한 ACL 권한이 함께 존재한다면 실제 공격 조건이 충족될 수 있습니다.
Q2. Redis 8.6.2만 취약한가요?
아닙니다. Redis 8.6.2는 대표적인 취약 버전일 뿐이며, 영향 범위는 Redis 7.2.0 이상 8.6.3 미만입니다. 운영 중인 Redis 브랜치별로 7.2.14, 7.4.9, 8.2.6, 8.4.3, 8.6.3 이상 적용 여부를 확인해야 합니다.
Q3. Criminal IP에서 CVE 검색 결과가 없으면 안전한가요?
아닙니다. CVE 기반 검색 결과는 배너 정보, 버전 식별 가능 여부, 취약점 매핑 상태에 따라 달라질 수 있습니다. 검색 결과가 없더라도 내부 Redis 자산이 영향 버전을 사용하고 있을 수 있으므로, Criminal IP 검색 결과와 내부 자산 목록을 함께 대조해야 합니다. 내부 점검을 위해서는 redis-cli INFO server | grep redis_version 명령으로 실제 버전을 직접 확인하고 위 패치 버전 표와 비교하는 절차가 필요합니다.
결론
CVE-2026-23479는 Redis의 blocked client 처리 흐름에서 발생한 use-after-free 취약점이다. 코드상으로는 processCommandAndResetClient(c)의 반환값 처리와 관련된 비교적 작은 조건에서 출발했지만, 특정 메모리 압박 조건과 블로킹 명령 타이밍이 맞물려야 발생하는 구조였기 때문에 일반적인 기능 테스트나 코드 리뷰만으로는 발견되기 어려웠던 취약점으로 볼 수 있다.
취약점 자체보다 더 중요한 것은 Redis가 실제 운영 환경에서 어떤 위치에 배치되어 있고, 어떤 권한으로 사용되는지다. 특히 Redis가 애플리케이션 계정, 세션 데이터, 캐시 계층, 내부 서비스 연결 정보와 맞닿아 있는 경우, 단일 인스턴스의 침해가 더 넓은 내부 공격 흐름으로 이어질 수 있다.
패치 적용과 함께 외부에서 식별 가능한 Redis 자산, 과도한 ACL 권한, 공유 계정, 함께 노출된 관리 포트에 대한 점검이 병행되어야 한다. 특히 클라우드 환경에서는 설정 변경이나 테스트 인스턴스 방치로 Redis가 다시 노출될 수 있으므로, 지속적인 외부 자산 모니터링을 통해 노출 상태를 주기적으로 확인하는 것이 필요하다.
관련하여 RediShell RCE 취약점 경보: 8천 개 이상 Redis 즉시 업데이트 권고 글을 참고할 수 있다.
Criminal IP (criminalip.io/ko/register) 에 가입하면 즉시 취약 자산 탐지를 시작할 수 있습니다. 또한 아래 버튼을 통해 데모를 요청하고, 엔터프라이즈 환경에서 외부에 노출된 자산을 대상으로 한 Criminal IP의 위협 인텔리전스(TI) 분석을 직접 확인해 보세요.
이 리포트는 AI기반 사이버 위협 인텔리전스 검색엔진 Criminal IP의 데이터를 바탕으로 작성되었습니다. 지금 바로 Criminal IP 무료 계정을 생성하면 리포트에 인용된 검색 결과를 직접 확인하거나, 더 방대한 위협 인텔리전스를 자유롭게 검색할 수 있습니다.
출처: Criminal IP(https://www.criminalip.io/ko), The Hacker News(https://thehackernews.com/2026/06/autonomous-ai-tool-finds-2-year-old-rce.html)