CVE-2026-54135: AirSane has a Remote Denial of Service (OOM) via Unvalidated Content-Length in HTTP Server
AirSane is a SANE frontend, and a scanner server that supports Apple's AirScan protocol. Versions prior to 0.4.12 have a vulnerability in the custom HTTP server implementation of AirSane that allows a remote unauthenticated attacker to cause a Denial of Service (DoS) via memory exhaustion (OOM). In httpserver.cpp, the HttpServer::Request::content function reads the Content-Length header and directly passes this value to std::string::resize() without any upper-bound validation or safe parsing. An attacker can send an HTTP POST request with an artificially large Content-Length value. This forces the daemon to attempt allocating gigabytes of memory, resulting in a std::badalloc exception and immediately crashing the AirSane process. Additionally, providing non-numeric characters in the Content-Length header leads to undefined behavior (NaN to integer conversion) due to the lack of error handling during header parsing. Version 0.4.12 patches the issue.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
AirSaneto a version that resolves this vulnerability.Fixed in 0.4.12
Event History
Frequently Asked Questions
Which deployments are exposed to remote exploitation?
AirSane versions earlier than 0.4.12 are exposed if an attacker can send HTTP requests to the AirSane daemon. Exploitation does not require authentication or user interaction.
What request is needed to trigger the denial of service?
An attacker can send an HTTP POST request with an artificially large Content-Length value, causing the process to attempt a very large memory allocation and crash with std::bad_alloc. A Content-Length header containing non-numeric characters can also trigger undefined behavior during parsing.
What is the impact of a successful attack?
The AirSane process immediately crashes due to memory exhaustion, resulting in denial of service. The provided data indicates no confidentiality or integrity impact.
What should be done if an immediate upgrade is not possible?
Restrict network access to the AirSane HTTP service so untrusted systems cannot send HTTP requests to it. The described attack is network-based and unauthenticated, so limiting reachable clients reduces exposure.
How can I determine whether the issue is fixed?
Version 0.4.12 patches the issue. Deployments running versions prior to 0.4.12 should be treated as affected.