Docker Dependency (CVE-2026-42306, CVE-2026-41567, and CVE-2026-41568)

[RichardSlater]

Docker Go module CVE assessment

Date: 2026-05-19

Summary

eirctl depends on github.com/docker/docker v28.5.2+incompatible, which is currently reported as affected by CVE-2026-42306, CVE-2026-41567, and CVE-2026-41568 in versions <= 28.5.2. No patched version of the Go module is currently available.

Based on the current eirctl codebase, the vulnerable Docker daemon code paths are not invoked by eirctl. The project uses the Docker Go client to create, start, attach to, stream logs from, inspect, stop, remove, and pull containers. It does not use Docker archive copy APIs such as CopyToContainer, CopyFromContainer, ContainerArchive, or PutContainerArchive, and it does not implement a docker cp equivalent.

Our position is that the dependency should remain tracked as a remediation item, but the known exploit preconditions for these CVEs are not met by eirctl's current Docker integration.

Dependency usage

The direct Docker module imports are limited to the container runner implementation:

• runner/executor_container.go
• runner/container_opts_unix.go
• runner/container_opts_windows.go
• runner/container_auth.go
• associated tests in runner/executor_container_test.go

The runtime Docker API surface used by eirctl is:

• image pull with registry authentication;
• container create and start;
• container attach for interactive shell mode;
• container resize for interactive terminal sessions;
• container logs streaming;
• container wait and inspect;
• container stop and remove.

The code does not call archive upload, archive download, or copy APIs.

CVE exposure assessment

CVE	Reported vulnerable behavior	eirctl usage assessment	Exploitability through eirctl
CVE-2026-42306	docker cp / archive copy race condition can redirect file operations to unintended host paths.	eirctl does not call Docker copy/archive APIs or provide a copy-to/from-container feature.	Not exploitable through current eirctl code paths.
CVE-2026-41567	Docker daemon archive upload processing may resolve decompression helpers from a container-controlled path, allowing host code execution when uploading compressed archives to a malicious container.	eirctl does not upload archives into containers. It starts containers with bind mounts and streams process output only.	Not exploitable through current eirctl code paths.
CVE-2026-41568	docker cp / archive copy race condition can write files outside the intended container boundary.	eirctl does not invoke Docker copy/archive functionality.	Not exploitable through current eirctl code paths.

eirctl can run untrusted container images if a user chooses to configure them, and it can bind mount host paths into those containers when container mounting is enabled. That is a separate and expected container-runner trust boundary: a malicious image can act on any writable host paths explicitly mounted into it. This is not the vulnerable Docker archive/copy behavior described by the CVEs above.

Current risk position

The current risk is assessed as low for eirctl itself because:

1. The vulnerable API class is not used.
2. The project does not expose Docker daemon access as a network service.
3. Container images, mounts, users, capabilities, extra hosts, and registry authentication are provided by local configuration and passed to the Docker daemon without using archive copy operations.

The residual risk is dependency and environment based:

1. Security scanners will continue to report the vulnerable module until an upstream patched release is available and adopted.
2. A future eirctl feature that copies files into or out of containers could introduce exposure if implemented using affected Docker archive APIs before an upstream fix is available.
3. The host Docker daemon may still be vulnerable to these CVEs when other tools or users invoke docker cp or archive upload APIs against malicious containers.

Remediation plan

1. Track the upstream Docker/Moby advisory and update github.com/docker/docker as soon as a patched version is released.
2. Until a patched module is available, document this assessment in vulnerability management records as "not exploitable through current eirctl usage" rather than suppressing the finding without context.
3. Do not add Docker copy/archive functionality to eirctl while the dependency remains unpatched. If such functionality becomes necessary, require a dedicated security review before implementation.
4. Prefer trusted, pinned container images in eirctl configuration, especially where bind mounts are enabled.
5. Keep host Docker daemon access restricted to trusted users and automation identities; eirctl users with Docker socket access effectively have elevated host capabilities independent of these CVEs.
6. Re-run dependency scanning after each Docker module update and revise this report if the upstream vulnerability details or eirctl's Docker API usage changes.

Review triggers

Reassess this position if any of the following occur:

• github.com/docker/docker publishes a patched version for these CVEs;
• eirctl adds file copy, archive upload, archive download, image export/import, or build-context upload functionality;
• the project starts exposing Docker API operations through a service boundary;
• new advisory details identify additional affected APIs beyond Docker archive/copy handling.