Summary
PraisonAI: AgentOS defaults to network-exposed no-auth mode, allowing unauthenticated agent invocation and instruction disclosure
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). Filessrc/praisonai-ts/src/os/config.tsandsrc/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:
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:
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
- Developer deploys AgentOS via the quickstart without setting
apiKey/PRAISONAI_AGENTOS_API_KEY. - Any network peer calls
GET /api/agents→ receives agent instructions/system prompts. - 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
PRAI-01-01-AgentOS-Agents-NoAuth:GET /api/agents(no Authorization) →127.0.0.1:18000.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 headerAccess-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.
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.
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.
Suggested remediation
- Default
hostto127.0.0.1; requireapiKey(fail closed) when binding non-loopback. - Do not default
corsOriginsto['*'], especially withAccess-Control-Allow-Credentials: true. - Do not return full
instructionson an unauthenticated endpoint.
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.
A critical operation is accessible without requiring any authentication. Typical impact: any user can invoke the privileged function.
CVE-2026-61426 has a CVSS score of 8.6 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.7.3); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-61426? CVE-2026-61426 is a high-severity missing authentication for critical function vulnerability in praisonai (npm), affecting versions < 1.7.3. It is fixed in 1.7.3. A critical operation is accessible without requiring any authentication.
- How severe is CVE-2026-61426? CVE-2026-61426 has a CVSS score of 8.6 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of praisonai are affected by CVE-2026-61426? praisonai (npm) versions < 1.7.3 is affected.
- Is there a fix for CVE-2026-61426? Yes. CVE-2026-61426 is fixed in 1.7.3. Upgrade to this version or later.
- Is CVE-2026-61426 exploitable, and should I be worried? Whether CVE-2026-61426 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-61426 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-61426? Upgrade
praisonaito 1.7.3 or later.