Wekan CVE-2026-68558

Exploitation requires an authenticated Wekan session with permission to configure Integrations (outgoing webhooks) on a board - minimally a board member role that has not been restricted from the Integrations UI. The attacker must use a DNS hostname that resolves to a blocked internal or metadata IP address, achievable trivially with public wildcard DNS services such as nip.io or xip.io, or with an attacker-controlled authoritative DNS server returning an A or AAAA record pointing to an internal target. For IPv4 cloud metadata and RFC 1918 targets: the delivery-time fetchSafe guard was already blocking these since approximately v8.35/v8.36, so practical IPv4 exploitation via the input bypass alone required the delivery guard to also be absent or misconfigured. For IPv6-only internal services or dual-stack targets with AAAA records: the pre-9.74 delivery guard resolved only IPv4, leaving these paths unblocked at delivery time. Exploitation is not possible without at least low-privilege authenticated access (PR:L per CVSS); anonymous or unauthenticated exploitation is not supported by the available data.

The CVSS 3.1 score of 8.5 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N) accurately characterizes the theoretical worst case - a scope-changing SSRF with high confidentiality impact where a successful webhook request reaches the cloud instance metadata service and returns IAM role credentials. However, the vendor changelog explicitly confirms that the specific reported proof-of-concept (IPv4 cloud metadata via nip.io) was already blocked at delivery time by the pre-existing fetchSafe guard in place since v8.35/v8.36, meaning the primary real-world risk at the time of disclosure was the IPv6 coverage gap and future blocklist drift rather than an immediately exploitable unguarded path. EPSS data is not provided in the available intelligence, limiting probabilistic forecasting; no CISA KEV listing is present, and no independently published exploit code exists, suggesting exploitation has not been observed at scale. The CVSS score is somewhat inflated relative to the immediate exploitability given the partial delivery-time mitigation, yet the underlying SSRF class remains serious - even a mid-sized municipal IT team in gdynia running Wekan on cloud infrastructure should treat this as a priority upgrade, because any authenticated board member could reach IPv6-addressed internal services or cloud metadata endpoints that the pre-9.74 delivery guard did not cover. The S:C/C:H combination is justified for cloud-hosted deployments where SSRF to metadata can escalate to full account compromise.

An authenticated Wekan board member with Integrations configuration access creates an outgoing webhook with the URL https://169-254-169-254.nip.io/latest/meta-data/iam/security-credentials/, which clears the synchronous hostname string validator because nip.io appears as a public domain with no literal private-IP pattern. If an equivalent IPv6 form of the target - or an attacker-controlled domain with an AAAA record pointing to an internal IPv6 address - is used, the pre-9.74 delivery guard (which resolved only IPv4 A-records) would not block the request, causing Wekan's server to issue an outbound HTTP request to the internal or metadata target and potentially returning credential material to the webhook-triggering board action.