CVE-2026-54237 in Wavelog
Summary
by MITRE • 09/18/2026
Wavelog is web-based amateur radio logging software. From 1.8 until 2.4.2, Wavelog exposes /install/ajax.php and /install/includes/interface_assets/triggers.php after installation without an installation lock or permission check. Unsanitized input reaches write_config() and write_configfile() in install/includes/core/core_class.php, allowing a remote unauthenticated attacker to read or write log files and place attacker-controlled content into PHP configuration files. The resulting PHP configuration content can execute on the server. This issue is fixed in version 2.4.2.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in Wavelog, specifically affecting versions from 1.8 through 2.4.2, represents a critical failure in post-installation security controls and input validation mechanisms within this web-based amateur radio logging software. The core of the issue lies in the improper handling of installation-related endpoints after the initial setup process has been completed. Specifically, the application continues to expose sensitive administrative scripts such as /install/ajax.php and /install/includes/interface_assets/triggers.php without implementing any form of installation lock or permission verification. In a properly secured web application, these types of configuration management interfaces should be permanently disabled or inaccessible once the software is deployed to ensure that only authorized administrators can modify system settings. The absence of this check allows remote unauthenticated attackers to interact with these endpoints as if they were still in the initial setup phase, effectively bypassing authentication requirements entirely.
The technical flaw extends beyond mere access control failures into severe input validation deficiencies within the core configuration handling logic. When an attacker interacts with the exposed installation scripts, unsanitized user-supplied data is passed directly to internal functions such as write_config() and write_configfile(), located in install/includes/core/core_class.php. These functions are responsible for writing settings to PHP configuration files on the server's file system. Because there is no sanitization or validation of the input parameters before they are processed, an attacker can inject arbitrary content into these configuration files. This lack of data integrity checks means that malicious payloads crafted by the attacker are written directly to disk without any filtering of dangerous characters or code structures.
The operational impact of this vulnerability is severe due to its potential for Remote Code Execution (RCE). By manipulating PHP configuration files, an attacker can introduce executable PHP code into the application's runtime environment. Since these configuration files are often included by other parts of the web application during normal operation, any malicious content placed within them will be executed with the privileges of the web server process. This allows a remote unauthenticated actor to gain full control over the underlying system hosting Wavelog. The attacker can read sensitive log files containing amateur radio communications data, modify application behavior, or deploy additional malware such as backdoors and web shells. Given that amateur radio logging software may contain personal information about operators and their activities, this also poses a significant privacy risk alongside the technical compromise of the server infrastructure.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, specifically regarding the failure to restrict access to administrative functions after initialization is complete. It also strongly correlates with CWE-94 Improper Control of Generation of Code (Code Injection), as unsanitized input leads directly to code execution via configuration file manipulation. In terms of adversary tactics, this exploit path maps to MITRE ATT&CK techniques such as T1053 Scheduled Task/Job which can be leveraged for persistence if the attacker modifies system-level configurations, and more broadly T1190 Exploit Public-Facing Application, where an unauthenticated user exploits a flaw in internet-facing software. The ability to read log files also touches upon data exfiltration capabilities inherent in many post-exploitation frameworks.
To mitigate this vulnerability, organizations running Wavelog must immediately upgrade to version 2.4.2 or later, which includes the necessary patches for these access control and input validation flaws. For environments where upgrading is not immediately feasible, temporary mitigations should be implemented at the web server level. This involves configuring the reverse proxy or web server software, such as Nginx or Apache, to deny all external HTTP requests targeting paths under /install/. Additionally, administrators should ensure that file permissions on configuration files are set strictly according to the principle of least privilege, preventing write access by the web service user where possible, although this is often difficult in dynamic PHP applications. Regular security audits and penetration testing focusing on post-installation workflows can help identify similar misconfigurations in other legacy or custom-built amateur radio software solutions before they are exploited in production environments.