GHSA-gj6x-q8rh-wj6x

## Summary Multiple HTTP handlers in Curio passed raw database error messages to HTTP clients via `http.Error()`. When the PostgreSQL/YugabyteDB driver (pgx) returned errors, these could contain the database connection string — including hostname, port, username, and password. Additionally, the internal connection string was constructed with the plaintext password embedded in the URL, which was also included in startup error messages and could surface in logs. ## Details Three components were affected: 1. **PDP handlers** (`pdp/handlers.go`) — 18+ HTTP error paths passed `err.Error()` directly to HTTP responses. While these endpoints require ECDSA JWT authentication, an authenticated client (e.g., a FilPay service) that triggered a database error would receive the raw pgx error in the HTTP response body. Present since PDP was introduced in v1.25.1. 2. **Market mk12 deal status** (`market/mk12/mk12_utils.go`) — The `GetDealStatus` handler included `err.Error()` in error responses: `"failed to query the db for deal status: %s"`. Present since v1.24.3. 3. **Market mk20 auth middleware** (`market/mk20/http/http.go`) — Authentication error responses included `err.Error()`, potentially leaking database error details during auth flows. Present since v1.27.2. ### Root Cause The database connection string was constructed as: ``` postgresql://username:password@host:port/database?... ``` The plaintext password was embedded directly in the URL. When pgx returned connection or query errors, the error text could contain fragments of this connection string. HTTP handlers forwarded these errors verbatim to clients. ## Impact An attacker with network access to Curio's PDP or Market HTTP endpoints and valid authentication credentials could intentionally trigger database errors (e.g., by sending malformed requests that cause SQL failures) and extract the YugabyteDB connection credentials from the error response. With these credentials, the attacker could directly access the