Details
## 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:
`DEFAULT_AGENTOS_CONFIG` / `mergeConfig`
Snippet:
```ts
export const DEFAULT_AGENTOS_CONFIG = {
host: '0.0.0.0',
corsOrigins: ['*'],
apiKey: '',
// ...
};
// mergeConfig: apiKey = userConfig?.apiKey ?? process.env.PRAISONAI_AGENTOS_API_KEY ?? '';
```
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`/`PRAISONAI_AGENTOS_API_KEY`.
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 ... PRAISONAI_INTERNAL_SECRET_CANARY_7f3a91"`; response header `Access-Control-Allow-Credentials: true`.
- `POST /api/chat` → `200`, agent invoked (`"response":"...PRAISONAI_AGENTOS_CANARY_7f3a91..."`).
### 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](https://github.com/user-attachments/files/29143421/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.
EPSS, exploit probability
Low0.48%
estimated chance of real-world exploitation in the next 30 days, higher than 39.3% of every CVE FIRST.org scores
Refreshed 10/9/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.