CVE-2026-103436 in apcupsd
Summary
by MITRE • 09/30/2026
apcupsd through 3.14.14 discloses uninitialized stack memory in getupsvar() in src/cgi/upsfetch.c (used by upsstats.cgi, multimon.cgi, and upsfstats.cgi. On the single-field path, when the matched STATUS line has fewer than three whitespace-separated tokens, sscanf("%*s %*s %s", answer) performs no assignment but the function returns success, and thus the caller prints the uninitialized destination buffer into the HTTP response.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/30/2026
The vulnerability identified in apcupsd versions through 3.14.14 represents a critical information disclosure flaw located within the cgi/upsfetch.c module, specifically affecting functions such as upsstats.cgi, multimon.cgi, and upsfstats.cgi that rely on the getupsvar() routine to retrieve status variables from Uninterruptible Power Supply devices. This issue stems from improper handling of input data parsing logic when interacting with the UPS hardware interface via serial or network connections. The core technical defect lies in how the function processes STATUS lines returned by the device, particularly under conditions where the expected format is not strictly adhered to by the connected hardware or simulated environment.
When the getupsvar() function attempts to extract specific data fields from a received line using sscanf with the format string "%s %s %s", it expects at least three whitespace-separated tokens in the input buffer. The first two tokens are skipped via pointer suppression, while the third is intended to be stored into a destination buffer provided by the caller. However, if the STATUS line contains fewer than three tokens, sscanf fails to perform any assignment operation on that destination buffer due to format mismatch or insufficient data availability. Despite this failure in parsing and lack of successful variable population, the function erroneously returns a success status code rather than an error indicator. This logical inconsistency creates a state where the calling CGI scripts proceed under the assumption that valid data has been retrieved and populated into their respective buffers.
Consequently, when these CGI scripts generate HTTP responses to present UPS statistics or monitoring information to users via web browsers, they output the contents of the destination buffer without verifying whether it was actually initialized by sscanf. Since C does not automatically zero-initialize stack variables unless explicitly done so by the developer, this buffer contains residual data from previous function calls on the same stack frame. This results in the leakage of uninitialized stack memory into the HTTP response body sent to the client. The disclosed information may include sensitive internal application state, previously processed UPS metrics, or other confidential data stored in adjacent memory locations that were not cleared before reuse.
From a security classification perspective, this vulnerability aligns with CWE-200: Exposure of Sensitive Information to an Unauthorized Actor and CWE-457: Use of Uninitialized Variable. The attack vector is classified under ATT&CK technique T1005: Data from Local System as the attacker can retrieve internal system data through a web interface without requiring authentication if the CGI scripts are publicly accessible, or with low privileges if access controls are in place but insufficient to prevent reading these specific endpoints. The impact extends beyond simple information leakage; it facilitates further reconnaissance by revealing details about the underlying operating system architecture, memory layout, and potentially other running processes that share stack space characteristics.
Mitigation strategies must focus on correcting the logic flow within getupsvar() to ensure that success is only returned when data has been successfully parsed and assigned. Developers should implement strict validation checks after sscanf calls to verify return values indicating successful field extraction before proceeding with buffer usage. Additionally, initializing all local buffers to zero immediately upon declaration eliminates the risk of leaking stale stack data regardless of parsing outcomes. Updating apcupsd to version 3.14.15 or later resolves this issue as it includes patches for these specific code paths. For systems where immediate patching is not feasible, restricting access to upsstats.cgi and related CGI scripts through firewall rules or web server configuration can reduce the attack surface by limiting exposure to untrusted networks until a permanent fix is deployed.