CVE-2026-33635

What it actually does

The flaw is an improper input validation issue in the Ruby iCalendar library versions 2.0.0 through versions before 2.12.2. When serializing URI-based iCalendar properties, the library may fall back to the raw attacker-supplied string if URI parsing fails, then write that value into the generated .ics output without removing or escaping carriage return and line feed characters. An attacker who can influence fields such as URL, source, image, organizer, attach, attendee, conference, or tzurl can inject CRLF sequences that terminate the intended property and add new iCalendar lines or components. The resulting .ics file may contain attacker-controlled calendar properties such as additional attendees, modified links, attachments, alarms, or other event metadata that downstream calendar clients treat as legitimate.

Why it matters to the business

Applications that generate calendar invitations or .ics downloads from user-supplied or partner-supplied metadata can produce tampered calendar files. The most likely impact is integrity loss: recipients may see altered event details, malicious links, unexpected attendees, or unwanted reminders that appear to come from a trusted workflow. This can support phishing, social engineering, data leakage through unintended attendee additions, or operational disruption through misleading calendar content. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV, but exposure can be broad where the library is embedded in event scheduling, booking, ticketing, collaboration, or notification systems.

How an attack unfolds

An attacker first identifies an application feature that accepts data later embedded into an .ics file, such as an event URL, conference link, image URL, organizer address, attachment reference, attendee value, or source field. They submit a crafted URI value that contains CRLF characters, often URL-encoded in transit, followed by additional iCalendar syntax. When the application uses a vulnerable iCalendar version to serialize the event, URI parsing fails or preserves the raw value, and the serializer writes the embedded line break characters into the output. The injected line break ends the original property and starts attacker-controlled properties or components. When a recipient imports or opens the generated .ics file, their calendar client processes the injected content as part of the event, potentially displaying attacker-chosen links, attendees, alarms, attachments, or modified metadata.

How to fix it

Upgrade the iCalendar Ruby gem to version 2.12.2 or later wherever it is used. If immediate upgrade is not possible, apply compensating controls before serialization: reject or normalize CR and LF characters in all fields that can become iCalendar property values, especially URI-backed fields; strictly validate URI schemes and formats; canonicalize percent-encoded input before validation; and avoid passing partially trusted raw strings directly into calendar properties. Regenerate affected build artifacts or containers after dependency updates, and ensure dependency lockfiles are updated so deployments do not continue using a vulnerable transitive or pinned version.

How to confirm the fix worked

Confirm dependency inventories, lockfiles, container images, and deployed runtime packages show iCalendar gem version 2.12.2 or later. Test calendar generation paths by submitting URI-like values containing CRLF sequences, including encoded forms such as %0D%0A and %0A, and verify generated .ics output does not contain attacker-created standalone lines. Inspect generated .ics files to ensure suspicious submitted values are escaped, rejected, or folded safely and cannot create new properties such as ATTENDEE, URL, ATTACH, TRIGGER, or BEGIN:VALARM. Run software composition analysis across repositories and deployed artifacts to find vulnerable versions before 2.12.2.

Typical attack path

1. Find an application endpoint or workflow that generates .ics calendar output using attacker-influenced event metadata.
2. Identify URI-backed fields accepted by the application, such as URL, source, image, organizer, attach, attendee, conference, or tzurl.
3. Submit a crafted value containing carriage return and line feed characters followed by valid iCalendar property lines.
4. Trigger generation, download, email delivery, or calendar feed publication of the .ics content.
5. Rely on the vulnerable serializer to embed the raw CRLF-containing value into the output without escaping it.
6. Cause downstream calendar clients or importers to interpret injected lines as legitimate event data.

How to detect it

To determine whether exploitation already occurred, review application access logs, API gateway logs, web server logs, and request bodies for calendar creation or update endpoints containing CRLF injection attempts, especially encoded sequences such as %0D%0A, %0A, or %0D in URI-like parameters. Inspect generated .ics files, outbound calendar email attachments, object storage buckets, and calendar feed outputs for unexpected property lines immediately after URL-like fields. Pay particular attention to inserted ATTENDEE, ORGANIZER, ATTACH, URL, CONFERENCE, BEGIN:VALARM, TRIGGER, ACTION, DESCRIPTION, LOCATION, or END/BEGIN component lines that were not produced by normal application logic. Review application error logs for URI parsing failures near calendar generation activity. If available, compare stored event metadata with the final serialized .ics output to identify properties present only in the generated file. Because exploitation may not create a server-side compromise, detection should focus on tampered calendar content and malicious input patterns rather than host malware artifacts.

• %0D%0AATTENDEE:
• %0AATTENDEE:
• %0D%0AORGANIZER:
• %0AORGANIZER:
• %0D%0AATTACH:
• %0AATTACH:
• %0D%0AURL:
• %0AURL:
• %0D%0ACONFERENCE:
• %0A CONFERENCE:
• %0D%0ABEGIN:VALARM
• %0A BEGIN:VALARM
• %0D%0ATRIGGER:
• %0A TRIGGER:
• %0D%0AACTION:
• %0A ACTION:
• \r\nATTENDEE:
• \nATTENDEE:
• \r\nBEGIN:VALARM
• \nBEGIN:VALARM
• BEGIN:VALARM
• TRIGGER:
• ACTION:DISPLAY
• ATTACH:http://
• ATTACH:https://

What your security team should do

• Prioritize upgrading the Ruby iCalendar gem to 2.12.2 or later in all applications that generate .ics files, calendar feeds, or calendar email attachments.
• Search source code for iCalendar generation paths that use untrusted or semi-trusted input in URI-like fields such as url, source, image, organizer, attach, attendee, conference, and tzurl.
• Add application-level validation that rejects CR, LF, and encoded CRLF sequences in calendar metadata before it reaches serialization.
• Review recent generated .ics files and calendar-related request logs for injected iCalendar properties following user-controlled URI values.
• Add regression tests that attempt CRLF injection into every calendar metadata field accepted by the application.
• If calendar files are emailed externally, coordinate with mail and SOC teams to monitor for suspicious .ics attachments containing unexpected alarms, attendees, links, or attachments.