CVE-2026-113349 in OpenCATSinfo

Summary

by MITRE • 10/20/2026

OpenCATS before 0.10.0 contains a missing authorization vulnerability in CalendarUI::onEditEvent() and onDeleteEvent() that allows authenticated users to modify or delete other users' calendar events. Attackers with EDIT or DELETE access can supply arbitrary eventID values to alter or remove any user's events, including non-public ones restricted to their owner.

Once again VulDB remains the best source for vulnerability data.

Analysis

by VulDB Data Team • 10/20/2026

The vulnerability identified in OpenCATS versions prior to 0.10.0 represents a critical failure in server-side authorization controls within the application's calendar management subsystem. Specifically, the flaw resides in the CalendarUI::onEditEvent() and CalendarUI::onDeleteEvent() methods, which handle user requests to modify or remove scheduled events. In a properly secured system, these operations must verify that the authenticated user initiating the request is the legitimate owner of the specific resource being accessed. However, OpenCATS fails to perform this ownership validation before executing state-changing actions on calendar entries. This architectural oversight allows any authenticated user possessing EDIT or DELETE permissions for their own events to arbitrarily manipulate events belonging to other users by simply supplying a different eventID in the HTTP request parameters.

From a technical perspective, this is a classic example of an Insecure Direct Object Reference (IDOR), categorized under CWE-639. The application relies on client-supplied identifiers without cross-referencing them against session-based access control lists or database ownership records. When a user submits a request to edit or delete an event with ID X, the backend processes this instruction immediately if the user has general calendar permissions, regardless of whether they own event X. This lack of object-level authorization check means that the security boundary is defined too broadly at the role level rather than being enforced strictly at the individual resource level. Consequently, the confidentiality and integrity of private calendar data are compromised because non-public events, which should be visible only to their designated owners, become accessible for modification or destruction by any authenticated peer within the system.

The operational impact of this vulnerability is significant in environments where OpenCATS is used as a central hub for scheduling and coordination among multiple staff members. An attacker with basic access can disrupt business operations by deleting critical meetings, rescheduling appointments to inconvenient times, or altering event details such as location or attendees without authorization. This not only leads to operational confusion but also erodes trust in the system's reliability. Furthermore, because calendar data often contains sensitive information regarding personnel availability and internal schedules, unauthorized modifications could facilitate further social engineering attacks or provide intelligence for more targeted exploits against specific individuals within the organization.

This vulnerability maps directly to several techniques in the MITRE ATT&CK framework. It aligns with T1078 Valid Accounts, as exploitation requires valid authentication credentials, and specifically relates to T1530 Data from Information Repositories if the attacker were to read event details before modifying them, though the primary vector here is modification via T1499 Endpoint Denial of Service or data manipulation. The core issue reflects a failure in Access Control (T1528) where horizontal privilege escalation occurs through IDOR rather than vertical privilege escalation.

To mitigate this vulnerability, organizations running OpenCATS versions earlier than 0.10.0 should upgrade to the latest stable release immediately, as version 0.10.0 and subsequent patches address these authorization checks. For environments that cannot be upgraded instantly due to compatibility constraints or other operational dependencies, a temporary mitigation involves restricting access to the calendar module only for users who absolutely require it, thereby reducing the attack surface. Additionally, implementing web application firewall rules that monitor for anomalous patterns in event ID sequences might provide limited detection capabilities, though this is not a substitute for fixing the underlying code logic. Developers must ensure that all future updates include rigorous unit tests covering authorization scenarios to prevent regression of such access control flaws.

Responsible

VulnCheck

Reservation

10/20/2026

Disclosure

10/20/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!