<?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://vulnerability.circl.lu</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, 28 Sep 2026 19:19:05 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-82184</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-82184</link>
      <description>&lt;p&gt;The WPLP Cookie Consent  WordPress plugin before 4.4.2 does not have any authorisation or CSRF checks when storing visitor consent state, and the code that does so runs on every front-end page load, allowing unauthenticated attackers to overwrite a site-wide option with arbitrary data.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;The WPLP Cookie Consent  WordPress plugin before 4.4.2 does not have any authorisation or CSRF checks when storing visitor consent state, and the code that does so runs on every front-end page load, allowing unauthenticated attackers to overwrite a site-wide option with arbitrary data.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-82184</guid>
    </item>
    <item>
      <title>GHSA-rmf2-688x-24h9</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-rmf2-688x-24h9</link>
      <description>&lt;p&gt;The WPLP Cookie Consent  WordPress plugin before 4.4.2 does not have any authorisation or CSRF checks when storing visitor consent state, and the code that does so runs on every front-end page load, allowing unauthenticated attackers to overwrite a site-wide option with arbitrary data.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;The WPLP Cookie Consent  WordPress plugin before 4.4.2 does not have any authorisation or CSRF checks when storing visitor consent state, and the code that does so runs on every front-end page load, allowing unauthenticated attackers to overwrite a site-wide option with arbitrary data.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-rmf2-688x-24h9</guid>
    </item>
  </channel>
</rss>
