The vulnerability CVE-2025-68949 affects the n8n open source workflow automation platform, specifically versions from 1.36.0 to before 2.2.0. The root cause is in the Webhook node’s IP whitelist validation mechanism, which incorrectly performs partial string matching rather than exact IP address comparison. This means that if an attacker’s IP address contains the whitelisted IP as a substring, the system erroneously grants access. For example, if the whitelist contains 192.168.1.1, an attacker with IP 192.168.1.10 could bypass the whitelist check. This flaw impacts both IPv4 and IPv6 addresses. The vulnerability undermines the intended security boundary that relies on IP-based restrictions to control webhook access, potentially allowing unauthorized external requests to trigger workflows. The vulnerability is categorized under CWE-134 (Use of Externally-Controlled Format String) and CWE-284 (Improper Access Control). It has a CVSS v3.1 score of 5.3 (medium severity), with an attack vector of network, low attack complexity, no privileges or user interaction required, and limited impact on confidentiality only. No known exploits are reported in the wild as of now. The issue was addressed and fixed in n8n version 2.2.0 by correcting the IP whitelist validation logic to perform exact IP comparisons.

For European organizations using affected versions of n8n, this vulnerability can lead to unauthorized invocation of restricted webhooks, potentially exposing sensitive business workflows or data. Since webhooks often trigger automated processes or data exchanges, unauthorized access could result in data leakage or manipulation of workflow execution. Although the vulnerability does not directly impact integrity or availability, the confidentiality breach risk is significant, especially for organizations relying on IP-based access controls as a primary security measure. This risk is heightened in sectors with strict data protection requirements such as finance, healthcare, and government. The ease of exploitation (no authentication or user interaction needed) increases the threat level. Organizations with public-facing n8n webhook endpoints are particularly vulnerable to remote attackers who can craft requests from IPs that partially match whitelisted addresses.

European organizations should immediately upgrade n8n instances to version 2.2.0 or later where the vulnerability is fixed. Until upgrade is possible, administrators should avoid relying solely on IP-based whitelist controls for webhook security. Instead, implement additional authentication mechanisms such as secret tokens, OAuth, or mutual TLS to validate webhook requests. Review and tighten network-level controls, including firewall rules and VPN access, to restrict webhook endpoint exposure. Conduct thorough audits of existing webhook configurations to identify any that rely on IP whitelisting and assess their risk. Monitor webhook access logs for suspicious requests originating from IP addresses that partially match trusted IPs. Consider deploying Web Application Firewalls (WAFs) with custom rules to detect and block anomalous webhook traffic patterns. Finally, educate developers and administrators about the limitations of partial IP matching and the importance of exact IP validation in access controls.