<?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, 17 Oct 2026 05:21:12 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-358955</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-358955</link>
      <description>EUVD-2026-358955</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-358955</guid>
    </item>
    <item>
      <title>fkie_cve-2026-55541</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-55541</link>
      <description>&lt;p&gt;PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.58, praisonai serve agents and praisonai serve unified parse --api-key but _create_agents_app() and _create_unified_app() do not install a credential check. Unauthenticated callers can reach POST /agents and POST /api/v1/agents/{id}/invoke. 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, praisonai serve agents and praisonai serve unified parse --api-key but _create_agents_app() and _create_unified_app() do not install a credential check. Unauthenticated callers can reach POST /agents and POST /api/v1/agents/{id}/invoke. 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-55541</guid>
    </item>
    <item>
      <title>GHSA-pvxx-r596-f5qj — PraisonAI: `--api-key` flag on `praisonai serve` is not properly enforced</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-pvxx-r596-f5qj</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;`praisonai serve agents` and `praisonai serve unified` both accept `--api-key` for authentication. The flag is parsed but never wired into the FastAPI app — no middleware, no header check, nothing. The server runs wide open regardless of what key you set. Tested on 4.6.50 from PyPI.&lt;/p&gt;
&lt;p&gt;## Affected versions&lt;/p&gt;
&lt;p&gt;- Confirmed on **4.6.50** (current PyPI, 2026-06-02)
- Likely since **4.6.34** when the serve subsystem shipped
- File: `src/praisonai/praisonai/cli/features/serve.py`&lt;/p&gt;
&lt;p&gt;## What happens&lt;/p&gt;
&lt;p&gt;The CLI defines `--api-key` in the arg spec (`serve.py:199`) and passes the parsed value into `_create_agents_app(config)`. But that function never reads `config[&amp;#34;api_key&amp;#34;]`. The FastAPI app gets created with no auth at all. Same thing in `_create_unified_app`.&lt;/p&gt;
&lt;p&gt;The help text says `--api-key &amp;lt;key&amp;gt;   API key for authentication`, so this isn&amp;#39;t ambiguous — it&amp;#39;s supposed to protect the server. It just doesn&amp;#39;t.
```
$ grep -n &amp;#34;api_key&amp;#34; src/praisonai/praisonai/cli/features/serve.py
107:  --api-key &amp;lt;key&amp;gt;   API key for authentication
199:            &amp;#34;api_key&amp;#34;: {&amp;#34;default&amp;#34;: None},
847:            &amp;#34;api_key&amp;#34;: {&amp;#34;default&amp;#34;: None},
```&lt;/p&gt;
&lt;p&gt;## Endpoints exposed without auth&lt;/p&gt;
&lt;p&gt;- `POST /agents` — runs the full agent workflow
- `POST /agents/{name}` — invokes a specific agent
- `POST /api/v1/agents/{id}/invoke` — n8n integration endpoint
- `GET /` — lists all endpoints
- `GET /__praisonai__/discovery` — service discovery&lt;/p&gt;
&lt;p&gt;## Not the same as CVE-2026-44338&lt;/p&gt;
&lt;p&gt;CVE-2026-44338 was about the legacy `deploy/api.…&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;`praisonai serve agents` and `praisonai serve unified` both accept `--api-key` for authentication. The flag is parsed but never wired into the FastAPI app — no middleware, no header check, nothing. The server runs wide open regardless of what key you set. Tested on 4.6.50 from PyPI.&lt;/p&gt;
&lt;p&gt;## Affected versions&lt;/p&gt;
&lt;p&gt;- Confirmed on **4.6.50** (current PyPI, 2026-06-02)
- Likely since **4.6.34** when the serve subsystem shipped
- File: `src/praisonai/praisonai/cli/features/serve.py`&lt;/p&gt;
&lt;p&gt;## What happens&lt;/p&gt;
&lt;p&gt;The CLI defines `--api-key` in the arg spec (`serve.py:199`) and passes the parsed value into `_create_agents_app(config)`. But that function never reads `config[&amp;#34;api_key&amp;#34;]`. The FastAPI app gets created with no auth at all. Same thing in `_create_unified_app`.&lt;/p&gt;
&lt;p&gt;The help text says `--api-key &amp;lt;key&amp;gt;   API key for authentication`, so this isn&amp;#39;t ambiguous — it&amp;#39;s supposed to protect the server. It just doesn&amp;#39;t.
```
$ grep -n &amp;#34;api_key&amp;#34; src/praisonai/praisonai/cli/features/serve.py
107:  --api-key &amp;lt;key&amp;gt;   API key for authentication
199:            &amp;#34;api_key&amp;#34;: {&amp;#34;default&amp;#34;: None},
847:            &amp;#34;api_key&amp;#34;: {&amp;#34;default&amp;#34;: None},
```&lt;/p&gt;
&lt;p&gt;## Endpoints exposed without auth&lt;/p&gt;
&lt;p&gt;- `POST /agents` — runs the full agent workflow
- `POST /agents/{name}` — invokes a specific agent
- `POST /api/v1/agents/{id}/invoke` — n8n integration endpoint
- `GET /` — lists all endpoints
- `GET /__praisonai__/discovery` — service discovery&lt;/p&gt;
&lt;p&gt;## Not the same as CVE-2026-44338&lt;/p&gt;
&lt;p&gt;CVE-2026-44338 was about the legacy `deploy/api.…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-pvxx-r596-f5qj</guid>
    </item>
    <item>
      <title>PYSEC-2026-3893 — PraisonAI: `--api-key` flag on `praisonai serve` is not properly enforced</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-3893</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;`praisonai serve agents` and `praisonai serve unified` both accept `--api-key` for authentication. The flag is parsed but never wired into the FastAPI app — no middleware, no header check, nothing. The server runs wide open regardless of what key you set. Tested on 4.6.50 from PyPI.&lt;/p&gt;
&lt;p&gt;## Affected versions&lt;/p&gt;
&lt;p&gt;- Confirmed on **4.6.50** (current PyPI, 2026-06-02)
- Likely since **4.6.34** when the serve subsystem shipped
- File: `src/praisonai/praisonai/cli/features/serve.py`&lt;/p&gt;
&lt;p&gt;## What happens&lt;/p&gt;
&lt;p&gt;The CLI defines `--api-key` in the arg spec (`serve.py:199`) and passes the parsed value into `_create_agents_app(config)`. But that function never reads `config[&amp;#34;api_key&amp;#34;]`. The FastAPI app gets created with no auth at all. Same thing in `_create_unified_app`.&lt;/p&gt;
&lt;p&gt;The help text says `--api-key &amp;lt;key&amp;gt;   API key for authentication`, so this isn&amp;#39;t ambiguous — it&amp;#39;s supposed to protect the server. It just doesn&amp;#39;t.
```
$ grep -n &amp;#34;api_key&amp;#34; src/praisonai/praisonai/cli/features/serve.py
107:  --api-key &amp;lt;key&amp;gt;   API key for authentication
199:            &amp;#34;api_key&amp;#34;: {&amp;#34;default&amp;#34;: None},
847:            &amp;#34;api_key&amp;#34;: {&amp;#34;default&amp;#34;: None},
```&lt;/p&gt;
&lt;p&gt;## Endpoints exposed without auth&lt;/p&gt;
&lt;p&gt;- `POST /agents` — runs the full agent workflow
- `POST /agents/{name}` — invokes a specific agent
- `POST /api/v1/agents/{id}/invoke` — n8n integration endpoint
- `GET /` — lists all endpoints
- `GET /__praisonai__/discovery` — service discovery&lt;/p&gt;
&lt;p&gt;## Not the same as CVE-2026-44338&lt;/p&gt;
&lt;p&gt;CVE-2026-44338 was about the legacy `deploy/api.…&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;`praisonai serve agents` and `praisonai serve unified` both accept `--api-key` for authentication. The flag is parsed but never wired into the FastAPI app — no middleware, no header check, nothing. The server runs wide open regardless of what key you set. Tested on 4.6.50 from PyPI.&lt;/p&gt;
&lt;p&gt;## Affected versions&lt;/p&gt;
&lt;p&gt;- Confirmed on **4.6.50** (current PyPI, 2026-06-02)
- Likely since **4.6.34** when the serve subsystem shipped
- File: `src/praisonai/praisonai/cli/features/serve.py`&lt;/p&gt;
&lt;p&gt;## What happens&lt;/p&gt;
&lt;p&gt;The CLI defines `--api-key` in the arg spec (`serve.py:199`) and passes the parsed value into `_create_agents_app(config)`. But that function never reads `config[&amp;#34;api_key&amp;#34;]`. The FastAPI app gets created with no auth at all. Same thing in `_create_unified_app`.&lt;/p&gt;
&lt;p&gt;The help text says `--api-key &amp;lt;key&amp;gt;   API key for authentication`, so this isn&amp;#39;t ambiguous — it&amp;#39;s supposed to protect the server. It just doesn&amp;#39;t.
```
$ grep -n &amp;#34;api_key&amp;#34; src/praisonai/praisonai/cli/features/serve.py
107:  --api-key &amp;lt;key&amp;gt;   API key for authentication
199:            &amp;#34;api_key&amp;#34;: {&amp;#34;default&amp;#34;: None},
847:            &amp;#34;api_key&amp;#34;: {&amp;#34;default&amp;#34;: None},
```&lt;/p&gt;
&lt;p&gt;## Endpoints exposed without auth&lt;/p&gt;
&lt;p&gt;- `POST /agents` — runs the full agent workflow
- `POST /agents/{name}` — invokes a specific agent
- `POST /api/v1/agents/{id}/invoke` — n8n integration endpoint
- `GET /` — lists all endpoints
- `GET /__praisonai__/discovery` — service discovery&lt;/p&gt;
&lt;p&gt;## Not the same as CVE-2026-44338&lt;/p&gt;
&lt;p&gt;CVE-2026-44338 was about the legacy `deploy/api.…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-3893</guid>
    </item>
  </channel>
</rss>
