CVE-2026-41495
ŚrednieCVSS 5.3Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 17 - wyżej niż 17% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Wrażliwe dane uwierzytelniające (tokeny, klucze API) mogą wyciec poprzez logi do systemów SIEM lub osób z dostępem operacyjnym. Może to umożliwić podszycie się i nieautoryzowany dostęp do n8n.
Rekomendacja
Zaktualizuj n8n-MCP do wersji 2.47.11 lub nowszej. Sprawdź i wyczyść istniejące logi pod kątem ujawnionych tokenów oraz rozważ rotację kluczy API.
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-42449Wysokie
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.
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. Prior to version 2.47.11, when n8n-mcp runs in HTTP transport mode, incoming requests to the POST /mcp endpoint had their request metadata written to server logs regardless of the authentication outcome. In deployments where logs are collected, forwarded to external systems, or viewable outside the request trust boundary (shared log storage, SIEM pipelines, support/ops access), this can result in disclosure of: bearer tokens from the Authorization header, per-tenant API keys from the, x-n8n-key header in multi-tenant setups, JSON-RPC request payloads sent to the MCP endpoint. Access control itself was not bypassed — unauthenticated requests were correctly rejected with 401 Unauthorized — but sensitive values from those rejected requests could still be persisted in logs. This issue has been patched in version 2.47.11.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS