Loading vulnerability…
Portainer Community Edition contains a missing authorization flaw in its Docker plugin management proxy handling. In affected versions from 2.33.0 before 2.33.8, before 2.39.2, and before 2.41.0, requests to Docker plugin management endpoints under /plugins/* were not registered in Portainer’s proxy authorization handler map. As a result, requests to those endpoints were forwarded directly to the underlying Docker daemon without the intended Portainer access-control checks. An authenticated non-admin Portainer user with RBAC-granted access to a Docker endpoint could invoke privileged plugin operations such as pulling, installing, and enabling arbitrary Docker plugins. Because Docker plugins run on the host with elevated privileges and declared mounts/capabilities, successful exploitation can lead to operating-system-level code execution on the Docker host.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
Small repository containing a single Python PoC and a README. The exploit targets CVE-2026-44848 in Portainer, where Docker plugin management routes are not protected by Portainer's RBAC proxy handlers. The script is self-contained, uses only Python standard library modules, disables TLS verification, and drives the Portainer HTTPS API directly. Repository structure: README.md documents the vulnerability, affected versions, lab setup, and intended safe behavior; portainer_plugin_poc.py is the only code file and the clear entry point. The script workflow is linear: create an HTTPS opener, initialize or log in as admin, create or recover a standard user named bob, enumerate or create a Docker endpoint backed by unix:///var/run/docker.sock, grant bob endpoint access, authenticate as bob, then request /api/endpoints/{id}/docker/plugins. A 200 response is treated as confirmation that a non-admin user can access privileged plugin endpoints. It then optionally attempts POST /api/endpoints/{id}/docker/plugins/pull with plugin name vieux/sshfs to demonstrate the next step toward host RCE, but it does not enable a plugin or execute arbitrary commands. Main exploit capability: authorization bypass against Portainer's proxied Docker plugin endpoints, allowing a lower-privileged user to perform privileged plugin operations. The README explains the security impact: Docker plugins may request CAP_SYS_ADMIN and host mounts, so successful plugin pull/enable can lead to root-equivalent execution on the Docker host. In practice, this PoC safely proves the primitive rather than delivering a destructive payload. It is therefore an operational exploit PoC for confirming the bypass and demonstrating the path to host RCE.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
2 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.