Threats Tagged 'cwe-772'

Package elasticsearch version 9.3.8-r2 fixes 8 vulnerabilities: CVE-2026-13505, CVE-2026-12817, CVE-2026-59640, CVE-2026-59649, CVE-2026-58062...

CVE-2026-13505 is a vulnerability in Bouncy Castle for Java FIPS (BC-FJA) before versions 1.0.2.7, 2.0.2, and 2.1.3. It involves improper zeroisation of sensitive key material due to reliance on Java finalization, which is deprecated and de-emphasized in later JVMs. This can cause sensitive key material to remain in memory longer than intended, potentially increasing exposure risk. The issue does not affect Bouncy Castle for Java (bcprov) or its LTS version. The vulnerability has a high severity rating with a CVSS score of 8.7.

Klever-Go versions prior to 1.7.18 contain a resource exhaustion vulnerability in the account-data trie syncers. The flaw causes throttler slots to be leaked on error paths during trie synchronization, leading to permanent consumption of these slots. An attacker can repeatedly trigger sync failures or timeouts, exhausting the throttler and preventing further progress in account-data trie syncs. This results in bootstrap failures for fresh, restarting, or resyncing nodes and validators, impacting availability. The issue is fixed in version 1.7.18.

Eclipse Milo versions 1.0.0 through 1.1.4 contain a vulnerability where monitored-item quota accounting is not exception-safe. An unauthenticated remote client can trigger a StackOverflowError by sending deeply nested PubSub ExtensionObjects in a CreateMonitoredItems event filter. This causes the server-global monitored-item quota to be exhausted and prevents new monitored items from being created until the server is restarted. Existing monitored items and other server functions remain unaffected.

Apache HttpComponents Client using the classic I/O model fails to release connections back to the connection manager when encountering invalid or unsupported Content-Encoding headers in response messages. This resource leak does not affect the async I/O model. The issue affects versions from 5.0-alpha1 through 5.6.2 and has a medium severity rating.

In NLnet Labs Unbound 1.20.0 up to and including 1.25.1, when Unbound is configured with 'serve-expired: yes' and 'serve-expired-client-timeout > discard-timeout > 0' (contrary to the suggested values), the discard-timeout branch during the serve expired logic drops an aged client reply without performing the correct accounting for the number of reply addresses for the query. Other identical branches outside of serve expired perform the correct decrement. Since the counter is never decremented in such scenario, it can reach the maximum limit and new clients for duplicate in-flight queries are silently dropped resulting in degradation of resolution service. A malicious actor can exploit the vulnerability by querying the resolver for a client-controlled slow-on-demand authoritative zone that can drive the counter past the threshold. Shipped defaults for 'serve-expired-client-timeout: 1800' and 'discard-timeout: 1900' make the branch unreachable.

In NLnet Labs Unbound 1.22.0 up to and including 1.25.1, client terminated DNS-over-QUIC (DoQ) queries are not accounted properly by Unbound resulting in low-cost inflation of the waiting number of replies for already in-flight resolution queries. This results in degradation of resolution service for new clients for already in-flight queries. A malicious actor can exploit the vulnerability by issuing DoQ queries for query names that need resolution and proceeding on immediately terminating the query by one of STOP_SENDING/RESET_STREAM/CONNECTION_CLOSE QUIC frames. Those terminated DoQ queries are not properly counted for and keep inflating the number of waiting replies for in-flight queries. When the maximum is reached, it results in silent query drops for new clients needing resolution for already in-flight queries. This vulnerability needs Unbound to be compiled with DoQ support ('--with-libngtcp2') and the 'quic-port' to be configured for the listening interfaces. Additionally, a malicious actor needs access to multiple source IPs to bypass the by-default configured 'wait-limit' option.

A malicious SSH peer could send unsolicited global request responses to fill an internal buffer, blocking the connection's read loop. The blocked goroutine could not be released by calling Close(), resulting in a resource leak per connection. Unsolicited global responses are now discarded.