CVE-2026-41455: WeKan SSRF Vulnerability

CVE-2026-41455 Overview

CVE-2026-41455 is a Server-Side Request Forgery (SSRF) vulnerability in WeKan before version 8.35 that exists in the webhook integration URL handling functionality. The vulnerability stems from the url schema field accepting any string without protocol restriction or destination validation. Attackers with the ability to create or modify integrations can exploit this flaw to set webhook URLs pointing to internal network addresses, causing the WeKan server to issue HTTP POST requests to attacker-controlled internal targets.

Critical Impact

Successful exploitation allows attackers to probe internal network services, exfiltrate sensitive board event payloads to internal targets, and exploit response handling to overwrite arbitrary comment text without proper authorization checks, potentially leading to data manipulation and internal network reconnaissance.

Affected Products

• WeKan versions prior to 8.35
• WeKan webhook integration module
• WeKan instances with integration creation permissions enabled for users

Discovery Timeline

• 2026-04-22 - CVE CVE-2026-41455 published to NVD
• 2026-04-23 - Last updated in NVD database

Technical Details for CVE-2026-41455

Vulnerability Analysis

This SSRF vulnerability exists in WeKan's webhook integration system within the models/integrations.js file. The vulnerable code path allowed users with integration creation or modification privileges to specify arbitrary URLs for webhook destinations without any validation of the URL scheme or target address. This meant that internal network addresses including private IP ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x), loopback addresses (127.0.0.1, ::1), and link-local addresses could be specified as webhook targets.

When board events occur, WeKan sends HTTP POST requests containing full board event payloads to the configured webhook URL. An attacker could leverage this to perform internal port scanning, access cloud metadata endpoints, interact with internal services not exposed to the public internet, and exfiltrate sensitive data contained in board events.

Additionally, the vulnerability includes a secondary impact where response handling from webhook requests could be exploited to overwrite arbitrary comment text without proper authorization checks, indicating a missing board admin verification in the authentication flow.

Root Cause

The root cause of CVE-2026-41455 is insufficient input validation on the webhook URL field in the integrations schema. The original implementation only performed basic URL format validation using a regex pattern but failed to implement critical security controls including protocol allowlisting (restricting to http/https only) and destination validation (blocking private, loopback, and link-local IP address ranges). The vulnerability is classified under CWE-918 (Server-Side Request Forgery).

Attack Vector

The attack vector is network-based and requires low privileges—specifically, the ability to create or modify webhook integrations within WeKan. An attacker would configure a webhook integration with a malicious internal URL target. When board events trigger webhook notifications, the WeKan server initiates HTTP POST requests to the attacker-specified internal destination, carrying sensitive board event data.

// Security patch in models/integrations.js - Fix IntegrationBleed.
       defaultValue: ['all'],
     },
     url: {
-      // URL validation regex (https://mathiasbynens.be/demo/url-regex)
+      // 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
        */
       type: String,
+      custom() {
+        try {
+          const u = new URL(this.value);
+
+          // Only allow http and https protocols
+          if (!['http:', 'https:'].includes(u.protocol)) {
+            return 'invalidProtocol';
+          }
+
+          // Block private/loopback IP ranges and hostnames
+          const hostname = u.hostname.toLowerCase();
+          const blockedPatterns = [
+            /^127\./, // 127.x.x.x (loopback)
+            /^10\./, // 10.x.x.x (private)
+            /^172\.(1[6-9]|2\d|3[01])\./, // 172.16-31.x.x (private)
+            /^192\.168\./, // 192.168.x.x (private)
+            /^0\./, // 0.x.x.x (current network)
+            /^::1$/, // IPv6 loopback
+            /^fe80:/, // IPv6 link-local
+            /^fc00:/, // IPv6 unique local

Source: GitHub Commit Update

The patch also adds board admin verification to prevent unauthorized comment manipulation:

// Security patch in server/authentication.js - Fix IntegrationBleed.
     await Authentication.checkAdminOrCondition(userId, writeAccess);
   };
 
+  // Helper function. Will throw an error if the user is not a board admin.
+  Authentication.checkBoardAdmin = async function(userId, boardId) {
+    Authentication.checkLoggedIn(userId);
+    const board = await ReactiveCache.getBoard(boardId);
+    const adminAccess = board.members.some(e => e.userId === userId && e.isActive && e.isAdmin);
+    await Authentication.checkAdminOrCondition(userId, adminAccess);
+  };
+
   if (Meteor.isServer) {
     if (
       process.env.ORACLE_OIM_ENABLED === 'true' ||

Source: GitHub Commit Update

Detection Methods for CVE-2026-41455

Indicators of Compromise

• Webhook integrations configured with internal IP addresses (10.x.x.x, 172.16-31.x.x, 192.168.x.x, 127.0.0.1)
• Webhook URLs pointing to localhost, cloud metadata endpoints (169.254.169.254), or non-standard protocols (file://, gopher://, dict://)
• Unexpected outbound HTTP POST requests from the WeKan server to internal network destinations
• Comment modifications without corresponding user actions in audit logs

Detection Strategies

• Monitor WeKan application logs for webhook creation or modification events containing internal IP addresses or suspicious hostnames
• Implement network monitoring to detect outbound HTTP requests from the WeKan server to internal RFC1918 address ranges
• Audit existing webhook integrations for URLs targeting internal network resources
• Review authentication logs for unauthorized comment modification attempts

Monitoring Recommendations

• Deploy egress filtering on the WeKan server to restrict outbound connections to approved external destinations only
• Implement alerting on webhook configuration changes, particularly those modifying URL destinations
• Monitor for anomalous patterns of outbound POST requests from the WeKan application server
• Enable detailed logging of all webhook execution events including target URLs and response codes

How to Mitigate CVE-2026-41455

Immediate Actions Required

• Upgrade WeKan to version 8.35 or later immediately
• Audit all existing webhook integrations and remove or disable any pointing to internal addresses
• Restrict integration creation permissions to trusted administrators only
• Implement network-level egress filtering to block outbound connections to internal IP ranges from the WeKan server

Patch Information

WeKan has released version 8.35 which addresses this vulnerability by implementing comprehensive URL validation including protocol allowlisting (http/https only) and blocking of private, loopback, and link-local IP address ranges. The patch is available through the GitHub Release v8.35. The security fix is contained in commit 2cd702f48df2b8aef0e7381685f8e089986a18a4. Additional technical details can be found in the VulnCheck Advisory: Wekan SSRF.

Workarounds

• Disable webhook integrations entirely if not required for business operations
• Implement a reverse proxy or web application firewall to filter outbound webhook requests and block internal destinations
• Restrict integration management permissions to only highly trusted administrators
• Deploy network segmentation to isolate the WeKan server from sensitive internal resources

# Configuration example - Network-level egress filtering using iptables
# Block outbound connections to private IP ranges from WeKan server

# Block RFC1918 private address ranges
iptables -A OUTPUT -d 10.0.0.0/8 -p tcp --dport 80 -j DROP
iptables -A OUTPUT -d 10.0.0.0/8 -p tcp --dport 443 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -p tcp --dport 80 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -p tcp --dport 443 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -p tcp --dport 80 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -p tcp --dport 443 -j DROP

# Block loopback (when coming from network namespace)
iptables -A OUTPUT -d 127.0.0.0/8 -p tcp --dport 80 -j DROP

# Block cloud metadata endpoint
iptables -A OUTPUT -d 169.254.169.254/32 -j DROP