Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

5544 vulnerabilities reference this CWE, most recent first.

GHSA-VJV9-7M7J-H833

Vulnerability from github – Published: 2026-06-18 14:26 – Updated: 2026-06-18 14:26
VLAI
Summary
npm PraisonAI SandboxExecutor allowedCommands bypass via shell chaining
Details

Summary

The published npm package praisonai exports SandboxExecutor, CommandValidator, and sandboxExec as "safe command execution with restrictions." When allowedCommands is configured, CommandValidator checks only the first whitespace-delimited token of the command string. SandboxExecutor then passes the entire original string to spawn("sh", ["-c", command]).

With a policy that allows only echo, this direct command is correctly rejected:

cat /tmp/marker

but this chained command is accepted and executed:

echo allowed; cat /tmp/marker

The shell executes cat even though cat is not allowlisted. This bypasses the command allowlist and can execute arbitrary shell commands with the PraisonAI process privileges when an application, CLI workflow, or agent pipeline exposes sandbox command execution to lower-trust users, prompts, or model output.

The PoV is deterministic and local-only. It creates and reads only a temporary marker file.

Technical Details

In src/praisonai-ts/src/cli/features/sandbox-executor.ts, CommandValidator.validate() normalizes the command and authorizes only the first whitespace token:

const normalized = command.toLowerCase().trim();

if (this.allowedCommands) {
  const baseCmd = normalized.split(/\s+/)[0];
  if (!this.allowedCommands.includes(baseCmd)) {
    return { valid: false, reason: `Command '${baseCmd}' not in allowlist` };
  }
}

The denylist does not generally reject shell separators. It blocks a few specific patterns such as ; rm, but not ; cat, &&, ||, backticks, $(), or newline as a general policy boundary.

SandboxExecutor.spawn() then executes the unmodified command string through a shell:

const proc = spawn('sh', ['-c', command], {
  cwd: this.config.cwd,
  env,
  timeout: this.config.timeout,
  stdio: ['pipe', 'pipe', 'pipe']
});

That creates a mismatch: the allowlist authorizes one command token, but the shell interprets the whole string as a script.

The published npm:praisonai@1.7.1 dist files preserve the same behavior:

  • dist/cli/features/sandbox-executor.js checks only baseCmd.
  • dist/cli/features/sandbox-executor.js later invokes spawn("sh", ["-c", command]).
  • dist/index.js exports SandboxExecutor, CommandValidator, and sandboxExec.

Why This Is Not Intended Behavior

PraisonAI's sandbox docs describe sandbox execution as a security feature for AI-generated commands, with command validation, resource limits, path restrictions, network isolation, and execution isolation. The TypeScript source also describes this component as "Safe command execution with restrictions."

With allowedCommands: ["echo"], PraisonAI correctly rejects cat <marker> when submitted directly. That proves the intended policy is to block non-allowlisted executables. The same policy allowing echo allowed; cat <marker> is therefore an authorization bypass, not merely a permissive configuration.

PoV

Run from a local reproduction checkout:

node poc/pov_poc.js 1.7.1

Expected output includes:

{
  "version": "1.7.1",
  "package": "npm:praisonai",
  "allowedCommands": ["echo"],
  "controls": {
    "directCatRejected": true,
    "benignEchoAllowed": true,
    "patchedControlRejectsChainedShell": true
  },
  "observed": {
    "directPolicy": {
      "allowed": false,
      "reason": "Command 'cat' not in allowlist"
    },
    "benignPolicy": {
      "allowed": true
    },
    "chainedPolicy": {
      "allowed": true
    },
    "chainedRun": {
      "success": true,
      "stdout": "allowed\npoc.7.1",
      "stderr": "",
      "exitCode": 0
    },
    "patchedControl": {
      "benign": {
        "allowed": true
      },
      "direct": {
        "allowed": false,
        "reason": "Command 'cat' not in allowlist"
      },
      "chained": {
        "allowed": false,
        "reason": "shell metacharacter rejected before execution"
      }
    }
  },
  "vulnerable": true
}

Interpretation:

  • Direct cat <marker> is rejected by the allowlist.
  • Benign echo allowed is accepted.
  • echo allowed; cat <marker> is accepted by the same allowlist and executes the non-allowlisted cat.
  • A patched-control validator that rejects shell metacharacters before execution blocks the chained command while still allowing benign echo.

The PoV installs npm:praisonai@1.7.1 into a temporary project, creates a temporary marker file, and reads only that file. It does not contact any live service or execute destructive commands.

PoC

The PoV section above contains the local reproduction command, input, and decisive output.

Impact

If lower-trust users, prompts, or model output can influence a command string sent to SandboxExecutor or sandboxExec, allowedCommands does not enforce the intended command boundary. An attacker can append arbitrary shell commands after an allowed first token and run them with the privileges of the PraisonAI process.

Concrete consequences depend on the hosting application and configured process privileges, but can include reading or modifying files, invoking local tools, using available credentials, or causing denial of service.

This report does not claim that npm PraisonAI exposes this as a default network service. It is a library-level sandbox/allowlist bypass in an exported TypeScript API that is explicitly designed for safe command execution.

Severity

Suggested severity: High.

Rationale:

  • AV: common deployment pattern is an application exposing agent prompts or command automation over a network.
  • AC: attacker only needs to induce or submit a command string that starts with an allowed command.
  • PR: conservative base score assumes the attacker can submit prompts or command requests to the application.
  • UI: no operator action is needed once the command reaches the executor.
  • S: impact is in the PraisonAI-hosting process.
  • C/I/A: arbitrary shell commands can affect confidentiality, integrity, and availability depending on process privileges.

If maintainers score only local CLI use, AV:L may be reasonable. If they score public unauthenticated prompt or command endpoints built on this API, PR:N may be reasonable.

Suggested Fix

Avoid passing policy-checked user strings to a shell.

Recommended:

  1. Require callers to pass { command, args }, or parse command strings into argv with a shell-aware parser.
  2. Execute with spawn(command, args, { shell: false }) / execFile() instead of sh -c.
  3. Apply allowedCommands to the exact executable after normalization.
  4. Reject shell metacharacters (;, &&, ||, |, backticks, $(), newline, redirects) when a shell string API must be kept for compatibility.
  5. Add regression tests proving allowedCommands: ["echo"] allows echo ok but rejects cat marker, echo ok; cat marker, echo ok && cat marker, and echo ok | cat marker.

Affected Package/Versions

  • Repository: MervinPraison/PraisonAI
  • Package: npm:praisonai
  • Component: TypeScript CLI feature SandboxExecutor
  • Current head validated: 1ad58ca02975ff1398efeda694ea2ab78f20cf3e
  • Current tag validated: v4.6.58
  • Latest npm package validated: 1.7.1

Suggested affected range:

npm:praisonai >= 1.2.3, <= 1.7.1

Selected version sweep:

  • 1.0.0: package main cannot be required in the selected test environment.
  • 1.2.0, 1.2.1, 1.2.2: SandboxExecutor is not exported.
  • 1.2.3: vulnerable.
  • 1.2.4: vulnerable.
  • 1.3.0: vulnerable.
  • 1.3.6: vulnerable.
  • 1.4.0: vulnerable.
  • 1.5.0: vulnerable.
  • 1.5.4: vulnerable.
  • 1.6.0: vulnerable.
  • 1.7.0: vulnerable.
  • 1.7.1: vulnerable.

Advisory History

This is distinct from known and previously submitted PraisonAI issues:

  • GHSA-r4f2-3m54-pp7q covers PyPI SubprocessSandbox shell=True and blocklist bypass.
  • GHSA-2763-cj5r-c79m covers PyPI praisonai OS command injection.
  • GHSA-v7px-3835-7gjx covers PyPI memory/hooks.py shell injection.
  • GHSA-4wr3-f4p3-5wjh covers Python agent tool approval allow-list manipulation.
  • GHSA-4mr5-g6f9-cfrh covers PyPI/Python execute_code sandbox escape.
  • GHSA-9qhq-v63v-fv3j covers an incomplete fix for a Python command injection.
  • GHSA-vmmj-pfw7-fjwp covers npm codeMode host-process new Function sandbox escape.

No visible local or GitHub advisory covers npm TypeScript SandboxExecutor, CommandValidator, allowedCommands, or the first-token allowlist followed by sh -c shell-chaining root cause.

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.7.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "praisonai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.2.3"
            },
            {
              "fixed": "1.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-693",
      "CWE-78",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T14:26:34Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe published npm package `praisonai` exports `SandboxExecutor`, `CommandValidator`, and `sandboxExec` as \"safe command execution with restrictions.\" When `allowedCommands` is configured, `CommandValidator` checks only the first whitespace-delimited token of the command string. `SandboxExecutor` then passes the entire original string to `spawn(\"sh\", [\"-c\", command])`.\n\nWith a policy that allows only `echo`, this direct command is correctly rejected:\n\n```sh\ncat /tmp/marker\n```\n\nbut this chained command is accepted and executed:\n\n```sh\necho allowed; cat /tmp/marker\n```\n\nThe shell executes `cat` even though `cat` is not allowlisted. This bypasses the command allowlist and can execute arbitrary shell commands with the PraisonAI process privileges when an application, CLI workflow, or agent pipeline exposes sandbox command execution to lower-trust users, prompts, or model output.\n\nThe PoV is deterministic and local-only. It creates and reads only a temporary marker file.\n\n## Technical Details\n\nIn `src/praisonai-ts/src/cli/features/sandbox-executor.ts`, `CommandValidator.validate()` normalizes the command and authorizes only the first whitespace token:\n\n```ts\nconst normalized = command.toLowerCase().trim();\n\nif (this.allowedCommands) {\n  const baseCmd = normalized.split(/\\s+/)[0];\n  if (!this.allowedCommands.includes(baseCmd)) {\n    return { valid: false, reason: `Command \u0027${baseCmd}\u0027 not in allowlist` };\n  }\n}\n```\n\nThe denylist does not generally reject shell separators. It blocks a few specific patterns such as `; rm`, but not `; cat`, `\u0026\u0026`, `||`, backticks, `$()`, or newline as a general policy boundary.\n\n`SandboxExecutor.spawn()` then executes the unmodified command string through a shell:\n\n```ts\nconst proc = spawn(\u0027sh\u0027, [\u0027-c\u0027, command], {\n  cwd: this.config.cwd,\n  env,\n  timeout: this.config.timeout,\n  stdio: [\u0027pipe\u0027, \u0027pipe\u0027, \u0027pipe\u0027]\n});\n```\n\nThat creates a mismatch: the allowlist authorizes one command token, but the shell interprets the whole string as a script.\n\nThe published `npm:praisonai@1.7.1` dist files preserve the same behavior:\n\n- `dist/cli/features/sandbox-executor.js` checks only `baseCmd`.\n- `dist/cli/features/sandbox-executor.js` later invokes `spawn(\"sh\", [\"-c\", command])`.\n- `dist/index.js` exports `SandboxExecutor`, `CommandValidator`, and `sandboxExec`.\n\n### Why This Is Not Intended Behavior\n\nPraisonAI\u0027s sandbox docs describe sandbox execution as a security feature for AI-generated commands, with command validation, resource limits, path restrictions, network isolation, and execution isolation. The TypeScript source also describes this component as \"Safe command execution with restrictions.\"\n\nWith `allowedCommands: [\"echo\"]`, PraisonAI correctly rejects `cat \u003cmarker\u003e` when submitted directly. That proves the intended policy is to block non-allowlisted executables. The same policy allowing `echo allowed; cat \u003cmarker\u003e` is therefore an authorization bypass, not merely a permissive configuration.\n\n## PoV\n\nRun from a local reproduction checkout:\n\n```bash\nnode poc/pov_poc.js 1.7.1\n```\n\nExpected output includes:\n\n```json\n{\n  \"version\": \"1.7.1\",\n  \"package\": \"npm:praisonai\",\n  \"allowedCommands\": [\"echo\"],\n  \"controls\": {\n    \"directCatRejected\": true,\n    \"benignEchoAllowed\": true,\n    \"patchedControlRejectsChainedShell\": true\n  },\n  \"observed\": {\n    \"directPolicy\": {\n      \"allowed\": false,\n      \"reason\": \"Command \u0027cat\u0027 not in allowlist\"\n    },\n    \"benignPolicy\": {\n      \"allowed\": true\n    },\n    \"chainedPolicy\": {\n      \"allowed\": true\n    },\n    \"chainedRun\": {\n      \"success\": true,\n      \"stdout\": \"allowed\\npoc.7.1\",\n      \"stderr\": \"\",\n      \"exitCode\": 0\n    },\n    \"patchedControl\": {\n      \"benign\": {\n        \"allowed\": true\n      },\n      \"direct\": {\n        \"allowed\": false,\n        \"reason\": \"Command \u0027cat\u0027 not in allowlist\"\n      },\n      \"chained\": {\n        \"allowed\": false,\n        \"reason\": \"shell metacharacter rejected before execution\"\n      }\n    }\n  },\n  \"vulnerable\": true\n}\n```\n\nInterpretation:\n\n- Direct `cat \u003cmarker\u003e` is rejected by the allowlist.\n- Benign `echo allowed` is accepted.\n- `echo allowed; cat \u003cmarker\u003e` is accepted by the same allowlist and executes the non-allowlisted `cat`.\n- A patched-control validator that rejects shell metacharacters before execution blocks the chained command while still allowing benign `echo`.\n\nThe PoV installs `npm:praisonai@1.7.1` into a temporary project, creates a temporary marker file, and reads only that file. It does not contact any live service or execute destructive commands.\n\n## PoC\n\nThe PoV section above contains the local reproduction command, input, and decisive output.\n\n## Impact\n\nIf lower-trust users, prompts, or model output can influence a command string sent to `SandboxExecutor` or `sandboxExec`, `allowedCommands` does not enforce the intended command boundary. An attacker can append arbitrary shell commands after an allowed first token and run them with the privileges of the PraisonAI process.\n\nConcrete consequences depend on the hosting application and configured process privileges, but can include reading or modifying files, invoking local tools, using available credentials, or causing denial of service.\n\nThis report does not claim that npm PraisonAI exposes this as a default network service. It is a library-level sandbox/allowlist bypass in an exported TypeScript API that is explicitly designed for safe command execution.\n\n### Severity\n\nSuggested severity: High.\n\nRationale:\n\n- `AV`: common deployment pattern is an application exposing agent prompts or command automation over a network.\n- `AC`: attacker only needs to induce or submit a command string that starts with an allowed command.\n- `PR`: conservative base score assumes the attacker can submit prompts or command requests to the application.\n- `UI`: no operator action is needed once the command reaches the executor.\n- `S`: impact is in the PraisonAI-hosting process.\n- `C/I/A`: arbitrary shell commands can affect confidentiality, integrity, and availability depending on process privileges.\n\nIf maintainers score only local CLI use, `AV:L` may be reasonable. If they score public unauthenticated prompt or command endpoints built on this API, `PR:N` may be reasonable.\n\n## Suggested Fix\n\nAvoid passing policy-checked user strings to a shell.\n\nRecommended:\n\n1. Require callers to pass `{ command, args }`, or parse command strings into argv with a shell-aware parser.\n2. Execute with `spawn(command, args, { shell: false })` / `execFile()` instead of `sh -c`.\n3. Apply `allowedCommands` to the exact executable after normalization.\n4. Reject shell metacharacters (`;`, `\u0026\u0026`, `||`, `|`, backticks, `$()`, newline, redirects) when a shell string API must be kept for compatibility.\n5. Add regression tests proving `allowedCommands: [\"echo\"]` allows `echo ok` but rejects `cat marker`, `echo ok; cat marker`, `echo ok \u0026\u0026 cat marker`, and `echo ok | cat marker`.\n\n## Affected Package/Versions\n\n- Repository: `MervinPraison/PraisonAI`\n- Package: `npm:praisonai`\n- Component: TypeScript CLI feature `SandboxExecutor`\n- Current head validated: `1ad58ca02975ff1398efeda694ea2ab78f20cf3e`\n- Current tag validated: `v4.6.58`\n- Latest npm package validated: `1.7.1`\n\nSuggested affected range:\n\n```text\nnpm:praisonai \u003e= 1.2.3, \u003c= 1.7.1\n```\n\nSelected version sweep:\n\n- `1.0.0`: package main cannot be required in the selected test environment.\n- `1.2.0`, `1.2.1`, `1.2.2`: `SandboxExecutor` is not exported.\n- `1.2.3`: vulnerable.\n- `1.2.4`: vulnerable.\n- `1.3.0`: vulnerable.\n- `1.3.6`: vulnerable.\n- `1.4.0`: vulnerable.\n- `1.5.0`: vulnerable.\n- `1.5.4`: vulnerable.\n- `1.6.0`: vulnerable.\n- `1.7.0`: vulnerable.\n- `1.7.1`: vulnerable.\n\n## Advisory History\n\nThis is distinct from known and previously submitted PraisonAI issues:\n\n- `GHSA-r4f2-3m54-pp7q` covers PyPI `SubprocessSandbox` `shell=True` and blocklist bypass.\n- `GHSA-2763-cj5r-c79m` covers PyPI `praisonai` OS command injection.\n- `GHSA-v7px-3835-7gjx` covers PyPI `memory/hooks.py` shell injection.\n- `GHSA-4wr3-f4p3-5wjh` covers Python agent tool approval allow-list manipulation.\n- `GHSA-4mr5-g6f9-cfrh` covers PyPI/Python `execute_code` sandbox escape.\n- `GHSA-9qhq-v63v-fv3j` covers an incomplete fix for a Python command injection.\n- `GHSA-vmmj-pfw7-fjwp` covers npm `codeMode` host-process `new Function` sandbox escape.\n\nNo visible local or GitHub advisory covers npm TypeScript `SandboxExecutor`, `CommandValidator`, `allowedCommands`, or the first-token allowlist followed by `sh -c` shell-chaining root cause.",
  "id": "GHSA-vjv9-7m7j-h833",
  "modified": "2026-06-18T14:26:35Z",
  "published": "2026-06-18T14:26:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-vjv9-7m7j-h833"
    },
    {
      "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:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "npm PraisonAI SandboxExecutor allowedCommands bypass via shell chaining"
}

GHSA-VJWH-P6R4-4Q46

Vulnerability from github – Published: 2023-06-15 12:30 – Updated: 2024-04-04 04:51
VLAI
Details

Improper Authorization in SSH server in Bosch VMS 11.0, 11.1.0, and 11.1.1 allows a remote authenticated user to access resources within the trusted internal network via a port forwarding request.

Severity
7.1 (High)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-28175"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-15T11:15:09Z",
    "severity": "HIGH"
  },
  "details": "Improper Authorization in SSH server in Bosch VMS 11.0, 11.1.0, and 11.1.1 allows a remote authenticated user to access resources within the trusted internal network via a port forwarding request.",
  "id": "GHSA-vjwh-p6r4-4q46",
  "modified": "2024-04-04T04:51:51Z",
  "published": "2023-06-15T12:30:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28175"
    },
    {
      "type": "WEB",
      "url": "https://psirt.bosch.com/security-advisories/BOSCH-SA-025794-bt.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VM3H-24GM-V3Q6

Vulnerability from github – Published: 2023-04-16 00:30 – Updated: 2024-04-04 03:29
VLAI
Details

LilyPond before 2.24 allows attackers to bypass the -dsafe protection mechanism via output-def-lookup or output-def-scope, as demonstrated by dangerous Scheme code in a .ly file that causes arbitrary code execution during conversion to a different file format. NOTE: in 2.24 and later versions, safe mode is removed, and the product no longer tries to block code execution when external files are used.

Severity
8.6 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-17354"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-15T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "LilyPond before 2.24 allows attackers to bypass the -dsafe protection mechanism via output-def-lookup or output-def-scope, as demonstrated by dangerous Scheme code in a .ly file that causes arbitrary code execution during conversion to a different file format. NOTE: in 2.24 and later versions, safe mode is removed, and the product no longer tries to block code execution when external files are used.",
  "id": "GHSA-vm3h-24gm-v3q6",
  "modified": "2024-04-04T03:29:41Z",
  "published": "2023-04-16T00:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-17354"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/lilypond/lilypond/-/merge_requests/1522"
    },
    {
      "type": "WEB",
      "url": "https://lilypond.org/download.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/K43PF6VGFJNNGAPY57BW3VMEFFOSMRLF"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ST5BLLQ4GDME3SN7UE5OMNE5GZE66X4Y"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/K43PF6VGFJNNGAPY57BW3VMEFFOSMRLF"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ST5BLLQ4GDME3SN7UE5OMNE5GZE66X4Y"
    },
    {
      "type": "WEB",
      "url": "https://phabricator.wikimedia.org/T259210"
    },
    {
      "type": "WEB",
      "url": "https://tracker.debian.org/news/1249694/accepted-lilypond-2221-1-source-into-unstable"
    },
    {
      "type": "WEB",
      "url": "https://www.mediawiki.org/wiki/Extension:Score/2021_security_advisory"
    },
    {
      "type": "WEB",
      "url": "http://lilypond.org/doc/v2.18/Documentation/usage/command_002dline-usage"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VM7J-VM2J-XWX7

Vulnerability from github – Published: 2022-05-24 17:39 – Updated: 2022-09-21 00:00
VLAI
Details

Multiple vulnerabilities in the web-based management interface of Cisco SD-WAN vManage Software could allow an authenticated, remote attacker to bypass authorization and modify the configuration of an affected system, gain access to sensitive information, and view information that they are not authorized to access. For more information about these vulnerabilities, see the Details section of this advisory.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-1305"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-20T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Multiple vulnerabilities in the web-based management interface of Cisco SD-WAN vManage Software could allow an authenticated, remote attacker to bypass authorization and modify the configuration of an affected system, gain access to sensitive information, and view information that they are not authorized to access.\n For more information about these vulnerabilities, see the Details section of this advisory.\n ",
  "id": "GHSA-vm7j-vm2j-xwx7",
  "modified": "2022-09-21T00:00:42Z",
  "published": "2022-05-24T17:39:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1305"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-abyp-TnGFHrS"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VM99-JJC2-8HW5

Vulnerability from github – Published: 2024-09-09 12:31 – Updated: 2024-09-17 18:33
VLAI
Details

This vulnerability exists in TechExcel Back Office Software versions prior to 1.0.0 due to improper access controls on certain API endpoints. An authenticated remote attacker could exploit this vulnerability by manipulating a parameter through API request URL which could lead to unauthorized access to sensitive information belonging to other users.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-8601"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-09T10:15:03Z",
    "severity": "HIGH"
  },
  "details": "This vulnerability exists in TechExcel Back Office Software versions prior to 1.0.0 due to improper access controls on certain API endpoints. An authenticated remote attacker could exploit this vulnerability by manipulating a parameter through API request URL which could lead to unauthorized access to sensitive information belonging to other users.",
  "id": "GHSA-vm99-jjc2-8hw5",
  "modified": "2024-09-17T18:33:24Z",
  "published": "2024-09-09T12:31:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8601"
    },
    {
      "type": "WEB",
      "url": "https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES01\u0026VLCODE=CIVN-2024-0285"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-VM9X-85QM-FVQ3

Vulnerability from github – Published: 2023-12-22 18:30 – Updated: 2023-12-22 18:30
VLAI
Details

The api /api/snapshot and /api/get_log_file would allow unauthenticated access. It could allow a DoS attack or get arbitrary files from FE node. Please upgrade to 2.0.3 to fix these issues.

Severity
8.2 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-41314"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-18T09:15:05Z",
    "severity": "HIGH"
  },
  "details": "The api /api/snapshot and /api/get_log_file would allow unauthenticated access.\nIt could allow a\u00a0DoS attack or get arbitrary files from FE node.\nPlease\u00a0upgrade to 2.0.3 to fix these issues.",
  "id": "GHSA-vm9x-85qm-fvq3",
  "modified": "2023-12-22T18:30:30Z",
  "published": "2023-12-22T18:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41314"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/tgvpvz3yw7zgodl1sb3sv3jbbz8t5zb4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VMHF-WMJ5-JX54

Vulnerability from github – Published: 2025-04-17 12:30 – Updated: 2025-04-17 12:30
VLAI
Details

The Password Protected – Password Protect your WordPress Site, Pages, & WooCommerce Products – Restrict Content, Protect WooCommerce Category and more plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 2.7.7 via the 'password_protected_cookie' function. This makes it possible for unauthenticated attackers to extract sensitive data including all protected site content if the 'Use Transient' setting is enabled.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-3453"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-17T12:15:15Z",
    "severity": "MODERATE"
  },
  "details": "The Password Protected \u2013 Password Protect your WordPress Site, Pages, \u0026 WooCommerce Products \u2013 Restrict Content, Protect WooCommerce Category and more plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 2.7.7 via the \u0027password_protected_cookie\u0027 function. This makes it possible for unauthenticated attackers to extract sensitive data including all protected site content if the \u0027Use Transient\u0027 setting is enabled.",
  "id": "GHSA-vmhf-wmj5-jx54",
  "modified": "2025-04-17T12:30:33Z",
  "published": "2025-04-17T12:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3453"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/password-protected/trunk/includes/compatibility.php"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3274358"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/241d75ca-55e3-461a-9844-52e69904da1b?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VMHQ-CQM9-6P7Q

Vulnerability from github – Published: 2026-03-13 20:54 – Updated: 2026-03-13 20:54
VLAI
Summary
OpenClaw: `browser.request` let `operator.write` persist admin-only browser profile changes
Details

Summary

An authorization mismatch in the gateway let an authenticated caller with only operator.write use browser.request to reach browser profile management routes that persist configuration to disk. In practice, this exposed an admin-only configuration write primitive through /profiles/create.

Impact

A write-scoped operator could create or modify browser profiles and store attacker-chosen remote CDP endpoints without holding operator.admin.

Affected versions

openclaw <= 2026.3.8

Patch

Fixed in openclaw 2026.3.11 and included in later releases such as 2026.3.12. Browser profile creation now requires the correct admin boundary, and regression tests cover the write-vs-admin authorization split.

Severity
7.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.8"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-13T20:54:25Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nAn authorization mismatch in the gateway let an authenticated caller with only `operator.write` use `browser.request` to reach browser profile management routes that persist configuration to disk. In practice, this exposed an admin-only configuration write primitive through `/profiles/create`.\n\n### Impact\n\nA write-scoped operator could create or modify browser profiles and store attacker-chosen remote CDP endpoints without holding `operator.admin`.\n\n### Affected versions\n\n`openclaw` `\u003c= 2026.3.8`\n\n### Patch\n\nFixed in `openclaw` `2026.3.11` and included in later releases such as `2026.3.12`. Browser profile creation now requires the correct admin boundary, and regression tests cover the write-vs-admin authorization split.",
  "id": "GHSA-vmhq-cqm9-6p7q",
  "modified": "2026-03-13T20:54:25Z",
  "published": "2026-03-13T20:54:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-vmhq-cqm9-6p7q"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenClaw: `browser.request` let `operator.write` persist admin-only browser profile changes"
}

GHSA-VMJJ-QR7V-PXM6

Vulnerability from github – Published: 2026-04-16 00:47 – Updated: 2026-04-24 20:54
VLAI
Summary
Froxlor has an Email Sender Alias Domain Ownership Bypass via Wrong Array Index Allows Cross-Customer Email Spoofing
Details

Summary

In EmailSender::add(), the domain ownership validation for full email sender aliases uses the wrong array index when splitting the email address, passing the local part instead of the domain to validateLocalDomainOwnership(). This causes the ownership check to always pass for non-existent "domains," allowing any authenticated customer to add sender aliases for email addresses on domains belonging to other customers. Postfix's sender_login_maps then authorizes the attacker to send emails as those addresses.

Details

In lib/Froxlor/Api/Commands/EmailSender.php at line 100, when a customer adds a full email address (not a @domain wildcard) as an allowed sender, the code splits on @ and takes index [0]:

// Line 96-106
if (substr($allowed_sender, 0, 1) != '@') {
    if (!Validate::validateEmail($idna_convert->encode($allowed_sender))) {
        Response::standardError('emailiswrong', $allowed_sender, true);
    }
    self::validateLocalDomainOwnership(explode("@", $allowed_sender)[0] ?? "");  // BUG: [0] is the local part
} else {
    if (!Validate::validateDomain($idna_convert->encode(substr($allowed_sender, 1)))) {
        Response::standardError('wildcardemailiswrong', substr($allowed_sender, 1), true);
    }
    self::validateLocalDomainOwnership(substr($allowed_sender, 1));  // CORRECT: passes domain
}

For input admin@domain-b.com, explode("@", "admin@domain-b.com") returns ["admin", "domain-b.com"]. Index [0] is "admin" — the local part, not the domain.

The validateLocalDomainOwnership() function (lines 346-355) then queries panel_domains for a domain matching "admin":

private static function validateLocalDomainOwnership(string $domain): void
{
    $sel_stmt = Database::prepare("SELECT customerid FROM `" . TABLE_PANEL_DOMAINS . "` WHERE `domain` = :domain");
    $domain_result = Database::pexecute_first($sel_stmt, ['domain' => $domain]);
    if ($domain_result && $domain_result['customerid'] != CurrentUser::getField('customerid')) {
        Response::standardError('senderdomainnotowned', $domain, true);
    }
}

Since no domain named "admin" exists in panel_domains, $domain_result is false, and the function returns without error — the ownership check silently passes.

The inserted mail_sender_aliases row is then picked up by Postfix's sender_login_maps query (configured in mysql-virtual_sender_permissions.cf):

... UNION (SELECT mail_sender_aliases.email FROM mail_sender_aliases
WHERE mail_sender_aliases.allowed_sender = '%s') ...

This query maps the allowed_sender back to the mail user, authorizing them to send as that address via SMTP.

PoC

# Prerequisites: Froxlor instance with mail.enable_allow_sender enabled,
# two customers: Customer A (owns domain-a.com) and Customer B (owns domain-b.com)

# Step 1: As Customer A, add a sender alias claiming Customer B's domain
# Via API:
curl -X POST 'https://froxlor-host/api/v1/' \
  -H 'Authorization: Basic <customer-A-credentials>' \
  -H 'Content-Type: application/json' \
  -d '{
    "command": "EmailSender.add",
    "params": {
      "emailaddr": "myaccount@domain-a.com",
      "allowed_sender": "ceo@domain-b.com"
    }
  }'

# Expected: Error "senderdomainnotowned" because domain-b.com belongs to Customer B
# Actual: 200 OK — alias is created because validateLocalDomainOwnership
#         receives "ceo" (local part) instead of "domain-b.com" (domain)

# Step 2: Verify the alias was inserted
curl -X POST 'https://froxlor-host/api/v1/' \
  -H 'Authorization: Basic <customer-A-credentials>' \
  -H 'Content-Type: application/json' \
  -d '{
    "command": "EmailSender.listing",
    "params": {"emailaddr": "myaccount@domain-a.com"}
  }'

# Step 3: Customer A can now send email as ceo@domain-b.com via SMTP
# because Postfix sender_login_maps will match the mail_sender_aliases entry
# and authorize Customer A's mail account to use that sender address.

The same attack works via the web UI by POST-ing to customer_email.php with action=add_sender and the target domain in allowed_domain.

Impact

Any authenticated customer on a multi-tenant Froxlor instance can add sender aliases for email addresses on domains belonging to other customers. This allows:

  • Cross-customer email spoofing: Send emails impersonating users on other customers' domains, bypassing Postfix's smtpd_sender_login_maps restriction that is specifically designed to prevent this.
  • Multi-tenant isolation breach: The domain ownership check (validateLocalDomainOwnership) is the only barrier preventing cross-customer sender aliasing, and it is completely ineffective for full email addresses.
  • Phishing and reputation damage: Spoofed emails originate from the legitimate mail server, passing SPF/DKIM checks for the target domain if those records point to the Froxlor server.

Note: The wildcard (@domain) code path at line 105 is not affected — it correctly passes the domain to validateLocalDomainOwnership().

Recommended Fix

Change index [0] to [1] on line 100 of lib/Froxlor/Api/Commands/EmailSender.php:

// Before (line 100):
self::validateLocalDomainOwnership(explode("@", $allowed_sender)[0] ?? "");

// After:
self::validateLocalDomainOwnership(explode("@", $allowed_sender)[1] ?? "");

This ensures the domain part of the email address is passed to the ownership validation, matching the behavior of the wildcard path on line 105.

Severity
5.0 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "froxlor/froxlor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41232"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T00:47:05Z",
    "nvd_published_at": "2026-04-23T05:16:05Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nIn `EmailSender::add()`, the domain ownership validation for full email sender aliases uses the wrong array index when splitting the email address, passing the local part instead of the domain to `validateLocalDomainOwnership()`. This causes the ownership check to always pass for non-existent \"domains,\" allowing any authenticated customer to add sender aliases for email addresses on domains belonging to other customers. Postfix\u0027s `sender_login_maps` then authorizes the attacker to send emails as those addresses.\n\n## Details\n\nIn `lib/Froxlor/Api/Commands/EmailSender.php` at line 100, when a customer adds a full email address (not a `@domain` wildcard) as an allowed sender, the code splits on `@` and takes index `[0]`:\n\n```php\n// Line 96-106\nif (substr($allowed_sender, 0, 1) != \u0027@\u0027) {\n    if (!Validate::validateEmail($idna_convert-\u003eencode($allowed_sender))) {\n        Response::standardError(\u0027emailiswrong\u0027, $allowed_sender, true);\n    }\n    self::validateLocalDomainOwnership(explode(\"@\", $allowed_sender)[0] ?? \"\");  // BUG: [0] is the local part\n} else {\n    if (!Validate::validateDomain($idna_convert-\u003eencode(substr($allowed_sender, 1)))) {\n        Response::standardError(\u0027wildcardemailiswrong\u0027, substr($allowed_sender, 1), true);\n    }\n    self::validateLocalDomainOwnership(substr($allowed_sender, 1));  // CORRECT: passes domain\n}\n```\n\nFor input `admin@domain-b.com`, `explode(\"@\", \"admin@domain-b.com\")` returns `[\"admin\", \"domain-b.com\"]`. Index `[0]` is `\"admin\"` \u2014 the local part, not the domain.\n\nThe `validateLocalDomainOwnership()` function (lines 346-355) then queries `panel_domains` for a domain matching `\"admin\"`:\n\n```php\nprivate static function validateLocalDomainOwnership(string $domain): void\n{\n    $sel_stmt = Database::prepare(\"SELECT customerid FROM `\" . TABLE_PANEL_DOMAINS . \"` WHERE `domain` = :domain\");\n    $domain_result = Database::pexecute_first($sel_stmt, [\u0027domain\u0027 =\u003e $domain]);\n    if ($domain_result \u0026\u0026 $domain_result[\u0027customerid\u0027] != CurrentUser::getField(\u0027customerid\u0027)) {\n        Response::standardError(\u0027senderdomainnotowned\u0027, $domain, true);\n    }\n}\n```\n\nSince no domain named `\"admin\"` exists in `panel_domains`, `$domain_result` is false, and the function returns without error \u2014 the ownership check silently passes.\n\nThe inserted `mail_sender_aliases` row is then picked up by Postfix\u0027s `sender_login_maps` query (configured in `mysql-virtual_sender_permissions.cf`):\n\n```sql\n... UNION (SELECT mail_sender_aliases.email FROM mail_sender_aliases\nWHERE mail_sender_aliases.allowed_sender = \u0027%s\u0027) ...\n```\n\nThis query maps the `allowed_sender` back to the mail user, authorizing them to send as that address via SMTP.\n\n## PoC\n\n```bash\n# Prerequisites: Froxlor instance with mail.enable_allow_sender enabled,\n# two customers: Customer A (owns domain-a.com) and Customer B (owns domain-b.com)\n\n# Step 1: As Customer A, add a sender alias claiming Customer B\u0027s domain\n# Via API:\ncurl -X POST \u0027https://froxlor-host/api/v1/\u0027 \\\n  -H \u0027Authorization: Basic \u003ccustomer-A-credentials\u003e\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\n    \"command\": \"EmailSender.add\",\n    \"params\": {\n      \"emailaddr\": \"myaccount@domain-a.com\",\n      \"allowed_sender\": \"ceo@domain-b.com\"\n    }\n  }\u0027\n\n# Expected: Error \"senderdomainnotowned\" because domain-b.com belongs to Customer B\n# Actual: 200 OK \u2014 alias is created because validateLocalDomainOwnership\n#         receives \"ceo\" (local part) instead of \"domain-b.com\" (domain)\n\n# Step 2: Verify the alias was inserted\ncurl -X POST \u0027https://froxlor-host/api/v1/\u0027 \\\n  -H \u0027Authorization: Basic \u003ccustomer-A-credentials\u003e\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\n    \"command\": \"EmailSender.listing\",\n    \"params\": {\"emailaddr\": \"myaccount@domain-a.com\"}\n  }\u0027\n\n# Step 3: Customer A can now send email as ceo@domain-b.com via SMTP\n# because Postfix sender_login_maps will match the mail_sender_aliases entry\n# and authorize Customer A\u0027s mail account to use that sender address.\n```\n\nThe same attack works via the web UI by POST-ing to `customer_email.php` with `action=add_sender` and the target domain in `allowed_domain`.\n\n## Impact\n\nAny authenticated customer on a multi-tenant Froxlor instance can add sender aliases for email addresses on domains belonging to other customers. This allows:\n\n- **Cross-customer email spoofing**: Send emails impersonating users on other customers\u0027 domains, bypassing Postfix\u0027s `smtpd_sender_login_maps` restriction that is specifically designed to prevent this.\n- **Multi-tenant isolation breach**: The domain ownership check (`validateLocalDomainOwnership`) is the only barrier preventing cross-customer sender aliasing, and it is completely ineffective for full email addresses.\n- **Phishing and reputation damage**: Spoofed emails originate from the legitimate mail server, passing SPF/DKIM checks for the target domain if those records point to the Froxlor server.\n\nNote: The wildcard (`@domain`) code path at line 105 is **not** affected \u2014 it correctly passes the domain to `validateLocalDomainOwnership()`.\n\n## Recommended Fix\n\nChange index `[0]` to `[1]` on line 100 of `lib/Froxlor/Api/Commands/EmailSender.php`:\n\n```php\n// Before (line 100):\nself::validateLocalDomainOwnership(explode(\"@\", $allowed_sender)[0] ?? \"\");\n\n// After:\nself::validateLocalDomainOwnership(explode(\"@\", $allowed_sender)[1] ?? \"\");\n```\n\nThis ensures the domain part of the email address is passed to the ownership validation, matching the behavior of the wildcard path on line 105.",
  "id": "GHSA-vmjj-qr7v-pxm6",
  "modified": "2026-04-24T20:54:28Z",
  "published": "2026-04-16T00:47:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/froxlor/froxlor/security/advisories/GHSA-vmjj-qr7v-pxm6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41232"
    },
    {
      "type": "WEB",
      "url": "https://github.com/froxlor/froxlor/commit/77d04badf549d5f8429828f0fbc69bc37a35e07a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/froxlor/froxlor"
    },
    {
      "type": "WEB",
      "url": "https://github.com/froxlor/froxlor/releases/tag/2.3.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Froxlor has an Email Sender Alias Domain Ownership Bypass via Wrong Array Index Allows Cross-Customer Email Spoofing"
}

GHSA-VMQR-HRFR-7527

Vulnerability from github – Published: 2025-06-03 09:32 – Updated: 2025-10-22 00:33
VLAI
Details

Memory corruption due to unauthorized command execution in GPU micronode while executing specific sequence of commands.

Severity
8.6 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-21479"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-03T07:15:20Z",
    "severity": "HIGH"
  },
  "details": "Memory corruption due to unauthorized command execution in GPU micronode while executing specific sequence of commands.",
  "id": "GHSA-vmqr-hrfr-7527",
  "modified": "2025-10-22T00:33:19Z",
  "published": "2025-06-03T09:32:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21479"
    },
    {
      "type": "WEB",
      "url": "https://docs.qualcomm.com/product/publicresources/securitybulletin/june-2025-bulletin.html"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2025-21479"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design
  • Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
  • For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
  • One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list