Description

Lektor through 3.3.14 and 3.4.0b15 contains an absolute path traversal vulnerability in the admin API on Windows that allows attackers to escape the project directory by supplying drive-letter paths that cleanup_path does not normalise. Attackers can use a malicious web page with cross-site requests or DNS rebinding against the unauthenticated local server to recursively delete directories via deleterecord or write attacker-controlled files via newattachment.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.8",
  "pubDate": "2026-11-06T15:17:19.363Z",
  "pubdate": "2026-11-06T15:17:19.363Z",
  "executiveSummary": "Lektor versions through 3.3.14 and 3.4.0b15 are susceptible to an absolute path traversal vulnerability specifically on the Windows platform.\nThe flaw originates from insufficient sanitization within the 'cleanup_path' function, allowing attackers to bypass the intended project directory restrictions by utilizing drive-letter paths.\nThis vulnerability is critical because it permits arbitrary file system access, including recursive directory deletion and the unauthorized creation or overwriting of files.\nExploitation can be achieved through cross-site requests (CSRF) or DNS rebinding techniques against an unauthenticated local Lektor server instance.\nThe primary risk implications involve complete filesystem compromise, potential remote code execution via malicious file writes, and data loss through unauthorized directory deletion.\nThe attack is viable against local users who interact with malicious web pages while the Lektor admin API is exposed.",
  "technicalDetails": "The vulnerability resides within the Lektor admin API's handling of path inputs on Windows operating systems. The core issue is the failure of the 'cleanup_path' function to properly normalize or restrict paths that include Windows drive letters (e.g., 'C:\\').\nUnder normal operating conditions, the admin API is intended to constrain file operations to the project directory. However, because 'cleanup_path' does not account for absolute paths containing drive designations, the application fails to validate if the requested path resides within the project root.\nThe attack flow leverages the unauthenticated state of the local admin API. An attacker can use a malicious web page to perform cross-site requests or utilize DNS rebinding to interact with the local service. By sending specifically crafted requests to the 'deleterecord' or 'newattachment' endpoints, an attacker can supply absolute paths.\nWhen targeting 'deleterecord', the flawed path validation allows the application to resolve and process recursive deletion commands outside the project directory, resulting in arbitrary directory removal. When targeting 'newattachment', the attacker can bypass directory restrictions to write arbitrary files to any location on the system accessible by the Lektor process.\nThe exploitation process typically involves: 1) Identifying a running local Lektor instance; 2) Crafting a payload targeting the admin API endpoints that uses an absolute path instead of a relative one; 3) Triggering the request via a malicious web page viewed by the user, effectively leveraging the victim's local context to execute unauthorized filesystem modifications.\nThe vulnerability is present in versions through 3.3.14 and 3.4.0b15. Because the flaw is rooted in path resolution logic, any functionality relying on 'cleanup_path' for input sanitization is potentially affected by this bypass. The impact is significant as it elevates a local file manipulation issue to a broad arbitrary file system control capability."
}