CWE-829
AllowedInclusion of Functionality from Untrusted Control Sphere
Abstraction: Base · Status: Incomplete
The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.
393 vulnerabilities reference this CWE, most recent first.
CVE-2018-1122 (GCVE-0-2018-1122)
Vulnerability from cvelistv5 – Published: 2018-05-23 14:00 – Updated: 2024-08-05 03:51| Vendor | Product | Version | |
|---|---|---|---|
| [UNKNOWN] | procps-ng, procps |
Affected:
procps-ng 3.3.15
|
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-05T03:51:48.790Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"name": "USN-3658-1",
"tags": [
"vendor-advisory",
"x_refsource_UBUNTU",
"x_transferred"
],
"url": "https://usn.ubuntu.com/3658-1/"
},
{
"name": "DSA-4208",
"tags": [
"vendor-advisory",
"x_refsource_DEBIAN",
"x_transferred"
],
"url": "https://www.debian.org/security/2018/dsa-4208"
},
{
"name": "GLSA-201805-14",
"tags": [
"vendor-advisory",
"x_refsource_GENTOO",
"x_transferred"
],
"url": "https://security.gentoo.org/glsa/201805-14"
},
{
"name": "44806",
"tags": [
"exploit",
"x_refsource_EXPLOIT-DB",
"x_transferred"
],
"url": "https://www.exploit-db.com/exploits/44806/"
},
{
"name": "[debian-lts-announce] 20180531 [SECURITY] [DLA 1390-1] procps security update",
"tags": [
"mailing-list",
"x_refsource_MLIST",
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2018/05/msg00021.html"
},
{
"name": "USN-3658-3",
"tags": [
"vendor-advisory",
"x_refsource_UBUNTU",
"x_transferred"
],
"url": "https://usn.ubuntu.com/3658-3/"
},
{
"name": "104214",
"tags": [
"vdb-entry",
"x_refsource_BID",
"x_transferred"
],
"url": "http://www.securityfocus.com/bid/104214"
},
{
"name": "[oss-security] 20180517 Qualys Security Advisory - Procps-ng Audit Report",
"tags": [
"mailing-list",
"x_refsource_MLIST",
"x_transferred"
],
"url": "http://seclists.org/oss-sec/2018/q2/122"
},
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-1122"
},
{
"tags": [
"x_refsource_MISC",
"x_transferred"
],
"url": "https://www.qualys.com/2018/05/17/procps-ng-audit-report-advisory.txt"
},
{
"name": "RHSA-2019:2189",
"tags": [
"vendor-advisory",
"x_refsource_REDHAT",
"x_transferred"
],
"url": "https://access.redhat.com/errata/RHSA-2019:2189"
},
{
"name": "openSUSE-SU-2019:2376",
"tags": [
"vendor-advisory",
"x_refsource_SUSE",
"x_transferred"
],
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00058.html"
},
{
"name": "openSUSE-SU-2019:2379",
"tags": [
"vendor-advisory",
"x_refsource_SUSE",
"x_transferred"
],
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00059.html"
},
{
"name": "RHSA-2020:0595",
"tags": [
"vendor-advisory",
"x_refsource_REDHAT",
"x_transferred"
],
"url": "https://access.redhat.com/errata/RHSA-2020:0595"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"product": "procps-ng, procps",
"vendor": "[UNKNOWN]",
"versions": [
{
"status": "affected",
"version": "procps-ng 3.3.15"
}
]
}
],
"datePublic": "2018-05-17T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"value": "procps-ng before version 3.3.15 is vulnerable to a local privilege escalation in top. If a user runs top with HOME unset in an attacker-controlled directory, the attacker could achieve privilege escalation by exploiting one of several vulnerabilities in the config_file() function."
}
],
"metrics": [
{
"cvssV3_0": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.3,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"version": "3.0"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-829",
"description": "CWE-829",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2020-02-25T14:06:10.000Z",
"orgId": "53f830b8-0a3f-465b-8143-3b8a9948e749",
"shortName": "redhat"
},
"references": [
{
"name": "USN-3658-1",
"tags": [
"vendor-advisory",
"x_refsource_UBUNTU"
],
"url": "https://usn.ubuntu.com/3658-1/"
},
{
"name": "DSA-4208",
"tags": [
"vendor-advisory",
"x_refsource_DEBIAN"
],
"url": "https://www.debian.org/security/2018/dsa-4208"
},
{
"name": "GLSA-201805-14",
"tags": [
"vendor-advisory",
"x_refsource_GENTOO"
],
"url": "https://security.gentoo.org/glsa/201805-14"
},
{
"name": "44806",
"tags": [
"exploit",
"x_refsource_EXPLOIT-DB"
],
"url": "https://www.exploit-db.com/exploits/44806/"
},
{
"name": "[debian-lts-announce] 20180531 [SECURITY] [DLA 1390-1] procps security update",
"tags": [
"mailing-list",
"x_refsource_MLIST"
],
"url": "https://lists.debian.org/debian-lts-announce/2018/05/msg00021.html"
},
{
"name": "USN-3658-3",
"tags": [
"vendor-advisory",
"x_refsource_UBUNTU"
],
"url": "https://usn.ubuntu.com/3658-3/"
},
{
"name": "104214",
"tags": [
"vdb-entry",
"x_refsource_BID"
],
"url": "http://www.securityfocus.com/bid/104214"
},
{
"name": "[oss-security] 20180517 Qualys Security Advisory - Procps-ng Audit Report",
"tags": [
"mailing-list",
"x_refsource_MLIST"
],
"url": "http://seclists.org/oss-sec/2018/q2/122"
},
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-1122"
},
{
"tags": [
"x_refsource_MISC"
],
"url": "https://www.qualys.com/2018/05/17/procps-ng-audit-report-advisory.txt"
},
{
"name": "RHSA-2019:2189",
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2019:2189"
},
{
"name": "openSUSE-SU-2019:2376",
"tags": [
"vendor-advisory",
"x_refsource_SUSE"
],
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00058.html"
},
{
"name": "openSUSE-SU-2019:2379",
"tags": [
"vendor-advisory",
"x_refsource_SUSE"
],
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00059.html"
},
{
"name": "RHSA-2020:0595",
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2020:0595"
}
],
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "secalert@redhat.com",
"ID": "CVE-2018-1122",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "procps-ng, procps",
"version": {
"version_data": [
{
"version_value": "procps-ng 3.3.15"
}
]
}
}
]
},
"vendor_name": "[UNKNOWN]"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "procps-ng before version 3.3.15 is vulnerable to a local privilege escalation in top. If a user runs top with HOME unset in an attacker-controlled directory, the attacker could achieve privilege escalation by exploiting one of several vulnerabilities in the config_file() function."
}
]
},
"impact": {
"cvss": [
[
{
"vectorString": "7.3/CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"version": "3.0"
}
]
]
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-829"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "USN-3658-1",
"refsource": "UBUNTU",
"url": "https://usn.ubuntu.com/3658-1/"
},
{
"name": "DSA-4208",
"refsource": "DEBIAN",
"url": "https://www.debian.org/security/2018/dsa-4208"
},
{
"name": "GLSA-201805-14",
"refsource": "GENTOO",
"url": "https://security.gentoo.org/glsa/201805-14"
},
{
"name": "44806",
"refsource": "EXPLOIT-DB",
"url": "https://www.exploit-db.com/exploits/44806/"
},
{
"name": "[debian-lts-announce] 20180531 [SECURITY] [DLA 1390-1] procps security update",
"refsource": "MLIST",
"url": "https://lists.debian.org/debian-lts-announce/2018/05/msg00021.html"
},
{
"name": "USN-3658-3",
"refsource": "UBUNTU",
"url": "https://usn.ubuntu.com/3658-3/"
},
{
"name": "104214",
"refsource": "BID",
"url": "http://www.securityfocus.com/bid/104214"
},
{
"name": "[oss-security] 20180517 Qualys Security Advisory - Procps-ng Audit Report",
"refsource": "MLIST",
"url": "http://seclists.org/oss-sec/2018/q2/122"
},
{
"name": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-1122",
"refsource": "CONFIRM",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-1122"
},
{
"name": "https://www.qualys.com/2018/05/17/procps-ng-audit-report-advisory.txt",
"refsource": "MISC",
"url": "https://www.qualys.com/2018/05/17/procps-ng-audit-report-advisory.txt"
},
{
"name": "RHSA-2019:2189",
"refsource": "REDHAT",
"url": "https://access.redhat.com/errata/RHSA-2019:2189"
},
{
"name": "openSUSE-SU-2019:2376",
"refsource": "SUSE",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00058.html"
},
{
"name": "openSUSE-SU-2019:2379",
"refsource": "SUSE",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00059.html"
},
{
"name": "RHSA-2020:0595",
"refsource": "REDHAT",
"url": "https://access.redhat.com/errata/RHSA-2020:0595"
}
]
}
}
}
},
"cveMetadata": {
"assignerOrgId": "53f830b8-0a3f-465b-8143-3b8a9948e749",
"assignerShortName": "redhat",
"cveId": "CVE-2018-1122",
"datePublished": "2018-05-23T14:00:00.000Z",
"dateReserved": "2017-12-04T00:00:00.000Z",
"dateUpdated": "2024-08-05T03:51:48.790Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
GHSA-236C-VHJ4-GFXG
Vulnerability from github – Published: 2022-05-25 00:00 – Updated: 2026-02-17 21:40Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-pjwm-rvh2-c87w. This link is maintained to preserve external references.
Original Description
A vulnerability was found in ua-parser-js 0.7.29/0.8.0/1.0.0. It has been rated as critical. This issue affects the crypto mining component which introduces a backdoor. Upgrading to version 0.7.30, 0.8.1 and 1.0.1 is able to address this issue. It is recommended to upgrade the affected component.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "ua-parser-js"
},
"ranges": [
{
"events": [
{
"introduced": "0.7.29"
},
{
"fixed": "0.7.30"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.7.29"
]
},
{
"package": {
"ecosystem": "npm",
"name": "ua-parser-js"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.0"
},
{
"fixed": "0.8.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.8.0"
]
},
{
"package": {
"ecosystem": "npm",
"name": "ua-parser-js"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.0.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.0.0"
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-829",
"CWE-912"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-17T21:40:20Z",
"nvd_published_at": "2022-05-24T16:15:00Z",
"severity": "HIGH"
},
"details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-pjwm-rvh2-c87w. This link is maintained to preserve external references.\n\n### Original Description\nA vulnerability was found in ua-parser-js 0.7.29/0.8.0/1.0.0. It has been rated as critical. This issue affects the crypto mining component which introduces a backdoor. Upgrading to version 0.7.30, 0.8.1 and 1.0.1 is able to address this issue. It is recommended to upgrade the affected component.",
"id": "GHSA-236c-vhj4-gfxg",
"modified": "2026-02-17T21:40:20Z",
"published": "2022-05-25T00:00:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4229"
},
{
"type": "WEB",
"url": "https://github.com/faisalman/ua-parser-js/issues/536"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-pjwm-rvh2-c87w"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.185453"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "Duplicate Advisory: Embedded malware in ua-parser-js",
"withdrawn": "2026-02-17T21:40:20Z"
}
GHSA-29PC-J6WP-67WC
Vulnerability from github – Published: 2025-07-14 15:30 – Updated: 2025-07-14 15:30The Secure Password extension in One Identity Password Manager before 5.14.4 allows local privilege escalation. The issue arises from a flawed security hardening mechanism within the kiosk browser used to display the Password Self-Service site to end users. Specifically, the application attempts to restrict privileged actions by overriding the native window.print() function. However, this protection can be bypassed by an attacker who accesses the Password Self-Service site from the lock screen and navigates to an attacker-controlled webpage via the Help function. By hosting a crafted web page with JavaScript, the attacker can restore and invoke the window.print() function, launching a SYSTEM-privileged print dialog. From this dialog, the attacker can exploit standard Windows functionality - such as the Print to PDF or Add Printer wizard - to spawn a command prompt with SYSTEM privileges. Successful exploitation allows a local attacker (with access to a locked workstation) to gain SYSTEM-level privileges, granting full control over the affected device.
{
"affected": [],
"aliases": [
"CVE-2025-27582"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-14T13:15:24Z",
"severity": "HIGH"
},
"details": "The Secure Password extension in One Identity Password Manager before 5.14.4 allows local privilege escalation. The issue arises from a flawed security hardening mechanism within the kiosk browser used to display the Password Self-Service site to end users. Specifically, the application attempts to restrict privileged actions by overriding the native window.print() function. However, this protection can be bypassed by an attacker who accesses the Password Self-Service site from the lock screen and navigates to an attacker-controlled webpage via the Help function. By hosting a crafted web page with JavaScript, the attacker can restore and invoke the window.print() function, launching a SYSTEM-privileged print dialog. From this dialog, the attacker can exploit standard Windows functionality - such as the Print to PDF or Add Printer wizard - to spawn a command prompt with SYSTEM privileges. Successful exploitation allows a local attacker (with access to a locked workstation) to gain SYSTEM-level privileges, granting full control over the affected device.",
"id": "GHSA-29pc-j6wp-67wc",
"modified": "2025-07-14T15:30:33Z",
"published": "2025-07-14T15:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27582"
},
{
"type": "WEB",
"url": "https://www.cyberis.com/article/password-manager-privilege-escalation"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2G3W-CPC4-CHR4
Vulnerability from github – Published: 2026-04-10 19:26 – Updated: 2026-04-10 19:26PraisonAI automatically loads a file named tools.py from the current working directory to discover and register custom agent tools. This loading process uses importlib.util.spec_from_file_location and immediately executes module-level code via spec.loader.exec_module() without explicit user consent, validation, or sandboxing.
The tools.py file is loaded implicitly, even when it is not referenced in configuration files or explicitly requested by the user. As a result, merely placing a file named tools.py in the working directory is sufficient to trigger code execution.
This behavior violates the expected security boundary between user-controlled project files (e.g., YAML configurations) and executable code, as untrusted content in the working directory is treated as trusted and executed automatically.
If an attacker can place a malicious tools.py file into a directory where a user or automated system (e.g., CI/CD pipeline) runs praisonai, arbitrary code execution occurs immediately upon startup, before any agent logic begins.
Vulnerable Code Location
src/praisonai/praisonai/tool_resolver.py → ToolResolver._load_local_tools
tools_path = Path(self._tools_py_path) # defaults to "tools.py" in CWD
...
spec = importlib.util.spec_from_file_location("tools", str(tools_path))
module = importlib.util.module_from_spec(spec)
spec.loader.exec_module(module) # Executes arbitrary code
Reproducing the Attack
- Create a malicious
tools.pyin the target directory:
import os
# Executes immediately on import
print("[PWNED] Running arbitrary attacker code")
os.system("echo RCE confirmed > pwned.txt")
def dummy_tool():
return "ok"
-
Create any valid
agents.yaml. -
Run:
praisonai agents.yaml
-
Observe:
-
[PWNED]is printed pwned.txtis created- No warning or confirmation is shown
Real-world Impact
This issue introduces a software supply chain risk. If an attacker introduces a malicious tools.py into a repository (e.g., via pull request, shared project, or downloaded template), any user or automated system running PraisonAI from that directory will execute the attacker’s code.
Affected scenarios include:
- CI/CD pipelines processing untrusted repositories
- Shared development environments
- AI workflow automation systems
- Public project templates or examples
Successful exploitation can lead to:
- Execution of arbitrary commands
- Exfiltration of environment variables and credentials
- Persistence mechanisms on developer or CI systems
Remediation Steps
-
Require explicit opt-in for loading
tools.py -
Introduce a CLI flag (e.g.,
--load-tools) or config option -
Disable automatic loading by default
-
Add pre-execution user confirmation
-
Warn users before executing local
tools.py -
Allow users to decline execution
-
Restrict trusted paths
-
Only load tools from explicitly defined project directories
-
Avoid defaulting to the current working directory
-
Avoid executing module-level code during discovery
-
Use static analysis (e.g., AST parsing) to identify tool functions
-
Require explicit registration functions instead of import side effects
-
Optional hardening
-
Support sandboxed execution (subprocess / restricted environment)
- Provide hash verification or signing for trusted tool files
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "praisonai"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.128"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40156"
],
"database_specific": {
"cwe_ids": [
"CWE-426",
"CWE-829",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-10T19:26:44Z",
"nvd_published_at": "2026-04-10T17:17:13Z",
"severity": "HIGH"
},
"details": "PraisonAI automatically loads a file named `tools.py` from the current working directory to discover and register custom agent tools. This loading process uses `importlib.util.spec_from_file_location` and immediately executes module-level code via `spec.loader.exec_module()` **without explicit user consent, validation, or sandboxing**.\n\nThe `tools.py` file is loaded **implicitly**, even when it is not referenced in configuration files or explicitly requested by the user. As a result, merely placing a file named `tools.py` in the working directory is sufficient to trigger code execution.\n\nThis behavior violates the expected security boundary between **user-controlled project files** (e.g., YAML configurations) and **executable code**, as untrusted content in the working directory is treated as trusted and executed automatically.\n\nIf an attacker can place a malicious `tools.py` file into a directory where a user or automated system (e.g., CI/CD pipeline) runs `praisonai`, arbitrary code execution occurs immediately upon startup, before any agent logic begins.\n\n---\n\n## Vulnerable Code Location\n\n`src/praisonai/praisonai/tool_resolver.py` \u2192 `ToolResolver._load_local_tools`\n\n```python\ntools_path = Path(self._tools_py_path) # defaults to \"tools.py\" in CWD\n...\nspec = importlib.util.spec_from_file_location(\"tools\", str(tools_path))\nmodule = importlib.util.module_from_spec(spec)\nspec.loader.exec_module(module) # Executes arbitrary code\n```\n\n---\n\n## Reproducing the Attack\n\n1. Create a malicious `tools.py` in the target directory:\n\n```python\nimport os\n\n# Executes immediately on import\nprint(\"[PWNED] Running arbitrary attacker code\")\nos.system(\"echo RCE confirmed \u003e pwned.txt\")\n\ndef dummy_tool():\n return \"ok\"\n```\n\n2. Create any valid `agents.yaml`.\n\n3. Run:\n\n```bash\npraisonai agents.yaml\n```\n\n4. Observe:\n\n* `[PWNED]` is printed\n* `pwned.txt` is created\n* No warning or confirmation is shown\n\n---\n\n## Real-world Impact\n\nThis issue introduces a **software supply chain risk**. If an attacker introduces a malicious `tools.py` into a repository (e.g., via pull request, shared project, or downloaded template), any user or automated system running PraisonAI from that directory will execute the attacker\u2019s code.\n\nAffected scenarios include:\n\n* CI/CD pipelines processing untrusted repositories\n* Shared development environments\n* AI workflow automation systems\n* Public project templates or examples\n\nSuccessful exploitation can lead to:\n\n* Execution of arbitrary commands\n* Exfiltration of environment variables and credentials\n* Persistence mechanisms on developer or CI systems\n\n---\n\n## Remediation Steps\n\n1. **Require explicit opt-in for loading `tools.py`**\n\n * Introduce a CLI flag (e.g., `--load-tools`) or config option\n * Disable automatic loading by default\n\n2. **Add pre-execution user confirmation**\n\n * Warn users before executing local `tools.py`\n * Allow users to decline execution\n\n3. **Restrict trusted paths**\n\n * Only load tools from explicitly defined project directories\n * Avoid defaulting to the current working directory\n\n4. **Avoid executing module-level code during discovery**\n\n * Use static analysis (e.g., AST parsing) to identify tool functions\n * Require explicit registration functions instead of import side effects\n\n5. **Optional hardening**\n\n * Support sandboxed execution (subprocess / restricted environment)\n * Provide hash verification or signing for trusted tool files",
"id": "GHSA-2g3w-cpc4-chr4",
"modified": "2026-04-10T19:26:44Z",
"published": "2026-04-10T19:26:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-2g3w-cpc4-chr4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40156"
},
{
"type": "PACKAGE",
"url": "https://github.com/MervinPraison/PraisonAI"
},
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/releases/tag/v4.5.128"
}
],
"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"
}
],
"summary": "PraisonAI Vulnerable to Implicit Execution of Arbitrary Code via Automatic `tools.py` Loading"
}
GHSA-2J97-56X9-C2HP
Vulnerability from github – Published: 2023-05-05 21:31 – Updated: 2023-05-05 21:31PHP Remote File Inclusion in GitHub repository unilogies/bumsys prior to 2.1.1.
{
"affected": [],
"aliases": [
"CVE-2023-2551"
],
"database_specific": {
"cwe_ids": [
"CWE-829",
"CWE-98"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-05T20:15:10Z",
"severity": "HIGH"
},
"details": "PHP Remote File Inclusion in GitHub repository unilogies/bumsys prior to 2.1.1.",
"id": "GHSA-2j97-56x9-c2hp",
"modified": "2023-05-05T21:31:11Z",
"published": "2023-05-05T21:31:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2551"
},
{
"type": "WEB",
"url": "https://github.com/unilogies/bumsys/commit/86e29dd23df348ec6075f0c0de8e06b8d9fb0a9a"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/5723613c-55c6-4f18-9ed3-61ad44f5de9c"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2JJV-QF24-VFM4
Vulnerability from github – Published: 2025-09-24 18:57 – Updated: 2025-12-22 16:31When using Claude Code with Yarn installed, Yarn config files can trigger code execution when running yarn --version. This could lead to a bypass of the directory trust dialog in Claude Code, as plugins and yarnPath could be executed prior to the user accepting the risks of working in an untrusted directory. Users on standard Claude Code auto-update will have received this fix automatically. Users performing manual updates are advised to update to the latest version.
Thank you to Benjamin Faller, Redguard AG and Michael Hess for reporting this issue!
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@anthropic-ai/claude-code"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.39"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-59828"
],
"database_specific": {
"cwe_ids": [
"CWE-829",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-24T18:57:44Z",
"nvd_published_at": "2025-09-24T20:15:33Z",
"severity": "HIGH"
},
"details": "When using Claude Code with Yarn installed, Yarn config files can trigger code execution when running `yarn --version`. This could lead to a bypass of the directory trust dialog in Claude Code, as plugins and `yarnPath` could be executed prior to the user accepting the risks of working in an untrusted directory. Users on standard Claude Code auto-update will have received this fix automatically. Users performing manual updates are advised to update to the latest version.\n\nThank you to Benjamin Faller, Redguard AG and Michael Hess for reporting this issue!",
"id": "GHSA-2jjv-qf24-vfm4",
"modified": "2025-12-22T16:31:26Z",
"published": "2025-09-24T18:57:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/anthropics/claude-code/security/advisories/GHSA-2jjv-qf24-vfm4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59828"
},
{
"type": "PACKAGE",
"url": "https://github.com/anthropics/claude-code"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/GHSA-2jjv-qf24-vfm4"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59828"
},
{
"type": "WEB",
"url": "https://yarnpkg.com/advanced/plugin-tutorial"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Claude Code Vulnerable to Arbitrary Code Execution via Plugin Autoloading with Specific Yarn Versions"
}
GHSA-2JMQ-PWPX-V2PQ
Vulnerability from github – Published: 2025-12-03 15:30 – Updated: 2025-12-10 21:31Akamai Guardicore Platform Agent before 52.1.1 allows an unprivileged user to fully elevate privileges to SYSTEM. This affects versions before 50.15.0, 51.12.0, and 52.1.1.
{
"affected": [],
"aliases": [
"CVE-2025-53841"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-03T15:15:51Z",
"severity": "HIGH"
},
"details": "Akamai Guardicore Platform Agent before 52.1.1 allows an unprivileged user to fully elevate privileges to SYSTEM. This affects versions before 50.15.0, 51.12.0, and 52.1.1.",
"id": "GHSA-2jmq-pwpx-v2pq",
"modified": "2025-12-10T21:31:29Z",
"published": "2025-12-03T15:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53841"
},
{
"type": "WEB",
"url": "https://community.akamai.com/customers/s/article/Windows-Agent-Vulnerability-Summary-and-Resolution"
},
{
"type": "WEB",
"url": "https://techdocs.akamai.com/guardicore-platform-agent/changelog"
},
{
"type": "WEB",
"url": "https://www.akamai.com/blog/security/advisory-cve-2025-53841-guardicore-local-privilege-escalation"
},
{
"type": "WEB",
"url": "https://www.tuv.com/landingpage/en/vulnerability-disclosure"
}
],
"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-2JQX-F366-MQRV
Vulnerability from github – Published: 2023-10-30 09:30 – Updated: 2023-11-08 03:30In Yettiesoft VestCert versions 2.36 to 2.5.29, a vulnerability exists due to improper validation of third-party modules. This allows malicious actors to load arbitrary third-party modules, leading to remote code execution.
{
"affected": [],
"aliases": [
"CVE-2023-45798"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-30T07:15:12Z",
"severity": "CRITICAL"
},
"details": "In Yettiesoft VestCert versions 2.36 to 2.5.29, a vulnerability exists due to improper validation of third-party modules. This allows malicious actors to load arbitrary third-party modules, leading to remote code execution.",
"id": "GHSA-2jqx-f366-mqrv",
"modified": "2023-11-08T03:30:32Z",
"published": "2023-10-30T09:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45798"
},
{
"type": "WEB",
"url": "https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133\u0026nttId=71008\u0026menuNo=205020"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2JRM-GWW7-WCH2
Vulnerability from github – Published: 2022-05-24 17:40 – Updated: 2024-04-23 23:37It was found in Moodle before version 3.10.1, 3.9.4, 3.8.7 and 3.5.16 that it was possible for site administrators to execute arbitrary PHP scripts via a PHP include used during Shibboleth authentication.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "3.5"
},
{
"fixed": "3.5.16"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "3.8"
},
{
"fixed": "3.8.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "3.9"
},
{
"fixed": "3.9.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "3.10"
},
{
"fixed": "3.10.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-20187"
],
"database_specific": {
"cwe_ids": [
"CWE-829",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-23T23:37:33Z",
"nvd_published_at": "2021-01-28T19:15:00Z",
"severity": "HIGH"
},
"details": "It was found in Moodle before version 3.10.1, 3.9.4, 3.8.7 and 3.5.16 that it was possible for site administrators to execute arbitrary PHP scripts via a PHP include used during Shibboleth authentication.",
"id": "GHSA-2jrm-gww7-wch2",
"modified": "2024-04-23T23:37:33Z",
"published": "2022-05-24T17:40:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20187"
},
{
"type": "PACKAGE",
"url": "https://github.com/moodle/moodle"
},
{
"type": "WEB",
"url": "https://moodle.org/mod/forum/discuss.php?d=417171"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Moodle Arbitrary PHP code execution by site admins via Shibboleth configuration"
}
GHSA-2Q6J-GQC4-4GW3
Vulnerability from github – Published: 2024-01-16 21:13 – Updated: 2024-01-19 19:28CL Signatures Issuer Key Correctness Proof lacks of prime strength checking
A weakness in the Hyperledger AnonCreds specification that is not mitigated in the Ursa and AnonCreds implementations is that the Issuer does not publish a key correctness proof demonstrating that a generated private key is sufficient to meet the unlinkability guarantees of AnonCreds. A sufficient private key is one in which it's components p and q are safe primes, such that:
pandqare both prime numberspandqare not equalpandqhave the same, sufficiently large, size- For example, using two values both 1024 bits long is sufficient, whereas using one value 2040 bits long and the other 8 bits long is not.
The Ursa and AnonCreds CL-Signatures implementations always generate a sufficient private key. A malicious issuer could in theory create a custom CL Signature implementation (derived from the Ursa or AnonCreds CL-Signatures implementations) that uses weakened private keys such that presentations from holders could be shared by verifiers to the issuer who could determine the holder to which the credential was issued.
Impact
This vulnerability could impact holders of AnonCreds credentials implemented using the CL-signature scheme in the Ursa and AnonCreds implementations of CL Signatures.
Mitigations
Jan Camenisch and Markus Michels. Proving in zero-knowledge that a number is the product of two safe primes (pages 12-13) demonstrates a key correctness proof that could be used to show the issuer has generated a sufficiently strong private key, proving the characteristics listed above.
In a future version of AnonCreds, the additional key correctness proof could be published separately or added to the Credential Definition. In the meantime, Issuers in existing ecosystems can share such a proof with their ecosystem co-participants in an ad hoc manner.
The lack of such a published key correctness proof allows a malicious Issuer to deliberately generate a private key that lacks the requirements listed above, enabling the Issuer to perform a brute force attack on presentations provided to colluding verifiers that breaks the unlinkability guarantee of AnonCreds.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c 0.3"
},
"package": {
"ecosystem": "crates.io",
"name": "anoncreds-clsignatures"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "ursa"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.3.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-31021"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": true,
"github_reviewed_at": "2024-01-16T21:13:36Z",
"nvd_published_at": "2024-01-16T22:15:37Z",
"severity": "LOW"
},
"details": "# CL Signatures Issuer Key Correctness Proof lacks of prime strength checking\n\nA weakness in the Hyperledger AnonCreds specification that is not mitigated in the Ursa and AnonCreds implementations is that the Issuer does not publish a key correctness proof demonstrating that a generated private key is sufficient to meet the unlinkability guarantees of AnonCreds. A sufficient private key is one in which it\u0027s components `p` and `q` are safe primes, such that:\n\n- `p` and `q` are both prime numbers\n- `p` and `q` are not equal\n- `p` and `q` have the same, sufficiently large, size\n - For example, using two values both 1024 bits long is sufficient, whereas using one value 2040 bits long and the other 8 bits long is not.\n\nThe Ursa and AnonCreds CL-Signatures implementations always generate a sufficient private key. A malicious issuer could in theory create a custom CL Signature implementation (derived from the Ursa or AnonCreds CL-Signatures implementations) that uses weakened private keys such that presentations from holders could be shared by verifiers to the issuer who could determine the holder to which the credential was issued.\n\n### Impact\n\nThis vulnerability could impact holders of AnonCreds credentials implemented using the CL-signature scheme in the Ursa and AnonCreds implementations of CL Signatures.\n\n### Mitigations\n\n[Jan Camenisch and Markus Michels. Proving in zero-knowledge that a number is the product of two safe primes] (pages 12-13) demonstrates a key correctness proof that could be used to show the issuer has generated a sufficiently strong private key, proving the characteristics listed above.\n\nIn a future version of AnonCreds, the additional key correctness proof could be published separately or added to the Credential Definition. In the meantime, Issuers in existing ecosystems can share such a proof with their ecosystem co-participants in an ad hoc manner.\n\n[Jan Camenisch and Markus Michels. Proving in zero-knowledge that a number is the product of two safe primes]: https://www.brics.dk/RS/98/29/BRICS-RS-98-29.pdf\n\nThe lack of such a published key correctness proof allows a malicious Issuer to deliberately generate a private key that lacks the requirements listed above, enabling the Issuer to perform a brute force attack on presentations provided to colluding verifiers that breaks the unlinkability guarantee of AnonCreds.",
"id": "GHSA-2q6j-gqc4-4gw3",
"modified": "2024-01-19T19:28:13Z",
"published": "2024-01-16T21:13:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/hyperledger-archives/ursa/security/advisories/GHSA-2q6j-gqc4-4gw3"
},
{
"type": "WEB",
"url": "https://github.com/hyperledger/ursa/security/advisories/GHSA-2q6j-gqc4-4gw3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31021"
},
{
"type": "PACKAGE",
"url": "https://github.com/hyperledger-archives/ursa"
},
{
"type": "WEB",
"url": "https://www.brics.dk/RS/98/29/BRICS-RS-98-29.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Breaking unlinkability in Identity Mixer using malicious keys"
}
Mitigation MIT-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 [REF-1482].
Mitigation MIT-21.1
Strategy: Enforcement by Conversion
- When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
- For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.
Mitigation MIT-15
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Mitigation MIT-22
Strategy: Sandbox or Jail
- Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
- OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Mitigation MIT-5.1
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.
- Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.
Mitigation MIT-34
Strategy: Attack Surface Reduction
- Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.
- This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.
Mitigation MIT-6
Strategy: Attack Surface Reduction
- Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
- Many file inclusion problems occur because the programmer assumed that certain inputs could not be modified, especially for cookies and URL components.
Mitigation MIT-29
Strategy: Firewall
Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
CAPEC-175: Code Inclusion
An adversary exploits a weakness on the target to force arbitrary code to be retrieved locally or from a remote location and executed. This differs from code injection in that code injection involves the direct inclusion of code while code inclusion involves the addition or replacement of a reference to a code file, which is subsequently loaded by the target and used as part of the code of some application.
CAPEC-201: Serialized Data External Linking
An adversary creates a serialized data file (e.g. XML, YAML, etc...) that contains an external data reference. Because serialized data parsers may not validate documents with external references, there may be no checks on the nature of the reference in the external data. This can allow an adversary to open arbitrary files or connections, which may further lead to the adversary gaining access to information on the system that they would normally be unable to obtain.
CAPEC-228: DTD Injection
An attacker injects malicious content into an application's DTD in an attempt to produce a negative technical impact. DTDs are used to describe how XML documents are processed. Certain malformed DTDs (for example, those with excessive entity expansion as described in CAPEC 197) can cause the XML parsers that process the DTDs to consume excessive resources resulting in resource depletion.
CAPEC-251: Local Code Inclusion
The attacker forces an application to load arbitrary code files from the local machine. The attacker could use this to try to load old versions of library files that have known vulnerabilities, to load files that the attacker placed on the local machine during a prior attack, or to otherwise change the functionality of the targeted application in unexpected ways.
CAPEC-252: PHP Local File Inclusion
The attacker loads and executes an arbitrary local PHP file on a target machine. The attacker could use this to try to load old versions of PHP files that have known vulnerabilities, to load PHP files that the attacker placed on the local machine during a prior attack, or to otherwise change the functionality of the targeted application in unexpected ways.
CAPEC-253: Remote Code Inclusion
The attacker forces an application to load arbitrary code files from a remote location. The attacker could use this to try to load old versions of library files that have known vulnerabilities, to load malicious files that the attacker placed on the remote machine, or to otherwise change the functionality of the targeted application in unexpected ways.
CAPEC-263: Force Use of Corrupted Files
This describes an attack where an application is forced to use a file that an attacker has corrupted. The result is often a denial of service caused by the application being unable to process the corrupted file, but other results, including the disabling of filters or access controls (if the application fails in an unsafe way rather than failing by locking down) or buffer overflows are possible.
CAPEC-538: Open-Source Library Manipulation
Adversaries implant malicious code in open source software (OSS) libraries to have it widely distributed, as OSS is commonly downloaded by developers and other users to incorporate into software development projects. The adversary can have a particular system in mind to target, or the implantation can be the first stage of follow-on attacks on many systems.
CAPEC-549: Local Execution of Code
An adversary installs and executes malicious code on the target system in an effort to achieve a negative technical impact. Examples include rootkits, ransomware, spyware, adware, and others.
CAPEC-640: Inclusion of Code in Existing Process
The adversary takes advantage of a bug in an application failing to verify the integrity of the running process to execute arbitrary code in the address space of a separate live process. The adversary could use running code in the context of another process to try to access process's memory, system/network resources, etc. The goal of this attack is to evade detection defenses and escalate privileges by masking the malicious code under an existing legitimate process. Examples of approaches include but not limited to: dynamic-link library (DLL) injection, portable executable injection, thread execution hijacking, ptrace system calls, VDSO hijacking, function hooking, reflective code loading, and more.
CAPEC-660: Root/Jailbreak Detection Evasion via Hooking
An adversary forces a non-restricted mobile application to load arbitrary code or code files, via Hooking, with the goal of evading Root/Jailbreak detection. Mobile device users often Root/Jailbreak their devices in order to gain administrative control over the mobile operating system and/or to install third-party mobile applications that are not provided by authorized application stores (e.g. Google Play Store and Apple App Store). Adversaries may further leverage these capabilities to escalate privileges or bypass access control on legitimate applications. Although many mobile applications check if a mobile device is Rooted/Jailbroken prior to authorized use of the application, adversaries may be able to "hook" code in order to circumvent these checks. Successfully evading Root/Jailbreak detection allows an adversary to execute administrative commands, obtain confidential data, impersonate legitimate users of the application, and more.
CAPEC-695: Repo Jacking
An adversary takes advantage of the redirect property of directly linked Version Control System (VCS) repositories to trick users into incorporating malicious code into their applications.
CAPEC-698: Install Malicious Extension
An adversary directly installs or tricks a user into installing a malicious extension into existing trusted software, with the goal of achieving a variety of negative technical impacts.