CVE-2026-57146

PraisonAI is a multi-agent teams system. From version 4.5.115 to before version 4.6.61, 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. 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 issue has been patched in version 4.6.61.

PraisonAI is a multi-agent teams system. From version 4.5.115 to before version 4.6.61, 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. 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 issue has been patched in version 4.6.61.

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:

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:

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

It forwards only those values to the shared serve handler:

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

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

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

_create_a2u_app() registers A2U routes directly:

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_a2u_routes(), auth is opt-in:

src/praisonai/praisonai/endpoints/a2u_server.py:245-253

auth_token = os.environ.get("A2U_AUTH_TOKEN")
if not auth_token:
    # No token configured - auth disabled (development mode)
    return None

The route helper then registers the same sensitive endpoints from the public advisory:

src/praisonai/praisonai/endpoints/a2u_server.py:391-409

Why 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:

python3 poc/pov_poc.py \
  --repo /path/to/PraisonAI \
  --json

Observed current-head output:

{
  "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…

PraisonAI is a multi-agent teams system. From version 4.5.115 to before version 4.6.61, 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. 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 issue has been patched in version 4.6.61.

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:

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:

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

It forwards only those values to the shared serve handler:

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

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

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

_create_a2u_app() registers A2U routes directly:

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_a2u_routes(), auth is opt-in:

src/praisonai/praisonai/endpoints/a2u_server.py:245-253

auth_token = os.environ.get("A2U_AUTH_TOKEN")
if not auth_token:
    # No token configured - auth disabled (development mode)
    return None

The route helper then registers the same sensitive endpoints from the public advisory:

src/praisonai/praisonai/endpoints/a2u_server.py:391-409

Why 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:

python3 poc/pov_poc.py \
  --repo /path/to/PraisonAI \
  --json

Observed current-head output:

{
  "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…

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:

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:

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

It forwards only those values to the shared serve handler:

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

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

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

_create_a2u_app() registers A2U routes directly:

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_a2u_routes(), auth is opt-in:

src/praisonai/praisonai/endpoints/a2u_server.py:245-253

auth_token = os.environ.get("A2U_AUTH_TOKEN")
if not auth_token:
    # No token configured - auth disabled (development mode)
    return None

The route helper then registers the same sensitive endpoints from the public advisory:

src/praisonai/praisonai/endpoints/a2u_server.py:391-409

Why 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:

python3 poc/pov_poc.py \
  --repo /path/to/PraisonAI \
  --json

Observed current-head output:

{
  "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…