<?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 06:49:00 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-322593</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-322593</link>
      <description>EUVD-2026-322593</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-322593</guid>
    </item>
    <item>
      <title>fkie_cve-2026-41160</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-41160</link>
      <description>&lt;p&gt;EspoCRM is an open source customer relationship management application. Prior to 9.3.5, a business logic flaw (Broken Access Control) in EspoCRM 9.3.3 allows low-privileged users to pin arbitrary notes without having the required edit permissions for the parent object. Due to a &amp;#34;write first, authorize later&amp;#34; execution flaw in the backend API, even though the server correctly returns a 403 Forbidden error, the targeted note&amp;#39;s pinned status is already persistently modified in the database. The root cause lies in the server-side processing of the POST /api/v1/Note/{id}/pin endpoint. In application/Espo/Tools/Stream/Api/PostNotePin.php, the process() method first calls getNote($id) before calling checkParent($note). This vulnerability is fixed in 9.3.5.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;EspoCRM is an open source customer relationship management application. Prior to 9.3.5, a business logic flaw (Broken Access Control) in EspoCRM 9.3.3 allows low-privileged users to pin arbitrary notes without having the required edit permissions for the parent object. Due to a &amp;#34;write first, authorize later&amp;#34; execution flaw in the backend API, even though the server correctly returns a 403 Forbidden error, the targeted note&amp;#39;s pinned status is already persistently modified in the database. The root cause lies in the server-side processing of the POST /api/v1/Note/{id}/pin endpoint. In application/Espo/Tools/Stream/Api/PostNotePin.php, the process() method first calls getNote($id) before calling checkParent($note). This vulnerability is fixed in 9.3.5.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-41160</guid>
    </item>
  </channel>
</rss>
