GHSA-jxcw-qp4h-6jfq: praisonai: incomplete auth fix exposes A2U agent streams

GHSA-jxcw-qp4h-6jfq HIGH
Published June 18, 2026
CISO Take

PraisonAI versions 4.5.115 through 4.6.60 contain an incomplete fix for unauthenticated access to the A2U (Agent-to-User) event streaming server: the dedicated `praisonai serve a2u` CLI path omits the API-key middleware and never generates an auth token, leaving agent responses, tool calls, thinking events, and stream metadata accessible to any network-reachable attacker with zero credentials. The critical risk amplifier is the deception — operators who upgraded post-GHSA-f292-66h9-fpmf may believe they are fully patched while actively exposing A2U on 0.0.0.0:8002. There is no CISA KEV listing and no public exploit, but with CVSS 7.5 (AV:N/AC:L/PR:N/UI:N) and a working PoV confirming HTTP 200 on /a2u/subscribe and /a2u/info with no credentials, exploitation requires no AI expertise — any attacker who can reach the port wins. Upgrade to praisonai 4.6.61 immediately; if patching is delayed, set the `A2U_AUTH_TOKEN` environment variable before starting the A2U server and block port 8002 at the network perimeter.

Sources: GitHub Advisory ATLAS

What is the risk?

CVSS 7.5 HIGH with network-accessible, zero-credential exploitation makes this high-priority despite only one direct downstream dependent. The primary risk multiplier is the incomplete-fix posture: organizations that upgraded after GHSA-f292-66h9-fpmf likely believe they are protected and may have lowered their guard. External binding via --host 0.0.0.0 expands the attack surface to any network-reachable host. No active exploitation or KEV listing reduces immediate urgency, but the trivial exploitation path and the sensitivity of exposed data — full cognitive traces of running AI agents — justify prompt remediation over routine patching cycles.

How does the attack unfold?

Discovery
Attacker scans the internet for port 8002 and fingerprints PraisonAI A2U servers using the unauthenticated /a2u/health endpoint, which returns HTTP 200 with JSON on vulnerable instances.
AML.T0006
Initial Access
Attacker sends an unauthenticated POST to /a2u/subscribe and receives a valid stream_url with no credentials required, confirming exploitability and obtaining a live event stream handle.
AML.T0049
Collection
Attacker consumes the SSE event stream at /a2u/events/{id}, receiving real-time agent responses, tool call inputs and outputs, and LLM reasoning traces from all active agent sessions.
AML.T0085
Exfiltration
Attacker maintains a persistent SSE connection, silently exfiltrating the organization's complete AI agent activity including any sensitive data surfaced by agent tools such as database query results, internal API responses, or file contents.
AML.T0025

What systems are affected?

Package Ecosystem Vulnerable Range Patched
PraisonAI pip >= 4.5.115, < 4.6.61 4.6.61
1 dependents 89% patched ~0d to patch Full package profile →

Do you use PraisonAI? You're affected.

How severe is it?

CVSS 3.1
7.5 / 10
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Trivial

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR None
UI None
S Unchanged
C High
I None
A None

What should I do?

5 steps
  1. Patch: Upgrade praisonai to 4.6.61 or later — this is the only fully remediated version.

  2. Immediate workaround (if patching is delayed): Set the A2U_AUTH_TOKEN environment variable to a strong random value before starting the A2U server; the route-level check enforces it when present.

  3. Network control: Block port 8002 (or your configured A2U port) at the firewall from all untrusted networks; never allow --host 0.0.0.0 without confirmed authentication.

  4. Detection: Audit HTTP access logs for unauthenticated 200 responses on /a2u/subscribe, /a2u/info, /a2u/events/*, and /a2u/health — any 200 without an Authorization header indicates active exploitation.

  5. Deployment audit: Confirm whether your environment uses praisonai serve a2u (vulnerable) or the unified server path (not affected); update runbooks accordingly.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 9 - Risk management system
ISO 42001
6.1.2 - AI risk treatment 8.1 - Operational planning and control
NIST AI RMF
MANAGE-2.2 - Mechanisms are in place to inventory AI risks
OWASP LLM Top 10
LLM02:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is GHSA-jxcw-qp4h-6jfq?

PraisonAI versions 4.5.115 through 4.6.60 contain an incomplete fix for unauthenticated access to the A2U (Agent-to-User) event streaming server: the dedicated `praisonai serve a2u` CLI path omits the API-key middleware and never generates an auth token, leaving agent responses, tool calls, thinking events, and stream metadata accessible to any network-reachable attacker with zero credentials. The critical risk amplifier is the deception — operators who upgraded post-GHSA-f292-66h9-fpmf may believe they are fully patched while actively exposing A2U on 0.0.0.0:8002. There is no CISA KEV listing and no public exploit, but with CVSS 7.5 (AV:N/AC:L/PR:N/UI:N) and a working PoV confirming HTTP 200 on /a2u/subscribe and /a2u/info with no credentials, exploitation requires no AI expertise — any attacker who can reach the port wins. Upgrade to praisonai 4.6.61 immediately; if patching is delayed, set the `A2U_AUTH_TOKEN` environment variable before starting the A2U server and block port 8002 at the network perimeter.

Is GHSA-jxcw-qp4h-6jfq actively exploited?

No confirmed active exploitation of GHSA-jxcw-qp4h-6jfq has been reported, but organizations should still patch proactively.

How to fix GHSA-jxcw-qp4h-6jfq?

1. Patch: Upgrade praisonai to 4.6.61 or later — this is the only fully remediated version. 2. Immediate workaround (if patching is delayed): Set the `A2U_AUTH_TOKEN` environment variable to a strong random value before starting the A2U server; the route-level check enforces it when present. 3. Network control: Block port 8002 (or your configured A2U port) at the firewall from all untrusted networks; never allow --host 0.0.0.0 without confirmed authentication. 4. Detection: Audit HTTP access logs for unauthenticated 200 responses on /a2u/subscribe, /a2u/info, /a2u/events/*, and /a2u/health — any 200 without an Authorization header indicates active exploitation. 5. Deployment audit: Confirm whether your environment uses `praisonai serve a2u` (vulnerable) or the unified server path (not affected); update runbooks accordingly.

What systems are affected by GHSA-jxcw-qp4h-6jfq?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, agentic pipelines, model serving.

What is the CVSS score for GHSA-jxcw-qp4h-6jfq?

GHSA-jxcw-qp4h-6jfq has a CVSS v3.1 base score of 7.5 (HIGH).

What is the AI security impact?

Affected AI Architectures

agent frameworksagentic pipelinesmodel serving

MITRE ATLAS Techniques

AML.T0006 Active Scanning
AML.T0049 Exploit Public-Facing Application
AML.T0063 Discover AI Model Outputs
AML.T0084 Discover AI Agent Configuration
AML.T0085 Data from AI Services

Compliance Controls Affected

EU AI Act: Article 9
ISO 42001: 6.1.2, 8.1
NIST AI RMF: MANAGE-2.2
OWASP LLM Top 10: LLM02:2025

What are the technical details?

Original Advisory

## 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_a2u_routes()`, auth is opt-in: ```text src/praisonai/praisonai/endpoints/a2u_server.py:245-253 ``` ```python 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: ```text 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: ```bash python3 poc/pov_poc.py \ --repo /path/to/PraisonAI \ --json ``` Observed 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: 1. Make `praisonai serve a2u` secure 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. 2. Add `--api-key` / `--auth-token` support to the dedicated A2U command and pass the configured token into `create_a2u_routes()` or shared middleware. 3. Fail closed for external binds such as `--host 0.0.0.0` unless authentication is enabled. 4. Require auth on `/a2u/health` or remove subscription and stream counts from unauthenticated health responses. 5. Add regression tests for `praisonai serve a2u` proving unauthenticated `/a2u/subscribe` returns `401` on 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 claims `praisonai <= 4.5.114` Suggested affected range: ```text pip:praisonai >= 4.5.115, <= 4.6.58 ``` If 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`.

Exploitation Scenario

An attacker targeting an organization using PraisonAI for internal agentic workflows performs an internet scan for port 8002 with responses matching PraisonAI A2U fingerprints (unauthenticated /a2u/health returning 200 with JSON). Upon finding an exposed instance, they POST to /a2u/subscribe with no credentials, receiving a stream_url. They then consume the SSE stream at /a2u/events/{stream_name}, receiving the real-time cognitive trace of all running agents: tool call inputs and outputs (potentially including database queries, internal API responses, and file contents), LLM reasoning traces, and agent-to-user messages. If PraisonAI agents have access to internal tools, the attacker gains persistent, silent read access to all agent activity — with no credentials, no alert, and no evidence left beyond normal-looking HTTP GET traffic.

Weaknesses (CWE)

CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor: The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

  • [Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Timeline

Published
June 18, 2026
Last Modified
June 18, 2026
First Seen
June 18, 2026

Related Vulnerabilities