Splunk Enterprise 사이드카 미인증 RCE 취약점 (CVE-2026-20253)

‍

Splunk Enterprise 사이드카 미인증 RCE 취약점 (CVE-2026-20253)

‍

■ 개요

‍

Splunk Enterprise의 PostgreSQL 사이드카 서비스에서 인증 없이 호출 가능한 임의 파일 작성·잘라내기(truncate) 결함이 확인됐습니다. 2026년 6월 10일 Splunk 권고 SVD-2026-0603으로 공개됐고, NVD는 이를 CWE-306(Missing Authentication for Critical Function)으로 분류했습니다. 사이드카는 Splunk 10에서 도입돼 기존 KV Store(Splunk의 키-값 저장소)를 PostgreSQL 기반으로 대체한 구성 요소입니다. 내부 관리용 서비스이지만 메인 웹 인터페이스가 /en-US/splunkd/__raw/v1/postgres/recovery/backup·/restore 경로를 그대로 외부로 프록시합니다.

외부로 노출된 프록시 엔드포인트는 임의의 Authorization 헤더를 받아들이지만 자격 증명을 실제로 검증하지 않습니다. 사이드카 측은 사용자 입력 database 필드를 PostgreSQL 연결문자열로 명령행에 그대로 전달해 pg_dump·pg_restore를 호출합니다. 공격자가 연결문자열에 hostaddr·passfile 같은 키를 주입하면 외부 데이터베이스 접속과 로컬 자격 증명 사용이 결합되고, 복원 단계에서 lo_export가 실행되는 순간 미인증 원격 코드 실행 체인이 완성됩니다.

공격 체인의 성립 여부와 별개로 영향 범위는 배포 형태에 따라 달라집니다. AWS 마켓플레이스 이미지나 권장 클라우드 템플릿으로 배포한 Splunk Enterprise는 사이드카가 기본 활성화돼 패치 전까지 즉시 노출됩니다. 온프레미스 Windows 설치는 일반적으로 사이드카가 설치·활성화되지 않아 위험도가 낮지만, KV Store 마이그레이션 정책에 따라 활성화한 환경은 별도 확인이 필요합니다. 2026년 6월 12일 watchTowr Labs가 페이로드와 RCE 단계를 모두 포함한 분석을 공개해 공격 활용 난이도가 낮아진 상태입니다.

‍

■ 요약

‍

‍

■ 기술 분석

‍

공격 경로의 핵심인 PostgreSQL 사이드카는 별도 프로세스로 127.0.0.1:5435에 바인딩되며 pg_dump·pg_restore를 실행해 KV Store 백업·복원을 처리합니다. 정상 설계상 사이드카는 내부 통신만 받지만, Splunk 웹 포트(기본 8000)가 /en-US/splunkd/__raw/v1/postgres/recovery/... 경로로 들어온 요청을 인증 검증 없이 그대로 내부 서비스에 중계합니다. 의도된 네트워크 격리가 메인 애플리케이션 프록시 단계에서 무너지는 구조입니다.

사이드카 내부에서는 사용자 입력 database 필드가 PostgreSQL 연결문자열로 해석돼 pg_dump 명령행 인자에 그대로 들어갑니다. PostgreSQL 클라이언트 라이브러리는 명령행 옵션과 연결문자열 키가 충돌하면 연결문자열 값을 우선합니다. 즉 코드가 -h localhost를 하드코딩해 두어도 공격자가 hostaddr=attacker.example.com을 주입하면 접속 대상이 외부로 전환되고, passfile=/opt/splunk/var/packages/data/postgres/.pgpass를 추가해 로컬 평문 자격 증명까지 사용하게 만들 수 있습니다.

// watchTowr Labs가 공개한 취약 호출 구간(Go)
exec.CommandContext(ctx,
    filepath.Join(m.installDir, "bin", "pg_dump"),
    "-h", "localhost",
    "-U", user,
    "-f", backupFile,
    database, // 사용자 입력이 연결문자열 인자로 그대로 흐름
)

백업 단계에서 접속 대상이 공격자 DB로 바뀌면 복원 단계에서는 공격자가 통제하는 PostgreSQL에서 가져온 SQL이 재생됩니다. 해당 SQL에는 lo_from_bytea로 임의 바이너리를 객체로 만든 뒤 lo_export로 Splunk 프로세스 권한의 임의 경로에 기록하는 함수가 포함됩니다. 공개 분석은 splunk_secure_gateway 앱의 Python 스크립트를 덮어쓰고 다음 실행 시점에 코드 실행에 도달하는 흐름을 제시했습니다. 패치는 이 미인증 진입점을 차단하기 위해 사이드카 프록시 경로에 인증을 강제하는 구조입니다.

‍

■ PoC

‍

전체 익스플로잇 체인은 두 호출로 압축됩니다. 첫 번째 호출은 미인증 백업 엔드포인트에 연결문자열을 주입해 pg_dump가 공격자 PostgreSQL에 접속하도록 만들고, 두 번째 호출은 동일 엔드포인트의 복원 경로로 그 백업을 재생해 lo_export가 Splunk 프로세스 권한으로 디스크 파일을 작성하게 합니다. 사용자 입력이 연결문자열로 직행하고, PostgreSQL이 연결문자열 값으로 명령행 옵션을 덮어쓰는 정상 동작이 결합되면서 신뢰 검증이 사라집니다.

# 방어용으로 단순화한 예시 — 실행 가능한 익스플로잇이 아님

def vulnerable_sidecar_call(database_param: str, backup_file: str) -> None:
    # 사이드카 내부 동작(개념): 사용자 입력을 연결문자열 인자로 그대로 사용
    run(["pg_dump", "-h", "localhost", "-f", backup_file, database_param])
    # 이 시점에 connection string 키가 -h localhost를 덮어쓰는 PostgreSQL 동작이 결합되면
    # ... 외부 DB 접속 전환·임의 파일 쓰기 무기화 로직 생략 ...

# 인증이 없어 외부에서 누구나 호출 가능한 정상 API 경로
http_post(
    "/en-US/splunkd/__raw/v1/postgres/recovery/backup",
    json={"database": "<연결문자열 입력>", "backupFile": "/tmp/x"},
)

‍

■ 탐지 및 점검

‍

• 공개된 체인이 두 엔드포인트 호출에 집중되므로 splunkd_access.log에서 /en-US/splunkd/__raw/v1/postgres/recovery/backup·/restore 경로의 POST 요청을 검색해 정상 운영에서 발생하지 않는 호출 시도를 확인합니다.

• 동일 경로 호출의 Authorization 헤더가 Basic Og==처럼 빈 자격 증명으로 들어오거나 비표준 클라이언트 IP에서 발생했는지 점검합니다.

• 호스트의 pg_dump·pg_restore 프로세스 명령행 인자에 hostaddr=·passfile=·외부 호스트명 같은 비정상 연결문자열 토큰이 포함됐는지 조사합니다.

• /opt/splunk/etc/apps/splunk_secure_gateway/bin/ 하위 Python 스크립트의 수정 시간과 해시를 정상 패치 본과 대조해 변조 여부를 확인합니다.

• bin/splunk version 또는 패키지 관리자로 영향 버전(10.0.0~10.0.6, 10.2.0~10.2.3) 운용 여부를 즉시 파악합니다.

‍

■ 대응 방안

‍

• 탐지 결과와 관계없이 Splunk Enterprise를 10.0.7, 10.2.4, 10.4.0 이상으로 업그레이드합니다. 벤더는 별도 임시 대응책을 제공하지 않습니다.

• AWS 마켓플레이스 이미지·IaC 템플릿으로 배포한 인스턴스를 우선 패치 대상으로 분류하고, 패치 전까지는 보안 그룹·WAF에서 관리 포트(기본 8000)와 사이드카 포트(5435)의 외부 노출을 차단합니다.

• Splunk Cloud Platform은 PostgreSQL 사이드카를 사용하지 않아 본 결함의 영향 범위에서 제외되지만, 자체 운영하는 Splunk Enterprise 인스턴스와 혼합 운영 중인 경우 후자만 패치 대상으로 분리해 관리합니다.

• 침해 가능성이 있는 자산은 PostgreSQL 계정 비밀번호, splunk.secret, HEC·REST·관리 토큰을 교체하고 KV Store에 저장된 키 값을 재발급합니다.

• 사이드카 기능을 사용하지 않는 환경은 PostgreSQL 사이드카 비활성화 가능성을 검토하고, 활성으로 유지하는 경우 관리망과 사용자망을 분리합니다.

‍

[참고 자료]

SVD-2026-0603 — Splunk Security Advisory

Why Use App-Level Auth When Every Database Has Auth? — watchTowr Labs

NVD — CVE-2026-20253

CVE-2026-20253: Splunk Enterprise RCE & File Operation Flaws — Orca Security