CVE-2026-55608

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.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.

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.

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.

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.