CVE-2026-102461 in Vert.x
Summary
by MITRE • 10/15/2026
In Eclipse Vert.x versions [4.0.0, 4.5.34] or [5.0.0,5.0.12] or [5.1.0,5.1.9] or [5.2.0, 5.2.0], the uniqueItems keyword validation uses an O(n²) pairwise comparison loop with no short-circuit or size limit. A remote unauthenticated attacker can submit a moderately-sized JSON array that consumes disproportionate CPU time, leading to denial of service.
The impacted component is io.vertx:vertx-json-schema.
The following Vert.x modules depend on vertx-json-schema and are also affected:
io.vertx:vertx-web-openapi-router io.vertx:vertx-web-validation io.vertx:vertx-openapi
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/15/2026
Eclipse Vert.x, a widely adopted reactive toolkit for building applications on the JVM, contains a critical performance vulnerability within its JSON Schema validation module. Specifically, versions ranging from 4.0.0 to 4.5.34, as well as newer branches including 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and the specific release of 5.2.0 are susceptible to a denial-of-service attack vector rooted in inefficient algorithmic complexity. The core issue resides in the implementation of the uniqueItems keyword validation logic within the io.vertx:vertx-json-schema library. This component is foundational for validating JSON data structures against defined schemas, ensuring that array elements meet specific criteria such as uniqueness. When an application utilizes this module to process incoming requests, it relies on these internal validation routines to enforce schema constraints before further processing occurs.
The technical flaw lies in the algorithmic approach used to verify item uniqueness within a JSON array. The current implementation employs a naive O(n squared) pairwise comparison loop without any short-circuiting mechanisms or size limits. In practical terms this means that for an input array of n items, the system performs approximately n times n comparisons to determine if all elements are distinct. While this approach is computationally acceptable for small datasets typical in many internal API interactions, it becomes a severe liability when exposed to untrusted external inputs. A remote attacker who can submit JSON payloads containing moderately sized arrays with high cardinality can trigger this quadratic time complexity. As the size of the array increases linearly, the CPU consumption grows exponentially, rapidly consuming available processing resources on the server hosting the Vert.x application.
This vulnerability is classified under CWE-400, which covers Uncontrolled Resource Consumption, and aligns with ATT&CK technique T1496, Resource Hijacking, where an adversary uses computing resources to disrupt service availability rather than stealing data or gaining unauthorized access. The impact of this flaw extends beyond the core schema validation library itself because several critical Vert.x modules depend on it for request handling and API definition enforcement. Consequently, applications using io.vertx:vertx-web-openapi-router, io.vertx:vertx-web-validation, or io.vertx:vertx-openapi are directly exposed to this risk if they process unvalidated JSON arrays in their endpoints. An attacker can craft a malicious HTTP POST request containing a large array of unique items, causing the server thread handling that request to become blocked for an extended period due to excessive CPU cycles spent on validation comparisons.
The operational impact is primarily a denial-of-service condition affecting availability and potentially integrity if cascading failures occur within microservice architectures relying on synchronous processing models. Since Vert.x often handles high-concurrency workloads, the exhaustion of thread pools or CPU cores by such malicious requests can degrade performance for legitimate users, leading to timeouts, dropped connections, or complete service unavailability depending on the scale of the attack and the server's resource limits. This is particularly dangerous in public-facing APIs where input size cannot be strictly controlled by internal policies alone.
Mitigation strategies must focus on both immediate patching and architectural defenses. The primary remediation is to upgrade the affected Vert.x modules to versions that include a fix for this algorithmic inefficiency, ensuring that the uniqueItems validation utilizes more efficient data structures such as hash sets or bloom filters which offer O(n) average time complexity. For organizations unable to immediately update their dependencies due to compatibility constraints, implementing strict input size limits on JSON arrays at the network perimeter via Web Application Firewalls is essential. Additionally, developers should enforce schema-level maximum array length properties within their OpenAPI specifications and validate these constraints before passing data deeper into the application stack. Monitoring CPU usage patterns for sudden spikes correlated with specific API endpoints can also aid in early detection of such abuse attempts until permanent fixes are deployed.