Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.5",
  "pubDate": "2026-08-19T20:17:20.910Z",
  "pubdate": "2026-08-19T20:17:20.910Z",
  "executiveSummary": "Wekan versions 8.36 through 9.74 contain a Server-Side Request Forgery (SSRF) vulnerability within the outgoing webhook integration functionality. The flaw arises from inadequate URL validation in models/integrations.js, which previously evaluated only the literal URL.hostname against regular expressions. This validation approach allowed malicious DNS names, such as 169-254-169-254.nip.io, to bypass initial domain-level checks and target internal network resources.\nThe impact of this vulnerability includes potential unauthorized access to internal infrastructure, sensitive metadata services, or private network endpoints. Attackers capable of configuring outgoing webhooks can leverage crafted DNS rebinding or wildcard DNS domains to traverse network boundaries. Exploitation requires the ability to supply or modify webhook integration URLs within the application.\nTo resolve this issue, Wekan version 9.74 introduces server/lib/ssrfGuard.js, which enforces robust connection-time validation by resolving all IP addresses using dns.lookup with the all: true parameter, validating every resolved address against a shared blocklist, pinning connections, and blocking redirects.",
  "technicalDetails": "The root cause of the vulnerability resides in the input validation logic within models/integrations.js. In affected versions 8.36 to 9.74, the outgoing webhook Integration URL validator performed superficial checks by comparing only the literal URL.hostname string against regular expressions.\nThis design flaw enabled attackers to bypass the first-line defense by employing alternative domain representations, such as wildcard DNS services (e.g., 169-254-169-254.nip.io), which resolve to sensitive internal or link-local IPv4 addresses like the cloud metadata service IP 169.254.169.254.\nAlthough a secondary delivery-path mechanism, fetchSafe, attempted to block restricted IPv4 destinations, its separate IPv4-only resolver and duplicated blocklist introduced logic drift and inconsistent enforcement between input-time validation and connection-time resolution. This architectural decoupling created a security gap where DNS resolution discrepancies could lead to successful requests against blocked destinations.\nThe attack flow proceeds as follows: an authenticated user or attacker with permissions to configure outgoing webhooks submits a maliciously crafted URL containing a rebinding domain or a dynamic DNS hostname mapped to internal resources. The input-time validator in models/integrations.js evaluates the literal hostname string, fails to recognize the internal risk due to the lack of deep resolution, and permits the configuration. When the webhook triggers, the underlying HTTP client attempts to dispatch the request. Due to the lack of comprehensive address-family validation and IP pinning in older versions, the request can be routed to restricted internal endpoints or metadata services, leading to potential data exfiltration or internal service interaction.\nThe vulnerability affects Wekan versions 8.36 up to 9.74, specifically impacting the webhook integration component. Authentication and privilege requirements depend on the application's access control configurations for creating or modifying webhook endpoints. Network exposure is inherent to applications handling outbound webhooks."
}