<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-30T23:20:58.107157+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/fkie_cve-2026-45414</id>
    <title>fkie_cve-2026-45414</title>
    <updated>2026-09-30T23:20:59.434483+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Decidim is a participatory democracy framework. Prior to 0.31.5 and in 0.32.0.rc1 before 0.32.0.rc2, JWT-backed API authentication is not bound to the organization selected by the current host, allowing a JWT issued for one tenant to be replayed against another tenant’s API to read participantDetails data and reach the proposal.answer mutation path. This issue is fixed in versions 0.31.5 and 0.32.0.rc2.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-45414"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-r3v7-5x4c-c69q</id>
    <title>GHSA-r3v7-5x4c-c69q — Decidim: JWT-backed authentication can be replayed across organizations</title>
    <updated>2026-09-30T23:20:59.434693+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> RubyGems: decidim</p>
<p>## Description</p>
<p>A JWT issued to an Org 1 account is accepted on the Org 2 API and can read the admin-only GraphQL `participantDetails` field for an Org 2 participant. The same trust-boundary problem also affects API-user authentication: an Org 1 API user can use a JWT on the Org 1 host and replay that JWT to the Org 2 API to read Org 2 participant personal data and reach Org 2's `proposal.answer` mutation path.</p>
<p>##  Technical description</p>
<p>The current host selects the Decidim organization context, but JWT-backed API authentication is not sufficiently bound to
that host organization. As a result, the API can process a request in Org 2's context while still trusting an authenticated
principal from Org 1.</p>
<p>Reproduction steps:</p>
<p>1. Use an API key provided by the system administrator that is assigned to organization 1 to create the JWT token or
get the JWT token shown in the response when logged in as the organization admin.</p>
<p>&lt;img width="1080" height="1119" alt="decidim-jwt-01" src="https://github.com/user-attachments/assets/6195a250-faef-41d5-8f64-4d77d4077e96" /&gt;</p>
<p>2. When using this JWT token it is possible to retrieve details from other organisations. Notice the change of the host header in the request below to that of another tenant `org2.localhost:3001`
 
&lt;img width="1085" height="1047" alt="decidim-jwt-02" src="https://github.com/user-attachments/assets/d40825e3-0d36-44f3-bede-86d247bbe6d0" /&gt;</p>
<p>Note that using a participant-generated JWT did not allow showing these results.…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-r3v7-5x4c-c69q"/>
  </entry>
</feed>
