n8n 2.13.0 / 2.12.3 stable 기준
IT/AI
n8n 3월 업데이트 직접 봤습니다 — 기능보다 보안이 먼저였습니다
3월 업데이트라는 말에 “멀티 에이전트 통합이겠지”라고 생각했는데, 공식 릴리즈노트를 실제로 열어보니 순서가 달랐습니다. 1월에 39,000개 이상의 인스턴스를 덮쳤던 취약점 사태 이후, n8n의 3월 집중 포인트는 보안 인프라 재건이었습니다.
(2026.01.27 기준)
심각도 점수
(v2.10.0 기준)
3월에 가장 먼저 들어온 건 새 기능이 아닙니다
n8n 3월 업데이트라고 하면 대부분 “멀티 에이전트 채팅 통합”이나 “MCP 연동 확장” 쪽을 떠올립니다. 실제로 커뮤니티에서도 그 이야기가 가장 많이 돌았습니다. 그런데 공식 GitHub 릴리즈 노트를 직접 열어서 2.13.0 커밋 목록을 훑으면 이야기가 달라집니다. 가장 먼저 눈에 들어오는 건 SSRF 보호 설정 추가와 SSRF 보호를 요청 헬퍼 전체에 통합이라는 두 개의 커밋입니다.
우연이 아닙니다. 2026년 1월, JFrog 보안 연구팀이 n8n에서 CVSS 9.9짜리 원격 코드 실행(RCE) 취약점(CVE-2026-1470)과 CVSS 8.5짜리 Python 샌드박스 탈출 취약점(CVE-2026-0863)을 공개했습니다. (출처: The Hacker News, 2026.01.28) 그 이전인 1월 초에는 CVSS 10.0 만점을 받은 CVE-2026-21858, 일명 “Ni8mare” 취약점도 터졌습니다. 공격자가 인증 없이 n8n 인스턴스 전체를 장악할 수 있는 구조였습니다.
Shadowserver Foundation 데이터 기준, 1월 27일 시점에 이 취약점에 노출된 인스턴스가 전 세계에 39,000개를 넘었습니다. (출처: Shadowserver Foundation 대시보드) 셀프호스팅으로 n8n을 돌리고 있다면, 3월 업데이트가 단순한 기능 추가가 아니라 보안 부채 청산 작업이라는 사실을 먼저 알아야 합니다.
JFrog 보안 연구 책임자 Shachar Menashe는 “CVE-2026-1470는 인증된 사용자라면 누구든 n8n 인스턴스 전체를 장악할 수 있어 위험도가 더 높다”고 직접 밝혔습니다.
SSRF 보호가 2.13.0에 들어온 이유
💡 공식 GitHub 커밋 히스토리와 보안 사고 일정을 같이 놓고 보면 이 타이밍이 왜 나왔는지 보입니다.
SSRF(Server-Side Request Forgery)는 공격자가 서버를 통해 내부 네트워크로 요청을 보내는 공격입니다. n8n처럼 HTTP Request 노드를 자유롭게 설정할 수 있는 자동화 플랫폼은 구조상 SSRF 공격 경로가 넓습니다. 워크플로우 안에서 외부 URL로 요청을 보내는 로직만으로도 내부 AWS 메타데이터 서버(169.254.169.254)나 내부 DB에 접근하는 경로가 될 수 있기 때문입니다.
2.13.0에서 추가된 내용은 두 가지입니다. 하나는 SSRF 보호 설정 구성(#26424)이고, 다른 하나는 이 설정을 n8n 내부 요청 헬퍼 전체에 통합(#26581)한 것입니다. (출처: n8n GitHub Releases, 2026.03.16) 설정으로만 놔두는 게 아니라, 요청이 발생하는 모든 경로에 보호 로직을 끼워 넣었다는 의미입니다. HTTP Request 노드가 내부 IP 범위로 향하는 요청을 막게 됩니다.
동시에 차단된 IP에 대해 에러 메시지도 개선됐습니다(#26837). 이전에는 요청이 막혔을 때 원인을 알기 어려웠는데, 이제는 “SSRF 보호로 차단됨”이라는 메시지가 명확히 나옵니다. 셀프호스팅 환경에서 방화벽 없이 n8n을 돌리는 경우라면, 지금 버전이 2.12.x 이하라면 업데이트를 먼저 챙겨야 합니다.
| 취약점 | CVSS 점수 | 패치 버전 | 설명 |
|---|---|---|---|
| CVE-2026-21858 (Ni8mare) | 10.0 | 2.4.5 이상 | 인증 없이 RCE 가능 |
| CVE-2026-1470 | 9.9 | 2.5.1 이상 | JS 샌드박스 탈출 → RCE |
| CVE-2026-0863 | 8.5 | 2.4.2 이상 | Python 샌드박스 탈출 |
| SSRF 공격 경로 | — | 2.13.0 이상 | 내부 IP 요청 차단 추가 |
출처: JFrog Security Research / The Hacker News (2026.01.28) / n8n 공식 GitHub Releases
MCP가 워크플로우를 직접 제어할 수 있게 됐습니다
💡 2.13.0 커밋에서 MCP 관련 항목만 모아보면, AI가 n8n 내부 구조를 조작하는 범위가 이번 달에 꽤 넓어졌습니다.
이번 2.13.0에서 MCP 관련 변경이 세 가지 들어왔습니다. 첫째는 워크플로우 발행(publish)과 발행 취소(unpublish) 기능을 MCP 도구로 추가한 것(#26681)입니다. 이전까지는 MCP를 통해 워크플로우를 읽고 실행하는 건 됐는데, 활성화/비활성화는 n8n UI에서 직접 해야 했습니다. (출처: n8n GitHub Releases 2.13.0, 2026.03.16)
둘째는 전체 실행 데이터를 가져오는 전용 MCP 도구가 생겼습니다(#26674). 이전에는 실행 요약 정보만 MCP로 조회할 수 있었는데, 이제는 실행 중에 각 노드가 처리한 전체 데이터를 AI가 읽을 수 있습니다. 셋째는 AI 빌더에 외부 문서를 가져오는 web-fetch 도구가 추가됐습니다(#26630). 워크플로우를 만들 때 API 문서 URL을 넣으면 AI 빌더가 직접 읽고 참고합니다.
솔직히 말하면, 이 세 가지 변화를 합치면 “AI가 n8n을 관리 도구처럼 쓸 수 있게 됐다”는 뜻입니다. Claude Code나 Cursor 같은 AI 코딩 도구에서 MCP로 n8n에 붙으면, 워크플로우를 만들고, 실행하고, 결과를 확인하고, 발행까지 AI가 혼자 처리할 수 있는 구조가 됩니다.
Chat Hub “무료”라더니, 역할 분리는 유료입니다
n8n이 Chat Hub를 공개하면서 “모든 요금제에서 이용 가능”이라고 발표했습니다. Community Edition 포함이라고요. 이게 사실이긴 합니다. 그런데 막상 쓰다 보면 걸리는 부분이 있습니다. Chat Hub에서 가장 핵심적인 기능인 Chat 사용자 역할 분리는 Pro, Business, Enterprise 플랜에서만 됩니다. (출처: n8n 공식 블로그 “Introducing Chat Hub”, 2026.01.28)
Chat Hub의 설계 철학은 “Builder(기술 사용자)가 워크플로우를 만들고, Chat 사용자(비기술 사용자)가 채팅으로 실행한다”는 역할 분리입니다. 근데 이 역할 분리 자체가 유료 기능입니다. Community나 Starter 플랜이라면, Chat Hub를 열어도 모든 사용자가 동일한 권한으로 접근합니다. 비기술 사용자에게 Chat Hub를 노출했다가 워크플로우를 실수로 편집하는 상황이 생길 수 있습니다.
Chat Hub가 “Shadow AI 문제를 해결한다”고 포지셔닝하는데, Shadow AI를 제대로 통제하려면 역할 관리가 핵심입니다. 그 핵심이 유료 플랜 전용이라는 점은 꼭 짚고 넘어가야 합니다. 무료로 써보는 건 좋지만, 팀 전체에 배포하려면 플랜 업그레이드 비용을 먼저 계산해봐야 합니다.
1Password 연동이 SSRF와 같은 릴리즈에 나온 이유
💡 두 기능이 같은 릴리즈에 묶인 건 우연이 아닙니다. GitHub 커밋 날짜를 보면 보안 로드맵이 읽힙니다.
2.13.0에서 1Password external secrets 프로바이더 지원이 추가됐습니다(#26307). n8n은 이미 AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, GCP Secrets Manager를 지원하고 있었는데, 여기에 1Password Connect Server 연동이 추가된 겁니다. (출처: n8n 공식 문서 External Secrets)
기능 자체는 단순해 보이는데, 타이밍이 중요합니다. 이번 취약점 사태에서 JFrog 연구팀이 지적한 핵심은 이겁니다. “n8n이 조직 전체의 LLM API, 영업 데이터, 내부 IAM 시스템의 키를 쥐고 있기 때문에, 탈취 시 사실상 회사 전체의 마스터키가 된다.” (출처: JFrog Security Research 성명, The Hacker News 2026.01.28) n8n 데이터베이스에 크레덴셜이 직접 저장된 구조라면, n8n 인스턴스 하나가 뚫리면 연결된 모든 서비스가 뚫립니다.
1Password 연동은 크레덴셜을 n8n DB 밖으로 꺼내 외부 보안 볼트에서 관리하도록 하는 접근입니다. SSRF 보호로 요청 경로를 막고, External Secrets로 크레덴셜 보관 위치를 분리하는 두 작업이 같은 릴리즈에 들어온 건 우연이 아닌 설계입니다. 셀프호스팅 환경에서 크리티컬한 API 키를 n8n DB에 직접 넣고 있다면, 이 기능 도입을 검토할 타이밍입니다.
지금 stable 버전은 2.12.3이고, 2.13.0은 beta입니다
인스타그램 릴 영상이나 YouTube Shorts에서 “n8n 3월 대규모 업데이트”라고 소개된 내용 대부분이 2.13.0 기반입니다. 2.13.0은 2026년 3월 16일에 나왔고, 이 시점에서 공식 분류는 beta(pre-release)입니다. 현재 stable 버전은 2.12.3으로, 2026년 3월 18일에 나온 버전입니다. (출처: n8n 공식 릴리즈노트, docs.n8n.io)
이게 왜 중요하냐면, n8n Cloud를 쓰는 경우와 self-hosted를 쓰는 경우 업데이트 시점이 다릅니다. Cloud는 n8n이 관리하기 때문에 stable을 기준으로 자동 업데이트되지만, self-hosted는 직접 버전을 지정해서 올려야 합니다. 그리고 n8n 공식 문서는 production 환경에서 beta 버전 사용을 권장하지 않습니다. 2.13.0의 SSRF 보호 기능을 빨리 쓰고 싶다면 2.13.x가 stable로 승격될 때까지 기다리거나, 별도 스테이징 환경에서 먼저 테스트하는 게 맞습니다.
참고로 2.10.0에서 워크플로우 및 크레덴셜 목록 페이지 로딩 속도가 대규모 인스턴스 기준 30~80% 개선됐습니다. (출처: n8n 공식 릴리즈노트 2.10.0) 이 부분은 stable 버전에 이미 들어가 있어서, 지금 당장 체감할 수 있는 변화입니다.
Q&A 5가지
Q1. n8n을 Cloud로 쓰고 있는데 이 업데이트를 따로 적용해야 하나요?
Cloud 플랜은 n8n이 직접 버전 관리를 합니다. stable 버전 기준으로 자동 적용되기 때문에 별도 조치 없이도 보안 패치가 반영됩니다. 다만 2.13.0의 신규 기능(SSRF 보호 설정, 1Password 연동 등)은 stable로 승격된 이후에 Cloud에서 이용 가능합니다.
Q2. SSRF 보호가 켜지면 기존 워크플로우가 깨질 수 있나요?
가능성이 있습니다. HTTP Request 노드에서 내부 IP(예: 192.168.x.x, 10.x.x.x, 172.16~31.x.x, 127.0.0.1, 169.254.169.254)로 향하는 요청이 있다면 차단됩니다. 내부 서비스를 호출하는 워크플로우가 있다면 업데이트 전에 꼭 점검이 필요합니다. 설정으로 제어 가능한 부분이 있는지는 공식 문서에서 별도 이유를 밝히지 않은 부분도 있어, 업데이트 후 테스트를 권장합니다.
Q3. 1Password 연동은 Enterprise 전용인가요?
External Secrets(외부 비밀 관리) 기능 자체가 n8n Enterprise 플랜 전용입니다. (출처: n8n 공식 문서 External Secrets) Community 또는 Starter 플랜에서는 1Password 연동을 사용할 수 없습니다. 크레덴셜을 n8n DB 밖에서 관리하고 싶다면 플랜 확인이 먼저입니다.
Q4. MCP로 n8n 워크플로우를 AI가 발행한다는 게 실제로 어떻게 쓰이나요?
Claude Code나 Cursor처럼 MCP를 지원하는 AI 도구에서 n8n MCP 서버에 연결하면, AI가 워크플로우 목록 조회 → 실행 → 실행 결과 조회 → 발행/취소까지 자연어 명령으로 처리할 수 있습니다. 예를 들어 “이 워크플로우 테스트 돌리고 결과 확인한 다음 배포해줘”라고 했을 때 AI가 단계별로 처리하는 구조입니다. 단, 이 기능이 제대로 작동하는 환경과 조건은 MCP 서버 설정에 따라 달라집니다.
Q5. 지금 self-hosted로 v2.x 이하 버전을 쓰고 있는데, 업데이트가 급한가요?
CVE-2026-21858(Ni8mare, CVSS 10.0) 패치는 2.4.5, CVE-2026-1470(CVSS 9.9) 패치는 2.5.1에 들어갔습니다. (출처: JFrog Security Research / The Hacker News 2026.01.28) 2.4.5 미만 버전이라면 인증 없이 원격 코드 실행이 가능한 상태입니다. 이 부분은 기능 업데이트보다 훨씬 급합니다. 지금 당장 현재 버전을 확인하고, 최소 2.5.1 이상으로 올리는 게 먼저입니다.
마치며
n8n 3월 업데이트를 “멀티 에이전트 채팅 통합”으로 요약한 글이 많은데, 실제 릴리즈노트를 직접 확인해보면 무게중심이 다릅니다. 1월에 CVSS 10.0 취약점으로 39,000개 인스턴스가 노출됐던 사건 이후, 3월 릴리즈는 기능 추가보다 보안 인프라 복구에 훨씬 많은 커밋이 들어갔습니다.
MCP 확장은 분명 방향성이 좋습니다. AI가 n8n 내부를 조작하는 범위가 넓어지면 자동화 자체의 가능성도 커집니다. 그런데 그 강력함이 보안 구멍과 함께 있으면 위험도가 배가됩니다. Chat Hub의 역할 분리 조건, External Secrets의 플랜 제한, stable과 beta 버전 구분 — 이 부분들을 모르고 쓰다 보면 생각지 못한 곳에서 막힙니다.
self-hosted로 n8n을 쓰고 있다면, 지금 당장 버전 확인부터 해보는 게 가장 실용적인 시작입니다. 2.4.5 미만이라면 기능 얘기는 나중에 하는 게 맞습니다.
📌 본 포스팅 참고 자료
- n8n 공식 릴리즈노트 — https://docs.n8n.io/release-notes/
- n8n GitHub Releases (2.13.0 상세 커밋) — https://github.com/n8n-io/n8n/releases/tag/n8n@2.13.0
- The Hacker News — Two High-Severity n8n Flaws (JFrog Research, 2026.01.28) — https://thehackernews.com/2026/01/two-high-severity-n8n-flaws-allow.html
- n8n 공식 블로그 — Introducing Chat Hub (2026.01.28) — https://blog.n8n.io/introducing-chat-hub/
- n8n 공식 문서 — External Secrets — https://docs.n8n.io/external-secrets/
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 본문 내 모든 버전 정보와 수치는 2026년 3월 23일 기준으로 작성됐습니다.
댓글 남기기