SECURITYCRITICALCVE-2026-71805

CVE-2026-71805: LZ-litchi Unauthenticated Arbitrary File Upload

LZ-litchi 1.0.0 lets unauthenticated attackers upload arbitrary files outside the storage directory via a path-traversal flaw in its upload API.

Dylan H.

Security Team

September 10, 2026
3 min read
CVE-2026-71805: LZ-litchi Unauthenticated Arbitrary File Upload

Critical severity

Rated critical. Prioritise patching — see the remediation guidance below.

Affected Products

  • LZ-litchi v1.0.0

Overview

A critical arbitrary file upload and path traversal vulnerability has been disclosed in LZ-litchi 1.0.0. Tracked as CVE-2026-71805, the flaw allows unauthenticated remote attackers to upload arbitrary files and write them outside the intended storage directory via the directory parameter in POST /app-api/infra/file/upload.

The vulnerability was published to the National Vulnerability Database on September 9, 2026, with a CVSS score of 9.8. Because no authentication is required and the upload endpoint is reachable directly over the network, this is a pre-auth flaw that is straightforward to weaponize at scale.


Technical Details

FieldValue
CVE IDCVE-2026-71805
SeverityCritical (CVSS 9.8)
Attack VectorNetwork
AuthenticationNone Required
Vulnerable EndpointPOST /app-api/infra/file/upload
Weakness ClassesCWE-434 (Unrestricted Upload of File with Dangerous Type), CWE-22 (Path Traversal)
Affected ProductLZ-litchi 1.0.0

How It Works

The /app-api/infra/file/upload endpoint accepts a directory parameter that controls where an uploaded file is written on disk. LZ-litchi fails to validate or canonicalize this parameter, so an attacker can supply directory-traversal sequences (for example, repeated ../ segments) to redirect the write operation outside the intended upload directory.

Combined with the lack of file-type restrictions on the upload itself, this allows an unauthenticated attacker to plant an arbitrary file — including a server-side script — at a location of their choosing on the filesystem. If that location is reachable by the web server (such as a web root or an executable script directory), the uploaded file can subsequently be invoked to achieve remote code execution.


Impact Assessment

Who Is At Risk

Any internet-facing or internally-reachable deployment of LZ-litchi 1.0.0 with the file upload API enabled is vulnerable. No authentication or user interaction is required to exploit the flaw.

Potential Attack Chains

  1. Unauthenticated Upload — Attacker sends a crafted POST request to /app-api/infra/file/upload with a traversal sequence in the directory parameter
  2. Arbitrary Write — The uploaded file (for example, a web shell) is written outside the intended storage path, potentially into a web-accessible or executable directory
  3. Remote Code Execution — Attacker requests the planted file directly, triggering execution on the server
  4. Lateral Movement — Server-level access is used to pivot to adjacent systems, databases, or credential stores

This attack pattern aligns with MITRE ATT&CK techniques for server-side component installation (web shell deployment) followed by command execution.


Mitigation

Immediate Actions

  • Upgrade LZ-litchi to a patched release that validates and canonicalizes the directory parameter before writing uploaded files
  • If no patch is yet available, restrict or disable the /app-api/infra/file/upload endpoint at the reverse proxy or WAF until remediated
  • Deny path-traversal sequences (../, encoded variants) in upload-related request parameters via WAF rules as a stopgap

Detection Opportunities

  • Monitor for POST requests to /app-api/infra/file/upload containing ../ or URL-encoded traversal sequences in the directory parameter
  • Alert on newly created files in web-accessible directories that do not correspond to expected application uploads
  • Review server logs for requests to unexpected, recently-created file paths shortly after suspicious upload activity

Defence-in-Depth

  • Run the application server with the minimum filesystem privileges required
  • Store uploads outside the web root and serve them only through an application-controlled handler that validates file type and path
  • Implement file-type allow-listing and content inspection on all upload endpoints

References