Lektor CVE-2026-75418

The Lektor development or preview HTTP server must be running on a Windows host and must be bound to a network-accessible interface (i.e., not restricted to 127.0.0.1/localhost). The installed Lektor version must be below 3.3.14. No authentication is required - the dev server imposes no access controls. Exploitation is constrained to Windows only; the path traversal leverages Windows-specific path separator normalization behavior, so Linux and macOS deployments are not affected by this vulnerability. The attack is read-only: no file write, code execution, or privilege escalation capability is conferred. The primary limiting factor in typical deployments is that the Lektor dev server is designed for local development use and should not ordinarily be reachable from untrusted networks; deliberate or accidental binding to 0.0.0.0 or a named network interface is required to expose the attack surface.

The CVSS 7.5 (High) score with AV:N/AC:L/PR:N/UI:N accurately reflects the technical severity when the Lektor development server is exposed on a network-accessible interface - no authentication is required and exploitation is low-complexity. However, the real-world attack surface is substantially narrowed by the development-only context of the vulnerable component: Lektor's built-in server is intended for local previewing and typically binds to localhost by default, meaning most installations are not reachable from the network without deliberate configuration changes. The Windows-only constraint further limits the exposed population. EPSS data was not provided, so exploitation probability cannot be quantified from available intelligence. A public proof-of-concept raises the threat level above baseline despite the absence of a CISA KEV listing. The most realistic risk scenario is a developer workstation or CI/CD pipeline host where the dev server has been inadvertently bound to a non-loopback interface - even a small internal deployment in a context where developers run Lektor with permissive bind settings could expose credentials through configuration file disclosure. The credential-disclosure outcome (deployment configs, API keys) is the highest-impact scenario and warrants prompt patching even where network exposure is believed to be limited.

An attacker who can reach a Windows host running the Lektor development server sends a crafted HTTP GET request embedding path traversal sequences - for example, requesting a URL such as /../../windows/system32/drivers/etc/hosts or an encoded equivalent - causing the server to serve file contents outside the web root. If the process can read deployment configuration files, the attacker may recover plaintext credentials or API keys without authenticating. A public proof-of-concept exploit demonstrating this technique has been published at https://github.com/TKar0/TKar0-CvePoc/tree/main/2026-CVE-POC/CVE-2026-75418.