CVE-2026-68558: Wekan: SSRF filter bypass via DNS-resolving hostname in outgoing webhooks (incomplete fix of CVE-2026-53446)
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Wekanto a version that resolves this vulnerability.Fixed in 9.74 - Compensating control
If you cannot upgrade to Wekan 9.74 immediately, review and align SSRF protection so input-time validation (models/integrations.js URL.hostname regex checks) and connection-time enforcement (server/lib/ssrfGuard.js IPv4/IPv6 resolution and isIpBlocked logic) use the same blocking behavior across all address families, and ensure redirects are blocked
Event History
Frequently Asked Questions
Which deployments are exposed?
Wekan versions from 8.36 through 9.74 are affected. Exposure applies where a user with the necessary privileges can configure an outgoing webhook Integration URL.
What does an attacker need to exploit this issue?
An attacker needs low-privilege access and the ability to set an outgoing webhook URL. They can use a DNS-resolving hostname that passes the literal hostname validator while resolving to a blocked address.
Is the issue mitigated by the existing webhook delivery guard?
Not reliably. The existing fetchSafe guard blocked the reported IPv4 destination, but used a separate IPv4-only resolver and duplicated blocklist, leaving inconsistent enforcement between URL validation and connection-time checks.
What changes in the fixed release?
Version 9.74 resolves all hostname addresses, validates every resolved address using shared blocking logic, pins the connection, and blocks redirects.