GL.iNet WebDAV COPY/MOVE Auth Bypass

Overview

CVE-2026-19979 is a remotely exploitable authorization bypass affecting the WebDAV service embedded in GL.iNet’s consumer and prosumer router firmware across seventeen distinct hardware models, including the AX1800, MT6000, BE10000, and XE3000 series. The vulnerability resides specifically in how the firmware handles COPY and MOVE HTTP method requests: the service correctly gates read access to public share directories but fails to apply equivalent destination-path authorization checks when a client requests that content be relocated. This asymmetry allows an unauthenticated or low-privileged remote attacker to maneuver files into — or out of — filesystem locations that should be inaccessible.

The flaw was discovered through targeted research into GL.iNet’s WebDAV implementation and was confirmed by the vendor, who acknowledged in their own disclosure that “the vulnerability described… does indeed exist.” GL.iNet has published a formal advisory in their CVE issues repository, indicating the issue was responsibly disclosed before public announcement. Firmware branches up to and including 4.8.x are affected across all listed hardware SKUs, which collectively represent a sizeable deployment base in home offices, small businesses, and travel networking scenarios.

The CVSS 3.x score of 8.3 (High) reflects that the attack is network-reachable, requires no user interaction, and yields meaningful impact on both integrity and confidentiality. Confidentiality and integrity impacts are rated High, with availability rated as partial, consistent with an attacker who can read or overwrite sensitive files but cannot trivially brick the device through this vector alone.

Technical Analysis

WebDAV extends HTTP/1.1 with additional methods — among them COPY and MOVE — that operate on two distinct resource identifiers: the request URI (source) and the Destination header (target). A correct authorization model must validate both. GL.iNet’s firmware implementation applies access control to the source URI when serving GET or PROPFIND requests, but the Destination header in COPY/MOVE operations passes through a separate — and less guarded — code path.

The root cause is a missing authorization gate on destination-path resolution. When the WebDAV handler receives a MOVE request, it resolves the Destination header to an absolute filesystem path and performs the operation without running that resolved path through the same permission check applied to the source. In practice, the vulnerable logic resembles the following pattern:

/* Simplified pseudocode representative of the vulnerable pattern */
int handle_webdav_move(Request *req) {
    const char *src_path  = resolve_path(req->uri);
    const char *dest_path = resolve_path(req->header("Destination"));

    /* Authorization check applied ONLY to source */
    if (!is_authorized(req->user, src_path)) {
        return HTTP_403_FORBIDDEN;
    }

    /* Destination path used directly — no authorization check */
    return fs_rename(src_path, dest_path);
}

Because dest_path is derived from attacker-controlled input (the Destination request header) and is never validated against the session’s permission scope, an attacker can supply a path outside the intended public share — for example /etc/, /overlay/, or a mounted USB partition directory not exposed via the share configuration. The resolve_path() call canonicalizes the URL but does not enforce a chroot-style boundary, compounding the issue.

A minimal proof-of-concept request pattern illustrates the bypass:

MOVE /public-share/document.txt HTTP/1.1
Host: 192.168.8.1
Destination: http://192.168.8.1/restricted/sensitive-config/document.txt
Overwrite: T

Because the source URI (/public-share/document.txt) passes the authorization check, execution proceeds to fs_rename() with the attacker-supplied destination. The same logic flaw applies to COPY, enabling read-equivalent access to arbitrary paths by copying content into the publicly accessible share directory first, then retrieving it via a standard GET.

Impact

The practical attack surface is significant. An attacker with network access to the router’s WebDAV service — typically exposed on the LAN interface, but potentially reachable over WAN depending on firewall configuration — can:

• Exfiltrate configuration files: By issuing a COPY that places /etc/config/network, /etc/shadow, or OpenWrt UCI configuration files into the public share, an attacker gains credentials, network topology data, and VPN pre-shared keys.
• Overwrite critical files: A MOVE or COPY with Overwrite: T targeting active configuration paths can alter routing tables, DNS settings, or firewall rules, achieving persistent network-level man-in-the-middle positioning.
• Pivot within multi-segment networks: Many affected models (MT5000, XE3000, BE-series) are deployed in multi-WAN or VLAN-segmented environments; credential exfiltration from these devices can enable lateral movement into otherwise isolated network zones.

The CVSS vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L reflects the absence of any meaningful pre-conditions: no account is required, no special network position is needed beyond reaching the WebDAV port, and no user must be deceived into taking an action.

How to Fix It

Firmware Upgrade: The primary remediation is to update to a firmware version beyond 4.8.x once GL.iNet releases a patched build. Users should monitor the GL.iNet firmware release page for their specific model and apply updates via the LuCI admin panel or gl_upgrade CLI utility.

Correct Authorization Pattern: The destination path must be subject to the same permission validation as the source. The fixed logic should enforce a scope boundary on both operands:

/* Corrected handler — authorization applied to BOTH source and destination */
int handle_webdav_move(Request *req) {
    const char *src_path  = resolve_path(req->uri);
    const char *dest_path = resolve_path(req->header("Destination"));

    /* Validate source */
    if (!is_authorized(req->user, src_path)) {
        return HTTP_403_FORBIDDEN;
    }

    /* Validate destination against the SAME share scope */
    if (!is_within_allowed_share(dest_path, req->user->share_root)) {
        return HTTP_403_FORBIDDEN;
    }

    /* Optional: verify dest_path is fully canonicalized and contains no
       path traversal sequences before reaching the filesystem layer */
    if (!is_canonicalized_within(dest_path, req->user->share_root)) {
        return HTTP_400_BAD_REQUEST;
    }

    return fs_rename(src_path, dest_path);
}

Mitigating Controls (short-term):

• Disable WebDAV if not required via GL Admin Panel → Applications → File Sharing → Disable.
• Restrict WebDAV to LAN-only access using firewall rules that drop inbound traffic to port 80/443 WebDAV endpoints from WAN.
• Enforce authenticated-only WebDAV sessions; eliminate anonymous/public share configurations until patched firmware is available.

Our Take

This vulnerability exemplifies a class of authorization flaw that recurs whenever a protocol exposes compound operations with multiple resource identifiers: the developer authoring the handler validates the “entry” resource but treats the “exit” resource — the destination — as implicitly trusted because it came through the same authenticated connection. It does not. The Destination header is entirely attacker-controlled, and any code that consumes it must re-enter the full authorization pipeline.

For enterprises deploying embedded Linux devices at network boundaries, this case underscores that router firmware warrants the same rigorous secure development lifecycle applied to server-side applications. WebDAV on network edge devices is a particularly high-value target because these devices often sit at trust boundaries between network zones, hold credentials for managed infrastructure, and are infrequently patched.

From a DAST perspective, this class of bug is readily detectable during active testing: any test harness that enumerates HTTP methods and then fuzzes secondary headers — particularly Destination, If, and Lock-Token — against both in-scope and out-of-scope paths will surface the authorization gap. Organizations running embedded device testing programs should ensure WebDAV method coverage is explicit in their test plans.

Detection with SAST

This vulnerability maps to CWE-863: Incorrect Authorization and secondarily to CWE-22: Path Traversal when the destination resolution involves unsanitized user input. SAST tooling should flag the following patterns in firmware codebases:

• Unpaired authorization calls: Any function that resolves a Destination or secondary URL header to a filesystem path without a subsequent call to an authorization or boundary-check function. SAST data-flow rules should trace the taint from http_header("Destination") through resolve_path() to rename(), copy_file(), or equivalent syscalls, and raise a finding when no sanitizer or permission gate intercepts the flow.
• Asymmetric guard coverage: Functions that call is_authorized() or equivalent once for a dual-operand filesystem operation. Rules enforcing that authorization checks appear once per resource operand — not once per request — catch this pattern structurally.
• CWE-863 rule category: Offensive360’s SAST engine flags taint flows from network-derived path inputs to privileged filesystem operations where the sanitization function set does not include both a canonicalization step and a scope-boundary assertion. This compound rule fires regardless of whether the path input arrives via URI or secondary header.

Embedding these checks into CI pipelines targeting OpenWrt and embedded Linux firmware build systems ensures regressions in this category are caught before release rather than after deployment to hundreds of thousands of network-edge devices.

References

• GL.iNet CVE Issues — WebDAV Public-Share Destination Authorization Bypass
• VulDB CVE-2026-19979
• VulDB Submission 873915
• VulDB Vulnerability 391161
• VulDB Vulnerability 391161 — CTI