Most recent entries from all

GHSA-jxcw-qp4h-6jfq — PraisonAI A2U incomplete authentication fix leaves current serve command unauthenticated by default

Affected: PyPI: praisonai

## Summary

The published A2U advisory `GHSA-f292-66h9-fpmf` says unauthenticated A2U event streaming was fixed in `praisonai` `4.5.115`. Current head still exposes the same A2U subscription and event routes without authentication when the operator starts the documented CLI entrypoint:

```text praisonai serve a2u --host 0.0.0.0 --port 8002 ```

The current CLI wrapper does not expose `--api-key`, does not install the common API-key middleware, and does not generate a token for A2U. It calls `create_a2u_routes(app)` directly. That helper only enforces auth if `A2U_AUTH_TOKEN` is already present; if the variable is missing, `_authenticate_request()` returns `None` and treats auth as disabled.

This is an incomplete-fix report for the published A2U issue, not a separate trust-model-only concern.

## Technical Details

The Typer command for A2U accepts only `--host` and `--port`:

```text src/praisonai/praisonai/cli/commands/serve.py:570-585 ```

It forwards only those values to the shared serve handler:

```python args = ["a2u", "--host", host, "--port", str(port)] ```

The serve handler for A2U likewise accepts only `host` and `port`, then creates the app:

```text src/praisonai/praisonai/cli/features/serve.py:802-817 ```

`_create_a2u_app()` registers A2U routes directly:

```text src/praisonai/praisonai/cli/features/serve.py:827-853 ```

No call to `_install_api_key_middleware(app, ...)` is made for the dedicated A2U server, unlike the unified server path.

Inside `create_a…

PYSEC-2026-3515 — PraisonAI A2U incomplete authentication fix leaves current serve command unauthenticated by default