Summary
Curio exposes database credentials to users with network access through verbose HTTP error responses
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 passederr.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), TheGetDealStatushandler includederr.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 includederr.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.
Remediation (PR #919)
Connection string password masking: The password in the connection string is replaced with
********. The real password is set separately viacfg.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
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.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
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. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-GJ6X-Q8RH-WJ6X? GHSA-GJ6X-Q8RH-WJ6X is a high-severity security vulnerability in github.com/filecoin-project/curio (go), affecting versions >= 1.24.3, <= 1.27.2. It is fixed in 1.27.3-rc2.
- Which versions of github.com/filecoin-project/curio are affected by GHSA-GJ6X-Q8RH-WJ6X? github.com/filecoin-project/curio (go) versions >= 1.24.3, <= 1.27.2 is affected.
- Is there a fix for GHSA-GJ6X-Q8RH-WJ6X? Yes. GHSA-GJ6X-Q8RH-WJ6X is fixed in 1.27.3-rc2. Upgrade to this version or later.
- Is GHSA-GJ6X-Q8RH-WJ6X exploitable, and should I be worried? Whether GHSA-GJ6X-Q8RH-WJ6X 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
- What actually determines whether GHSA-GJ6X-Q8RH-WJ6X 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.
- How do I fix GHSA-GJ6X-Q8RH-WJ6X? Upgrade
github.com/filecoin-project/curioto 1.27.3-rc2 or later.