A memory leak flaw was found in Libtiff's tiffcrop utility. This issue occurs when tiffcrop operates on a TIFF image file, allowing an attacker to pass a crafted TIFF image file to tiffcrop utility, which causes this memory leak issue, resulting an application crash, eventually leading to a denial of service.
Applications that use the function EVPPKEYpubliccheck() to check RSA public keys may experience long delays. Where the key that is being checked has been obtained from an untrusted source this may lead to a Denial of Service. An application that calls EVPPKEYpubliccheck() and supplies an RSA key obtained from an untrusted source could be vulnerable to a Denial of Service attack.
The OpenSSL SSL/TLS implementation is not affected by this issue. The OpenSSL 3.0 and 3.1 FIPS providers are affected by this issue. OpenSSL versions 3.0.0 to 3.0.12, 3.1.0 to 3.1.4 and 3.2.0 are vulnerable to this issue. OpenSSL versions 1.1.1 and 1.0.2 are not affected by this issue.
References: https://www.openssl.org/news/secadv/20240115.txt https://www.openwall.com/lists/oss-security/2024/01/15/2
Upstream fix: https://github.com/openssl/openssl/commit/18c02492138d1eb8b6548cb26e7b625fb2414a2a (3.0.13) https://github.com/openssl/openssl/commit/a830f551557d3d66a84bbb18a5b889c640c36294 (3.1.5) https://github.com/openssl/openssl/commit/0b0f7abfb37350794a4b8960fafc292cd5d1b84d (3.2.1)
Issue summary: Calling the OpenSSL API function SSLselectnextproto with an empty supported client protocols buffer may cause a crash or memory contents to be sent to the peer.
A flaw was found in expat. The vulnerability occurs due to large content in element type declarations when there is an element declaration handler present which leads to an integer overflow. This flaw allows an attacker to inject an unsigned integer, leading to a crash or a denial of service.
Expat (aka libexpat) before 2.4.4 has a signed integer overflow in XMLGetBuffer, for configurations with a nonzero XMLCONTEXTBYTES.
Accounts. The issue was addressed with improved checks.
GNU Emacs could allow a remote attacker to execute arbitrary code on the system, caused by a code injection flaw in org-link-expand-abbrev in lisp/ol.el. By sending a specially crafted request, an attacker could exploit this vulnerability to execute arbitrary code on the system.
A security vulnerability was found in zlib. The flaw triggered a heap-based buffer in inflate in the inflate.c function via a large gzip header extra field. This flaw is only applicable in the call inflateGetHeader.
Summary pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication.
Impact A malicious server can instruct the driver to perform SCRAM authentication with a very large iteration count. With a large enough value, the client spends an unbounded amount of CPU time inside PBKDF2 before authentication can fail. A single attempt ties up a CPU core. Repeated or concurrent attempts exhaust client CPU and can wedge connection pools.
In affected versions, loginTimeout did not fully mitigate this problem. When loginTimeout expired, the caller could stop waiting, but the worker thread performing the connection attempt could continue running and burning CPU inside the SCRAM PBKDF2 computation.
This issue affects availability. It does not provide authentication bypass, privilege escalation, or direct password disclosure.
A user is vulnerable when all of the following are true:
1. The connection uses SCRAM-SHA-256 authentication. 2. The client reaches a malicious, compromised, or attacker-controlled PostgreSQL endpoint. 3. That endpoint sends a very large SCRAM PBKDF2 iteration count in the server-first-message.
In practice, that can happen in these situations:
- the application lets end users or tenants supply their own database connection details (as in many BI, reporting, analytics, ETL, and low-code platforms), so a user can point the shared client host at a server they control - the application accepts connection strings, hostnames, or JDBC URLs from user input, configuration uploaded by users, or other untrusted sources - the application is configured to connect to a PostgreSQL server that is itself malicious or later becomes compromised - the application connects through an untrusted proxy, relay, tunnel, bastion, or connection-pooling service that can act as the PostgreSQL server - an attacker can redirect the client to a fake PostgreSQL endpoint by manipulating DNS, service discovery, Kubernetes service resolution, /etc/hosts, environment variables, or similar indirection - an active network attacker on the path can impersonate the server because the connection does not strongly verify server identity (for example, sslmode lower than verify-full, or trusting a CA that signs hosts outside the operator's control)
The issue is more damaging when the application uses connection retries, many parallel connection attempts, or loginTimeout and assumes the timeout fully stops the work.
Patches The patch introduces a new connection property, scramMaxIterations, with a default of 100K. The client now rejects SCRAM server messages that advertise more PBKDF2 iterations than the configured cap before starting the PBKDF2 computation begins.
Workarounds
Until a patched version of pgjdbc is deployed, the following measures reduce exposure:
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
Impact
An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires cross-reference streams with repeated malformed cross-reference streams.
Patches
This has been fixed in pypdf==6.14.0.
Workarounds
If you cannot upgrade yet, consider applying the changes from PR #3887.
Impact
An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires parsing the content stream of a page with a not terminated inline image, as done when extracting the page text for example.
Patches
This has been fixed in pypdf==6.14.1.
Workarounds
If you cannot upgrade yet, consider applying the changes from PR #3891.
Impact
An attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires loading images where the declared size values are much too large compared to the actual data.
Patches
This has been fixed in pypdf==6.14.0.
Workarounds
If you cannot upgrade yet, consider applying the changes from PR #3888.
Impact
An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires parsing the content stream of a page with a not terminated inline image, as done when extracting the page text for example. It only affects the ASCII85 and ASCIIHex filters.
Patches
This has been fixed in pypdf==6.14.2.
Workarounds
If you cannot upgrade yet, consider applying the changes from PR #3892.
pypdf is a free and open-source pure-python PDF library. Prior to 6.13.3, a maliciously crafted PDF can cause DoS. An attacker who uses this vulnerability can craft a PDF which leads to large memory usage, as MAXDECLAREDSTREAMLENGTH is sometimes ignored. This requires parsing a content stream without a /Length value. This issue has been fixed in version 6.13.3.
Impact
An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires merging a file with threads/articles into a writer.
Patches
This has been fixed in pypdf==6.13.1.
Workarounds
If users cannot upgrade yet, consider applying the changes from PR #3839.
Impact
An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires merging a file with outlines into a writer.
Patches
This has been fixed in pypdf==6.13.0.
Workarounds
If you cannot upgrade yet, consider applying the changes from PR #3830.
Impact
An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires extracting the text in layout mode.
Patches
This has been fixed in pypdf==6.13.0.
Workarounds
If you cannot upgrade yet, consider applying the changes from PR #3830.
Impact
An attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires parsing large XMP metadata, possibly with lots of unnecessary elements.
Patches This has been fixed in pypdf==6.12.1.
Workarounds If you cannot upgrade yet, consider applying the changes from PR #3796.
Impact An attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires extracting the text of a page which contains a form XObject with self-references.
Patches This has been fixed in pypdf==6.12.2.
Workarounds If you cannot upgrade yet, consider applying the changes from PR #3805.
Impact
An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires cross-reference streams with /W [0 0 0] values and large /Size values.
Patches
This has been fixed in pypdf==6.12.0.
Workarounds
If developers are unable to upgrade their apps immediately, they should consider applying the changes from PR #3791.
Impact An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires accessing a stream which uses the /FlateDecode filter with a PNG predictor.
Patches This has been fixed in pypdf==6.12.2.
Workarounds If you cannot upgrade yet, consider applying the changes from PR #3806.
Impact
An attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires extracting text in layout mode with large character offsets.
Patches
This has been fixed in pypdf==6.12.0.
Workarounds
If developers are unable to immediately upgrade, they should consider applying the changes from PR #3790.
Impact
An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop. This requires accessing the children of a TreeObject, for example as part of outlines.
Patches
This has been fixed in pypdf==6.7.1.
Workarounds
If you cannot upgrade yet, consider applying the changes from PR #3645.
Impact
An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires a malformed /FlateDecode stream, where the byte-by-byte decompression is used.
Patches
This has been fixed in pypdf==6.7.1.
Workarounds
If you cannot upgrade yet, consider applying the changes from PR #3644.
Impact
An attacker who uses this vulnerability can craft a PDF which leads to long runtimes and large memory consumption. This requires parsing the /ToUnicode entry of a font with unusually large values, for example during text extraction.
Patches
This has been fixed in pypdf==6.7.1.
Workarounds
If you cannot upgrade yet, consider applying the changes from PR #3646.
OOM Denial of Service via Unbounded Array Allocation in Apache OpenNLP AbstractModelReader
Versions Affected:
before 1.9.5 before 2.5.9
before 3.0.0-M3
Description:
The AbstractModelReader methods getOutcomes(), getOutcomePatterns(), and getPredicates() each read a 32-bit signed integer count field from a binary model stream and pass that value directly to an array allocation (new String[numOutcomes], new int[numOCTypes][], new String[NUMPREDS]) without validating that the value is non-negative or within a reasonable bound. The count is therefore fully attacker-controlled when the model file originates from an untrusted source.
A crafted .bin model file in which any of these count fields is set to Integer.MAXVALUE (or any value large enough to exhaust the available heap) triggers an OutOfMemoryError at the array allocation itself, before the corresponding label or pattern data is consumed from the stream. The error occurs very early in deserialization: for a GIS model, getOutcomes() is reached after only the model-type string, the correction constant, and the correction parameter have been read; so the attacker pays no meaningful size cost to weaponize a payload, and a single small file can crash a JVM that loads it. Any code path that deserializes a .bin model is affected, including direct use of GenericModelReader and any higher-level component that delegates to it during model load.
The practical impact is denial of service against processes that load model files from untrusted or semi-trusted origins.
Mitigation:
2.x users should upgrade to 2.5.9.
3.x users should upgrade to 3.0.0-M3.
Note: The fix introduces an upper bound on each of the three count fields, checked before array allocation; counts that are negative or exceed the bound cause an IllegalArgumentException to be thrown and the read to fail fast with no large allocation. The default bound is 10,000,000, which is well above the entry counts of legitimate OpenNLP models but far below any value that would threaten heap exhaustion. Deployments that legitimately need to load models with more entries than the default can raise the limit at JVM startup by setting the OPENNLPMAXENTRIES system property to the desired positive integer (e.g. -DOPENNLPMAXENTRIES=50000000); invalid or non-positive values fall back to the default.
Users who cannot upgrade immediately should treat all .bin model files as untrusted input unless their provenance is verified, and should avoid loading models supplied by end users or fetched from third-party repositories without integrity checks.
LibTIFF 4.4.0 has an out-of-bounds read in tiffcp in tools/tiffcp.c:948, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit e8131125.
LibTIFF 4.4.0 has an out-of-bounds write in extractContigSamplesShifted24bits in tools/tiffcrop.c:3604, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit cfbb883b.
A vulnerability found in nss. By this security vulnerability, nss client auth crash without a user certificate in the database and this can lead us to a segmentation fault or crash.
LibTIFF 4.4.0 has an out-of-bounds write in TIFFmemcpy in libtiff/tifunix.c:346 when called from extractImageSection, tools/tiffcrop.c:6826, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit 236b7191.