CVE-2026-62251 in Homer
Summary
by MITRE • 10/07/2026
Homer is open source telecom observability software. Prior to version 11.0.283, the `V4StatisticsQuery` handler passes the user-supplied `rawquery` field directly to DuckDB without calling the `sqlvalidator.ValidateRawSQL` function used throughout the rest of the codebase. Any authenticated user can execute arbitrary SQL statements against all data accessible through the FlightSQL service. Version 11.0.283 patches the issue.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
Homer is an open-source software solution designed for telecom observability, providing insights into network performance and status. A critical security vulnerability was identified in versions prior to 11.0.283 within the V4StatisticsQuery handler component of this application. This specific flaw represents a significant deviation from the established secure coding practices implemented elsewhere in the codebase, leading to severe consequences for data integrity and confidentiality. The core technical issue stems from how user-supplied input is processed during query execution operations. Specifically, when handling requests directed at the V4StatisticsQuery endpoint, the application accepts a parameter named rawquery which contains SQL statements provided by the client. In secure implementations within this software suite, such inputs are typically passed through a validation function called sqlvalidator.ValidateRawSQL to ensure that only syntactically correct and semantically safe queries are executed against the underlying database engine.
The vulnerability arises because the V4StatisticsQuery handler bypasses this crucial security control mechanism. Instead of validating the rawquery parameter using the standard sqlvalidator, the code passes it directly to DuckDB, which is the embedded analytical database used by Homer for storing and querying telemetry data. This direct passthrough allows an attacker who has successfully authenticated to the application to inject arbitrary SQL commands. Because there is no sanitization or validation layer intercepting these inputs before they reach the database engine, the application fails to distinguish between legitimate statistical queries and maliciously crafted injection payloads. This lack of input validation creates a classic Injection vulnerability where user-controlled data influences the execution logic of backend systems without proper checks.
From an operational perspective, this flaw grants any authenticated user extensive privileges over the underlying DuckDB instance. Since the V4StatisticsQuery handler interacts with all data accessible through the FlightSQL service, an attacker can read sensitive network metrics, configuration details, and potentially other proprietary information stored within the observability platform. Beyond simple data exfiltration, depending on the specific capabilities of the DuckDB version and its integration layer, this could also allow for unauthorized modification or deletion of critical records. The impact is particularly severe because authentication serves as the only barrier; once a user bypasses identity verification through stolen credentials or other means, they gain full control over the data exposure surface defined by the FlightSQL service permissions.
This vulnerability aligns with Common Weakness Enumeration (CWE) category CWE-89, which describes Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. Furthermore, within the MITRE ATT&CK framework, this behavior corresponds to techniques involving Data from Information Repositories or potentially T1059 Command and Scripting Interpreter if further exploitation leads to broader system compromise via linked services. The failure to apply consistent security controls across different endpoints indicates a gap in the application's defense-in-depth strategy, where some paths are hardened while others remain exposed due to oversight during development or refactoring processes.
To mitigate this risk, organizations running Homer versions prior to 11.0.283 must upgrade immediately to version 11.0.283 or later, which includes the patch that restores the use of sqlvalidator.ValidateRawSQL for all query handlers including V4StatisticsQuery. Until an upgrade is feasible, administrators should enforce strict network segmentation to limit access to the Homer interface and ensure that only trusted internal users can authenticate. Additionally, implementing Web Application Firewall rules that detect common SQL injection patterns in POST body parameters may provide a temporary layer of defense against automated exploitation attempts. Regular security audits focusing on input validation consistency across all API endpoints are recommended to prevent similar oversights in future development cycles.