CVE-2026-30846: Wekan Information Disclosure Vulnerability

CVE-2026-30846 Overview

CVE-2026-30846 is an information disclosure vulnerability in Wekan, an open source kanban tool built with Meteor. The vulnerability exists in versions 8.31.0 through 8.33, where the globalwebhooks publication exposes all global webhook integrations—including sensitive URL and token fields—without performing any authentication check on the server side. Although the subscription is normally invoked from the admin settings page, the server-side publication has no access control, meaning any DDP (Distributed Data Protocol) client, including unauthenticated ones, can subscribe and receive the data.

Critical Impact

An unauthenticated attacker can retrieve global webhook URLs and authentication tokens, potentially enabling unauthorized use of those webhooks and access to connected external services.

Affected Products

• Wekan versions 8.31.0 through 8.33
• Wekan_project Wekan (all deployments using vulnerable versions)
• Self-hosted and cloud instances running affected versions

Discovery Timeline

• 2026-03-06 - CVE-2026-30846 published to NVD
• 2026-03-11 - Last updated in NVD database

Technical Details for CVE-2026-30846

Vulnerability Analysis

This vulnerability represents a classic case of missing authentication on a sensitive server-side publication. In Meteor applications, publications are server-side functions that control what data is sent to clients via the DDP protocol. The globalwebhooks publication in Wekan was designed to serve webhook configuration data to the admin settings interface, but the developers failed to implement proper access control checks on the server side.

The absence of authentication verification means that any client connecting to the Wekan DDP endpoint can subscribe to this publication and receive the full payload of global webhook data. This includes webhook URLs that may point to internal services or third-party integrations, as well as authentication tokens that could grant access to those external systems.

The vulnerability is classified under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) and CWE-306 (Missing Authentication for Critical Function), highlighting both the information disclosure aspect and the fundamental access control failure.

Root Cause

The root cause of this vulnerability is the absence of authentication and authorization checks in the server-side globalwebhooks publication function. While the client-side application restricts access to the admin settings page through UI controls, these restrictions are not enforced at the data layer. The publication function blindly returns all global webhook documents to any subscriber without verifying that the requesting user has administrative privileges or is even authenticated.

This pattern represents a common security anti-pattern in web applications where developers rely on client-side access controls without implementing corresponding server-side enforcement.

Attack Vector

The attack can be executed remotely over the network without requiring any authentication. An attacker can exploit this vulnerability by:

1. Connecting to the target Wekan instance's DDP endpoint
2. Subscribing to the globalwebhooks publication
3. Receiving the complete set of global webhook configurations including sensitive URLs and tokens
4. Using the extracted credentials to access or abuse connected external services

The vulnerability can be exploited using any DDP client library or custom implementation. Since DDP is a WebSocket-based protocol, the attacker simply needs network access to the Wekan instance. No user interaction is required, making this vulnerability particularly dangerous for publicly accessible Wekan deployments. For detailed technical analysis, refer to the GitHub Security Advisory GHSL-2026-037.

Detection Methods for CVE-2026-30846

Indicators of Compromise

• Unusual DDP subscription requests to the globalwebhooks publication from unauthenticated sessions
• WebSocket connections from unknown IP addresses requesting webhook-related publications
• Unexpected access patterns to webhook data outside of admin interface usage
• External services reporting unauthorized webhook invocations using leaked tokens

Detection Strategies

• Monitor DDP subscription logs for requests to sensitive publications from unauthenticated clients
• Implement network-level logging to track WebSocket connection patterns and subscription requests
• Review application logs for subscription patterns that don't correlate with admin user sessions
• Set up alerts for webhook endpoint access from unexpected sources

Monitoring Recommendations

• Enable detailed logging for Meteor DDP subscriptions, particularly for admin-related publications
• Implement real-time monitoring of webhook token usage in connected external services
• Configure SentinelOne Singularity to detect and alert on anomalous network patterns to Wekan instances
• Regularly audit webhook configurations for signs of unauthorized access or modification

How to Mitigate CVE-2026-30846

Immediate Actions Required

• Upgrade Wekan to version 8.34 or later immediately
• Rotate all global webhook tokens that may have been exposed
• Review external service access logs for any unauthorized webhook invocations
• Audit connected external services for signs of compromise via leaked webhook credentials

Patch Information

The vulnerability has been fixed in Wekan version 8.34. The fix implements proper authentication checks in the globalwebhooks publication to ensure only authorized administrators can access webhook configuration data. Organizations should upgrade immediately by following the GitHub Release v8.34 instructions. The specific code changes can be reviewed in the security commit.

Workarounds

• Restrict network access to Wekan instances using firewall rules or VPN requirements
• Place Wekan behind an authentication proxy that requires login before accessing the application
• Disable or remove global webhooks if not actively required until patching is complete
• Monitor and rotate webhook tokens regularly as a defensive measure

# Example: Restrict access to Wekan using iptables (Linux)
# Allow only trusted IP ranges to access Wekan port
iptables -A INPUT -p tcp --dport 3000 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 3000 -s 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -p tcp --dport 3000 -j DROP