React Router's SSR hydration function deserializeErrors() accepted error payloads that were later deserialized on the client. The impact of this flaw is that if application code allows an attacker to inject custom data into the error object, the deserialization could call a constructor that was not intended, leading to an arbitrary outbound network request. Based on the description, it is inferred that this scenario requires sophisticated manipulation of server‑side error handling, which is unlikely in most deployments. Nevertheless, the flaw permits an attacker to trigger unintended client‑side execution and could be used for data exfiltration or malicious redirects. The core weakness is code injection via deserialization (CWE‑470).

Customers deploying remix‑run's React Router between versions 6.4.0 and 7.17.0 in Framework Mode or Data Mode with manual server‑side rendering are vulnerable. Declarative Mode builds are unaffected. The fix was introduced in 7.18.0. Based on the description, it is inferred that the vulnerability only manifests in applications that perform manual SSR/hydration in Framework or Data Mode, while Declarative Mode builds remain unaffected.

The CVSS score of 6.1 places this vector at medium severity. The EPSS score is less than 1%, indicating a very low likelihood of exploitation. The vulnerability is not currently listed in CISA's KEV catalog. Exploitation requires the attacker to subvert the application’s error‑handling logic to supply a crafted payload that will reach the React Router SSR layer, which suggests the likelihood of real‑world attacks is relatively low. Based on the description, it is inferred that an attacker must possess the ability to influence the server‑side error handling to inject a crafted error payload; such a condition is atypical in normal operation. Nevertheless, the presence of a constructor injection mechanism means that a successful exploit can result in unintended network calls from the client.