elFinder.class.php` hardcodes `'secure' => true` in session `cookieParams`, breaking all write operations over plain HTTP

[mschlenstedt]

I run elFinder on a local server via HTTP. We include elFinder in our LoxBerry project - a plugin system for the Loxone smarthome systems. https://github.com/mschlenstedt/Loxberry

I figured out that all write operations (like creating a folder) are visible in the elFinder WebUI, but are not written to the filesystem in "reality". After changing the folder in elFinder, the changes are gone also in the elFinder WebUI.

I analysed this with Claude Code:

elFinder.class.php hardcodes 'secure' => true in session cookieParams, breaking all write operations over plain HTTP

elFinder version: 2.1.69 (API 2.1, Revision 69)

Summary

All write operations (mkdir, upload, delete, rename, …) silently fail when elFinder is used over a plain HTTP connection. The root cause is a hardcoded 'secure' => true in the default cookieParams built inside elFinder.class.php. This forces the Secure attribute onto the PHPSESSID cookie regardless of whether the actual connection is HTTP or HTTPS. Browsers (per RFC 6265) and HTTP clients refuse to send a Secure-flagged cookie over non-TLS requests, so every write command arrives at the connector without a session cookie. PHP starts a fresh empty session for each write request, the CSRF token stored during the open handshake is never found, and the connector returns errPerm / csrfReload: true.

Root cause

elFinder.class.php, around line 676:

$sessionOpts = array(
    // …
    'cookieParams' => array(
        'path'     => '/',
        'secure'   => true,   // ← hardcoded, unconditional
        'httponly' => true,
        'samesite' => defined('ELFINDER_COOKIE_SAMESITE') ? ELFINDER_COOKIE_SAMESITE : 'Lax'
    )
);
$this->session = new elFinderSession($sessionOpts);

elFinderSession.php, getSessionCookieParams():

$secure = (!empty($_SERVER['HTTPS']) && strtolower($_SERVER['HTTPS']) !== 'off');
// ↑ correctly computes false for HTTP …

$params = array('secure' => $secure, …);

// … but then cookieParams from elFinder.class.php override it:
$params = array_merge($params, $this->opts['cookieParams']);
// ↑ 'secure' => true now wins unconditionally

elFinderSession already contains the correct dynamic logic to derive the secure flag from $_SERVER['HTTPS'], but array_merge lets the hardcoded value from elFinder.class.php silently override it.

Steps to reproduce

1. Deploy elFinder with the stock connector.minimal.php on a server accessible via HTTP (no TLS).
2. Open the file manager in a browser.
3. Try to create a folder anywhere — the folder briefly appears in the UI (optimistic update) and then disappears.
4. Inspect the connector response: {"error":["errPerm","Invalid request. Please reload."],"csrfReload":true}.

Verified with curl:

# open — gets CSRF token, but Set-Cookie carries the 'secure' flag
curl -si -c cookies.txt -X POST http://myserver/elfinder/php/connector.minimal.php \
  --data 'cmd=open&target=l1_Lw&init=1' | grep -i set-cookie
# → Set-Cookie: PHPSESSID=…; path=/; secure; HttpOnly; SameSite=Lax

# mkdir — browser/curl does NOT send PHPSESSID cookie because of 'secure' flag over HTTP
curl -s -b cookies.txt -X POST http://myserver/elfinder/php/connector.minimal.php \
  -H "X-elFinder-CSRF: <token>" \
  --data 'cmd=mkdir&target=l1_Lw&name=test'
# → {"error":["errPerm","Invalid request. Please reload."],"csrfReload":true}

Why it is not immediately obvious

• Read-only commands (open, ls, info) do not require CSRF validation and work fine, so navigation appears normal.
• Folder creation briefly shows an optimistic placeholder in the UI, making it look like a backend deletion rather than a creation failure.
• error_reporting(0) in connector.minimal.php suppresses any PHP-level hints.
• The issue only manifests on HTTP — installations served exclusively over HTTPS are unaffected.

Suggested fix

Replace the hardcoded true in elFinder.class.php with a dynamic check, consistent with what elFinderSession::getSessionCookieParams() already does:

// elFinder.class.php, cookieParams block
'secure' => !empty($_SERVER['HTTPS']) && strtolower($_SERVER['HTTPS']) !== 'off',

Alternatively (without touching vendor code), callers can work around the issue by passing a pre-configured session object via $opts['session']:

// connector.minimal.php
require_once dirname(__FILE__) . '/elFinderSession.php';
$elfinderSession = new elFinderSession(array(
    'keys' => array('default' => 'elFinderCaches', 'netvolume' => 'elFinderNetVolumes'),
    'cookieParams' => array(
        'path'     => '/',
        'secure'   => !empty($_SERVER['HTTPS']) && strtolower($_SERVER['HTTPS']) !== 'off',
        'httponly' => true,
        'samesite' => defined('ELFINDER_COOKIE_SAMESITE') ? ELFINDER_COOKIE_SAMESITE : 'Lax',
    ),
));
$opts = array('session' => $elfinderSession, 'roots' => array(…));

[Azuka]

Is there any way to bypass csrf entirely? When using this in a framework like Laravel for example which already verifies CSRF for post requests, my initialization code already looks like this:

$('#elfinder').elfinder({
                customHeaders: {
                    'X-Requested-With' : 'XMLHttpRequest',
                    'X-CSRF-TOKEN': '<?php echo csrf_token(); ?>'
                },
...