CVE-2026-68558: Wekan SSRF Vulnerability

CVE-2026-68558 Overview

CVE-2026-68558 is a Server-Side Request Forgery (SSRF) vulnerability in Wekan, an open source kanban board built with Meteor. The flaw affects versions 8.36 through 9.73 and exists in the outgoing webhook Integration URL validator inside models/integrations.js. The validator only checked the literal URL.hostname against regular expressions, allowing DNS names such as 169-254-169-254.nip.io to bypass the first-line SSRF check and resolve to internal addresses like the AWS instance metadata service. The issue is tracked as CWE-918 and fixed in version 9.74.

Critical Impact
An authenticated attacker can configure outgoing webhooks that resolve to internal network destinations, enabling SSRF against cloud metadata services and internal HTTP endpoints reachable by the Wekan server.

Affected Products

Wekan versions 8.36 through 9.73
Wekan models/integrations.js outgoing webhook Integration URL validator
Wekan server/lib/ssrfGuard.js delivery-time fetch guard

Discovery Timeline

2026-08-19 - CVE-2026-68558 published to the National Vulnerability Database
2026-08-19 - Last updated in NVD database

Technical Details for CVE-2026-68558

Vulnerability Analysis

The vulnerability, tracked as GHSA-66m2-4wfr-c45p and named DnsBleed, stems from inconsistent SSRF enforcement between input-time validation and connection-time delivery. The Integration URL validator in models/integrations.js runs synchronously in an isomorphic context and cannot resolve DNS. It only checks the literal hostname string against regular expressions for private and loopback IPs.

Any public hostname that resolves to an internal IP address bypasses this check. Attackers can use services like nip.io to encode internal IPv4 addresses inside public DNS names, for example 169-254-169-254.nip.io resolving to 169.254.169.254, the AWS instance metadata service endpoint.

The delivery path's fetchSafe guard did block the reported IPv4 destination, but it used a separate IPv4-only resolver with a duplicated blocklist. This created drift between input-time and connection-time enforcement and inconsistent handling across address families, including IPv6.

Root Cause

The root cause is reliance on a non-authoritative, synchronous hostname regex check as the SSRF boundary. The validator cannot perform DNS resolution, so it never sees the actual destination IP. The duplicated blocklist between models/integrations.js and server/lib/ssrfGuard.js compounded the drift risk.

Attack Vector

An authenticated user with permission to create outgoing webhook integrations submits an Integration URL containing a public hostname that resolves to an internal IP. When Wekan later delivers a webhook event, the server issues an HTTP request to the resolved internal address and may return response data to the attacker's board activity.

javascript

// Source: https://github.com/wekan/wekan/commit/ef845fe4a0adb82af436313310939cd48c0b1347
// Patch to models/integrations.js clarifying the validator role
       type: String,
     },
     url: {
-      // URL validation with SSRF protection
       /**
-       * URL validation regex (https://mathiasbynens.be/demo/url-regex)
-       * Includes validation to block private/loopback addresses and ensure safe protocols
+       * First-line, NON-AUTHORITATIVE SSRF check.
+       *
+       * This validator runs synchronously (isomorphically) and therefore CANNOT
+       * resolve DNS. It only rejects the obvious cases (bad protocol, literal
+       * private/loopback IPs, localhost) to give quick feedback in the UI. It is
+       * trivially bypassed by a public hostname that resolves to an internal IP
+       * (e.g. 169-254-169-254.nip.io), so it MUST NOT be relied on as the SSRF
+       * boundary — that was the root cause of GHSA-66m2-4wfr-c45p (DnsBleed).
+       *
+       * The authoritative, DNS-aware checks live server-side and validate the
+       * RESOLVED IP of every address family:
+       *   - input time: validateAttachmentUrl() at the REST write paths
+       *     (server/models/integrations.js POST/PUT), and
+       *   - delivery time: fetchSafe() (server/lib/ssrfGuard.js), which resolves
+       *     once, pins the connection to the validated IP and blocks redirects.
        */
       type: String,
       custom() {

Detection Methods for CVE-2026-68558

Indicators of Compromise

Outgoing webhook integrations pointing to hostnames using DNS wildcard services such as nip.io, sslip.io, or xip.io.
Outbound HTTP requests from the Wekan server process to RFC1918 ranges, 127.0.0.0/8, 169.254.0.0/16, or IPv6 link-local fe80::/10 addresses.
Access log entries showing Wekan fetching cloud metadata endpoints such as 169.254.169.254 or metadata.google.internal.

Detection Strategies

Audit the Wekan integrations collection for URLs whose hostnames resolve to internal or metadata IP addresses.
Monitor egress traffic from Wekan hosts for connections to internal ranges that would not normally be part of webhook delivery.
Alert on unusual webhook creation activity, especially from newly created or low-privilege user accounts.

Monitoring Recommendations

Enable network flow logging on the Wekan server subnet and correlate to the Wekan process identifier or container.
Track HTTP client logs from fetchSafe in server/lib/ssrfGuard.js for blocked destinations after upgrading.
Review DNS query logs for lookups of encoded-IP hostnames originating from the Wekan host.

How to Mitigate CVE-2026-68558

Immediate Actions Required

Upgrade Wekan to version 9.74 or later, which resolves all address families through dns.lookup({ all: true }) and validates every result via the shared isIpBlocked logic.
Review existing outgoing webhook integrations and remove any pointing to suspicious or wildcard DNS hostnames.
Restrict who can create outgoing webhook integrations to trusted administrators until the upgrade is applied.

Patch Information

The fix is delivered in Wekan release v9.74 via commit ef845fe. The patch centralizes SSRF enforcement in server/lib/ssrfGuard.js, exports isIpBlocked from models/lib/attachmentUrlValidation.js for shared use, resolves every address family, pins the outbound connection to the validated IP, and blocks HTTP redirects. Full details are in the GitHub Security Advisory GHSA-66m2-4wfr-c45p.

Workarounds

Place the Wekan server behind an egress proxy that denies traffic to RFC1918, loopback, and cloud metadata ranges across both IPv4 and IPv6.
Block DNS resolution of wildcard IP-encoding services such as nip.io and sslip.io at the resolver used by the Wekan host.
Disable the outgoing webhook feature or restrict integration creation permissions until upgrading to 9.74.

bash

# Example iptables egress restriction on the Wekan host
iptables -A OUTPUT -m owner --uid-owner wekan -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner wekan -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner wekan -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner wekan -d 192.168.0.0/16 -j REJECT
ip6tables -A OUTPUT -m owner --uid-owner wekan -d fe80::/10 -j REJECT