CVE-2026-42449
WysokieCVSS 8.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 11 - wyżej niż 11% wszystkich znanych CVE
Streszczenie
n8n-MCP w wersjach 2.47.4–2.47.13 ma niekompletny walidator URL w SSRFProtection.validateUrlSync(), który nie sprawdza adresów IPv6. Adresy IPv4-mapped IPv6, takie jak http://[::ffff:169.254.169.254], omijają kontrole metadanych chmury, localhost i zakresów prywatnych, umożliwiając atakującemu wywołanie żądań do wrażliwych celów i ujawnienie odpowiedzi oraz nagłówka x-n8n-api-key. Problem naprawiono w wersji 2.47.14.
Ocena ryzyka
Atakujący może uzyskać dostęp do metadanych chmury, usług lokalnych i sieci prywatnych oraz przechwycić klucz API n8n, co może prowadzić do eskalacji uprawnień i wycieku danych. Ryzyko dotyczy wdrożeń wykorzystujących n8n-mcp jako SDK z danymi InstanceContext pochodzącymi od użytkownika.
Rekomendacja
Zaktualizuj n8n-MCP do wersji 2.47.14 lub nowszej. Jako obejście waliduj adresy URL przed przekazaniem do SDK, ogranicz ruch wychodzący na poziomie sieci i odrzucaj wartości n8nApiUrl kontrolowane przez użytkownika.
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.
- CVE-2026-42282Średnie
W n8n-MCP przed wersją 2.47.13, w trybie transportu HTTP, uwierzytelnione żądania tools/call miały pełne argumenty i parametry JSON-RPC zapisywane w logach serwera przed jakąkolwiek redakcją. Gdy wywołanie narzędzia zawiera dane uwierzytelniające (np. n8n_manage_credentials.data), surowe wartości mogą zostać utrwalone w logach. W środowiskach z gromadzeniem logów może to ujawnić tokeny bearer, poświadczenia OAuth, klucze API i inne sekrety. Luka wymaga uwierzytelnienia i została naprawiona w wersji 2.47.13.
- CVE-2026-41495Średnie
W n8n-MCP przed wersją 2.47.11, w trybie transportu HTTP, metadane żądań do punktu końcowego POST /mcp były zapisywane w logach serwera niezależnie od wyniku uwierzytelnienia. W środowiskach, gdzie logi są gromadzone lub przekazywane dalej, może to ujawnić tokeny bearer, klucze API poszczególnych dzierżawców oraz ładunki JSON-RPC. Kontrola dostępu nie została obejściа — nieuwierzytelnione żądania były poprawnie odrzucane z kodem 401, ale wrażliwe wartości mogły trafić do logów. Luka została naprawiona w wersji 2.47.11.
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 was not primarily affected — it has a second async validator (validateWebhookUrl) that catches IPv6 addresses. This issue has been fixed in version 2.47.14. If users are unable to upgrade immediately as a workaround they can validate URLs before passing to the SDK, restrict egress at the network layer, and reject user-controlled n8nApiUrl values.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS