CVE-2026-45221 in Konga
Summary
by MITRE • 09/01/2026
Konga before 2.1.0 contains a privilege escalation vulnerability that allows low-privileged local attackers to execute arbitrary code by planting attacker-controlled OpenSSL configuration or library files in a hardcoded filesystem path absent from default installations. On Windows, the missing directory resides in a location writable by any authenticated local user, enabling attackers to create the directory and place malicious files that execute at the privilege level of the user or service account that launches Konga, facilitating privilege escalation.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in versions of Konga prior to 2.1.0 represents a critical security flaw rooted in improper handling of external configuration resources during runtime initialization. This issue is classified under CWE-94 as Improper Control of Generation of Code or Command, specifically involving the injection of malicious content through trusted paths that are not adequately secured against unauthorized modification. The core technical failure lies in Konga's reliance on hardcoded filesystem paths for loading OpenSSL configurations and library files without verifying their integrity or ownership prior to use. In default installation scenarios, these specific directories do not exist by design, creating a gap between expected behavior and actual system state where the application assumes safe defaults that are absent from the operating environment.
On Windows systems, this architectural oversight manifests as a significant privilege escalation vector because the missing directory resides in a location accessible to any authenticated local user. When Konga attempts to load these resources during startup or operation, it does not perform sufficient checks to ensure that the target path is either non-existent or securely locked down by administrative privileges. Instead, if an attacker with standard user-level credentials can create the expected directory structure and populate it with malicious OpenSSL configuration files or library binaries, the application will inadvertently process these inputs as legitimate system resources. This behavior allows low-privileged local attackers to execute arbitrary code within the context of the Konga process.
The operational impact of this vulnerability is severe due to its potential for privilege escalation. By exploiting this flaw, an attacker can achieve remote code execution or elevated privileges depending on how the Konga service is configured and launched. If Konga runs under a high-privilege service account, such as Local System or Administrator, the malicious files will execute with those same elevated rights, granting the attacker full control over the underlying operating system. Even if running under a standard user context, the ability to inject code into an application process can facilitate further lateral movement within a networked environment or lead to data exfiltration and persistence mechanisms that compromise overall infrastructure security.
This vulnerability aligns with MITRE ATT&CK technique T1059 Command and Scripting Interpreter, as it involves executing arbitrary commands through manipulated configuration files, and relates to T1078 Valid Accounts when considering the requirement for local authentication access. The exploitation chain typically follows a pattern where an attacker first gains initial foothold via standard user credentials, then identifies the specific path Konga expects for OpenSSL resources, creates that directory structure with write permissions, and finally places crafted malicious files designed to be loaded by the vulnerable application logic.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. The primary recommendation is to upgrade immediately to version 2.1.0 or later of Konga, where this path validation issue has been addressed through improved security controls that prevent loading from untrusted locations. For environments unable to update promptly, administrators should ensure that the hardcoded directories referenced by Konga are either explicitly created with restrictive permissions owned only by the service account running Konga, or removed entirely if not required for functionality. Additionally, implementing strict file integrity monitoring on application configuration paths can help detect unauthorized modifications before they trigger malicious execution. Regular audits of default installation practices and adherence to least-privilege principles when configuring service accounts will further reduce the attack surface associated with such path traversal vulnerabilities.