CVE-2024-28121 in stimulus_reflex
Summary
by MITRE • 03/12/2024
stimulus_reflex is a system to extend the capabilities of both Rails and Stimulus by intercepting user interactions and passing them to Rails over real-time websockets. In affected versions more methods than expected can be called on reflex instances. Being able to call some of them has security implications. To invoke a reflex a websocket message of the following shape is sent: `\"target\":\"[class_name]#[method_name]\",\"args\":[]`. The server will proceed to instantiate `reflex` using the provided `class_name` as long as it extends `StimulusReflex::Reflex`. It then attempts to call `method_name` on the instance with the provided arguments. This is problematic as `reflex.method method_name` can be more methods that those explicitly specified by the developer in their reflex class. A good example is the instance_variable_set method. This vulnerability has been patched in versions 3.4.2 and 3.5.0.rc4. Users unable to upgrade should: see the backing GHSA advisory for mitigation advice.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 12/03/2025
The stimulus_reflex library represents a powerful integration mechanism that bridges Rails applications with Stimulus JavaScript controllers through real-time websocket communication. This system enables developers to create dynamic user interfaces where client-side interactions are seamlessly transmitted to server-side Rails controllers, allowing for responsive web applications without full page reloads. The library operates by intercepting user interactions and routing them through websocket messages to Rails applications, creating a sophisticated real-time communication channel between frontend and backend components.
The core vulnerability in stimulus_reflex stems from improper method validation during reflex execution, specifically within the method invocation mechanism that processes websocket messages. When a client sends a websocket message with the target format `"[class_name]#[method_name]"`, the system instantiates the specified reflex class and attempts to execute the requested method. However, the implementation fails to properly restrict method calls to only those explicitly defined within the developer's reflex class, instead allowing execution of any method available on the reflex instance through Ruby's dynamic method invocation capabilities.
This flaw creates a significant security risk by enabling arbitrary method execution on reflex instances, particularly through Ruby's metaprogramming features. The vulnerability allows attackers to exploit methods like instance_variable_set, which can modify internal object state and potentially access sensitive data or manipulate object behavior in unexpected ways. The attack surface expands beyond intended functionality because the system does not properly validate that the requested method_name corresponds to explicitly defined methods within the reflex class, opening pathways for privilege escalation or data manipulation through carefully crafted websocket messages.
The operational impact of this vulnerability extends beyond simple code execution, potentially enabling attackers to manipulate application state, access protected data, or perform unauthorized operations on server-side objects. Since the reflex instances are instantiated with developer-defined classes that extend StimulusReflex::Reflex, attackers can leverage Ruby's powerful metaprogramming capabilities to traverse object hierarchies, modify instance variables, or even execute arbitrary code through method chaining. This vulnerability particularly affects applications that rely heavily on dynamic reflex handling and real-time user interaction patterns.
Security practitioners should note this vulnerability aligns with CWE-20: Improper Input Validation and follows patterns commonly seen in deserialization and method invocation vulnerabilities. The ATT&CK framework categorizes this under T1059.001: Command and Scripting Interpreter - PowerShell and similar execution techniques that leverage dynamic method invocation. Organizations should prioritize patching to versions 3.4.2 or 3.5.0.rc4 as these releases contain proper method validation mechanisms. For those unable to upgrade immediately, the GitHub Security Advisory provides specific mitigation strategies including input sanitization and method whitelisting approaches. The vulnerability demonstrates the critical importance of proper method access control in dynamic language environments where reflection and metaprogramming features are leveraged for application functionality.