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.

5540 vulnerabilities reference this CWE, most recent first.

GHSA-VJJW-C569-5C3P

Vulnerability from github – Published: 2025-01-21 21:30 – Updated: 2025-01-21 21:30
VLAI
Details

Vulnerability in the PeopleSoft Enterprise CC Common Application Objects product of Oracle PeopleSoft (component: Run Control Management). The supported version that is affected is 9.2. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise PeopleSoft Enterprise CC Common Application Objects. Successful attacks of this vulnerability can result in unauthorized read access to a subset of PeopleSoft Enterprise CC Common Application Objects accessible data. CVSS 3.1 Base Score 4.3 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).

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-2025-21562"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-21T21:15:23Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the PeopleSoft Enterprise CC Common Application Objects product of Oracle PeopleSoft (component: Run Control Management).   The supported version that is affected is 9.2. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise PeopleSoft Enterprise CC Common Application Objects.  Successful attacks of this vulnerability can result in  unauthorized read access to a subset of PeopleSoft Enterprise CC Common Application Objects accessible data. CVSS 3.1 Base Score 4.3 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).",
  "id": "GHSA-vjjw-c569-5c3p",
  "modified": "2025-01-21T21:30:56Z",
  "published": "2025-01-21T21:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21562"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2025.html"
    }
  ],
  "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-VJJX-RFW4-RMFC

Vulnerability from github – Published: 2026-07-01 20:10 – Updated: 2026-07-01 20:10
VLAI
Summary
SurrealDB: Graph traversal bypasses table SELECT permissions
Details

An authenticated record or scope user could read records on any table reachable through a graph edge or REFERENCES TO back-reference, regardless of that table's PERMISSIONS FOR select clause.

Traversing SELECT * FROM source->edge->target returned full documents from target even when target was defined as PERMISSIONS FOR select NONE. The same bypass extended through multi-hop chains, so any table reachable by a sequence of edges from a readable starting point was exposed.

The root cause: GraphEdgeScan and ReferenceScan fetched records straight from storage without routing them through Document::pluck_select, so the target table's permission expression was never consulted.

Impact

An authenticated record or scope user can read records on any table reachable through a chain of graph edges or back-references from a table they have select on, regardless of the target's PERMISSIONS FOR select clause. Confidentiality-only and bounded to the caller's current database — namespace and database isolation are unaffected.

Patches

A new per-batch permission cache (exec::permission::CachedTableSelect) resolves each target table's SELECT permission once and filters yielded values through check_permission_for_value, matching the regular SELECT code path.

  • Versions 3.1.0 and later are not affected.

Workarounds

  • Remove select permission on edge tables whose targets should be hidden.
  • Use namespace or database isolation as the primary boundary where feasible.
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "surrealdb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T20:10:34Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "An authenticated record or scope user could read records on any table reachable through a graph edge or `REFERENCES TO` back-reference, regardless of that table\u0027s `PERMISSIONS FOR select` clause.\n\nTraversing `SELECT * FROM source-\u003eedge-\u003etarget` returned full documents from `target` even when `target` was defined as `PERMISSIONS FOR select NONE`. The same bypass extended through multi-hop chains, so any table reachable by a sequence of edges from a readable starting point was exposed.\n\nThe root cause: `GraphEdgeScan` and `ReferenceScan` fetched records straight from storage without routing them through `Document::pluck_select`, so the target table\u0027s permission expression was never consulted.\n\n### Impact\n\nAn authenticated record or scope user can read records on any table reachable through a chain of graph edges or back-references from a table they have `select` on, regardless of the target\u0027s `PERMISSIONS FOR select` clause. Confidentiality-only and bounded to the caller\u0027s current database \u2014 namespace and database isolation are unaffected.\n\n### Patches\n\nA new per-batch permission cache (`exec::permission::CachedTableSelect`) resolves each target table\u0027s `SELECT` permission once and filters yielded values through `check_permission_for_value`, matching the regular `SELECT` code path.\n\n- Versions 3.1.0 and later are not affected.\n\n### Workarounds\n\n- Remove `select` permission on edge tables whose targets should be hidden.\n- Use namespace or database isolation as the primary boundary where feasible.",
  "id": "GHSA-vjjx-rfw4-rmfc",
  "modified": "2026-07-01T20:10:34Z",
  "published": "2026-07-01T20:10:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-vjjx-rfw4-rmfc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/surrealdb/surrealdb"
    }
  ],
  "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"
    }
  ],
  "summary": "SurrealDB: Graph traversal bypasses table SELECT permissions"
}

GHSA-VJMM-VXXF-QMX4

Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-08-06 00:00
VLAI
Details

A flaw was found in the BPMN editor in version jBPM 7.51.0.Final. Any authenticated user from any project can see the name of Ruleflow Groups from other projects, despite the user not having access to those projects. The highest threat from this vulnerability is to confidentiality.

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-20306"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-01T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in the BPMN editor in version jBPM 7.51.0.Final. Any authenticated user from any project can see the name of Ruleflow Groups from other projects, despite the user not having access to those projects. The highest threat from this vulnerability is to confidentiality.",
  "id": "GHSA-vjmm-vxxf-qmx4",
  "modified": "2022-08-06T00:00:48Z",
  "published": "2022-05-24T19:03:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20306"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1946213"
    }
  ],
  "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-VJP8-WPRM-2JW9

Vulnerability from github – Published: 2026-03-04 18:56 – Updated: 2026-03-30 13:42
VLAI
Summary
OpenClaw has cross-account DM pairing authorization bypass via unscoped pairing store access
Details

Summary

OpenClaw had account-scope gaps in pairing-store access for DM pairing policy, which could let a pairing approval from one account authorize the same sender on another account in multi-account setups.

Impact

This is an authorization-boundary weakness in multi-account channel deployments. A sender approved in one account could be accepted in another account before explicit approval there.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Latest published version affected: 2026.2.25
  • Vulnerable range: <= 2026.2.25
  • Patched version (planned next release): >= 2026.2.26

Fix

OpenClaw now enforces account-scoped pairing reads/writes consistently across core and extension message channels, with stricter runtime/SDK helpers and shared policy wiring to prevent cross-account pairing bleed.

Fix Commit(s)

  • a0c5e28f3bf0cc0cd9311f9e9ec2ca0352550dcf
  • bce643a0bd145d3e9cb55400af33bd1b85baeb02

Release Process Note

patched_versions is pre-set to the planned next release (2026.2.26). After npm publish of that version, this advisory is ready to publish without further content edits.

OpenClaw thanks @tdjackey for reporting.

Severity
3.7 (Low)
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N
2.0 (Low)
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.2.25"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.26"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32067"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-04T18:56:10Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\nOpenClaw had account-scope gaps in pairing-store access for DM pairing policy, which could let a pairing approval from one account authorize the same sender on another account in multi-account setups.\n\n### Impact\nThis is an authorization-boundary weakness in multi-account channel deployments. A sender approved in one account could be accepted in another account before explicit approval there.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published version affected: `2026.2.25`\n- Vulnerable range: `\u003c= 2026.2.25`\n- Patched version (planned next release): `\u003e= 2026.2.26`\n\n### Fix\nOpenClaw now enforces account-scoped pairing reads/writes consistently across core and extension message channels, with stricter runtime/SDK helpers and shared policy wiring to prevent cross-account pairing bleed.\n\n### Fix Commit(s)\n- `a0c5e28f3bf0cc0cd9311f9e9ec2ca0352550dcf`\n- `bce643a0bd145d3e9cb55400af33bd1b85baeb02`\n\n### Release Process Note\n`patched_versions` is pre-set to the planned next release (`2026.2.26`). After npm publish of that version, this advisory is ready to publish without further content edits.\n\nOpenClaw thanks @tdjackey for reporting.",
  "id": "GHSA-vjp8-wprm-2jw9",
  "modified": "2026-03-30T13:42:54Z",
  "published": "2026-03-04T18:56:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-vjp8-wprm-2jw9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32067"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/a0c5e28f3bf0cc0cd9311f9e9ec2ca0352550dcf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/bce643a0bd145d3e9cb55400af33bd1b85baeb02"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-cross-account-authorization-bypass-in-dm-pairing-store"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw has cross-account DM pairing authorization bypass via unscoped pairing store access"
}

GHSA-VJPH-QJ4M-F5G8

Vulnerability from github – Published: 2024-04-25 15:30 – Updated: 2024-04-25 15:30
VLAI
Details

An issue has been discovered in GitLab CE/EE affecting all versions starting from 16.7 before 16.9.6, all versions starting from 16.10 before 16.10.4, all versions starting from 16.11 before 16.11.1 where personal access scopes were not honored by GraphQL subscriptions

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-2024-4006"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-25T14:15:09Z",
    "severity": "MODERATE"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions starting from 16.7 before 16.9.6, all versions starting from 16.10 before 16.10.4, all versions starting from 16.11 before 16.11.1 where personal access scopes were not honored by GraphQL subscriptions",
  "id": "GHSA-vjph-qj4m-f5g8",
  "modified": "2024-04-25T15:30:37Z",
  "published": "2024-04-25T15:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4006"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/455805"
    }
  ],
  "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-VJRR-3C22-J86F

Vulnerability from github – Published: 2022-07-07 00:00 – Updated: 2022-07-15 00:00
VLAI
Details

The client in Northern.tech Mender 3.2.0, 3.2.1, and 3.2.2 has Incorrect Access Control. It listens on a random, unprivileged TCP port and exposes an HTTP proxy to facilitate API calls from additional client components running on the device. However, it listens on all network interfaces instead of only the localhost interface. Therefore, any client on the same network can connect to this TCP port and send HTTP requests. The Mender Client will forward these requests to the Mender Server. Additionally, if mTLS is set up, the Mender Client will connect to the Mender Server using the device's client certificate, making it possible for the attacker to bypass mTLS authentication and send requests to the Mender Server without direct access to the client certificate and related private key. Accessing the HTTP proxy from the local network doesn't represent a direct threat, because it doesn't expose any device or server-specific data. However, it increases the attack surface and can be a potential vector to exploit other vulnerabilities both on the Client and the Server.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-32290"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-06T12:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The client in Northern.tech Mender 3.2.0, 3.2.1, and 3.2.2 has Incorrect Access Control. It listens on a random, unprivileged TCP port and exposes an HTTP proxy to facilitate API calls from additional client components running on the device. However, it listens on all network interfaces instead of only the localhost interface. Therefore, any client on the same network can connect to this TCP port and send HTTP requests. The Mender Client will forward these requests to the Mender Server. Additionally, if mTLS is set up, the Mender Client will connect to the Mender Server using the device\u0027s client certificate, making it possible for the attacker to bypass mTLS authentication and send requests to the Mender Server without direct access to the client certificate and related private key. Accessing the HTTP proxy from the local network doesn\u0027t represent a direct threat, because it doesn\u0027t expose any device or server-specific data. However, it increases the attack surface and can be a potential vector to exploit other vulnerabilities both on the Client and the Server.",
  "id": "GHSA-vjrr-3c22-j86f",
  "modified": "2022-07-15T00:00:15Z",
  "published": "2022-07-07T00:00:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32290"
    },
    {
      "type": "WEB",
      "url": "https://mender.io/blog/cve-2022-32290-mender-client-listening-on-all-the-interfaces"
    },
    {
      "type": "WEB",
      "url": "https://northern.tech"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VJV5-GP2W-65VM

Vulnerability from github – Published: 2021-07-19 15:15 – Updated: 2022-04-19 15:15
VLAI
Summary
Encoded URIs can access WEB-INF directory in Eclipse Jetty
Details

Description

URIs can be crafted using some encoded characters to access the content of the WEB-INF directory and/or bypass some security constraints. This is a variation of the vulnerability reported in CVE-2021-28164/GHSA-v7ff-8wcx-gmc5.

Impact

The default compliance mode allows requests with URIs that contain a %u002e segment to access protected resources within the WEB-INF directory. For example, a request to /%u002e/WEB-INF/web.xml can retrieve the web.xml file. This can reveal sensitive information regarding the implementation of a web application. Similarly, an encoded null character can prevent correct normalization so that /.%00/WEB-INF/web.xml cal also retrieve the web.xml file.

Workarounds

Some Jetty rewrite rules can be deployed to rewrite any request containing encoded dot segments or null characters in the raw request URI, to a known not found resource:

<Call name="addRule">
  <Arg>
    <New class="org.eclipse.jetty.rewrite.handler.RewriteRegexRule">
      <Set name="regex">.*/(?:\.+/)+.*</Set>
      <Set name="replacement">/WEB-INF/Not-Found</Set>
    </New>
  </Arg>
</Call>
<Call name="addRule">
  <Arg>
    <New class="org.eclipse.jetty.rewrite.handler.ValidUrlRule"/>
  </Arg>
</Call>

Analysis

Prior to 9.4.37, Jetty was protected from this style of attack by two lines of defense: + URIs were decoded first and then normalized for . and .. sequences. Whilst this is not according to the RFC, it did remove relative segments that were encoded or parameterized and made the resulting URI paths safe from any repeated normalization (often done by URI manipulation and file system mapping). + The FileResource class treated any difference between absolute path and canonical path of a resource as an alias, and thus the resource would not be served by default.

Prior to 9.4.37, the FileResource class was replaced by the PathResource class that did not treat normalization differences as aliases. Then release 9.4.37 updated the URI parsing to be compliant with the RFC, in that normalization is done before decoding. This allowed various encodings or adornments to relative path segments that would not be normalized by the pure RFC URI normalization, but were normalized by the file system, thus allowing protected resources to be accessed via an alias. Specifically by decoding URIs after normalization, it left them vulnerable to any subsequent normalization (potentially after checking security constraints) changing the URI singificantly. Such extra normalization is often down by URI manipulation code and file systems.

With Jetty releases 9.4.43, 10.0.6, 11.0.6, we have restored several lines of defense: + URIs are first decoded and then normalized which is not strictly according to the current RFC. Since the normalization is done after decoding, the URI paths produced are safe from further normalisation and the referenced resource cannot easily be so changed after passing security constraints. + During URI parsing checks are made for some specific segments/characters that are possible to be seen ambiguously by an application (e.g. encode dot segments, encoded separators, empty segments, parameterized dot segments and/or null characters). So even though Jetty code handles these URIs correctly, there is a risk that an application may not do so, thus such requests are rejected with a 400 Bad Request unless a specific compliance mode is set. + Once decoded and normalized by initial URI processing, Jetty will not decode or normalize a received URI again within its own resource handling. This avoids to possibility of double decode attacks. + The ContextHandler.getResource(String path) method always checks that the passed path is normalized, only accepting a non normal path if approved by an AliasChecker. This is the method that is directly used by Jetty resource serving. + The API methods like ServletContext.getResource(String path) will normalize the prior to calling ContextHandler.getResource(String path). This allows applications to use non normal paths. + The PathResource class now considers any difference in normal/canonical name between a request resource name and the found resource name to be an alias, which will only be served if approved by an explicit AliasChecker

In summary, the defense is a front line of detection of specific known URI alias attacks, with the last line defense of not allowing any aliasing of resources.

Many thanks to @cangqingzhe from @CloverSecLabs for reporting this issue.

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": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty:jetty-webapp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.4.37"
            },
            {
              "fixed": "9.4.43"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty:jetty-webapp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.1"
            },
            {
              "fixed": "10.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty:jetty-webapp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.1"
            },
            {
              "fixed": "11.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-34429"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-551",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-07-15T21:33:21Z",
    "nvd_published_at": "2021-07-15T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Description\nURIs can be crafted using some encoded characters to access the content of the `WEB-INF` directory and/or bypass some security constraints.\nThis is a variation of the vulnerability reported in [CVE-2021-28164](https://nvd.nist.gov/vuln/detail/CVE-2021-28164)/[GHSA-v7ff-8wcx-gmc5](https://github.com/eclipse/jetty.project/security/advisories/GHSA-v7ff-8wcx-gmc5).\n\n### Impact\nThe default compliance mode allows requests with URIs that contain a %u002e segment to access protected resources within the WEB-INF directory. For example, a request to `/%u002e/WEB-INF/web.xml` can retrieve the web.xml file. This can reveal sensitive information regarding the implementation of a web application.  Similarly, an encoded null character can prevent correct normalization so that /.%00/WEB-INF/web.xml cal also retrieve the web.xml file.\n\n### Workarounds\nSome Jetty [rewrite rules](https://www.eclipse.org/jetty/documentation/jetty-9/index.html#rewrite-handler) can be deployed to rewrite any request containing encoded dot segments or null characters in the raw request URI, to a known not found resource:\n```xml\n\u003cCall name=\"addRule\"\u003e\n  \u003cArg\u003e\n    \u003cNew class=\"org.eclipse.jetty.rewrite.handler.RewriteRegexRule\"\u003e\n      \u003cSet name=\"regex\"\u003e.*/(?:\\.+/)+.*\u003c/Set\u003e\n      \u003cSet name=\"replacement\"\u003e/WEB-INF/Not-Found\u003c/Set\u003e\n    \u003c/New\u003e\n  \u003c/Arg\u003e\n\u003c/Call\u003e\n\u003cCall name=\"addRule\"\u003e\n  \u003cArg\u003e\n    \u003cNew class=\"org.eclipse.jetty.rewrite.handler.ValidUrlRule\"/\u003e\n  \u003c/Arg\u003e\n\u003c/Call\u003e\n```\n\n### Analysis\nPrior to 9.4.37, Jetty was protected from this style of attack by two lines of defense:\n + URIs were decoded first and then normalized for `.` and `..` sequences. Whilst this is not according to the RFC, it did remove relative segments that were encoded or parameterized and made the resulting URI paths safe from any repeated normalization (often done by URI manipulation and file system mapping).\n + The `FileResource` class treated any difference between absolute path and canonical path of a resource as an alias, and thus the resource would not be served by default.\n\nPrior to 9.4.37, the `FileResource` class was replaced by the `PathResource` class that did not treat normalization differences as aliases.  Then release 9.4.37 updated the URI parsing to be compliant with the RFC, in that normalization is done before decoding.   This allowed various encodings or adornments to relative path segments that would not be normalized by the pure RFC URI normalization, but were normalized by the file system, thus allowing protected resources to be accessed via an alias.  Specifically by decoding URIs after normalization, it left them vulnerable to any subsequent normalization (potentially after checking security constraints) changing the URI singificantly.  Such extra normalization is often down by URI manipulation code and file systems.\n\nWith Jetty releases 9.4.43, 10.0.6, 11.0.6, we have restored several lines of defense:\n + URIs are first decoded and then normalized which is not strictly according to the current RFC.  Since the normalization is done after decoding, the URI paths produced are safe from further normalisation and the referenced resource cannot easily be so changed after passing security constraints.\n + During URI parsing checks are made for some specific segments/characters that are possible to be seen ambiguously by an application (e.g. encode dot segments, encoded separators, empty segments, parameterized dot segments and/or null characters). So even though Jetty code handles these URIs correctly, there is a risk that an application may not do so, thus such requests are rejected with a 400 Bad Request unless a specific compliance mode is set.\n + Once decoded and normalized by initial URI processing, Jetty will not decode or normalize a received URI again within its own resource handling. This avoids to possibility of double decode attacks.\n + The `ContextHandler.getResource(String path)` method always checks that the passed path is normalized, only accepting a non normal path if approved by an AliasChecker.  This is the method that is directly used by Jetty resource serving.\n + The API methods like `ServletContext.getResource(String path)` will normalize the  prior to calling `ContextHandler.getResource(String path)`. This allows applications to use non normal paths.\n + The `PathResource` class now considers any difference in normal/canonical name between a request resource name and the found resource name  to be an alias, which will only be served if approved by an explicit `AliasChecker`\n\nIn summary, the defense is a front line of detection of specific known URI alias attacks, with the last line defense of not allowing any aliasing of resources.\n\nMany thanks to @cangqingzhe from @CloverSecLabs for reporting this issue. ",
  "id": "GHSA-vjv5-gp2w-65vm",
  "modified": "2022-04-19T15:15:34Z",
  "published": "2021-07-19T15:15:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/eclipse/jetty.project/security/advisories/GHSA-vjv5-gp2w-65vm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34429"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r763840320a80e515331cbc1e613fa93f25faf62e991974171a325c82@%3Cdev.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r7dd079fa0ac6f47ba1ad0af98d7d0276547b8a4e005f034fb1016951@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r833a4c8bdbbfeb8a2cd38238e7b59f83edd5c1a0e508b587fc551a46@%3Cissues.hbase.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r8e6c116628c1277c3cf132012a66c46a0863fa2a3037c0707d4640d4@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r90e7b4c42a96d74c219e448bee6a329ab0cd3205c44b63471d96c3ab@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9d245c6c884bbc804a472116d730c1a01676bf24f93206a34923fc64@%3Ccommits.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9e6158d72ef25077c2dc59fbddade2eacf7d259a2556c97a989f2fe8@%3Ccommits.pulsar.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rb33d65c3e5686f2e3b9bb8a032a44163b2f2ad9d31a8727338f213c1@%3Ccommits.pulsar.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rc26807be68748b3347decdcd03ae183622244b0b4cb09223d4b7e500@%3Ccommits.pulsar.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rcb157f55b9ae41b3076801de927c6fca1669c6d8eaf11a9df5dbeb46@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rcea249eb7a0d243f21696e4985de33f3780399bf7b31ea1f6d489b8b@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re01890eef49d4201018f2c97e26536e3e75f441ecdbcf91986c3bc17@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re3de01414ccf682fe0951205f806dd8e94440798fd64c55a4941de3e@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re5e9bb535db779506013ef8799dc2a299e77cdad6668aa94c456dba6@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re850203ef8700cb826534dd4a1cb9f5b07bb8f6f973b39ff7838d3ba@%3Cissues.hbase.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210819-0006"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2022.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/eclipse/jetty.project"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclipse/jetty.project/releases/tag/jetty-9.4.43.v20210629"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r029c0c6833c8bb6acb094733fd7b75029d633f47a92f1c9d14391fc0@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r02f940c27e997a277ff14e79e84551382e1081e8978b417e0c2b0857@%3Ccommits.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r0626f279ebf65506110a897e3a57ccd4072803ee5434b2503e070398@%3Ccommits.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r2a3ea27cca2ac7352d392b023b72e824387bc9ff16ba245ec663bdc6@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r2e32390cb7aedb39069e5b18aa130ca53e766258518faee63c31d3ea@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r3aefe613abce594c71ace50088d2529bbde65d08b8e7ff2c2723aaa1@%3Cdev.santuario.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r3c55b0baa4dc38958ae147b2f216e212605f1071297f845e14477d36@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r44ea39ca8110de7353bfec88f58aa3aa58a42bb324b8772512ee190c@%3Ccommits.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r46900f74dbb7d168aeac43bf0e7f64825376bb7eb74d31a5b33344ce@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r46f748c1dc9cf9b6c1c18f6b5bfc3a869907f68f72e17666f2f30f24@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r4727d282b5c2d951057845a46065d59f6e33132edc0a14f41c26b01e@%3Cdev.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r48a93f2bc025acd7c7e341ed3864bfdeb75f0c768d41bc247e1a1f63@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5678d994d4dd8e7c838eed3bbc1a83a7f6bc62724b0cce67e8892a45@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r679d96f981d4c92724090ed2d5e8565a1d655a72bb315550489f052e@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r6e6f50c1ce1fb592cb43e913f5be23df104d50751465f8f1952ace0c@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r721ab6a5fa8d45bec76714b674f5d4caed2ebfeca69ad1d6d4caae6c@%3Cdev.hbase.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r74fdc446df551fe89a0a16957a1bfdaad19380e0c1afd30625685a9c@%3Cjira.kafka.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r756443e9d50af7e8c3df82e2c45105f452c8e8195ddbc0c00f58d5fe@%3Ccommits.kafka.apache.org%3E"
    }
  ],
  "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"
    }
  ],
  "summary": "Encoded URIs can access WEB-INF directory in Eclipse Jetty"
}

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"
    }
  ]
}
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