Executive brief
Froxlor's AJAX endpoint (lib/ajax.php) lacks Cross-Site Request Forgery (CSRF) protection, whereas the main application enforces CSRF tokens on all state-changing requests. An attacker can craft a malicious webpage that, when visited by an authenticated Froxlor administrator, silently modifies API key properties such as adding the attacker's IP address to the whitelist or extending expiration indefinitely. This allows unauthorized API access when combined with other attacks to obtain the API secret.
Technical details
The vulnerability is a missing CSRF token validation in the AJAX endpoint (lib/ajax.php). While the main application bootstrap (lib/init.php) enforces CSRF token validation on POST/PUT/PATCH/DELETE requests before processing state-changing operations, the standalone AJAX endpoint bypasses this security control entirely and validates only session existence. The vulnerable code path: lib/ajax.php does not include lib/init.php and instantiates Ajax class directly; Ajax::__construct() and Ajax::handle() perform session validation but skip CSRF checks; Ajax::editApiKey() modifies the database (api_keys table) with attacker-controlled POST parameters without verifying request origin. An unauthenticated attacker cannot exploit this, but any attacker who can trick an authenticated administrator into visiting a malicious webpage can modify API key settings (allowed_from, valid_until) via cross-site POST request. The endpoint's SameSite=Lax cookie provides partial mitigation in modern browsers, but this fails on HTTP deployments, older browser versions, and same-site subdomain attacks. Patch available in version 2.3.8.
Affected products
- Froxlor Froxlor <= 2.3.7
Timeline
- 2026-06-29: disclosed: GitHub Security Advisory GHSA-xpr4-8vp6-c87j published
- 2026-08-18: advisory: CVE-2026-55593 assigned
- 2026: patched: Fix available in Froxlor 2.3.8