PraisonAI A2U incomplete authentication fix leaves current serve command unauthenticated by default
Date: 2026-06
Affected: pip/praisonai
Attack vector: other
Category: vulnerability-disclosure
Severity: High
CWE: CWE-200
CWE-306
CVSS: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)

## 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_a2


Mitigations:

Architectural layers (MAESTRO):