나는 n8n의 보안 결함을 찾아다녔다. 그 진실은 어떤 악용보다도 훨씬 더 충격적이었다.

Source: Dev.to

Introduction

나는 n8n에 대한 표준 보안 심층 분석을 쓰려고 계획했다. 흔히 하는 방식이다: CVE 데이터베이스를 스크랩하고, 닫힌 GitHub 이슈를 파고들며, 인기 있는 워크플로 자동화 도구의 아키텍처적 약점을 분석한다. 오픈소스 세계에서는 모든 도구가 숨겨진 결함을 가지고 있으며, 나는 그것들을 찾아내고 싶었다.

하지만 조사는 시작도 하기 전에 막다른 골목에 다다랐다. 데이터를 끌어올 때—크래시 리포트, 패치 노트, 혹은 공개 스레드를 기대했지만—나는 잡음만 얻었다. 검색 결과는 버퍼 오버플로우나 권한 상승에 관한 것이 아니라 “AI 에이전트의 부상”과 “SaaS 시장 트렌드” 같은 고수준의 허풍으로 가득했다.

The Search Process

처음에는 이것을 검색 과정의 실패로 여겼다. 나는 특정 기술 질문(“n8n은 안전한가?”)을 디버깅하려 했고, “로그”(내 연구 결과)가 마케팅 과대광고로 오염된 것이었다.

하지만 그 잡음을 살펴보면서 나는 “무관한” 결과들이 실제로 훨씬 큰 문제를 가리키고 있다는 것을 깨달았다. 우리는 자동화 보안에 대해 잘못된 질문을 하고 있었다.

Emerging Threat: Autonomous AI Agents

우리는 보통 n8n, Make, Zapier 같은 플랫폼을 코드에 버그가 있는지 감사한다. SQL 인젝션 취약점이 있나? 공격자가 인증을 우회할 수 있나? 이러한 질문은 타당하지만, 내 데이터의 “잡음”은 새로운, 급속히 다가오는 위협 벡터를 강조했다: 자율 AI 에이전트.

우리는 인간이 명시적으로 워크플로를 구축하던 시기(예: “이메일을 받으면 첨부파일을 Drive에 저장”)를 넘어, AI 에이전트에게 목표와 도구 세트를 제공하는 시대로 이동하고 있다. 그리고 AI 에이전트에게 가장 강력한 도구는 n8n 같은 플랫폼이다.

생각해 보라. LLM 기반 에이전트에게 n8n 인스턴스에 대한 접근 권한을 부여한다면, 사실상 전체 디지털 인프라에 대한 범용 API 키를 제공하는 것과 같다:

• CRM 접근: 고객 데이터 읽기/쓰기 (Salesforce 노드)
• 재무 제어: 금액 이동 또는 환불 발행 (Stripe 노드)
• 코드 배포: 소스 코드 읽기 또는 빌드 트리거 (GitHub 노드)
• 시스템 접근: 자체 호스팅 인스턴스에서 셸 스크립트 실행 (“Execute Command” 노드)

이 시나리오에서는 n8n이 완벽하게 안전할 수도 있다—버그 제로, 완전 패치. 하지만 이를 제어하는 AI 에이전트가 혼란스러워지거나, 명령을 환각하거나, 프롬프트 인젝션 공격에 노출되면 플랫폼은 무기가 된다.

공격자는 더 이상 n8n을 해킹할 필요가 없다. 단지 AI를 속여 “이 데이터베이스를 내보내서 외부 주소로 이메일을 보내야겠다”라고 생각하게 하면 된다.

Risks and Challenges

이는 복합적인 위험 프로파일을 만든다. 당신은 단순히 나쁜 코드에 대비하는 것이 아니라, 비결정적이고 블랙박스인 의사결정에 대비해야 한다.

• AI의 “의도”에 대한 방화벽 규칙은 어떻게 작성하나요?
• 에이전트가 유연하고 자율적이어야 하는 상황에서 최소 권한 원칙을 어떻게 구현하나요?

n8n의 CVE를 찾으려는 내 검색은 빈 결과를 반환했다. 그러나 그 침묵은 오해를 불러일으킨다. 우리는 어제의 취약점—고전적인 소프트웨어 버그—을 찾느라 바쁘면서도, 무심코 내일의 보안 악몽을 위한 인프라를 구축하고 있다.

Conclusion

n8n의 보안은 이제 n8n 팀만의 책임이 아니다. 우리가 곧 열쇠를 넘겨줄 AI 에이전트 주변에 구축하는 가드레일에 달려 있다.