An issue was discovered in OPC Foundation OPCFoundation/UA-.NETStandard through 1.5.374.78. A remote attacker can send requests with invalid credentials and cause the server performance to degrade gradually.

Apollo Router Query Validation Vulnerable to Excessive Resource Consumption via Named Fragment Processing

The Apollo Router Core is a configurable, high-performance graph router written in Rust to run a federated supergraph that uses Apollo Federation 2. A vulnerability in Apollo Router's usage of Apollo Compiler allowed queries with deeply nested and reused named fragments to be prohibitively expensive to validate. This could lead to excessive resource consumption and denial of service. Apollo Router's usage of Apollo Compiler has been updated so that validation logic processes each named fragment only once, preventing redundant traversal. This has been remediated in apollo-router versions 1.61.2 and 2.1.1.

OpenComputers Denial of Service using xpcall

OpenComputers is a Minecraft mod that adds programmable computers and robots to the game. A user can use OpenComputers to get a Computer thread stuck in the Lua VM, which eventually blocks the Server thread, requiring the server to be forcibly shut down. This can be accomplished using any device in the mod and can be performed by anyone who can execute Lua code on them. This occurs while using the native Lua library. LuaJ appears to not have this issue. This vulnerability is fixed in 1.8.4. The GregTech: New Horizons modpack uses its own modified version of OpenComputers. They have applied the relevant patch in version 1.10.10-GTNH.

Apollo Router Query Planner Vulnerable to Excessive Resource Consumption via Named Fragment Expansion

The Apollo Router Core is a configurable, high-performance graph router written in Rust to run a federated supergraph that uses Apollo Federation 2. Prior to 1.61.2 and 2.1.1, a vulnerability in Apollo Router allowed queries with deeply nested and reused named fragments to be prohibitively expensive to query plan, specifically during named fragment expansion. Named fragments were being expanded once per fragment spread during query planning, leading to exponential resource usage when deeply nested and reused fragments were involved. This could lead to excessive resource consumption and denial of service. This has been remediated in apollo-router versions 1.61.2 and 2.1.1.

Apollo Router Query Planner Vulnerable to Excessive Resource Consumption via Optimization Bypass

The Apollo Router Core is a configurable, high-performance graph router written in Rust to run a federated supergraph that uses Apollo Federation 2. A vulnerability in Apollo Router allowed queries with deeply nested and reused named fragments to be prohibitively expensive to query plan, specifically due to internal optimizations being frequently bypassed. The query planner includes an optimization that significantly speeds up planning for applicable GraphQL selections. However, queries with deeply nested and reused named fragments can generate many selections where this optimization does not apply, leading to significantly longer planning times. Because the query planner does not enforce a timeout, a small number of such queries can exhaust router's thread pool, rendering it inoperable. This could lead to excessive resource consumption and denial of service. This has been remediated in apollo-router versions 1.61.2 and 2.1.1.

bep/imagemeta allows a potentially large memory allocation in PNG and WebP parsing

bep/imagemeta is a Go library for reading EXIF, IPTC and XMP image meta data from JPEG, TIFF, PNG, and WebP files. The buffer created for parsing metadata for PNG and WebP images was only bounded by their input data type, which could lead to potentially large memory allocation, and unreasonably high for image metadata. Before v0.11.0, If you didn't trust the input images, this could be abused to construct denial-of-service attacks. v0.11.0 added a 10 MB upper limit.

bep/imagemeta allows excessively large EXIF data structures

bep/imagemeta is a Go library for reading EXIF, IPTC and XMP image meta data from JPEG, TIFF, PNG, and WebP files. The EXIF data format allows for defining excessively large data structures in relatively small payloads. Before v0.10.0, If you didn't trust the input images, this could be abused to construct denial-of-service attacks. v0.10.0 added LimitNumTags (default 5000) and LimitTagSize (default 10000) options.

HCL DevOps Velocity is susceptible to a Denial of Service vulnerability

Rate limiting for certain API calls is not being enforced, making HCL Velocity vulnerable to Denial of Service (DoS) attacks. An attacker could flood the system with a large number of requests, overwhelming its resources and causing it to become unresponsive to legitimate users. This vulnerability is fixed in 5.1.7.

apollo-compiler Named Fragment Processing Vulnerability

apollo-compiler is a query-based compiler for the GraphQL query language. Prior to 1.27.0, a vulnerability in Apollo Compiler allowed queries with deeply nested and reused named fragments to be prohibitively expensive to validate. Named fragments were being processed once per fragment spread in some cases during query validation, leading to exponential resource usage when deeply nested and reused fragments were involved. This could lead to excessive resource consumption and denial of service in applications. This vulnerability is fixed in 1.27.0.

Denial of service due to allocation of resources without limits. The following products are affected: Acronis Cyber Protect Cloud Agent (Windows) before build 39904, Acronis Cyber Protect 17 (Windows) before build 41186.

An issue was discovered in Atos Eviden BullSequana XH2140 BMC before C4EM-125: OMF_C4E 101.05.0014. Some BullSequana XH products were shipped without proper hardware programming, leading to a potential denial-of-service with privileged access.

Improper resource initialization handling in firmware of some Solidigm DC Products may allow an attacker to potentially enable denial of service.

Possible DOS in processing specially formed ASN.1 Object Identifiers

Allocation of Resources Without Limits or Throttling vulnerability in Legion of the Bouncy Castle Inc. BC Java bcprov on All (API modules), Legion of the Bouncy Castle Inc. BC-FJA bc-fips on All allows Excessive Allocation. This vulnerability is associated with program files https://github.com/bcgit/bc-java/blob/main/core/src/main/java/org/bouncycastle/asn1/ASN1ObjectIdenti... https://github.com/bcgit/bc-java/blob/main/core/src/main/java/org/bouncycastle/asn1/ASN1ObjectIdentifier.Java . This issue affects BC Java: from 1.0 through 1.77; BC-FJA: from 1.0.0 through 1.0.2.5, from 2.0.0 through 2.0.1.

A denial of service (DoS) vulnerability has been identified in the JavaScript library microlight version 0.0.7. This library, used for syntax highlighting, does not limit the size of textual content it processes in HTML elements with the microlight class. When excessively large content (e.g., 100 million characters) is processed, the reset function in microlight.js consumes excessive memory and CPU resources, causing browser crashes or unresponsiveness. An attacker can exploit this vulnerability by tricking a user into visiting a malicious web page containing a microlight element with large content, resulting in a denial of service. NOTE: this is disputed by multiple parties because a large amount of memory and CPU resources is expected to be needed for content of that size.

Memory Exhaustion in Expr Parser with Unrestricted Input

Expr is an expression language and expression evaluation for Go. Prior to version 1.17.0, if the Expr expression parser is given an unbounded input string, it will attempt to compile the entire string and generate an Abstract Syntax Tree (AST) node for each part of the expression. In scenarios where input size isn’t limited, a malicious or inadvertent extremely large expression can consume excessive memory as the parser builds a huge AST. This can ultimately lead to*excessive memory usage and an Out-Of-Memory (OOM) crash of the process. This issue is relatively uncommon and will only manifest when there are no restrictions on the input size, i.e. the expression length is allowed to grow arbitrarily large. In typical use cases where inputs are bounded or validated, this problem would not occur. The problem has been patched in the latest versions of the Expr library. The fix introduces compile-time limits on the number of AST nodes and memory usage during parsing, preventing any single expression from exhausting resources. Users should upgrade to Expr version 1.17.0 or later, as this release includes the new node budget and memory limit safeguards. Upgrading to v1.17.0 ensures that extremely deep or large expressions are detected and safely aborted during compilation, avoiding the OOM condition. For users who cannot immediately upgrade, the recommended workaround is to impose an input size restriction before parsing. In practice, this means validating or limiting the length of expression strings that your application will accept. For example, set a maximum allowable number of characters (or nodes) for any expression and reject or truncate inputs that exceed this limit. By ensuring no unbounded-length expression is ever fed into the parser, one can prevent the parser from constructing a pathologically large AST and avoid potential memory exhaustion. In short, pre-validate and cap input size as a safeguard in the absence of the patch.

Improper resource management in firmware of some Solidigm DC Products may allow an attacker to potentially enable denial of service.

py-libp2p before 0.2.3 allows a peer to cause a denial of service (resource consumption) via a large RSA key.

A vulnerability has been identified in SIPROTEC 5 6MD84 (CP300) (All versions < V10.0), SIPROTEC 5 6MD85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 6MD86 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 6MD89 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 6MU85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7KE85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SA82 (CP150) (All versions < V10.0), SIPROTEC 5 7SA86 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SA87 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SD82 (CP150) (All versions < V10.0), SIPROTEC 5 7SD86 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SD87 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SJ81 (CP150) (All versions < V10.0), SIPROTEC 5 7SJ82 (CP150) (All versions < V10.0), SIPROTEC 5 7SJ85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SJ86 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SK82 (CP150) (All versions < V10.0), SIPROTEC 5 7SK85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SL82 (CP150) (All versions < V10.0), SIPROTEC 5 7SL86 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SL87 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7SS85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7ST85 (CP300) (All versions < V10.0), SIPROTEC 5 7ST86 (CP300) (All versions < V10.0), SIPROTEC 5 7SX82 (CP150) (All versions < V10.0), SIPROTEC 5 7SX85 (CP300) (All versions < V10.0), SIPROTEC 5 7SY82 (CP150) (All versions < V10.0), SIPROTEC 5 7UM85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7UT82 (CP150) (All versions < V10.0), SIPROTEC 5 7UT85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7UT86 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7UT87 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7VE85 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7VK87 (CP300) (All versions >= V7.80 < V10.0), SIPROTEC 5 7VU85 (CP300) (All versions < V10.0), SIPROTEC 5 Compact 7SX800 (CP050) (All versions < V10.0). Affected devices do not properly limit the bandwidth for incoming network packets over their local USB port. This could allow an attacker with physical access to send specially crafted packets with high bandwidth to the affected devices thus forcing them to exhaust their memory and stop responding to any network traffic via the local USB port. Affected devices reset themselves automatically after a successful attack. The protection function is not affected of this vulnerability.

Go JOSE's Parsing Vulnerable to Denial of Service

Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. In versions on the 4.x branch prior to version 4.0.5, when parsing compact JWS or JWE input, Go JOSE could use excessive memory. The code used strings.Split(token, ".") to split JWT tokens, which is vulnerable to excessive memory consumption when processing maliciously crafted tokens with a large number of `.` characters. An attacker could exploit this by sending numerous malformed tokens, leading to memory exhaustion and a Denial of Service. Version 4.0.5 fixes this issue. As a workaround, applications could pre-validate that payloads passed to Go JOSE do not contain an excessive number of `.` characters.

Net::IMAP vulnerable to possible DoS by memory exhaustion

Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Starting in version 0.3.2 and prior to versions 0.3.8, 0.4.19, and 0.5.6, there is a possibility for denial of service by memory exhaustion in `net-imap`'s response parser. At any time while the client is connected, a malicious server can send can send highly compressed `uid-set` data which is automatically read by the client's receiver thread. The response parser uses `Range#to_a` to convert the `uid-set` data into arrays of integers, with no limitation on the expanded size of the ranges. Versions 0.3.8, 0.4.19, 0.5.6, and higher fix this issue. Additional details for proper configuration of fixed versions and backward compatibility are available in the GitHub Security Advisory.