<?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>Sat, 10 Oct 2026 04:42:31 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-358822</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-358822</link>
      <description>EUVD-2026-358822</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-358822</guid>
    </item>
    <item>
      <title>fkie_cve-2026-55533</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-55533</link>
      <description>&lt;p&gt;PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.58, create_auth_middleware() allows requests when auth=api-key lacks PRAISONAI_API_KEY or JWT authentication lacks PRAISONAI_JWT_SECRET. An externally bound Recipe server can therefore accept unauthenticated POST /v1/recipes/run requests despite authentication being enabled. This issue is fixed in version 4.6.58.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.58, create_auth_middleware() allows requests when auth=api-key lacks PRAISONAI_API_KEY or JWT authentication lacks PRAISONAI_JWT_SECRET. An externally bound Recipe server can therefore accept unauthenticated POST /v1/recipes/run requests despite authentication being enabled. This issue is fixed in version 4.6.58.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-55533</guid>
    </item>
    <item>
      <title>GHSA-gfq8-hmph-9gjv — PraisonAI: Authentication fail-open in Recipe server allows unauthenticated access when API key or JWT auth is configur…</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-gfq8-hmph-9gjv</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: PraisonAI&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The PraisonAI Recipe HTTP server silently allows unauthenticated requests when `auth` is configured as `api-key` or `jwt` but the corresponding secret is missing.&lt;/p&gt;
&lt;p&gt;This creates an authentication fail-open condition. An operator can start the Recipe server with authentication enabled, including on a non-localhost interface, but the server still accepts unauthenticated requests if no API key or JWT secret is provided.&lt;/p&gt;
&lt;p&gt;The issue is especially risky because the CLI safety check for non-localhost binding only verifies that `auth != &amp;#34;none&amp;#34;`. It does not verify that an actual API key or JWT secret exists.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The Recipe server documents the following authentication modes:&lt;/p&gt;
&lt;p&gt;- `none`
- `api-key`
- `jwt`&lt;/p&gt;
&lt;p&gt;Relevant source locations:&lt;/p&gt;
&lt;p&gt;- `src/praisonai/praisonai/recipe/serve.py`
- `src/praisonai/praisonai/cli/features/recipe.py`&lt;/p&gt;
&lt;p&gt;In `create_auth_middleware()`, the API key middleware resolves the expected key as:&lt;/p&gt;
&lt;p&gt;```python
expected_key = api_key or os.environ.get(&amp;#34;PRAISONAI_API_KEY&amp;#34;)&lt;/p&gt;
&lt;p&gt;if not expected_key:
    # No key configured, allow request
    return await call_next(request)
```&lt;/p&gt;
&lt;p&gt;This means `auth: api-key` does not enforce authentication if `api_key` / `PRAISONAI_API_KEY` is missing.&lt;/p&gt;
&lt;p&gt;The JWT middleware has the same fail-open behavior:&lt;/p&gt;
&lt;p&gt;```python
secret = jwt_secret or os.environ.get(&amp;#34;PRAISONAI_JWT_SECRET&amp;#34;)
if not secret:
    return await call_next(request)
```&lt;/p&gt;
&lt;p&gt;The auth middleware is still attached when `auth` is configured:&lt;/p&gt;
&lt;p&gt;```python
auth_type = config.get(…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: PraisonAI&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The PraisonAI Recipe HTTP server silently allows unauthenticated requests when `auth` is configured as `api-key` or `jwt` but the corresponding secret is missing.&lt;/p&gt;
&lt;p&gt;This creates an authentication fail-open condition. An operator can start the Recipe server with authentication enabled, including on a non-localhost interface, but the server still accepts unauthenticated requests if no API key or JWT secret is provided.&lt;/p&gt;
&lt;p&gt;The issue is especially risky because the CLI safety check for non-localhost binding only verifies that `auth != &amp;#34;none&amp;#34;`. It does not verify that an actual API key or JWT secret exists.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The Recipe server documents the following authentication modes:&lt;/p&gt;
&lt;p&gt;- `none`
- `api-key`
- `jwt`&lt;/p&gt;
&lt;p&gt;Relevant source locations:&lt;/p&gt;
&lt;p&gt;- `src/praisonai/praisonai/recipe/serve.py`
- `src/praisonai/praisonai/cli/features/recipe.py`&lt;/p&gt;
&lt;p&gt;In `create_auth_middleware()`, the API key middleware resolves the expected key as:&lt;/p&gt;
&lt;p&gt;```python
expected_key = api_key or os.environ.get(&amp;#34;PRAISONAI_API_KEY&amp;#34;)&lt;/p&gt;
&lt;p&gt;if not expected_key:
    # No key configured, allow request
    return await call_next(request)
```&lt;/p&gt;
&lt;p&gt;This means `auth: api-key` does not enforce authentication if `api_key` / `PRAISONAI_API_KEY` is missing.&lt;/p&gt;
&lt;p&gt;The JWT middleware has the same fail-open behavior:&lt;/p&gt;
&lt;p&gt;```python
secret = jwt_secret or os.environ.get(&amp;#34;PRAISONAI_JWT_SECRET&amp;#34;)
if not secret:
    return await call_next(request)
```&lt;/p&gt;
&lt;p&gt;The auth middleware is still attached when `auth` is configured:&lt;/p&gt;
&lt;p&gt;```python
auth_type = config.get(…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-gfq8-hmph-9gjv</guid>
    </item>
    <item>
      <title>PYSEC-2026-3889 — PraisonAI: Authentication fail-open in Recipe server allows unauthenticated access when API key or JWT auth is configur…</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-3889</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: praisonai&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The PraisonAI Recipe HTTP server silently allows unauthenticated requests when `auth` is configured as `api-key` or `jwt` but the corresponding secret is missing.&lt;/p&gt;
&lt;p&gt;This creates an authentication fail-open condition. An operator can start the Recipe server with authentication enabled, including on a non-localhost interface, but the server still accepts unauthenticated requests if no API key or JWT secret is provided.&lt;/p&gt;
&lt;p&gt;The issue is especially risky because the CLI safety check for non-localhost binding only verifies that `auth != &amp;#34;none&amp;#34;`. It does not verify that an actual API key or JWT secret exists.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The Recipe server documents the following authentication modes:&lt;/p&gt;
&lt;p&gt;- `none`
- `api-key`
- `jwt`&lt;/p&gt;
&lt;p&gt;Relevant source locations:&lt;/p&gt;
&lt;p&gt;- `src/praisonai/praisonai/recipe/serve.py`
- `src/praisonai/praisonai/cli/features/recipe.py`&lt;/p&gt;
&lt;p&gt;In `create_auth_middleware()`, the API key middleware resolves the expected key as:&lt;/p&gt;
&lt;p&gt;```python
expected_key = api_key or os.environ.get(&amp;#34;PRAISONAI_API_KEY&amp;#34;)&lt;/p&gt;
&lt;p&gt;if not expected_key:
    # No key configured, allow request
    return await call_next(request)
```&lt;/p&gt;
&lt;p&gt;This means `auth: api-key` does not enforce authentication if `api_key` / `PRAISONAI_API_KEY` is missing.&lt;/p&gt;
&lt;p&gt;The JWT middleware has the same fail-open behavior:&lt;/p&gt;
&lt;p&gt;```python
secret = jwt_secret or os.environ.get(&amp;#34;PRAISONAI_JWT_SECRET&amp;#34;)
if not secret:
    return await call_next(request)
```&lt;/p&gt;
&lt;p&gt;The auth middleware is still attached when `auth` is configured:&lt;/p&gt;
&lt;p&gt;```python
auth_type = config.get(…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: praisonai&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The PraisonAI Recipe HTTP server silently allows unauthenticated requests when `auth` is configured as `api-key` or `jwt` but the corresponding secret is missing.&lt;/p&gt;
&lt;p&gt;This creates an authentication fail-open condition. An operator can start the Recipe server with authentication enabled, including on a non-localhost interface, but the server still accepts unauthenticated requests if no API key or JWT secret is provided.&lt;/p&gt;
&lt;p&gt;The issue is especially risky because the CLI safety check for non-localhost binding only verifies that `auth != &amp;#34;none&amp;#34;`. It does not verify that an actual API key or JWT secret exists.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The Recipe server documents the following authentication modes:&lt;/p&gt;
&lt;p&gt;- `none`
- `api-key`
- `jwt`&lt;/p&gt;
&lt;p&gt;Relevant source locations:&lt;/p&gt;
&lt;p&gt;- `src/praisonai/praisonai/recipe/serve.py`
- `src/praisonai/praisonai/cli/features/recipe.py`&lt;/p&gt;
&lt;p&gt;In `create_auth_middleware()`, the API key middleware resolves the expected key as:&lt;/p&gt;
&lt;p&gt;```python
expected_key = api_key or os.environ.get(&amp;#34;PRAISONAI_API_KEY&amp;#34;)&lt;/p&gt;
&lt;p&gt;if not expected_key:
    # No key configured, allow request
    return await call_next(request)
```&lt;/p&gt;
&lt;p&gt;This means `auth: api-key` does not enforce authentication if `api_key` / `PRAISONAI_API_KEY` is missing.&lt;/p&gt;
&lt;p&gt;The JWT middleware has the same fail-open behavior:&lt;/p&gt;
&lt;p&gt;```python
secret = jwt_secret or os.environ.get(&amp;#34;PRAISONAI_JWT_SECRET&amp;#34;)
if not secret:
    return await call_next(request)
```&lt;/p&gt;
&lt;p&gt;The auth middleware is still attached when `auth` is configured:&lt;/p&gt;
&lt;p&gt;```python
auth_type = config.get(…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-3889</guid>
    </item>
  </channel>
</rss>
