CVE-2026-92785 in Angel
Summary
by MITRE • 09/16/2026
Angel through 3.3.0 deserializes untrusted setAlgoMetrics payload using Kryo without class registration or allowlist validation. Unauthenticated network attackers can instantiate arbitrary classes or exhaust coordinator memory by sending crafted serialized objects to the master RPC endpoint.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in Apache Angel versions through 3.3.0 represents a critical failure in input validation and serialization safety, specifically within the Kryo deserialization mechanism used for handling setAlgoMetrics payloads. This flaw allows unauthenticated attackers who have network access to the master RPC endpoint to execute arbitrary code or cause denial of service conditions by injecting maliciously crafted serialized objects. The core issue stems from the framework's reliance on Kryo without implementing strict class registration policies or allowlist validations, which are essential security controls when processing data from untrusted sources in distributed computing environments.
From a technical perspective, Apache Angel utilizes Kryo as its primary serialization library to facilitate communication between nodes and coordinate tasks within the cluster architecture. When the master node receives setAlgoMetrics requests, it deserializes the incoming payload using default configurations that do not restrict which classes can be instantiated during the unmarshaling process. This lack of restriction means that an attacker can craft a serialized object containing references to arbitrary Java classes available in the classpath. Upon receipt and processing by the master node, Kryo will instantiate these classes without verifying their legitimacy or safety, leading directly to remote code execution if dangerous classes such as those capable of executing system commands are present on the server's classpath.
The operational impact of this vulnerability is severe due to its unauthenticated nature and network accessibility. Attackers do not need valid credentials to exploit this flaw; they only require connectivity to the master RPC endpoint, which in many default configurations may be exposed or accessible within internal networks that lack sufficient segmentation. Beyond remote code execution, attackers can also target availability by sending crafted serialized objects designed to exhaust system resources. By triggering complex object graphs or large data structures during deserialization, an attacker can cause significant memory consumption on the coordinator node, leading to service degradation or complete crash of the Angel master process and potentially disrupting jobs running across the cluster.
This vulnerability aligns with CWE-502, which describes Deserialization of Untrusted Data, a category of flaws where applications deserialize data without ensuring its integrity or origin. Furthermore, it maps directly to MITRE ATT&CK technique T1648, specifically Leverage Serverless Execution via Supply Chain Compromise if the attack vector involves manipulating dependencies, but more accurately fits under T1059 Command and Scripting Interpreter through arbitrary code execution facilitated by deserialization flaws. The exploitation path typically follows a pattern where an attacker constructs a malicious payload using known gadget chains or custom classes that perform harmful actions upon instantiation, such as executing shell commands or accessing sensitive files.
Mitigation strategies must focus on hardening the serialization configuration within Apache Angel. Administrators should immediately upgrade to version 3.4.0 or later if available, where this issue has been addressed by implementing stricter class filtering mechanisms. For environments unable to patch immediately, it is critical to restrict network access to the master RPC endpoint using firewalls or security groups, ensuring that only trusted internal services can communicate with these endpoints. Additionally, configuring Kryo to use a whitelist of allowed classes rather than relying on default behavior provides an essential layer of defense against arbitrary class instantiation. Monitoring logs for unusual deserialization errors or high memory usage spikes associated with the master node can also aid in early detection and response to potential exploitation attempts.