워크플로우 한 줄이 셸이 되는 순간 — Kestra OSS 명령 주입(CVE-2026-49869) 방어 노트

이미지 출처: CISA KEV

데이터 파이프라인을 굴리는 팀에서 Kestra는 꽤 익숙한 이름임. YAML로 플로우를 정의하고, 스케줄 돌리고, 실패하면 재시도까지 알아서 해주는 오케스트레이터라 한 번 붙여놓으면 손이 잘 안 감. 그런데 바로 그 "손이 안 가는" 성질이 문제임. 이번에 공개된 CVE-2026-49869는 Kestra 오픈소스 배포판에서 OS 명령이 주입될 수 있는 결함으로, 워크플로우 엔진이라는 물건이 본질적으로 "남이 준 문자열을 시스템에 실행시키는 기계"라는 사실을 다시 확인시켜 줌.

핵심 요약

• Kestra OSS에서 사용자 입력이 OS 명령 실행 경로로 흘러들어가는 명령 주입 취약점(CVE-2026-49869)이 보고됨
• 워크플로우 엔진 특성상 실행 권한 자체가 넓어, 성공 시 오케스트레이터 호스트 전체가 공격자의 실행 환경이 됨
• 방어는 패치 적용 + 플로우 편집 권한 최소화 + 워커 프로세스의 자식 프로세스 로그를 탐지 대상으로 올리는 3단 구성

1. 왜 오케스트레이터에서 명령 주입이 특히 아픈가

일반 웹앱에서 명령 주입이 터지면 "웹 서버 계정 권한"까지가 보통의 손해임. 그런데 Kestra 같은 워크플로우 엔진은 성격이 다름. 이 물건은 설계상 이미 셸을 부르고, 스크립트를 실행하고, 컨테이너를 띄우고, 외부 시스템에 붙기 위한 자격증명을 잔뜩 들고 있음. 즉 취약점이 주는 것은 "새로운 권한"이 아니라 "기존의 강한 권한에 대한 접근"임.

• 워커 노드에는 DB 접속 정보, 클라우드 키, 사내 API 토큰이 시크릿 스토어를 통해 주입되어 있음
• 오케스트레이터는 대개 내부망 깊숙한 곳에 있어, 여기서 한 발짝만 옮기면 측면 이동 거리가 매우 짧음
• 정상 동작 자체가 "명령 실행"이라 악성 실행과 정상 실행의 구분선이 흐릿함

세 번째가 특히 고약한 부분인것같음. 탐지 관점에서 보면 워커가 자식 프로세스를 만드는 건 매일 수천 번 일어나는 정상 이벤트라, 단순히 "프로세스 생성"을 알림으로 걸면 그날로 알림 피로에 묻혀버림.

2. 결함의 구조 — 개념 수준으로만

명령 주입의 골격은 어디서나 같음. 애플리케이션이 문자열을 조립해 시스템 셸에 넘기는데, 그 문자열 안에 사용자가 통제 가능한 조각이 섞여 있고, 셸이 해석하는 메타문자(구분자·치환 기호 등)가 걸러지지 않은 상태로 통과하는 것. Kestra처럼 플로우 정의·태스크 파라미터·표현식 치환 같은 층이 여러 겹 쌓인 시스템에서는 "어디까지가 검증된 값인지"의 경계가 층 사이에서 흐려지기 쉬움.

실무에서 이런 결함이 살아남는 전형적인 이유가 몇 가지 있음.

• 입력 검증을 진입 지점(API·UI)에서만 하고, 내부 표현식 평가 이후의 값은 이미 안전하다고 가정함
• 템플릿 치환이 검증보다 나중에 일어나서, 검증 시점의 문자열과 실행 시점의 문자열이 달라짐
• "이건 관리자만 쓰는 기능"이라는 전제로 방어를 생략했는데, 실제 배포에서는 그 관리자 경계가 생각보다 헐거움

재현 가능한 페이로드를 적을 생각은 없고, 방어자 입장에서 필요한 건 그게 아님. 필요한 건 "우리 환경에서 저 경로가 살아 있는가"를 확인하는 방법이지, 남의 서버에서 명령을 실행하는 방법이 아니니까.

3. 지금 당장 해야 할 것 — 우선순위 순

순서를 지키는 게 중요함. 아래를 위에서부터 차례로 밟는 걸 개인적으로는 추천함.

• 패치 적용: Kestra 릴리스 노트에서 해당 CVE가 정리된 버전을 확인하고 올리는 게 1순위. 오케스트레이터는 "다운타임이 무서워서" 업데이트가 제일 밀리는 컴포넌트라 지금 버전이 몇 개월 묵어 있을 확률이 높음
• 노출면 축소: Kestra UI와 API가 인터넷에서 직접 닿는지 먼저 봄. 이런 내부 도구는 VPN이나 리버스 프록시 뒤 인증 게이트 안쪽에 있어야 정상이고, 공개 노출되어 있다면 패치보다 이쪽이 더 급함
• 권한 재정비: 플로우를 생성·수정할 수 있는 계정이 몇 개인지 세어봄. 이 취약점 계열에서 "플로우 편집 권한"은 사실상 "임의 명령 실행 권한"과 동의어라, 조회 권한과 편집 권한이 같은 롤에 묶여 있으면 지금 분리해야 함
• 실행 격리: 워커를 별도 컨테이너·별도 서비스 계정으로 돌리고, 시크릿은 필요한 태스크에만 스코프를 좁혀 주입함. 컨테이너 안에서 root로 도는 워커라면 그것부터 손보는 게 순서임
• 이그레스 통제: 워커에서 나가는 아웃바운드를 화이트리스트로 묶음. 명령 주입 이후 단계는 거의 항상 외부로 나가는 통신이라, 여기서 한 번 더 끊을 기회가 생김

4. 탐지 규칙은 이렇게 짜면 덜 시끄러움

앞에서 말했듯 "프로세스 생성"만 보면 노이즈에 파묻힘. 그래서 정상 워크플로우가 절대 하지 않을 행동을 기준선으로 잡는 게 핵심임.

• 워커 프로세스(JVM)의 자식으로 대화형 셸이나 네트워크 유틸리티가 뜨는 경우 — 정상 태스크는 대개 정해진 스크립트 인터프리터만 부름
• 플로우 실행 컨텍스트에서 시크릿 파일이나 환경변수 전체를 한꺼번에 읽어가는 접근 패턴
• 워커가 평소 붙지 않던 목적지로 나가는 아웃바운드 세션, 특히 짧은 주기의 반복 연결
• Kestra 감사 로그에서 비업무 시간대의 플로우 생성·수정, 그리고 만들자마자 즉시 실행되고 곧 삭제되는 플로우
• 실행 이력에는 남았는데 대응하는 플로우 정의가 저장소에 없는 경우 — 흔적 지우기의 전형적인 잔상임

마지막 두 개는 취약점 종류와 무관하게 오케스트레이터 침해를 잡아내는 데 두루 잘 먹히는 신호라, 이번 건이 아니더라도 규칙으로 만들어두면 두고두고 값을 함.

5. 그리고 조금 더 근본적인 이야기

요 몇 년 사이 CI/CD 러너, 워크플로우 엔진, MLOps 파이프라인, 에이전트 실행 환경까지 "설정을 받아 명령을 실행하는 시스템"이 사내 인프라의 중심으로 들어왔음. 그런데 이 계열은 자산 목록에서 자주 누락됨. 개발팀이 필요해서 올렸고, 보안팀은 존재를 늦게 알고, 인터넷 노출 여부는 아무도 정기적으로 확인하지 않는 상태로 몇 년을 굴러가다 보니 이런 CVE 하나에 조직 전체가 흔들리는 구조가 만들어지는 것임.

그래서 이번 기회에 패치만 올리고 끝내지 말고, 한 번쯤 목록을 만들어보는 걸 권함. 우리 회사에서 YAML이나 JSON을 읽어 명령을 실행하는 시스템이 몇 개나 돌고 있는지, 각각 누가 관리하고 어디까지 노출되어 있는지. 저도 예전에 이 작업을 한 번 해보고 나서 목록 절반이 제가 모르던 것이라 꽤 당황했던 기억이 있음. 아마 다들 비슷할 거라고 봄.

정리

CVE-2026-49869는 기술적으로 특별히 정교한 취약점은 아님. 오히려 명령 주입이라는 아주 고전적인 결함이, 하필 권한이 가장 넓은 컴포넌트에서 발견됐다는 점이 핵심임. 패치 → 노출면 축소 → 권한 분리 → 탐지 규칙 순서로 밟아나가면 이번 건도 정리되고, 다음에 비슷한 게 나와도 대응 시간이 훨씬 짧아짐.

혹시 이미 Kestra를 운영 중이시라면 오늘 안에 버전 확인이랑 외부 노출 여부, 이 두 가지만이라도 먼저 봐두시길. 그리고 워크플로우 엔진 쪽 탐지 규칙 잘 쓰고 계신 게 있으면 댓글로 공유해 주세요. 이런 건 서로 알려주면서 차차 다듬어가는 게 제일 빠르더라고요. 같이 해보아요!