CVE-2026-55509 in wsgidav
Summary
by MITRE • 08/28/2026
WsgiDAV is a generic and extendable WebDAV server based on WSGI. Prior to 4.3.5, the sample MySQLBrowserProvider in wsgidav/samples/mysql_dav_provider.py concatenates the record key parsed from a request URL directly into SQL WHERE clauses. The affected _exists_record_by_primary_key, _get_field_by_primary_key, and _get_record_by_primary_key methods are part of a shipped example provider that is not enabled by default. An attacker who can access a share explicitly configured with this non-default provider can inject SQL through a normal GET request; anonymously exposed read shares permit a status-code oracle and extraction of arbitrary data reachable by the configured MySQL account. This issue is fixed in version 4.3.5.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in WsgiDAV versions prior to 4.3.5 represents a critical SQL injection flaw within its sample database provider implementation. WsgiDAV serves as a generic and extendable WebDAV server built on the Python Web Server Gateway Interface, allowing for flexible integration with various storage backends. Among these integrations is the MySQLBrowserProvider located in the samples directory at wsgidav/samples/mysql_dav_provider.py. While this specific provider is not enabled by default configuration, its presence as a shipped example introduces risk if administrators choose to deploy it without adequate security review or sanitization of input parameters. The core technical flaw lies in how the application handles data retrieved from HTTP request URLs. Specifically, when processing requests that target database records via their primary keys, the server concatenates these parsed key values directly into SQL WHERE clauses rather than employing parameterized queries or prepared statements. This practice violates fundamental secure coding principles and creates a direct pathway for malicious actors to manipulate backend database operations.
The affected methods within this provider include _exists_record_by_primary_key, _get_field_by_primary_key, and _get_record_by_primary_key. These functions are responsible for querying the MySQL database based on identifiers extracted from client requests. Because the input is treated as executable SQL code rather than a literal string value, an attacker can craft specific GET request URLs containing maliciously constructed primary key values. By injecting SQL syntax into these parameters, it becomes possible to alter the logic of the underlying queries. This capability allows for unauthorized data access and manipulation, effectively bypassing intended application-level security controls that rely on proper authentication and authorization checks within the database layer itself.
The operational impact of this vulnerability is significant when an attacker gains access to a share explicitly configured with the vulnerable MySQLBrowserProvider. In scenarios where such shares are exposed anonymously or with read-only permissions, the consequences escalate beyond simple data leakage. An adversary can perform status-code oracle attacks by observing HTTP response codes generated in reaction to different SQL payloads. This technique enables the extraction of arbitrary data accessible by the database account used by WsgiDAV. Even without immediate full control over the server operating system, the ability to read sensitive information from the backend MySQL instance constitutes a severe breach of confidentiality and integrity. The vulnerability aligns with CWE-89 Improper Neutralization of Special Elements used in an SQL Command, highlighting the failure to properly sanitize user-supplied input before its inclusion in database queries.
From a threat modeling perspective, this exploitation vector corresponds to techniques found within the MITRE ATT&CK framework, particularly those related to Database Access and Data Exfiltration via Web Application Attacks. The ability to infer data through side-channel effects like HTTP status codes is characteristic of blind SQL injection scenarios often categorized under T1059 Command and Scripting Interpreter or more specifically database interaction techniques depending on the exact payload used. To mitigate this risk, organizations deploying WsgiDAV must ensure that any custom providers are reviewed for secure coding practices before production use. The immediate remediation involves upgrading to version 4.3.5 of WsgiDAV, where the developers have addressed this issue by implementing proper input handling mechanisms such as parameterized queries. Additionally, administrators should avoid enabling sample providers in production environments unless they have been thoroughly audited and hardened against injection attacks.