icalendar EUVD-2026-84800

Requires: (1) the application uses icalendar 6.1.0-7.2.1; (2) the application accepts attacker-influenced iCalendar/.ics content containing a VALARM with a large REPEAT property; and (3) critically, the application must ACCESS the alarm properties - Alarms.times or Alarms.active (affected 6.1.0+) or Alarm.triggers (affected 7.0.0+). Parsing alone does NOT trigger the flaw, which meaningfully limits exposure to apps that expand/render alarm schedules. Authentication is not inherent to the vulnerability and depends on the host application's ingestion path (anonymous ICS import = unauthenticated; account-gated calendar upload = low-privilege). Before the fix there was no application-level cap on expansion, and REPEAT accepted values up to the RFC 5545 signed 32-bit maximum.

This is a genuine but bounded availability issue (CWE-400 resource exhaustion), not a code-execution flaw - the CVSS vector confirms A:H with C:N/I:N, so the only impact is DoS. The NVD vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H yields 6.5 (Medium). No EPSS score, no CISA KEV listing, and no public exploit code are present in the provided intelligence, so exploitation status is 'no public exploit identified at time of analysis' - DoS bugs in parsing libraries are rarely weaponized at scale and this reads as low real-world urgency. One nuance worth flagging: the vulnerability is a library-level flaw whose exposure depends entirely on the consuming application. Parsing an .ics file alone is safe; the exhaustion only fires when the application accesses Alarms.times, Alarms.active (6.1.0+) or Alarm.triggers (7.0.0+). NVD chose PR:L, but the flaw itself imposes no authentication requirement - whether an attacker needs an account is a property of the host application (e.g. a calendar service that requires login to upload events would be PR:L, while an anonymous ICS-import endpoint would be PR:N). Treat this as a patch-in-normal-cycle Medium rather than an emergency.

An attacker submits a crafted iCalendar (.ics) file containing a VALARM with an enormous REPEAT value (up to the RFC signed 32-bit max, ~2.1 billion) to an application that ingests calendars and then reads alarm/trigger times. When the app accesses Alarms.times/active or Alarm.triggers, the library eagerly expands billions of trigger datetimes, exhausting CPU and heap and stalling or killing the service. No public exploit code is identified, but the trigger is trivial to construct given the fix simply clamps the expansion count.