Finding React vulnerabilities as part of our security work at Privy
How upstream security research fits into Privy's day-to-day engineering work
Andrew MacPherson
|Dec 19, 2025
At Privy, security is foundational to how we build.
Because we operate wallet infrastructure that holds value, our security posture extends beyond our own codebase. It includes the frameworks, libraries, and ecosystems we depend on.
That mindset is what led our security team to closely examine a critical React vulnerability disclosed in early December, commonly referred to as React2Shell. The initial goal was straightforward: understand the vulnerability, validate the patch, and assess any potential downstream impact on systems built with modern React tooling.
Because Privy maintains React-based SDKs and works closely with modern React frameworks, it was important for us to understand how this issue could surface in real applications, particularly those using React Server Components.
Security incidents rarely end with the first patch
When a critical Common Vulnerability and Exposure (CVE) is disclosed in widely used software, it often triggers a second phase of scrutiny. Researchers and security teams examine nearby code paths, test variant exploit techniques, and attempt to bypass the initial mitigation.
This is both a healthy and necessary practice.
While validating the React2Shell patch, our team identified unexpected behaviors in React Server Components that warranted deeper investigation. That work ultimately led to the discovery and responsible disclosure of additional vulnerabilities, including:
High-severity denial-of-service vulnerabilities that could allow a malicious request to hang a server process and consume CPU resources
A source code exposure vulnerability where server functions could unintentionally leak their own source code under specific conditions
These issues were responsibly disclosed to the React team, validated, and patched as CVE-2025-55183. Some of the denial-of-service cases were also identified independently by other researchers as part of the broader community response.
This sequence of critical disclosure followed by follow-on findings is not unusual. It reflects the reality that modern software systems are complex, and that fixes often need to be tested against adversarial creativity.
Security work in practice
This investigation followed the same process we apply across our security work at Privy:
Reproducing reported vulnerabilities locally
Building minimal test harnesses to understand failure modes
Stress-testing edge cases through fuzzing and malformed inputs
Verifying behavior against production-equivalent bundles
Disclosing responsibly and collaborating upstream on fixes
What has changed is the tooling available to support this work.
As part of this investigation, our team used OpenAI’s GPT-5.1-Codex, an advanced agentic coding model designed to assist with long-horizon software engineering and defensive security workflows. The model helped accelerate routine but time-intensive tasks. This included reasoning across large codebases, iterating on test harnesses, and exploring edge-case behavior, while keeping humans firmly in the loop.
Importantly, the model did not “find” vulnerabilities on its own. The discoveries emerged through standard security practices: hypothesis-driven testing, adversarial thinking, and careful validation. GPT-5.1-Codex functioned as a force multiplier within that process, not a shortcut around it.
OpenAI later shared this work publicly in a blog post discussing the evolving role of AI in defensive cybersecurity, and OpenAI CEO Sam Altman referenced it as an example of how advanced models are being used responsibly by security teams. We view that visibility not as an achievement in itself, but as evidence of a broader shift: modern security work increasingly blends human judgment with increasingly capable tooling.
Security engineering at Privy
At Privy, we believe all engineering is security engineering.
Engaging in upstream security work helps us better understand the systems we rely on, identify risks earlier, and contribute to faster remediation across the ecosystem. That rigor directly benefits our customers, whose applications depend on the safety and reliability of shared infrastructure.
Security work like this is not episodic. As wallets increasingly function as global accounts, the expectations placed on infrastructure providers will continue to rise.
Our responsibility is to meet that bar not just by securing our own systems, but by participating thoughtfully in the security of the broader ecosystem they’re built on.
To learn more about Privy’s approach to security, visit privy.io/security.
If you believe you’ve found a security issue or want to collaborate on responsible disclosure, we welcome reports through our bug bounty program.
