@grackle-ai/server JSON.parse lacks try-catch logic in its gRPC Service AdapterConfig Handling
### Impact
`JSON.parse(env.adapterConfig)` is called without error handling in three locations within the gRPC service. While the data originates from the server's own SQLite database and should always be valid JSON, database corruption, migration errors, or unexpected state could cause an unhandled exception that crashes the gRPC handler.
Additionally, the parsed result is cast as `Record<string, unknown>` and passed to adapter methods without property validation, creating a theoretical prototype pollution surface if the database is compromised.
**Affected code:**
- `packages/server/src/grpc-service.ts:415` — `reconnectOrProvision` handle
@grackle-ai/server has a Missing Secure Flag on Session Cookie
### Impact
The session cookie is set with `HttpOnly; SameSite=Lax; Path=/` but does not include the `Secure` flag. This means the cookie will be sent over plain HTTP connections.
Since the server binds to `127.0.0.1` by default and uses HTTP (not HTTPS), this is acceptable for localhost use. However, when `--allow-network` is used to bind to `0.0.0.0`, cookies could be transmitted over insecure network connections and intercepted by an attacker.
**Affected code:**
- `packages/server/src/session.ts:76` — cookie string lacks `; Secure` attribute
### Patches
0.70.5
**Fix:** Conditionally add `; Secure` when served over HTTPS or when `--all
@grackle-ai/server has Missing Content-Security-Policy and X-Frame-Options Headers
### Impact
The HTTP server does not set `Content-Security-Policy`, `X-Frame-Options`, or `X-Content-Type-Options` headers on any response. This reduces defense-in-depth against XSS, clickjacking, and MIME-sniffing attacks.
While the current XSS attack surface is small (React-markdown is configured safely, no `dangerouslySetInnerHTML`, Vite does not generate source maps), the absence of these headers means any future XSS vulnerability would have no secondary defense layer.
**Affected code:**
- `packages/server/src/index.ts` — all `res.writeHead()` calls only set `Content-Type`, with no security headers
### Patches
0.70.4
**Fix:** Add sec
@grackle-ai/server has Missing WebSocket Origin Header Validation
### Impact
The WebSocket upgrade handler in the server validates authentication (API key token or session cookie) but does not check the `Origin` header. A malicious webpage on a different origin could initiate a WebSocket connection to `ws://localhost:3000/ws` if it can leverage the user's session cookie (which is `SameSite=Lax`, allowing top-level navigations).
This enables **cross-origin WebSocket hijacking** — if a user visits a malicious site while a Grackle session is active, the attacker's page could open a WebSocket and subscribe to real-time events (session output, task updates, environment state).
**Affected code:**
- `packages/s
@grackle-ai/server: Unescaped Error String in renderPairingPage() HTML Template
### Impact
The `renderPairingPage()` function embeds the `error` parameter directly into HTML without escaping:
```typescript
const errorHtml = error ? `<p style="color:#e74c3c">${error}</p>` : "";
```
All current call sites pass hardcoded strings, so this is **not exploitable today**. However, the function is architecturally fragile — if a future code change passes user-controlled or dynamic content into the error parameter, it would create an XSS vulnerability.
The `renderAuthorizePage()` function in the same file correctly uses `escapeHtml()` for dynamic content, making this an inconsistency.
**Affected code:**
- `packages/server/src/i