Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-55593

CVE-2026-55593: Froxlor CSRF Vulnerability

CVE-2026-55593 is a CSRF flaw in Froxlor server administration software that allows attackers to modify API key restrictions. This post explains its technical details, affected versions, impact, and mitigation steps.

Published:

CVE-2026-55593 Overview

CVE-2026-55593 is a Cross-Site Request Forgery [CWE-352] vulnerability in Froxlor, an open source server administration platform. The flaw exists in the standalone lib/ajax.php entry point, which bypasses the centralized request validation performed in lib/init.php. The Ajax::handle method in lib/Froxlor/Ajax/Ajax.php validates only the session before routing state-changing requests. As a result, the editapikey action in Ajax::editApiKey modifies allowed_from and valid_until without checking a CSRF token. An unauthenticated attacker can trick an authenticated administrator into submitting a forged request that weakens an API key's access restrictions. The issue is fixed in Froxlor version 2.3.8.

Critical Impact

A successful CSRF attack lets a remote attacker add an attacker-controlled address to an API key's allowed_from list or remove its expiration, undermining API key integrity.

Affected Products

  • Froxlor server administration software prior to version 2.3.8
  • Deployments exposing lib/ajax.php to authenticated administrators
  • Any Froxlor instance using API keys with allowed_from or valid_until restrictions

Discovery Timeline

  • 2026-08-18 - CVE-2026-55593 published to NVD
  • 2026-08-19 - Last updated in NVD database

Technical Details for CVE-2026-55593

Vulnerability Analysis

Froxlor centralizes request validation, including CSRF token verification, inside lib/init.php. However, the lib/ajax.php file operates as a standalone entry point that does not invoke this centralized validation flow. When a request reaches Ajax::handle in lib/Froxlor/Ajax/Ajax.php, the handler confirms only that a valid session exists before dispatching to the requested action.

The editapikey action, implemented by Ajax::editApiKey, updates two sensitive fields on an API key: allowed_from (the address allowlist) and valid_until (the expiration timestamp). Neither field is protected by anti-CSRF checks. The client-side script templates/Froxlor/assets/js/jquery/apikeys.js sends no token because the server does not require one.

Root Cause

The root cause is missing CSRF validation on a state-changing Ajax endpoint. Because lib/ajax.php bypasses lib/init.php, session presence becomes the only precondition for modifying API key restrictions. Session cookies are automatically attached to cross-origin requests by the browser, which is precisely the condition CSRF tokens are designed to defeat.

Attack Vector

An attacker hosts a malicious page and induces an authenticated Froxlor administrator to visit it. The page issues a forged POST request to lib/ajax.php?action=editapikey, supplying an existing API key id and an attacker-chosen allowed_from value or an empty valid_until. The Froxlor backend processes the request under the administrator's session and rewrites the API key restrictions. The attacker can then use the modified key from their own network location, or continue using an expired key that has been silently extended.

php
// Patch excerpt: lib/Froxlor/Ajax/Ajax.php
namespace Froxlor\Ajax;

-use Exception;
 use DateTime;
+use Exception;
 use Froxlor\Config\ConfigDisplay;
 use Froxlor\Config\ConfigParser;
 use Froxlor\CurrentUser;
 use Froxlor\Database\Database;
 use Froxlor\FileDir;
 use Froxlor\Froxlor;
 use Froxlor\Http\HttpClient;
+use Froxlor\Http\RateLimiter;
 use Froxlor\Install\Update;
 use Froxlor\Settings;
+use Froxlor\UI\Linker;
 use Froxlor\UI\Listing;
 use Froxlor\UI\Panel\UI;
 use Froxlor\UI\Request;
-use Froxlor\UI\Response;
 use Froxlor\Validate\Validate;

class Ajax

Source: GitHub Commit 5f540fe

javascript
// Patch excerpt: templates/Froxlor/assets/js/jquery/apikeys.js
    url: "lib/ajax.php?action=editapikey",
    type: "POST",
    dataType: "json",
+   beforeSend: function (request) {
+       request.setRequestHeader('X-CSRF-TOKEN', document.querySelector('meta[name="csrf-token"]').getAttribute('content'));
+   },
    data: {
        id: akid,
        allowed_from: _this.val(),

Source: GitHub Commit 5f540fe. The patch enforces an X-CSRF-TOKEN header on the client and validates it server-side, aligning the Ajax entry point with the protection model used elsewhere in Froxlor.

Detection Methods for CVE-2026-55593

Indicators of Compromise

  • POST requests to lib/ajax.php?action=editapikey with a Referer header pointing to an external or unexpected origin.
  • API keys whose allowed_from value has expanded to include unfamiliar IP addresses or CIDR ranges.
  • API keys whose valid_until field has been cleared or extended without a corresponding administrator action in Froxlor audit logs.

Detection Strategies

  • Compare current API key allowed_from and valid_until values against a known-good baseline and alert on drift.
  • Inspect web server access logs for action=editapikey requests that lack an Origin or Referer matching the Froxlor host.
  • Correlate API key modifications with administrator browser activity to identify changes that occurred outside of active admin sessions on the Froxlor UI.

Monitoring Recommendations

  • Enable verbose logging on the Froxlor host and forward web server logs to a central analytics platform for retention and search.
  • Alert on subsequent API calls originating from newly added allowed_from addresses.
  • Track outbound requests from administrator workstations to suspicious domains that could host CSRF payloads.

How to Mitigate CVE-2026-55593

Immediate Actions Required

  • Upgrade Froxlor to version 2.3.8 or later, which enforces CSRF token validation on the editapikey Ajax action.
  • Rotate all existing API keys and review each key's allowed_from and valid_until values for unauthorized changes.
  • Require administrators to log out of Froxlor sessions before browsing untrusted sites until patching is complete.

Patch Information

The fix is delivered in Froxlor 2.3.8 and detailed in GHSA-xpr4-8vp6-c87j. The patch adds X-CSRF-TOKEN header validation to the Ajax action handler and updates apikeys.js to attach the token from the page's csrf-token meta tag. Review the commit diff for the full change set.

Workarounds

  • Restrict access to the Froxlor administration panel to trusted networks using firewall or reverse proxy allowlists.
  • Configure the web server to reject requests to lib/ajax.php when the Origin or Referer header does not match the Froxlor hostname.
  • Advise administrators to use a dedicated browser profile for Froxlor to eliminate cross-site session reuse.
bash
# Example nginx snippet to enforce same-origin on the Ajax endpoint
location = /lib/ajax.php {
    if ($http_origin !~* ^https://froxlor\.example\.com$) {
        return 403;
    }
    if ($http_referer !~* ^https://froxlor\.example\.com/) {
        return 403;
    }
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.