위협 피드

CVE-2026-0770 — Langflow 인증 없는 원격 코드 실행 (해설 및 대응)

Langflow 원격 코드 실행(CVE-2026-0770, CISA KEV 등재): 버전 관련 진술과 수정 참조를 구분하고, 노출을 제한하며, 업데이트하고 침해 여부를 확인하십시오.

게시 2026-07-23 업데이트 2026-10-23 최종 확인 2026-07-23 6분 읽기
이 페이지에서

실제 공격에서 악용이 확인된 취약점(CISA KEV 등재)에 대한 방어 관점의 권고문입니다. 무슨 일이 일어나는지, 무엇이 영향을 받는지, 어떻게 대응할지를 다룹니다. 공격 방법이나 개념 증명(PoC)은 포함하지 않습니다.

버전 출처 간 차이(2026년 10월 23일 확인)

GHSA는 패치된 릴리스 없이 1.7.3까지의 버전을 나열하며, CNA는 1.4.2를 영향 받는 버전으로 표시하고 다른 버전은 알 수 없다고 합니다. KEV는 v1.9.0을 가리키며, 이 버전의 릴리스 노트에는 이 CVE의 최소 수정 릴리스가 명시되어 있지 않습니다. 각 출처의 범위를 구분해서 보십시오.

권고 요약
CVE
CVE-2026-0770 (신뢰할 수 없는 제어 영역의 기능 포함, CWE-829)
심각도
Critical (CVSS 9.8) — 실제 악용 중 (CISA KEV)
유형
validate(코드 검사) 엔드포인트의 인증 없는 원격 코드 실행(RCE)
영향
인증 없이 임의 코드 실행(많은 배포 환경에서 root), 자격 증명 및 클라우드 메타데이터 탈취, 내부 확산
영향 버전
Langflow 1.7.3 이하
주요 대응
노출 중단(네트워크 격리 + 인증) + 최신 릴리스로 업데이트
9.8
CVSS / 최고 등급
인증 없음
접근 가능성
RCE→root
접근 시 영향
노출 중단
주요 방어

인증 없이 접근됨

validate 엔드포인트

임의 코드 실행(많은 환경에서 root)

자격 증명 및 클라우드 메타데이터 탈취 / 내부 확산

대응: 노출 중단(네트워크 격리 + 인증) 및 업데이트

인증 없이 접근할 수 있어 무차별 스캔의 대상이 됩니다. 두 곳에서 막을 수 있습니다. 노출하지 않는 것과 버전을 업데이트하는 것입니다.

수정하지 않는 것이 위험한 이유

인증 없이 root 수준의 코드 실행에 도달할 수 있으므로, 공개된 Langflow 인스턴스는 대규모 자동 스캔의 대상이 됩니다. 보도와 위협 인텔리전스에 따르면, 실제 공격은 약 2026-06-27부터 관찰되었으며, CISA가 KEV 카탈로그에 추가하기 전에 64개의 고유 소스 IP에서 220회 이상의 악용 시도가 기록되었습니다. 관찰된 행위에는 명령 실행 확인, 시스템 정찰, 추가 스크립트 가져오기, 자격 증명 및 클라우드 메타데이터 접근 시도가 포함됩니다. 인터넷에서 접근 가능했다면 침해된 것으로 간주하십시오.

영향 범위

항목상세
대상Langflow (AI 에이전트/플로우용 시각적 빌더)
영향 버전1.7.3 이하 (GHSA 범위; CNA는 1.4.2를 영향 받는 버전으로 표시하고 다른 버전은 알 수 없다고 함)
수정 버전GHSA에 등록된 패치 버전 없음; KEV는 v1.9.0을 가리킴. 여기서는 최소 수정 버전을 확정하지 않음. 공식 정보를 확인하고, 업데이트하며, 격리와 인증을 함께 적용하십시오
전제 조건인증 불필요(인증되지 않음)
접근 시 영향임의 코드 실행(RCE) → 서버 장악, 자격 증명/메타데이터 탈취, 내부 확산
상태실제 악용 중 (CISA KEV)

심각도 점수 차이에 대한 참고(양측 모두)

점수는 평가 기관과 CVSS 버전에 따라 다릅니다. NVD와 ZDI(ZDI-26-036)는 CVSS 3.x에 따라 9.8(Critical)을 부여하고, GitHub Advisory는 CVSS 4.0에 따라 8.9(High)를 부여합니다. 서로 다른 버전이나 평가 조건을 사용한 점수는 직접 비교할 수 없습니다. 인증되지 않은 코드 실행과 실제 악용이 보고되었으므로, 노출 제한과 업데이트를 우선하십시오.

반복되는 유형의 취약점입니다(중요)

Langflow의 validate / 코드 실행 엔드포인트에서는 이전에도 인증 없는 RCE가 KEV 카탈로그에 추가되었습니다(CVE-2025-3248). 또한 별도의 Langflow 취약점에서는 "수정된" 것으로 보였던 버전이 여전히 악용 가능했다고 보고되었습니다. "업데이트했으니 안전하다"고 가정하지 마십시오. 업데이트는 하되, 네트워크 격리, 인증, 최소 권한을 상시적인 1차 통제 수단으로 삼으십시오.

대응 방법

1

인터넷 노출 중단(최우선)

Langflow를 공용 네트워크에서 분리하십시오. 역방향 프록시 + 인증, IP 허용 목록, VPN/내부 전용 접근을 사용해 인증되지 않은 접근 가능성을 0으로 만드십시오. Langflow는 설계상 코드를 실행하므로, 노출 자체가 근본적인 위험입니다. 이것이 RCE를 실제로 차단하는 조치입니다.
2

최신 릴리스로 업데이트(단, 패치만 믿지 마십시오)

사용 가능한 최신 릴리스로 업데이트하십시오. GHSA의 등록 정보와 KEV의 수정 참조를 구분하고, 업데이트와 격리 + 인증을 함께 적용하십시오. 현재 상태는 항상 공급사의 릴리스 노트와 보안 권고에서 확인하십시오.
3

침해 여부 확인(노출되었다고 가정)

의심스러운 프로세스, cron 항목, 외부 트래픽, 예상치 못한 파일 쓰기, 자격 증명 또는 클라우드 메타데이터 접근 흔적(예: 인스턴스 IAM 토큰), validate 엔드포인트에 대한 인증되지 않은 요청을 확인하십시오. RCE는 "서버 비밀 정보(키, 토큰, DB 자격 증명)가 유출되었을 수 있다"는 전제로 다루고, 노출되었다면 자격 증명을 교체하십시오.
4

최소 권한으로 실행하고 공격 표면 축소

Langflow를 root가 아닌 사용자로 실행하고, 접근 가능한 클라우드 권한(인스턴스 역할 등)을 최소화하십시오. 필요하지 않다면 메타데이터 엔드포인트로의 접근을 제한하십시오. 침해되더라도 피해를 줄이기 위한 다층 방어입니다.
5

CVE를 기계적으로 모니터링하고 빠르게 업데이트

Langflow와 기타 자체 호스팅 제품의 버전 및 CVE를 모니터링하고, 권고가 공개되면 신속하게 업데이트하거나 차단하십시오. 이는 "알려진 공개 CVE를 놓쳐 패치되지 않은 채 방치되는" 상황을 구조적으로 막습니다.

이 사이트의 견해: 코드를 실행하는 도구는 기본적으로 '비노출'이어야 합니다

이 문제의 본질은 단일 버그라기보다, 설계상 코드를 실행하는 도구를 신뢰할 수 없는 네트워크에 노출한 것에 있습니다. AI 에이전트 빌더와 로우코드 플랫폼은 편의를 위해 임의 코드 실행을 전제로 하는 경우가 많으며, "내부 테스트용" 인스턴스가 어느새 인터넷에 노출되기도 합니다. 업데이트는 필수이지만, 장기적으로 효과가 있는 것은 "개발/테스트용 코드 실행 도구는 절대 인터넷에 연결하지 않는다"는 기본값과, 자체 호스팅 CVE를 기계적으로 모니터링하고 신속히 차단하는 절차입니다. 관련 내용은 AI 시대 보안 체크리스트도 참고하십시오.

다음으로 읽을거리

출처 및 범위

아래 1차 자료는 위에서 논의한 설정, 범위 또는 대응 내용을 뒷받침합니다. 링크는 2026년 10월 23일에 확인했습니다. 버전 및 구성 조건을 직접 확인하십시오. 점검 우선순위와 교훈은 이 사이트의 지침이며, 전체 기사 재검증이나 안전을 보장하는 내용이 아닙니다.

FAQ

QCVE-2026-0770으로 공격자가 무엇을 할 수 있습니까?
A

Langflow의 코드 검사(validate) 엔드포인트에서 exec_globals 매개변수로 전달된 신뢰할 수 없는 입력이 Python의 exec()로 직접 실행됩니다. 인증되지 않은 공격자는 이를 이용해 임의의 코드를 실행할 수 있으며(많은 배포 환경에서 root 권한), 이로 인해 서버 장악, 자격 증명 및 클라우드 메타데이터 탈취, 다른 시스템으로의 확산으로 이어질 수 있습니다. CVSS 9.8이며, 실제 공격에서 악용이 확인되었습니다(CISA KEV).

Q가장 확실한 대응 방법은 무엇입니까?
A

인터넷 노출을 제한하고, 인증과 최소 권한을 요구하며, 업데이트하고 침해 여부를 확인하십시오. GHSA에는 등록된 패치 릴리스가 없고 KEV는 v1.9.0을 가리킵니다. 이 차이로부터 최소 수정 버전을 추정하지 말고, 설치된 버전에 대해 공식 정보를 확인하십시오.

Q출처마다 심각도 평가가 다른 이유는 무엇입니까?
A

NVD와 ZDI는 CVSS 3.x에 따라 9.8(Critical)을 부여하고, GitHub Advisory는 CVSS 4.0에 따라 8.9(High)를 부여합니다. 서로 다른 버전이나 평가 조건을 사용한 점수는 직접 비교할 수 없습니다. 인증되지 않은 코드 실행과 실제 악용이 보고되었으므로, 노출 제한과 업데이트를 우선하십시오.