~ / search / GHSA-pv9c-9mfh-hvxq

GHSA-pv9c-9mfh-hvxq

iCalendar has ICS injection via unsanitized URI property values

Source: GitHub Advisory Database (reviewed) Moderate CVE-2026-33635

Packages

EcosystemPackageAffectedFixed in
RubyGems icalendar >= 2.0.0, < 2.12.2 2.12.2

Details

As written in the advisory (Markdown source, shown as plain text).

### Summary .ics serialization does not properly sanitize URI property values, enabling ICS injection through attacker-controlled input, adding arbitrary calendar lines to the output. ### Details `Icalendar::Values::Uri` falls back to the raw input string when `URI.parse` fails and later serializes it with `value.to_s` without removing or escaping `\r` or `\n` characters. That value is embedded directly into the final ICS line by the normal serializer, so a payload containing CRLF can terminate the original property and create a new ICS property or component. (It looks like you can inject via url, source, image, organizer, attach, attendee, conference, tzurl because of this) Relevant code: - `lib/icalendar/values/uri.rb:16` ### PoC Run the following with the library loaded: ```ruby require "icalendar/value" require "icalendar/values/uri" v = Icalendar::Values::Uri.new("https://a.example/ok\r\nATTENDEE:mailto:[email protected]") puts v.to_ical(Icalendar::Values::Text) ``` output: ```text ;VALUE=URI:https://a.example/ok ATTENDEE:mailto:[email protected] ``` ### Impact Applications that generate `.ics` files from partially untrusted metadata are impacted. As a result, downstream calendar clients or importers may process attacker-supplied content as if it were legitimate event data, such as added attendees, modified URLs, alarms, or other calendar fields. ## Fix Reject raw CR and LF characters in `URI`-typed values before serialization, or escape/encode them so they cannot terminate the current ICS content line.

References

External links from the advisory. They lead to third-party sites.