원문: arXiv 2609.33413v1 · 저자: Eilon Cohen, Ariel Fogel · 소속: Pillar Security · 공개: 2026년 9월 27일
Tags: AI Security, Workflow Security, n8n, Expression Sandbox, Trust Boundary
본 글은 원 논문의 주요 기술적 내용을 이해하기 쉽게 요약·정리한 글입니다. 자세한 내용은 상단의 원문 링크를 참고하세요.
한눈에 보기
이 논문은 AI 워크플로 플랫폼의 표현식 평가기를 연구한 n8n 사례 분석입니다. 핵심은 모델이 위험한 문장을 생성한다는 문제가 아니라, 외부 데이터와 사용자가 작성한 표현식을 처리하는 소프트웨어가 서버 실행 환경과 자격 증명 저장소를 충분히 분리하지 못했다는 점입니다.
저자는 AST 변환에서 검사되지 않는 문맥과 데이터의 재평가를 통해 신뢰 경계가 무너지는 사례를 제시합니다. 다만 인증된 워크플로 작성자의 샌드박스 탈출과 특정 공개 폼 설정에서 발생하는 비인증 표현식 주입은 서로 다른 전제를 가지며, 후자만으로 서버 코드 실행이 자동으로 성립하지는 않습니다.
실무에서는 개별 문법 차단 목록의 확대보다 알 수 없는 입력을 거부하는 허용 목록, 데이터와 코드의 분리, 표현식 실행 환경과 비밀 정보의 격리를 우선 검토할 가치가 있습니다. 이 문서는 공개 취약점의 방어적 분석을 다루며, 실행 가능한 페이로드나 침해 절차는 제공하지 않습니다.
연구 배경
워크플로 플랫폼은 여러 서비스의 인증 정보를 보관하면서 사용자에게 데이터 변환 기능을 제공합니다. 표현식 엔진이 같은 서버 프로세스의 넓은 실행 능력을 상속하면, 작은 언어 기능의 검증 오류도 여러 연결 서비스의 비밀 정보에 영향을 줄 수 있습니다.
논문은 이런 조합을 weird machine 관점으로 설명합니다. 의도된 기능의 개별 안전성만으로 전체 시스템의 안전성이 보장되지 않으며, 평가기·템플릿 처리·자격 증명 저장소를 연결하는 경계 자체를 분석해야 한다는 주장입니다.
공격 모델 / 전제 조건
첫 번째 모델은 인증된 사용자가 워크플로를 만들거나 편집할 수 있는 경우입니다. 관리자 권한이 반드시 필요한 것은 아니지만, 관련 기능을 사용할 권한과 취약한 표현식 평가 경로에 도달할 수 있는 제품 버전이 필요합니다. 공식 권고의 두 샌드박스 탈출 취약점도 이 권한 조건을 명시합니다.
두 번째 모델은 외부 사용자가 공개 폼에 입력을 제출하는 경우입니다. 모든 공개 폼이 취약한 것은 아니며, 입력을 다시 표현식으로 처리하는 특정 워크플로 구성이 필요합니다. 피해자의 별도 클릭보다는 운영자가 이미 구성한 데이터 처리 경로가 중요합니다.
폼 입력에서 평가 문맥으로 넘어가는 경계와 평가 문맥에서 호스트 런타임으로 넘어가는 경계는 구분해야 합니다. 서버 코드 실행의 전체 영향을 주장하려면 두 경계를 모두 넘는 연결이 입증되어야 하며, 단순 문자열 반영이나 표현식 계산 결과만으로 이를 대신할 수 없습니다.
비판적 검토 / 아쉬운 점
가장 큰 쟁점은 사례의 범위를 일반적인 불가능성 주장으로 확장하는 부분입니다. n8n의 반복된 패치 우회는 해당 구현의 취약성을 보여주지만, 모든 AST 기반 제한 언어가 본질적으로 안전해질 수 없다는 증명은 아닙니다. 저자가 권하는 최소 허용 목록 역시 문법 구조를 검증할 수 있으므로, 허용하는 언어와 위험한 실행 능력의 경계를 명확히 정의한 추가 분석이 필요합니다.
두 번째 쟁점은 25개 처리 문맥과 ESTree의 72개 노드 유형을 비교한 수치입니다. 47개가 남는다는 계산은 점검 범위의 경고 신호이지만, 서로 다른 비교 단위와 실제 파서의 도달 가능성을 고려해야 합니다. 나머지 46개를 개별 검증한 결과가 없으므로 이를 47개의 확인된 취약점이나 보편적 공격 성공률로 해석할 수 없습니다.
세 번째로 표현식 주입의 현실적 전제를 과소평가하면 위험도 평가가 달라집니다. 논문은 폼 취약점을 Critical로 표현하지만, n8n의 공식 권고는 특정 설정 조건과 별도 탈출 취약점의 필요성을 반영해 High로 평가합니다. 공개 폼의 수가 아니라 실제 데이터 재평가 설정의 보급률과 연결 가능한 취약 버전의 비율을 조사해야 현실의 노출 규모를 판단할 수 있습니다.
또한 주요 플랫폼에 격리가 없다는 포괄적 서술은 공식 자료와 맞지 않습니다. Retool은 2025년 공개 자료에서 별도의 코드 실행 컨테이너와 이를 사용하지 않는 구성의 차이를 설명합니다. 제품별 격리 방식, 버전 및 배포 설정을 비교해야 하며, 사례가 없는 플랫폼까지 동일한 결론을 적용할 수 없습니다.
저자가 인정하는 미검증 문맥과 향후 도구 공개는 연구 범위의 한계입니다. 여기에 분석자가 추가로 지적하는 것은 비교 단위의 불일치, 일반적인 불가능성 주장과 증거의 간격, 플랫폼 전체에 대한 일반화입니다. 반면 실제 CVE와 수정 이력이 존재한다는 점은 이 사례의 실무적 신뢰도를 높이는 강점입니다.
핵심 Root Cause
첫 번째 원인은 검사기가 알지 못하는 AST 문맥에서 위험한 런타임 접근을 일관되게 거부하지 않는 구조입니다. 제한된 표현식으로 허용한 입력이 검증되지 않은 언어 문맥을 통과해 더 넓은 실행 능력을 얻는다면, ‘허용된 입력의 실행 능력은 정의된 범위 안에 남는다’는 보안 불변조건이 깨집니다.
두 번째 원인은 외부 입력의 평가 결과를 다시 코드로 해석하는 데이터 처리 구조입니다. 이미 데이터로 취급한 문자열이 후속 단계에서 평가 대상이 되면, ‘외부 데이터는 명시적인 신뢰 검증 없이 실행 의미를 얻지 않는다’는 조건이 무너집니다.
세 번째 원인은 표현식 처리 환경과 비밀 정보에 접근하는 호스트 환경의 결합입니다. 자격 증명의 저장 시 암호화가 존재하더라도 같은 실행 영역에서 복호화 능력을 사용할 수 있다면, 표현식 경계의 실패를 비밀 정보 경계가 독립적으로 막지 못합니다.
핵심 공격 원리
논문의 AST 사례는 특정 문법 자체가 언제나 위험하다는 주장보다, 같은 의미를 나타내는 문법이 서로 다른 검사 경로를 거친다는 점에서 중요합니다. 보안 변환이 일부 부모 문맥만 처리하면 의미적으로 동등한 입력 사이에 검증 결과의 차이가 생길 수 있습니다.
폼 사례는 외부 데이터가 여러 처리 단계를 거치면서 평가 의미를 얻는 문제입니다. 단일 단계에서 안전한 텍스트 반영처럼 보여도 후속 평가 단계의 존재가 전체 경계를 바꿉니다. 이 위험은 모델 출력 여부와 독립적이며, 모델이 없어도 취약한 데이터 흐름이 있으면 성립합니다.
공격 흐름
방어자가 확인할 흐름은 입력 권한의 확인, 표현식 변환과 평가 경로의 식별, 호스트 실행 능력과의 격리 확인, 후속 비밀 정보 접근 경계의 검증입니다. 각 단계의 관측을 따로 남겨야 표현식 주입과 호스트 침해를 혼동하지 않습니다.
공개 폼에서는 외부 입력이 데이터로 유지되는지, 중간 처리 결과가 재평가되는지, 재평가 환경이 비밀 정보와 분리되는지를 순서대로 검토합니다. 논문의 후속 영향은 서버 권한으로 접근 가능한 정보와 연결 서비스의 권한에 따라 달라지며, 이 문서에서는 침해를 수행하는 구체적 조작 순서를 생략합니다.
성공 조건 / 실패 조건
인증된 작성자 모델에서 영향이 성립하려면 워크플로 편집 권한, 취약한 평가기, 검사되지 않는 실행 문맥 및 호스트 능력에 도달하는 경로가 함께 필요합니다. 해당 권한이 없거나 관련 버전이 수정되었거나 평가기가 독립된 제한 환경에서 실행되면 논문의 동일한 경로는 성립하지 않을 수 있습니다.
비인증 폼 모델에서는 특정 재평가 구성이 추가로 필요합니다. 데이터가 한 번만 해석되고 이후에도 텍스트로 유지되면 그 연결이 끊어집니다. 표현식 주입이 확인되더라도 별도 샌드박스 탈출이 없으면 공식 권고가 설명하는 표현식 문맥의 영향과 서버 코드 실행의 영향을 구분해야 합니다.
취약 경로를 차단한 패치와 환경의 영향 완화는 다릅니다. 운영체제 권한과 네트워크 접근을 줄이면 피해를 제한할 수 있지만, 취약한 평가기를 고친 것과 동일하게 판정할 수는 없습니다.
연구진의 실험 환경
핵심 연구 대상은 n8n의 JavaScript 표현식 평가와 AST 처리 구현입니다. 논문은 수정 전후 코드와 취약점 사례를 중심으로 분석하며, 공개 배포 전체를 대상으로 한 무작위 표본 실험이나 대규모 성공률 벤치마크를 제시하지 않습니다.
부록에는 취약점 목록, 공개 및 수정 이력, 문법 문맥 점검 방법이 포함됩니다. 본문과 부록의 사례를 읽었지만, 이 분석 실행에서는 취약한 서비스를 배포하거나 PoC를 실행하지 않았습니다. 저자의 환경에서 보여준 동작과 실제 고객 조직에서 관찰한 침해 사례는 구분해서 해석해야 합니다.
주요 실험 결과
저자는 25개의 처리 문맥과 72개의 ESTree 노드 유형을 비교하고, 약 35%의 처리 범위라는 값을 제시합니다. 이는 언어 구조에 관한 정적 비교이며, 72회의 공격 실험 중 25회만 차단되었다는 뜻이 아닙니다. 47개의 미처리 차이는 확인된 성공 사례의 수로 전환할 수 없습니다.
논문은 한 수정 버전의 9개 런타임 보호 장치가 제시한 우회 경로를 막지 못했다고 설명합니다. 이 결과는 해당 경로에 대한 보호의 부족을 뒷받침하지만, 모든 실행에서 보호 장치가 한 번도 동작하지 않거나 모든 문법이 탈출 가능하다는 입증은 아닙니다.
조직 수와 Docker 다운로드 수는 플랫폼의 사용 규모를 설명하는 배경 정보입니다. 이를 취약 설정을 사용하는 조직 수, 실제 피해자 수 또는 확인된 악용 건수로 볼 수 없습니다. LLM을 이용해 분석을 단축했다는 주장 역시 동일 조건의 비교군, 모델 설정과 반복 측정이 없어 정량적인 생산성 개선으로 확정하기 어렵습니다.
실제 발견된 취약점 / 사례
다음 표는 2026년 9월 30일 확인한 n8n 공식 권고를 기준으로 정리했습니다. 과거 수정 버전의 표이며 현재 권장 최신 버전을 대신하는 목록은 아닙니다.
| 항목 | 공식 권고의 핵심 전제 | 확인한 수정 버전 |
|---|---|---|
| CVE-2026-25049 | 인증된 워크플로 생성·편집 사용자, 표현식 샌드박스 탈출 | 1.123.17, 2.5.2 |
| CVE-2026-27577 | 인증된 워크플로 편집 사용자, 별도의 표현식 탈출 문제 | 1.123.22, 2.9.3, 2.10.1 |
| CVE-2026-27493 | 특정 폼 처리 설정에서의 비인증 표현식 주입, RCE에는 별도 탈출 필요 | 1.123.22, 2.9.3, 2.10.1 |
첫 항목의 공식 공개일은 2026년 2월 4일이며, 후속 두 권고는 2월 25일입니다. 폼 항목의 공식 등급은 High로, 논문의 Critical 표현과 차이가 있습니다. 영향 판단에는 저자 설명과 공급자의 구성 조건을 함께 적용해야 합니다.
논문이 비교 대상으로 언급한 CVE-2025-68613 공식 권고는 인증된 표현식 사용자의 RCE와 1.122.0 수정을 설명합니다. 이 역시 새로운 세 취약점과 동일한 항목으로 합산하면 안 됩니다.
저자 주장 vs 실제 증명 범위
저자의 강한 주장은 인프로세스 AST 샌드박스에 구조적인 한계가 있고 조합된 기능이 공격 실행 환경을 만든다는 것입니다. 실제 증거는 n8n의 구체적 검사 누락, 데이터 재평가 경로, 여러 수정과 공식 취약점 확인입니다. 구현별 사례는 설득력이 있지만 모든 AST 검증기에 대한 형식적 불가능성 증명은 아닙니다.
서버 접근 뒤 자격 증명과 연결 서비스로 영향이 확장될 수 있다는 설명은 위험 분석으로 중요합니다. 다만 논문이 제시한 환경의 권한과 구성에 의존하며, 모든 배포에서 조직 전체가 동일하게 침해되었다는 실증 결과는 아닙니다. 실제 공격 관찰, 실험실 검증 및 가능한 후속 영향을 각각 구분해야 합니다.
기존 공격 / 기존 점검 방식과의 차이
익숙한 금지 속성이나 토큰 문자열을 찾는 방식은 같은 의미를 가진 다른 문법 문맥과 후속 재평가를 놓칠 수 있습니다. 이 연구는 문자열 목록보다 파서 문맥, 변환 결과, 실행 권한의 연결을 확인하도록 점검 관점을 옮깁니다.
또한 모델의 지시 준수만 평가하는 프롬프트 인젝션 점검과 달리, 워크플로 엔진이 입력을 실행 의미로 바꾸는 경계를 다룹니다. 모델 안전성 시험을 통과해도 표현식 평가기와 비밀 정보 격리의 결함은 별도로 남을 수 있습니다.
연구의 한계와 주의해서 볼 부분
언어 문맥의 수가 많다는 점과 샌드박스의 안전성은 동일한 척도가 아닙니다. 허용 문법을 줄이고 나머지를 거부하는 설계에서는 노드 유형을 얼마나 지원하는지보다 허용된 의미가 어떤 실행 능력을 갖는지가 중요합니다. 100% 처리율도 보안 증명이 아닙니다.
OS 프로세스, 컨테이너와 언어 런타임의 isolate는 서로 다른 경계입니다. 단순히 격리 기술의 이름이 있다는 사실보다 공유 파일, 네트워크, 비밀 정보, IPC를 통해 다시 권한이 연결되는지 확인해야 합니다. 논문은 이런 대안들의 성능·격리 강도·운영 비용을 통제한 비교 실험을 제공하지 않습니다.
연구 결과를 실무에 옮길 때는 워크플로 작성 권한의 분배와 공개 폼 설정을 조사해야 합니다. 논문의 사용 규모나 최악의 후속 영향을 조직별 실제 노출과 같은 것으로 취급하면 조치 우선순위를 왜곡할 수 있습니다.
공개 PoC / Exploit / Tool / Artifact 분석
논문은 저자 조직의 n8n-poc 저장소를 언급합니다. 이번 확인에서는 저장소와 README 요청이 접근 제한 오류로 실패하여 내부 구조, 환경, 현재 파일과 재현 범위를 검증하지 못했습니다. 따라서 현재 재현 가능한 공개 PoC라고 확정하지 않습니다. 접근 오류가 저장소의 비공개 또는 삭제를 증명하는 것도 아닙니다.
문법 문맥 분석기는 향후 공개 예정으로 설명됩니다. 실제 접근 가능한 공식 구현과 실행 결과를 확인하지 못했으므로, 논문의 방법 설명과 현재 사용 가능한 도구를 구분해야 합니다. n8n, ESTree와 AST 처리 라이브러리 자체는 연구의 의존성과 참고 자료이며 저자의 신규 분석 도구로 취급할 수 없습니다.
공급자 권고 세 건과 저자의 공개 설명은 접근을 확인했습니다. 비교 자료인 Retool의 공식 공개 문서는 별도 코드 실행 컨테이너를 사용하는 구성의 차이를 설명하므로, 플랫폼 전반에 격리가 없다는 주장에 반례가 됩니다.
참고 취약점 자료 중 Pallets의 Jinja 권고, 후속 권고, JFrog의 n8n 연구 공개, Docker의 공개 설명 및 Zenity의 Zapier 연구는 페이지 접근을 확인했습니다. 이들이 존재한다는 사실만으로 동일한 제품 조건이나 동일한 탈출 원리를 공유한다고 단정하지 않습니다. vm2 CVE의 NVD 주소는 본문을 확보하지 못해 상세 사실 검증에는 사용하지 않았습니다.
레드팀 / 모의해킹에서 어떻게 활용할까
허가된 자체 환경에서 워크플로 작성자, 공개 입력 제출자와 시스템 관리자 사이의 권한 모델을 먼저 정리하는 데 활용할 수 있습니다. 위험한 실행을 유도하기보다 입력이 어떤 단계에서 평가 의미를 얻는지, 해당 평가기가 어떤 자원에 접근하는지를 코드와 설정으로 확인하는 것이 우선입니다.
검증 기준은 외부 데이터의 비실행 유지, 알 수 없는 문법의 명시적 거부, 비밀 정보 접근 권한의 독립성입니다. 실제 자격 증명이나 운영 서비스로 연결될 가능성이 발견되면 시험을 중단하고 격리된 더미 데이터 환경으로 옮겨야 합니다. 운영 고객이나 타 조직의 폼을 대상으로 확인하는 절차로 확장하지 않습니다.
실제 점검 시 추가할 체크리스트
- 실제 n8n 버전과 공식 권고의 해당 분기를 대조하고 수정 여부를 기록합니다.
- 워크플로 생성·편집 권한을 가진 사용자와 그 신뢰 수준을 확인합니다.
- 공개 입력이 후속 단계에서 다시 평가되는 구성을 찾아 제거하거나 데이터로 고정합니다.
- 허용하지 않은 AST 유형과 문맥이 기본 거부되는지 코드 검토로 확인합니다.
- 표현식 환경과 자격 증명 저장소의 읽기·복호화 권한이 분리되는지 확인합니다.
- 격리 환경의 파일, 네트워크와 IPC 권한이 최소화되어 있는지 확인합니다.
- 자격 증명 목적지와 워크플로 설정 변경의 감사 기록을 확보합니다.
- 의심되는 접근 증거가 있다면 영향 범위를 조사하고 관련 비밀 정보의 교체를 계획합니다.
실무 가치 평가
가장 높은 가치는 표현식 평가기를 신뢰 경계로 다루도록 한다는 데 있습니다. 서버 내부 기능으로만 보면 과소평가하기 쉬운 권한이 외부 입력과 연결될 수 있으며, 저장 시 암호화만으로는 실행 중 비밀 정보 접근을 보호할 수 없다는 점을 보여줍니다.
공식 수정 이력은 제품별 조치에 사용할 수 있는 근거입니다. 반면 표현식 언어 전체에 대한 불가능성 주장이나 플랫폼 사용 규모를 이용한 피해 규모 추정은 직접적인 운영 지표로 사용하기 어렵습니다. 이 연구는 설계 검토와 권한 분리에는 강하지만 실제 노출 빈도의 정량 추정에는 제한적입니다.
결론
이 연구는 n8n의 표현식 검사 누락과 데이터 재평가가 호스트 실행 권한까지 영향을 확장할 수 있음을 보여주는 사례 분석입니다. 중요한 대응은 수정 버전 적용과 함께 데이터·코드, 작성자·관리자, 평가기·비밀 정보 사이의 경계를 독립적으로 유지하는 것입니다.
폼 주입과 샌드박스 탈출의 전제를 구분하고 공식 권고의 구성 조건을 적용해야 위험을 정확하게 평가할 수 있습니다. 확인된 구현 결함은 받아들이되, 모든 플랫폼과 모든 AST 샌드박스로의 일반화에는 추가 증거가 필요합니다.
댓글