A restricted Komodo user with permission to view logs can reach a shell on a managed server through Periphery, the agent Komodo uses to manage Docker hosts. The CERT/CC vulnerability note describes an OS command injection flaw in request handling: some values a user supplies for an allowed operation enter a shell command without escaping. On a typical root-run Periphery host, that crosses from a narrow Komodo grant to commands with root privileges.
The affected environment is a multi-user Komodo deployment with restricted accounts holding the relevant grants and Periphery older than 2.3.0. The CVE Program record identifies the issue as CVE-2026-110005 and lists the affected range starting at 1.19.1; Komodo’s statement in the CERT/CC note calls all releases before 2.3.0 affected and names verified vulnerable releases through 2.2.0. The vendor says, “If your installation has only admin users, you are not affected.” That qualification concerns privilege escalation inside Komodo’s permission model.
How a log request reaches shell
Komodo’s vendor statement names SearchContainerLog, SearchStackLog and the equivalent Swarm service log search. A user with Read and the specific Logs permission on a Server, Stack or Deployment can call these paths. Periphery built a Docker log search command by inserting request-supplied container or service names and search terms into a shell string. Shell interpretation of those values gives the caller command execution as the Periphery process user, bypassing the narrower grant. The CERT/CC overview also names the container-destruction path, DestroyContainer / RemoveContainer.
RunStackService requires Execute on a Stack; its service, workdir, user, entrypoint and environment values entered a shell command. Komodo also describes Swarm secret and configuration creation fields that reached a shell through a heredoc. A handler using the non-shell execution path avoided this command-execution route, though a name beginning with a dash could still be treated as a Docker option. This is why reviewing log searches alone would miss part of the affected permission surface.
Which Komodo accounts need review
Identify restricted users with Read plus Logs on Server, Stack or Deployment resources, and those with Execute on a Stack. Map those resources to their Periphery servers and check the running agent version on each server. The vendor also describes a separate exception: a directly exposed Periphery instance without its passkey can let a user reach the endpoints without a Komodo account. Protect direct agent access while inventorying those hosts.
When operations and host telemetry are retained, correlate use of the named handlers with unexpected processes launched by Periphery on the same host. The vendor’s permission review helps narrow who could reach the handlers, but its statement is explicit: “Workarounds: None.” Reducing grants alone leaves an affected agent version in place.
Upgrade the agents and verify
Upgrade Periphery on managed servers to 2.3.0 or later. Komodo says the fix shell-escapes supplied values, replaces the affected heredoc with a pipe and puts -- before positional arguments to prevent option injection. Recheck the Logs and Execute grants after the upgrade; remove unnecessary grants. For hosts with suspicious activity, preserve the available agent-operation and host-process records and investigate the host before returning it to normal service.
Confirm each managed server is running Periphery 2.3.0 or later and compare its restricted-user grants with the access you intend to allow.