<?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://db.gcve.eu</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, 30 Sep 2026 08:11:19 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-76901 — CordysCRM: Broken object-level authorization in lead pool and account pool detail endpoints exposes arbitrary leads and…</title>
      <link>https://db.gcve.eu/vuln/cve-2026-76901</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 1Panel-dev CordysCRM&lt;/p&gt;
&lt;p&gt;CordysCRM is an open source AI-powered customer relationship management system that supports private deployment. Prior to 1.7.4, GET /pool/lead/get/{id} in PoolClueController.get and GET /pool/account/get/{id} in PoolCustomerController.get use bare pool-read permission checks without the CsPermission resourceId binding that enforces per-record data scope. An authenticated user with the ordinary CLUE_MANAGEMENT_POOL:READ or CUSTOMER_MANAGEMENT_POOL:READ permission can supply another record&amp;#39;s id and cause unscoped primary-key getters to return leads or accounts owned by other users, departments, or organizations. Exposed data includes contact names, phone numbers, owner and department attribution, and custom field values. This issue is fixed in version 1.7.4.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 1Panel-dev CordysCRM&lt;/p&gt;
&lt;p&gt;CordysCRM is an open source AI-powered customer relationship management system that supports private deployment. Prior to 1.7.4, GET /pool/lead/get/{id} in PoolClueController.get and GET /pool/account/get/{id} in PoolCustomerController.get use bare pool-read permission checks without the CsPermission resourceId binding that enforces per-record data scope. An authenticated user with the ordinary CLUE_MANAGEMENT_POOL:READ or CUSTOMER_MANAGEMENT_POOL:READ permission can supply another record&amp;#39;s id and cause unscoped primary-key getters to return leads or accounts owned by other users, departments, or organizations. Exposed data includes contact names, phone numbers, owner and department attribution, and custom field values. This issue is fixed in version 1.7.4.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-76901</guid>
    </item>
  </channel>
</rss>
