CVE-2026-33815

What it actually does

CVE-2026-33815 is a memory-safety vulnerability in the jackc pgx v5 PostgreSQL client library for Go. A vulnerable application that processes attacker-controlled PostgreSQL protocol data or interacts with a malicious or compromised PostgreSQL endpoint may experience memory corruption. With the assigned CVSS vector indicating network reachability, low attack complexity, no privileges, and no user interaction, the worst-case technical impact is remote code execution, data disclosure, data tampering, or process crash, depending on how the vulnerable code path is reached and how the application is compiled and deployed.

Why it matters to the business

Applications that depend on vulnerable versions of jackc pgx may be exposed to compromise through database connectivity paths, especially where applications connect to databases, proxies, test infrastructure, tenant-provided endpoints, or services that could be spoofed or compromised. Successful exploitation could lead to application takeover, theft or modification of data handled by the application, service outages, and downstream compromise of systems reachable from the application. Although EPSS is currently low at 0.00605, has remained flat over 30 days, and there is no known KEV listing or public exploit maturity reported, the CVSS 9.8 severity warrants prompt inventory and remediation planning.

How an attack unfolds

An attacker first identifies an application using the vulnerable github.com/jackc/pgx/v5 library and determines whether they can influence PostgreSQL protocol traffic received by that application. This may be possible by controlling a database endpoint the application connects to, compromising an existing PostgreSQL server or proxy, redirecting traffic through DNS or configuration manipulation, or abusing application functionality that accepts database connection parameters. The attacker then sends specially crafted PostgreSQL protocol responses or data that trigger the memory-safety flaw inside pgx. If exploitation is reliable, the process may crash, leak memory contents, corrupt application state, or potentially execute attacker-controlled code in the context of the affected application. Because no public exploit maturity is reported, defenders should treat observed crashes or anomalous PostgreSQL protocol behavior as suspicious but should not assume a commodity exploit is already available.

How to fix it

Identify all Go applications and services that depend on github.com/jackc/pgx/v5, including direct and transitive dependencies. Because no fixed versions were provided in the supplied advisory data, monitor the upstream pgx project and package advisories for the patched release and upgrade as soon as an official fixed version is available. Until a fix is available, reduce exposure by ensuring applications only connect to trusted PostgreSQL servers, enforcing TLS with certificate validation for database connections where supported, preventing user-controlled database connection strings, restricting egress to approved database hosts, and isolating workloads that use pgx from untrusted networks. Rebuild and redeploy affected applications after dependency updates, since Go dependencies are typically compiled into application binaries.

How to confirm the fix worked

Confirm exposure by reviewing go.mod, go.sum, software composition analysis output, SBOMs, and built binary dependency metadata for github.com/jackc/pgx/v5. Run `go list -m all` from application source trees and verify whether pgx v5 is present. After an upstream fix is published and applied, verify that all builds use the fixed pgx version, regenerate lockfiles or module metadata as needed, rebuild binaries, and redeploy containers or packages. Validate that applications do not accept untrusted PostgreSQL connection parameters, that database egress is restricted to approved hosts, and that TLS certificate validation is enabled where applicable. Perform controlled regression testing against PostgreSQL connectivity paths and monitor for crashes, panics, or protocol parsing errors after deployment.

Typical attack path

1. Identify applications or services built with Go that import github.com/jackc/pgx/v5.
2. Find a path to influence PostgreSQL protocol data received by the application, such as a malicious database endpoint, compromised database server, database proxy, DNS redirection, or attacker-controlled connection configuration.
3. Deliver crafted PostgreSQL protocol messages or result data designed to reach the vulnerable memory-safety code path in pgx.
4. Trigger memory corruption in the application process.
5. Use the resulting condition to crash the service, disclose sensitive data, corrupt application behavior, or, in the highest-impact scenario, execute code as the application process.
6. Pivot using the application’s database credentials, environment secrets, network access, or service permissions if code execution or sensitive memory disclosure is achieved.

How to detect it

Look for evidence of exploitation attempts in application logs, container logs, process supervisor logs, database proxy logs, PostgreSQL server logs, DNS logs, egress firewall logs, and endpoint telemetry from systems running Go applications that use pgx v5. Key signs include sudden crashes or restarts of affected applications, Go runtime fatal errors, segmentation faults, stack traces referencing github.com/jackc/pgx/v5, PostgreSQL protocol parsing errors, connections to unexpected PostgreSQL hosts, DNS lookups for unusual database endpoints, and abnormal responses from database servers or proxies shortly before an application crash. If a crash occurred, preserve core dumps, container images, process memory artifacts, application logs, and network captures where available. Because no public exploit indicators or actor-specific infrastructure were provided, detection should focus on behavioral anomalies around PostgreSQL protocol traffic and vulnerable application process instability rather than fixed attacker IOCs.

• github.com/jackc/pgx/v5
• panic: runtime error
• fatal error: unexpected signal during runtime execution
• fatal error: fault
• unexpected fault address
• SIGSEGV
• segmentation violation
• runtime: invalid memory address or nil pointer dereference
• pgx:
• PostgreSQL protocol
• invalid message length
• unexpected message type
• conn closed
• database/sql: driver: bad connection

What your security team should do

• Inventory all applications, containers, and services that include github.com/jackc/pgx/v5, prioritizing internet-facing services, multi-tenant platforms, and systems that connect to externally managed or less-trusted PostgreSQL endpoints.
• Track upstream pgx advisories and apply the first official fixed version when released; rebuild and redeploy affected Go binaries rather than only updating source repositories.
• Before a patch is available, enforce database egress allowlisting so affected applications can connect only to trusted PostgreSQL servers and proxies.
• Disable or tightly control any feature that allows users, tenants, jobs, plugins, or configuration files to supply PostgreSQL connection strings or database hostnames.
• Require TLS and certificate validation for PostgreSQL connections where feasible to reduce the risk of spoofed or man-in-the-middle database endpoints.
• Hunt for unexplained application crashes, Go runtime fatal errors, PostgreSQL protocol errors, and unexpected outbound database connections from applications using pgx.
• Treat successful exploitation as potential application compromise: rotate database credentials, application secrets, and service tokens if suspicious crashes or anomalous database traffic are observed.
• Because this CVE is not currently in CISA KEV, has no reported ransomware use, and EPSS is low and flat, prioritize based on exposure and trust boundary rather than broad emergency patching; however, do not defer remediation for systems that process untrusted database traffic.