CVE-2026-123504 in Vikunja
Summary
by MITRE • 11/08/2026
Vikunja from 0.22.0 before 2.7.1 contains an information disclosure vulnerability that allows read-only project members to view full webhook target URLs by listing project webhooks. Attackers can extract incoming-webhook tokens or API keys embedded in target_url values to post to receiving channels or reuse keys until rotated.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/08/2026
The vulnerability identified in Vikunja versions prior to 2.7.1 represents a significant information disclosure flaw rooted in insufficient access control mechanisms within the project webhook management subsystem. Specifically, the application fails to enforce proper authorization checks when retrieving the list of webhooks associated with a given project. While the system correctly restricts write operations and sensitive configuration changes for read-only users, it inadvertently exposes the full payload of webhook configurations during retrieval requests. This architectural oversight allows any user assigned the role of read-only member on a project to access detailed metadata that is intended only for administrators or members with higher privilege levels who are responsible for managing integrations.
From a technical perspective, the core issue lies in how the API endpoint handling webhook listings processes and returns data objects. When an authenticated user requests the list of webhooks for a specific project, the backend service constructs response objects that include all fields defined in the webhook model without filtering out sensitive components based on the caller's role. Consequently, the target_url field is returned in its entirety rather than being masked or truncated to hide embedded credentials. This behavior violates the principle of least privilege and fails to implement proper data sanitization for non-administrative roles, leading directly to the exposure of confidential configuration details that should remain restricted.
The operational impact of this vulnerability is severe due to the nature of webhook integrations commonly used in project management tools like Vikunja. Webhooks frequently utilize target URLs that contain authentication tokens, API keys, or other secrets as query parameters or path segments to authenticate with downstream services such as Slack, Discord, Microsoft Teams, or custom internal APIs. An attacker leveraging this flaw can extract these incoming webhook tokens or API keys directly from the exposed URL strings. Once obtained, these credentials allow the attacker to impersonate the legitimate integration endpoint. This capability enables unauthorized posting of messages to receiving channels, potentially causing social engineering attacks, spreading misinformation, or disrupting team communications by flooding channels with spam or malicious content.
Furthermore, the reuse of extracted API keys poses a persistent risk until they are manually rotated by an administrator. During this window of exposure, attackers can perform reconnaissance on downstream services if the tokens grant broader access than just posting messages. They may also attempt to exploit any additional functionality exposed through those APIs, such as deleting posts or modifying channel settings depending on the permissions granted to the webhook token. The lack of immediate detection mechanisms means that unauthorized activity driven by these stolen credentials could persist for an extended period, complicating forensic analysis and incident response efforts.
To mitigate this vulnerability, organizations running Vikunja must upgrade immediately to version 2.7.1 or later where the access control logic has been corrected to filter sensitive fields from webhook responses based on user role. In environments where upgrading is not immediately feasible, administrators should rotate all existing webhook tokens and API keys associated with affected projects as a precautionary measure. Additionally, implementing strict logging and monitoring for webhook usage can help detect anomalous activity resulting from compromised credentials. From a broader security architecture perspective, this incident highlights the importance of applying CWE-200 Improper Information Disclosure and ensuring that authorization checks are applied consistently across all data retrieval operations, not just modification ones, to prevent similar leaks in other modules.