Plane CVE-2026-105641

Exploitation requires that the target was deployed using the deployments/aio/community/ or deployments/cli/community/ manifests AND that the operator never overrode the shipped SECRET_KEY (default '60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5') or LIVE_SERVER_SECRET_KEY (default 'htbqvBJAgpm9bzvf3r4urJer0ENReatceh'). The top-level setup.sh randomizes secrets ONLY for the development Docker Compose path, so aio/cli community installs retain the shared production secrets by default. Limiting factors that reduce real-world exposure: instances deployed via the dev Compose path, instances where an operator explicitly set unique secrets, and instances upgraded to 1.4.0 (which auto-generates and persists a random key on first boot) are NOT exploitable; reachability also requires the instance to be network-accessible to the attacker.

All exploitability signals point in the same direction and reinforce a genuinely high priority for the affected population. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) describes a network-reachable, low-complexity, unauthenticated flaw, and CWE-798 (use of hard-coded credentials) makes that plausible because the SECRET_KEY and LIVE_SERVER_SECRET_KEY defaults are literally published in the shipped manifests and now visible in the fix commit/diff - anyone can read them without research effort, which justifies AC:L. However, the raw 9.8 overstates the UNIVERSAL risk: exploitation is strictly conditional on the operator having deployed the aio or cli community manifests AND never overriding the secrets, so this behaves less like a blanket remote RCE and more like an insecure-default that silently affects a subset of self-hosted instances. No EPSS score, KEV listing, or SSVC decision data was provided in the input, so automatable/technical-impact framing cannot be derived; their ABSENCE is not evidence of low risk, only missing telemetry. The 'source code evidence' is the vendor patch diff, NOT a weaponized exploit, so this is not confirmed active exploitation. Net: a real, high-priority issue for anyone running unmodified Plane community Docker deployments, but the real-world blast radius is gated by configuration rather than being every Plane install.

An attacker identifies an internet-reachable Plane instance that was stood up from the deployments/aio/community/ or deployments/cli/community/ manifests, then uses the publicly-known default SECRET_KEY to forge a Django-signed session or token (e.g. a password-reset or auth cookie) and authenticates as an existing user or administrator. Separately, the known LIVE_SERVER_SECRET_KEY lets the attacker bypass live-service authentication on the same unchanged deployment. No public proof-of-concept exploit was provided - the GitHub source evidence is the remediation patch, not attack code.