Ruby/icalendar/2.10.2


Implements the iCalendar specification (RFC-5545) in Ruby. This allows for the generation and parsing of .ics files, which are used by a variety of calendaring applications.

https://rubygems.org/gems/icalendar
BSD-2-Clause OR GPL-3.0-only OR icalendar

2 Security Vulnerabilities

iCalendar has ICS injection via unsanitized URI property values

Published date: 2026-03-24T19:13:41Z
CVE: CVE-2026-33635
Links:

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:

require "icalendar/value"
require "icalendar/values/uri"

v = Icalendar::Values::Uri.new("https://a.example/ok\r\nATTENDEE:mailto:evil@example.com")
puts v.to_ical(Icalendar::Values::Text)

output:

;VALUE=URI:https://a.example/ok
ATTENDEE:mailto:evil@example.com

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.

Affected versions: ["2.12.1", "2.12.0", "2.11.2", "2.11.1", "2.11.0", "2.10.3", "2.10.2", "2.10.1", "2.10.0", "2.9.0", "2.8.0", "2.7.1", "2.7.0", "2.6.1", "2.6.0", "2.5.3", "2.5.2", "2.5.1", "2.5.0", "2.4.1", "2.4.0", "2.3.0", "2.2.2", "2.2.1", "2.2.0", "2.1.2", "2.1.1", "2.1.0", "2.0.1", "2.0.0"]
Secure versions: [0.95, 0.96, 0.96.1, 0.96.2, 0.96.3, 0.96.4, 0.97, 0.98, 1.0, 1.0.1, 1.0.2, 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.6, 1.2, 1.2.0, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.3.0, 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.5.0, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 2.0.0.beta.1, 2.0.0.beta.2, 2.12.2, 2.12.3, 2.12.4, 2.12.5, 2.13.0]
Recommendation: Update to version 2.13.0.

iCalendar has ICS injection via unsanitized URI property values

Published date: 2026-03-24
CVE: 2026-33635
CVSS V3: 4.3
Links:

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

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.

Affected versions: ["2.2.2", "2.2.0", "2.5.2", "2.1.2", "2.5.0", "2.3.0", "2.7.0", "2.2.1", "2.1.1", "2.5.3", "2.0.0", "2.1.0", "2.4.1", "2.6.0", "2.0.1", "2.4.0", "2.6.1", "2.5.1", "2.7.1", "2.8.0", "2.9.0", "2.10.0", "2.10.1", "2.10.2", "2.10.3", "2.11.0", "2.11.1", "2.11.2", "2.12.0", "2.12.1"]
Secure versions: [0.95, 0.96, 0.96.1, 0.96.2, 0.96.3, 0.96.4, 0.97, 0.98, 1.0, 1.0.1, 1.0.2, 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.6, 1.2, 1.2.0, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.3.0, 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.5.0, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 2.0.0.beta.1, 2.0.0.beta.2, 2.12.2, 2.12.3, 2.12.4, 2.12.5, 2.13.0]
Recommendation: Update to version 2.13.0.

73 Other Versions

Version License Security Released
1.2.3 UNKNOWN 2013-03-09 - 18:17 over 13 years
1.2.2 UNKNOWN 2013-02-16 - 15:04 over 13 years
1.2.1 UNKNOWN 2012-11-21 - 12:13 almost 14 years
1.2 UNKNOWN 2012-08-31 - 12:11 about 14 years
1.2.0 UNKNOWN 2012-08-31 - 12:13 about 14 years
1.1.6 UNKNOWN 2011-03-10 - 11:47 over 15 years
1.1.5 UNKNOWN 2010-06-21 - 13:31 over 16 years
1.1.4 UNKNOWN 2010-04-23 - 17:04 over 16 years
1.1.3 UNKNOWN 2010-03-15 - 12:38 over 16 years
1.1.2 UNKNOWN 2010-03-10 - 13:44 over 16 years
1.1.1 UNKNOWN 2010-03-06 - 12:54 over 16 years
1.1.0 UNKNOWN 2009-07-25 - 18:13 about 17 years
1.0.2 UNKNOWN 2009-07-25 - 18:13 about 17 years
1.0.1 UNKNOWN 2009-07-25 - 18:13 about 17 years
1.0 UNKNOWN 2009-07-25 - 18:13 about 17 years
0.98 UNKNOWN 2009-07-25 - 18:13 about 17 years
0.97 UNKNOWN 2009-07-25 - 18:13 about 17 years
0.96.4 UNKNOWN 2009-07-25 - 18:13 about 17 years
0.96.3 UNKNOWN 2009-07-25 - 18:13 about 17 years
0.96.2 UNKNOWN 2009-07-25 - 18:13 about 17 years
0.96.1 UNKNOWN 2009-07-25 - 18:13 about 17 years
0.96 UNKNOWN 2009-07-25 - 18:13 about 17 years
0.95 UNKNOWN 2009-07-25 - 18:13 about 17 years