Konga CVE-2026-45221

The attacker must be an authenticated local or domain user on the Windows host where Konga is installed - remote, unauthenticated exploitation is not possible. The specific prerequisite is the absence of the hardcoded OpenSSL directory from the default Konga installation, combined with the Windows DACL on the parent path permitting any authenticated user to create subdirectories. Exploitation requires the ability to write files to the filesystem (standard user capability on Windows) and to wait for or trigger a Konga restart or launch. Limiting factors: this is Windows-only; Linux/macOS deployments are not described as vulnerable. The privilege gain depends entirely on how Konga is deployed - if launched as an interactive user rather than a privileged service, the attacker gains no additional privileges beyond their own. Exploitation is also limited to hosts where Konga is installed, reducing the attack surface to that specific software's deployment footprint.

The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) scoring 8.5 accurately reflects the realistic threat model: local access with low privileges is sufficient, complexity is low, and no attack requirements or user interaction are needed beyond planting the files. The primary risk amplifier is that Konga may run as a privileged service account (e.g., LOCAL SYSTEM or a dedicated service identity), meaning a low-privileged attacker who plants files can achieve privilege escalation to that service context - a meaningful step up. Conversely, if Konga runs only as an interactive user-launched application, the privilege gain is limited to that user's own token, reducing the severity. The description's phrasing 'privilege level of the user or service account that launches Konga' leaves this ambiguous; defenders should verify how Konga is deployed in their environment. No EPSS data, KEV listing, or public POC was provided, and given Konga's niche market footprint, opportunistic mass exploitation is implausible. Risk is realistic primarily in shared Windows environments (RDS, Citrix, multi-user terminal servers) or where Konga runs as a privileged service.

An attacker with a standard domain or local user account on a Windows host running Konga identifies the hardcoded OpenSSL path is absent and that the parent directory is world-writable. They create the missing directory, copy a malicious OpenSSL DLL or crafted openssl.cnf into it, then wait for Konga to be restarted (e.g., at next system boot or service cycle). When Konga initializes OpenSSL, it loads the attacker's file and executes attacker-controlled code at the privilege level of the Konga service account. No public POC has been identified at time of analysis.