Portainer CE EUVD-2026-33007

Attacker must hold an authenticated, non-administrative Portainer CE account that has been assigned access to at least one Docker endpoint, and that endpoint must still carry the insecure default EndpointSecuritySettings (AllowBindMountsForRegularUsers, AllowPrivilegedModeForRegularUsers, AllowHostNamespaceForRegularUsers, AllowContainerCapabilitiesForRegularUsers, AllowDeviceMappingForRegularUsers, and AllowSysctlSettingForRegularUsers all true) - these are applied automatically to any endpoint created on a pre-fix build unless an administrator manually disabled them. Passive user interaction (UI:P) is required per the CVSS vector, consistent with normal authenticated use of the Portainer web UI. Exploitation is LIMITED by the requirement for a pre-existing endpoint-scoped Portainer user account and a Docker-type endpoint (the host-breakout primitives are Docker-specific); deployments where every Portainer user is an admin, or where non-admins were never granted endpoint access, are not exposed. Administrators who previously hardened endpoint security settings by hand are also not affected even on vulnerable code.

CVSS v4.0 base score 8.5 with vector AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H reflects a network-reachable, low-complexity attack requiring low privileges (a non-admin Portainer account with endpoint access) and passive user interaction, yielding full confidentiality/integrity/availability impact on both the vulnerable system and downstream (the Docker host beyond Portainer's trust boundary). Threat metric E:P indicates proof-of-concept exploit code exists. EPSS and CISA KEV status were not provided in the input; absence of a KEV listing means there is no confirmed widespread exploitation, but the bar to abuse is low for any insider or compromised low-privilege account. The UI:P requirement is the only meaningful brake - exploitation requires the attacker to already hold a Portainer account on the affected endpoint, so external risk depends entirely on how broadly user accounts are provisioned. This is a real priority for any multi-tenant Portainer deployment; in single-admin home-lab setups the practical risk is much lower.

A non-admin Portainer user with assigned access to a Docker endpoint authenticates to the Portainer UI, creates a new container from any image, and in the advanced options enables a bind mount of /:/host (or sets the container to privileged mode with the host PID namespace). Once the container starts, they chroot into /host or use nsenter from the privileged context to read /etc/shadow, install SSH keys for root, or pivot into the host. Publicly available exploit code exists per CVSS threat metrics.