Security Audit

A spec-valid MONTHLY rule with a signed or lowercase BYDAY value (for example FREQ=MONTHLY;BYDAY=+1MO) was parsed but not recognised by the expansion engines, so the weekday search never terminated. Any expansion path, including events imported from an ICS feed, could block the process indefinitely.

• +Fixed in v2.5.3: BYDAY values are canonicalised and validated at parse time; unknown weekdays are rejected with an error
• +Every weekday search loop in both engines is bounded to seven iterations
• +Regression test expands the affected rule forms inside a child process with a time budget

The ICS feed URL guard only understood dotted IPv4 literals and a few IPv6 prefixes. IPv4-mapped IPv6 literals in hexadecimal form, NAT64 addresses and other embedded-IPv4 forms passed validation, and hosts containing a colon skipped the DNS re-check, so importFromURL and subscribe could reach loopback, link-local and other internal addresses.

• +Fixed in v2.5.3: IPv6 literals are parsed in full and judged by the address they denote; mapped, compatible, translated, NAT64 and 6to4 forms are checked as the embedded IPv4 address
• +Loopback, unspecified, link-local, unique-local, site-local, multicast and documentation ranges are refused; unparseable literals fail closed
• +DNS re-check now runs for every non-literal host in Node; redirect targets are validated and their bodies discarded when rejected
• +Known limitation: the DNS-rebinding window between the lookup and the request remains (closing it needs a custom network agent, which conflicts with the zero-dependency constraint)

The ICS parser processes external .ics files, which are untrusted input by definition. It previously lacked input size limits, which could allow denial of service via crafted files.

• +Fixed in v2.1.21: configurable size limits with safe defaults
• +Maximum input size, line count, and event count enforced
• +Parser is read-only; it cannot execute code or modify system state

The ICS fetching mechanism previously accepted URLs pointing to internal network resources. In server-side contexts this created a Server-Side Request Forgery vector.

• +Fixed in v2.1.21: URL validation against private and internal IP ranges
• +Scheme allowlisting restricts fetches to http and https
• +Client-side usage is additionally mitigated by the browser same-origin policy

The Web Components interface layer renders event data into the DOM. Renderers previously inserted content via innerHTML without escaping, creating a cross-site scripting vector when event data contained untrusted input.

• +Fixed: all user-controlled values are escaped before template interpolation
• +Hardened further in v1.0.60: parseHTML() sanitizes by default, stripping script-capable elements, inline handlers, and javascript: URLs
• +The core library is entirely DOM-free and not affected

The recurrence expansion engine processes RFC 5545 RRULE patterns. It previously lacked hard limits on occurrence count, which could cause excessive computation via an algorithmic-complexity attack.

• +Fixed in v2.1.21: hard cap on maxOccurrences prevents unbounded expansion
• +Expansion is CPU-bound only; no I/O or network side effects
• +Can be further isolated in a Web Worker (already supported)

The email validation regex used for organizer and attendee fields was vulnerable to Regular Expression Denial of Service. Crafted input could cause catastrophic backtracking and block the main thread.

• +Fixed in v2.1.22: replaced the vulnerable regex with linear-time validation
• +The new check has O(n) worst-case complexity
• +Affects ICS parsing of ORGANIZER and ATTENDEE fields with mailto: URIs

GitHub Actions workflows were using default (write-all) permissions, granting more access than necessary. Overly permissive workflows can be exploited if a dependency or action is compromised.

• +Fixed: explicit least-privilege permissions blocks on all workflows
• +Read-only default with scoped write access only where required
• +Follows GitHub's recommended security hardening for Actions