<?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-10-02T04:43:29.412454+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-57127</id>
    <title>fkie_cve-2026-57127</title>
    <updated>2026-10-02T04:43:29.430133+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>PraisonAI is a multi-agent teams system. Prior to 4.6.58, recipe serve installs APIKeyAuthMiddleware or JWTAuthMiddleware when an operator selects api-key or JWT authentication, but each middleware forwards requests when PRAISONAI_API_KEY or PRAISONAI_JWT_SECRET and the corresponding recipe value are absent. Unauthenticated clients can then reach recipe execution, input, and output surfaces and may trigger connected tools despite the operator explicitly enabling authentication. This issue is fixed in 4.6.58.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-57127"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-j4hj-7hfh-g2f4</id>
    <title>GHSA-j4hj-7hfh-g2f4 — praisonai: recipe serve auth middleware silently disables itself when no secret is set</title>
    <updated>2026-10-02T04:43:29.430212+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: praisonai</p>
<p># praisonai: `recipe serve` authentication middleware silently disables itself when no secret is set</p>
<p>**Researcher:** Kai Aizen — SnailSploit (@SnailSploit), Adversarial &amp; Offensive Security Research
**Target:** https://github.com/MervinPraison/PraisonAI</p>
<p>---</p>
<p>**Package:** `praisonai` on PyPI
**Version tested:** 4.6.48.
**File:** `praisonai/recipe/serve.py` (sha256 `491bf8f29e399418260810ba4bf0f6802c6e4aa675628e2be68a9726c15d9b23`).</p>
<p>---</p>
<p>## TL;DR</p>
<p>`praisonai/recipe/serve.py:312-410` defines two auth middlewares (`APIKeyAuthMiddleware`, `JWTAuthMiddleware`). Both contain the same "fail open when the secret is unset" branch at the top of their `dispatch`:</p>
<p>```python
async def dispatch(self, request, call_next):
    if request.url.path == "/health":
        return await call_next(request)
    expected_key = api_key or os.environ.get("PRAISONAI_API_KEY")
    if not expected_key:
        # No key configured, allow request
        return await call_next(request)
    ...
```</p>
<p>```python
async def dispatch(self, request, call_next):
    if request.url.path == "/health":
        return await call_next(request)
    secret = jwt_secret or os.environ.get("PRAISONAI_JWT_SECRET")
    if not secret:
        return await call_next(request)
    ...
```</p>
<p>The realistic mis-deploy:</p>
<p>1. operator sets `auth: api-key` (or `auth: jwt`) in their recipe YAML, expecting that line alone to enable auth,
2. operator does not set the corresponding `api_key:` / `jwt_secret:` value in the same YAML, AND
3.…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-j4hj-7hfh-g2f4"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/pysec-2026-3513</id>
    <title>PYSEC-2026-3513 — praisonai: recipe serve auth middleware silently disables itself when no secret is set</title>
    <updated>2026-10-02T04:43:29.430336+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: praisonai</p>
<p># praisonai: `recipe serve` authentication middleware silently disables itself when no secret is set</p>
<p>**Researcher:** Kai Aizen — SnailSploit (@SnailSploit), Adversarial &amp; Offensive Security Research
**Target:** https://github.com/MervinPraison/PraisonAI</p>
<p>---</p>
<p>**Package:** `praisonai` on PyPI
**Version tested:** 4.6.48.
**File:** `praisonai/recipe/serve.py` (sha256 `491bf8f29e399418260810ba4bf0f6802c6e4aa675628e2be68a9726c15d9b23`).</p>
<p>---</p>
<p>## TL;DR</p>
<p>`praisonai/recipe/serve.py:312-410` defines two auth middlewares (`APIKeyAuthMiddleware`, `JWTAuthMiddleware`). Both contain the same "fail open when the secret is unset" branch at the top of their `dispatch`:</p>
<p>```python
async def dispatch(self, request, call_next):
    if request.url.path == "/health":
        return await call_next(request)
    expected_key = api_key or os.environ.get("PRAISONAI_API_KEY")
    if not expected_key:
        # No key configured, allow request
        return await call_next(request)
    ...
```</p>
<p>```python
async def dispatch(self, request, call_next):
    if request.url.path == "/health":
        return await call_next(request)
    secret = jwt_secret or os.environ.get("PRAISONAI_JWT_SECRET")
    if not secret:
        return await call_next(request)
    ...
```</p>
<p>The realistic mis-deploy:</p>
<p>1. operator sets `auth: api-key` (or `auth: jwt`) in their recipe YAML, expecting that line alone to enable auth,
2. operator does not set the corresponding `api_key:` / `jwt_secret:` value in the same YAML, AND
3.…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/pysec-2026-3513"/>
  </entry>
</feed>
