CWE-863
Allowed-with-ReviewIncorrect 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.
5723 vulnerabilities reference this CWE, most recent first.
GHSA-GC72-8J9H-JJC3
Vulnerability from github – Published: 2025-07-15 21:31 – Updated: 2025-07-15 21:31Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Components Services). Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and 9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).
{
"affected": [],
"aliases": [
"CVE-2025-50086"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-15T20:15:44Z",
"severity": "MODERATE"
},
"details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Components Services). Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and 9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).",
"id": "GHSA-gc72-8j9h-jjc3",
"modified": "2025-07-15T21:31:41Z",
"published": "2025-07-15T21:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-50086"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2025.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GC8H-QJVM-5F2G
Vulnerability from github – Published: 2025-01-21 21:30 – Updated: 2025-11-03 21:32Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB). Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and 9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).
{
"affected": [],
"aliases": [
"CVE-2025-21555"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-21T21:15:22Z",
"severity": "MODERATE"
},
"details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB). Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and 9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).",
"id": "GHSA-gc8h-qjvm-5f2g",
"modified": "2025-11-03T21:32:21Z",
"published": "2025-01-21T21:30:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21555"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250131-0004"
},
{
"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:H/UI:N/S:U/C:N/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GC9F-RWQ2-6PG3
Vulnerability from github – Published: 2022-02-11 00:01 – Updated: 2022-07-13 00:00Improper access control in software for Intel(R) PROSet/Wireless Wi-Fi and Killer(TM) Wi-Fi in Windows 10 and 11 may allow a privileged user to potentially enable escalation of privilege via local access.
{
"affected": [],
"aliases": [
"CVE-2021-0167"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-09T23:15:00Z",
"severity": "MODERATE"
},
"details": "Improper access control in software for Intel(R) PROSet/Wireless Wi-Fi and Killer(TM) Wi-Fi in Windows 10 and 11 may allow a privileged user to potentially enable escalation of privilege via local access.",
"id": "GHSA-gc9f-rwq2-6pg3",
"modified": "2022-07-13T00:00:58Z",
"published": "2022-02-11T00:01:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0167"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00539.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GC9F-XMG3-M3PP
Vulnerability from github – Published: 2023-04-25 21:30 – Updated: 2024-04-04 03:41VMware Fusion contains a local privilege escalation vulnerability. A malicious actor with read/write access to the host operating system can elevate privileges to gain root access to the host operating system.
{
"affected": [],
"aliases": [
"CVE-2023-20871"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-25T21:15:10Z",
"severity": "HIGH"
},
"details": "VMware Fusion contains a local privilege escalation vulnerability. A malicious actor with read/write access to the host operating system can elevate privileges to gain root access to the host operating system.",
"id": "GHSA-gc9f-xmg3-m3pp",
"modified": "2024-04-04T03:41:11Z",
"published": "2023-04-25T21:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20871"
},
{
"type": "WEB",
"url": "https://www.vmware.com/security/advisories/VMSA-2023-0008.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GCCQ-H3XJ-JGVF
Vulnerability from github – Published: 2024-02-12 15:17 – Updated: 2024-10-11 21:35Summary
When processing requests authorization was improperly and insufficiently checked, allowing attackers to access far more functionality than users intended, including to the administrative and moderator functionality of the Pixelfed server.
This vulnerability affects every version of Pixelfed between v0.10.4 and v0.11.9, inclusive. A proof of concept of this vulnerability exists.
Details
In vulnerable versions of Pixelfed (versions before 0.11.11), when the API checked the request for permissions to perform a certain behavior, it did not check that the OAuth Application/Client had granted access to those API endpoints, it only checked if the user was authenticated via an access token, and if the user was the owner of the resource or an admin on the instance.
This meant that an attacker could request an access token for "read" permissions to authenticate you with their application, but the access token that they obtained actually could be used for "write" or even administrative actions, and the user who granted access to their account had zero knowledge of this elevated access.
Proof of Concept
- Create an access token either via 2-legged OAuth flow for the
readscope, or create a Personal Access Tokens with thereadscope. - Using that Access Token, perform a request that would need a particular higher-privilege scope, for instance, following a user or performing an administrative request. (respectively requiring
followoradmin:readandadmin:writescopes in the patched versions) - Observe that despite your access token having
readpermissions, the follow or administrative request was successful.
e.g., Maybe an attacker collects an access token (which expires in 1 year) wants to do something really nasty to an admin, such as disabling federation on their target's pixelfed server. As long as that server has instance.enable_cc configured (defaults to true), then the attacker can use the read scoped access token and perform the following request:
POST /api/admin/config/update
Content-Type: application/json
Accept: application/json
Authorization: Bearer <access token with read scope>
{ "key": "federation.activitypub.enabled": "value": false }
And federation of that pixelfed server would be subsequently disabled, as if the administrator had disabled it.
Impact
This vulnerability affects every local user of a Pixelfed server, and can potentially affect the servers' ability to federate.
Some user interaction is required to setup the conditions to be able to exercise the vulnerability, but the attacker could conduct this attack time-delayed manner, where user interaction is not actively required, since access tokens in Pixelfed have a 1-year lifetime before they expire, and users' often forget to revoke access tokens for applications that they are no longer using.
This also means that Access Tokens that may have been leaked from third-party OAuth Application's databases would be usable for a significant amount of time by potential attackers.
Prior versions
Whilst this vulnerability is listed as >= 0.10.4, there is potential that versions before 0.10.4 are also vulnerable to this sort of security bypass, however, given that the code changed significantly between 0.10.3 and 0.10.4 we've been unable to easily assess if these heavily outdated versions are vulnerable or not to this exploit.
Sponsorship
The work involved in investigating and remediation of this security vulnerability was provided by Nivenly Foundation, for whom we are grateful for their support of the Fediverse and Pixelfed.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "pixelfed/pixelfed"
},
"ranges": [
{
"events": [
{
"introduced": "0.10.4"
},
{
"fixed": "0.11.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-25108"
],
"database_specific": {
"cwe_ids": [
"CWE-280",
"CWE-285",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2024-02-12T15:17:23Z",
"nvd_published_at": "2024-02-12T20:15:08Z",
"severity": "CRITICAL"
},
"details": "### Summary\n\nWhen processing requests authorization was improperly and insufficiently checked, allowing attackers to access far more functionality than users intended, including to the administrative and moderator functionality of the Pixelfed server.\n\nThis vulnerability affects every version of Pixelfed between `v0.10.4` and `v0.11.9`, inclusive. A proof of concept of this vulnerability exists.\n\n### Details\n\nIn vulnerable versions of Pixelfed (versions before 0.11.11), when the API checked the request for permissions to perform a certain behavior, it did not check that the OAuth Application/Client had granted access to those API endpoints, it only checked if the user was authenticated via an access token, and if the user was the owner of the resource or an admin on the instance.\n\nThis meant that an attacker could request an access token for \"read\" permissions to authenticate you with their application, but the access token that they obtained actually could be used for \"write\" or even administrative actions, and the user who granted access to their account had zero knowledge of this elevated access.\n\n#### Proof of Concept\n\n1. Create an access token either via [2-legged OAuth flow](https://oauth.net/2/grant-types/authorization-code/) for the `read` scope, or create a Personal Access Tokens with the `read` scope.\n2. Using that Access Token, perform a request that would need a particular higher-privilege scope, for instance, following a user or performing an administrative request. (respectively requiring `follow` or `admin:read` and `admin:write` scopes in the patched versions)\n3. Observe that despite your access token having `read` permissions, the follow or administrative request was successful.\n\ne.g., Maybe an attacker collects an access token (which expires in 1 year) wants to do something really nasty to an admin, such as disabling federation on their target\u0027s pixelfed server. As long as that server has `instance.enable_cc` configured (defaults to `true`), then the attacker can use the `read` scoped access token and perform the following request:\n\n```\nPOST /api/admin/config/update\nContent-Type: application/json\nAccept: application/json\nAuthorization: Bearer \u003caccess token with read scope\u003e\n\n{ \"key\": \"federation.activitypub.enabled\": \"value\": false }\n```\n\nAnd federation of that pixelfed server would be subsequently disabled, as if the administrator had disabled it.\n\n### Impact\n\nThis vulnerability affects every local user of a Pixelfed server, and can potentially affect the servers\u0027 ability to federate.\n\nSome user interaction is required to setup the conditions to be able to exercise the vulnerability, but the attacker could conduct this attack time-delayed manner, where user interaction is not actively required, since access tokens in Pixelfed have a 1-year lifetime before they expire, and users\u0027 often forget to revoke access tokens for applications that they are no longer using.\n\nThis also means that Access Tokens that may have been leaked from third-party OAuth Application\u0027s databases would be usable for a significant amount of time by potential attackers.\n\n### Prior versions\n\nWhilst this vulnerability is listed as `\u003e= 0.10.4`, there is potential that versions before `0.10.4` are also vulnerable to this sort of security bypass, however, given that the code changed significantly between `0.10.3` and `0.10.4` we\u0027ve been unable to easily assess if these heavily outdated versions are vulnerable or not to this exploit.\n\n### Sponsorship\n\nThe work involved in investigating and remediation of this security vulnerability was provided by [Nivenly Foundation](https://nivenly.org/), for whom we are grateful for their support of the Fediverse and Pixelfed.",
"id": "GHSA-gccq-h3xj-jgvf",
"modified": "2024-10-11T21:35:07Z",
"published": "2024-02-12T15:17:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pixelfed/pixelfed/security/advisories/GHSA-gccq-h3xj-jgvf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25108"
},
{
"type": "WEB",
"url": "https://github.com/pixelfed/pixelfed/commit/7e47d6dccb0393a2e95c42813c562c854882b037"
},
{
"type": "WEB",
"url": "https://github.com/pixelfed/pixelfed/commit/fd7f5dbb"
},
{
"type": "WEB",
"url": "https://github.com/pixelfed/pixelfed/commit/fd7f5dbba13818f60d1c2b3ab110b499e996aa81"
},
{
"type": "PACKAGE",
"url": "https://github.com/pixelfed/pixelfed"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Pixelfed doesn\u0027t check OAuth Scopes in API routes, giving elevated permissions"
}
GHSA-GCF7-XV2H-QVV7
Vulnerability from github – Published: 2024-10-11 21:31 – Updated: 2024-10-15 21:30An issue in GIANT MANUFACTURING CO., LTD RideLink (tw.giant.ridelink) 2.0.7 allows a remote attacker to obtain sensitive information via the firmware update process.
{
"affected": [],
"aliases": [
"CVE-2024-48778"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-11T20:15:06Z",
"severity": "CRITICAL"
},
"details": "An issue in GIANT MANUFACTURING CO., LTD RideLink (tw.giant.ridelink) 2.0.7 allows a remote attacker to obtain sensitive information via the firmware update process.",
"id": "GHSA-gcf7-xv2h-qvv7",
"modified": "2024-10-15T21:30:37Z",
"published": "2024-10-11T21:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48778"
},
{
"type": "WEB",
"url": "https://github.com/HankJames/Vul-Reports/blob/main/FirmwareLeakage/tw.giant.ridelink/tw.giant.ridelink.md"
},
{
"type": "WEB",
"url": "http://giant.com"
},
{
"type": "WEB",
"url": "http://ridelink.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GCJ2-4JCM-VGJG
Vulnerability from github – Published: 2022-08-06 00:00 – Updated: 2022-08-12 00:01An issue has been discovered in GitLab CE/EE affecting all versions before 15.0.5, all versions starting from 15.1 before 15.1.4, all versions starting from 15.2 before 15.2.1. It may be possible to gain access to a private project through an email invite by using other user's email address as an unverified secondary email.
{
"affected": [],
"aliases": [
"CVE-2022-2326"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-05T16:15:00Z",
"severity": "HIGH"
},
"details": "An issue has been discovered in GitLab CE/EE affecting all versions before 15.0.5, all versions starting from 15.1 before 15.1.4, all versions starting from 15.2 before 15.2.1. It may be possible to gain access to a private project through an email invite by using other user\u0027s email address as an unverified secondary email.",
"id": "GHSA-gcj2-4jcm-vgjg",
"modified": "2022-08-12T00:01:20Z",
"published": "2022-08-06T00:00:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2326"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1517554"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-2326.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/356665"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GCM7-M975-8Q53
Vulnerability from github – Published: 2022-05-24 19:05 – Updated: 2022-07-31 00:00Intent redirection vulnerability in Samsung Internet prior to version 14.0.1.20 allows attacker to execute privileged action.
{
"affected": [],
"aliases": [
"CVE-2021-25400"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-11T15:15:00Z",
"severity": "HIGH"
},
"details": "Intent redirection vulnerability in Samsung Internet prior to version 14.0.1.20 allows attacker to execute privileged action.",
"id": "GHSA-gcm7-m975-8q53",
"modified": "2022-07-31T00:00:57Z",
"published": "2022-05-24T19:05:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25400"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2021\u0026month=5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GCMG-M9M3-J5JW
Vulnerability from github – Published: 2022-05-24 19:20 – Updated: 2022-05-24 19:20Adobe Experience Manager version 6.5.9.0 (and earlier) are affected by an improper access control vulnerability that leads to a security feature bypass. By manipulating referer headers, an unauthenticated attacker could gain access to arbitrary pages that they are not authorized to access.
{
"affected": [],
"aliases": [
"CVE-2021-42725"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-788",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-16T22:15:00Z",
"severity": "MODERATE"
},
"details": "Adobe Experience Manager version 6.5.9.0 (and earlier) are affected by an improper access control vulnerability that leads to a security feature bypass. By manipulating referer headers, an unauthenticated attacker could gain access to arbitrary pages that they are not authorized to access.",
"id": "GHSA-gcmg-m9m3-j5jw",
"modified": "2022-05-24T19:20:45Z",
"published": "2022-05-24T19:20:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42725"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/bridge/apsb21-94.html"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/experience-manager/apsb21-82.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GCQ3-MFVH-3X25
Vulnerability from github – Published: 2026-06-18 13:59 – Updated: 2026-07-20 21:23PraisonAI Code agent tools fail open without a workspace boundary
Summary
PraisonAI Code's agent-compatible CODE_TOOLS wrappers keep a global workspace root initialized to None. If an application uses CODE_TOOLS, code_read_file, code_search_replace, or code_apply_diff before calling set_workspace(), the wrappers pass workspace=None into lower-level helpers that only enforce path containment when a workspace is truthy. Absolute paths outside the intended project workspace are then read and modified.
The official examples correctly call set_workspace() before CODE_TOOLS, and this report does not claim configured workspaces are ineffective. The issue is the fail-open default. PraisonAI's security documentation describes workspace boundaries as the path-traversal protection mechanism, and the already-published Python API arbitrary file write advisory (GHSA-hvhp-v2gc-268q) was fixed by defaulting an unset workspace to os.getcwd(). The adjacent read and edit paths reached through CODE_TOOLS still fail open.
Affected Components
- Package:
praisonai - Current upstream main tested:
2f9677abb2ea68eab864ee8b6a828fd0141612e1 - Latest tested release:
v4.6.57 - Primary files:
src/praisonai/praisonai/code/agent_tools.pysrc/praisonai/praisonai/code/tools/read_file.pysrc/praisonai/praisonai/code/tools/search_replace.pysrc/praisonai/praisonai/code/tools/apply_diff.py
Root Cause
agent_tools.py initializes _workspace_root to None and passes it directly to lower-level helpers:
_workspace_root: Optional[str] = None
...
result = _read_file(..., workspace=_workspace_root)
...
result = _search_replace(..., workspace=_workspace_root)
The lower-level helpers only enforce containment if workspace is set:
if workspace:
if not is_path_within_directory(abs_path, workspace):
return {"success": False, ...}
The already-hardened write_file() path uses effective_workspace = workspace or os.getcwd(). Current tests assert that write_file(workspace=None) must stay inside the current working directory. The same fail-closed default is missing from read_file, search_replace, apply_diff, and the agent wrappers that call them.
Local-Only Reproduction
Run:
PYTHONPATH=/path/to/PraisonAI/src/praisonai:/path/to/PraisonAI/src/praisonai-agents \
python poc_code_tools_workspace_bypass.py
Expected vulnerable result:
[poc] HIT: CODE_TOOLS wrappers read and edit outside workspace when workspace is unset
The PoV creates a temporary workspace and a temporary file outside that workspace. With get_workspace() == None, code_read_file() reads the outside file, code_search_replace() modifies it, and code_apply_diff() modifies it again. After set_workspace(workspace), the same outside path is rejected by all three wrappers.
No external services, model providers, or network access are used.
Impact
If an application exposes PraisonAI Code's agent-compatible CODE_TOOLS to an LLM before setting a workspace boundary, prompt-influenced tool calls can read and modify files outside the intended project workspace. The practical attack shape matches the existing PraisonAI prompt-content advisory pattern: untrusted content influences an agent that has been given file-editing tools.
Practical impacts include:
- reading host secrets or local configuration files accessible to the process user;
- modifying arbitrary existing files when the attacker can supply or infer matching content for
code_search_replaceorcode_apply_diff; - using
code_read_fileto first learn file content and thencode_apply_diffto produce an exact modification; - bypassing the advertised workspace-boundary security posture unless the embedding application remembered to call
set_workspace()first.
This issue does not claim set_workspace() is ineffective. The control works when configured. The vulnerability is the fail-open default for the advertised agent-tool bundle and adjacent read/edit helpers.
Affected-Version Sweep
The same behavior was reproduced on:
- current upstream main:
2f9677abb2ea68eab864ee8b6a828fd0141612e1 v4.6.57v4.6.56v4.6.10v4.6.9v4.5.128v4.5.126v3.9.26v3.9.24
Suggested Fix
Recommended fix:
- Make every low-level file helper compute
effective_workspace = workspace or os.getcwd()before resolving paths. - Make
code_read_file,code_list_files,code_apply_diff,code_search_replace, andcode_execute_commanduseos.getcwd()as the default workspace when_workspace_root is None. - Keep allowing absolute paths only when they resolve inside the effective workspace.
- Add regression tests proving outside absolute paths are rejected before and after
set_workspace(). - Consider failing closed if
CODE_TOOLSis used before a workspace is configured, or log a warning when the default current working directory is used.
Disclosure Route
PraisonAI's official security documentation lists GitHub Security Advisories as the preferred reporting method and asks reports to include reproduction steps, affected versions, impact, and suggested fixes. The repository security policy page currently shows no configured SECURITY.md, but private vulnerability reporting is available.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.6.57"
},
"package": {
"ecosystem": "PyPI",
"name": "praisonai"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.6.59"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-56839"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-22",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T13:59:26Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "# PraisonAI Code agent tools fail open without a workspace boundary\n\n## Summary\n\nPraisonAI Code\u0027s agent-compatible `CODE_TOOLS` wrappers keep a global workspace root initialized to `None`. If an application uses `CODE_TOOLS`, `code_read_file`, `code_search_replace`, or `code_apply_diff` before calling `set_workspace()`, the wrappers pass `workspace=None` into lower-level helpers that only enforce path containment when a workspace is truthy. Absolute paths outside the intended project workspace are then read and modified.\n\nThe official examples correctly call `set_workspace()` before `CODE_TOOLS`, and this report does not claim configured workspaces are ineffective. The issue is the fail-open default. PraisonAI\u0027s security documentation describes workspace boundaries as the path-traversal protection mechanism, and the already-published Python API arbitrary file write advisory (`GHSA-hvhp-v2gc-268q`) was fixed by defaulting an unset workspace to `os.getcwd()`. The adjacent read and edit paths reached through `CODE_TOOLS` still fail open.\n\n## Affected Components\n\n- Package: `praisonai`\n- Current upstream main tested: `2f9677abb2ea68eab864ee8b6a828fd0141612e1`\n- Latest tested release: `v4.6.57`\n- Primary files:\n - `src/praisonai/praisonai/code/agent_tools.py`\n - `src/praisonai/praisonai/code/tools/read_file.py`\n - `src/praisonai/praisonai/code/tools/search_replace.py`\n - `src/praisonai/praisonai/code/tools/apply_diff.py`\n\n## Root Cause\n\n`agent_tools.py` initializes `_workspace_root` to `None` and passes it directly to lower-level helpers:\n\n```python\n_workspace_root: Optional[str] = None\n...\nresult = _read_file(..., workspace=_workspace_root)\n...\nresult = _search_replace(..., workspace=_workspace_root)\n```\n\nThe lower-level helpers only enforce containment if `workspace` is set:\n\n```python\nif workspace:\n if not is_path_within_directory(abs_path, workspace):\n return {\"success\": False, ...}\n```\n\nThe already-hardened `write_file()` path uses `effective_workspace = workspace or os.getcwd()`. Current tests assert that `write_file(workspace=None)` must stay inside the current working directory. The same fail-closed default is missing from `read_file`, `search_replace`, `apply_diff`, and the agent wrappers that call them.\n\n## Local-Only Reproduction\n\nRun:\n\n```bash\nPYTHONPATH=/path/to/PraisonAI/src/praisonai:/path/to/PraisonAI/src/praisonai-agents \\\n python poc_code_tools_workspace_bypass.py\n```\n\nExpected vulnerable result:\n\n```text\n[poc] HIT: CODE_TOOLS wrappers read and edit outside workspace when workspace is unset\n```\n\nThe PoV creates a temporary workspace and a temporary file outside that workspace. With `get_workspace() == None`, `code_read_file()` reads the outside file, `code_search_replace()` modifies it, and `code_apply_diff()` modifies it again. After `set_workspace(workspace)`, the same outside path is rejected by all three wrappers.\n\nNo external services, model providers, or network access are used.\n\n## Impact\n\nIf an application exposes PraisonAI Code\u0027s agent-compatible `CODE_TOOLS` to an LLM before setting a workspace boundary, prompt-influenced tool calls can read and modify files outside the intended project workspace. The practical attack shape matches the existing PraisonAI prompt-content advisory pattern: untrusted content influences an agent that has been given file-editing tools.\n\nPractical impacts include:\n\n- reading host secrets or local configuration files accessible to the process user;\n- modifying arbitrary existing files when the attacker can supply or infer matching content for `code_search_replace` or `code_apply_diff`;\n- using `code_read_file` to first learn file content and then `code_apply_diff` to produce an exact modification;\n- bypassing the advertised workspace-boundary security posture unless the embedding application remembered to call `set_workspace()` first.\n\nThis issue does not claim `set_workspace()` is ineffective. The control works when configured. The vulnerability is the fail-open default for the advertised agent-tool bundle and adjacent read/edit helpers.\n\n## Affected-Version Sweep\n\nThe same behavior was reproduced on:\n\n- current upstream main: `2f9677abb2ea68eab864ee8b6a828fd0141612e1`\n- `v4.6.57`\n- `v4.6.56`\n- `v4.6.10`\n- `v4.6.9`\n- `v4.5.128`\n- `v4.5.126`\n- `v3.9.26`\n- `v3.9.24`\n\n## Suggested Fix\n\nRecommended fix:\n\n1. Make every low-level file helper compute `effective_workspace = workspace or os.getcwd()` before resolving paths.\n2. Make `code_read_file`, `code_list_files`, `code_apply_diff`, `code_search_replace`, and `code_execute_command` use `os.getcwd()` as the default workspace when `_workspace_root is None`.\n3. Keep allowing absolute paths only when they resolve inside the effective workspace.\n4. Add regression tests proving outside absolute paths are rejected before and after `set_workspace()`.\n5. Consider failing closed if `CODE_TOOLS` is used before a workspace is configured, or log a warning when the default current working directory is used.\n\n## Disclosure Route\n\nPraisonAI\u0027s official security documentation lists GitHub Security Advisories as the preferred reporting method and asks reports to include reproduction steps, affected versions, impact, and suggested fixes. The repository security policy page currently shows no configured `SECURITY.md`, but private vulnerability reporting is available.",
"id": "GHSA-gcq3-mfvh-3x25",
"modified": "2026-07-20T21:23:47Z",
"published": "2026-06-18T13:59:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-gcq3-mfvh-3x25"
},
{
"type": "PACKAGE",
"url": "https://github.com/MervinPraison/PraisonAI"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "PraisonAI Code agent tools fail open without a workspace boundary"
}
Mitigation
- 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
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
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
- 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
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.