{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "pixelfed/pixelfed"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.10.4"
            },
            {
              "fixed": "0.11.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-25108"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-280",
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-02-12T15:17:23Z",
    "nvd_published_at": "2024-02-12T20:15:08Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nWhen processing requests authorization was improperly and insufficiently checked, allowing attackers to access far more functionality than users intended, including to the administrative and moderator functionality of the Pixelfed server.\n\nThis vulnerability affects every version of Pixelfed between `v0.10.4` and `v0.11.9`, inclusive. A proof of concept of this vulnerability exists.\n\n### Details\n\nIn vulnerable versions of Pixelfed (versions before 0.11.11), when the API checked the request for permissions to perform a certain behavior, it did not check that the OAuth Application/Client had granted access to those API endpoints, it only checked if the user was authenticated via an access token, and if the user was the owner of the resource or an admin on the instance.\n\nThis meant that an attacker could request an access token for \"read\" permissions to authenticate you with their application, but the access token that they obtained actually could be used for \"write\" or even administrative actions, and the user who granted access to their account had zero knowledge of this elevated access.\n\n#### Proof of Concept\n\n1. Create an access token either via [2-legged OAuth flow](https://oauth.net/2/grant-types/authorization-code/) for the `read` scope, or create a Personal Access Tokens with the `read` scope.\n2. Using that Access Token, perform a request that would need a particular higher-privilege scope, for instance, following a user or performing an administrative request. (respectively requiring `follow` or `admin:read` and `admin:write` scopes in the patched versions)\n3. Observe that despite your access token having `read` permissions, the follow or administrative request was successful.\n\ne.g., Maybe an attacker collects an access token (which expires in 1 year) wants to do something really nasty to an admin, such as disabling federation on their target\u0027s pixelfed server. As long as that server has `instance.enable_cc` configured (defaults to `true`), then the attacker can use the `read` scoped access token and perform the following request:\n\n```\nPOST /api/admin/config/update\nContent-Type: application/json\nAccept: application/json\nAuthorization: Bearer \u003caccess token with read scope\u003e\n\n{ \"key\": \"federation.activitypub.enabled\": \"value\": false }\n```\n\nAnd federation of that pixelfed server would be subsequently disabled, as if the administrator had disabled it.\n\n### Impact\n\nThis vulnerability affects every local user of a Pixelfed server, and can potentially affect the servers\u0027 ability to federate.\n\nSome user interaction is required to setup the conditions to be able to exercise the vulnerability, but the attacker could conduct this attack time-delayed manner, where user interaction is not actively required, since access tokens in Pixelfed have a 1-year lifetime before they expire, and users\u0027 often forget to revoke access tokens for applications that they are no longer using.\n\nThis also means that Access Tokens that may have been leaked from third-party OAuth Application\u0027s databases would be usable for a significant amount of time by potential attackers.\n\n### Prior versions\n\nWhilst this vulnerability is listed as `\u003e= 0.10.4`, there is potential that versions before `0.10.4` are also vulnerable to this sort of security bypass, however, given that the code changed significantly between `0.10.3` and `0.10.4` we\u0027ve been unable to easily assess if these heavily outdated versions are vulnerable or not to this exploit.\n\n### Sponsorship\n\nThe work involved in investigating and remediation of this security vulnerability was provided by [Nivenly Foundation](https://nivenly.org/), for whom we are grateful for their support of the Fediverse and Pixelfed.",
  "id": "GHSA-gccq-h3xj-jgvf",
  "modified": "2024-10-11T21:35:07Z",
  "published": "2024-02-12T15:17:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pixelfed/pixelfed/security/advisories/GHSA-gccq-h3xj-jgvf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25108"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pixelfed/pixelfed/commit/7e47d6dccb0393a2e95c42813c562c854882b037"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pixelfed/pixelfed/commit/fd7f5dbb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pixelfed/pixelfed/commit/fd7f5dbba13818f60d1c2b3ab110b499e996aa81"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pixelfed/pixelfed"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Pixelfed doesn\u0027t check OAuth Scopes in API routes, giving elevated permissions"
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-48778"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-11T20:15:06Z",
    "severity": "CRITICAL"
  },
  "details": "An issue in GIANT MANUFACTURING CO., LTD RideLink (tw.giant.ridelink) 2.0.7 allows a remote attacker to obtain sensitive information via the firmware update process.",
  "id": "GHSA-gcf7-xv2h-qvv7",
  "modified": "2024-10-15T21:30:37Z",
  "published": "2024-10-11T21:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48778"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HankJames/Vul-Reports/blob/main/FirmwareLeakage/tw.giant.ridelink/tw.giant.ridelink.md"
    },
    {
      "type": "WEB",
      "url": "http://giant.com"
    },
    {
      "type": "WEB",
      "url": "http://ridelink.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-2326"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-05T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions before 15.0.5, all versions starting from 15.1 before 15.1.4, all versions starting from 15.2 before 15.2.1. It may be possible to gain access to a private project through an email invite by using other user\u0027s email address as an unverified secondary email.",
  "id": "GHSA-gcj2-4jcm-vgjg",
  "modified": "2022-08-12T00:01:20Z",
  "published": "2022-08-06T00:00:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2326"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1517554"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-2326.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/356665"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-25400"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-11T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "Intent redirection vulnerability in Samsung Internet prior to version 14.0.1.20 allows attacker to execute privileged action.",
  "id": "GHSA-gcm7-m975-8q53",
  "modified": "2022-07-31T00:00:57Z",
  "published": "2022-05-24T19:05:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25400"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2021\u0026month=5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-42725"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-119",
      "CWE-788",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-16T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Adobe Experience Manager version 6.5.9.0 (and earlier) are affected by an improper access control vulnerability that leads to a security feature bypass. By manipulating referer headers, an unauthenticated attacker could gain access to arbitrary pages that they are not authorized to access.",
  "id": "GHSA-gcmg-m9m3-j5jw",
  "modified": "2022-05-24T19:20:45Z",
  "published": "2022-05-24T19:20:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42725"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/bridge/apsb21-94.html"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/experience-manager/apsb21-82.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.6.57"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.6.59"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-22",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T13:59:26Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "# PraisonAI Code agent tools fail open without a workspace boundary\n\n## Summary\n\nPraisonAI Code\u0027s agent-compatible `CODE_TOOLS` wrappers keep a global workspace root initialized to `None`. If an application uses `CODE_TOOLS`, `code_read_file`, `code_search_replace`, or `code_apply_diff` before calling `set_workspace()`, the wrappers pass `workspace=None` into lower-level helpers that only enforce path containment when a workspace is truthy. Absolute paths outside the intended project workspace are then read and modified.\n\nThe official examples correctly call `set_workspace()` before `CODE_TOOLS`, and this report does not claim configured workspaces are ineffective. The issue is the fail-open default. PraisonAI\u0027s security documentation describes workspace boundaries as the path-traversal protection mechanism, and the already-published Python API arbitrary file write advisory (`GHSA-hvhp-v2gc-268q`) was fixed by defaulting an unset workspace to `os.getcwd()`. The adjacent read and edit paths reached through `CODE_TOOLS` still fail open.\n\n## Affected Components\n\n- Package: `praisonai`\n- Current upstream main tested: `2f9677abb2ea68eab864ee8b6a828fd0141612e1`\n- Latest tested release: `v4.6.57`\n- Primary files:\n  - `src/praisonai/praisonai/code/agent_tools.py`\n  - `src/praisonai/praisonai/code/tools/read_file.py`\n  - `src/praisonai/praisonai/code/tools/search_replace.py`\n  - `src/praisonai/praisonai/code/tools/apply_diff.py`\n\n## Root Cause\n\n`agent_tools.py` initializes `_workspace_root` to `None` and passes it directly to lower-level helpers:\n\n```python\n_workspace_root: Optional[str] = None\n...\nresult = _read_file(..., workspace=_workspace_root)\n...\nresult = _search_replace(..., workspace=_workspace_root)\n```\n\nThe lower-level helpers only enforce containment if `workspace` is set:\n\n```python\nif workspace:\n    if not is_path_within_directory(abs_path, workspace):\n        return {\"success\": False, ...}\n```\n\nThe already-hardened `write_file()` path uses `effective_workspace = workspace or os.getcwd()`. Current tests assert that `write_file(workspace=None)` must stay inside the current working directory. The same fail-closed default is missing from `read_file`, `search_replace`, `apply_diff`, and the agent wrappers that call them.\n\n## Local-Only Reproduction\n\nRun:\n\n```bash\nPYTHONPATH=/path/to/PraisonAI/src/praisonai:/path/to/PraisonAI/src/praisonai-agents \\\n  python poc_code_tools_workspace_bypass.py\n```\n\nExpected vulnerable result:\n\n```text\n[poc] HIT: CODE_TOOLS wrappers read and edit outside workspace when workspace is unset\n```\n\nThe PoV creates a temporary workspace and a temporary file outside that workspace. With `get_workspace() == None`, `code_read_file()` reads the outside file, `code_search_replace()` modifies it, and `code_apply_diff()` modifies it again. After `set_workspace(workspace)`, the same outside path is rejected by all three wrappers.\n\nNo external services, model providers, or network access are used.\n\n## Impact\n\nIf an application exposes PraisonAI Code\u0027s agent-compatible `CODE_TOOLS` to an LLM before setting a workspace boundary, prompt-influenced tool calls can read and modify files outside the intended project workspace. The practical attack shape matches the existing PraisonAI prompt-content advisory pattern: untrusted content influences an agent that has been given file-editing tools.\n\nPractical impacts include:\n\n- reading host secrets or local configuration files accessible to the process user;\n- modifying arbitrary existing files when the attacker can supply or infer matching content for `code_search_replace` or `code_apply_diff`;\n- using `code_read_file` to first learn file content and then `code_apply_diff` to produce an exact modification;\n- bypassing the advertised workspace-boundary security posture unless the embedding application remembered to call `set_workspace()` first.\n\nThis issue does not claim `set_workspace()` is ineffective. The control works when configured. The vulnerability is the fail-open default for the advertised agent-tool bundle and adjacent read/edit helpers.\n\n## Affected-Version Sweep\n\nThe same behavior was reproduced on:\n\n- current upstream main: `2f9677abb2ea68eab864ee8b6a828fd0141612e1`\n- `v4.6.57`\n- `v4.6.56`\n- `v4.6.10`\n- `v4.6.9`\n- `v4.5.128`\n- `v4.5.126`\n- `v3.9.26`\n- `v3.9.24`\n\n## Suggested Fix\n\nRecommended fix:\n\n1. Make every low-level file helper compute `effective_workspace = workspace or os.getcwd()` before resolving paths.\n2. Make `code_read_file`, `code_list_files`, `code_apply_diff`, `code_search_replace`, and `code_execute_command` use `os.getcwd()` as the default workspace when `_workspace_root is None`.\n3. Keep allowing absolute paths only when they resolve inside the effective workspace.\n4. Add regression tests proving outside absolute paths are rejected before and after `set_workspace()`.\n5. Consider failing closed if `CODE_TOOLS` is used before a workspace is configured, or log a warning when the default current working directory is used.\n\n## Disclosure Route\n\nPraisonAI\u0027s official security documentation lists GitHub Security Advisories as the preferred reporting method and asks reports to include reproduction steps, affected versions, impact, and suggested fixes. The repository security policy page currently shows no configured `SECURITY.md`, but private vulnerability reporting is available.",
  "id": "GHSA-gcq3-mfvh-3x25",
  "modified": "2026-06-18T13:59:26Z",
  "published": "2026-06-18T13:59:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-gcq3-mfvh-3x25"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PraisonAI Code agent tools fail open without a workspace boundary"
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-35336"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-01T13:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Tieline IP Audio Gateway 2.6.4.8 and below is affected by Incorrect Access Control. A vulnerability in the Tieline Web Administrative Interface could allow an unauthenticated user to access a sensitive part of the system with a high privileged account.",
  "id": "GHSA-gcr2-226m-p44h",
  "modified": "2022-07-13T00:01:28Z",
  "published": "2022-05-24T19:06:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35336"
    },
    {
      "type": "WEB",
      "url": "https://pratikkhalane91.medium.com/use-of-default-credentials-to-unauthorised-remote-access-of-internal-panel-of-tieline-c1ffe3b3757c"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-2386"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-18T13:16:21Z",
    "severity": "MODERATE"
  },
  "details": "The The Plus Addons for Elementor \u2013 Addons for Elementor, Page Templates, Widgets, Mega Menu, WooCommerce plugin for WordPress is vulnerable to Incorrect Authorization in all versions up to, and including, 6.4.7. This is due to the tpae_create_page() AJAX handler authorizing users only with current_user_can(\u0027edit_posts\u0027) while accepting a user-controlled \u0027post_type\u0027 value passed directly to wp_insert_post() without post-type-specific capability checks. This makes it possible for authenticated attackers, with Author-level access and above, to create arbitrary draft posts for restricted post types (e.g., \u0027page\u0027 and \u0027nxt_builder\u0027) via the \u0027post_type\u0027 parameter.",
  "id": "GHSA-gcr4-23wm-438x",
  "modified": "2026-02-18T15:31:25Z",
  "published": "2026-02-18T15:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2386"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3463156/the-plus-addons-for-elementor-page-builder"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/4fc3e24a-8b51-4b6f-bacf-665ceb03bc05?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "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-41235"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T15:36:26Z",
    "nvd_published_at": "2026-06-04T19:16:29Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nFroxlor 2.3.6 lets administrators configure `system.available_shells` as the approved shell list that customers may assign to FTP users. However, the server-side FTP account handlers do not enforce that whitelist when processing add or edit requests.\n\nAs a result, an authenticated customer with shell delegation enabled can submit an arbitrary shell such as `/bin/bash` even when the panel UI only offers more restricted choices. In deployments that use the default `nssextrausers` integration, the attacker-controlled shell is then propagated into the system account database, leading to real host shell access.\n\n### Details\nThe customer-facing FTP account page builds the shell selector from `system.available_shells`, which shows that the product intends the setting to act as the authorization boundary:\n\n```php\n// customer_ftp.php:138-149\n$shells = [\n    \u0027/bin/false\u0027 =\u003e \u0027/bin/false\u0027\n];\n$availableshells = explode(\u0027,\u0027, Settings::Get(\u0027system.available_shells\u0027));\nif (is_array($availableshells) \u0026\u0026 !empty($availableshells)) {\n    foreach ($availableshells as $shell) {\n        $shells[trim($shell)] = trim($shell);\n    }\n}\n```\n\nThe request handler forwards posted form data directly into the FTP API command implementation:\n\n```php\n// customer_ftp.php:170-172\nif ($action == \u0027edit\u0027 \u0026\u0026 Request::post(\u0027send\u0027) == \u0027send\u0027) {\n    $result = $log-\u003elogAction(USR_ACTION, LOG_INFO, \"edited ftp-account #\" . $id);\n    Commands::get()-\u003eapiCall(\u0027Ftps.update\u0027, Request::postAll());\n}\n```\n\nOn the server side, `Ftps::add()` and `Ftps::update()` only perform generic shell string validation. They do not verify that the submitted shell belongs to `system.available_shells`:\n\n```php\n// lib/Froxlor/Api/Commands/Ftps.php:119-123\nif (Settings::Get(\u0027system.allow_customer_shell\u0027) == \u00271\u0027 \u0026\u0026 $this-\u003egetUserDetail(\u0027shell_allowed\u0027) == \u00271\u0027) {\n    $shell = Validate::validate(trim($shell), \u0027shell\u0027, \u0027\u0027, \u0027\u0027, [], true);\n} else {\n    $shell = \u0027/bin/false\u0027;\n}\n```\n\nThe validated shell is stored into `ftp_users.shell` and later consumed by the root-owned cron task that rebuilds NSS extrausers files:\n\n```php\n// lib/Froxlor/Cron/System/Extrausers.php:89-97\n$passwd_entries[] = $user[\u0027username\u0027] . \u0027:x:\u0027 . $uid . \u0027:\u0027 . $gid . \u0027:\u0027 . $gecos . \u0027:\u0027 . $homedir . \u0027:\u0027 . $shell;\n```\n\nBecause the default installer configuration sets `system.nssextrausers=1`, and the shipped Debian/Bookworm configuration enables `extrausers` in `nsswitch.conf`, the attacker-controlled shell becomes the effective login shell of the generated system user on standard supported deployments.\n\n### PoC\nAn attacker needs a normal customer account and a deployment where customer shell delegation is enabled for that customer.\n\nRelevant runtime prerequisites:\n\n- `system.allow_customer_shell=1`\n- the attacking customer has `shell_allowed=1`\n- the deployment uses `system.nssextrausers=1` with the shipped `libnss-extrausers` integration\n\nFroxlor requires a valid CSRF token for POST requests, so the attacker performs the exploit from an authenticated session.\n\nComplete PoC flow:\n\n1. Log in as a customer and obtain a valid `csrf_token`.\n2. Identify one FTP account owned by that customer.\n3. Submit an edit request that sets an arbitrary shell outside the administrator-approved `system.available_shells` list:\n\n```http\nPOST /customer_ftp.php?page=accounts\u0026action=edit\u0026id=17 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\nid=17\u0026\nusername=test1ftp1\u0026\nftp_description=poc\u0026\npath=/\u0026\nshell=/bin/bash\u0026\nlogin_enabled=1\n```\n\n4. Wait for Froxlor\u0027s master cron to process the queued `REBUILD_NSSUSERS` task.\n\nResult:\n\n- the request is accepted even if `/bin/bash` is not present in `system.available_shells`\n- `ftp_users.shell` is updated to `/bin/bash`\n- `/var/lib/extrausers/passwd` is regenerated with `/bin/bash` as the FTP user\u0027s login shell\n- the attacker can then authenticate to the host using that FTP user\u0027s credentials and obtain an interactive shell\n\n\n### Impact\nThis issue lets a low-privileged customer bypass an administrator-defined authorization boundary and promote an FTP-only account into a real shell account. On shared-hosting systems managed by Froxlor, that materially changes the trust model and can expose the host to lateral movement, local privilege-escalation follow-on attacks, data theft from colocated services, and persistence on the server.\n\nBecause the vulnerable flow is executed through the normal authenticated web interface and a root-owned provisioning task later materializes the chosen shell at the operating-system level, the vulnerability is stronger than a UI-only restriction bypass.",
  "id": "GHSA-gcv3-5v9q-fmhh",
  "modified": "2026-06-09T11:54:54Z",
  "published": "2026-05-29T15:36:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/froxlor/froxlor/security/advisories/GHSA-gcv3-5v9q-fmhh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41235"
    },
    {
      "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Froxlor has an authorization bypass in FTP shell assignment via missing server-side `available_shells` enforcement"
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-29158"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-23T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Sonatype Nexus Repository Manager 3 Pro up to and including 3.30.0 has Incorrect Access Control.",
  "id": "GHSA-gf6v-2xhw-h825",
  "modified": "2024-04-04T03:06:21Z",
  "published": "2022-05-24T17:48:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29158"
    },
    {
      "type": "WEB",
      "url": "https://support.sonatype.com/hc/en-us/articles/1500006126462"
    },
    {
      "type": "WEB",
      "url": "https://support.sonatype.com/hc/en-us/categories/201980768-Welcome-to-the-Sonatype-Support-Knowledge-Base"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}