주소창의 ID 한 글자를 바꿨더니 남의 워크플로가 열렸다 — Langflow 권한 우회(CVE-2026-55255)를 방어자 시선으로

이미지 출처: CISA KEV

사내에서 Langflow로 LLM 파이프라인을 굴리는 팀을 상상해 보자. 마케팅 담당자 계정으로 로그인해 자기 흐름도(flow)를 여는데, 브라우저 주소창이나 요청 본문에 붙은 식별자(ID) 값이 순차적인 숫자거나 추측하기 쉬운 문자열이더라. 그 값을 옆자리 동료의 것으로 슬쩍 바꿔 요청을 보냈더니, 서버가 "이건 당신 게 아닌데요"라고 막지 않고 그대로 남의 워크플로를, 심지어 그 안에 박아둔 API 키까지 내어준다면? CVE-2026-55255는 바로 이 지점, 사용자가 마음대로 바꿀 수 있는 키(user-controlled key)를 서버가 그대로 믿어버리는 인가(authorization) 결함을 다룬다.

핵심 요약

• Langflow에서 요청에 담긴 리소스 식별자를 소유권 검증 없이 신뢰해, 남의 흐름도·자격증명에 접근할 수 있는 권한 우회 결함임.
• 인증(로그인)은 통과했지만 인가(이 리소스가 네 것이냐)를 빠뜨린 전형적 IDOR/BOLA 패턴으로 봄.
• 방어는 화려한 탐지보다 서버측 소유권 검증·최소권한·이상 접근 로깅이라는 기본기가 핵심임.

무엇이 문제인가 — '로그인'과 '권한'은 다른 일이다

많은 서비스가 로그인만 통과하면 안심한다. 하지만 인증은 "네가 누구냐"를 확인하는 단계고, 인가는 "그래서 이 자원에 손댈 자격이 있냐"를 따지는 단계다. 둘은 완전히 다른 검문소다.

• 사용자 제어 키 문제는 인가 검문소를 통째로 비워 둔 상황임. 요청에 담긴 flow_id·object_id 같은 값을 서버가 "이 값을 보낸 사람이 곧 주인"이라고 지레짐작함.
• 이 값이 1, 2, 3처럼 순차적이거나 규칙이 보이면 공격자는 자기 것 근처의 값을 훑어 남의 자원을 열거(enumeration)함.
• 보안 용어로는 IDOR(Insecure Direct Object Reference), API 맥락에선 BOLA(Broken Object Level Authorization)라 부르는 결이고, 접근제어 실패의 오랜 단골임.

왜 Langflow에서 특히 뼈아픈가

Langflow는 노드를 이어 붙여 LLM 에이전트와 파이프라인을 만드는 도구다. 그 흐름도 안에는 겉보기보다 민감한 것들이 잔뜩 들어 있다.

• OpenAI·Anthropic 같은 외부 LLM API 키와 각종 커넥터 자격증명이 흐름 구성에 함께 저장되는 경우가 많음. 남의 흐름을 읽는 순간 그 키까지 새는 셈임.
• 프롬프트·시스템 지시·내부 문서 참조 등 영업기밀에 가까운 로직이 그대로 노출됨.
• 편집 권한까지 우회되면 흐름 자체를 변조해, 조용히 데이터를 외부로 빼돌리는 백도어 노드를 심을 여지도 생김. 단순 열람을 넘어 무결성 훼손으로 번질 수 있음.

즉 이건 "글 하나 잘못 보인" 수준이 아니라, 자격증명 유출과 파이프라인 변조로 이어질 수 있는 문제라 가볍게 넘기기 어렵다.

방어자라면 어떻게 탐지하나

공격을 재현하려 들 필요는 없다. 중요한 건 이 결함이 남기는 '흔적'을 아는 것이다. 접근제어 우회는 로그에서 특유의 패턴을 남긴다.

• 식별자 열거 흐름 관찰: 한 계정(또는 한 토큰)이 짧은 시간에 여러 리소스 ID를 순차적·연속적으로 조회하는 요청은 강한 신호임. 정상 사용자는 보통 자기 것만, 띄엄띄엄 접근함.
• 소유자 불일치 로깅: 요청한 리소스의 실제 소유자와 요청 주체가 다른데 응답이 성공(2xx)으로 나간 기록을 별도로 남기고 알림을 걸어 둠. 이 한 줄이 사후 추적의 핵심임.
• 403 대신 200: 남의 자원 접근 시도가 마땅히 403/404여야 하는데 200이 반복된다면 인가 로직이 비어 있다는 방증임. WAF·API 게이트웨이 로그에서 상태코드 분포를 지표로 삼음.
• 인증은 유효한데 이상한 대상: 토큰은 정상인데 접근 대상만 계속 바뀌는 트래픽을 UEBA/행위 기반으로 잡으면, 탈취가 아니라 권한 우회 쪽임을 구분할 수 있음.

완화 — 결국 기본기 싸움이다

• 가장 먼저 최신 버전으로 갱신: 공식 패치가 나온 릴리스로 올리는 게 1순위임. 인터넷에 그대로 노출된 Langflow 인스턴스라면 특히 서둘러야 함.
• 서버측 소유권 검증 강제: 모든 리소스 접근에서 "이 자원의 주인이 요청자와 같은가"를 서버가 매번 확인하도록 함. 클라이언트가 보낸 ID를 신뢰의 근거로 삼지 않음.
• 추측 불가능한 식별자: 순차 숫자 대신 UUID처럼 열거가 어려운 값을 쓰면 자동 훑기 공격의 비용을 크게 올림. 다만 이건 보조 방어일 뿐, 인가 검증을 대체하진 못함.
• 노출 면적 줄이기: Langflow를 공개 인터넷에 열어두지 말고 VPN·리버스 프록시 뒤, 인증 게이트웨이 안쪽에 두는 게 안전함. 자격증명은 흐름에 평문으로 박지 말고 비밀 관리(secret) 기능으로 분리함.
• 최소권한과 키 회전: 흐름에 물린 LLM·외부 API 키는 필요한 범위로만 발급하고, 노출이 의심되면 즉시 회전함. 이미 유출됐다는 가정 아래 움직이는 게 현명함.

이런 권한 우회는 화려한 제로데이라기보다, 개발할 때 흔히 빠뜨리는 검문 한 곳에서 비롯되는 경우가 많다. 그래서 오히려 방어자에게는 승산이 있다. 오늘 당장 우리 Langflow가 인터넷에 열려 있는지, 흐름 안에 API 키가 평문으로 들어가 있는지, 로그에 소유자 불일치를 남기고 있는지부터 점검해 보길 개인적으로 추천한다. 점검하다 막히는 부분이나 우리 환경에선 이렇게 걸러냈다는 경험이 있다면 댓글로 나눠 주면 좋겠다. 같이 하나씩 잠가 보아요.