CVE-2026-24474 — Dioxus Components Client-Side Eval Injection

CVE: CVE-2026-24474
Name: Dioxus Components Code Injection via Eval
CVSS v4.0: 5.3 (Medium)
Severity: Medium
Exploitability: Network accessible; no authentication required; requires victim interaction
Exploit Availability: No widely shared public exploit; conceptually easy to construct

What Is This Vulnerability?

This vulnerability affects a specific part of the Dioxus Components library used in web applications built with Dioxus. A function named use_animated_open built a JavaScript string that included an id value directly from the application. That string was then fed into an eval call in the browser. Because eval runs any JavaScript text you give it, putting untrusted text into an eval string means an attacker can slip in extra code.

In simple terms:

→ User input was being inserted directly into code that gets run in the browser without proper safety checks.
→ If an attacker can control that input, they can make the browser run extra JavaScript.

When the browser runs this extra code, it effectively becomes remote client-side code execution — a form of client-side RCE.

How Attackers Could Abuse This

This isn’t a server taking over a database, but it is a browser running harmful code:

1. An attacker finds a way to inject or supply a specially crafted id value to an application that uses the vulnerable component.
2. That id value contains extra JavaScript characters that break out of the intended context and append malicious instructions.
3. When a victim loads the page or component, the browser runs the malicious script under the site’s origin.
4. This script can then:
   • Read localStorage
   • Read cookies (if not HttpOnly)
   • Call application APIs on behalf of the user
   • Perform actions as the user
   • Send sensitive info to an attacker-controlled server

This requires the victim to load the crafted page or component — meaning the attacker must somehow convince or trick the user into triggering the code (for example, through a link or embedded iframe). But once that happens, the injected JavaScript runs with the same privileges as the legitimate site in the browser.

Why Eval Is Dangerous

eval executes text as code. If code doesn’t carefully separate data from instructions, then user input becomes executable instructions. In this case, the library directly formatted user input into an eval string without escaping or isolation.

Good practice is to avoid eval entirely, or at minimum ensure data is passed in a way that cannot morph into executable instructions.

Proof-of-Concept / Exploitation (Educational)

A published proof of concept exploit was not widely circulated. However, the concept behind the vulnerability is simple:

A crafted id value containing JavaScript breaking characters could be used to close a quoted string and insert arbitrary code. For example, if the component did something like:

eval("someCodeBefore('" + id + "')someCodeAfter");

then an attacker-controlled id like:

');alert(document.cookie);//  

could break the intended structure and insert an alert(document.cookie) call.

Signs of Exploit Attempts

Because this vulnerability runs code in the browser, detection isn’t just about server logs:

Browser & Client-Side Signals

• Unexpected JavaScript errors appearing in console logs related to the component
• CSP violation reports indicating attempts to run inline scripts or eval
• Unusual outbound network calls from the client that coincide with rendering the affected component

Server & Edge Detection

Even though the exploit happens in the browser, the initial id value that triggers it often comes from a request parameter or body:

Look for suspicious values in logs:

• IDs containing characters like:
  " ' ) ; // <script>
• Encoded variants like %22, %27, %29

Example detection pattern (generic logic):

If request parameter id contains JavaScript tokens such as:
[" ' ) ; // <script ]
then flag or alert.

These aren’t precise signatures, but they help catch obvious misuse.

Where to Look for Evidence

• Application access logs — inspect id query parameters
• Web server logs / CDN logs — look for injected tokens
• WAF logs — blocked or modified requests containing JS tokens
• Browser CSP reports — indicates inline eval attempts
• Client telemetry / RUM — JS exceptions around the affected code

How You Can Detect Vulnerable Code Before It Runs

To find vulnerable code during development or review:

• Search your codebase for:
  • document.eval
  • format!( combined with user input into eval
  • Any dynamic string built around user input that ends up in eval
• Static analysis rules can flag patterns like: eval( any_string_built_from_untrusted_input )
• Manual review of any library code that uses eval with formatted strings

What to Do Right Now

If you cannot immediately update, take these steps:

Short-Term Mitigations

• Restrict or validate all id inputs
  → Only allow safe patterns like alphanumeric and known delimiters
• Set a strict Content Security Policy
  → Disallow eval and inline scripts where possible

But these only reduce risk — they do not fix the underlying issue.

Fix — Apply Official Patch

You must upgrade the Dioxus Components library to include the patch that removes untrusted interpolation into eval. This removes the core risk.

Official patch link / upgrade location:
🔗 https://github.com/DioxusLabs/components/commit/41e4242ecb1062d04ae42a5215363c1d9fd4e23a

Make sure the patched version is included in your build and dependencies. Do not rely on temporary workarounds long-term.

Final Takeaway

Here’s what you absolutely need to know:

• CVE-2026-24474 comes from unsafe use of eval in a component used on the client side
• Attackers can cause arbitrary JavaScript to run in a user’s browser by supplying a malicious id
• Real damage happens in the browser: session compromise, token theft, and unauthorized actions
• Detection is both server-side (look for malicious input) and client-side (monitor errors & CSP reports)
• Patch as soon as possible — it closes the vulnerability at its source