CVE-2026-50167 in Kurrier
Summary
by MITRE • 08/18/2026
Kurrier is a modern, self-hosted workspace for email, calendar, contacts, and storage. Prior to 1.2.4, Kurrier API endpoints for listing and retrieving webhook and identity resources did not enforce ownership checks for authenticated API requests. An attacker with a valid API key could use another account's identifiers to read and enumerate webhook and identity resources belonging to that account through apps/worker/server/routes/api/kurrier/webhooks/[id].get.ts, apps/worker/server/routes/api/kurrier/webhooks/index.get.ts, apps/worker/server/routes/api/kurrier/identities/[id].get.ts, and apps/worker/server/routes/api/kurrier/identities/index.get.ts. Anonymous requests and invalid API keys were rejected, and cross-user modification operations were blocked, but affected GET and list operations could expose another user's resource metadata. This issue is fixed in version 1.2.4.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in Kurrier prior to version 1.2.4 represents a critical failure in access control logic within the application’s API layer, specifically affecting endpoints responsible for listing and retrieving webhook configurations and identity resources. As a modern self-hosted workspace solution integrating email, calendar, contacts, and storage capabilities, Kurrier relies heavily on robust authentication and authorization mechanisms to ensure data isolation between distinct user accounts. The flaw resides in specific server-side route handlers located at apps/worker/server/routes/api/kurrier/webhooks/[id].get.ts, apps/worker/server/routes/api/kurrier/webhooks/index.get.ts, apps/worker/server/routes/api/kurrier/identities/[id].get.ts, and apps/worker/server/routes/api/kurrier/identities/index.get.ts. These endpoints were designed to process authenticated API requests but failed to validate that the requesting user possessed ownership or explicit permission for the specific resource identifiers being accessed. This architectural oversight allows an attacker who has obtained a valid API key from one account to manipulate request parameters, substituting their own resource IDs with those belonging to other users within the same Kurrier instance.
From a technical perspective, this vulnerability is classified as Insecure Direct Object References (IDOR), corresponding to CWE-639 in the Common Weakness Enumeration standard. The core issue stems from the application’s reliance on client-supplied identifiers without performing server-side authorization checks against the authenticated user’s context. While the system correctly rejects anonymous requests and invalid API keys, ensuring that only legitimate users can interact with the API, it fails to enforce vertical or horizontal privilege separation during read operations. Consequently, an attacker possessing a low-privilege or standard user account can enumerate sensitive metadata associated with high-privilege accounts or other tenants by iterating through known or guessed resource IDs. This behavior aligns with MITRE ATT&CK technique T1078, Valid Accounts, as the exploitation requires valid credentials but leverages them to access unauthorized resources, and potentially T1592, Gather Victim Host Information, if the enumerated data reveals infrastructure details or configuration patterns that aid further reconnaissance.
The operational impact of this vulnerability is significant for organizations deploying Kurrier in multi-tenant environments or where strict data segregation between departments or users is required. Although cross-user modification operations such as creation, update, and deletion were correctly blocked by existing security controls, the ability to read and enumerate webhook endpoints exposes sensitive configuration details including endpoint URLs, secret tokens used for signing payloads, and event types being monitored. Similarly, exposure of identity resources may reveal user identifiers, authentication methods, or linked external services. This information leakage can facilitate more sophisticated attacks, such as crafting targeted phishing campaigns using known contact data, hijacking webhooks to intercept sensitive communications, or mapping the internal structure of an organization’s communication infrastructure. The lack of ownership verification effectively breaks the trust boundary between users, allowing for horizontal privilege escalation where a user gains access to resources belonging to peers at the same permission level.
Mitigation strategies primarily involve upgrading to Kurrier version 1.2.4 or later, which implements proper authorization checks ensuring that API requests are validated against the authenticated user’s ownership of the requested resource. For organizations unable to immediately patch due to operational constraints, temporary mitigations should focus on restricting network access to the Kurrier API endpoints using firewall rules or reverse proxy configurations, limiting exposure only to trusted IP ranges if possible. Additionally, implementing strict rate limiting and monitoring for unusual patterns in ID parameter usage can help detect enumeration attempts. It is also advisable to review logging mechanisms to ensure that all API requests are logged with sufficient detail to identify potential abuse of these endpoints post-exploitation or during incident response activities. Regular security audits focusing on access control logic across all RESTful interfaces are recommended to prevent similar flaws in other parts of the application stack.