<?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>Tue, 29 Sep 2026 11:46:04 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-57148</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-57148</link>
      <description>&lt;p&gt;PraisonAI is a multi-agent teams system. Prior to 0.1.6, praisonai_platform/services/auth_service.py falls back to the public dev-secret-change-me HS256 signing key when PLATFORM_JWT_SECRET is unset, while the startup and token-issuance guards are disabled because PLATFORM_ENV also defaults to dev. An unauthenticated attacker can sign a JWT containing an attacker-chosen sub value, and AuthService._verify_token() accepts it as an authenticated identity, enabling user or workspace-owner impersonation when a target identifier is known. This vulnerability is fixed in praisonai-platform 0.1.6.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;PraisonAI is a multi-agent teams system. Prior to 0.1.6, praisonai_platform/services/auth_service.py falls back to the public dev-secret-change-me HS256 signing key when PLATFORM_JWT_SECRET is unset, while the startup and token-issuance guards are disabled because PLATFORM_ENV also defaults to dev. An unauthenticated attacker can sign a JWT containing an attacker-chosen sub value, and AuthService._verify_token() accepts it as an authenticated identity, enabling user or workspace-owner impersonation when a target identifier is known. This vulnerability is fixed in praisonai-platform 0.1.6.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-57148</guid>
    </item>
    <item>
      <title>GHSA-f38v-77qj-h4jq — praisonai-platform 0.1.4 still boots on the hardcoded JWT secret dev-secret-change-me (default-open production guard)</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-f38v-77qj-h4jq</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: praisonai-platform&lt;/p&gt;
&lt;p&gt;- Affected: praisonai-platform (PyPI) &amp;lt;= 0.1.4 — including 0.1.4, the version GHSA-3qg8-5g3r-79v5 declares as the patch; main HEAD 8acf77c531e624c46d3d61dcae37e9942e90972c is also affected. File src/praisonai-platform/praisonai_platform/services/auth_service.py&lt;/p&gt;
&lt;p&gt;- CWE: CWE-1188 (Insecure Default Initialization) + CWE-798 (Use of Hard-coded Credentials) -&amp;gt; CWE-287 (Improper Authentication)&lt;/p&gt;
&lt;p&gt;## Overview&lt;/p&gt;
&lt;p&gt;GHSA-3qg8-5g3r-79v5 (Critical) reported that praisonai-platform&amp;#39;s JWT signing secret defaulted to the hardcoded literal &amp;#34;dev-secret-change-me&amp;#34;, and that the production guard meant to prevent this was default-open (it only fired when PLATFORM_ENV != &amp;#34;dev&amp;#34;, but PLATFORM_ENV defaults to &amp;#34;dev&amp;#34;). That advisory declares the issue patched in &amp;gt;= 0.1.4. **It is not.** The shipped praisonai-platform==0.1.4 (and current main) still resolves the signing key to &amp;#34;dev-secret-change-me&amp;#34; in any deployment that does not explicitly set PLATFORM_JWT_SECRET, because the 0.1.4 change merely duplicated the same default-open guard into a second function instead of failing closed. An unauthenticated attacker reads the literal from the public source, forges a JWT with an arbitrary sub, and is authenticated as that user — including a workspace owner.&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;Any deployment that runs praisonai-platform 0.1.4 without explicitly exporting a strong PLATFORM_JWT_SECRET signs and verifies session JWTs with the publicly known key &amp;#34;dev-secret-change-me&amp;#34;. The package&amp;#39;s documented entry point — `python -m pra…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: praisonai-platform&lt;/p&gt;
&lt;p&gt;- Affected: praisonai-platform (PyPI) &amp;lt;= 0.1.4 — including 0.1.4, the version GHSA-3qg8-5g3r-79v5 declares as the patch; main HEAD 8acf77c531e624c46d3d61dcae37e9942e90972c is also affected. File src/praisonai-platform/praisonai_platform/services/auth_service.py&lt;/p&gt;
&lt;p&gt;- CWE: CWE-1188 (Insecure Default Initialization) + CWE-798 (Use of Hard-coded Credentials) -&amp;gt; CWE-287 (Improper Authentication)&lt;/p&gt;
&lt;p&gt;## Overview&lt;/p&gt;
&lt;p&gt;GHSA-3qg8-5g3r-79v5 (Critical) reported that praisonai-platform&amp;#39;s JWT signing secret defaulted to the hardcoded literal &amp;#34;dev-secret-change-me&amp;#34;, and that the production guard meant to prevent this was default-open (it only fired when PLATFORM_ENV != &amp;#34;dev&amp;#34;, but PLATFORM_ENV defaults to &amp;#34;dev&amp;#34;). That advisory declares the issue patched in &amp;gt;= 0.1.4. **It is not.** The shipped praisonai-platform==0.1.4 (and current main) still resolves the signing key to &amp;#34;dev-secret-change-me&amp;#34; in any deployment that does not explicitly set PLATFORM_JWT_SECRET, because the 0.1.4 change merely duplicated the same default-open guard into a second function instead of failing closed. An unauthenticated attacker reads the literal from the public source, forges a JWT with an arbitrary sub, and is authenticated as that user — including a workspace owner.&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;Any deployment that runs praisonai-platform 0.1.4 without explicitly exporting a strong PLATFORM_JWT_SECRET signs and verifies session JWTs with the publicly known key &amp;#34;dev-secret-change-me&amp;#34;. The package&amp;#39;s documented entry point — `python -m pra…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-f38v-77qj-h4jq</guid>
    </item>
    <item>
      <title>PYSEC-2026-3525 — praisonai-platform 0.1.4 still boots on the hardcoded JWT secret dev-secret-change-me (default-open production guard)</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-3525</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: praisonai-platform&lt;/p&gt;
&lt;p&gt;- Affected: praisonai-platform (PyPI) &amp;lt;= 0.1.4 — including 0.1.4, the version GHSA-3qg8-5g3r-79v5 declares as the patch; main HEAD 8acf77c531e624c46d3d61dcae37e9942e90972c is also affected. File src/praisonai-platform/praisonai_platform/services/auth_service.py&lt;/p&gt;
&lt;p&gt;- CWE: CWE-1188 (Insecure Default Initialization) + CWE-798 (Use of Hard-coded Credentials) -&amp;gt; CWE-287 (Improper Authentication)&lt;/p&gt;
&lt;p&gt;## Overview&lt;/p&gt;
&lt;p&gt;GHSA-3qg8-5g3r-79v5 (Critical) reported that praisonai-platform&amp;#39;s JWT signing secret defaulted to the hardcoded literal &amp;#34;dev-secret-change-me&amp;#34;, and that the production guard meant to prevent this was default-open (it only fired when PLATFORM_ENV != &amp;#34;dev&amp;#34;, but PLATFORM_ENV defaults to &amp;#34;dev&amp;#34;). That advisory declares the issue patched in &amp;gt;= 0.1.4. **It is not.** The shipped praisonai-platform==0.1.4 (and current main) still resolves the signing key to &amp;#34;dev-secret-change-me&amp;#34; in any deployment that does not explicitly set PLATFORM_JWT_SECRET, because the 0.1.4 change merely duplicated the same default-open guard into a second function instead of failing closed. An unauthenticated attacker reads the literal from the public source, forges a JWT with an arbitrary sub, and is authenticated as that user — including a workspace owner.&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;Any deployment that runs praisonai-platform 0.1.4 without explicitly exporting a strong PLATFORM_JWT_SECRET signs and verifies session JWTs with the publicly known key &amp;#34;dev-secret-change-me&amp;#34;. The package&amp;#39;s documented entry point — `python -m pra…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: praisonai-platform&lt;/p&gt;
&lt;p&gt;- Affected: praisonai-platform (PyPI) &amp;lt;= 0.1.4 — including 0.1.4, the version GHSA-3qg8-5g3r-79v5 declares as the patch; main HEAD 8acf77c531e624c46d3d61dcae37e9942e90972c is also affected. File src/praisonai-platform/praisonai_platform/services/auth_service.py&lt;/p&gt;
&lt;p&gt;- CWE: CWE-1188 (Insecure Default Initialization) + CWE-798 (Use of Hard-coded Credentials) -&amp;gt; CWE-287 (Improper Authentication)&lt;/p&gt;
&lt;p&gt;## Overview&lt;/p&gt;
&lt;p&gt;GHSA-3qg8-5g3r-79v5 (Critical) reported that praisonai-platform&amp;#39;s JWT signing secret defaulted to the hardcoded literal &amp;#34;dev-secret-change-me&amp;#34;, and that the production guard meant to prevent this was default-open (it only fired when PLATFORM_ENV != &amp;#34;dev&amp;#34;, but PLATFORM_ENV defaults to &amp;#34;dev&amp;#34;). That advisory declares the issue patched in &amp;gt;= 0.1.4. **It is not.** The shipped praisonai-platform==0.1.4 (and current main) still resolves the signing key to &amp;#34;dev-secret-change-me&amp;#34; in any deployment that does not explicitly set PLATFORM_JWT_SECRET, because the 0.1.4 change merely duplicated the same default-open guard into a second function instead of failing closed. An unauthenticated attacker reads the literal from the public source, forges a JWT with an arbitrary sub, and is authenticated as that user — including a workspace owner.&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;Any deployment that runs praisonai-platform 0.1.4 without explicitly exporting a strong PLATFORM_JWT_SECRET signs and verifies session JWTs with the publicly known key &amp;#34;dev-secret-change-me&amp;#34;. The package&amp;#39;s documented entry point — `python -m pra…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-3525</guid>
    </item>
  </channel>
</rss>
