PT-2026-53142 · Pypi · Praisonai
Published
2026-06-18
·
Updated
2026-06-18
CVSS v3.1
7.5
High
| Vector | 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 8002The 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-585It 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-853No call to
install api key middleware(app, ...) is made for the dedicated A2U server, unlike the unified server path.Inside
create a2u routes(), auth is opt-in:text
src/praisonai/praisonai/endpoints/a2u server.py:245-253python
auth token = os.environ.get("A2U AUTH TOKEN")
if not auth token:
# No token configured - auth disabled (development mode)
return NoneThe route helper then registers the same sensitive endpoints from the public advisory:
text
src/praisonai/praisonai/endpoints/a2u server.py:391-409Why This Is Not Intended Behavior
The public advisory for
GHSA-f292-66h9-fpmf describes unauthenticated /a2u/info, /a2u/subscribe, /a2u/events/{stream name}, /a2u/events/sub/{id}, and /a2u/health as the vulnerability and lists 4.5.115 as patched.Current documentation also says PraisonAI API servers are now secure by default, bind to
127.0.0.1, and generate a bearer token if no token is provided. The dedicated A2U command does not implement that secure-by-default behavior. It remains unauthenticated unless a different environment variable, A2U AUTH TOKEN, was set before startup.This report does not claim that explicit local-only development mode is always a vulnerability. The issue is the mismatch between the published fixed version / secure-by-default posture and the current A2U CLI behavior, including external binding via
--host 0.0.0.0.PoV
Run:
bash
python3 poc/pov poc.py
--repo /path/to/PraisonAI
--jsonObserved current-head output:
json
{
"no token": {
"info status no auth": 200,
"subscribe status no auth": 200,
"health status no auth": 200,
"subscribe body": {
"stream name": "events",
"stream url": "http://testserver/a2u/events/sub-d8ee868a5491"
}
},
"with token": {
"info status no auth": 401,
"subscribe status no auth": 401,
"info with token": 200,
"subscribe with token": 200
},
"vulnerable current default": true
}The PoV is local-only. It uses a small Starlette response/route shim so it can invoke the registered A2U handlers without starting a network listener or installing dependencies. The control shows that the route-level token check works when
A2U AUTH TOKEN is configured; the vulnerable behavior is that the current documented CLI path does not require or generate that token.PoC
The PoV section above contains the local reproduction command, input, and decisive output.
Impact
An attacker who can reach a current A2U server started without
A2U AUTH TOKEN can subscribe to agent event streams without credentials. The prior public advisory already classifies the exposed data as agent responses, tool calls, thinking/progress events, and stream metadata.If operators rely on the published fixed version or the secure-by-default serve documentation, they may expose A2U on a network interface believing the unauthenticated stream issue is fixed.
Severity
Suggested severity: High.
Suggested Fix
Recommended:
- Make
praisonai serve a2usecure by default in the same way as the documented API servers: generate a bearer token when none is configured, print it to stderr, and enforce it on all non-public A2U endpoints. - Add
--api-key/--auth-tokensupport to the dedicated A2U command and pass the configured token intocreate a2u routes()or shared middleware. - Fail closed for external binds such as
--host 0.0.0.0unless authentication is enabled. - Require auth on
/a2u/healthor remove subscription and stream counts from unauthenticated health responses. - Add regression tests for
praisonai serve a2uproving unauthenticated/a2u/subscribereturns401on current/fixed versions by default.
Affected Package/Versions
- Repository:
MervinPraison/PraisonAI - Ecosystem:
pip - Package:
praisonai - Component: A2U Agent-to-User event stream server
- Current checkout validated:
2f9677abb2ea68eab864ee8b6a828fd0141612e1 - Current checkout tag state:
v4.6.57-4-g2f9677ab - Public prior advisory:
GHSA-f292-66h9-fpmf, fixed range claimspraisonai <= 4.5.114
Suggested affected range:
text
pip:praisonai >= 4.5.115, <= 4.6.58If maintainers prefer to update the public advisory rather than create a new advisory, the important correction is that the fixed version/range should not mark the current
praisonai serve a2u behavior as fixed.Advisory History
This is intentionally adjacent to
GHSA-f292-66h9-fpmf. The report-grade point is that current versions after the claimed patched version still reproduce the same default unauthenticated A2U behavior through the maintained CLI entrypoint.Visible PraisonAI advisories and prior submissions were checked. None cover A2U incomplete authentication after
GHSA-f292-66h9-fpmf.Fix
Information Disclosure
Missing Authentication
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Praisonai