CVE-2026-109391 in Squash
Summary
by MITRE • 10/12/2026
Square Squash through commit e73f280 contains an insecure deserialization vulnerability that allows unauthenticated attackers to store crafted YAML via the POST /api/1.0/symbolication endpoint. When occurrences referencing the attacker-controlled symbolication UUID are symbolicated, the stored values are passed to YAML.load with SafeYAML in unsafe mode, enabling arbitrary Ruby object deserialization and potential code execution.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified within Square Squash prior to commit e73f280 represents a critical insecure deserialization flaw that compromises the integrity of the application's symbolication service. This specific weakness is located in the POST /api/1.0/symbolication endpoint, which serves as an entry point for unauthenticated attackers to inject malicious payloads into the system. The core issue stems from how the application handles data persistence and subsequent processing of user-supplied input. When a request is made to this endpoint with crafted YAML content associated with a specific symbolication UUID, the server stores these values in its backend storage without sufficient validation or sanitization mechanisms that would prevent malicious object instantiation upon retrieval.
The technical severity of this vulnerability lies in the manner in which stored data is processed during the symbolication phase. When occurrences referencing the attacker-controlled symbolication UUID are subsequently symbolicated by the system, the previously stored YAML values are retrieved and passed to a Ruby deserialization function. Although the application utilizes SafeYAML, a library designed to mitigate risks associated with arbitrary object creation, it was configured or invoked in an unsafe mode during this specific operation. This configuration effectively disables the security restrictions that normally prevent the instantiation of arbitrary Ruby objects from serialized data. Consequently, instead of treating the input as plain text or safe structured data, the application interprets YAML tags and structures that instruct the runtime environment to create instances of specified classes with provided attributes.
This architectural flaw allows for remote code execution (RCE) by unauthenticated actors who do not require valid credentials to exploit the vulnerability. By crafting a YAML payload containing specific object instantiation directives, an attacker can force the Ruby interpreter to load and initialize arbitrary classes available within the application's environment or its dependencies. If these classes contain methods that interact with the file system, execute shell commands, or access sensitive internal resources, the attacker gains full control over the underlying server infrastructure. This capability transforms a simple data injection issue into a severe compromise of confidentiality, integrity, and availability for the affected systems.
From an industry standard perspective, this vulnerability aligns directly with CWE-502, which describes deserialization of untrusted data. The lack of proper input validation at storage time combined with unsafe processing logic exemplifies how insecure defaults can lead to critical security breaches. Furthermore, in terms of tactical mapping within the MITRE ATT&CK framework, this exploitation technique corresponds to T1059 Command and Scripting Interpreter, as it enables the execution of arbitrary code on the target system. It also relates to T1190 Exploit Public-Facing Application, given that the entry point is an API endpoint accessible without authentication.
To mitigate this vulnerability, immediate remediation involves updating Square Squash to a version post-commit e73f280 where the insecure deserialization logic has been addressed. Developers must ensure that SafeYAML or similar serialization libraries are always invoked in safe mode when processing any data derived from user input, regardless of whether that data was stored previously or received directly in the current request. Additionally implementing strict allow-listing for permitted YAML tags can further restrict the types of objects that can be instantiated during deserialization processes. Input validation should also be enforced at both the entry point and before storage to ensure that only expected data formats are persisted, thereby reducing the attack surface available to potential adversaries seeking to exploit serialization flaws in Ruby-based applications.