What is the CVSS score of CVE-2026-48099?

CVE-2026-48099 has a CVSS 3.1 base score of 7.1 (High). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L. EPSS exploitation probability: 0.1%.

Which versions of WsgiDAV are affected by CVE-2026-48099?

WsgiDAV 4.3.3 contains a path traversal vulnerability enabling attackers to read, write, and delete files outside the configured file-share directory, exposing sensitive organizational data and…. A patch is available.

How to fix or mitigate CVE-2026-48099?

Within 24 hours: Inventory systems running WsgiDAV 4.3.3; restrict network access to WebDAV endpoints from untrusted sources if immediate patching is not feasible. Within 7 days: Upgrade all instances to WsgiDAV 4.3.4. Within 30 days: Validate patch deployment across all systems and review access logs for suspicious file operations during the unpatched window.

WsgiDAV CVE-2026-48099

HIGH

Path Traversal (CWE-22)

2026-06-11 https://github.com/mar10/wsgidav

GHSA-wxq4-cc2q-338q

Path Traversal Authentication Bypass

7.1

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

7.1 HIGH

AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L

vuln.today AI

7.1 HIGH

Network-reachable WebDAV (AV:N); requires prefix-colliding sibling path and encoded-segment passthrough (AC:H); anonymous or authenticated WebDAV access needed (PR:L); arbitrary read/write/delete on outside files yields C:H/I:H and limited A:L.

3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L

4.0 AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N

Primary rating from GitHub Advisory.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L

Attack Vector

Network

Attack Complexity

High

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

Low

Lifecycle Timeline

Source Code Evidence Fetched

Jun 11, 2026 - 20:52 vuln.today

Analysis Generated

Jun 11, 2026 - 20:52 vuln.today

DescriptionGitHub Advisory

Impact

WsgiDAV 4.3.3 can allow a WebDAV request path containing an encoded parent-directory segment to escape the configured filesystem share root in a specific path layout.

Patches

The issue is fixed with version 4.3.4.

Preconditions

The practical impact depends on the deployment.

The deployment uses a filesystem-backed WsgiDAV share.

The attacker can send WebDAV requests accepted by that share. This may be an anonymous share or an authenticated WebDAV user. This is not an authentication bypass.

Details

The issue is in FilesystemProvider._loc_to_file_path(). The method builds a candidate path with os.path.abspath(os.path.join(root_path, *path_parts)), then checks containment with file_path.startswith(root_path). This is not path-boundary aware. For example, if the configured share root is /tmp/share, a resolved sibling path such as /tmp/share_evil/secret.txt still starts with the string /tmp/share.

In a local proof, this allowed GET, PUT, and DELETE requests to operate on files outside the configured share root.

The WSGI/server layer forwards the encoded dot segment to WsgiDAV's PATH_INFO. The local proof used /%2e%2e/..., which wsgiref passed through as /../....

A sibling or neighboring path exists whose absolute path starts with the configured root path string, such as /tmp/share and /tmp/share_evil.

The WsgiDAV process has OS permissions for the outside path.

AnalysisAI

Path traversal in WsgiDAV 4.3.3 allows WebDAV clients to read, write, or delete files outside the configured filesystem share root when a sibling directory's name shares a prefix with the share root. The flaw lives in FilesystemProvider._loc_to_file_path(), which performs a string-prefix containment check instead of a path-boundary-aware one, and is reachable via URL-encoded dot segments such as /%2e%2e/. No public exploit is identified at time of analysis, but a proof-of-concept is described in the vendor advisory and a vendor-released patch exists (4.3.4).

Technical ContextAI

WsgiDAV is a generic WebDAV server written in Python (distributed via PyPI as pkg:pip/wsgidav) commonly used to expose filesystem directories over HTTP. The vulnerable code path is FilesystemProvider._loc_to_file_path(), which composes a candidate path with os.path.abspath(os.path.join(root_path, *path_parts)) and then validates containment via file_path.startswith(root_path). This is a classic CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) implementation mistake: string-prefix matching is not directory-boundary aware, so a sibling such as /tmp/share_evil/secret.txt satisfies startswith('/tmp/share') even though it is outside the share. The encoded ../ payload reaches the provider because the WSGI/server layer (wsgiref in the proof-of-concept) decodes %2e%2e in PATH_INFO before WsgiDAV applies its containment check.

RemediationAI

Vendor-released patch: WsgiDAV 4.3.4 - upgrade via 'pip install --upgrade wsgidav>=4.3.4' as tracked in the advisory at https://github.com/mar10/wsgidav/security/advisories/GHSA-wxq4-cc2q-338q and commit f894ed8656d7bdd7438ab8148c5a02546cb15183. Where immediate upgrade is not possible, choose share root paths that cannot collide with neighboring directory names (for example, use a dedicated parent directory with no sibling whose name begins with the same string, or append a trailing separator-safe suffix) so that the startswith() check cannot match a sibling; this is a workaround only, has no functional side effect, and does not address the underlying bug. Additionally, restrict the OS permissions of the WsgiDAV process to the share directory only (drop read/write on parents and siblings) to limit blast radius, accepting that this may break legitimate uses that rely on broader filesystem access, and front the service with a reverse proxy that normalizes/rejects encoded dot segments (%2e%2e) in PATH_INFO, noting this may break clients that legitimately rely on encoded paths.