Xoscar actor control-plane exposure

The boundary that failed

An unauthenticated peer reaching an exposed actor-pool port could request configuration and topology information or stop an actor pool. The application’s HTTP login did not protect this separate internal transport.

The maintainer’s advisory describes get_config returning topology, module configuration and configured subprocess environment dictionaries, which may contain sensitive values. The stop operation can shut down a pool.

The contribution and the public credit

I reported the related unauthenticated control-plane exposure. The maintainers included that report in their combined advisory and list joshua-bluestine as a reporter.

The combined advisory is CVE-2026-49950 / GHSA-mmvj-m246-m9vf. Its critical rating and title concern a separate deserialization issue; they should not be read as the severity or description of my control-plane contribution.

Read the maintainer advisory and reporter credits →

Mitigation is a configuration decision, too.

Xoscar 0.12.0 introduced opt-in actor-transport authentication using XOSCAR_AUTH_KEY. A strong, nonempty key must be configured on communicating processes, and actor ports must be restricted to intended peers.

An unset or empty key retains unauthenticated behavior. Upgrading alone does not enable the protection. The shared key establishes trusted peers; it does not introduce separate permissions for each control operation. Consult the maintainer advisory for current deployment guidance.

What this means for an AI product review

A product can enforce login on its public API and still expose privileged internal functions elsewhere. Mapping the services behind the product is part of understanding where identity, data and actions cross boundaries.

The AI agent and LLM security review applies that perspective to retrieval, tools and integrations. The SaaS and API review examines roles, tenant isolation and application workflows.