노코드 AI 워크플로우가 파이썬 셸이 될 때 — Langflow 코드 인젝션 대응 노트

이미지 출처: CISA KEV

Langflow를 처음 켜보면 화면이 참 얌전함. 블록을 끌어다 놓고 선을 잇는 것만으로 LLM 파이프라인이 완성되니, 개발자가 아닌 기획자도 며칠이면 프로토타입을 만드는 도구임. 그런데 그 얌전한 캔버스 아래에서 실제로 벌어지는 일은 사용자가 넣은 문자열을 파이썬 코드로 해석해 실행하는 것이고, CVE-2026-9198은 바로 그 지점을 건드림.

핵심 요약

• IBM Langflow에서 사용자 입력이 서버 측 파이썬 실행 경로로 흘러들어가 임의 코드가 실행될 수 있는 코드 인젝션 결함임.
• Langflow는 기본 설정으로 인증 없이 뜨는 경우가 많아, 인터넷에 노출된 인스턴스는 사실상 원격 셸을 열어둔 것과 같음.
• 패치 적용이 우선이고, 그전까지는 노출면 차단·컨테이너 격리·자식 프로세스 기반 탐지로 버텨야 함.

왜 이 계열 취약점이 계속 나오는가

Langflow 같은 비주얼 AI 오케스트레이션 도구는 태생적으로 "코드를 데이터처럼" 다룸. 커스텀 컴포넌트를 만들 수 있게 해주려면 사용자가 작성한 파이썬 스니펫을 받아서 서버에서 돌려야 하고, 프롬프트 템플릿이나 조건 분기 역시 문자열을 평가하는 방식으로 구현되는 경우가 많음. 즉 임의 코드 실행이 버그가 아니라 기능인 구조임.

문제는 이 기능이 "인증된 관리자만 쓴다"는 전제 위에 서 있는데, 실제 배포에서는 그 전제가 자주 깨진다는 것임. 개발용으로 띄운 컨테이너가 보안그룹 정리 없이 그대로 운영에 남거나, 사내망이라 믿고 인증을 꺼두거나, API 엔드포인트 일부가 인증 미들웨어를 우회하는 경로에 걸려 있거나. 이런 상황에서 코드 인젝션 결함이 하나 발견되면 공격자 입장에서는 별도 익스플로잇 체인을 짤 필요도 없음. 정상 API에 문자열 하나 넣으면 끝나니까.

공격 흐름을 개념 수준에서 이해하기

재현 코드를 적을 이유는 없고, 방어자가 알아야 할 건 흐름임. 대략 이런 모양임.

• 진입 — 컴포넌트 정의·플로우 실행·검증 관련 API 중 하나로 요청이 들어감. 여기 담긴 필드 값이 코드 문자열로 취급됨.
• 평가 — 서버가 그 문자열을 파싱·컴파일하거나 동적으로 실행함. 샌드박스가 있더라도 파이썬 수준의 격리는 우회 기법이 잘 알려져 있어 신뢰하기 어려움.
• 실행 — Langflow 프로세스 권한으로 명령이 돌아감. 컨테이너가 root로 떠 있다면 그 권한 그대로임.
• 확산 — 프로세스 환경변수에 들어 있는 LLM API 키, 벡터DB 접속정보, 클라우드 IAM 토큰이 곧바로 전리품이 됨.

개인적으로 이 마지막 단계가 제일 무섭다고 봄. AI 워크플로우 서버는 성격상 온갖 외부 서비스 자격증명이 한곳에 모이는 지점임. OpenAI 키, 사내 DB, S3 버킷, 슬랙 웹훅까지 한 프로세스 안에 다 들어있는 경우가 흔함. 서버 하나 뚫렸는데 조직 전체 SaaS 자격증명이 새는 구조인 거죠.

지금 당장 확인할 것

1. 내 조직에 Langflow가 몇 개나 떠 있는지부터 세기. 이게 제일 어려운 단계임. IT가 승인한 인스턴스보다 데이터팀이 개인적으로 띄운 게 더 많은 경우가 태반이라, 컨테이너 이미지명(langflow) 기준 스캔과 7860 계열 포트 스캔을 같이 돌리는 걸 권함.
2. 외부 노출 여부 확인. 공인 IP에 붙어 있거나 리버스 프록시로 열려 있다면 다른 모든 조치보다 이걸 먼저 닫아야 함. 인증을 켰더라도 마찬가지임.
3. 버전 확인 및 패치. 벤더 보안 공지에 명시된 수정 버전으로 올리는 것이 유일한 근본 대책임. 우회 완화책은 시간 벌기에 불과함.
4. 자격증명 회전. 노출 이력이 있었다면 패치만 하고 끝내면 안 됨. 그 프로세스가 들고 있던 키는 전부 갈아야 함.

탐지: 무엇을 로그로 남길 것인가

코드 인젝션은 페이로드 문자열을 정규식으로 잡으려 하면 금방 한계가 옴. 인코딩이나 문자열 조합으로 얼마든지 형태를 바꿀 수 있기 때문임. 그래서 페이로드가 아니라 결과 행위를 본다는 원칙으로 접근하는 게 훨씬 오래감.

• 프로세스 계보. Langflow의 파이썬 프로세스에서 sh, bash, curl, wget, 혹은 또 다른 python이 자식으로 뜨는 순간을 알람 조건으로 잡음. 정상 운용에서는 거의 나오지 않는 조합임.
• 아웃바운드 연결. 이 서버가 평소에 붙는 곳은 LLM API 엔드포인트와 내부 DB 정도로 목록이 짧음. 목록에 없는 목적지로 나가는 트래픽, 특히 원시 IP 주소로의 연결은 강한 신호임.
• 파일 쓰기. /tmp나 애플리케이션 디렉터리에 새 스크립트·바이너리가 생성되는지 감시함.
• 인증 없는 API 접근. 세션 토큰 없이 성공(2xx)한 플로우 실행 요청이 있다면 그 자체로 이미 조사 대상임.
• 메타데이터 서비스 조회. 클라우드에 올라가 있다면 169.254.169.254로 향하는 요청이 있는지 반드시 확인함. IAM 자격증명 탈취의 전형적 신호임.

구조적으로 줄이는 방법

패치는 이번 CVE를 막지만 다음 CVE는 못 막음. 이런 계열 제품은 "언젠가 또 코드 실행 결함이 나온다"를 전제로 배치해두는 게 마음이 편함.

• 전용 네임스페이스·전용 노드에 격리하고, 비root 사용자로 실행함.
• 이그레스를 기본 차단으로 두고 필요한 LLM 엔드포인트만 화이트리스트함. 이것 하나로 리버스셸과 데이터 유출 대부분이 막힘.
• 자격증명은 환경변수 대신 짧은 수명의 시크릿으로 주입하고, 워크로드 아이덴티티를 써서 훔쳐가도 재사용이 어렵게 만듦.
• 인증은 무조건 켜고, 그 앞에 SSO 프록시를 한 겹 더 둠. 애플리케이션 인증 하나만 믿지 않음.
• 커스텀 컴포넌트 작성 권한은 별도 역할로 분리함. 플로우를 실행하는 사람과 코드를 넣는 사람은 다른 권한이어야 함.

정리하며

AI 도구가 빠르게 사내에 퍼지면서, 예전 같으면 보안팀 검토를 거쳤을 서버들이 "그냥 실험용인데요" 하는 말과 함께 조용히 늘어나고 있음. Langflow 같은 도구는 편의성이 곧 위험 표면이라, 이번 CVE는 특정 제품의 사고라기보다 AI 인프라 전반의 자산 관리 문제를 비추는 거울에 가깝다고 봄.

오늘 퇴근 전에 사내 컨테이너 목록에서 langflow 한 번만 검색해보는 걸 추천해요. 생각보다 많이 나와서 놀라실 수도 있답니다. 각자 환경에서 어떤 탐지 규칙이 잘 먹혔는지 댓글로 공유해주시면 저도 같이 배우겠습니다. 우리 같이 하나씩 점검해보아요!