<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 07 Oct 2026 19:41:52 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-277972</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-277972</link>
      <description>EUVD-2026-277972</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-277972</guid>
    </item>
    <item>
      <title>fkie_cve-2026-33635</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-33635</link>
      <description>&lt;p&gt;iCalendar is a Ruby library for dealing with iCalendar files in the iCalendar format defined by RFC-5545. Starting in version 2.0.0 and prior to version 2.12.2, .ics serialization does not properly sanitize URI property values, enabling ICS injection through attacker-controlled input, adding arbitrary calendar lines to the output. `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). 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. Version 2.12.2 contains a patch for the issue.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;iCalendar is a Ruby library for dealing with iCalendar files in the iCalendar format defined by RFC-5545. Starting in version 2.0.0 and prior to version 2.12.2, .ics serialization does not properly sanitize URI property values, enabling ICS injection through attacker-controlled input, adding arbitrary calendar lines to the output. `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). 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. Version 2.12.2 contains a patch for the issue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-33635</guid>
    </item>
    <item>
      <title>GHSA-pv9c-9mfh-hvxq — iCalendar has ICS injection via unsanitized URI property values</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-pv9c-9mfh-hvxq</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; RubyGems: icalendar&lt;/p&gt;
&lt;p&gt;### Summary
.ics serialization does not properly sanitize URI property values, enabling ICS injection through attacker-controlled input, adding arbitrary calendar lines to the output.&lt;/p&gt;
&lt;p&gt;### 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)&lt;/p&gt;
&lt;p&gt;Relevant code:
- `lib/icalendar/values/uri.rb:16`&lt;/p&gt;
&lt;p&gt;### PoC
Run the following with the library loaded:&lt;/p&gt;
&lt;p&gt;```ruby
require &amp;#34;icalendar/value&amp;#34;
require &amp;#34;icalendar/values/uri&amp;#34;&lt;/p&gt;
&lt;p&gt;v = Icalendar::Values::Uri.new(&amp;#34;https://a.example/ok\r\nATTENDEE:mailto:evil@example.com&amp;#34;)
puts v.to_ical(Icalendar::Values::Text)
```&lt;/p&gt;
&lt;p&gt;output:&lt;/p&gt;
&lt;p&gt;```text
;VALUE=URI:https://a.example/ok
ATTENDEE:mailto:evil@example.com
```&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;## Fix
Reject raw CR and LF characters in `URI`-typed values before serialization, or escape/encode them so they canno…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; RubyGems: icalendar&lt;/p&gt;
&lt;p&gt;### Summary
.ics serialization does not properly sanitize URI property values, enabling ICS injection through attacker-controlled input, adding arbitrary calendar lines to the output.&lt;/p&gt;
&lt;p&gt;### 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)&lt;/p&gt;
&lt;p&gt;Relevant code:
- `lib/icalendar/values/uri.rb:16`&lt;/p&gt;
&lt;p&gt;### PoC
Run the following with the library loaded:&lt;/p&gt;
&lt;p&gt;```ruby
require &amp;#34;icalendar/value&amp;#34;
require &amp;#34;icalendar/values/uri&amp;#34;&lt;/p&gt;
&lt;p&gt;v = Icalendar::Values::Uri.new(&amp;#34;https://a.example/ok\r\nATTENDEE:mailto:evil@example.com&amp;#34;)
puts v.to_ical(Icalendar::Values::Text)
```&lt;/p&gt;
&lt;p&gt;output:&lt;/p&gt;
&lt;p&gt;```text
;VALUE=URI:https://a.example/ok
ATTENDEE:mailto:evil@example.com
```&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;## Fix
Reject raw CR and LF characters in `URI`-typed values before serialization, or escape/encode them so they canno…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-pv9c-9mfh-hvxq</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-33635</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-33635</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:20.04:LTS: ruby-icalendar, Ubuntu:22.04:LTS: ruby-icalendar, Ubuntu:24.04:LTS: ruby-icalendar&lt;/p&gt;
&lt;p&gt;iCalendar is a Ruby library for dealing with iCalendar files in the iCalendar format defined by RFC-5545. Starting in version 2.0.0 and prior to version 2.12.2, .ics serialization does not properly sanitize URI property values, enabling ICS injection through attacker-controlled input, adding arbitrary calendar lines to the output. `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). 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. Version 2.12.2 contains a patch for the issue.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:20.04:LTS: ruby-icalendar, Ubuntu:22.04:LTS: ruby-icalendar, Ubuntu:24.04:LTS: ruby-icalendar&lt;/p&gt;
&lt;p&gt;iCalendar is a Ruby library for dealing with iCalendar files in the iCalendar format defined by RFC-5545. Starting in version 2.0.0 and prior to version 2.12.2, .ics serialization does not properly sanitize URI property values, enabling ICS injection through attacker-controlled input, adding arbitrary calendar lines to the output. `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). 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. Version 2.12.2 contains a patch for the issue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-33635</guid>
    </item>
  </channel>
</rss>
