Podatności n8n-MCP

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.

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.

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.

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.

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.

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.