<?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>Mon, 05 Oct 2026 14:19:59 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-285137</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-285137</link>
      <description>EUVD-2026-285137</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-285137</guid>
    </item>
    <item>
      <title>fkie_cve-2026-4394</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-4394</link>
      <description>&lt;p&gt;The Gravity Forms plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the Credit Card field&amp;#39;s &amp;#39;Card Type&amp;#39; sub-field (`input_&amp;lt;id&amp;gt;.4`) in all versions up to, and including, 2.9.30. This is due to the `get_value_entry_detail()` method in the `GF_Field_CreditCard` class outputting the card type value without escaping, combined with `get_value_save_entry()` accepting and storing unsanitized user input for the `input_&amp;lt;id&amp;gt;.4` parameter. The Card Type field is not rendered on the frontend form (it is normally derived from the card number), but the backend submission parser blindly accepts it if included in the POST request. This makes it possible for unauthenticated attackers to inject arbitrary web scripts that execute when an administrator views the form entry in the WordPress dashboard.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;The Gravity Forms plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the Credit Card field&amp;#39;s &amp;#39;Card Type&amp;#39; sub-field (`input_&amp;lt;id&amp;gt;.4`) in all versions up to, and including, 2.9.30. This is due to the `get_value_entry_detail()` method in the `GF_Field_CreditCard` class outputting the card type value without escaping, combined with `get_value_save_entry()` accepting and storing unsanitized user input for the `input_&amp;lt;id&amp;gt;.4` parameter. The Card Type field is not rendered on the frontend form (it is normally derived from the card number), but the backend submission parser blindly accepts it if included in the POST request. This makes it possible for unauthenticated attackers to inject arbitrary web scripts that execute when an administrator views the form entry in the WordPress dashboard.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-4394</guid>
    </item>
    <item>
      <title>GHSA-5pv5-mj98-fr8x</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-5pv5-mj98-fr8x</link>
      <description>&lt;p&gt;The Gravity Forms plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the Credit Card field&amp;#39;s &amp;#39;Card Type&amp;#39; sub-field (`input_&amp;lt;id&amp;gt;.4`) in all versions up to, and including, 2.9.30. This is due to the `get_value_entry_detail()` method in the `GF_Field_CreditCard` class outputting the card type value without escaping, combined with `get_value_save_entry()` accepting and storing unsanitized user input for the `input_&amp;lt;id&amp;gt;.4` parameter. The Card Type field is not rendered on the frontend form (it is normally derived from the card number), but the backend submission parser blindly accepts it if included in the POST request. This makes it possible for unauthenticated attackers to inject arbitrary web scripts that execute when an administrator views the form entry in the WordPress dashboard.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;The Gravity Forms plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the Credit Card field&amp;#39;s &amp;#39;Card Type&amp;#39; sub-field (`input_&amp;lt;id&amp;gt;.4`) in all versions up to, and including, 2.9.30. This is due to the `get_value_entry_detail()` method in the `GF_Field_CreditCard` class outputting the card type value without escaping, combined with `get_value_save_entry()` accepting and storing unsanitized user input for the `input_&amp;lt;id&amp;gt;.4` parameter. The Card Type field is not rendered on the frontend form (it is normally derived from the card number), but the backend submission parser blindly accepts it if included in the POST request. This makes it possible for unauthenticated attackers to inject arbitrary web scripts that execute when an administrator views the form entry in the WordPress dashboard.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-5pv5-mj98-fr8x</guid>
    </item>
  </channel>
</rss>
