Description

Lektor 3.3.14 and 3.4.0b15 contains a cross-site request forgery vulnerability in the admin API blueprint that allows unauthenticated attackers to perform state-changing actions by sending cross-origin requests without CSRF tokens, Origin/Referer validation, CORS configuration, or Host allowlisting. Attackers can exploit the newattachment, deleterecord, build, clean, and publish endpoints from a malicious web page to write arbitrary files, delete pages, wipe build output, trigger deployment publication, and via DNS rebinding reach read endpoints to disclose data.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-10-01T19:17:19.480Z",
  "pubdate": "2026-10-01T19:17:19.480Z",
  "executiveSummary": "Lektor versions 3.3.14 and 3.4.0b15 are susceptible to a critical Cross-Site Request Forgery (CSRF) vulnerability residing within the admin API blueprint.\nThe absence of robust state-changing request validation allows unauthenticated attackers to perform unauthorized actions on the Lektor admin interface by coercing a victim's browser to send cross-origin requests.\nThis vulnerability is particularly severe because the API lacks essential security controls, including CSRF tokens, Origin/Referer header validation, CORS configuration, and Host allowlisting.\nAttackers can leverage this flaw to trigger administrative functions such as file system modifications, content deletion, and deployment cycles.\nThe risk is exacerbated by the potential for DNS rebinding attacks, which can circumvent same-origin policy restrictions to disclose sensitive data.\nImpact includes complete administrative control over the Lektor instance, including arbitrary file write, data destruction, and unauthorized service publication.\nNo authentication is required to initiate these forged requests, and the victim's session context is used to authorize the malicious actions.",
  "technicalDetails": "The root cause of this vulnerability is the failure to implement CSRF protection mechanisms within the Lektor admin API blueprint. Because the application processes state-changing requests—such as newattachment, deleterecord, build, clean, and publish—without verifying the origin of the request or requiring a cryptographically secure CSRF token, the application assumes that any request received during an active admin session is intentional.\nAn attacker can exploit this by hosting a malicious web page that embeds specially crafted cross-origin requests targeting these administrative endpoints. When an authenticated administrator visits the malicious page, the browser automatically attaches relevant session cookies to the forged requests, allowing the attacker to interact with the admin API as if they were the legitimate user.\nThe lack of CORS configuration and Host header validation ensures that the browser does not preemptively block these requests, and the server fails to verify the provenance of the incoming traffic. This provides a direct path to performing high-privilege operations.\nThe attack flow proceeds as follows: 1) The attacker lures a victim with an active Lektor session to a malicious site. 2) The site executes a client-side script that sends an HTTP request to the Lektor admin endpoints. 3) The browser includes the victim's authentication credentials. 4) The Lektor server processes the request as a legitimate administrative action, despite the request originating from an external, hostile domain. 5) Through DNS rebinding, the attacker may bypass potential same-origin policy enforcement, effectively extending the impact to read-only endpoints to exfiltrate internal site data.\nThe impact extends beyond simple configuration changes. The ability to invoke the 'newattachment' endpoint allows for arbitrary file writes, potentially enabling Remote Code Execution (RCE) if the web server directory is writable. The 'deleterecord' and 'clean' endpoints facilitate denial-of-service through the deletion of site content and the wiping of build outputs. Finally, the ability to trigger the 'publish' endpoint allows an attacker to force a deployment, potentially pushing malicious or outdated content to the production environment."
}