How severe is GHSA-gj6x-q8rh-wj6x?

No CVSS score has been assigned to GHSA-gj6x-q8rh-wj6x yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-gj6x-q8rh-wj6x?

GHSA-gj6x-q8rh-wj6x affects the following packages: github.com/filecoin-project/curio (Go). Ecosystems affected: Go.

How do I fix GHSA-gj6x-q8rh-wj6x?

Update github.com/filecoin-project/curio to 1.27.3-rc2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-gj6x-q8rh-wj6x is resolved across your whole dependency graph.

How do I detect GHSA-gj6x-q8rh-wj6x in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/filecoin-project/curio. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-gj6x-q8rh-wj6x if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-gj6x-q8rh-wj6x?

O3 pinpoints whether GHSA-gj6x-q8rh-wj6x is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-gj6x-q8rh-wj6x actively exploited in the wild?

No public exploit code has been indexed for GHSA-gj6x-q8rh-wj6x yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-gj6x-q8rh-wj6x published, and has it been updated?

GHSA-gj6x-q8rh-wj6x was published on February 26, 2026 and was last updated on March 23, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹 Go

GHSA-gj6x-q8rh-wj6x

Curio exposes database credentials to users with network access through verbose HTTP error responses

Also known asGO-2026-4568

Published

Feb 26, 2026

Updated

Mar 23, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Blast Radius

1 pkg affected

🐹github.com/filecoin-project/curio

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

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:

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.
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.
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 database, which serves as Curio's control plane.

Per Curio's security boundary documentation, these endpoints are expected to be on a trusted network. However, defense-in-depth requires that credentials are never exposed through HTTP responses regardless of network trust assumptions.

Remediation (PR #919)

Connection string password masking: The password in the connection string is replaced with ********. The real password is set separately via cfg.ConnConfig.Password, so it never appears in error messages or logs.
HTTP handler sanitization: All affected handlers now log the detailed error server-side and return a generic error message to the HTTP client.
Error filter (errFilter): A new function in the database layer detects and redacts any error messages containing keywords like "password", "host", "port", or "://" before they can propagate.
Prometheus metrics cleanup: Database connection metrics that could expose connection details were removed from the metrics endpoint.
Security boundary documentation: A new section documents what Curio expects operators to secure.

Resources

Fix: https://github.com/filecoin-project/curio/pull/919
Patched release: v1.27.3-rc2

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/filecoin-project/curio`	≥ 1.24.3&&< 1.27.3-rc2	1.27.3-rc2

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/filecoin-project/curio. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/filecoin-project/curio to 1.27.3-rc2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-gj6x-q8rh-wj6x is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-gj6x-q8rh-wj6x is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-gj6x-q8rh-wj6x. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## 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()` dire

O3 Security · Impact-Aware SCA

Is GHSA-gj6x-q8rh-wj6x in your dependencies?

O3 detects GHSA-gj6x-q8rh-wj6x across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works