Cockpit CMS CVE-2026-105217

Exploitation requires an active man-in-the-middle position on the outbound network path from the Cockpit server to its configured site_url, because the cron.php web-worker restart request disables TLS peer and host verification (CURLOPT_SSL_VERIFYPEER=false, CURLOPT_SSL_VERIFYHOST=0). The attacker must be positioned to intercept that specific egress connection and must catch it while a cron-triggered worker restart is in flight. Limiting factors: the vulnerability is only reachable from an adjacent/on-path network location (not arbitrary remote Internet attackers), attack complexity is high, and the only gain is disclosure of the worker/web/token - there is no direct code execution or data read. Affected versions are Cockpit CMS 2.12.0 up to (not including) 2.14.1.

This is a genuinely low-priority vulnerability despite the CWE-295 (improper certificate validation) classification, and all available signals agree. The vendor-supplied CVSS 4.0 vector (CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N) scores only 2.3 (Low): while exploitation is unauthenticated (PR:N), it requires an adjacent network position (AV:A), high attack complexity (AC:H), and a present attack requirement (AT:P) - namely an active man-in-the-middle foothold on the outbound path from the Cockpit server to its configured site_url. The impact is confined to low confidentiality (VC:L) with no integrity or availability effect, consistent with the description: the attacker can capture the worker/web/token and (mis)start the web worker, but cannot directly read data or alter the system. No EPSS score was supplied; there is no CISA KEV listing and no public proof-of-concept referenced, so the exploitation status is 'no public exploit identified at time of analysis.' There is no conflict among the signals - low CVSS, no KEV, no POC, and a demanding prerequisite (MITM on the server's egress path) all point the same direction. The primary caveat is that the token disclosed could enable follow-on worker control, so the real-world consequence depends on what that token authorizes; verify token scope with the vendor if Cockpit is deployed on untrusted network paths.

An attacker who already controls a hop on the network path between a Cockpit server and its configured site_url (e.g. a compromised router, rogue Wi-Fi, or ARP-spoofed LAN segment) waits for cron.php to issue its worker-restart request. Because cron.php sets CURLOPT_SSL_VERIFYPEER=false and CURLOPT_SSL_VERIFYHOST=0, the attacker presents any TLS certificate, terminates the connection, and reads the worker/web/token from the request URL. No public exploit code was identified, and the adjacent position plus high complexity make this opportunistic rather than scalable.