Flowise RCE 취약점 PoC 공개 — LLM 빌더 쓴다면 오늘 확인해야 한다

Flowise를 셀프호스팅으로 운영 중이라면 이 글이 직접적으로 해당된다. PoC(개념 증명 코드)가 공개된 원격 코드 실행 취약점이 보고됐고, 패치하지 않은 인스턴스는 지금 이 순간에도 노출 상태다. 버전 확인부터 API 키 로테이션 경로까지, 오늘 당장 처리해야 할 체크리스트를 정리했다.

---

1. 왜 지금 이걸 봐야 하나

Flowise는 LangChain 기반의 에이전트, RAG 파이프라인, 챗봇을 드래그&드롭으로 조립할 수 있는 오픈소스 도구다. 노코드에 가까운 인터페이스 덕분에 스타트업과 사내 AI 팀 사이에서 빠르게 퍼졌고, 국내에도 사내 프로젝트에 깔려 있는 경우가 꽤 많다.

문제는 이 도구가 대부분 셀프호스팅 환경에서 돌아간다는 점이다. 공식 SaaS가 아니라 사내 VM이나 클라우드 인스턴스에 직접 올려두는 구조라, 패치 타이밍이 전적으로 운영 팀의 손에 달려 있다. "나중에 업데이트하지" 하고 넘긴 순간, PoC가 공개된 오늘부터 공격 코드가 기술 없이 남의 코드를 그대로 쓰는 수준의 공격자에게도 닿는다.

SecurityWeek가 보도한 이번 취약점에는 "원클릭 RCE"라는 수식어가 붙었다. RCE는 Remote Code Execution, 즉 공격자가 인터넷 어딘가에서 요청 하나만 날려도 내 서버에서 임의 코드가 실행된다는 뜻이다. 이론적 위험이 아니라, 실제로 쓸 수 있는 PoC가 이미 공개돼 있다.

Flowise 인스턴스가 같은 네트워크 안의 데이터베이스나 내부 API와 연결돼 있다면, 서버 한 대 탈취가 내부망 전체 침투 경로로 이어진다. 여기에 환경변수로 OpenAI 키, Anthropic 키, Pinecone 키를 들고 있는 경우가 흔한데, 한 번의 RCE로 이 키들이 전부 노출된다.

---

2. 핵심 아이디어

모델 성능이 아니라 파이프라인 실행 환경의 권한 경계가 핵심이다.

LLM 파이프라인 도구는 외부 API를 호출하고, 파일 시스템에 접근하고, 때로는 쉘 명령까지 실행할 수 있는 권한을 가진다. Flowise가 강력한 이유가 곧 공격 표면이 넓은 이유이기도 하다.

아래 표로 위험 수준을 정리하면 이렇다.

운영 환경	위험 수준	이유
퍼블릭 IP + 인증 없음	매우 높음	누구나 접근 가능
퍼블릭 IP + 기본 인증	높음	PoC가 인증 우회 가능성 포함
사내망 + VPN 필요	중간	내부 위협 또는 VPN 탈취 시 노출
패치 완료 + 방화벽 차단	낮음	현재 권고 상태

패치만으로는 부족하다. 환경변수에 적재된 API 키, 인스턴스의 네트워크 노출 범위, 로그에 남은 흔적까지 함께 점검해야 한다.

---

3. 바로 따라하는 방법

단계 1 — 운영 중인 Flowise 버전 확인

# Docker로 실행 중인 경우
docker inspect flowise | grep -i image

# npm으로 설치한 경우
npx flowise --version

# 또는 패키지 직접 확인
cat node_modules/flowise/package.json | grep '"version"'

확인한 버전을 Flowise GitHub 릴리스 페이지(github.com/FlowiseAI/Flowise/releases)와 대조한다. 취약점이 패치된 버전 이상인지 반드시 확인해야 한다. 현재 기준으로 최신 릴리스 노트에서 RCE 관련 보안 패치 항목을 직접 찾아본다.

단계 2 — 인스턴스 네트워크 노출 범위 점검

# 리스닝 포트 확인
ss -tlnp | grep 3000

# 외부에서 접근 가능한지 확인 (본인 서버 IP로 교체)
curl -I http://<SERVER_IP>:3000

# AWS 보안 그룹 확인 (AWS CLI 설치된 경우)
aws ec2 describe-security-groups --group-ids <SG_ID> \
  --query 'SecurityGroups[*].IpPermissions'

포트 3000(또는 커스텀 포트)이 0.0.0.0에 바인딩돼 있고 방화벽 예외가 열려 있다면 즉시 제한해야 한다.

# Nginx로 접근 제한하는 경우 — /etc/nginx/sites-available/flowise
server {
    listen 80;
    server_name your-domain.com;

    location / {
        # 허용할 IP만 명시
        allow 192.168.1.0/24;
        allow 10.0.0.0/8;
        deny all;

        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
    }
}

단계 3 — 환경변수 API 키 목록 파악 및 로테이션 준비

# .env 파일 위치 확인
find /opt/flowise -name ".env" 2>/dev/null
find ~/flowise -name ".env" 2>/dev/null

# 환경변수에서 API 키 관련 항목만 필터링
grep -E "(API_KEY|SECRET|TOKEN|PASSWORD)" .env | \
  sed 's/=.*/=<REDACTED>/'

실제 키 값은 출력하지 말고 어떤 키가 존재하는지 목록만 파악한다. 이후 각 서비스(OpenAI, Anthropic, Pinecone 등) 대시보드에서 키 로테이션 경로를 미리 확인해 둔다. 사고가 나기 전에 로테이션 절차를 익혀두는 것과 그렇지 않은 것의 차이는 크다.

단계 4 — 침해 흔적 확인

# 최근 서버 로그에서 의심스러운 요청 패턴 확인
grep -E "(eval|exec|system|spawn|child_process)" /var/log/nginx/access.log | tail -50

# Flowise 자체 로그 (Docker 기준)
docker logs flowise --since 72h | grep -i error

비정상적인 POST 요청이나 /api/v1/ 엔드포인트에 대한 대량 접근이 있었다면 이미 시도가 있었던 것으로 봐야 한다.

---

4. 운영할 때 조심할 점

인증 설정만으로 안심하지 말 것. PoC가 인증 우회 가능성을 포함하는 경우가 많다. 기본 인증(Basic Auth)이나 단순 API 키 방식은 네트워크 레벨 차단과 병행해야 실질적인 방어가 된다.

환경 분리가 핵심이다. Flowise 인스턴스가 프로덕션 데이터베이스와 같은 서브넷에 있다면 지금 당장 분리를 검토해야 한다. AI 파이프라인 서버는 별도 격리 네트워크에서 돌리고, 필요한 외부 API만 Egress 허용하는 구조가 이상적이다.

Docker 환경에서 권한 최소화:

# docker-compose.yml 보안 설정 예시
services:
  flowise:
    image: flowiseai/flowise
    user: "1001:1001"          # root 금지
    read_only: true            # 파일시스템 쓰기 금지
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    tmpfs:
      - /tmp                   # 임시 파일은 메모리에서만

Mac/Linux/Docker 차이: 로컬 맥북에서만 쓰는 경우는 외부 노출이 없어 위험도가 낮다. 문제는 클라우드 VM이나 NAS에 올려둔 인스턴스다. Cloudflare Tunnel이나 ngrok으로 외부에 열어둔 경우도 동일하게 노출로 봐야 한다.

API 키 로테이션 후 확인:

# 새 키로 교체 후 Flowise 재시작
docker compose down && docker compose up -d

# 헬스체크
curl http://localhost:3000/api/v1/ping

---

자주 묻는 질문

Flowise를 로컬에서만 쓰는데도 패치해야 할까?
로컬 전용이라면 즉각적인 위험은 낮다. 하지만 같은 머신에서 다른 서비스를 운영하거나, 나중에 외부 접근을 열 계획이 있다면 지금 패치해두는 게 낫다. 취약한 버전을 그대로 두면 다른 경로로 들어온 공격자가 Flowise를 횡적 이동에 활용할 수 있다.

패치 적용 전에 반드시 확인해야 할 것은 무엇인가?
버전 업그레이드 전에 현재 플로우 설정을 JSON으로 백업해야 한다. Flowise는 버전 간 데이터 마이그레이션이 자동으로 처리되는 경우가 많지만, 커스텀 노드나 환경변수 구성이 복잡하면 업그레이드 후 동작이 달라질 수 있다. 스테이징 환경에서 먼저 검증하는 것을 권장한다.

침해 여부를 어떻게 검증할 수 있나?
서버 로그에서 /api/v1/ 엔드포인트에 대한 비정상적인 POST 패턴을 확인하는 것이 첫 번째다. 두 번째로 환경변수에 있던 API 키들의 사용 이력을 각 서비스 대시보드에서 확인한다. OpenAI 사용량이 갑자기 급증했거나 모르는 IP에서 API 호출이 있었다면 침해를 의심해야 한다. 확신이 없다면 키를 전부 로테이션하고 서버를 새로 띄우는 것이 가장 안전하다.

---

마무리

패치 버전 확인, 네트워크 노출 차단, API 키 로테이션 준비 — 이 세 가지를 오늘 안에 처리하면 현재 알려진 공격 벡터는 대부분 막힌다. AI 파이프라인 도구는 강력할수록 공격 표면도 넓다는 사실을 운영 정책에 반영해야 할 시점이다.

다음 글에서는 Flowise처럼 셀프호스팅 AI 도구를 안전하게 운영하기 위한 네트워크 격리 구성과 시크릿 관리 패턴을 다룰 예정이다.

---

🐦 X에서 더 빠르게: @baegseungh7061
📚 이 시리즈 더 보기: AI 인사이트
💌 새 글 알림: X 팔로우 또는 블로그 RSS 구독