Redis 2026 보안 권고 — 메모리 손상과 조건부 RCE
2026년 5월 5일 Redis 공식 권고 · 5개 CVE의 공격 원리와 해결 과정
개요
2026년 5월 5일 Redis는 인증된 사용자가 악용할 수 있는 5가지 메모리 안전성 취약점을 공개했습니다. 네 건은 CVSS 7.7(High), 한 건은 CVSS 6.1(Medium)입니다. 취약 경로에 진입하면 메모리 손상과 조건부 원격 코드 실행(RCE)이 가능하지만 인증 우회나 무조건적인 RCE를 뜻하지 않습니다. Redis 공식 권고
다섯 CVE의 차이
| CVE | CVSS | 취약 경로 | 성립 조건과 영향 |
|---|---|---|---|
| CVE-2026-23479 | 7.7 High | 차단된 클라이언트의 재실행·축출 | 오류 반환이 처리되지 않아 Use-After-Free(UAF), 조건부 RCE |
| CVE-2026-25243 | 7.7 High | 기본 RESTORE 역직렬화 | 인증 사용자의 조작된 직렬화 데이터 → 잘못된 메모리 접근 |
| CVE-2026-25588 | 7.7 High | RESTORE + RedisTimeSeries | 모듈 사용 환경에서 특수 데이터 복원 중 잘못된 메모리 접근 |
| CVE-2026-25589 | 7.7 High | RESTORE + RedisBloom | 모듈 사용 환경에서 특수 데이터 복원 중 잘못된 메모리 접근 |
| CVE-2026-23631 | 6.1 Medium | Lua + 복제 동기화 | replica-read-only가 비활성화된 레플리카의 UAF 가능 |
다섯 CVE는 독립적인 결함입니다. RESTORE의 세 가지 문제는 하나의 연속 공격 단계가 아니며, 각 모듈의 사용 여부를 확인해야 합니다. 공식 권고는 공통적으로 인증된 접근이 필요한 공격면이라고 명시합니다.
CVE-2026-23479 — 클라이언트 재개 중 해제 후 사용
차단된 클라이언트의 명령을 다시 실행하는 도중 해당 클라이언트가 축출되는 경우 문제가 생깁니다. 내부 처리 함수 processCommandAndResetClient가 오류 값을 돌려주는 경로를 올바르게 처리하지 않아 이미 해제된 상태를 다시 참조할 수 있습니다.
- 인증 사용자의 명령이 차단된 뒤 재실행 경로로 이동합니다.
- 재실행 도중 클라이언트 축출이 발생합니다.
- 오류 반환이 처리되지 않으면 유효하지 않은 클라이언트 상태를 사용할 수 있습니다.
- 이 UAF가 추가 악용 조건과 결합하면 Redis 프로세스 권한의 RCE가 가능할 수 있습니다.
CVE-2026-25243 — 기본 RESTORE의 메모리 접근 오류
RESTORE는 직렬화된 Redis 데이터를 키로 복원하는 명령입니다. 인증된 사용자가 RESTORE를 통해 특수하게 조작된 직렬화 데이터를 전달하면 복원 처리 중 유효하지 않은 메모리 접근이 발생할 수 있습니다. 공식 글은 조건부 RCE와 데이터 유출, 서비스 중단 가능성을 설명합니다. 이 페이지는 악용 가능한 바이트 배열이나 재현 명령을 제공하지 않습니다.
CVE-2026-25588 — RedisTimeSeries RESTORE 처리
RedisTimeSeries 모듈을 사용하는 경우 해당 모듈의 RESTORE 경로에서 조작된 직렬화 데이터로 잘못된 메모리 접근을 유도할 수 있습니다. 기본 RESTORE와 구분하며, Redis 본체뿐 아니라 RedisTimeSeries의 설치·수정 버전을 함께 확인해야 합니다.
CVE-2026-25589 — RedisBloom RESTORE 처리
RedisBloom 모듈을 사용하는 경우 모듈의 직렬화 데이터 복원 경로에서 잘못된 메모리 접근이 발생할 수 있습니다. RedisTimeSeries와 다른 취약점이며, 모듈별 보안 수정 빌드를 구분해야 합니다.
CVE-2026-23631 — Lua·복제 동기화의 UAF
인증된 사용자가 마스터·레플리카 동기화 관련 경로를 악용하면 Lua 스크립팅을 사용하는 Redis에서 UAF가 발생할 수 있습니다. Redis 공식 권고는 replica-read-only가 비활성화되어 있거나 그렇게 구성될 수 있는 레플리카를 영향 조건으로 제시합니다. 모든 읽기 전용 레플리카가 이 취약점에 노출된다고 단정해서는 안 됩니다.
Redis 권고에 추가로 기재된 내부 결함 유형
Redis 공식 권고의 연구자 기여 항목은 취약점 요약보다 내부 결함을 조금 더 자세히 구분합니다. 다만 해당 항목은 각 결함을 재현하는 전체 공격 절차를 공개하지 않습니다.
| CVE | 공식 기여 항목에 기재된 내용 | 해석할 때 주의할 점 |
|---|---|---|
| CVE-2026-25243 | Redis의 double-free, VectorSets의 정수 오버플로와 범위 밖 읽기(OOB read) | CVE 요약은 RESTORE의 잘못된 메모리 접근으로 설명합니다. 세부 하위 결함이 반드시 동일한 순서로 발생한다는 의미는 아닙니다. |
| CVE-2026-25589 | RedisBloom의 범위 밖 읽기·쓰기(OOB read/write), 정수 오버플로, 힙 버퍼 오버플로 | 모듈의 직렬화 복원과 연관된 보고 내용이며, 공격자가 정확히 어떤 바이트를 전달했는지는 해당 공지만으로 확정할 수 없습니다. |
- double-free: 같은 메모리를 둘 이상 해제하는 상황을 가리키며, 힙 메타데이터 손상 위험이 있습니다.
- 정수 오버플로: 크기 계산이 정수 범위를 넘어서 예상하지 못한 작은 값 등으로 바뀌는 현상입니다. 실제 취약 여부는 해당 코드 경로에 따라 달라집니다.
- 범위 밖 읽기·쓰기: 할당된 버퍼의 경계를 벗어나 메모리에 접근하는 문제입니다. 범위 밖 읽기와 쓰기는 각각 다른 영향을 가질 수 있습니다.
이 구분은 공식 권고의 발견·기여 내역을 학습용으로 정리한 것이며, CVE별 실제 익스플로잇 체인을 역추정하거나 특정 페이로드를 주장하는 자료는 아닙니다. Redis 공식 권고의 연구자 기여 항목
제품별 수정 릴리스
다음 버전은 2026년 5월 5일 공식 권고에 표기된 수정 릴리스입니다. 운영 환경에서는 현재 지원 중인 버전·공급자 백포트·후속 보안 업데이트도 확인합니다.
| 제품 또는 모듈 | 권고에 기재된 수정 릴리스 | 적용 대상 |
|---|---|---|
| Redis OSS / CE | 6.2.22, 7.2.14, 7.4.9, 8.2.6, 8.4.3, 8.6.3 | 공식 표에 기재된 해당 계열의 다섯 CVE 수정 |
| Redis Software | 8.0.10-64, 7.22.2-79, 7.8.6-253, 7.4.6-279, 7.2.4-153 | 앞선 네 CVE의 Software 수정 빌드 |
| RedisTimeSeries | 1.12.14, 1.10.24, 1.8.23 | CVE-2026-25588 모듈 수정 |
| RedisBloom | 2.8.20, 2.6.28, 2.4.23 | CVE-2026-25589 모듈 수정 |
| Redis Cloud | 발표 당시 서비스에 수정 빌드 적용 완료 | Cloud 고유 버전 체계 사용 가능 |
Redis Software의 앞선 네 CVE 영향 범위는 공식 발표 기준 8.0.6 이하이며, 이미 수정된 특정 빌드 또는 동일 계열 후속 수정 릴리스는 예외입니다. CVE-2026-23631은 공식 표에서 OSS의 레플리카 설정 조건으로 별도 제시되므로 Software의 수정 버전 목록을 그 CVE에 임의로 적용하지 않습니다.
안전한 환경 확인 예시
다음은 공격 페이로드를 사용하지 않는 읽기 중심의 운영 점검 예시입니다. 관리자가 승인한 연결에서 인증을 마친 뒤 실행하며, 서비스 제품·권한 구성에 따라 일부 명령이 차단될 수 있습니다.
INFO server
INFO replication
MODULE LIST
CONFIG GET replica-read-only
| 조회 | 확인할 사항 | 주의점 |
|---|---|---|
| INFO server | 현재 서버의 redis_version, redis_build_id 등 실행 빌드 | 단순 버전 문자열만으로 공급자 백포트 적용 여부를 확정할 수 없음 |
| INFO replication | master/replica 역할과 복제 연결·동기화 상태 | 한 노드의 결과로 전체 클러스터를 판단하지 말 것 |
| MODULE LIST | 로드된 RedisTimeSeries·RedisBloom 모듈의 이름·등록된 버전 | MODULE LIST의 버전 숫자가 배포 패키지의 정확한 릴리스 문자열과 일치한다고 단정하지 말 것 |
| CONFIG GET replica-read-only | 해당 노드의 레플리카 쓰기 제한 설정 | 쓰기 가능한 레플리카를 점검할 때 유용하며 명령 자체가 설정을 변경하지 않음 |
실제 환경의 서버·모듈 패키지 버전은 배포 이미지, 패키지 관리 시스템 또는 제품 관리 콘솔의 정보와 대조합니다. Redis Software·Cloud에서는 일부 관리 명령이나 출력이 OSS/CE와 다를 수 있습니다.
이 명령들은 취약점 악용 여부를 판별하는 진단 테스트가 아닙니다. Redis 인스턴스에 접속이 불가능한 학습 환경에서는 아래의 입력-처리-결과 비교로 전제조건을 스스로 판단할 수 있습니다.
| 가상의 상황 | 판단 | 추가 확인 |
|---|---|---|
| RedisBloom 미설치, 인증된 사용자가 RESTORE 사용 | 25589의 Bloom 모듈 경로는 해당 인스턴스에 없음 | 기본 RESTORE의 25243 및 다른 CVE는 별도 평가 |
| RedisTimeSeries 설치, 인증된 사용자가 RESTORE 사용 가능 | 25588의 주요 전제조건이 충족됨 | 모듈·서버 보안 수정 버전과 명령 권한 |
| 레플리카가 replica-read-only=yes | 23631의 공식 권고에 기재된 쓰기 허용 조건과 다름 | 설정 변경 가능성, 실제 복제 구조, 수정 버전 |
| Redis 크래시가 관찰됨 | 조사해야 할 이상 징후 | 크래시만으로 RCE 발생이나 특정 CVE 악용을 단정할 수 없음 |
INFO · MODULE LIST · CONFIG GET · Redis 복제 구성
운영 환경의 해결 과정
- 자산 파악: 실제 실행 중인 Redis OSS/CE, Software, Cloud 버전과 모든 레플리카·클러스터 노드·설치 모듈을 조사합니다. Lua 사용 여부와 replica-read-only 설정을 확인합니다.
- 접근 경계 강화: 신뢰된 네트워크에서만 Redis에 접근하도록 방화벽·네트워크 정책을 설정하고 강한 인증을 적용합니다. ACL로 RESTORE와 스크립트 등 위험도가 큰 명령을 필요한 사용자에게만 허용합니다.
- 패치: 각 제품 계열에 맞는 최신 보안 수정 버전으로 업그레이드합니다. RedisTimeSeries·RedisBloom을 사용한다면 Redis 본체뿐 아니라 모듈의 수정 버전도 적용합니다.
- 적용 확인: 배포된 서버·모듈의 실제 실행 버전, 레플리카 상태, 설정 및 서비스 정상 동작을 확인합니다. 복제 구성은 백업과 롤링 업데이트 계획을 먼저 마련합니다.
- 침해 점검: 비인가 접속·네트워크 인그레스/이그레스, 예상 밖 Redis 명령 실행, Redis 크래시(특히 Lua 스택), Redis 사용자 권한의 이상 프로세스, 영속화·설정 파일의 알 수 없는 변경을 확인합니다.
- 의심 정황 대응: 증거 보존·격리·자격 증명 점검·데이터 무결성 검증을 수행합니다. 패치 적용만으로 이미 발생한 침해가 없었다고 결론 내릴 수는 없습니다.
접속 제한·인증·ACL은 보조 통제이며 보안 패치를 대체하지 않습니다. Redis는 공식 발표 당시 자사 또는 고객 환경에서 이 취약점들의 악용 증거를 확인하지 못했다고 밝혔지만, 모든 환경의 안전을 보증하지는 않습니다.
시각화 해석 및 공식 출처
상단에서 5개 CVE와 취약한 처리 경로 / 패치 후 검증 경로를 각각 선택할 수 있습니다. 사용자·인증/ACL·Redis 명령 처리기·서브시스템·메모리·결과 도형은 동일한 위치를 유지하지만, 취약 상태와 수정된 상태는 별도 흐름으로 보여줍니다. 패치가 공격 도중 자동으로 일어나는 단계는 아닙니다. 이는 공식 권고를 바탕으로 한 개념적인 공격 과정으로, 검증된 페이로드·실측 타이밍·익스플로잇 실행 결과가 아닙니다.
학습 목표
- 5개 CVE의 공격 전제와 취약 처리 경로를 구분한다.
- 모듈별 수정 릴리스와 Redis 본체의 버전 체계를 구분한다.
- 권한 제한과 패치, 사고 대응의 역할이 다른 이유를 설명한다.
- 서버 상태·설치 모듈·레플리카 설정을 읽기 조회로 확인하고 결과의 한계를 설명한다.
자주 하는 오해
- 5개 취약점을 인증 우회형 RCE로 설명하는 것
- RedisTimeSeries와 RedisBloom 미설치 환경에도 모듈 관련 CVE가 동일하게 성립한다고 단정하는 것
- Lua UAF의 replica-read-only 설정 조건을 생략하는 것
- Redis Software 수정 빌드와 OSS/CE 수정 버전을 혼동하는 것
- 서버 크래시를 RCE의 확증으로 단정하거나 패치를 공격 흐름의 자동 마지막 단계로 이해하는 것
핵심 정리
- 인증 이후 메모리 안전성 문제 5건: 7.7점 네 건, 6.1점 한 건
- RESTORE 경로 세 건은 기본 Redis·TimeSeries·Bloom을 구분
- Lua UAF에는 복제 노드의 replica-read-only 설정 조건이 있음
- 서버와 모듈에 각각 맞는 패치를 적용하고 탐지 지표를 조사
- 취약 경로와 패치 후 검증을 나누어 이해하며, 크래시·인증·모듈 설치 여부만으로 RCE 성공을 단정하지 않음
학습 확인
핵심 단계
- 1
인증된 사용자의 접근 — 다섯 취약점은 모두 인증 후 공격면에 해당합니다.
- 2
명령·동기화 경로 진입 — 차단 명령 재실행, RESTORE, Lua와 레플리카 동기화 경로가 각각 다릅니다.
- 3
취약한 내부 처리 — 축출 오류, 역직렬화, RedisTimeSeries·RedisBloom 복원, 복제 상태가 주요 분기점입니다.
- 4
메모리 안전성 위반 — Use-After-Free 또는 잘못된 메모리 접근으로 서버 내부 상태가 손상될 수 있습니다.
- 5
조건부 영향 — 악용 환경에 따라 Redis 서버 권한의 RCE, 정보 유출 및 서비스 장애가 가능해집니다.
- 6
보안 수정 및 재검증 — 제품·모듈 수정 버전을 적용하고 ACL, 노드 설정, 로그·복제 상태를 점검합니다.