[CVE] CVE-2026-55255

주의: 이 글은 AI 자동 작성되었습니다. 반드시 재검증해야 합니다. 내용의 오류가 있을 경우 댓글 작성 부탁드립니다.

핵심 요약

CVE-2026-55255는 Langflow의 /api/v1/responses 엔드포인트에서 발생하는 IDOR(Insecure Direct Object Reference) 취약점입니다. 인증된 공격자가 다른 사용자의 flow ID를 요청에 지정하면, 해당 victim의 flow를 실행할 수 있습니다.

핵심은 “권한이 있는 사용자”라는 전제 아래에서도, 서버가 객체 소유권을 충분히 검증하지 못해 다른 사용자의 자원에 접근·실행이 가능해진다는 점입니다. 이 취약점은 CVSS 3.1 기준 9.9점, CRITICAL로 평가되었습니다.

공개된 설명 기준으로는 1.9.2에서 수정되었으며, 공개 익스플로잇 신호는 확인되지 않았습니다.

기술 배경

IDOR는 공격자가 직접 식별 가능한 객체 식별자, 예를 들어 flow ID, user ID, response ID 같은 값을 바꿔치기하면서 원래는 접근할 수 없어야 하는 객체를 조작하는 취약점입니다. 서버가 “요청자가 인증되었는가”만 확인하고, “이 객체가 이 사용자에게 속하는가”까지 확인하지 않으면 발생하기 쉽습니다.

이번 사례에서는 /api/v1/responses 엔드포인트가 문제 지점입니다. 설명에 따르면 인증된 공격자는 요청에 피해자의 flow ID를 넣는 방식으로 다른 사용자의 flow를 실행할 수 있었습니다. 즉, 단순 조회 수준이 아니라 실행 경로에 연결되어 있어 영향이 더 큽니다. 공격자가 의도한 flow를 직접 선택해 동작시키는 구조라면, 내부 자동화나 AI 워크플로우의 맥락상 데이터 유출과 비정상 동작 유발 가능성이 함께 열립니다.

CVSS 벡터는 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L입니다. 네트워크를 통해 원격에서 가능하고, 난이도는 낮으며, 낮은 권한의 인증 계정만 있으면 된다는 점이 눈에 띕니다. 범위 변경(S:C)도 포함되어 있어, 단일 컴포넌트 내부 문제를 넘어 다른 보안 경계에 파급될 수 있음을 시사합니다.

공격자 관점에서 볼 부분

공격자 입장에서는 이 취약점이 “인증 우회”가 아니라 “권한 상승형 객체 탈취”에 가깝다는 점이 중요합니다. 즉, 계정을 새로 뚫기보다 정상 계정 하나만 확보하면 공격을 전개할 수 있습니다.

관찰 포인트는 다음과 같습니다.

요청에서 flow ID가 직접 사용되는지 서버가 해당 flow의 소유권을 세션 사용자 기준으로 재검증하는지 실행 API가 다른 사용자 소유의 객체를 참조했을 때 거부하는지 response 생성과 flow 실행이 동일한 권한 모델을 공유하는지

이런 유형은 종종 멀티테넌트 환경에서 더 위험해집니다. 같은 인스턴스 안에 여러 사용자의 flow가 공존하면, 한 사용자의 인증 세션이 다른 사용자의 자동화 로직을 건드릴 수 있기 때문입니다. 특히 AI 워크플로우는 외부 연동, 비밀 정보, 내부 데이터 소스와 연결되는 경우가 많아, 실행 자체가 곧 정보 노출로 이어질 수 있습니다.

또한 공격자는 단발성 실행뿐 아니라, 반복적으로 다른 사용자 flow를 호출하며 어떤 객체가 어떤 반응을 보이는지 탐색할 가능성도 있습니다. IDOR의 전형적인 위험은 “보여주지 말아야 할 객체를 보여줌”인데, 여기서는 “보여주지 말아야 할 객체를 실행함”으로 확장된 점이 더 민감합니다.

영향 범위

공개된 설명 기준으로 영향받는 제품은 Langflow이며, 1.9.2 이전 버전에서 취약점이 존재합니다. 그 외 세부 영향 버전은 확인 필요입니다.

영향은 다음과 같이 정리할 수 있습니다.

인증된 공격자가 타 사용자 소유 flow를 실행 가능 사용자 간 데이터 경계가 무너질 가능성 flow 내부에 포함된 민감한 연결 정보, 외부 API 호출, 내부 데이터 접근 로직이 간접적으로 노출될 가능성 실행 결과나 부작용을 통해 정보 유출 또는 비정상 상태 유발 가능성

다만 실제로 어떤 데이터가 노출되는지, 어떤 종류의 부작용이 가능한지는 각 flow 구성에 따라 달라집니다. 따라서 영향도는 “해당 인스턴스에서 어떤 flow가 존재하는가”에 크게 의존합니다.

대응 및 패치

공개 설명에 따르면 이 취약점은 Langflow 1.9.2에서 수정되었습니다. 가장 직접적인 대응은 영향을 받는 환경을 1.9.2 이상으로 업데이트하는 것입니다.

추가로, 운영 관점에서는 인증만으로 객체 접근을 허용하는 API가 있는지 점검하고, 요청자의 권한과 객체 소유권을 서버 측에서 강하게 검증하는 구조로 정비해야 합니다. 특히 flow ID처럼 직접 참조되는 식별자는 접근 제어의 핵심이 되므로, 단순 존재 확인이 아니라 “이 사용자가 이 객체를 실행할 수 있는가”까지 확인해야 합니다.

메모