CVE-2026-42449
WysokieStreszczenie
W wersjach 2.47.4 do 2.47.13 n8n-MCP występuje podatność związana z brakiem weryfikacji adresów IPv6 w funkcji walidacji URL. Atakujący może wykorzystać tę lukę do wysyłania żądań HTTP do nieautoryzowanych punktów końcowych, co prowadzi do ujawnienia danych.
Ocena ryzyka
Organizacje mogą być narażone na ataki SSRF, które mogą prowadzić do wycieku danych z lokalnych usług lub prywatnych sieci. Ujawnienie klucza API n8n może umożliwić atakującym dalsze działania w systemie.
Rekomendacja
Zaleca się aktualizację n8n-MCP do najnowszej wersji, która zawiera poprawki dotyczące weryfikacji adresów IPv6. Należy również przeanalizować i ograniczyć dostęp do n8nApiUrl w aplikacjach korzystających z tego serwera.
Inne podatności w n8n-MCP
Zobacz wszystkie- CVE-2026-54052Krytyczne
W n8n-MCP przed wersją 2.56.1, w trybie HTTP z włączoną wielodzierżawnością (ENABLE_MULTI_TENANT=true), lokalne kopie zapasowe wersji przepływów pracy nie były izolowane dla poszczególnych dzierżawców. Umożliwiało to uwierzytelnionemu dzierżawcy odczyt i usunięcie kopii zapasowych innych dzierżawców, w tym pełnych definicji węzłów, referencji do poświadczeń i nagłówków autoryzacyjnych.
- CVE-2026-44694Krytyczne
W n8n-MCP, serwerze MCP, występuje podatność na uwierzytelnione oszustwo w żądaniach serwerowych, która dotyczy narzędzi wyzwalania webhooków oraz klienta API n8n. Problem ten występuje w wersjach od 2.18.7 do przed 2.50.2 i został naprawiony w wersji 2.50.2.
- CVE-2026-55608Średnie
W n8n-MCP przed wersją 2.57.4, w trybie wielodostępnym HTTP z włączoną opcją ENABLE_MULTI_TENANT=true, uwierzytelniony najemca mógł uzyskać dostęp do kopii zapasowych workflow_versions o domyślnym zakresie, zamiast być ograniczonym do swojego zakresu najemcy. Problem umożliwiał ujawnienie lub usunięcie kopii zapasowych wersji przepływów pracy z wcześniejszych wdrożeń jedno- lub wielodostępnych.
- CVE-2026-45707Wysokie
W n8n-MCP przed wersją 2.51.2, gdy włączono tryb wielodostępny (ENABLE_MULTI_TENANT=true), żądania HTTP bez nagłówków x-n8n-url lub x-n8n-key domyślnie używały poświadczeń operatora, co pozwalało uwierzytelnionemu tenantowi MCP na wykonywanie wywołań zarządzania n8n na instancji operatora zamiast własnej.
- CVE-2026-45582Średnie
W n8n-MCP przed wersją 2.51.3, sanitizer telemetrii przepływów pracy mógł zachowywać fragmenty parametrów węzłów w kształcie URL, takich jak identyfikatory klientów czy sekrety w zapytaniach, przed wysłaniem danych do anonimowego backendu telemetrii. Problem został naprawiony w wersji 2.51.3.
Oryginalny opis (angielski, źródło NVD)
n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. In versions 2.47.4 through 2.47.13, the SDK embedder path (N8NDocumentationMCPServer constructor, getN8nApiClient(), and validateInstanceContext()), the synchronous URL validator in SSRFProtection.validateUrlSync() had no IPv6 checks. IPv4-mapped IPv6 addresses such as http://[::ffff:169.254.169.254] bypassed the cloud-metadata, localhost, and private-IP range checks. An attacker able to supply an n8nApiUrl value could cause the server to issue HTTP requests to cloud metadata endpoints, RFC1918 private networks, or localhost services. Response bodies are returned to the caller (non-blind SSRF), and the n8nApiKey is forwarded in the x-n8n-api-key header to the attacker-controlled target. Projects with deployments embedding n8n-mcp as an SDK using N8NDocumentationMCPServer or N8NMCPEngine with user-supplied InstanceContext are affected. The first-party HTTP server deployment