Find, fix and prevent vulnerabilities in your code.

Overview

com.fasterxml.jackson.core:jackson-core is a Core Jackson abstractions, basic JSON streaming API implementation

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the enforcement of document length constraints in blocking, async, and DataInput parser processes. An attacker can cause excessive resource consumption by submitting oversized JSON documents that bypass configured size limits.

Remediation

Upgrade com.fasterxml.jackson.core:jackson-core to version 2.18.7, 2.21.2 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Issue
• Maintainer's Advisory

Overview

org.postgresql:postgresql is a Java JDBC 4.2 (JRE 8+) driver for PostgreSQL database.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling during the client-side SCRAM-SHA-256 authentication. An attacker can cause excessive CPU consumption by specifying a very large PBKDF2 iteration count during authentication attempts from a malicious server. This can lead to exhaustion of client CPU resources and disruption of connection pools.

Workaround

The following measures can reduce exposure:

• Only connect to trusted PostgreSQL servers whose identity is verified. Connect only to trusted PostgreSQL servers, and verify server identity with TLS using sslmode=verify-full and a trusted CA. TLS without certificate and hostname verification is not sufficient as an active network attacker can still impersonate the server.

• Do not rely on loginTimeout as a complete mitigation on unpatched versions. On affected versions, loginTimeout can stop the waiting caller while the worker thread continues spending CPU.

• Avoid SCRAM on untrusted or interceptable connection paths. For those paths, use an authentication method that does not let the server choose a SCRAM PBKDF2 iteration count.

• Reduce blast radius operationally. Limit parallel connection attempts, add retry backoff, isolate connection establishment in a separate worker or process when possible, and apply CPU or container limits where appropriate.

• On trusted servers you control, keep SCRAM iteration counts at ordinary values. This does not defend against an attacker-controlled server, but it avoids unnecessary client cost when talking to legitimate servers.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade org.postgresql:postgresql to version 42.7.11 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Release
• Release Notes

Overview

org.lz4:lz4-java is a Java port of the LZ4 compression algorithm and the xxHash hashing algorithm.

Affected versions of this package are vulnerable to Insertion of Sensitive Information Into Sent Data in the decompression process when the output buffer is reused without being cleared. An attacker can access sensitive information from previous buffer contents by providing crafted compressed input.

Note:

• JNI implementations are not vulnerable.
• LZ4Factory.safeInstance(), LZ4Factory.unsafeInstance(), and LZ4Factory.fastestJavaInstance() are all vulnerable.
• nativeInstance().fastDecompressor() is vulnerable but nativeInstance().safeDecompressor() is not.
• This vulnerability is distinct from the one described in CVE-2025-12183, and was discovered during follow-up research.

Workaround

This vulnerability can be mitigated by zeroing the output buffer before passing it to the decompression function.

Remediation

There is no fixed version for org.lz4:lz4-java.

References

• GitHub Commit