n8n 원격코드실행 취약점 CVE-2025-68613 긴급 패치 필수! 완벽 대응 가이드

 

혹시 업무 자동화를 위해 n8n을 사용하고 계신가요? 🤔

최근 n8n에서 CVSS 9.9점이라는 거의 만점에 가까운 치명적인 보안 취약점이 발견되어 전 세계 보안 커뮤니티가 발칵 뒤집혔습니다. 이 취약점을 악용하면 해커가 여러분의 서버를 완전히 장악할 수 있다는 사실, 알고 계셨나요?

특히 연말연시를 노린 공격이 급증하고 있어서 지금 바로 확인하고 조치하지 않으면 큰 피해를 입을 수 있습니다. 😱

오늘은 CVE-2025-68613 취약점이 무엇인지, 왜 이렇게 위험한지, 그리고 어떻게 대응해야 하는지 차근차근 알려드릴게요!

---

📌 n8n이 뭔가요? 왜 많은 기업에서 사용할까?

본격적인 취약점 설명에 앞서 n8n이 무엇인지 간단히 짚고 넘어갈게요.

**n8n(Node for Node)**은 오픈소스 기반의 워크플로우 자동화 플랫폼입니다. 쉽게 말해서 여러 앱과 서비스를 연결해서 반복 업무를 자동화해주는 도구인데요.

n8n의 주요 특징을 살펴보면:

• 노코드/로우코드 방식: 프로그래밍 지식 없이도 드래그 앤 드롭으로 워크플로우 구성 가능
• 300개 이상의 서비스 연동: Slack, Google Sheets, Notion, OpenAI 등 다양한 앱 통합
• 셀프 호스팅 지원: 자체 서버에 설치해서 데이터 보안 유지 가능
• 무료 오픈소스: 비용 부담 없이 강력한 자동화 구현

예를 들어 "매일 아침 9시에 뉴스 기사를 수집해서 AI로 요약한 후 Slack으로 전송"하는 워크플로우를 코딩 없이 만들 수 있어요. 이런 편리함 덕분에 전 세계적으로 npm 주간 다운로드 57,000건 이상을 기록하며, 기업의 업무 자동화에 널리 활용되고 있습니다.

그런데 바로 이 인기 있는 플랫폼에서 심각한 보안 구멍이 발견된 거예요. 😰

---

🚨 CVE-2025-68613 취약점, 도대체 뭐가 문제인가요?

취약점 개요

CVE-2025-68613은 2025년 12월 19일에 공개된 n8n의 원격 코드 실행(RCE, Remote Code Execution) 취약점입니다.

항목 내용

CVE 번호	CVE-2025-68613
CVSS 점수	9.9 / 10.0 (Critical)
취약점 유형	Expression Injection을 통한 원격 코드 실행
발견자	보안 연구원 Fatih Çelik
공개일	2025년 12월 19일
영향받는 버전	0.211.0 이상 ~ 1.120.4, 1.121.1, 1.122.0 미만

왜 이렇게 위험한가요?

n8n은 워크플로우 설정 시 **표현식(Expression)**을 사용해 동적으로 데이터를 처리합니다. 이 표현식은 {{ }} 안에 작성되는데요.

문제는 취약한 버전에서 이 표현식이 충분히 격리되지 않은 환경에서 실행된다는 점입니다. 공격자가 악의적인 JavaScript 코드를 표현식에 삽입하면:

1. Node.js 샌드박스를 탈출하고
2. 시스템 명령어를 실행할 수 있으며
3. n8n 프로세스 권한으로 서버를 장악할 수 있어요

더 무서운 건, 이 공격에는 관리자 권한이 필요 없다는 거예요. 워크플로우를 생성하거나 편집할 수 있는 일반 사용자 계정만 있으면 공격이 가능합니다.

실제 공격 시나리오

공격자가 이 취약점을 악용하면 다음과 같은 일들이 벌어질 수 있습니다:

• API 키, OAuth 토큰, 데이터베이스 비밀번호 등 민감 정보 탈취
• 환경 변수에 저장된 암호화 키와 내부 접근 토큰 유출
• 워크플로우 조작 및 삭제로 업무 마비
• 리버스 쉘 설치로 지속적인 원격 접속 확보
• 연결된 클라우드 서비스, 데이터베이스, CI/CD 시스템으로 측면 이동 공격

n8n은 보통 여러 시스템의 중앙 허브 역할을 하기 때문에, 한 번 뚫리면 연결된 모든 시스템이 위험에 노출됩니다. 🔓

---

📊 현재 상황이 얼마나 심각한가요?

보안 전문 기업 Censys의 조사에 따르면, 2025년 12월 22일 기준으로 전 세계에 103,476개의 취약한 n8n 인스턴스가 인터넷에 노출되어 있습니다.

국가별 분포를 보면 미국, 독일, 프랑스, 브라질, 싱가포르 순으로 많은데요. 한국에서도 셀프 호스팅으로 n8n을 운영하는 기업과 개인이 적지 않기 때문에 결코 남의 일이 아닙니다.

특히 Resecurity 보안 팀의 분석에 따르면, 이 취약점을 노린 공격이 크리스마스 연휴 시즌에 급증했다고 해요. 해커들은 기업의 보안 모니터링이 느슨해지는 연말연시를 노리는 경향이 있거든요.

현재 PoC(Proof of Concept) 익스플로잇 코드가 공개되어 있어서, 기술적 장벽이 낮아진 상태입니다. 즉, 숙련된 해커가 아니어도 공격을 시도할 수 있다는 의미예요. ⚠️

---

🔍 우리 시스템이 취약한지 확인하는 방법

1단계: n8n 버전 확인

먼저 현재 사용 중인 n8n 버전을 확인해야 합니다.

Docker 환경

docker exec -it [컨테이너명] n8n --version

NPM 설치 환경

n8n --version

웹 인터페이스

• n8n 관리자 페이지 → Settings → About 메뉴에서 확인

2단계: 취약 버전인지 판단

다음 버전에 해당하면 즉시 업그레이드가 필요합니다:

• 취약: 0.211.0 이상 ~ 1.120.4 미만
• 취약: 1.121.0 ~ 1.121.0 (1.121.1 미만)
• 취약: 1.122.0 미만

안전한 버전:

• 1.120.4 이상
• 1.121.1 이상
• 1.122.0 이상
• 2.x 버전

3단계: 워크플로우 점검

기존 워크플로우에 악성 코드가 삽입되었는지 확인하려면 다음 패턴을 검색해보세요:

# 워크플로우 파일에서 위험한 패턴 검색
grep -r "this.process" /path/to/n8n/workflows/
grep -r "mainModule.require" /path/to/n8n/workflows/
grep -r "child_process" /path/to/n8n/workflows/
grep -r "binding(" /path/to/n8n/workflows/
grep -r "_load(" /path/to/n8n/workflows/

위 패턴이 발견되면 해당 워크플로우를 즉시 비활성화하고 보안 점검을 진행해야 합니다.

---

🛡️ CVE-2025-68613 완벽 대응 가이드

1. 즉시 패치 적용 (최우선)

가장 확실한 해결책은 최신 버전으로 업그레이드하는 것입니다.

Docker 환경 업그레이드

# 최신 이미지 다운로드
docker pull n8nio/n8n:latest

# 또는 특정 버전 지정
docker pull n8nio/n8n:1.122.0

# 컨테이너 재시작
docker-compose down
docker-compose up -d

NPM 환경 업그레이드

npm install -g n8n@latest

# 또는 특정 버전 지정
npm install -g n8n@1.122.0

권장 업그레이드 버전:

• 1.120.x 사용 중 → 1.120.4 이상
• 1.121.x 사용 중 → 1.121.1 이상
• 신규 설치 또는 전체 업그레이드 → 1.122.0 이상 또는 2.x

n8n 2.x 버전은 추가적인 보안 개선사항과 새로운 기능을 포함하고 있어서, 가능하다면 2.x로 업그레이드하는 것을 권장드려요.

2. 즉시 패치가 어려운 경우 임시 조치

업무 상황 때문에 바로 업그레이드가 어렵다면 다음 임시 조치를 적용하세요:

워크플로우 권한 제한

• 워크플로우 생성/편집 권한을 신뢰할 수 있는 소수의 사용자에게만 부여
• 정기적으로 권한 감사 수행
• 공개 회원가입 기능 비활성화

네트워크 격리

• n8n 인스턴스를 인터넷에서 직접 접근할 수 없도록 설정
• VPN 또는 화이트리스트 기반 IP 접근 제어 적용
• 리버스 프록시를 통한 접근 로깅

최소 권한 원칙 적용

• n8n 프로세스를 root가 아닌 일반 사용자로 실행
• 운영 체제 수준에서 권한 제한
• 불필요한 네트워크 접근 차단

3. 추가 보안 강화 조치

강력한 인증 체계 구축

• 복잡한 비밀번호 정책 적용
• 이중 인증(2FA) 활성화
• 기업 환경에서는 SSO(Single Sign-On) 연동

모니터링 및 탐지

• 프록시 솔루션을 통해 n8n으로 들어오는 요청 로깅
• /rest/workflows URI로 오는 POST 요청 중 의심스러운 패턴 모니터링
• SIEM 솔루션에 n8n 로그 연동

정기적인 보안 점검

• n8n 보안 권고사항 구독
• 스테이징 환경에서 패치 테스트 후 프로덕션 적용
• 분기별 보안 감사 수행

---

💡 실무에서 바로 적용할 수 있는 체크리스트

빠른 대응을 위해 체크리스트를 정리했어요. 하나씩 확인하면서 진행해보세요!

긴급 조치 (24시간 이내)

• [ ] 현재 n8n 버전 확인
• [ ] 취약 버전인 경우 업그레이드 일정 수립
• [ ] 외부 인터넷 노출 여부 확인
• [ ] 워크플로우 편집 권한 보유자 목록 확인

단기 조치 (1주일 이내)

• [ ] 최신 버전으로 업그레이드 완료
• [ ] 기존 워크플로우 악성 패턴 검사
• [ ] 접근 로그 검토로 이상 징후 확인
• [ ] 연결된 서비스의 API 키 로테이션 검토

장기 조치 (1개월 이내)

• [ ] 2FA 또는 SSO 도입
• [ ] 모니터링 및 알림 체계 구축
• [ ] 보안 권고사항 구독 설정
• [ ] 정기 보안 점검 일정 수립

---

🔧 기술 담당자를 위한 심층 분석

조금 더 기술적인 내용이 궁금하신 분들을 위해 취약점의 원인을 설명드릴게요.

취약점 발생 원인

n8n의 표현식 평가 엔진에서 FunctionThisSanitizer가 적용되지 않았던 것이 핵심 원인입니다.

취약한 버전의 동작

// 패치 전: this.process에 접근 가능
(function() { return this.process; })()
// → 실제 Node.js process 객체 반환

패치 후의 동작

// 패치 후: this가 빈 객체로 치환됨
(function() { return this.process; }).call({ process: {} })
// → 빈 객체 반환

또한 PrototypeSanitizer의 블랙리스트가 불완전해서 mainModule, binding, _load 같은 위험한 속성에 접근할 수 있었습니다.

악용 예시

공격자는 워크플로우 표현식에 다음과 같은 코드를 삽입할 수 있었습니다:

{{ (function(){ 
  return this.process.mainModule.require('child_process')
    .execSync('id').toString() 
})() }}

이 코드가 실행되면 서버에서 id 명령이 실행되어 현재 사용자 정보가 반환됩니다. 이를 응용하면 리버스 쉘, 파일 다운로드, 데이터 탈취 등 다양한 공격이 가능해집니다.

---

📝 마무리하며

오늘은 n8n의 치명적인 보안 취약점 CVE-2025-68613에 대해 알아봤습니다.

정리하자면:

• CVSS 9.9점의 초고위험 취약점으로, 서버 완전 장악이 가능
• 전 세계 10만 개 이상의 인스턴스가 영향을 받음
• 즉시 패치 적용이 최선의 대응책
• 패치가 어려우면 권한 제한과 네트워크 격리로 임시 대응