CVE-2026-118994 in CallBackery
Summary
by MITRE • 10/30/2026
CallBackery versions before 0.62.0 for Perl allow log injection via newlines in the login name.
login() writes the login name to the application log without escaping control characters. The login RPC method needs no authentication, so a name containing a newline followed by text in the log record format adds a forged record.
An unauthenticated attacker can forge log records, such as a successful administrator login from an address of their choosing.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in CallBackery versions prior to 0.62.0 represents a significant security flaw rooted in improper input validation and logging practices. Specifically, the application is susceptible to Log Injection attacks when processing user credentials during the authentication process. The core technical issue lies within the login() function, which writes the provided login name directly into the application log files without performing any sanitization or escaping of control characters. This lack of data cleansing allows an attacker to inject arbitrary newline sequences and subsequent text that conforms to the expected log record format. Because the system fails to distinguish between legitimate user input and injected formatting commands, it treats the malicious payload as a valid new entry in the log stream rather than part of the username string itself.
From an operational perspective, this vulnerability is exacerbated by the fact that the login RPC method does not require authentication prior to processing the request. This design decision creates an unauthenticated attack vector, allowing any external actor with network access to interact with the endpoint and attempt injection attacks without needing valid credentials first. The ability to inject newlines effectively breaks the single-line structure of typical log entries, enabling the attacker to append a second line that mimics a complete log record. This capability transforms what might otherwise be a minor data integrity issue into a severe security incident involving potential deception and forensic obstruction.
The impact of this vulnerability is primarily centered on the manipulation of audit trails and system logs. An unauthenticated attacker can forge log records, such as creating false entries that indicate a successful administrator login from an IP address controlled by the attacker. This capability allows for sophisticated social engineering or cover-up operations where malicious activities are masked behind legitimate-looking administrative actions. Conversely, attackers could also inject fake failure messages to trigger unnecessary alerts and distract security teams. The integrity of the logging system is compromised, which undermines its value as a primary source for incident response, forensic analysis, and compliance auditing. Security analysts cannot trust these logs to accurately reflect actual authentication events or user activities within the application.
This flaw aligns with CWE-117, Improper Output Neutralization for Logs, which describes vulnerabilities where an attacker can inject newlines into log entries to create fake records. It also relates to CWE-20, Improper Input Validation, as the system fails to restrict or sanitize special characters in user-supplied data before processing. In terms of offensive security frameworks, this vulnerability facilitates actions associated with ATT&CK technique T1562, Impair Defenses, specifically under the subtechnique of Log Injection. By manipulating logs, an attacker can obscure their presence and activities from defenders who rely on these records for detection and monitoring.
To mitigate this risk, immediate remediation is required by upgrading CallBackery to version 0.62.0 or later, where the developers have presumably addressed the input handling in the login function. In environments where an upgrade is not immediately feasible, a compensating control should be implemented at the application code level to ensure that all user-supplied data written to logs is strictly sanitized. This involves escaping or removing newline characters and other control codes before they are passed to the logging subsystem. Additionally, implementing input validation rules that reject usernames containing non-alphanumeric characters can further reduce the attack surface. From a defensive architecture standpoint, it is advisable to separate application logic from log generation by using structured logging formats such as JSON or syslog with strict field definitions, which inherently prevent newline injection because fields are delimited rather than relying on line breaks for record separation.