GitHub Security Advisory: GHSA-xqq2-4j46-vwp7
Package: github.com/pinchtab/pinchtab (GO)
Severity: MODERATE (CVSS 4.1)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 0.8.3
Patched in: 0.8.4

Summary: PinchTab has Unauthenticated Blind SSRF in Task Scheduler via Unvalidated callbackUrl

Details:
### Summary
PinchTab v0.8.3 contains a server-side request forgery issue in the optional scheduler's webhook delivery path. When a task is submitted to `POST /tasks` with a user-controlled `callbackUrl`, the v0.8.3 scheduler sends an outbound HTTP `POST` to that URL when the task reaches a terminal state. In that release, the webhook path validated only the URL scheme and did not reject loopback, private, link-local, or other non-public destinations.

Because the v0.8.3 implementation also used the default HTTP client behavior, redirects were followed and the destination was not pinned to validated IPs. This allowed blind SSRF from the PinchTab server to attacker-chosen HTTP(S) targets reachable from the server.

This issue is narrower than a general unauthenticated internet-facing SSRF. The scheduler is optional and off by default, and in token-protected deployments the attacker must already be able to submit tasks using the server's master API token. In PinchTab's intended deployment model, that token represents administrative control rather than a low-privilege role. Tokenless deployments lower the barrier further, but that is a separate insecure configuration state rather than impact created by the webhook bug itself.

PinchTab's default deployment model is local-first and user-controlled, with loopback bind and token-based access in the recommended setup. That lowers practical risk in default use, even though it does not remove the underlying webhook issue when the scheduler is enabled and reachable.

This was addressed in v0.8.4 by validating callback targets before dispatch, rejecting non-public IP ranges, pinning delivery to validated IPs, disabling redirect following, and validating `callbackUrl` during task submission.

### Details
**Issue 1 - Webhook dispatch validated only scheme in v0.8.3 (`internal/scheduler/webhook.go`):**
The vulnerable `sendWebhook()` implementation accepted any `http` or `https` URL and dispatched the outbound request without destination IP validation:

```go
// internal/scheduler/webhook.go - v0.8.3
parsed, err := url.Parse(callbackURL)
if parsed.Scheme != "http" && parsed.Scheme != "https" {
    slog.Warn("webhook: unsupported scheme", ...)
    return
}

req, _ := http.NewRequest(http.MethodPost, callbackURL, bytes.NewReader(payload))
resp, err := webhookClient.Do(req)
```

In v0.8.3 there was no hostname resolution and no rejection of loopback, private, link-local, or other non-public addresses before dispatch.

**Issue 2 - `callbackUrl` was accepted without server-side validation in v0.8.3 (`internal/scheduler/task.go`):**
The task submission schema accepted a user-controlled `callbackUrl`, and the v0.8.3 request validation logic did not validate it:

```go
// internal/scheduler/task.go - v0.8.3
type SubmitRequest struct {
    AgentID     string         `json:"agentId"`
    Action      string         `json:"action"`
    CallbackURL string         `json:"callbackUrl,omitempty"`
}

func (r *SubmitRequest) Vali