CVE-2026-40289

PraisonAI is a multi-agent teams system. In versions below 4.5.139 of PraisonAI and 1.5.140 of praisonaiagents, the browser bridge (praisonai browser start) is vulnerable to unauthenticated remote session hijacking due to missing authentication and a bypassable origin check on its /ws WebSocket endpoint. The server binds to 0.0.0.0 by default and only validates the Origin header when one is present, meaning any non-browser client that omits the header is accepted without restriction. An unauthenticated network attacker can connect, send a start_session message, and the server will route it to the first idle browser-extension WebSocket (effectively hijacking that session) and then broadcast all resulting automation actions and outputs back to the attacker. This enables unauthorized remote control of connected browser automation sessions, leakage of sensitive page context and automation results, and misuse of model-backed browser actions in any environment where the bridge is network-reachable. This issue has been fixed in versions 4.5.139 of PraisonAI and 1.5.140 of praisonaiagents.

PraisonAI is a multi-agent teams system. In versions below 4.5.139 of PraisonAI and 1.5.140 of praisonaiagents, the browser bridge (praisonai browser start) is vulnerable to unauthenticated remote session hijacking due to missing authentication and a bypassable origin check on its /ws WebSocket endpoint. The server binds to 0.0.0.0 by default and only validates the Origin header when one is present, meaning any non-browser client that omits the header is accepted without restriction. An unauthenticated network attacker can connect, send a start_session message, and the server will route it to the first idle browser-extension WebSocket (effectively hijacking that session) and then broadcast all resulting automation actions and outputs back to the attacker. This enables unauthorized remote control of connected browser automation sessions, leakage of sensitive page context and automation results, and misuse of model-backed browser actions in any environment where the bridge is network-reachable. This issue has been fixed in versions 4.5.139 of PraisonAI and 1.5.140 of praisonaiagents.

Summary

praisonai browser start exposes the browser bridge on 0.0.0.0 by default, and its /ws endpoint accepts websocket clients that omit the Origin header entirely. An unauthenticated network client can connect as a fake controller, send start_session, cause the server to forward start_automation to another connected browser-extension websocket, and receive the resulting action/status stream back over that hijacked session. This allows unauthorized remote use of a connected browser automation session without any credentials.

Details

The issue is in the browser bridge trust model. The code assumes that websocket peers are trusted local components, but that assumption is not enforced.

Relevant code paths:

• Default network exposure: src/praisonai/praisonai/browser/server.py:38-44 and src/praisonai/praisonai/browser/cli.py:25-30
• Optional-only origin validation: src/praisonai/praisonai/browser/server.py:156-173
• Unauthenticated start_session routing: src/praisonai/praisonai/browser/server.py:237-240 and src/praisonai/praisonai/browser/server.py:289-302
• Cross-connection forwarding to any other idle websocket: src/praisonai/praisonai/browser/server.py:344-356
• Broadcast of action output back to the initiating unauthenticated client: src/praisonai/praisonai/browser/server.py:412-423 and src/praisonai/praisonai/browser/server.py:462-476

The handshake logic only checks origin when an Origin header is present:

origin = websocket.headers.get("origin")
if origin:
    ...
    if not is_allowed:
        await websocket.close(code=1008)
        return

await websocket.accept()

This means a non-browser client can omit Origin completely and still be accepted.

After that, any connected client can send {"type":"start_session", ...}. The server then looks for the first other websocket without a session and sends it a start_automation message:

if client_conn != conn and client_conn.websocket and not client_conn.session_id:
    await client_conn.websocket.send_text(json_mod.dumps(start_msg))
    client_conn.session_id = session_id
    sent_to_extension = True
    break

When the extension-side connection responds with an observation, the resulting action is broadcast to every websocket with the same session_id, including the unauthenticated initiating client:

action_response = {
    "type": "action",
    "session_id": session_id,
    **action,
}

for client_id, client_conn in self._connections.items():
    if client_conn.session_id == session_id and client_conn != conn:
        await client_conn.websocket.send_json(action_response)

I verified this on the latest local checkout: praisonai version 4.5.134 at commit 365f75040f4e279736160f4b6bdb2bdb7a3968d4.

PoC

I used tmp/pocs/poc.sh to reproduce the issue from a clean local checkout.

Run:

cd "/Users/r1zzg0d/Documents/CVE hunting/targets/PraisonAI"
./tmp/pocs/poc.sh

Expected vulnerable output:

[+] No-Origin client accepted: True
[+] Session forwarded to extension: True
[+] Action broadcast to attacker: True
[+] RESULT: VULNERABLE - unauthenticated client can hijack browser sessions.

Step-by-step reproduction:

1. Start the local browser bridge from the checked-out source tree.
2. Connect one websocket as a stand-in extension using a valid chrome-extension://<32-char-id> origin.
3. Connect a second websocket with no Origin header.
4. Send start_session from the unauthenticated websocket.
5. Observe that the server forwards start_automation to the extension websocket.
6. Send an observation from the extension websocket using the assigned session_id.
7. Observe that the resulting action and completion status are delivered back to the unauthenticated initiating websocket.

tmp/pocs/poc.sh:

#!/bin/sh
set -eu

SCRIPT_DIR="$(CDPATH= cd -- "$(dirname -- "$0")" && pwd)"

cd "$SCRIPT_DIR/../.."

exec uv run --no-project \
  --with fastapi…

PraisonAI is a multi-agent teams system. In versions below 4.5.139 of PraisonAI and 1.5.140 of praisonaiagents, the browser bridge (praisonai browser start) is vulnerable to unauthenticated remote session hijacking due to missing authentication and a bypassable origin check on its /ws WebSocket endpoint. The server binds to 0.0.0.0 by default and only validates the Origin header when one is present, meaning any non-browser client that omits the header is accepted without restriction. An unauthenticated network attacker can connect, send a start_session message, and the server will route it to the first idle browser-extension WebSocket (effectively hijacking that session) and then broadcast all resulting automation actions and outputs back to the attacker. This enables unauthorized remote control of connected browser automation sessions, leakage of sensitive page context and automation results, and misuse of model-backed browser actions in any environment where the bridge is network-reachable. This issue has been fixed in versions 4.5.139 of PraisonAI and 1.5.140 of praisonaiagents.

PraisonAI is a multi-agent teams system. In versions below 4.5.139 of PraisonAI and 1.5.140 of praisonaiagents, the browser bridge (praisonai browser start) is vulnerable to unauthenticated remote session hijacking due to missing authentication and a bypassable origin check on its /ws WebSocket endpoint. The server binds to 0.0.0.0 by default and only validates the Origin header when one is present, meaning any non-browser client that omits the header is accepted without restriction. An unauthenticated network attacker can connect, send a start_session message, and the server will route it to the first idle browser-extension WebSocket (effectively hijacking that session) and then broadcast all resulting automation actions and outputs back to the attacker. This enables unauthorized remote control of connected browser automation sessions, leakage of sensitive page context and automation results, and misuse of model-backed browser actions in any environment where the bridge is network-reachable. This issue has been fixed in versions 4.5.139 of PraisonAI and 1.5.140 of praisonaiagents.

Summary

praisonai browser start exposes the browser bridge on 0.0.0.0 by default, and its /ws endpoint accepts websocket clients that omit the Origin header entirely. An unauthenticated network client can connect as a fake controller, send start_session, cause the server to forward start_automation to another connected browser-extension websocket, and receive the resulting action/status stream back over that hijacked session. This allows unauthorized remote use of a connected browser automation session without any credentials.

Details

The issue is in the browser bridge trust model. The code assumes that websocket peers are trusted local components, but that assumption is not enforced.

Relevant code paths:

• Default network exposure: src/praisonai/praisonai/browser/server.py:38-44 and src/praisonai/praisonai/browser/cli.py:25-30
• Optional-only origin validation: src/praisonai/praisonai/browser/server.py:156-173
• Unauthenticated start_session routing: src/praisonai/praisonai/browser/server.py:237-240 and src/praisonai/praisonai/browser/server.py:289-302
• Cross-connection forwarding to any other idle websocket: src/praisonai/praisonai/browser/server.py:344-356
• Broadcast of action output back to the initiating unauthenticated client: src/praisonai/praisonai/browser/server.py:412-423 and src/praisonai/praisonai/browser/server.py:462-476

The handshake logic only checks origin when an Origin header is present:

origin = websocket.headers.get("origin")
if origin:
    ...
    if not is_allowed:
        await websocket.close(code=1008)
        return

await websocket.accept()

This means a non-browser client can omit Origin completely and still be accepted.

After that, any connected client can send {"type":"start_session", ...}. The server then looks for the first other websocket without a session and sends it a start_automation message:

if client_conn != conn and client_conn.websocket and not client_conn.session_id:
    await client_conn.websocket.send_text(json_mod.dumps(start_msg))
    client_conn.session_id = session_id
    sent_to_extension = True
    break

When the extension-side connection responds with an observation, the resulting action is broadcast to every websocket with the same session_id, including the unauthenticated initiating client:

action_response = {
    "type": "action",
    "session_id": session_id,
    **action,
}

for client_id, client_conn in self._connections.items():
    if client_conn.session_id == session_id and client_conn != conn:
        await client_conn.websocket.send_json(action_response)

I verified this on the latest local checkout: praisonai version 4.5.134 at commit 365f75040f4e279736160f4b6bdb2bdb7a3968d4.

PoC

I used tmp/pocs/poc.sh to reproduce the issue from a clean local checkout.

Run:

cd "/Users/r1zzg0d/Documents/CVE hunting/targets/PraisonAI"
./tmp/pocs/poc.sh

Expected vulnerable output:

[+] No-Origin client accepted: True
[+] Session forwarded to extension: True
[+] Action broadcast to attacker: True
[+] RESULT: VULNERABLE - unauthenticated client can hijack browser sessions.

Step-by-step reproduction:

1. Start the local browser bridge from the checked-out source tree.
2. Connect one websocket as a stand-in extension using a valid chrome-extension://<32-char-id> origin.
3. Connect a second websocket with no Origin header.
4. Send start_session from the unauthenticated websocket.
5. Observe that the server forwards start_automation to the extension websocket.
6. Send an observation from the extension websocket using the assigned session_id.
7. Observe that the resulting action and completion status are delivered back to the unauthenticated initiating websocket.

tmp/pocs/poc.sh:

#!/bin/sh
set -eu

SCRIPT_DIR="$(CDPATH= cd -- "$(dirname -- "$0")" && pwd)"

cd "$SCRIPT_DIR/../.."

exec uv run --no-project \
  --with fastapi…

Summary

praisonai browser start exposes the browser bridge on 0.0.0.0 by default, and its /ws endpoint accepts websocket clients that omit the Origin header entirely. An unauthenticated network client can connect as a fake controller, send start_session, cause the server to forward start_automation to another connected browser-extension websocket, and receive the resulting action/status stream back over that hijacked session. This allows unauthorized remote use of a connected browser automation session without any credentials.

Details

The issue is in the browser bridge trust model. The code assumes that websocket peers are trusted local components, but that assumption is not enforced.

Relevant code paths:

• Default network exposure: src/praisonai/praisonai/browser/server.py:38-44 and src/praisonai/praisonai/browser/cli.py:25-30
• Optional-only origin validation: src/praisonai/praisonai/browser/server.py:156-173
• Unauthenticated start_session routing: src/praisonai/praisonai/browser/server.py:237-240 and src/praisonai/praisonai/browser/server.py:289-302
• Cross-connection forwarding to any other idle websocket: src/praisonai/praisonai/browser/server.py:344-356
• Broadcast of action output back to the initiating unauthenticated client: src/praisonai/praisonai/browser/server.py:412-423 and src/praisonai/praisonai/browser/server.py:462-476

The handshake logic only checks origin when an Origin header is present:

origin = websocket.headers.get("origin")
if origin:
    ...
    if not is_allowed:
        await websocket.close(code=1008)
        return

await websocket.accept()

This means a non-browser client can omit Origin completely and still be accepted.

After that, any connected client can send {"type":"start_session", ...}. The server then looks for the first other websocket without a session and sends it a start_automation message:

if client_conn != conn and client_conn.websocket and not client_conn.session_id:
    await client_conn.websocket.send_text(json_mod.dumps(start_msg))
    client_conn.session_id = session_id
    sent_to_extension = True
    break

When the extension-side connection responds with an observation, the resulting action is broadcast to every websocket with the same session_id, including the unauthenticated initiating client:

action_response = {
    "type": "action",
    "session_id" : session_id,
    **action,
}

for client_id, client_conn in self._connections.items():
    if client_conn.session_id == session_id and client_conn != conn:
        await client_conn.websocket.send_json(action_response)

I verified this on the latest local checkout: praisonai version 4.5.134 at commit 365f75040f4e279736160f4b6bdb2bdb7a3968d4.

PoC

I used tmp/pocs/poc.sh to reproduce the issue from a clean local checkout.

Run:

cd "/Users/r1zzg0d/Documents/CVE hunting/targets/PraisonAI"
./tmp/pocs/poc.sh

Expected vulnerable output:

[+] No-Origin client accepted: True
[+] Session forwarded to extension: True
[+] Action broadcast to attacker: True
[+] RESULT: VULNERABLE - unauthenticated client can hijack browser sessions.

Step-by-step reproduction:

1. Start the local browser bridge from the checked-out source tree.
2. Connect one websocket as a stand-in extension using a valid chrome-extension://<32-char-id> origin.
3. Connect a second websocket with no Origin header.
4. Send start_session from the unauthenticated websocket.
5. Observe that the server forwards start_automation to the extension websocket.
6. Send an observation from the extension websocket using the assigned session_id.
7. Observe that the resulting action and completion status are delivered back to the unauthenticated initiating websocket.

tmp/pocs/poc.sh:

#!/bin/sh
 set -eu

SCRIPT_DIR="$(CDPATH= cd -- "$(dirname -- "$0")" && pwd)"

cd "$SCRIPT_DIR/../.."

exec uv run --no-project \
 …

Summary

praisonai browser start exposes the browser bridge on 0.0.0.0 by default, and its /ws endpoint accepts websocket clients that omit the Origin header entirely. An unauthenticated network client can connect as a fake controller, send start_session, cause the server to forward start_automation to another connected browser-extension websocket, and receive the resulting action/status stream back over that hijacked session. This allows unauthorized remote use of a connected browser automation session without any credentials.

Details

The issue is in the browser bridge trust model. The code assumes that websocket peers are trusted local components, but that assumption is not enforced.

Relevant code paths:

• Default network exposure: src/praisonai/praisonai/browser/server.py:38-44 and src/praisonai/praisonai/browser/cli.py:25-30
• Optional-only origin validation: src/praisonai/praisonai/browser/server.py:156-173
• Unauthenticated start_session routing: src/praisonai/praisonai/browser/server.py:237-240 and src/praisonai/praisonai/browser/server.py:289-302
• Cross-connection forwarding to any other idle websocket: src/praisonai/praisonai/browser/server.py:344-356
• Broadcast of action output back to the initiating unauthenticated client: src/praisonai/praisonai/browser/server.py:412-423 and src/praisonai/praisonai/browser/server.py:462-476

The handshake logic only checks origin when an Origin header is present:

origin = websocket.headers.get("origin")
if origin:
    ...
    if not is_allowed:
        await websocket.close(code=1008)
        return

await websocket.accept()

This means a non-browser client can omit Origin completely and still be accepted.

After that, any connected client can send {"type":"start_session", ...}. The server then looks for the first other websocket without a session and sends it a start_automation message:

if client_conn != conn and client_conn.websocket and not client_conn.session_id:
    await client_conn.websocket.send_text(json_mod.dumps(start_msg))
    client_conn.session_id = session_id
    sent_to_extension = True
    break

When the extension-side connection responds with an observation, the resulting action is broadcast to every websocket with the same session_id, including the unauthenticated initiating client:

action_response = {
    "type": "action",
    "session_id" : session_id,
    **action,
}

for client_id, client_conn in self._connections.items():
    if client_conn.session_id == session_id and client_conn != conn:
        await client_conn.websocket.send_json(action_response)

I verified this on the latest local checkout: praisonai version 4.5.134 at commit 365f75040f4e279736160f4b6bdb2bdb7a3968d4.

PoC

I used tmp/pocs/poc.sh to reproduce the issue from a clean local checkout.

Run:

cd "/Users/r1zzg0d/Documents/CVE hunting/targets/PraisonAI"
./tmp/pocs/poc.sh

Expected vulnerable output:

[+] No-Origin client accepted: True
[+] Session forwarded to extension: True
[+] Action broadcast to attacker: True
[+] RESULT: VULNERABLE - unauthenticated client can hijack browser sessions.

Step-by-step reproduction:

1. Start the local browser bridge from the checked-out source tree.
2. Connect one websocket as a stand-in extension using a valid chrome-extension://<32-char-id> origin.
3. Connect a second websocket with no Origin header.
4. Send start_session from the unauthenticated websocket.
5. Observe that the server forwards start_automation to the extension websocket.
6. Send an observation from the extension websocket using the assigned session_id.
7. Observe that the resulting action and completion status are delivered back to the unauthenticated initiating websocket.

tmp/pocs/poc.sh:

#!/bin/sh
 set -eu

SCRIPT_DIR="$(CDPATH= cd -- "$(dirname -- "$0")" && pwd)"

cd "$SCRIPT_DIR/../.."

exec uv run --no-project \
 …