DB-GPT CodeAction executed model-generated code in its own application container

The DB-GPT CodeAction runner used the presence of a Docker container as a condition to execute generated Python or shell in the current application process environment instead of a disposable sandbox.

CVE-2026-123018 reports LLM-generated code reaching service-container subprocesses with a permissive approval path. Container execution does not itself establish compromise of the physical host.

The danger is not that a model is able to propose Python; that can be a legitimate coding-agent function. The trust boundary fails when the DB-GPT CodeAction runner treats the fact that it is already inside Docker as a reason to execute generated code locally rather than inside a separate confined executor. In that configuration, the action inherits the DB-GPT service's network reach, environment and filesystem mounts. The advisory describes an exploitable code path, but its broad label of remote execution still depends on a reachable workflow that triggers CodeAction. No physical host escape or field victim was demonstrated, and an application's own container is not a security boundary against code run inside that same application.

The misleading safety signal is the mere presence of Docker. Under the reported conditional, detecting that DB-GPT itself runs inside a container selects native subprocess execution inside that same application environment, not a fresh isolated sandbox. A model-generated CodeAction can therefore inherit the service's mounts and credentials. This is separate from DB-GPT's unsafe skill-template rendering and remote model-code loading: those are additional entry points, but none of the advisories establishes that they were chained in a deployed compromise.