Langflow 코드 주입 취약점(CVE-2026-0768)｜실제 악용과 대응

실제 악용으로 달라진 우선순위

Langflow는 시각적 흐름을 조합해 AI 애플리케이션을 만드는 플랫폼이지만, 내부적으로는 사용자가 구성한 Python 기반 구성요소와 외부 서비스 자격증명을 함께 다룹니다. 이런 실행 특성 때문에 네트워크에 노출된 인스턴스의 코드 검증 경계가 무너지면 일반적인 웹 입력 오류보다 영향이 커질 수 있습니다. CVE-2026-0768은 인증을 거치지 않은 요청이 코드 검증 기능에 전달되고, 입력값이 충분히 제한되지 않은 채 Python 실행으로 이어지는 코드 주입 취약점입니다. Zero Day Initiative는 이 문제를 CVSS 9.8로 평가했으며 원격 공격자가 인증 없이 영향을 주는 경로로 설명했습니다.

이번에 중요한 변화는 공개 취약점 정보에 실제 공격 관측이 더해졌다는 점입니다. BleepingComputer가 인용한 VulnCheck 허니팟 관측에 따르면 영국 센서에서 주말 동안 최소 50회의 시도가 포착됐고, 9월 1일 기준 누적 시도는 360회로 늘었습니다. 단순한 스캐닝에서 멈추지 않고 Langflow 슈퍼유저 설정, OpenAI API 키, AWS 접근키와 비밀키 형태의 환경변수를 찾으려는 명령이 이어졌습니다. 운영자는 이 CVE를 정기 패치 목록의 한 항목이 아니라 노출 여부와 자격증명 사용 흔적을 함께 점검해야 하는 침해 대응 과제로 다루는 편이 안전합니다.

코드 검증 경계의 취약점

취약점의 중심에는 코드 검증 요청이 있습니다. 정상적인 검증 기능은 제출된 코드를 분석해 오류나 허용 범위를 확인해야 합니다. 그러나 CVE-2026-0768에서는 요청에 포함된 코드 값이 Python 실행 전에 충분히 검증되지 않아 서버 프로세스 권한으로 명령을 수행할 수 있습니다. 공격자는 별도의 사용자 계정을 확보하거나 관리 콘솔에 로그인하는 단계를 생략할 수 있어, 인터넷에서 해당 기능에 접근 가능한 배치가 특히 위험합니다. 이때 웹 화면의 로그인 유무만 보는 점검은 부족합니다. 역방향 프록시, API 게이트웨이, 로드밸런서, 컨테이너 포트가 실제 검증 경로를 외부에 전달하는지까지 확인해야 합니다.

Langflow 공식 보안 문서는 이 제품을 코드 실행 플랫폼으로 규정하고 입력 정제, API 게이트웨이, 네트워크 격리, 프로세스·디스크·데이터베이스 격리를 중요한 통제로 제시합니다. 이 원칙은 이번 취약점의 대응 범위를 결정하는 기준이 됩니다. 외부 접근 차단은 공격 진입점을 줄이고, 인스턴스를 별도 구역에 격리하면 코드 실행 이후 OpenAI나 AWS 같은 후속 자산으로 이어지는 이동 범위를 줄입니다. 따라서 패키지 파일만 교체하고 기존 네트워크 구조와 비밀정보 배치를 유지하는 방식보다 노출 경로와 자격증명 경계를 함께 재설계하는 대응이 필요합니다.

관측된 자격증명 탐색

허니팟에서 관측된 명령은 공격자가 무엇을 우선 수집하려 했는지 보여줍니다. LANGFLOW_SUPERUSER 설정을 조회하고 OPENAI_API 계열과 AWS_ACCESS·AWS_SECRET 계열의 환경변수를 검색했으며, Langflow 캐시 아래의 비밀키 파일도 읽으려 했습니다. 홈 디렉터리의 SSH 관련 경로와 셸 기록 파일 크기를 확인하는 동작도 포함됐습니다. 이는 취약한 프로세스 안에서 끝나는 일회성 코드 실행보다, 인스턴스가 보유한 키를 가져가 외부 API나 클라우드 계정으로 접근 범위를 넓히려는 흐름에 가깝습니다.

환경변수는 컨테이너와 자동화 환경에서 편리하지만, 프로세스가 탈취되면 한 번에 여러 서비스의 비밀정보가 노출될 수 있습니다. Langflow가 OpenAI, AWS, 데이터베이스, 벡터 저장소와 연결돼 있다면 각 키가 허용하는 작업과 대상 리소스를 따로 확인해야 합니다. 같은 키를 개발·검증·운영 환경에서 재사용했거나 장기간 유지했다면 교체 순서를 더 앞당기는 편이 좋습니다. 키 이름만 검색하는 것으로 점검을 끝내지 말고, 실제 발급 주체의 감사 로그에서 호출 시각, 출발 주소, 리전, 사용 API, 실패·성공 패턴을 검토해야 합니다.

노출 여부와 영향 범위 판단

첫 번째 판단 기준은 취약한 기능까지 이어지는 네트워크 경로입니다. 자산 목록에서 Langflow 인스턴스, 컨테이너 이미지, 배포 템플릿, 공개 도메인과 로드밸런서 규칙을 묶어 확인합니다. 인터넷에 직접 공개하지 않았더라도 협력사 VPN, 원격개발 게이트웨이, 사내 공용 프록시를 통해 넓은 사용자 집단이 접근한다면 같은 우선순위로 살펴야 합니다. 서비스가 종료됐더라도 이전 이미지와 스냅샷에 API 키가 남아 있을 수 있으므로 폐기된 환경도 자격증명 조사 범위에 포함하는 것이 좋습니다.

두 번째 기준은 실행과 비밀정보 접근 흔적입니다. 웹·프록시 로그에서 코드 검증 기능으로 향한 비정상 요청, 짧은 시간의 반복 호출, 익숙하지 않은 사용자 에이전트와 출발지를 찾습니다. 컨테이너와 호스트에서는 Langflow 프로세스가 평소 사용하지 않던 셸, 파일 조회, 환경변수 열람, 외부 네트워크 연결을 만들었는지 시간순으로 맞춥니다. OpenAI와 AWS 감사 로그는 같은 시각대의 새 호출원, 권한 오류 급증, 키 사용 지역 변화를 확인하는 데 도움이 됩니다. 여러 기록의 시계를 KST나 UTC 한 기준으로 정규화하면 공격 요청과 후속 키 사용을 연결하기가 쉬워집니다.

우선 대응 순서

1. 외부 프록시와 방화벽에서 Langflow 검증 경로의 인터넷 접근을 먼저 차단하고, 꼭 필요한 관리망과 승인된 운영자만 허용합니다.
2. 의심 요청이나 실행 흔적이 보인 인스턴스는 네트워크에서 격리하되 즉시 삭제하지 않습니다. 메모리·컨테이너·프록시·클라우드 로그의 보존 시점을 확보합니다.
3. 배포 설정, 환경변수, 마운트된 비밀 파일, 서비스 계정 연결을 목록화하고 어떤 키가 Langflow 프로세스에서 읽힐 수 있었는지 구분합니다.
4. 노출 가능성이 높은 Langflow 비밀키와 OpenAI·AWS·데이터베이스 키를 서비스 영향 순서에 맞춰 교체하고 기존 값을 폐기합니다.
5. 공식 보안 지침에 맞춰 인증, API 게이트웨이, 입력 제한, 컨테이너 격리와 외부 통신 정책을 재검증한 뒤 제한된 관리망에서 서비스를 복구합니다.

차단과 키 교체의 순서도 중요합니다. 공격자가 접근을 유지한 상태에서 새 키를 주입하면 새 값까지 다시 노출될 수 있습니다. 먼저 공격 경로를 차단하고 인스턴스를 격리한 다음 증거를 확보하며, 그 뒤에 비밀정보를 교체해야 합니다. 운영 중단을 줄이려면 새 키를 발급한 뒤 소비 시스템을 전환하고, 호출 정상 여부를 확인한 다음 이전 키를 폐기하는 방식으로 진행합니다. 다만 의심스러운 사용이 이어지는 키는 서비스 편의보다 즉시 폐기를 우선해야 합니다.

복구 뒤 검증 범위

복구 검증은 로그인 화면이 다시 열리는지에 그치지 않습니다. 외부에서 검증 기능에 직접 도달할 수 없는지, 승인되지 않은 요청이 API 게이트웨이에서 차단되는지, 컨테이너가 필요한 목적지 이외로 통신하지 못하는지 확인합니다. Langflow 서비스 계정과 연결된 클라우드 역할은 읽기·쓰기·관리 권한을 분리하고, 모델 API 키에는 사용량 경보와 출발지 제한을 적용합니다. 운영팀은 교체한 키가 이전 로그나 이미지 레이어, CI/CD 변수, 백업 파일에 남지 않았는지도 찾아야 합니다.

탐지 기준에는 코드 검증 기능의 비정상 호출량, Langflow 프로세스가 실행한 셸, 비밀 파일과 환경변수 접근, 새 외부 목적지 연결을 포함할 수 있습니다. OpenAI나 AWS 쪽에서는 평소와 다른 사용자 에이전트, 리전, API 조합을 별도 경보로 묶은 편이 유용합니다. 정상 업무와 공격 탐색이 같은 키를 사용하면 구분이 어려우므로 애플리케이션·환경·업무별로 자격증명을 분리해야 합니다. 이번 대응을 마친 뒤에도 며칠간 인증 실패, 비용 변화, 새 인프라 생성, 권한 정책 변경을 집중 모니터링하면 뒤늦게 사용되는 탈취 키를 식별하는 데 도움이 됩니다.

재발 방지를 위한 운영 통제

장기적으로는 Langflow를 일반 협업 도구가 아니라 임의 코드 실행을 허용하는 개발 플랫폼으로 분류하는 것이 중요합니다. 운영 인스턴스와 실험 인스턴스를 분리하고, 새 구성요소 추가가 허용된 환경에는 운영 데이터와 장기 자격증명 연결을 피하는 편이 좋습니다. 외부 연동이 필요하면 서비스별 전용 계정과 짧은 수명의 토큰을 사용하고, 비밀 관리 시스템이 런타임에 필요한 값만 전달하도록 구성합니다. 컨테이너는 읽기 전용 파일시스템, 비특권 사용자, 제한된 볼륨과 외부 통신 정책을 기본값으로 삼을 수 있습니다. 새 배포 전에는 인증 우회 경로, 프록시 예외 규칙, 직접 노출된 포트, 샘플 환경변수를 자동 점검 항목에 넣고, 검증을 통과하지 못한 이미지는 운영 승격을 막습니다. 이렇게 제품 설정과 인프라 경계를 함께 관리해야 비슷한 코드 실행 취약점이 다시 등장했을 때 자격증명 탈취와 후속 클라우드 접근으로 번지는 범위를 줄일 수 있습니다.

정보 확인 기준

이 글은 2026년 9월 2일 14시 KST를 기준으로 Zero Day Initiative의 취약점 분석, Langflow 공식 보안 지침, BleepingComputer가 전달한 VulnCheck 허니팟 관측을 교차 확인해 작성했습니다. 공격 시도 횟수와 탐색 대상은 허니팟 관측 범위에 한정해 해석했으며, 대응 절차는 공개 재현보다 노출 차단·증거 보존·자격증명 교체와 검증에 초점을 맞췄습니다.