Common Weakness Enumeration

CWE-178

Allowed

Improper Handling of Case Sensitivity

Abstraction: Base · Status: Incomplete

The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results.

141 vulnerabilities reference this CWE, most recent first.

GHSA-XRMC-C5CG-RV7X

Vulnerability from github – Published: 2026-07-10 19:34 – Updated: 2026-07-10 19:34
VLAI
Summary
SafeInstall agent guard shell parsing can miss raw package execution
Details

Summary

SafeInstall CLI through 0.10.1 can fail to recognize some package-manager and registry-runner commands in its agent guard. Case-variant launcher names, leading file-descriptor redirections, and supported shell wrappers with options can cause a raw install command to receive no guard decision. Remote project scaffolding through package-manager create/init commands can also avoid the approval decision used for other registry runners.

Impact

When the SafeInstall guard is installed for a coding agent, a crafted shell command can bypass the intended deny or ask response. The coding agent may then run a package installation or registry-provided scaffolding command without SafeInstall policy evaluation and without SafeInstall enforcing disabled lifecycle scripts.

Exploitation requires a coding agent to act on attacker-influenced instructions and issue the crafted shell command. A successful malicious package or runner can execute with the permissions of the developer account, affecting the confidentiality, integrity, and availability of local source code, credentials, and development resources.

The vulnerability is limited to guard interception. Commands already routed through the SafeInstall CLI continue to receive normal policy evaluation.

Affected versions

  • safeinstall-cli <= 0.10.1

Patched version

  • safeinstall-cli 0.10.2

Fix

Version 0.10.2:

  • normalizes package-manager and wrapper launcher names for detection and rewriting;
  • parses leading redirections before classifying the command;
  • handles supported wrapper option arity conservatively and fails closed on ambiguous embedded command syntax;
  • routes remote create/init scaffolding through the registry-runner approval path;
  • preserves SafeInstall routing for path-qualified package-manager invocations.

The patch includes a permanent regression corpus, table-driven parser characterization, an independent reference detector, and deterministic fuzz invariants. The integrated release candidate passed 626 tests, package smoke validation, and a one-million-command fuzz campaign with zero invariant violations.

Mitigation

Upgrade to safeinstall-cli 0.10.2 or later.

Until an upgrade is possible, manually review every coding-agent shell command and prevent the agent from invoking package managers or registry runners directly. Running an affected guard does not make raw package-manager execution safe.

Credits

Discovered, reproduced, and remediated by the SafeInstall maintainer during adversarial parser testing.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "safeinstall-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.10.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-178",
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-10T19:34:14Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nSafeInstall CLI through 0.10.1 can fail to recognize some package-manager and registry-runner commands in its agent guard. Case-variant launcher names, leading file-descriptor redirections, and supported shell wrappers with options can cause a raw install command to receive no guard decision. Remote project scaffolding through package-manager create/init commands can also avoid the approval decision used for other registry runners.\n\n## Impact\n\nWhen the SafeInstall guard is installed for a coding agent, a crafted shell command can bypass the intended deny or ask response. The coding agent may then run a package installation or registry-provided scaffolding command without SafeInstall policy evaluation and without SafeInstall enforcing disabled lifecycle scripts.\n\nExploitation requires a coding agent to act on attacker-influenced instructions and issue the crafted shell command. A successful malicious package or runner can execute with the permissions of the developer account, affecting the confidentiality, integrity, and availability of local source code, credentials, and development resources.\n\nThe vulnerability is limited to guard interception. Commands already routed through the SafeInstall CLI continue to receive normal policy evaluation.\n\n## Affected versions\n\n- safeinstall-cli \u003c= 0.10.1\n\n## Patched version\n\n- safeinstall-cli 0.10.2\n\n## Fix\n\nVersion 0.10.2:\n\n- normalizes package-manager and wrapper launcher names for detection and rewriting;\n- parses leading redirections before classifying the command;\n- handles supported wrapper option arity conservatively and fails closed on ambiguous embedded command syntax;\n- routes remote create/init scaffolding through the registry-runner approval path;\n- preserves SafeInstall routing for path-qualified package-manager invocations.\n\nThe patch includes a permanent regression corpus, table-driven parser characterization, an independent reference detector, and deterministic fuzz invariants. The integrated release candidate passed 626 tests, package smoke validation, and a one-million-command fuzz campaign with zero invariant violations.\n\n## Mitigation\n\nUpgrade to safeinstall-cli 0.10.2 or later.\n\nUntil an upgrade is possible, manually review every coding-agent shell command and prevent the agent from invoking package managers or registry runners directly. Running an affected guard does not make raw package-manager execution safe.\n\n## Credits\n\nDiscovered, reproduced, and remediated by the SafeInstall maintainer during adversarial parser testing.",
  "id": "GHSA-xrmc-c5cg-rv7x",
  "modified": "2026-07-10T19:34:14Z",
  "published": "2026-07-10T19:34:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Mickdownunder/SafeInstall/security/advisories/GHSA-xrmc-c5cg-rv7x"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Mickdownunder/SafeInstall"
    }
  ],
  "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": "SafeInstall agent guard shell parsing can miss raw package execution"
}

Mitigation MIT-44
Architecture and Design

Strategy: Input Validation

Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.

Mitigation MIT-5
Implementation

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.
Mitigation MIT-20
Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

No CAPEC attack patterns related to this CWE.