Langflow 코드 검증 API 미인증 원격 코드 실행 취약점 (CVE-2026-0768)

NOW Briefing

Brief 1 AI 애플리케이션을 블록 조립 방식으로 만드는 로우코드 플랫폼 Langflow에서 인증 없이 임의 코드가 실행되는 원격 코드 실행(RCE) 취약점(CVE-2026-0768)이 확인됐습니다. 코드 검증 기능이 전달받은 코드 문자열을 그대로 실행하는 것이 원인이며, 1.4.2 이하 모든 릴리스가 영향을 받습니다.

Brief 2 2026년 8월 30일부터 실제 공격에 악용되고 있습니다. VulnCheck가 인터넷에 노출해 둔 미끼 서버(카나리)에서 관측된 공격 요청은 Langflow 관리자 자격증명, OpenAI·AWS 키가 담긴 환경변수, 서버에 저장된 비밀 키 파일, SSH 접근 정보를 조회하려 했습니다.

Brief 3 1.11.6 이상으로 업그레이드하고, 즉시 적용이 어렵다면 인터넷 노출을 차단해야 합니다. 취약 버전으로 외부에 열려 있던 인스턴스는 해당 호스트에 보관돼 있던 API 키와 관리자 자격증명을 폐기·재발급해야 합니다.

‍

Langflow 코드 검증 API 미인증 원격 코드 실행 취약점 (CVE-2026-0768)

‍

■ 개요

‍

Langflow는 대규모 언어 모델(LLM) 기반 애플리케이션과 AI 에이전트를 화면에서 블록으로 조립해 만드는 로우코드 플랫폼입니다. 사용자가 직접 파이썬 코드를 작성해 커스텀 컴포넌트를 만들 수 있고, 편집기에는 그 코드가 정상인지 확인해 주는 코드 검증 기능이 있습니다. 이 검증 기능이 전달받은 코드 문자열을 문법 검사에서 멈추지 않고 실제로 실행하는 것이 이번 취약점의 본질입니다. Trend Micro의 Zero Day Initiative(ZDI)가 CVE-2026-0768로 공개했고, 1.4.2 이하 모든 릴리스가 영향을 받습니다.

ZDI 권고는 이 취약점으로 root 권한으로 임의 코드가 실행되며 인증이 필요 없다고 기술합니다. 공격에 성공하면 Langflow가 보관하는 비밀 키와 프로세스 환경변수에 담긴 외부 서비스 자격증명이 노출될 수 있습니다. AI 플랫폼 특성상 이 환경변수에는 상용 LLM API 키와 클라우드 접근 키가 함께 들어 있는 경우가 많아, 서버 한 대의 침해가 곧 외부 유료 서비스 계정과 클라우드 계정 침해로 이어질 수 있습니다.

ZDI 타임라인 기준으로 2025년 7월 18일 벤더에 통보됐고, 조율 기한이 지난 뒤 2026년 1월 9일 제로데이 형태로 공개됐습니다. 공개 이후 7개월 넘게 악용 보고가 나오지 않다가, 위협 인텔리전스 업체 VulnCheck가 영국에 배치한 카나리 시스템에서 2026년 8월 30일 처음 악용 시도가 관측됐습니다. 시도는 몇 시간 만에 50건을 넘어 8월 31일 기준 누적 360건으로 늘었습니다. VulnCheck는 이 트래픽이 주로 러시아에서 유입됐으며, 관측 시점에 알려진 공개 PoC 익스플로잇이 없다고 밝혔습니다.

‍

■ 요약

‍

항목	내용
CVE ID	CVE-2026-0768 (커스텀 컴포넌트 코드 검증 경로의 코드 인젝션)
CVSS 점수	CVSS v3.0 9.8
취약점 유형	CWE-94, 미인증 원격 코드 실행
영향/위험	• 인증 없이 root 권한으로 임의 파이썬 코드 실행 가능 • 관리자 계정·OpenAI·AWS 자격증명이 담긴 환경변수 조회 시도가 카나리 시스템에서 관측됨 • Langflow 비밀 키 파일·SSH 접근·셸 히스토리 조회 시도가 관측됨 • 2026-08-30 이후 실제 공격에 악용 중
취약 버전	Langflow 1.4.2 이하 전체 릴리스
패치 버전	• 1.11.6 이상 권장 • 1.4.3 태그 소스에는 검증 경로의 코드 실행 로직이 그대로 남아 있어 불충분

‍

■ 취약점 동작과 노출 조건

‍

1.4.2 태그의 src/backend/base/langflow/utils/validate.py에 있는 validate_code()는 요청으로 받은 코드 문자열을 구문 트리로 파싱한 뒤, 그 안의 함수 정의를 하나씩 컴파일해 exec()로 실행합니다.

    # Evaluate the function definition
    for node in tree.body:
        if isinstance(node, ast.FunctionDef):
            code_obj = compile(ast.Module(body=[node], type_ignores=[]), "<string>", "exec")
            try:
                exec(code_obj)
            except Exception as e:  # noqa: BLE001
                logger.opt(exception=True).debug("Error executing function code")
                errors["function"]["errors"].append(str(e))

함수를 호출하지 않아도 정의를 실행하는 순간 데코레이터와 기본 인자 표현식이 평가되므로, 검증 요청을 처리하는 것만으로 공격자가 넣은 코드가 동작합니다. 같은 함수는 코드에 포함된 임포트 구문도 importlib.import_module()로 실제 로드합니다.

검증 요청을 받는 /api/v1/validate/code 라우트는 1.4.2 소스에서도 로그인 사용자 의존성(CurrentActiveUser)을 선언합니다. 다만 인증 설정의 기본값이 자동 로그인(AUTO_LOGIN: bool = True)이어서, 이 값이 켜져 있으면 API 키나 토큰이 없는 요청도 superuser 계정으로 해석돼 통과합니다. 인증 처리 코드에 들어 있는 경고 문구는 v1.5부터 자동 로그인 환경에서도 유효한 API 키나 JWT를 요구하도록 기본 동작이 바뀐다고 명시합니다. ZDI가 영향 범위를 1.4.2 이하로 한정한 것도 이 기본 동작 변경과 맞아떨어지는 정황입니다.

‍

■ 패치가 바꾼 검증 동작

‍

검증 경로에서 코드를 실행하지 않도록 하는 수정은 2026년 6월 18일 병합된 Langflow PR #13696에서 이뤄졌습니다. 이 PR은 문제를 인증이 필요한 RCE로 기술하면서도, 기본 단일 사용자 자동 로그인 설정에서는 사실상 미인증으로 악용된다고 설명합니다. 아래는 그 커밋의 unified diff 중 validate_code()의 함수 정의 처리 부분입니다.

     for node in tree.body:
         if isinstance(node, ast.FunctionDef):
-            code_obj = compile(ast.Module(body=[node], type_ignores=[]), "<string>", "exec")
             try:
-                # Create execution context with common langflow imports
-                exec_globals = _create_langflow_execution_context()
-                exec(code_obj, exec_globals)
+                compile(ast.Module(body=[node], type_ignores=[]), "<string>", "exec")
             except Exception as e:  # noqa: BLE001
-                logger.debug("Error executing function code", exc_info=True)
+                logger.debug("Error compiling function code", exc_info=True)
                 errors["function"]["errors"].append(str(e))

수정 후에는 컴파일만 수행해 문법·컴파일 오류를 보고하고, 검증 경로에서 코드를 실행하지 않습니다. 수정이 이뤄진 시점의 코드에는 실행 컨텍스트를 만들어 exec()에 전달하는 로직까지 붙어 있었지만, 1.4.2에서는 인자 없는 exec(code_obj) 형태였습니다. 두 경우 모두 검증 경로에서 실행이 일어난다는 점은 같습니다.

2026년 9월 1일 공개된 1.11.6 태그 소스에서는 검증 경로의 exec() 호출이 제거되고 컴파일만 남은 상태를 확인했습니다. 같은 파일의 컴포넌트 실행 헬퍼에는 exec()가 그대로 있지만, 이는 검증 경로가 아니라 별도 설정으로 통제되는 실행 기능입니다. 반면 1.4.3 태그 소스의 validate_code()와 자동 로그인 기본값은 1.4.2와 동일합니다. 공개 취약점 기록은 1.4.2를 영향 버전으로 지목할 뿐 최초 수정 릴리스를 특정하지 않으며, 확인한 공개 소스에서 1.4.3이 이 실행 경로를 닫았다는 근거는 찾지 못했습니다. 주요 보도가 함께 권고하는 1.11.6 이상을 기준으로 삼아야 합니다.

‍

■ 탐지 및 점검

‍

• 웹 서버·리버스 프록시 로그에서 /api/v1/validate/code로 향하는 POST 요청과 응답 코드를 조회합니다. 요청 본문의 code 값까지 확인하려면 프록시 본문 로깅이나 전체 패킷 캡처가 필요하며, 방화벽·NetFlow 로그로는 목적지와 연결 메타데이터만 확인됩니다.

• Langflow 서버 프로세스에서 파생된 셸(/bin/sh, bash)이나 curl·wget 실행 이력이 있는지 확인합니다. 정상 운영 중에는 검증 요청이 자식 프로세스를 만들지 않습니다. 다만 이 신호 하나만으로 침해를 확정하지 말고, 같은 시각의 검증 엔드포인트 요청 기록과 함께 상관 분석해 추가 점검 대상으로 분류합니다.

• /root/.cache/langflow/secret_key 파일과 ~/.ssh 디렉터리, .bash_history, .env 파일의 최근 읽기 접근 흔적을 점검합니다. VulnCheck가 관측한 공격 요청에는 이 자산들의 조회와 LANGFLOW_SUPERUSER, OPENAI_API*, AWS_ACCESS*, AWS_SECRET* 환경변수 조회가 포함됐습니다.

• 운영 중인 인스턴스의 LANGFLOW_AUTO_LOGIN 설정값과 버전을 확인해, 1.4.2 이하이면서 자동 로그인이 켜진 조합을 우선 격리 대상으로 분류합니다.

• 외부에서 접근 가능한 Langflow 관리 화면이 있는지 인터넷 노출 자산 목록으로 대조합니다. 보도 기준으로 취약한 Langflow 호스트는 미국·독일·말레이시아·브라질·인도에 다수 분포합니다.

‍

■ 대응 방안

‍

• Langflow를 1.11.6 이상으로 업그레이드합니다. 1.4.3만 적용하는 것으로는 검증 경로의 실행 로직이 남아 있어 충분하지 않습니다.

• 즉시 업그레이드가 어려우면 Langflow 인스턴스를 인터넷에서 분리하고, 네트워크 ACL이나 리버스 프록시 인증으로 접근 주체를 내부 사용자로 제한합니다. ZDI 권고도 제품과의 상호작용 제한을 유일한 완화 조치로 제시했습니다.

• 인증을 실제로 강제하도록 LANGFLOW_AUTO_LOGIN을 비활성화하고, 기본 superuser 계정 대신 별도 자격증명과 API 키를 발급해 운영합니다.

• 취약 버전으로 인터넷에 노출됐던 인스턴스는 침해 가능성을 전제로, 해당 호스트에 보관돼 있던 OpenAI·클라우드 API 키, Langflow 관리자 자격증명, 비밀 키 파일, SSH 키를 폐기하고 재발급합니다.

• Langflow 컨테이너를 root로 구동하지 않도록 실행 사용자를 낮추고, 자격증명은 프로세스 환경변수 대신 외부 시크릿 관리 체계에서 주입합니다.

⚠️ WARN

공개 PoC가 확인되지 않았다는 점은 위험 완화 근거가 되지 않습니다. 이번 사례는 공개 PoC가 확인되지 않은 상태에서 실제 공격이 먼저 관측됐습니다.
자격증명 재발급을 미루면 서버를 패치한 뒤에도 이미 반출됐을 수 있는 API 키로 외부 서비스 계정이 계속 악용될 수 있습니다.

‍