GHSA-6wjp-v33h-5cvq: Infoleak
Summary
The AgentOS server in the praisonai TypeScript/npm package ships an insecure default: it binds 0.0.0.0, sets no API key, and uses CORS with credentials. The API-key middleware is only registered when an API key is configured, so the documented quickstart (new AgentOS({agents:[...]}).serve({port})) exposes, unauthenticated, GET /api/agents (which leaks agent names/roles/instructions, i.e. system prompts) and POST /api/chat (which invokes agents). Any network peer can read agent system prompts and drive the agent. Runtime-confirmed; severity High.
Details
Affected component - Package: praisonai (npm / TypeScript). Files src/praisonai-ts/src/os/config.ts and src/praisonai-ts/src/os/agentos.ts (AgentOS).
Vulnerable code / root cause
Path: src/praisonai-ts/src/os/config.ts
Class/const: DEFAULTAGENTOSCONFIG / mergeConfig
Snippet: ts export const DEFAULTAGENTOSCONFIG = { host: '0.0.0.0', corsOrigins: [''], apiKey: '', // ... }; // mergeConfig: apiKey = userConfig?.apiKey ?? process.env.PRAISONAIAGENTOSAPIKEY ?? ''; Issue: defaults bind all interfaces, with an empty API key and wildcard CORS. apiKey stays empty unless the developer explicitly sets it.
Path: src/praisonai-ts/src/os/agentos.ts
Function: serve / registerRoutes (Express app)
Snippet: ts if (this.config.apiKey) { // auth middleware ONLY added when apiKey is set app.use((req,res,next) => { / 401 unless Bearer/x-auth-token matches / }); } // routes: app.get(${apiPrefix}/agents, ...) // returns name/role/instructions app.post(${apiPrefix}/chat, ...) // calls agent.chat(message) Issue: the only auth gate is conditional on a non-empty apiKey. With the default empty key, no auth middleware is registered, and GET /api/agents (system-prompt disclosure) and POST /api/chat (agent invocation) are served to any network client. CORS sets Access-Control-Allow-Credentials: true with a wildcard origin.
Attack flow 1. Developer deploys AgentOS via the quickstart without setting apiKey/PRAISONAIAGENTOSAPIKEY. 2. Any network peer calls GET /api/agents → receives agent instructions/system prompts. 3. Any network peer calls POST /api/chat → invokes the agent.
Why existing protection is bypassed There is no protection in the default config — the auth gate is skipped when apiKey is empty (the default), and the server binds all interfaces.
Security boundary Unauthenticated network access to agent metadata + invocation. This is the CVE-2026-44338 anti-pattern recurring in the TS package, and worse (0.0.0.0 is the default).
Proof of Concept
Environment Real AgentOS from src/praisonai-ts run via ts-node in a node container with default config (stub agent, no LLM needed). 127.0.0.1:18000. Runnable assets: PraisonAI-Runtime-Repro\runtime-files\ (docker-compose.agentos.yml).
Steps to reproduce 1. PRAI-01-01-AgentOS-Agents-NoAuth: GET /api/agents (no Authorization) → 127.0.0.1:18000. 2. PRAI-01-02-AgentOS-Chat-NoAuth: POST /api/chat {"message":"hello from attacker"} (no Authorization).
Expected result Non-loopback exposure should require authentication; agent instructions should not be disclosed unauthenticated.
Actual result - GET /api/agents → 200, leaks "instructions":"SYSTEM PROMPT SECRET ... PRAISONAIINTERNALSECRETCANARY7f3a91"; response header Access-Control-Allow-Credentials: true. - POST /api/chat → 200, agent invoked ("response":"...PRAISONAIAGENTOSCANARY7f3a91...").
Screenshots
Unauthenticated /api/agents leaks agent instructions
A GET request to /api/agents succeeds without an Authorization header. The response exposes agent metadata and instructions, including the canary system-prompt value.
<img width="1535" height="829" alt="01-AgentOS-Agents-NoAuth" src="https://github.com/user-attachments/assets/705087e1-8017-46f6-9a91-edb8312e2f26" />
Unauthenticated /api/chat invokes the agent
A POST request to /api/chat succeeds without an Authorization header. The response confirms that the attacker-controlled message was processed by the configured agent.
<img width="1537" height="833" alt="02-AgentOS-Chat-NoAuth" src="https://github.com/user-attachments/assets/5cdf8f56-b8d8-498b-87bd-44834f39998c" />
Reproduction assets
The attached archive contains the local Docker runtime used to reproduce the issue with controlled canary values only. It does not contain real secrets, third-party API keys, or production credentials.
PraisonAI-Runtime-Repro.zip
Impact Unauthenticated disclosure of agent configuration/system prompts; unauthenticated agent invocation; LLM cost abuse; possible tool abuse depending on the configured agent's tools; permissive CORS-with-credentials.
Suggested remediation - Default host to 127.0.0.1; require apiKey (fail closed) when binding non-loopback. - Do not default corsOrigins to [''], especially with Access-Control-Allow-Credentials: true. - Do not return full instructions on an unauthenticated endpoint.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/praisonaito a version that resolves this vulnerability.Fixed in 1.7.3 - Configuration
Default host to 127.0.0.1; require a non-empty apiKey and fail closed when binding to a non-loopback address.
PraisonAI AgentOS host = 127.0.0.1 - Configuration
Require apiKey authentication whenever AgentOS binds to a non-loopback address; do not skip the authentication middleware when apiKey is empty.
PraisonAI AgentOS apiKey = required for non-loopback binding - Configuration
Do not default corsOrigins to ['*'], especially when Access-Control-Allow-Credentials is true.
PraisonAI AgentOS corsOrigins = explicit, non-wildcard origins - Configuration
Do not return full agent instructions or system prompts from an unauthenticated endpoint.
PraisonAI AgentOS /api/agents instructions response = not returned unauthenticated
Event History
Frequently Asked Questions
Is the documented quickstart configuration affected?
Yes. Starting AgentOS with new AgentOS({agents:[...]}).serve({port}) uses the insecure defaults unless configuration or environment settings override them.
Who can exploit an exposed instance?
Any network peer that can reach the AgentOS server can access it without authentication when no API key is configured. No privileges or user interaction are required.
What can an unauthenticated requester do?
They can call GET /api/agents to retrieve agent names, roles, and instructions, including system prompts. They can also call POST /api/chat to invoke agents.
How can I check whether an instance is exposed?
Check whether AgentOS is bound to 0.0.0.0 and whether its API key resolves to an empty value. An affected instance permits unauthenticated requests to /api/agents and /api/chat.
What configuration changes reduce exposure if immediate patching is not possible?
Configure a non-empty API key so the API-key middleware is registered. Avoid the default all-interface bind and wildcard CORS configuration; restrict network binding and allowed origins to those required.