COMMENTS (0)
댓글은 익명으로 작성되며, 삭제 비밀번호를 설정하면 본인만 삭제할 수 있습니다. 비밀번호를 설정하지 않은 댓글은 누구나 삭제할 수 있습니다.
AI 개발 플랫폼 Langflow의 CVE-2026-5027(CVSS 8.8)은 파일 업로드 API 경로 탐색 결함으로 인증 없이 RCE를 허용한다. 인터넷 노출 7,000개 인스턴스에서 실제 악용이 VulnCheck 허니팟에서 포착됐으며, Tenable이 2개월 무응답 후 공시했다. v1.10.0 업그레이드 권장.
댓글은 익명으로 작성되며, 삭제 비밀번호를 설정하면 본인만 삭제할 수 있습니다. 비밀번호를 설정하지 않은 댓글은 누구나 삭제할 수 있습니다.
패치는 두 달 전에 나왔다. 그런데 2026년 6월 11일, VulnCheck 허니팟은 아직 업데이트하지 않은 Langflow 인스턴스에서 실제 파일 투하 활동을 포착했다. Censys 스캔 기준 인터넷에 노출된 약 7,000개 인스턴스 중 상당수가 여전히 구버전을 운영 중이다. (CVSS 8.8)은 파일 업로드 API의 경로 탐색 결함으로, 공격자가 서버 파일시스템 어디에나 파일을 쓰고 최종적으로 원격 코드 실행(RCE)까지 달성할 수 있다.
| 항목 | 내용 |
|---|---|
| CVE | |
| CVSS | 8.8 (HIGH), CVSSv4: 8.7 |
| 공격 벡터 | AV:N/AC:L/PR:L/UI:N — 원격, 낮은 복잡도 |
| 취약점 유형 | 경로 탐색 (CWE-22) → 임의 파일 쓰기 → RCE |
| 영향 버전 | Langflow 1.9.0 미만 |
| 패치 | v1.9.0 (2026-04-15), 최신 권장: v1.10.0 (2026-06-10) |
| 발견자 | Tenable Network Security |
| 악용 상태 | 야생(in-the-wild) 악용 확인 (2026-06-11) |
Langflow는 GitHub 별 14만 9,000개를 기록한 오픈소스 플랫폼으로, AI 에이전트·RAG 시스템·MCP 기반 워크플로우를 드래그 앤 드롭으로 구축하는 저코드(low-code) 환경을 제공한다. LLM 서비스 수요가 폭발적으로 늘면서 기업과 스타트업이 Langflow를 핵심 AI 개발 인프라로 채택했다. Langflow 인스턴스가 침해되면 해당 플랫폼 위에서 동작하는 AI 에이전트와 연결된 모든 데이터 소스, API 키, 내부 시스템이 위험에 노출된다는 점에서 피해 파급력이 크다.
에서 특히 주목할 부분은 기본 설정(default configuration) 의 함정이다. Langflow는 설치 시 자동 로그인(auto-login)이 기본으로 활성화되어 있다. CVSS 벡터상 PR:L(낮은 권한 필요)로 표기되지만, 이 기본값 때문에 실제 환경에서는 자격증명 없이도 취약한 엔드포인트에 도달할 수 있다. Tenable이 이 취약점을 "사실상 인증 없이 RCE 가능"으로 분류한 이유다.
이번 취약점은 2025년 이후 Langflow에서 발견된 두 번째 주요 RCE다. 2025년 (CVSS 9.8)은 /api/v1/validate/code 엔드포인트가 사용자 입력을 인증 없이 exec()로 실행하는 구조적 결함으로, CISA가 KEV(Known Exploited Vulnerabilities) 목록에 등재하고 Flodrix 봇넷 배포에 악용됐다. 은 그 패치 이후에도 Langflow의 공격 표면이 줄어들지 않았음을 보여주는 사례다.
취약점 공시 프로세스에서도 문제가 드러났다. Tenable은 2026년 1월 20일 최초 통보를 시작해 같은 해 1월 27일과 2월 4일 두 차례 추가 통보를 보냈지만 응답을 받지 못했다. 2개월 이상 무응답이 이어지자 3월 23일 공개 경고를 발령하고 3월 27일 공식 어드바이저리를 릴리스했다. 벤더가 CVE를 공식 확인한 것은 패치 출시(4월)보다 늦은 6월 11일이었다.
결함의 핵심은 POST /api/v2/files 엔드포인트의 filename 파라미터에 있다. 멀티파트 폼 데이터로 전송되는 파일명이 서버 측에서 전혀 검증되지 않아, 공격자가 ../ 시퀀스를 사용해 업로드 대상 경로를 업로드 경계 밖으로 벗어나게 할 수 있다.
공격자가 Python 패키지 디렉터리에 있는 기존 모듈 파일을 악성 코드로 덮어쓰면, 다음 번 Langflow가 해당 모듈을 임포트할 때 덮어쓴 코드가 실행된다. Python은 임포트 시 sys.path 탐색 순서에 따라 패키지 디렉터리를 먼저 읽기 때문에, 이미 설치된 합법적 모듈이 대체된 상태라면 원본 확인 없이 공격자 코드를 서버 프로세스 권한으로 실행한다. cron 설정 파일을 덮어써 지속적인 접근(persistence)을 확보하는 방법도 가능하다. VulnCheck 연구팀의 보안 연구 부사장 Caitlin Condon은 "이 취약점은 원격 코드 실행을 허용한다"고 직접 확인했다.
이전 이 코드 실행 엔드포인트의 직접적 남용이었다면, 은 파일시스템 쓰기 권한을 통한 우회 경로다. 두 취약점 모두 Langflow의 기본 동작 방식이 공격 표면을 키운다는 공통점이 있다.
이번 악용이 노린 것은 v1.9.0(4월 15일) 패치가 나온 뒤에도 두 달 가까이 업데이트하지 않은 미패치 인스턴스다. 공개된 패치는 공격자에게 어느 경로가 수정됐는지 비교 분석할 단서를 주고, 공격자는 변경점을 역추적해 아직 구버전을 운영하는 인스턴스를 공략한다. 패치 공개와 야생 악용 사이의 간격을 파고드는 n-day 공격 패턴의 전형이다.
패치 공개(4월 15일)부터 야생 악용 확인(6월 11일)까지 약 57일의 간격이 있었다. 이 기간 동안 7,000개에 달하는 인터넷 노출 인스턴스가 업데이트 없이 운영됐다. 오픈소스 도구의 패치 사이클이 상용 소프트웨어보다 느린 점이 이 간격을 만들었다.
을 악용하는 공격자는 다음 흔적을 남길 수밖에 없다.
네트워크 수준: POST /api/v2/files 요청에서 멀티파트 폼 데이터의 filename 필드에 경로 탐색 시퀀스(../, %2e%2e%2f, %2e%2e/)가 포함된 HTTP 트래픽이 웹 서버 로그 또는 WAF 로그에 기록된다. 요청 성공 여부와 무관하게 이 패턴 자체가 탐지 신호다.
파일시스템 수준: Langflow 업로드 디렉터리 경계 밖의 위치에 새 파일이 생성되거나 기존 파일이 예상치 못한 시각에 수정된 경우 침해 지표다. 특히 Python 패키지 경로나 시스템 설정 위치에서 Langflow 실행 사용자(uvicorn/python)가 쓴 흔적이 발견되면 즉각 조사 대상이다.
프로세스 수준: Langflow의 Python/uvicorn 프로세스가 평소에 실행하지 않는 자식 프로세스를 생성하거나, 내부 네트워크 또는 외부 IP로 새로운 아웃바운드 연결을 시도하면 RCE가 성공했을 가능성이 있다.
ATT&CK 매핑 (추정):
| 기법 | ID | 설명 |
|---|---|---|
| Exploit Public-Facing Application | T1190 (추정) | 인터넷 노출 Langflow 인스턴스 초기 접근 |
| Ingress Tool Transfer | T1105 (추정) | 경로 탐색으로 추가 파일 투하 |
| Command and Scripting Interpreter: Python | T1059.006 (추정) | 덮어쓴 Python 모듈 실행 |
국내에서도 RAG 기반 챗봇·AI 에이전트·MCP 워크플로우 구축에 Langflow 같은 오픈소스 플랫폼을 활용하는 개발팀이 늘고 있다. Langflow 인스턴스 하나가 침해되면 거기에 연결된 OpenAI·Azure 등의 API 키와 내부 데이터베이스 접근 정보가 한꺼번에 노출될 수 있다는 점에서, AI 서비스를 빠르게 구축·운영하는 팀일수록 이 취약점의 파급이 크다.
패치는 이미 두 달 전에 공개됐다. 7,000개 인스턴스가 그 사이에도 업데이트하지 않았고, 결국 VulnCheck 허니팟이 실제 공격을 포착했다. 오픈소스 AI 플랫폼이 내부 시스템과 연결되는 구조라면, 라이브러리 업데이트 주기와 인터넷 노출 범위가 이 사건이 주는 핵심 함의다.
AI 활용 안내 이 글은 AI(Claude)의 도움을 받아 작성되었습니다. 인용된 통계와 사례는 참고 자료에 명시된 출처에 근거하며, 설명을 위한 일부 표현은 각색되었습니다.
면책 조항 본 글은 보안 인식 제고를 위한 교육 목적으로 작성되었습니다. 언급된 공격 기법을 실제로 시도하는 행위는 「정보통신망법」, 「형법」 등에 따라 처벌받을 수 있으며, 본 블로그는 이에 대한 법적 책임을 지지 않습니다.