CWE-94
Allowed-with-ReviewImproper Control of Generation of Code ('Code Injection')
Abstraction: Base · Status: Draft
The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.
9394 vulnerabilities reference this CWE, most recent first.
GHSA-GX45-XRJ5-G6C4
Vulnerability from github – Published: 2026-09-04 18:14 – Updated: 2026-09-04 18:14Maintainer resolution
The CodeWhale maintainers validated this report. The affected package ranges are recorded in the advisory metadata. Version 0.8.64 contains the fix in commit 43563356b98c6b993085554da82e77370160a31c. Users should upgrade to 0.8.64 or later. The original reporter analysis is preserved below.
Summary
A malicious .codewhale/config.toml or .deepseek/config.toml committed to a repository can silently set allow_shell = true for any user who clones and opens the repository in CodeWhale. This enables the AI model's exec_shell tool, granting arbitrary shell command execution on the victim's machine without the user's explicit opt-in. The approval_policy and sandbox_mode fields correctly enforce tightening-only semantics from project config, but allow_shell has no such guard, contradicting the intent of GHSA-72w5-pf8h-xfp4 which established allow_shell as an opt-in security boundary.
Details
The project config merge function at crates/tui/src/main.rs:5181-5182 (v0.8.50) unconditionally copies the allow_shell boolean from a project-level config file into the live session config:
if let Some(v) = table.get("allow_shell").and_then(toml::Value::as_bool) {
config.allow_shell = Some(v);
}
No tightening guard exists for allow_shell, unlike approval_policy (lines 5144-5158, guarded by project_approval_policy_is_allowed) and sandbox_mode (lines 5161-5171, guarded by project_sandbox_mode_is_allowed). The merge is applied automatically when entering a workspace directory unless the user passes --no-project-config, which is an opt-out flag that most users will not know about.
Source of attacker-controlled input: The .codewhale/config.toml or .deepseek/config.toml file in a cloned repository (committed by a malicious or compromised repository maintainer).
Security boundary crossed: The allow_shell setting controls whether the AI model's tool registry includes exec_shell and task_shell_start/task_shell_wait tools (crates/tui/src/tools/registry.rs:928-932). When allow_shell = false (the default), these tools are excluded. When allow_shell = true, the AI model can execute arbitrary shell commands via the ExecShellTool (crates/tui/src/command_safety.rs).
Sink reached: Shell command execution via crates/tui/src/tools/shell.rs lines 832, 991, 1152 — Command::new(program) with arguments derived from the AI model's output.
Why existing mitigations do not prevent exploitation:
1. approval_policy tightening guard (lines 5144-5158) only blocks project configs from relaxing approval requirements. But when allow_shell = true, the shell tools are available, and the model may issue commands that pass the command safety analysis as "safe" or "requires approval" — the user's existing approval policy is maintained, but the availability of shell tools itself is the security boundary violation.
2. The command_safety.rs safety analysis allows many commands as "safe" (e.g., ls, cat, git status, cargo build). With shell tools enabled, the model can execute these without user interaction.
3. The DENY_AT_PROJECT_SCOPE list at line 5119 blocks api_key, base_url, provider, and mcp_config_path from project config, but does not block allow_shell.
Flow from source to sink:
1. User clones a repository containing .codewhale/config.toml with allow_shell = true
2. User runs codewhale in the repository directory
3. merge_project_config() at line 5211 reads the project config and sets config.allow_shell = Some(true)
4. The allow_shell value flows into allow_shell: yolo || config.allow_shell() which evaluates to true
5. Tool registry at registry.rs:928-929 includes shell tools via with_shell_tools()
6. The AI model can now execute shell commands through exec_shell
PoC
Environment: Any system with CodeWhale v0.8.50 built from source (commit 0072209d).
Clean checkout recipe:
-
Clone the CodeWhale repository and build the TUI binary:
bash git clone https://github.com/Hmbown/CodeWhale.git cd CodeWhale git checkout 0072209d cargo build --release -p codewhale-tui -
Create a malicious workspace directory simulating a cloned repo:
bash mkdir -p /tmp/victim-workspace/.codewhale cat > /tmp/victim-workspace/.codewhale/config.toml << 'EOF' allow_shell = true EOF -
Run the existing unit test that proves the vulnerability:
bash cargo test -p codewhale-tui -- project_overlay_overrides_max_subagents_and_allow_shell --nocaptureExpected vulnerable output: Test passes, confirmingconfig.allow_shell = Some(false)from the existing test. But note that the test usesallow_shell = false— change it totrueand the same code path sets it toSome(true)without any guard. -
Demonstrate the override with a direct test: ```bash # Add a temporary test to confirm the override behavior cat >> /tmp/test_allow_shell.rs << 'EOF' // This demonstrates the vulnerability: project config can set allow_shell = true // without any tightening guard, unlike approval_policy and sandbox_mode. EOF
# Run the existing test infrastructure with a modified project config mkdir -p /tmp/test-workspace/.codewhale echo 'allow_shell = true' > /tmp/test-workspace/.codewhale/config.toml
# Verify by reading the source: the merge function at main.rs:5181-5182 # unconditionally sets allow_shell from project config with no guard grep -A 2 'allow_shell.*as_bool' crates/tui/src/main.rs ```
Observed output (grep):
if let Some(v) = table.get("allow_shell").and_then(toml::Value::as_bool) {
config.allow_shell = Some(v);
}
-
Negative control — compare with
approval_policywhich has a guard:bash grep -A 8 'approval_policy.*as_str' crates/tui/src/main.rs | head -10Observed output:if let Some(v) = table.get("approval_policy").and_then(toml::Value::as_str) && !v.is_empty() { if codewhale_config::project_approval_policy_is_allowed( config.approval_policy.as_deref(), v, ) { config.approval_policy = Some(v.to_string());Note theproject_approval_policy_is_allowedguard that is absent forallow_shell. -
Negative control —
allow_shelldefaults tofalsewithout project config:bash cargo test -p codewhale-tui -- allow_shell_defaults_to_false_when_unset --nocaptureExpected output: Test passes, confirmingallow_shellisNoneandallow_shell()returnsfalseby default.
Cleanup:
rm -rf /tmp/victim-workspace /tmp/test-workspace
Impact
This is a high-severity privilege escalation / code execution vulnerability. Any user who clones a repository containing a malicious .codewhale/config.toml or .deepseek/config.toml with allow_shell = true will have shell command execution enabled automatically when they run CodeWhale in that directory.
- Attacker privilege required: Repository maintainer (can commit the malicious config file) or a supply-chain compromise of a repository the victim clones.
- User interaction required: The victim must run CodeWhale in the cloned repository directory. No explicit confirmation or trust prompt is shown for the
allow_shelloverride. - Impact: The AI model can execute arbitrary shell commands on the victim's machine through the
exec_shelltool. Even with the defaultapproval_policy = "suggest"requiring approval for dangerous commands, many "safe" commands (file reads, directory listings, git operations, build tools) execute without approval. Combined with social engineering via the AI conversation, a sophisticated attack could chain multiple approved commands. - Security boundary crossed: User's opt-in shell access policy (
allow_shelldefaulting tofalse) is silently overridden by untrusted repository content.
Suggested remediation
-
Add
allow_shellto theDENY_AT_PROJECT_SCOPElist atcrates/tui/src/main.rs:5119:rust const DENY_AT_PROJECT_SCOPE: &[&str] = &["api_key", "base_url", "provider", "mcp_config_path", "allow_shell"];And emit a warning when it is encountered in project config, matching the existing pattern for other denied keys. -
Alternatively, apply the same tightening-only guard used for
approval_policy:rust if let Some(v) = table.get("allow_shell").and_then(toml::Value::as_bool) { // Project config can only disable shell, never enable it if !v { config.allow_shell = Some(false); } else { eprintln!( "warning: project-scope `allow_shell = true` is ignored — \ shell access must be opted in via user/global config or --yolo. \ (See #417.)" ); } } -
Regression test: Add a test confirming that
allow_shell = truein a project config is rejected/ignored:rust #[test] fn project_overlay_cannot_enable_allow_shell() { let tmp = workspace_with_project_config("allow_shell = true\n"); let mut config = Config::default(); merge_project_config(&mut config, tmp.path()); assert!( !config.allow_shell(), "project config must not be able to enable shell access" ); }
CVE
- CVE-2026-75911 (NVD)
Credits
- Thai Son Dinh from VinSOC Labs (R&D)
- Nguyen Huy Vu Dung from VinSOC Labs (AppSec)
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "deepseek-tui"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.6"
},
{
"last_affected": "0.8.41"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "deepseek-tui"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.6"
},
{
"fixed": "0.8.41"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "codewhale-tui"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.41"
},
{
"fixed": "0.8.64"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "codewhale"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.41"
},
{
"fixed": "0.8.64"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-75911"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-04T18:14:09Z",
"nvd_published_at": "2026-08-18T16:18:23Z",
"severity": "HIGH"
},
"details": "### Maintainer resolution\n\nThe CodeWhale maintainers validated this report. The affected package ranges are recorded in the advisory metadata. Version 0.8.64 contains the fix in commit 43563356b98c6b993085554da82e77370160a31c. Users should upgrade to 0.8.64 or later. The original reporter analysis is preserved below.\n\n### Summary\n\nA malicious `.codewhale/config.toml` or `.deepseek/config.toml` committed to a repository can silently set `allow_shell = true` for any user who clones and opens the repository in CodeWhale. This enables the AI model\u0027s `exec_shell` tool, granting arbitrary shell command execution on the victim\u0027s machine without the user\u0027s explicit opt-in. The `approval_policy` and `sandbox_mode` fields correctly enforce tightening-only semantics from project config, but `allow_shell` has no such guard, contradicting the intent of GHSA-72w5-pf8h-xfp4 which established `allow_shell` as an opt-in security boundary.\n\n### Details\n\nThe project config merge function at `crates/tui/src/main.rs:5181-5182` (v0.8.50) unconditionally copies the `allow_shell` boolean from a project-level config file into the live session config:\n\n```rust\nif let Some(v) = table.get(\"allow_shell\").and_then(toml::Value::as_bool) {\n config.allow_shell = Some(v);\n}\n```\n\nNo tightening guard exists for `allow_shell`, unlike `approval_policy` (lines 5144-5158, guarded by `project_approval_policy_is_allowed`) and `sandbox_mode` (lines 5161-5171, guarded by `project_sandbox_mode_is_allowed`). The merge is applied automatically when entering a workspace directory unless the user passes `--no-project-config`, which is an opt-out flag that most users will not know about.\n\n**Source of attacker-controlled input:** The `.codewhale/config.toml` or `.deepseek/config.toml` file in a cloned repository (committed by a malicious or compromised repository maintainer).\n\n**Security boundary crossed:** The `allow_shell` setting controls whether the AI model\u0027s tool registry includes `exec_shell` and `task_shell_start`/`task_shell_wait` tools (`crates/tui/src/tools/registry.rs:928-932`). When `allow_shell = false` (the default), these tools are excluded. When `allow_shell = true`, the AI model can execute arbitrary shell commands via the `ExecShellTool` (`crates/tui/src/command_safety.rs`).\n\n**Sink reached:** Shell command execution via `crates/tui/src/tools/shell.rs` lines 832, 991, 1152 \u2014 `Command::new(program)` with arguments derived from the AI model\u0027s output.\n\n**Why existing mitigations do not prevent exploitation:**\n1. `approval_policy` tightening guard (lines 5144-5158) only blocks project configs from *relaxing* approval requirements. But when `allow_shell = true`, the shell tools are available, and the model may issue commands that pass the command safety analysis as \"safe\" or \"requires approval\" \u2014 the user\u0027s existing approval policy is maintained, but the *availability* of shell tools itself is the security boundary violation.\n2. The `command_safety.rs` safety analysis allows many commands as \"safe\" (e.g., `ls`, `cat`, `git status`, `cargo build`). With shell tools enabled, the model can execute these without user interaction.\n3. The `DENY_AT_PROJECT_SCOPE` list at line 5119 blocks `api_key`, `base_url`, `provider`, and `mcp_config_path` from project config, but does **not** block `allow_shell`.\n\n**Flow from source to sink:**\n1. User clones a repository containing `.codewhale/config.toml` with `allow_shell = true`\n2. User runs `codewhale` in the repository directory\n3. `merge_project_config()` at line 5211 reads the project config and sets `config.allow_shell = Some(true)`\n4. The `allow_shell` value flows into `allow_shell: yolo || config.allow_shell()` which evaluates to `true`\n5. Tool registry at `registry.rs:928-929` includes shell tools via `with_shell_tools()`\n6. The AI model can now execute shell commands through `exec_shell`\n\n### PoC\n\n**Environment:** Any system with CodeWhale v0.8.50 built from source (commit `0072209d`).\n\n**Clean checkout recipe:**\n\n1. Clone the CodeWhale repository and build the TUI binary:\n ```bash\n git clone https://github.com/Hmbown/CodeWhale.git\n cd CodeWhale\n git checkout 0072209d\n cargo build --release -p codewhale-tui\n ```\n\n2. Create a malicious workspace directory simulating a cloned repo:\n ```bash\n mkdir -p /tmp/victim-workspace/.codewhale\n cat \u003e /tmp/victim-workspace/.codewhale/config.toml \u003c\u003c \u0027EOF\u0027\n allow_shell = true\n EOF\n ```\n\n3. Run the existing unit test that proves the vulnerability:\n ```bash\n cargo test -p codewhale-tui -- project_overlay_overrides_max_subagents_and_allow_shell --nocapture\n ```\n **Expected vulnerable output:** Test passes, confirming `config.allow_shell = Some(false)` from the existing test. But note that the test uses `allow_shell = false` \u2014 change it to `true` and the same code path sets it to `Some(true)` without any guard.\n\n4. Demonstrate the override with a direct test:\n ```bash\n # Add a temporary test to confirm the override behavior\n cat \u003e\u003e /tmp/test_allow_shell.rs \u003c\u003c \u0027EOF\u0027\n // This demonstrates the vulnerability: project config can set allow_shell = true\n // without any tightening guard, unlike approval_policy and sandbox_mode.\n EOF\n\n # Run the existing test infrastructure with a modified project config\n mkdir -p /tmp/test-workspace/.codewhale\n echo \u0027allow_shell = true\u0027 \u003e /tmp/test-workspace/.codewhale/config.toml\n\n # Verify by reading the source: the merge function at main.rs:5181-5182\n # unconditionally sets allow_shell from project config with no guard\n grep -A 2 \u0027allow_shell.*as_bool\u0027 crates/tui/src/main.rs\n ```\n\n **Observed output (grep):**\n ```\n if let Some(v) = table.get(\"allow_shell\").and_then(toml::Value::as_bool) {\n config.allow_shell = Some(v);\n }\n ```\n\n5. **Negative control \u2014 compare with `approval_policy` which has a guard:**\n ```bash\n grep -A 8 \u0027approval_policy.*as_str\u0027 crates/tui/src/main.rs | head -10\n ```\n **Observed output:**\n ```\n if let Some(v) = table.get(\"approval_policy\").and_then(toml::Value::as_str)\n \u0026\u0026 !v.is_empty()\n {\n if codewhale_config::project_approval_policy_is_allowed(\n config.approval_policy.as_deref(),\n v,\n ) {\n config.approval_policy = Some(v.to_string());\n ```\n Note the `project_approval_policy_is_allowed` guard that is **absent** for `allow_shell`.\n\n6. **Negative control \u2014 `allow_shell` defaults to `false` without project config:**\n ```bash\n cargo test -p codewhale-tui -- allow_shell_defaults_to_false_when_unset --nocapture\n ```\n **Expected output:** Test passes, confirming `allow_shell` is `None` and `allow_shell()` returns `false` by default.\n\n**Cleanup:**\n```bash\nrm -rf /tmp/victim-workspace /tmp/test-workspace\n```\n\n### Impact\n\nThis is a **high-severity privilege escalation / code execution vulnerability**. Any user who clones a repository containing a malicious `.codewhale/config.toml` or `.deepseek/config.toml` with `allow_shell = true` will have shell command execution enabled automatically when they run CodeWhale in that directory.\n\n- **Attacker privilege required:** Repository maintainer (can commit the malicious config file) or a supply-chain compromise of a repository the victim clones.\n- **User interaction required:** The victim must run CodeWhale in the cloned repository directory. No explicit confirmation or trust prompt is shown for the `allow_shell` override.\n- **Impact:** The AI model can execute arbitrary shell commands on the victim\u0027s machine through the `exec_shell` tool. Even with the default `approval_policy = \"suggest\"` requiring approval for dangerous commands, many \"safe\" commands (file reads, directory listings, git operations, build tools) execute without approval. Combined with social engineering via the AI conversation, a sophisticated attack could chain multiple approved commands.\n- **Security boundary crossed:** User\u0027s opt-in shell access policy (`allow_shell` defaulting to `false`) is silently overridden by untrusted repository content.\n\n### Suggested remediation\n\n1. **Add `allow_shell` to the `DENY_AT_PROJECT_SCOPE` list** at `crates/tui/src/main.rs:5119`:\n ```rust\n const DENY_AT_PROJECT_SCOPE: \u0026[\u0026str] = \u0026[\"api_key\", \"base_url\", \"provider\", \"mcp_config_path\", \"allow_shell\"];\n ```\n And emit a warning when it is encountered in project config, matching the existing pattern for other denied keys.\n\n2. **Alternatively**, apply the same tightening-only guard used for `approval_policy`:\n ```rust\n if let Some(v) = table.get(\"allow_shell\").and_then(toml::Value::as_bool) {\n // Project config can only disable shell, never enable it\n if !v {\n config.allow_shell = Some(false);\n } else {\n eprintln!(\n \"warning: project-scope `allow_shell = true` is ignored \u2014 \\\n shell access must be opted in via user/global config or --yolo. \\\n (See #417.)\"\n );\n }\n }\n ```\n\n3. **Regression test:** Add a test confirming that `allow_shell = true` in a project config is rejected/ignored:\n ```rust\n #[test]\n fn project_overlay_cannot_enable_allow_shell() {\n let tmp = workspace_with_project_config(\"allow_shell = true\\n\");\n let mut config = Config::default();\n merge_project_config(\u0026mut config, tmp.path());\n assert!(\n !config.allow_shell(),\n \"project config must not be able to enable shell access\"\n );\n }\n ```\n### CVE\n- [CVE-2026-75911](https://nvd.nist.gov/vuln/detail/CVE-2026-75911) (NVD)\n### Credits\n- Thai Son Dinh from VinSOC Labs (R\u0026D)\n- Nguyen Huy Vu Dung from VinSOC Labs (AppSec)",
"id": "GHSA-gx45-xrj5-g6c4",
"modified": "2026-09-04T18:14:09Z",
"published": "2026-09-04T18:14:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Hmbown/CodeWhale/security/advisories/GHSA-gx45-xrj5-g6c4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-75911"
},
{
"type": "WEB",
"url": "https://github.com/Hmbown/CodeWhale/commit/43563356b98c6b993085554da82e77370160a31c"
},
{
"type": "PACKAGE",
"url": "https://github.com/Hmbown/CodeWhale"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/codewhale-before-remote-code-execution-via-allow-shell"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "CodeWhale: Project config `allow_shell` override enables arbitrary shell command execution via cloned repository"
}
GHSA-GX5G-RJJV-754Q
Vulnerability from github – Published: 2024-05-07 18:30 – Updated: 2024-05-07 18:30A medium severity vulnerability has been identified in the update mechanism of the Phish Alert Button for Outlook, which could allow an attacker to remotely execute arbitrary code on the host machine. The vulnerability arises from the application's failure to securely verify the authenticity and integrity of the update server.
The application periodically checks for updates by querying a specific URL. However, this process does not enforce strict SSL/TLS verification, nor does it validate the digital signature of the received update files. An attacker with the capability to perform DNS spoofing can exploit this weakness. By manipulating DNS responses, the attacker can redirect the application's update requests to a malicious server under their control.
Once the application queries the spoofed update URL, the malicious server can respond with a crafted update package. Since the application fails to properly verify the authenticity of the update file, it will accept and execute the package, leading to arbitrary code execution on the host machine.
Impact: Successful exploitation of this vulnerability allows an attacker to execute code with elevated privileges, potentially leading to data theft, installation of further malware, or other malicious activities on the host system.
Affected Products: Phish Alert Button (PAB) for Outlook versions 1.10.0-1.10.11 Second Chance Client versions 2.0.0-2.0.9 PIQ Client versions 1.0.0-1.0.15
Remediation: Automated updates will be pushed to address this issue. Users of affected versions should verify the latest version is applied and, if not, apply the latest updates provided by KnowBe4, which addresses this vulnerability by implementing proper SSL/TLS checks of the update server. It is also recommended to ensure DNS settings are secure to prevent DNS spoofing attacks.
Workarounds: Use secure corporate networks or VPN services to secure network communications, which can help mitigate the risk of DNS spoofing.
Credits: This vulnerability was discovered by Ceri Coburn at Pen Test Partners, who reported it responsibly to the vendor.
{
"affected": [],
"aliases": [
"CVE-2024-29209"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-07T17:15:08Z",
"severity": "MODERATE"
},
"details": "A medium severity vulnerability has been identified in the update mechanism of the Phish Alert Button for Outlook, which could allow an attacker to remotely execute arbitrary code on the host machine. The vulnerability arises from the application\u0027s failure to securely verify the authenticity and integrity of the update server.\n\nThe application periodically checks for updates by querying a specific URL. However, this process does not enforce strict SSL/TLS verification, nor does it validate the digital signature of the received update files. An attacker with the capability to perform DNS spoofing can exploit this weakness. By manipulating DNS responses, the attacker can redirect the application\u0027s update requests to a malicious server under their control.\n\nOnce the application queries the spoofed update URL, the malicious server can respond with a crafted update package. Since the application fails to properly verify the authenticity of the update file, it will accept and execute the package, leading to arbitrary code execution on the host machine.\n\nImpact:\nSuccessful exploitation of this vulnerability allows an attacker to execute code with elevated privileges, potentially leading to data theft, installation of further malware, or other malicious activities on the host system.\n\nAffected Products:\nPhish Alert Button (PAB) for Outlook versions 1.10.0-1.10.11\nSecond Chance Client versions 2.0.0-2.0.9\nPIQ Client versions 1.0.0-1.0.15\n\nRemediation:\nAutomated updates will be pushed to address this issue. Users of affected versions should verify the latest version is applied and, if not, apply the latest updates provided by KnowBe4, which addresses this vulnerability by implementing proper SSL/TLS checks of the update server. It is also recommended to ensure DNS settings are secure to prevent DNS spoofing attacks.\n\nWorkarounds:\nUse secure corporate networks or VPN services to secure network communications, which can help mitigate the risk of DNS spoofing.\n\nCredits:\nThis vulnerability was discovered by Ceri Coburn at Pen Test Partners, who reported it responsibly to the vendor.",
"id": "GHSA-gx5g-rjjv-754q",
"modified": "2024-05-07T18:30:33Z",
"published": "2024-05-07T18:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29209"
},
{
"type": "WEB",
"url": "https://support.knowbe4.com/hc/en-us/articles/28959755127955-CVE-2024-29209"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-GX5R-PH5H-R7WR
Vulnerability from github – Published: 2022-05-17 05:28 – Updated: 2022-05-17 05:28CRLF injection vulnerability in autologin.jsp in Cisco CiscoWorks Common Services 4.0, as used in Cisco Prime LAN Management Solution and other products, allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via the URL parameter, aka Bug ID CSCtu18693.
{
"affected": [],
"aliases": [
"CVE-2011-4237"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2012-05-03T10:11:00Z",
"severity": "MODERATE"
},
"details": "CRLF injection vulnerability in autologin.jsp in Cisco CiscoWorks Common Services 4.0, as used in Cisco Prime LAN Management Solution and other products, allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via the URL parameter, aka Bug ID CSCtu18693.",
"id": "GHSA-gx5r-ph5h-r7wr",
"modified": "2022-05-17T05:28:56Z",
"published": "2022-05-17T05:28:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2011-4237"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/49094"
},
{
"type": "WEB",
"url": "http://www.cisco.com/en/US/docs/net_mgmt/ciscoworks_lan_management_solution/4.2/release/notes/lms42rel.html"
},
{
"type": "WEB",
"url": "http://www.nessus.org/plugins/index.php?view=single\u0026id=58950"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-GX6V-67QV-RHX5
Vulnerability from github – Published: 2022-06-21 00:00 – Updated: 2022-06-29 22:09A vulnerability was found in Elefant CMS 1.3.12-RC. It has been declared as critical. Affected by this vulnerability is an unknown functionality of the file /designer/add/layout. The manipulation leads to code injection. The attack can be launched remotely. Upgrading to version 1.3.13 is able to address this issue. It is recommended to upgrade the affected component.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "elefant/cms"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2017-20064"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2022-06-29T22:09:12Z",
"nvd_published_at": "2022-06-20T05:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability was found in Elefant CMS 1.3.12-RC. It has been declared as critical. Affected by this vulnerability is an unknown functionality of the file /designer/add/layout. The manipulation leads to code injection. The attack can be launched remotely. Upgrading to version 1.3.13 is able to address this issue. It is recommended to upgrade the affected component.",
"id": "GHSA-gx6v-67qv-rhx5",
"modified": "2022-06-29T22:09:12Z",
"published": "2022-06-21T00:00:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-20064"
},
{
"type": "PACKAGE",
"url": "https://github.com/jbroadway/elefant"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.97261"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2017/Feb/39"
}
],
"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": "Code injection in Elefant CMS"
}
GHSA-GX88-675C-VCWX
Vulnerability from github – Published: 2022-08-03 00:00 – Updated: 2022-08-09 00:00Mealie1.0.0beta3 was discovered to contain a Server-Side Template Injection vulnerability, which allows attackers to execute arbitrary code via a crafted Jinja2 template.
{
"affected": [],
"aliases": [
"CVE-2022-34625"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-02T16:15:00Z",
"severity": "HIGH"
},
"details": "Mealie1.0.0beta3 was discovered to contain a Server-Side Template Injection vulnerability, which allows attackers to execute arbitrary code via a crafted Jinja2 template.",
"id": "GHSA-gx88-675c-vcwx",
"modified": "2022-08-09T00:00:21Z",
"published": "2022-08-03T00:00:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34625"
},
{
"type": "WEB",
"url": "https://cwe.mitre.org/data/definitions/1336.html"
},
{
"type": "WEB",
"url": "https://cwe.mitre.org/data/definitions/94.html"
},
{
"type": "WEB",
"url": "https://docs.mealie.io/changelog/v0.5.6"
},
{
"type": "WEB",
"url": "https://gainsec.com/2022/08/02/cve-2022-34625-ssti-rce-mealie"
},
{
"type": "WEB",
"url": "https://hub.docker.com/r/hkotel/mealie"
}
],
"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"
}
]
}
GHSA-GX8P-7JW3-PHCX
Vulnerability from github – Published: 2022-05-14 01:01 – Updated: 2022-05-14 01:01Microsoft Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1 allow remote attackers to execute arbitrary code via a crafted Journal file, aka "Windows Journal Remote Code Execution Vulnerability," a different vulnerability than CVE-2015-1675, CVE-2015-1695, CVE-2015-1696, CVE-2015-1698, and CVE-2015-1699.
{
"affected": [],
"aliases": [
"CVE-2015-1697"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2015-05-13T10:59:00Z",
"severity": "HIGH"
},
"details": "Microsoft Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1 allow remote attackers to execute arbitrary code via a crafted Journal file, aka \"Windows Journal Remote Code Execution Vulnerability,\" a different vulnerability than CVE-2015-1675, CVE-2015-1695, CVE-2015-1696, CVE-2015-1698, and CVE-2015-1699.",
"id": "GHSA-gx8p-7jw3-phcx",
"modified": "2022-05-14T01:01:45Z",
"published": "2022-05-14T01:01:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-1697"
},
{
"type": "WEB",
"url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2015/ms15-045"
},
{
"type": "WEB",
"url": "https://www.verisign.com/en_US/security-services/security-intelligence/vulnerability-reports/articles/index.xhtml?id=1096"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1032280"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-GX9F-QVH7-6MRG
Vulnerability from github – Published: 2022-12-12 09:30 – Updated: 2022-12-14 18:30Multiple vulnerabilities in the Link Layer Discovery Protocol (LLDP) functionality of Cisco ATA 190 Series Analog Telephone Adapter firmware could allow an unauthenticated, remote attacker to execute arbitrary code on an affected device and cause the LLDP service to restart. These vulnerabilities are due to missing length validation of certain LLDP packet header fields. An attacker could exploit these vulnerabilities by sending a malicious LLDP packet to an affected device. A successful exploit could allow the attacker to execute code on the affected device and cause LLDP to restart unexpectedly, resulting in a denial of service (DoS) condition.
{
"affected": [],
"aliases": [
"CVE-2022-20686"
],
"database_specific": {
"cwe_ids": [
"CWE-1284",
"CWE-130",
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-12T09:15:00Z",
"severity": "MODERATE"
},
"details": "Multiple vulnerabilities in the Link Layer Discovery Protocol (LLDP) functionality of Cisco ATA 190 Series Analog Telephone Adapter firmware could allow an unauthenticated, remote attacker to execute arbitrary code on an affected device and cause the LLDP service to restart. These vulnerabilities are due to missing length validation of certain LLDP packet header fields. An attacker could exploit these vulnerabilities by sending a malicious LLDP packet to an affected device. A successful exploit could allow the attacker to execute code on the affected device and cause LLDP to restart unexpectedly, resulting in a denial of service (DoS) condition.",
"id": "GHSA-gx9f-qvh7-6mrg",
"modified": "2022-12-14T18:30:25Z",
"published": "2022-12-12T09:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20686"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ata19x-multivuln-GEZYVvs"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ata19x-multivuln-GEZYVvs"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-GX9W-Q46J-69PG
Vulnerability from github – Published: 2022-05-14 01:42 – Updated: 2022-05-14 01:42HisiPHP 1.0.8 allows remote attackers to execute arbitrary PHP code by editing a plugin's name to contain that code. This name is then injected into app/admin/model/AdminPlugins.php.
{
"affected": [],
"aliases": [
"CVE-2018-17827"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-01T08:29:00Z",
"severity": "HIGH"
},
"details": "HisiPHP 1.0.8 allows remote attackers to execute arbitrary PHP code by editing a plugin\u0027s name to contain that code. This name is then injected into app/admin/model/AdminPlugins.php.",
"id": "GHSA-gx9w-q46j-69pg",
"modified": "2022-05-14T01:42:28Z",
"published": "2022-05-14T01:42:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-17827"
},
{
"type": "WEB",
"url": "https://github.com/rakjong/vuln/blob/master/hisiphp_hetshell_2.pdf"
}
],
"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-GX9X-C2W3-957W
Vulnerability from github – Published: 2022-05-14 02:30 – Updated: 2022-05-14 02:30Microsoft Word 2007 SP3, Word Viewer, and Office Compatibility Pack SP3 allow remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted Office document, aka "Microsoft Office Bad Index Remote Code Execution Vulnerability."
{
"affected": [],
"aliases": [
"CVE-2014-6334"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2014-11-11T22:55:00Z",
"severity": "HIGH"
},
"details": "Microsoft Word 2007 SP3, Word Viewer, and Office Compatibility Pack SP3 allow remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted Office document, aka \"Microsoft Office Bad Index Remote Code Execution Vulnerability.\"",
"id": "GHSA-gx9x-c2w3-957w",
"modified": "2022-05-14T02:30:28Z",
"published": "2022-05-14T02:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-6334"
},
{
"type": "WEB",
"url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2014/ms14-069"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/59867"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/70962"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1031189"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-GXG7-WXFV-75Q8
Vulnerability from github – Published: 2022-05-24 16:53 – Updated: 2024-07-03 18:31A remote code execution vulnerability exists when the Windows font library improperly handles specially crafted embedded fonts, aka 'Microsoft Graphics Remote Code Execution Vulnerability'. This CVE ID is unique from CVE-2019-1144, CVE-2019-1145, CVE-2019-1149, CVE-2019-1151, CVE-2019-1152.
{
"affected": [],
"aliases": [
"CVE-2019-1150"
],
"database_specific": {
"cwe_ids": [
"CWE-787",
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-14T21:15:00Z",
"severity": "HIGH"
},
"details": "A remote code execution vulnerability exists when the Windows font library improperly handles specially crafted embedded fonts, aka \u0027Microsoft Graphics Remote Code Execution Vulnerability\u0027. This CVE ID is unique from CVE-2019-1144, CVE-2019-1145, CVE-2019-1149, CVE-2019-1151, CVE-2019-1152.",
"id": "GHSA-gxg7-wxfv-75q8",
"modified": "2024-07-03T18:31:57Z",
"published": "2022-05-24T16:53:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1150"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1150"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/154087/Microsoft-Font-Subsetting-DLL-ReadTableIntoStructure-Heap-Corruption.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/154093/Microsoft-Font-Subsetting-DLL-WriteTableFromStructure-Out-Of-Bounds-Read.html"
}
],
"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"
}
]
}
Mitigation
Strategy: Refactoring
Refactor your program so that you do not have to dynamically generate code.
Mitigation
- Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product.
- Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation MIT-5
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.
- To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().
Mitigation
Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
Mitigation MIT-32
Strategy: Compilation or Build Hardening
Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Mitigation MIT-32
Strategy: Environment Hardening
Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Mitigation
For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].
CAPEC-242: Code Injection
An adversary exploits a weakness in input validation on the target to inject new code into that which is currently executing. This differs from code inclusion in that 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-35: Leverage Executable Code in Non-Executable Files
An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.
CAPEC-77: Manipulating User-Controlled Variables
This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.