CVE-2026-68558 in Wekan
Summary
by MITRE • 08/20/2026
Wekan is open source kanban built with Meteor. From 8.36 until 9.74, the outgoing webhook Integration URL validator in models/integrations.js checked only the literal URL.hostname against regular expressions, so DNS names such as 169-254-169-254.nip.io passed that first-line check. The delivery path's fetchSafe guard already blocked the reported IPv4 destination, but its separate IPv4-only resolver and duplicated blocklist created inconsistent all-address-family enforcement and drift risk between input-time and connection-time validation. Version 9.74 makes server/lib/ssrfGuard.js resolve all addresses with `dns.lookup({ all: true })`, validate every result through the shared isIpBlocked logic, pin the connection, and block redirects. This issue is fixed in version 9.74.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability described involves a Server-Side Request Forgery (SSRF) flaw within Wekan versions ranging from 8.36 to 9.74. SSRF vulnerabilities occur when an application fetches a remote resource without validating the user-supplied URL, allowing attackers to coerce the application into sending crafted requests to unexpected destinations. In this specific case, the outgoing webhook integration feature in Wekan failed to adequately restrict which URLs could be accessed by server-side processes. This flaw stems from insufficient validation logic within the models/integrations.js file, where the system relied on a superficial check of the URL hostname against regular expressions rather than performing comprehensive network-level verification.
The technical root cause lies in how the application handled DNS resolution and IP address blocking during the input phase versus the connection phase. The initial validator checked only the literal string representation of the hostname against regex patterns designed to block private or reserved IP ranges. However, this check was bypassed by using domain names that resolve to blocked addresses through techniques such as nip.io subdomains. For instance, a DNS name like 169-254-169-254.nip.io resolves to the link-local address 169.254.169.254, which is commonly used by cloud providers for metadata services and should be blocked. While the fetchSafe guard attempted to mitigate this risk using a separate IPv4-only resolver and a duplicated blocklist, this approach introduced significant inconsistencies. The validation logic at input time did not align with the resolution logic at connection time, creating a window of opportunity where an attacker could exploit discrepancies between these two stages.
This architectural inconsistency creates a drift risk where input-time validation might pass while connection-time behavior differs due to DNS caching or resolver variations. Furthermore, the use of an IPv4-only resolver meant that any IPv6 addresses resolving to private ranges were not subject to the same rigorous blocking rules as their IPv4 counterparts. This lack of all-address-family enforcement allows attackers to potentially bypass restrictions by leveraging IPv6 pathways if they are supported by the underlying network stack or DNS infrastructure. The failure to pin connections and block redirects further exacerbates the risk, as an attacker could redirect a request from a permitted domain to a blocked internal IP address during the handshake process, effectively circumventing the initial checks.
The operational impact of this vulnerability is severe, particularly in environments where Wekan instances have access to internal network resources or cloud metadata endpoints. An authenticated attacker with permission to create webhooks can craft malicious URLs that cause the server to make requests to internal services such as database servers, administrative interfaces, or cloud instance metadata stores like 169.254.169.254 on AWS EC2 instances. Accessing these metadata endpoints can lead to credential theft, unauthorized configuration changes, and further lateral movement within the network infrastructure. This aligns with CWE-918, which addresses Server-Side Request Forgery (SSRF) flaws where a web server receives a URL or IP address from an HTTP request and makes requests to that resource without validating it for internal networks. Additionally, this vulnerability maps to MITRE ATT&CK technique T1059.007, Command and Scripting Interpreter via Web Services, as the attacker leverages legitimate application functionality to execute unauthorized network actions that facilitate reconnaissance or data exfiltration.
The issue was addressed in version 9.74 of Wekan through a comprehensive overhaul of the SSRF protection mechanisms. The fix introduces server/lib/ssrfGuard.js which utilizes dns.lookup with the all: true option to resolve both IPv4 and IPv6 addresses, ensuring that no address family is overlooked during validation. Every resolved IP address is then validated against a shared isIpBlocked logic, eliminating the duplication and inconsistency present in previous versions. By pinning connections after successful validation, the application prevents redirect-based bypasses where an initial allowed domain could point to a blocked internal IP. This holistic approach ensures that input-time checks are robustly enforced at connection time across all network protocols. Organizations running Wekan should immediately upgrade to version 9.74 or later to mitigate this risk and ensure consistent enforcement of security policies regarding outbound web requests.