CVE-2026-68558

Executive Summary

CVE-2026-68558 is a Server-Side Request Forgery (SSRF) vulnerability in Wekan, an open-source kanban board application built on the Meteor framework, affecting versions 8.36 through 9.74. The flaw resides in the outgoing webhook integration URL validation logic, where the validator in models/integrations.js performs only a superficial hostname check against regular expressions, allowing DNS rebinding-style bypasses via services like nip.io (e.g., 169-254-169-254.nip.io). An authenticated attacker with permission to configure webhook integrations could leverage this to make the server issue requests to internal network resources, potentially accessing cloud metadata services and other internal endpoints. The vulnerability has a CVSS score of 8.5 (High) with a confirmed fix in version 9.74; however, no public patch Evidence has been tracked for earlier versions at the time of this report.

Technical Analysis

The vulnerability is a classic Server-Side Request Forgery (CWE-918) arising from an incomplete validation strategy in the webhook integration URL validation logic. According to the NVD description, the vulnerable code path exists in models/integrations.js, where outgoing webhook URLs are validated. The first-line validation mechanism checks the literal URL.hostname against a set of regular expressions. This check is insufficient because it fails to account for DNS names that resolve to internal or link-local IP addresses. For example, the domain 169-254-169-254.nip.io is a public DNS service that resolves to 169.254.169.254 — the well-known cloud metadata service IP address. Since the validator only inspects the literal hostname string and not the actual resolved addresses, such DNS names pass the initial validation.

The NVD description further notes that the delivery path's fetchSafe guard already blocked the reported IPv4 destination. However, the fetchSafe mechanism had its own shortcomings: it used a separate IPv4-only resolver and maintained a blocklist that was duplicated and potentially inconsistent with the input-time validation blocklist. This architectural flaw introduced a drift risk — meaning the set of IP addresses blocked at input time (during URL validation) could differ from the set blocked at connection time (when the request is actually made). This inconsistency creates a window for all-address-family enforcement gaps, potentially allowing IPv6 addresses or other edge cases to slip through the blocklist.

The fix implemented in version 9.74 addresses these issues by replacing the fragmented validation approach with a centralized guard in server/lib/ssrfGuard.js. The new implementation:

1. Uses dns.lookup({ all: true }) to resolve all IP addresses associated with a hostname (both IPv4 and IPv6).
2. Validates every resolved address through a shared isIpBlocked logic, ensuring consistent enforcement across all address families.
3. Pins the connection to the validated resolved IP address to prevent time-of-check/time-of-use (TOCTOU) DNS rebinding attacks.
4. Blocks redirects, preventing an attacker from using a redirect chain to bypass the SSRF protections at the initial fetch stage.

From an attacker's perspective, the vulnerability class is SSRF via DNS-based bypass of an input validation regex. The attack surface is any Wekan instance where authenticated users can create or modify outgoing webhook integrations. The privilege requirement of PR:L in the CVSS vector indicates that a low-privileged account is sufficient to exploit this issue.

Exploitation Scenarios

Assumption: No public PoC is available at the time of writing; the attack chain below is inferred from the vulnerability class and the NVD description. Specific implementation details not present in the description are intentionally omitted.

Attack Chain:

1. Reconnaissance / Target Identification: An attacker with a valid low-privileged account in a Wekan instance (versions 8.36 to 9.74) identifies that the board admin or the platform allows configuration of outgoing webhook integrations. The attacker enumerates the Wekan UI to locate the webhook configuration settings within board or card integrations.

2. Triggering the Flaw: The attacker supplies a webhook integration URL that resolves to an internal or restricted address via a DNS rebinding service. For example, the attacker could use a domain name such as 169-254-169-254.nip.io (which resolves to the AWS/GCP/Azure metadata service IP 169.254.169.254). Because the validator in models/integrations.js only checks the literal hostname string against its regular expression blocklist, and the hostname 169-254-169-254.nip.io does not match the IP-based blocklist regex, the input passes validation. Alternatively, the attacker could use any DNS name that resolves to an internal IP range not blocked by the regex.

3. Payload / Execution Mechanism: When a webhook event is triggered (e.g., a card is moved, a comment is added, or another board event fires), the Wekan server performs an HTTP request to the configured webhook URL. At this point, the fetchSafe guard attempts to block the request, but due to the IPv4-only resolver and duplicated blocklist, the guard may either fail to resolve and validate all addresses or have a stale/inconsistent blocklist. The server-side fetch proceeds, sending a request to the internal target. If the target is the cloud metadata service (169.254.169.254), the attacker can potentially retrieve IAM credentials, instance identity documents, or other sensitive cloud environment data.

4. Post-Exploitation Impact: With access to internal network services via the SSRF, the attacker can:

   • Read cloud metadata services to obtain temporary IAM credentials, potentially granting broader cloud-account access.
   • Probe and interact with internal HTTP-based services (admin panels, internal APIs, monitoring dashboards) that are not exposed externally.
   • Use the Wekan server as a pivot point to scan and interact with the internal network.
   • The CVSS vector C:H/I:L/A:N indicates high confidentiality impact (data exfiltration), low integrity impact (minor data modification), and no availability impact.

Impact Assessment

The business impact of CVE-2026-68558 is High, as reflected by the CVSS score of 8.5 (High severity). The vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N breaks down as:

• Attack Vector (AV:N): Network — the vulnerability is exploitable remotely.
• Attack Complexity (AC:L): Low — no special conditions beyond the standard webhook configuration flow are required; the DNS-based bypass does not require race conditions or complex setups.
• Privileges Required (PR:L): Low — an authenticated user with basic access to configure integrations can exploit this; no admin privileges are required.
• User Interaction (UI:N): None — no victim interaction is needed.
• Scope (S:C): Changed — the impacted resource (internal network/cloud metadata) is outside the security authority of the vulnerable component (Wekan server).
• Confidentiality (C:H): High — full read access to internal HTTP endpoints and cloud metadata is possible.
• Integrity (I:L): Low — in limited scenarios, an attacker might be able to modify internal resources via non-GET HTTP methods (e.g., issuing PUT/POST requests to internal APIs), though this is constrained.
• Availability (A:N): None — no direct availability impact.

The blast radius extends to the internal network adjacent to the Wekan server. If the Wekan instance is deployed in a cloud environment (AWS, GCP, Azure) with a reachable metadata service, the confidentiality impact becomes critical — an attacker could harvest IAM credentials and pivot into the cloud account. For on-premises deployments, the risk is lower but still significant, as internal HTTP services (e.g., internal dashboards, admin panels for adjacent systems, CI/CD tools) become reachable. Affected systems are any Wekan deployment in the version range 8.36 to 9.74 with webhook integration functionality enabled and accessible to non-admin users.

Detection Guidance

Sigma Rule

title: Wekan SSRF via DNS Rebinding in Webhook Integration (CVE-2026-68558)
id: 3f8c7b21-6a4d-4e2f-9c1a-5d2f8b7a9c31
status: experimental
description: Detects attempts to configure Wekan webhook integration URLs that use DNS rebinding services or resolve to internal/cloud metadata IP addresses.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-68558
author: Valtersit Threat Intel
date: 2026/01/01
logsource:
    category: application
    product: wekan
detection:
    selection:
        event.category: webhook
        wekan.integration.url|contains:
            - '.nip.io'
            - '.xip.io'
            - '.sslip.io'
            - '169.254.169.254'
            - '169-254-169-254'
        wekan.integration.url|re:
            - '^https?://(127|10|192\.168|172\.(1[6-9]|2[0-9]|3[01]))\.'
            - '^https?://\[::1\]'
            - '^https?://\[fc'
            - '^https?://\[fd'
    condition: selection
falsepositives:
    - Legitimate use of public services that happen to use nip.io or similar wildcard DNS services (rare but possible)
    - Intentionally configured access to internal services via webhooks by legitimate administrators
level: high

YARA Rule

rule Wekan_SSRF_DNS_Rebinding_CVE_2026_68558 {
    meta:
        author = "Valtersit Threat Intel"
        description = "Detects Wekan webhook URL payloads using DNS rebinding services or internal IP literals"
        cve = "CVE-2026-68558"
        date = "2026-01-01"
        severity = "high"
    strings:
        $nip = ".nip.io" ascii wide nocase
        $xip = ".xip.io" ascii wide nocase
        $sslip = ".sslip.io" ascii wide nocase
        $meta = "169.254.169.254" ascii wide
        $meta_dash = "169-254-169-254" ascii wide
        $priv10 = "http://10." ascii wide nocase
        $priv192 = "http://192.168." ascii wide nocase
        $priv172 = "http://172." ascii wide nocase
        $ipv6_loop = "http://[::1]" ascii wide nocase
    condition:
        uint16(0) == 0x7B22 or uint16(0) == 0x5B7B or uint32(0) == 0x0A7D22 or
        any of ($nip, $xip, $sslip, $meta, $meta_dash) or
        (any of ($priv10, $priv192, $priv172) and filesize < 1MB) or
        $ipv6_loop
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (msg:"CVE-2026-68558 - Wekan SSRF Webhook URL with DNS Rebinding Service"; flow:established,to_server; http.uri; content:".nip.io"; nocase; sid:202668581; rev:1; classtype:attempted-recon; reference:cve,2026-68558; priority:1;)
alert http any any -> $HOME_NET any (msg:"CVE-2026-68558 - Wekan SSRF Webhook URL with Internal IP"; flow:established,to_server; http.uri; content:"169.254.169.254"; nocase; sid:202668582; rev:1; classtype:attempted-recon; reference:cve,2026-68558; priority:1;)
alert http any any -> $HOME_NET any (msg:"CVE-2026-68558 - Wekan SSRF Webhook URL with xip.io/sslip.io"; flow:established,to_server; http.uri; pcre:"/(\.xip\.io|\.sslip\.io)/i"; sid:202668583; rev:1; classtype:attempted-recon; reference:cve,2026-68558; priority:1;)

Elastic Detection

// EQL query for Elastic SIEM
// Detects Wekan webhook configuration events with IP addresses in the URL
sequence by host.name, process.pid
// Look for Wekan application log entries containing webhook integration actions
[any where event.category == "application" and 
 process.name == "node" and
 message : "*webhook*" and
 message : ("*169.254.169.254*", "*.nip.io*", "*.xip.io*", "*.sslip.io*", "http://10.*", "http://192.168.*")]

Splunk SPL Query

index=wekan OR index=main sourcetype=wekan:log
| search "webhook" AND ("integration" OR "configure" OR "create" OR "update")
| regex _raw="(http[s]?://)((\d{1,3}\.){3}\d{1,3}|[a-zA-Z0-9\-]+\.(nip\.io|xip\.io|sslip\.io))"
| eval suspicious = case(
    match(_raw, "169\.254\.169\.254") OR match(_raw, "169-254-169-254") OR 
    match(_raw, "10\.") OR match(_raw, "192\.168\.") OR 
    match(_raw, "172\.(1[6-9]|2[0-9]|3[01])\.") OR
    match(_raw, "\[::1\]") OR match(_raw, "\.nip\.io") OR 
    match(_raw, "\.xip\.io") OR match(_raw, "\.sslip\.io"), "CVE-2026-68558 Indicator", "Normal")
| where suspicious == "CVE-2026-68558 Indicator"
| table _time, host, user, source, _raw
| sort - _time

Wazuh OSSEC Rule

<group name="wekan,ssrf,">
  <rule id="100685" level="12">
    <decoded_as>json</decoded_as>
    <field name="event\.category">webhook</field>
    <field name="wekan\.integration\.url" type="pcre2">(?i)(\.nip\.io|\.xip\.io|\.sslip\.io|169\.254\.169\.254|169-254-169-254|http://10\.|http://192\.168\.|http://172\.(1[6-9]|2[0-9]|3[01])\.)</field>
    <description>Wekan webhook integration URL contains potential SSRF indicator (CVE-2026-68558)</description>
    <group>wekan,cve-2026-68558,ssrf,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Status: CVE-2026-68558 has a patch confidence score of 0/4 (UNPATCHED) — no patch evidence from any tracked source is available in the provided data. However, the NVD description explicitly states that version 9.74 fixes the issue by rewriting the SSRF guard in server/lib/ssrfGuard.js. It is strongly recommended to upgrade to Wekan 9.74 or later as the primary remediation step.

1. Immediate Mitigations (until the upgrade is performed):

• Restrict webhook integration permissions: If possible, limit the ability to configure or modify outgoing webhook integrations to only trusted administrator accounts. This raises the privilege requirement from PR:L to PR:H, substantially reducing the attack surface.
• Network segmentation: Place the Wekan server in a network segment with restricted egress traffic. Use firewall rules or security groups to block outbound traffic from the Wekan server to internal-only IP ranges and to the cloud metadata service IP (169.254.169.254). This provides defense-in-depth even if the application validation is bypassed.
• Deploy a Web Application Firewall (WAF) or reverse proxy: Add a WAF rule to block requests to URLs containing DNS rebinding domains (e.g., *.nip.io, *.xip.io, *.sslip.io) and requests containing internal IP literal representations.
• Disable webhook functionality entirely if not strictly required by the business.

2. Patch/Upgrade Steps:

• Upgrade Wekan to version 9.74 or later as soon as possible. The fix rewrites the SSRF guard to resolve all IP addresses (dns.lookup with all: true), validate every address through a shared blocklist, pin connections to the resolved IP, and block redirects.
• For containerized deployments (Docker), pull the latest Wekan image using docker pull wekan/wekan:latest (ensure the tag corresponds to ≥ 9.74) and redeploy.
• For manual installations, update the Meteor application code to the 9.74 release from the official Wekan GitHub repository.
• After upgrading, verify that the server/lib/ssrfGuard.js file contains the new resolution logic described in the NVD.

3. Long-Term Hardening:

• Regularly audit all configured webhook integrations for unexpected or unauthorized URLs.
• Monitor application logs for webhook configuration changes and outbound HTTP requests from the Wekan server to internal/cloud metadata IP addresses.
• Implement a structured SSRF prevention library (e.g., one that resolves and validates all IPs, supports both IPv4/IPv6, and blocks redirects) at the architectural level for all outbound HTTP requests in the application.
• Track the vendor's advisory (if/when officially released) for additional recommended hardening steps.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-68558 — Official NVD vulnerability record containing the description, CVSS vector, and CWE classification.
2. Wekan Official Project: https://github.com/wekan/wekan — Official source repository; version 9.74 contains the fix in server/lib/ssrfGuard.js.
3. Wekan Boards / GitHub Release Notes: https://github.com/wekan/wekan/releases — Release notes for version 9.74, which documents the SSRF guard overhaul.
4. MITRE ATT&CK Technique T1190: https://attack.mitre.org/techniques/T1190/ — Exploit Public-Facing Application, the technique mapped to this vulnerability.
5. CISA Known Exploited Vulnerabilities (KEV): https://www.cisa.gov/known-exploited-vulnerabilities-catalog — No entry for CVE-2026-68558 at the time of this report (confirmed NO in source data).

Threat Actor / ITW Evidence: No known threat actor campaigns or exploit-in-the-wild evidence are available for CVE-2026-68558 at the time of this report. The PoC/Exploit status is marked as "None," and these is no Nuclei template or public exploit code. The attack chain described in this report is inferred from the vulnerability class and technical details in the NVD description; it should be considered analytical assessment rather than confirmed exploitation activity.