"CVSS 10.0짜리 RCE"는 취약점 뉴스에서 가장 심각한 표현 중 하나입니다. 왜 RCE가 "최악의 부류"인지, 다른 버그와 무엇이 다른지를 처음부터 설명합니다.
다른 버그와의 차이
대부분의 취약점은 영향이 제한적입니다. RCE는 서버 자체에서 명령을 실행하므로 한 차원 더 심각합니다.
| 취약점 | 코드가 실행되는 곳 | 주요 피해 | 일반적 심각도 |
|---|---|---|---|
| XSS | 브라우저 | 세션 탈취, 변조 | 중–높음 |
| SQLi | 데이터베이스 | 데이터 읽기/변경 | 높음 |
| RCE | 서버 자체 | 장악, 다른 시스템으로 확산, 프로세스가 할 수 있는 모든 것 | 최악(10.0급) |
왜 최악의 부류인가
공격자가 당신의 서버에서 명령을 실행한다는 것은 그 프로세스가 할 수 있는 모든 일을 그들이 할 수 있다는 뜻입니다.
RCE 달성 (임의 코드 실행)
.env 를 읽어 비밀 탈취피해가 어디까지 퍼지는지는 "그 프로세스의 권한"으로 결정됩니다. 바로 그래서 컨테이너화, 최소 권한, 격리(피해 확산 제한)가 효과적입니다. root로 실행하면 공격자가 서버 전체를 제어할 수 있고, 비특권으로 격리해 실행하면 봉쇄할 수 있습니다.
대부분의 RCE는 당신의 버그가 아니라 공개된 취약점에서 온다
RCE는 당신이 작성한 버그가 아니라, 당신이 사용하는 프레임워크나 라이브러리의 알려진 취약점에서 오는 경우가 매우 많습니다. 많은 이정표적 사고가 RCE였습니다.
- Log4Shell (CVE-2021-44228): 로깅 컴포넌트를 통한 RCE. 전 세계의 조직이 대응에 쫓겼습니다.
- Equifax (CVE-2017-5638): 패치되지 않은 Struts의 RCE로 약 1억 4,700만 명의 데이터가 유출되었습니다.
- 방치된 CVSS 10.0: 공개된 RCE가 몇 달간 패치되지 않은 채 방치됨.
방어를 위해 할 수 있는 일
공개된 CVE를 방치하지 않기 (가장 큰 방어)
CVE 를 기계(Dependabot / osv-scanner)로 모니터링하고 수정된 버전으로 빠르게 업데이트하세요. 대부분의 RCE는 알려진 취약점을 패치하지 않고 방치한 데서 옵니다.
실행 중인 버전으로 판단하기
매니페스트의 하한선이 아니라 실제로 실행 중인 버전으로 위험을 측정하세요. 텍스트를 믿으면 위험을 잘못 판단합니다. 록 파일(lockfile)과 실제 배포된 이미지를 함께 확인해, "고쳤다고 적혀 있지만 실제로는 옛 버전이 도는" 상황을 피하세요.
피해 제한
비특권 사용자로 실행하고, 컨테이너와 네트워크를 격리하세요. 당하더라도 피해를 봉쇄합니다. 같은 맥락에서, 프로세스가 읽을 수 있는 비밀(.env, 토큰)을 꼭 필요한 것만으로 줄이면, 설령 코드가 실행되더라도 손에 들어갈 수 있는 것이 줄어듭니다.
입력을 실행으로 곧장 넘기지 않기
외부 입력을 셸 명령, 역직렬화, 템플릿 평가에 직접 넣지 마세요. 스스로 RCE를 만들지 않기 위한 기본입니다.
RCE로 이어지는 주요 원인
RCE는 결과를 가리키는 이름이고, 원인은 여러 유형으로 나뉩니다. 2025년 12월 공개된 MITRE의 "CWE Top 25"(가장 위험한 소프트웨어 약점 25개)에는 RCE로 이어지는 약점이 많이 들어 있습니다.
| 원인(CWE) | 내용 | CWE Top 25(2025) |
|---|---|---|
| OS 명령 인젝션(CWE-78) | 외부 입력이 셸 명령에 섞여 명령으로 실행된다 | 9위 |
| 코드 인젝션(CWE-94) | 외부 입력이 프로그램 코드로 평가되어 실행된다 | 10위 |
| 위험한 파일 업로드(CWE-434) | 실행 가능한 파일이 서버에 놓여 거기서 실행된다(→ 파일 업로드 취약점(영문)) | 12위 |
| 안전하지 않은 역직렬화(CWE-502) | 외부에서 받은 데이터를 복원하는 도중 코드가 실행된다(→ 안전하지 않은 역직렬화(영문)) | 15위 |
| 메모리 손상(CWE-787 등) | C/C++로 작성된 소프트웨어가 메모리 경계 밖에 써서 실행 흐름을 빼앗긴다 | 5위(범위 밖 쓰기) |
앞의 네 가지는 직접 만드는 앱에 들어가기 쉬운 것입니다. 메모리 손상은 주로 OS, 네트워크 장비, 라이브러리에서 발견되며, 사용자 쪽의 방어는 업데이트입니다.
실제 사례: 밖에서 닿는 제품이 노려진다
- 네트워크 장비: 2024년 7월 미국 CISA와 FBI는 네트워크 경계 장비의 OS 명령 인젝션이 인증 없는 RCE로 악용된 일을 계기로, 제조사에 이 유형의 결함을 없애라고 요청하는 경보를 냈습니다(→ VPN 장비 지키기(영문)).
- AI 도구: AI 에이전트를 만드는 도구 Langflow의 코드 검증 기능에 인증 없는 RCE(CVE-2026-0770)가 있었고, KEV에 등재되었습니다(→ CVE-2026-0770 해설(영문)).
- CMS: WordPress 코어의 파일 포함 결함(CVE-2026-87902)은 특정 서버 조건이 갖춰지면 RCE로 이어집니다(→ CVE-2026-87902 해설(영문)).
공통점은 제품이 인터넷에서 인증 없이 닿는 곳에 있었다는 점입니다. RCE의 위험도는 결함 자체뿐 아니라 밖에서 닿을 수 있는지에 크게 좌우됩니다.
"CVSS 10.0짜리 RCE"를 들었을 때 확인할 것
그것을 쓰고 있는가?
CVE / KEV 조회로 CVE 번호에서 영향받는 제품과 버전을 확인하고, 내 환경에서 실제로 돌고 있는 버전과 비교합니다. 의존성은 osv-scanner로 한꺼번에 검사할 수 있습니다.
밖에서 닿을 수 있는가?
해당 기능이나 관리 화면에 인터넷에서 인증 없이 닿을 수 있는지 확인합니다. 닿는다면 업데이트할 때까지 서비스에서 내리는 것을 검토하세요.
악용되고 있는가?
CISA의 KEV에 있다면 실제로 악용되고 있습니다. 점수 읽는 법은 CVSS·EPSS·KEV로 우선순위 정하기를 참고하세요.
업데이트 후 침입 흔적을 찾는다
업데이트 전에 누군가 들어왔다면 업데이트 후에도 그대로 남아 있습니다. 모르는 파일, 새 계정, 수상한 외부 통신(C2)이 없는지 살펴보세요.
출처(1차 자료)
- MITRE, "2025 CWE Top 25 Most Dangerous Software Weaknesses"(2025년 12월) — cwe.mitre.org(CWE-78, 94, 434, 502, 787의 순위)
- CISA·FBI, "Secure by Design Alert: Eliminating OS Command Injection Vulnerabilities"(2024년 7월 10일) — cisa.gov
- FIRST, "CVSS v3.1 Specification Document" — first.org(심각도 채점 방식)
- CISA, "Known Exploited Vulnerabilities Catalog" — cisa.gov
다음으로 읽기
- 용어집: CVE란 · CVSS란
- 역사: Log4Shell — 의존성을 통한 RCE
- 방어: Next.js를 안전하게 운영하기 (CVE 위생)