Wekan SSRF filter bypass via DNS-resolving hostname in outgoing webhooks

Vulnerability Overview Vulnerability Name: SSRF filter bypass via DNS-resolving hostname in outgoing webhooks (incomplete fix of GHSA-hc3x-hq3m-663q) Vulnerability Description: This vulnerability involves a bypass of the "integrations" URL validator in the Wekan platform. The validator prevents access to private addresses (such as 169.254.169.254) via string/regular expression matching but does not resolve DNS. An attacker can bypass this restriction by providing a public hostname that resolves to a blocked address (e.g., 169-254-169-254.nip.io). When the webhook is triggered, the hostname resolves to an internal IP address, resulting in a Server-Side Request Forgery (SSRF) vulnerability. Scope of Impact Affected Versions: Wekan 8.36-9.73 Fixed Version: Wekan 9.74 CVSS Score: 8.5/10 Attack Vector: Network Attack Complexity: Low Privileges Required: Low User Interaction: None Scope: Changed Confidentiality: High Integrity: Low Availability: None Remediation Recommended Fix: Validate the resolved IP address at the time of connection, rather than the hostname. - Resolve the hostname and reject any IP that resolves to loopback/private-link-local/ULA reserved addresses (including IPv4 and IPv6 mappings). - Perform this check before sending and direct the connection to the inspected IP (resolve then connect to the same address) to prevent DNS rebinding. - Re-validate on each redirect (or disable redirects). - Prefer using tested libraries (such as in Node.js) to apply IP filtering. Proof of Concept (POC) 1. As a board administrator (any user can create their own board), create an outgoing webhook integration: The URL is accepted (bypassing the blacklist). 2. Trigger any board activity (e.g., creating a card); Wekan sends the webhook: HTTP POST to 169-254-169-254.nip.io → 169.254.169.254. Code Snippet Impact Server-Side Request Forgery (SSRF) vulnerability exploitable by any authenticated user (board administrator). The server sends HTTP POST requests to internal/loopback/link-local addresses, including cloud instance metadata (169.254.169.254). In cloud-hosted deployments and for internal services (databases, admin panels, etc.), responses are not returned to the attacker (blind SSRF); however, the attacker can use it to probe the internal network/ports and interact with metadata services that accept requests.

Goal Reached Thanks to every supporter — we hit 100%!

Wekan SSRF filter bypass via DNS-resolving hostname in outgoing webhooks

More from this source