Listen to this Post
The Froxlor AJAX endpoint (lib/ajax.php) is a standalone entry point that does not include the main application bootstrap (lib/init.php). While all state‑changing administrative pages (admin_.php, customer_.php) enforce CSRF token validation via lib/init.php lines 363‑369, the Ajax class in lib/Froxlor/Ajax/Ajax.php performs only a session existence check (getValidatedSession()) before routing any request. There is no CSRF token generation, storage, or verification for POST/PUT/PATCH/DELETE actions within this endpoint. The vulnerable editApiKey() method (lines 257‑315) directly updates the api_keys table with attacker‑controlled parameters (id, allowed_from, valid_until) from the POST body. The legitimate frontend JavaScript (apikeys.js) does not send a csrf_token parameter because the backend does not require one, confirming the missing protection. An attacker can host a malicious HTML page that auto‑submits a form to the AJAX endpoint; when an authenticated Froxlor administrator visits that page, the attacker’s IP is added to the API key’s whitelist and the expiration is extended indefinitely. SameSite=Lax cookies provide only limited mitigation and fail under HTTP deployments, Safari inconsistencies, or subdomain attacks. This vulnerability is a stepping stone for persistent administrative API abuse if combined with other weaknesses (e.g., plaintext secret exposure). The affected actions include editapikey (high risk), updatetablelisting (low risk), and others that also lack CSRF checks. The root cause is architectural divergence – the Ajax endpoint bypasses the central security layer of init.php. The recommended fix is to route the AJAX endpoint through init.php or add CSRF validation directly in the Ajax class, and update frontend code to include the available Twig csrf_token meta tag.
DailyCVE Form:
Platform: Froxlor
Version: 2.3.7 (all prior 2.x)
Vulnerability: Cross‑Site Request Forgery (CSRF) in AJAX endpoint
Severity: High
date: 2026‑05‑26
Prediction: Patch expected in Froxlor 2.3.8 by 2026‑06‑15
What Undercode Say:
Exploit simulation – PoC HTML form
<
h2 style=”color: blue;”>cat > csrf_poc.html <<EOF
EOF
Verify the change via database query (requires admin DB access)
mysql -u froxlor_user -p froxlor_db -e “SELECT id, allowed_from, valid_until FROM api_keys WHERE id=1;”
Simulate a curl request from an attacker (if session cookie known)
curl -X POST http://froxlor.example.com/lib/ajax.php?action=editapikey \
-d “id=1&allowed_from=10.99.99.99&valid_until=-1” \
–cookie “PHPSESSID=
Check the actual frontend JavaScript that omits CSRF token
grep -A5 “url: \”lib/ajax.php?action=editapikey\”” templates/Froxlor/assets/js/jquery/apikeys.js
Exploit: (Educational Purposes!)
An attacker hosts the above HTML on a domain under their control. When an authenticated Froxlor admin visits that page, the browser automatically submits a POST request to lib/ajax.php?action=editapikey with the attacker’s desired IP and -1 for never‑expiring. The session cookie is sent (due to SameSite=Lax or missing Secure in HTTP), and the server updates api_keys for the targeted API key (ID 1). The admin never notices the change, and the attacker later obtains the API secret (e.g., via database dump) to gain persistent admin access.
Protection: from this CVE
- Option A (recommended): Refactor lib/ajax.php to include lib/init.php (e.g., define AREA and require init.php) so that all CSRF, rate limiting, and area checks apply.
- Option B: Add CSRF token validation inside Ajax::handle() before routing, mirroring init.php lines 363‑369. Validate against the stored token in the user session.
- Update frontend: In apikeys.js, include the CSRF token from the meta tag () in the POST data.
- Ensure all state‑changing AJAX actions also require token validation.
Impact:
- Integrity: An attacker can modify API key allowed_from and valid_until fields, potentially adding their own IP to the whitelist and making keys never expire. This facilitates subsequent unauthorized API usage.
- Availability: The attacker could set valid_until to a past date, rendering the API key unusable.
- Worst‑case: Combined with another vulnerability (e.g., plaintext API secret exposure), an attacker gains persistent administrative API access, leading to complete system compromise.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
