CVE-2025-68613: n8n의 인증된 표현식 인젝션 RCE(CWE-913) - 영향을 받는 대상, 패치 대상 및 억제 방법

CVE-2025-68613의 실제 내용

CVE-2025-68613의 영향 n8n오픈 소스 워크플로 자동화 플랫폼입니다. 이 취약점은 원격 코드 실행(RCE) N8N의 문제 워크플로 표현식 평가 시스템특정 조건에서 다음에서 제공하는 표현식은 인증된 사용자 는 워크플로 구성 중 실행 컨텍스트에서 평가할 수 있습니다. 충분히 격리되지 않음 를 제거합니다. 공격자는 이 동작을 악용하여 n8n 프로세스의 권한으로 임의의 코드를 실행할 수 있으며, 잠재적으로 인스턴스의 전체 손상(데이터 액세스, 워크플로 수정, 시스템 수준 작업)을 초래할 수 있습니다. (NVD)

국가 취약점 데이터베이스(NVD) 항목에 따르면 현재 NVD의 자체 점수 강화는 아직 제공되지 않지만 다음과 같이 표시됩니다. 의 CNA 점수를 표시합니다.: CVSS v3.1 기본 점수 9.9(중요) 벡터 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. (NVD)

이 벡터는 네트워크에 도달할 수 있고, 복잡성이 낮으며, 낮은 권한만 필요하고, 사용자 상호 작용이 없으며, 범위가 변경되어 서비스가 내부 시스템에 연결될 때 '앱 버그'가 '환경 손상'으로 바뀌는 경향이 있다는 점에서 운영상 중요한 문제입니다.

약점 매핑은 다음과 같습니다. CWE-913. MITRE는 CWE-913을 동적으로 관리되는 코드 리소스(변수, 객체, 클래스, 속성, 함수, 실행 명령어/문)에 대한 부적절한 제어로 정의하며, 이는 이 문제의 "표현식 평가가 의도된 격리를 벗어나는" 특성과 일치합니다. (cwe.mitre.org)

보안 권고에 넣을 수 있는 하나의 테이블

'인증 필요'가 여전히 긴급 처리되어야 하는 이유

"인증되었기 때문에 덜 긴급한 문제"로 취급하는 것은 일반적인 실패 모드입니다. n8n에서 인증된 사용자는 단순한 관리자가 아니라 자동화 빌더, 통합 운영자 또는 서비스 계정일 수 있습니다. 표현식 평가 경계가 무너지면 공격자는 애플리케이션 동작에만 국한되지 않고, n8n 프로세스의 권한을 가진 임의 코드 실행과 전체 인스턴스 손상 가능성을 명시적으로 지적합니다. (NVD)

실제로 워크플로 플랫폼은 공격자들이 좋아하는 세 가지 요소, 즉 광범위한 연결성, 비밀, 로직 실행에 집중되어 있습니다. 그렇기 때문에 대응 계획을 "로그인 필요"에 대한 직관보다는 CVSS 벡터(PR:L + S:C + C/I/A:H)에 고정시켜야 합니다. (NVD)

혼란에 빠지지 않는 패치 전략

"올바른" 최종 상태는 간단합니다: 수정된 버전을 실행하세요. NVD는 이 문제를 다음에서 수정된 것으로 나열합니다. 1.120.4, 1.121.1 및 1.122.0. (NVD)

n8n/GitHub 권고 텍스트는 이 문제가 다음에서 수정되었음을 강조합니다. v1.122.0 로 업그레이드할 것을 권장합니다. 1.122.0 이상 "표현식 평가를 제한하는 추가 안전 장치를 도입"하기 때문입니다. (GitHub)

운영적으로 이는 간단한 규칙을 제시합니다:

안전하게 전진할 수 있다면 다음 사항에 집중하세요. 1.122.0+특정 릴리스 트레인에 고정되어 있는 경우, 가능한 한 빨리 전진 이동을 계획하면서 NVD에 표시된 최소 고정 버전에 착륙하세요. (NVD)

다음은 감사 전용 버전 검사기를 CI, 호스트 또는 플릿 작업에서 실행할 수 있습니다(익스플로잇 로직 없이 버전/위험 플래그만 지정):

#!/usr/bin/env bash
# CVE-2025-68613 n8n 버전 감사(익스플로잇 없음)

set -euo pipefail

if 명령 -v n8n >/dev/null 2>&1; then
  VER="$(n8n --version | tr -d 'v' | head -n1)"
else
  VER="${N8N_VERSION:-unknown}"
fi

echo "n8n 버전 감지: $VER"

# GitHub 권고에 따른 영향 범위: >=0.211.0 <1.120.4
# NVD에 따른 고정 버전: 1.120.4, 1.121.1, 1.122.0
if [[ "$VER" != "unknown" ]] && \\.
   [[ "$(printf '%s\\n' "0.211.0" "$VER" | sort -V | head -n1)" == "0.211.0" ]] && \\
   [[ "$(printf '%s\\n' "$VER" "1.120.4" | sort -V | head -n1)" == "$VER" ]] && \\
   [[ "$VER" != "1.120.4" ]]; then
  echo "FLAG: 잠재적으로 CVE-2025-68613의 영향을 받음. NVD/GitHub 지침에 따라 업그레이드하세요."
  2번 출구
fi

echo "이 빠른 검사에서 플래그가 없습니다. 공식 권고 사항 + 정확한 배포 세부 정보와 비교하여 검증하세요."

단기 완화

워크플로 생성/편집 권한을 다음과 같이 제한하는 단기 완화 조치는 NVD와 GitHub 권고 모두 동일하게 제공됩니다. 완전히 신뢰할 수 있는 사용자에 n8n을 배포하고 강화된 환경 영향을 줄이기 위해 OS 권한과 네트워크 액세스를 제한하는 한편, 이러한 완화 조치가 위험을 완전히 제거하지는 못한다고 명시적으로 명시하고 있습니다. (NVD)

이를 적용하려면 "강화된 환경"이 런타임 제어로 변환되어야 합니다. 다음은 익스플로잇 후 활용도를 줄이기 위한 보수적인 컨테이너 강화 스케치입니다(심층 방어):

서비스:
  n8n:
    image: n8nio/n8n:1.122.0
    READ_ONLY: true
    tmpfs:
      - /tmp
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    user: "1000:1000"
    환경:
      - N8N_LOG_LEVEL=info
    # 네트워크 정책/방화벽과 페어링:
    #는 기본적으로 이그레스를 거부하고 필요한 목적지만 허용합니다.

탐지 및 위협 헌팅: 취약한 시그니처를 통한 행동

트리거링 메커니즘은 "불충분하게 격리된 컨텍스트에서 평가된 워크플로 구성 중 표현식"이므로 다음을 중심으로 유용한 탐지 기능을 구축할 수 있습니다. 워크플로우를 편집하는 사람, 얼마나 자주및 이후 런타임이 수행하는 작업. (NVD)

구현의 차이를 극복할 수 있는 실용적인 접근 방식은 상관관계를 파악하는 것입니다:

권한이 낮은 사용자(또는 서비스 계정)에 의한 비정상적인 워크플로 편집 + n8n 런타임에서 의심스러운 프로세스 실행/아웃바운드 연결. 이는 익스플로잇에 성공하면 n8n 프로세스 권한으로 시스템 수준의 작업이 실행될 수 있다는 NVD의 설명과 일치합니다. (NVD)

감사 아이디어 예시(사용자 환경에 맞게 조정):

-a always,exit -F arch=b64 -S execve -F comm=node -k n8n_exec
-a always,exit -F arch=b64 -S connect -F comm=node -k n8n_net

검토해야 할 인접한 영향력이 큰 n8n CVE

조직에서 n8n을 사용하는 경우, CVE-2025-68613을 일회성으로 취급해서는 안 됩니다. 인접한 두 가지 예는 워크플로 플랫폼에서 반복되는 주제, 즉 구성과 실행의 경계를 모호하게 만드는 기능을 보여줍니다.

CVE-2025-65964 는 Git 노드와 관련된 별도의 n8n 이슈입니다: 0.123.1 ~ 1.119.1 버전에는 워크플로 동작이 Git 구성(예: core.hooksPath)에 영향을 미치고 후크 실행을 유발할 수 있는 Git 후크를 통한 RCE를 방지하는 적절한 보호 기능이 부족하다고 설명하며, 이 문제는 다음에서 수정되었습니다. 1.119.2. (NVD)

CVE-2025-57749 은 이전에 n8n의 읽기/쓰기 파일 노드에서 심볼릭 링크 트래버스 취약점이 발견되었습니다. 1.106.0를 사용하면 심볼릭 링크를 통해 디렉터리 제한을 우회하여 제한된 경로에 액세스할 수 있습니다. (NVD)

워크플로 엔진은 '코드 및 시스템 기능'에 위험할 정도로 근접해 있으므로 격리, 노드 수준 가드레일, 엄격한 권한 경계는 선택 사항이 아니라는 교훈은 동일합니다. 동적 코드 리소스가 예기치 않게 영향을 받을 수 있을 때 이러한 문제가 다시 나타나는 이유를 MITRE의 CWE-913 정의에서 확인할 수 있습니다. (cwe.mitre.org)

자산 검색, 버전 검증, 패치 검증, 증거 등급 보고와 같은 엔지니어링 폐쇄 루프가 목표라면 Penligent와 같은 AI 기반 보안 워크플로 플랫폼이 '수정 및 회귀 확인' 단계에 자연스럽게 적합할 수 있습니다. 프로덕션 리스크를 즉시 줄이는 것이 유일한 목표인 경우, 가장 활용도가 높은 조치는 수정된 버전으로 업그레이드하고 가능할 때까지 공급업체의 단기 완화 조치를 적용하는 것입니다. (NVD)

https://nvd.nist.gov/vuln/detail/CVE-2025-68613
https://github.com/n8n-io/n8n/security/advisories/GHSA-v98v-ff95-f3cp
https://cwe.mitre.org/data/definitions/913.html
https://docs.n8n.io/release-notes/
https://nvd.nist.gov/vuln/detail/CVE-2025-65964
https://github.com/n8n-io/n8n/security/advisories/GHSA-wpqc-h9wp-chmq
https://nvd.nist.gov/vuln/detail/CVE-2025-57749