Contents / DnsBleed

CVE	Vulnerability name	Date	Responsible Security Disclosure by	Vulnerabilities
GHSA-66m2-4wfr-c45p	DnsBleed	2026-07-01	4n207 (coordinated disclosure) and xet7 (fix) Did send detailed report with PoC!	SSRF filter bypass via DNS-resolving hostname in outgoing webhooks (CWE-918) CVSS:3.1 High (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N) Incomplete-fix follow-up to WebhookBleed (GHSA-hc3x-hq3m-663q) and IntegrationBleed / RebindBleed Affected Wekan v8.36 and later Fixed at the upcoming WeKan release

Details

SSRF filter bypass via DNS-resolving hostname in outgoing webhooks (GHSA-66m2-4wfr-c45p, CWE-918)

Wekan's outgoing-webhook (board Integrations) URLs are validated by a synchronous validator in models/integrations.js that blocks private / loopback / link-local addresses by regex-matching the URL hostname string — it never resolves DNS. An attacker can therefore supply a public hostname that resolves to a blocked address and slip past the blocklist:

• 169-254-169-254.nip.io → 169.254.169.254 (cloud instance metadata / IMDS)
• 127-0-0-1.nip.io → 127.0.0.1 (loopback)
• any attacker-controlled domain with an A / AAAA record pointing at an internal RFC 1918 / ULA host

nip.io / sslip.io are public wildcard-DNS services that require no attacker infrastructure. The report's core point is correct and is the reason this class of bug keeps recurring: matching the hostname string is not an SSRF boundary, because the string can't see the IP the name actually resolves to.

Why the reported PoC was already blocked

The advisory quotes the models/integrations.js string blocklist and states that the webhook send path does not re-validate the resolved IP. That was true before, but the delivery path had already been fixed:

• Delivery time. Outgoing webhooks are sent through fetchSafe (server/lib/ssrfGuard.js, added in the IntegrationBleed RebindBleed fix), which resolves the hostname, validates the resolved IP, pins the TCP connection to it (closing DNS-rebinding) and blocks redirects. 169-254-169-254.nip.io resolves to 169.254.169.254 and is rejected before any request is sent.
• Input time. The REST write paths POST / PUT /api/boards/:boardId/integrations were hardened in WebhookBleed to run the DNS-aware validateAttachmentUrl(), which resolves the hostname and rejects any blocked resolved IP.

The completing fix

This release closes the remaining gap and, more importantly, the drift risk the advisory highlights. The delivery guard previously resolved only IPv4 A-records (dns.resolve4), leaving it blind to AAAA (an IPv6-only internal target was merely fail-closed, and legitimate IPv6 webhooks were unreachable) and kept a second, less-complete private-range block-list that could drift out of sync with the input-time one.

• fetchSafe now resolves both address families via dns.lookup({ all: true }) — the same resolver call the input-time validator uses — and validates every resolved address.
• The three previously-separate block-lists (schema regex, delivery guard, input validator) are unified behind the single shared isIpBlocked in models/lib/attachmentUrlValidation.js, so the input and delivery layers can no longer disagree about what is private.
• The schema-level url validator is documented in code as a non-authoritative first-line UI check only, so the regex is never again mistaken for the SSRF boundary.

Timeline	Details
2026-07-01	Reported by 4n207 (GHSA-66m2-4wfr-c45p) and fixed at the upcoming WeKan release.