{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/cpu_exhaustion/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[{"cvss":7.5,"id":"CVE-2026-42198"}],"_cs_exploited":false,"_cs_products":["postgresql/pgjdbc (\u003e= 42.2.0, \u003c 42.7.11)"],"_cs_severities":["high"],"_cs_tags":["dos","cpu_exhaustion","pgjdbc","scram","authentication"],"_cs_type":"advisory","_cs_vendors":["PostgreSQL"],"content_html":"\u003cp\u003eThe pgjdbc driver is susceptible to a denial-of-service (DoS) attack stemming from unbounded PBKDF2 iterations during SCRAM-SHA-256 authentication. A malicious PostgreSQL server can exploit this vulnerability by sending a \u003ccode\u003eserver-first-message\u003c/code\u003e containing an excessively large SCRAM PBKDF2 iteration count to the client. This causes the client to expend an unbounded amount of CPU time executing the PBKDF2 algorithm, effectively tying up a CPU core. Repeated or concurrent attempts can exhaust client CPU resources, potentially wedging connection pools.  The vulnerability is present in pgjdbc versions 42.2.0 up to 42.7.10.  Successful exploitation does not lead to authentication bypass or password disclosure. The patch introduces \u003ccode\u003escramMaxIterations\u003c/code\u003e to prevent excessive iterations.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe application initiates a connection to a PostgreSQL server using the pgjdbc driver. The connection is configured to use SCRAM-SHA-256 authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker compromises a PostgreSQL server or sets up a malicious server designed to exploit the pgjdbc vulnerability.\u003c/li\u003e\n\u003cli\u003eThe client attempts to authenticate with the malicious PostgreSQL server.\u003c/li\u003e\n\u003cli\u003eThe server responds with a \u003ccode\u003eserver-first-message\u003c/code\u003e that specifies an extremely high PBKDF2 iteration count.\u003c/li\u003e\n\u003cli\u003eThe pgjdbc driver, prior to version 42.7.11, initiates the PBKDF2 computation using the attacker-supplied iteration count.\u003c/li\u003e\n\u003cli\u003eThe PBKDF2 computation consumes an excessive amount of CPU time on the client machine, potentially tying up a CPU core.\u003c/li\u003e\n\u003cli\u003eIf multiple connection attempts are made concurrently, or if connection retries are enabled, the CPU exhaustion can escalate rapidly.\u003c/li\u003e\n\u003cli\u003eThe client application becomes unresponsive or experiences significant performance degradation due to CPU exhaustion, resulting in a denial-of-service condition.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability leads to a denial-of-service condition on the client-side. Applications using vulnerable versions of pgjdbc may become unresponsive or experience significant performance degradation due to excessive CPU consumption. The impact is more pronounced in applications that allow users to supply their own database connection details or that connect through untrusted proxies.  While the source mentions a high severity, it does NOT appear that any large-scale attacks have leveraged this vulnerability.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to pgjdbc version 42.7.11 or later to incorporate the fix that introduces the \u003ccode\u003escramMaxIterations\u003c/code\u003e connection property.\u003c/li\u003e\n\u003cli\u003eConfigure the \u003ccode\u003escramMaxIterations\u003c/code\u003e connection property to a reasonable value (e.g., 100,000) to prevent excessive PBKDF2 iterations.\u003c/li\u003e\n\u003cli\u003eWhere possible, only connect to trusted PostgreSQL servers whose identity is verified using TLS with \u003ccode\u003esslmode=verify-full\u003c/code\u003e and a trusted CA.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect pgjdbc Excessive PBKDF2 Iteration Count\u0026rdquo; to identify connections attempting to use unusually high SCRAM iteration counts.\u003c/li\u003e\n\u003cli\u003eAvoid relying solely on \u003ccode\u003eloginTimeout\u003c/code\u003e as a complete mitigation, as the worker thread may continue consuming CPU even after the timeout expires.\u003c/li\u003e\n\u003cli\u003eImplement operational measures such as limiting parallel connection attempts, adding retry backoff, and applying CPU or container limits to reduce the blast radius.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-05T20:09:36Z","date_published":"2026-05-05T20:09:36Z","id":"/briefs/2024-01-pgjdbc-cpu-exhaustion/","summary":"pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication, where a malicious server can instruct the driver to perform SCRAM authentication with a very large iteration count, leading to CPU exhaustion.","title":"pgjdbc SCRAM Authentication CPU Exhaustion DoS","url":"https://feed.craftedsignal.io/briefs/2024-01-pgjdbc-cpu-exhaustion/"}],"language":"en","title":"CraftedSignal Threat Feed — Cpu_exhaustion","version":"https://jsonfeed.org/version/1.1"}