Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

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.

5537 vulnerabilities reference this CWE, most recent first.

GHSA-W67P-2W4G-FGJP

Vulnerability from github – Published: 2022-05-24 17:22 – Updated: 2022-05-24 17:22
VLAI
Details

The /rest/project-templates/1.0/createshared resource in Atlassian Jira Server and Data Center before version 8.5.5, from 8.6.0 before 8.7.2, and from 8.8.0 before 8.8.1 allows remote attackers to enumerate project names via an improper authorization vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-4029"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-07-01T02:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The /rest/project-templates/1.0/createshared resource in Atlassian Jira Server and Data Center before version 8.5.5, from 8.6.0 before 8.7.2, and from 8.8.0 before 8.8.1 allows remote attackers to enumerate project names via an improper authorization vulnerability.",
  "id": "GHSA-w67p-2w4g-fgjp",
  "modified": "2022-05-24T17:22:14Z",
  "published": "2022-05-24T17:22:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-4029"
    },
    {
      "type": "WEB",
      "url": "https://jira.atlassian.com/browse/JRASERVER-70926"
    }
  ],
  "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-W68R-5P45-5RQP

Vulnerability from github – Published: 2021-05-06 18:54 – Updated: 2021-05-04 22:46
VLAI
Summary
Improper Input Validation in Laravel
Details

An issue was discovered in Laravel before 6.18.35 and 7.x before 7.24.0. The $guarded property is mishandled in some situations involving requests with JSON column nesting expressions.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "laravel/framework"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.18.35"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "laravel/framework"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.24.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-24941"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-04T22:46:50Z",
    "nvd_published_at": "2020-09-04T02:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Laravel before 6.18.35 and 7.x before 7.24.0. The $guarded property is mishandled in some situations involving requests with JSON column nesting expressions.",
  "id": "GHSA-w68r-5p45-5rqp",
  "modified": "2021-05-04T22:46:50Z",
  "published": "2021-05-06T18:54:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24941"
    },
    {
      "type": "WEB",
      "url": "https://github.com/laravel/framework/commit/897d107775737a958dbd0b2f3ea37877c7526371"
    },
    {
      "type": "WEB",
      "url": "https://blog.laravel.com/security-release-laravel-61835-7240"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Input Validation in Laravel"
}

GHSA-W6C7-J32F-RQ8J

Vulnerability from github – Published: 2025-05-13 09:31 – Updated: 2025-07-16 21:02
VLAI
Summary
Apache Superset Allows Ownership Takeover
Details

Improper Authorization vulnerability in Apache Superset allows ownership takeover of dashboards, charts or datasets by authenticated users with read permissions.

This issue affects Apache Superset: through 4.1.1.

Users are recommended to upgrade to version 4.1.2 or above, which fixes the issue.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "apache-superset"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-27696"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-13T20:23:45Z",
    "nvd_published_at": "2025-05-13T09:15:20Z",
    "severity": "MODERATE"
  },
  "details": "Improper Authorization vulnerability in Apache Superset allows ownership takeover of dashboards, charts or datasets by authenticated users with read permissions.\n\nThis issue affects Apache Superset: through 4.1.1.\n\nUsers are recommended to upgrade to version 4.1.2 or above, which fixes the issue.",
  "id": "GHSA-w6c7-j32f-rq8j",
  "modified": "2025-07-16T21:02:59Z",
  "published": "2025-05-13T09:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27696"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/superset/commit/fc844d3dfdace890b32c00a507a959b81122b425"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/superset"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/k2od03bxnxs6vcp80sr03ywcxl194413"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/05/12/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Superset Allows Ownership Takeover"
}

GHSA-W6F2-8WX4-47R5

Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2022-06-22 18:13
VLAI
Summary
Incorrect Authorization in MySQL Connector Java
Details

Vulnerability in the MySQL Connectors product of Oracle MySQL (component: Connector/J). Supported versions that are affected are 8.0.26 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Connectors. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all MySQL Connectors accessible data and unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Connectors. CVSS 3.1 Base Score 5.9 (Confidentiality and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:H).

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 8.0.26"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "mysql:mysql-connector-java"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.27"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-2471"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-22T18:13:52Z",
    "nvd_published_at": "2021-10-20T11:16:00Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the MySQL Connectors product of Oracle MySQL (component: Connector/J). Supported versions that are affected are 8.0.26 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Connectors. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all MySQL Connectors accessible data and unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Connectors. CVSS 3.1 Base Score 5.9 (Confidentiality and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:H).",
  "id": "GHSA-w6f2-8wx4-47r5",
  "modified": "2022-06-22T18:13:52Z",
  "published": "2022-05-24T19:18:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-2471"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Incorrect Authorization in MySQL Connector Java"
}

GHSA-W6F7-PJ3M-833J

Vulnerability from github – Published: 2026-07-06 21:30 – Updated: 2026-07-08 12:30
VLAI
Details

Improper enforcement of a mandatory multi-factor authentication policy in Devolutions Server 2026.2.9.0 allows an attacker with valid user credentials to bypass the MFA Required policy and authenticate without completing multi-factor authentication. The problem occurs when DVLS encounters an invalid default MFA value.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-14536"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-06T20:16:29Z",
    "severity": "HIGH"
  },
  "details": "Improper enforcement of a mandatory multi-factor authentication policy in Devolutions Server 2026.2.9.0 allows an attacker with valid user credentials to bypass the MFA Required policy and authenticate without completing multi-factor authentication. The problem occurs when DVLS encounters an invalid default MFA value.",
  "id": "GHSA-w6f7-pj3m-833j",
  "modified": "2026-07-08T12:30:24Z",
  "published": "2026-07-06T21:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14536"
    },
    {
      "type": "WEB",
      "url": "https://devolutions.net/security/advisories/DEVO-2026-0023"
    }
  ],
  "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"
    }
  ]
}

GHSA-W6FV-6GCC-X825

Vulnerability from github – Published: 2025-03-17 14:46 – Updated: 2025-03-19 15:00
VLAI
Summary
Zincati allows unprivileged access to rpm-ostree D-Bus `Deploy()` and `FinalizeDeployment()` methods
Details

Impact

Zincati ships a polkit rule which allows the zincati system user to use the following actions: - org.projectatomic.rpmostree1.deploy: used to deploy updates to the system - org.projectatomic.rpmostree1.finalize-deployment: used to reboot the system into the deployed update

Since Zincati v0.0.24, this polkit rule contains a logic error which broadens access of those polkit actions to any unprivileged user rather than just the zincati system user.

In practice, this means that any unprivileged user with access to the system D-Bus socket is able to deploy older Fedora CoreOS versions (which may have other known vulnerabilities). Note that rpm-ostree enforces that the selected version must be from the same branch the system is currently on so this cannot directly be used to deploy an attacker-controlled update payload.

This primarily impacts users running untrusted workloads with access to the system D-Bus socket. Note that in general, untrusted workloads should not be given this access, whether containerized or not. By default, containers do not have access to the system D-Bus socket.

Patches

The logic error is fixed in Zincati v0.0.30. The fix is included in the following FCOS releases: - On the stable stream: 41.20250302.3.2 - On the testing stream: 41.20250315.2.0 - On the next stream: 42.20250316.1.0

Workarounds

A workaround is to add the following polkit rule:

polkit.addRule(function(action, subject) {
    if (action.id == "org.projectatomic.rpmostree1.deploy" ||
        action.id == "org.projectatomic.rpmostree1.finalize-deployment" ||
        action.id == "org.projectatomic.rpmostree1.cleanup") {
        if (subject.user != "zincati") {
                return polkit.Result.NO;
        }
    }
});

to e.g. /etc/polkit-1/rules.d/00-zincati-fix.rules (it must sort earlier than zincati.rules lexicographically).

Note that this rule will deny all non-root users other than zincati from using those actions. If you've added polkit rules to allow e.g. the core user or other users, you will need to adjust the policy (or make sure the ordering is appropriate).

References

This issue was introduced by this commit, and is fixed in v0.0.30.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.0.29"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "zincati"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.24"
            },
            {
              "fixed": "0.0.30"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-27512"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-783",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-17T14:46:56Z",
    "nvd_published_at": "2025-03-17T15:15:44Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\nZincati ships a polkit rule which allows the `zincati` system user to use the following actions:\n- `org.projectatomic.rpmostree1.deploy`: used to deploy updates to the system\n- `org.projectatomic.rpmostree1.finalize-deployment`: used to reboot the system into the deployed update\n\nSince Zincati [v0.0.24](https://github.com/coreos/zincati/releases/tag/v0.0.24), this polkit rule contains a logic error which broadens access of those polkit actions to any unprivileged user rather than just the `zincati` system user.\n\nIn practice, this means that any unprivileged user with access to the system D-Bus socket is able to deploy older Fedora CoreOS versions (which may have other known vulnerabilities). Note that rpm-ostree enforces that the selected version must be from the same branch the system is currently on so this cannot directly be used to deploy an attacker-controlled update payload.\n\nThis primarily impacts users running untrusted workloads with access to the system D-Bus socket. Note that in general, untrusted workloads should not be given this access, whether containerized or not. By default, containers do not have access to the system D-Bus socket.\n\n### Patches\n\nThe logic error is fixed in Zincati v0.0.30. The fix is included in the following FCOS releases:\n- On the `stable` stream: 41.20250302.3.2\n- On the `testing` stream: 41.20250315.2.0\n- On the `next` stream: 42.20250316.1.0\n\n### Workarounds\n\nA workaround is to add the following polkit rule:\n\n```javascript\npolkit.addRule(function(action, subject) {\n    if (action.id == \"org.projectatomic.rpmostree1.deploy\" ||\n        action.id == \"org.projectatomic.rpmostree1.finalize-deployment\" ||\n        action.id == \"org.projectatomic.rpmostree1.cleanup\") {\n        if (subject.user != \"zincati\") {\n                return polkit.Result.NO;\n        }\n    }\n});\n```\n\nto e.g. `/etc/polkit-1/rules.d/00-zincati-fix.rules` (it must sort earlier than `zincati.rules` lexicographically).\n\nNote that this rule will deny all non-root users other than `zincati` from using those actions. If you\u0027ve added polkit rules to allow e.g. the `core` user or other users, you will need to adjust the policy (or make sure the ordering is appropriate).\n\n### References\n\nThis issue was introduced by [this commit](https://github.com/coreos/zincati/commit/28a43aa2c1edda091ba659677d73c13e6e3ea99d), and is fixed in [v0.0.30](https://github.com/coreos/zincati/releases/tag/v0.0.30).",
  "id": "GHSA-w6fv-6gcc-x825",
  "modified": "2025-03-19T15:00:20Z",
  "published": "2025-03-17T14:46:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/coreos/zincati/security/advisories/GHSA-w6fv-6gcc-x825"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27512"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coreos/zincati/commit/01d8e89f799e6ba21bdf7dc668abce23bd0d8f78"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coreos/zincati/commit/28a43aa2c1edda091ba659677d73c13e6e3ea99d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/coreos/zincati"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coreos/zincati/releases/tag/v0.0.24"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coreos/zincati/releases/tag/v0.0.30"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Zincati allows unprivileged access to rpm-ostree D-Bus `Deploy()` and `FinalizeDeployment()` methods"
}

GHSA-W6H2-FR4Q-XVXV

Vulnerability from github – Published: 2026-06-18 13:55 – Updated: 2026-06-18 13:55
VLAI
Summary
PraisonAI: Compute-bridged file tools allow shell command injection
Details

Compute-bridged file tools allow shell command injection

Summary

LocalManagedAgent / SandboxedAgent compute bridging wraps read_file, list_files, and write_file when a compute provider is attached. The bridge converts those file operations into shell command strings using raw path arguments, then sends those strings to shell-backed compute providers.

An attacker who can influence a file-tool path argument can break out of the quoted path and execute arbitrary shell commands in the compute environment. With compute="local", commands execute through the local subprocess compute provider on the host. With Docker, commands execute in the container.

Affected Product

  • Repository: MervinPraison/PraisonAI
  • Package: praisonai
  • Component: src/praisonai/praisonai/integrations/managed_local.py
  • Confirmed affected:
  • v4.6.10
  • v4.6.56
  • v4.6.57
  • current main at 2f9677abb2ea68eab864ee8b6a828fd0141612e1
  • Confirmed not affected:
  • v4.6.9
  • v4.6.1
  • v4.5.149
  • Suggested affected range: >= 4.6.10, <= 4.6.57

Root Cause

Current managed_local.py defines the bridged tool set:

compute_bridged_tools = {"execute_command", "read_file", "write_file", "list_files"}

For file tools, _bridge_file_tool() constructs shell command strings:

command = f'cat "{filepath}"'
command = f'ls -la "{directory}"'
command = f'cat > "{filepath}" << "EOF"\n{content}\nEOF'

The local compute provider executes the string with asyncio.create_subprocess_shell(...); the Docker compute provider executes it with ["sh", "-c", command].

The bridge keeps the low-risk read_file / list_files tool names and signatures while changing their execution primitive into shell interpretation.

Why This Is Not Intended Behavior

Compute bridging itself is documented and intentional. The vulnerability is that file path data is interpreted as shell syntax.

The normal read_file and list_files implementations treat the same payload as a literal path and do not expand shell metacharacters. The approval registry also marks execute_command as critical, while read_file and list_files are not dangerous-tool entries.

Impact

An application that exposes a PraisonAI agent using LocalManagedAgent or SandboxedAgent with a compute provider and a restricted file-tool set can be tricked into executing shell commands through a path argument to read_file or list_files.

This can bypass least-privilege tool configuration and tool-approval expectations. A prompt-injection path, chat endpoint, automation webhook, or other user-controlled agent task can supply the file path argument without the operator granting execute_command.

Local PoV

The PoV is local-only and harmless. It uses an environment canary and compares normal file tools against compute-bridged file tools.

Minimal inline reproducer:

import os
from pathlib import Path

from praisonai.integrations.managed_local import LocalManagedAgent, LocalManagedConfig
from praisonaiagents.tools import list_files, read_file

workdir = Path(".prai-cand-006-pov-workdir")
workdir.mkdir(exist_ok=True)
(workdir / "safe.txt").write_text("SAFE_CONTENT\n", encoding="utf-8")

canary = "PRAISONAI_CAND_006_COMMAND_EXECUTED"
os.environ["PRAI_CAND_006_CANARY"] = canary
payload = 'missing"; printf "$PRAI_CAND_006_CANARY"; #'

# Control: normal file tools treat the payload as a literal path.
normal_read = read_file(str(workdir / payload))
normal_list = str(list_files(str(workdir) + '"; printf "$PRAI_CAND_006_CANARY"; #'))

cfg = LocalManagedConfig(
    name="prai-cand-006-poc",
    tools=["read_file", "list_files"],
    working_dir=str(workdir),
)
managed = LocalManagedAgent(config=cfg, compute="local")
tools = {tool.__name__: tool for tool in managed._resolve_tools()}

bridged_read = tools["read_file"](payload)
bridged_list = tools["list_files"]('."; printf "$PRAI_CAND_006_CANARY"; #')

print("normal_read_contains_canary", canary in normal_read)
print("normal_list_contains_canary", canary in normal_list)
print("bridged_read_contains_canary", canary in bridged_read)
print("bridged_list_contains_canary", canary in bridged_list)

Command:

python3 \
  submission-bundle/praisonai-prai-cand-006-compute-file-tool-command-injection/poc/prai_cand_006_compute_file_tool_command_injection.py \
  --repo artifacts/repos/praisonai-current

Current-head result:

{
  "describe": "v4.6.57-4-g2f9677ab",
  "vulnerable": true,
  "normal_controls": {
    "read_file_payload_contains_canary": false,
    "list_files_payload_contains_canary": false
  },
  "bridged_results": {
    "read_file_payload_contains_canary": true,
    "list_files_payload_contains_canary": true
  },
  "approval_registry": {
    "execute_command_risk": "critical",
    "read_file_risk": null,
    "list_files_risk": null
  }
}

The payload used by the PoV is:

missing"; printf "$PRAI_CAND_006_CANARY"; #

Normal read_file treats this as a literal missing filename. The bridged tool constructs:

cat "missing"; printf "$PRAI_CAND_006_CANARY"; #"

and returns the canary from the compute shell.

Suggested Fix

Do not implement file operations by constructing shell command strings from path/content arguments.

Preferred fix:

  1. Add provider-native file APIs for read, write, and list operations, or pass arguments as structured argv where the provider supports it.
  2. Preserve the normal file-tool path validation and workspace boundary checks for compute-bridged file tools.
  3. Treat write_file content as data, not shell source. The current heredoc construction is also unsafe if content can contain the delimiter.
  4. Add regression tests that use paths containing ", ;, $(), backticks, newline, and # and assert no shell execution occurs.
  5. Keep execute_command as the only bridge path that intentionally accepts a shell command string, with critical approval semantics.

A minimal stopgap is to remove read_file, list_files, and write_file from compute_bridged_tools until safe provider-native file operations exist.

Suggested Severity

The vector assumes an attacker has low-privilege access to an agent interface that can request file-tool use. If a deployment exposes such an agent without authentication, PR:N may be appropriate.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.6.58"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.6.10"
            },
            {
              "fixed": "4.6.59"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-78",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T13:55:08Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "# Compute-bridged file tools allow shell command injection\n\n## Summary\n\n`LocalManagedAgent` / `SandboxedAgent` compute bridging wraps\n`read_file`, `list_files`, and `write_file` when a compute provider is\nattached. The bridge converts those file operations into shell command strings\nusing raw path arguments, then sends those strings to shell-backed compute\nproviders.\n\nAn attacker who can influence a file-tool path argument can break out of the\nquoted path and execute arbitrary shell commands in the compute environment.\nWith `compute=\"local\"`, commands execute through the local subprocess compute\nprovider on the host. With Docker, commands execute in the container.\n\n## Affected Product\n\n- Repository: `MervinPraison/PraisonAI`\n- Package: `praisonai`\n- Component: `src/praisonai/praisonai/integrations/managed_local.py`\n- Confirmed affected:\n  - `v4.6.10`\n  - `v4.6.56`\n  - `v4.6.57`\n  - current `main` at `2f9677abb2ea68eab864ee8b6a828fd0141612e1`\n- Confirmed not affected:\n  - `v4.6.9`\n  - `v4.6.1`\n  - `v4.5.149`\n- Suggested affected range: `\u003e= 4.6.10, \u003c= 4.6.57`\n\n## Root Cause\n\nCurrent `managed_local.py` defines the bridged tool set:\n\n```python\ncompute_bridged_tools = {\"execute_command\", \"read_file\", \"write_file\", \"list_files\"}\n```\n\nFor file tools, `_bridge_file_tool()` constructs shell command strings:\n\n```python\ncommand = f\u0027cat \"{filepath}\"\u0027\ncommand = f\u0027ls -la \"{directory}\"\u0027\ncommand = f\u0027cat \u003e \"{filepath}\" \u003c\u003c \"EOF\"\\n{content}\\nEOF\u0027\n```\n\nThe local compute provider executes the string with\n`asyncio.create_subprocess_shell(...)`; the Docker compute provider executes it\nwith `[\"sh\", \"-c\", command]`.\n\nThe bridge keeps the low-risk `read_file` / `list_files` tool names and\nsignatures while changing their execution primitive into shell interpretation.\n\n## Why This Is Not Intended Behavior\n\nCompute bridging itself is documented and intentional. The vulnerability is\nthat file path data is interpreted as shell syntax.\n\nThe normal `read_file` and `list_files` implementations treat the same payload\nas a literal path and do not expand shell metacharacters. The approval registry\nalso marks `execute_command` as `critical`, while `read_file` and `list_files`\nare not dangerous-tool entries.\n\n## Impact\n\nAn application that exposes a PraisonAI agent using `LocalManagedAgent` or\n`SandboxedAgent` with a compute provider and a restricted file-tool set can be\ntricked into executing shell commands through a path argument to `read_file` or\n`list_files`.\n\nThis can bypass least-privilege tool configuration and tool-approval\nexpectations. A prompt-injection path, chat endpoint, automation webhook, or\nother user-controlled agent task can supply the file path argument without the\noperator granting `execute_command`.\n\n## Local PoV\n\nThe PoV is local-only and harmless. It uses an environment canary and compares\nnormal file tools against compute-bridged file tools.\n\nMinimal inline reproducer:\n\n```python\nimport os\nfrom pathlib import Path\n\nfrom praisonai.integrations.managed_local import LocalManagedAgent, LocalManagedConfig\nfrom praisonaiagents.tools import list_files, read_file\n\nworkdir = Path(\".prai-cand-006-pov-workdir\")\nworkdir.mkdir(exist_ok=True)\n(workdir / \"safe.txt\").write_text(\"SAFE_CONTENT\\n\", encoding=\"utf-8\")\n\ncanary = \"PRAISONAI_CAND_006_COMMAND_EXECUTED\"\nos.environ[\"PRAI_CAND_006_CANARY\"] = canary\npayload = \u0027missing\"; printf \"$PRAI_CAND_006_CANARY\"; #\u0027\n\n# Control: normal file tools treat the payload as a literal path.\nnormal_read = read_file(str(workdir / payload))\nnormal_list = str(list_files(str(workdir) + \u0027\"; printf \"$PRAI_CAND_006_CANARY\"; #\u0027))\n\ncfg = LocalManagedConfig(\n    name=\"prai-cand-006-poc\",\n    tools=[\"read_file\", \"list_files\"],\n    working_dir=str(workdir),\n)\nmanaged = LocalManagedAgent(config=cfg, compute=\"local\")\ntools = {tool.__name__: tool for tool in managed._resolve_tools()}\n\nbridged_read = tools[\"read_file\"](payload)\nbridged_list = tools[\"list_files\"](\u0027.\"; printf \"$PRAI_CAND_006_CANARY\"; #\u0027)\n\nprint(\"normal_read_contains_canary\", canary in normal_read)\nprint(\"normal_list_contains_canary\", canary in normal_list)\nprint(\"bridged_read_contains_canary\", canary in bridged_read)\nprint(\"bridged_list_contains_canary\", canary in bridged_list)\n```\n\nCommand:\n\n```bash\npython3 \\\n  submission-bundle/praisonai-prai-cand-006-compute-file-tool-command-injection/poc/prai_cand_006_compute_file_tool_command_injection.py \\\n  --repo artifacts/repos/praisonai-current\n```\n\nCurrent-head result:\n\n```json\n{\n  \"describe\": \"v4.6.57-4-g2f9677ab\",\n  \"vulnerable\": true,\n  \"normal_controls\": {\n    \"read_file_payload_contains_canary\": false,\n    \"list_files_payload_contains_canary\": false\n  },\n  \"bridged_results\": {\n    \"read_file_payload_contains_canary\": true,\n    \"list_files_payload_contains_canary\": true\n  },\n  \"approval_registry\": {\n    \"execute_command_risk\": \"critical\",\n    \"read_file_risk\": null,\n    \"list_files_risk\": null\n  }\n}\n```\n\nThe payload used by the PoV is:\n\n```text\nmissing\"; printf \"$PRAI_CAND_006_CANARY\"; #\n```\n\nNormal `read_file` treats this as a literal missing filename. The bridged tool\nconstructs:\n\n```sh\ncat \"missing\"; printf \"$PRAI_CAND_006_CANARY\"; #\"\n```\n\nand returns the canary from the compute shell.\n\n## Suggested Fix\n\nDo not implement file operations by constructing shell command strings from\npath/content arguments.\n\nPreferred fix:\n\n1. Add provider-native file APIs for read, write, and list operations, or pass\n   arguments as structured argv where the provider supports it.\n2. Preserve the normal file-tool path validation and workspace boundary checks\n   for compute-bridged file tools.\n3. Treat `write_file` content as data, not shell source. The current heredoc\n   construction is also unsafe if content can contain the delimiter.\n4. Add regression tests that use paths containing `\"`, `;`, `$()`, backticks,\n   newline, and `#` and assert no shell execution occurs.\n5. Keep `execute_command` as the only bridge path that intentionally accepts a\n   shell command string, with critical approval semantics.\n\nA minimal stopgap is to remove `read_file`, `list_files`, and `write_file` from\n`compute_bridged_tools` until safe provider-native file operations exist.\n\n## Suggested Severity\n\nThe vector assumes an attacker has low-privilege access to an agent interface\nthat can request file-tool use. If a deployment exposes such an agent without\nauthentication, `PR:N` may be appropriate.",
  "id": "GHSA-w6h2-fr4q-xvxv",
  "modified": "2026-06-18T13:55:08Z",
  "published": "2026-06-18T13:55:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-w6h2-fr4q-xvxv"
    },
    {
      "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": "PraisonAI: Compute-bridged file tools allow shell command injection"
}

GHSA-W6R8-H4CF-GR7J

Vulnerability from github – Published: 2022-05-01 07:40 – Updated: 2024-01-25 03:30
VLAI
Details

Pedro Lineu Orso chetcpasswd before 2.4 relies on the X-Forwarded-For HTTP header when verifying a client's status on an IP address ACL, which allows remote attackers to gain unauthorized access by spoofing this header.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2006-6679"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2006-12-21T19:28:00Z",
    "severity": "HIGH"
  },
  "details": "Pedro Lineu Orso chetcpasswd before 2.4 relies on the X-Forwarded-For HTTP header when verifying a client\u0027s status on an IP address ACL, which allows remote attackers to gain unauthorized access by spoofing this header.",
  "id": "GHSA-w6r8-h4cf-gr7j",
  "modified": "2024-01-25T03:30:57Z",
  "published": "2022-05-01T07:40:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2006-6679"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/30451"
    },
    {
      "type": "WEB",
      "url": "http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394454"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=116371297325564\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22967"
    },
    {
      "type": "WEB",
      "url": "http://sourceforge.net/project/shownotes.php?group_id=68912\u0026release_id=466649"
    },
    {
      "type": "WEB",
      "url": "http://www.osvdb.org/30544"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/21102"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W6WX-JQ6J-6MCJ

Vulnerability from github – Published: 2026-04-07 18:15 – Updated: 2026-04-07 18:15
VLAI
Summary
OpenClaw: pnpm dlx approvals did not bind local script operands
Details

Summary

Before OpenClaw 2026.4.2, pnpm dlx approval planning did not bind local script operands the same way as related pnpm exec flows. A local script approved through a pnpm dlx path could be replaced before execution without invalidating the approval.

Impact

An operator could approve a benign local script and then execute modified script contents through the still-valid approval plan. This was an approval-integrity bug in the node-host command-planning path.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected versions: <= 2026.4.1
  • Patched versions: >= 2026.4.2
  • Latest published npm version: 2026.4.1

Fix Commit(s)

  • 176c059b05357df1bc09d4328a2380670859eeff — bind local scripts in pnpm dlx approval plans

Release Process Note

The fix is present on main and is staged for OpenClaw 2026.4.2. Publish this advisory after the 2026.4.2 npm release is live.

Thanks @Kazamayc for reporting.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.4.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-07T18:15:52Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nBefore OpenClaw 2026.4.2, `pnpm dlx` approval planning did not bind local script operands the same way as related `pnpm exec` flows. A local script approved through a `pnpm dlx` path could be replaced before execution without invalidating the approval.\n\n## Impact\n\nAn operator could approve a benign local script and then execute modified script contents through the still-valid approval plan. This was an approval-integrity bug in the node-host command-planning path.\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.4.1`\n- Patched versions: `\u003e= 2026.4.2`\n- Latest published npm version: `2026.4.1`\n\n## Fix Commit(s)\n\n- `176c059b05357df1bc09d4328a2380670859eeff` \u2014 bind local scripts in `pnpm dlx` approval plans\n\n## Release Process Note\n\nThe fix is present on `main` and is staged for OpenClaw `2026.4.2`. Publish this advisory after the `2026.4.2` npm release is live.\n\nThanks @Kazamayc for reporting.",
  "id": "GHSA-w6wx-jq6j-6mcj",
  "modified": "2026-04-07T18:15:52Z",
  "published": "2026-04-07T18:15:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-w6wx-jq6j-6mcj"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/176c059b05357df1bc09d4328a2380670859eeff"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: pnpm dlx approvals did not bind local script operands"
}

GHSA-W6XX-RR92-X6GV

Vulnerability from github – Published: 2023-06-27 21:30 – Updated: 2024-04-04 05:12
VLAI
Details

IBM Robotic Process Automation for Cloud Pak 21.0.1 through 21.0.7.3 and 23.0.0 through 23.0.3 is vulnerable to security misconfiguration of the Redis container which may provide elevated privileges. IBM X-Force ID: 244074.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-22593"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-27T19:15:09Z",
    "severity": "HIGH"
  },
  "details": "\nIBM Robotic Process Automation for Cloud Pak 21.0.1 through 21.0.7.3 and 23.0.0 through 23.0.3 is vulnerable to security misconfiguration of the Redis container which may provide elevated privileges.  IBM X-Force ID:  244074.\n\n",
  "id": "GHSA-w6xx-rr92-x6gv",
  "modified": "2024-04-04T05:12:57Z",
  "published": "2023-06-27T21:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22593"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/244074"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7006001"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "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.