CVE-2026-77399 in icalendar
Summary
by MITRE • 09/22/2026
icalendar is an RFC 5545 compatible parser and generator of iCalendar files for Python. From 6.1.0 until 7.2.2, vInt.from_ical accepts an attacker-controlled VALARM REPEAT value and applications that request alarm times can eagerly expand it without an application-level limit. Alarms.times and Alarms.active reach the unbounded expansion in versions starting with 6.1.0, while Alarm.triggers adds a second affected path starting with 7.0.0. Parsing alone does not trigger the issue, but accessing these properties can consume excessive CPU time and heap memory and terminate or stall a service. This issue is fixed in version 7.2.2.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified within the Pythonicalendar library represents a significant resource exhaustion risk stemming from improper validation of input data during the processing of iCalendar files. Specifically, versions ranging from6.1.0 through7.2.2 are susceptible to this flaw because they fail to enforce application-level limits on the expansion of alarm repeat values defined in accordance with RFC5545. The core technical issue lies within the vInt.from_ical method which accepts attacker-controlled VALARM REPEAT parameters without sufficient bounds checking. When an iCalendar file containing a maliciously crafted repetition count is parsed, the library does not immediately trigger the vulnerability during the initial parsing phase; rather, the exploitability arises when specific properties such as Alarms.times or Alarms.active are accessed by the consuming application. These property accessors attempt to eagerly expand the alarm schedule based on the provided repeat value, leading to an unbounded expansion of data structures in memory and excessive CPU consumption due to iterative calculations required to determine each individual alarm occurrence.
The operational impact of this vulnerability is severe for any service that processes iCalendar files and subsequently accesses these specific alarm properties. An attacker can craft a specially designed iCalendar file with an extremely large REPEAT value, causing the application to enter an infinite or near-infinite loop while attempting to calculate all future alarms up to the specified count. This behavior results in a denial of service condition characterized by high CPU utilization and rapid heap memory exhaustion. In many cases, this resource consumption leads to the termination of the process due out-of-memory errors or causes the service to stall completely, rendering it unresponsive to legitimate requests. The vulnerability affects two distinct code paths depending on the library version; versions starting from6.1.0 are impacted through the Alarms.times and Alarms.active properties, while a secondary affected path was introduced in7.0.0 via the Alarm.triggers property, broadening the attack surface for applications utilizing newer features of the library.
From a classification perspective, this vulnerability aligns with CWE-400 which describes uncontrolled resource consumption, as well as CWE-1321 which pertains to improper control of iteration counts. In terms of adversarial tactics, this flaw can be leveraged within an ATT&CK framework context under techniques related to Resource Hijacking or Denial of Service, where the attacker aims to degrade service availability by exhausting computational resources rather than compromising confidentiality or integrity directly. The lack of input validation on numerical parameters that drive iterative processes is a common pattern in parser vulnerabilities and highlights the necessity for strict bounds checking when handling external data inputs that influence internal loop structures.
To mitigate this vulnerability, organizations must ensure that all instances of theicalendar library are upgraded to version7.2.2 or later where these limits have been properly implemented. For environments unable to upgrade immediately, defensive coding practices should be adopted within the application layer by implementing custom validation logic before accessing alarm properties. This includes verifying that any repeat values derived from iCalendar files fall within expected operational bounds and rejecting inputs with excessively high repetition counts. Additionally, developers should consider wrapping property access in try-except blocks or using timeout mechanisms to prevent long-running calculations from blocking critical threads. Regular security audits of third-party dependencies are essential to identify similar patterns where external data influences internal resource allocation without adequate safeguards against abuse.