What RepoSignal Surfaced in React — and Why Review Alone Doesn't Catch Everything

• · RepoSignal.io · May 2026 *

---

The React repository has over 220,000 GitHub stars. It is maintained by Facebook engineers, reviewed by thousands of contributors, and used by millions of developers worldwide. It is one of the most scrutinized open source codebases in existence.

We connected it to RepoSignal.

Within 24 seconds, the scanner returned 20 findings requiring review: 16 high severity and 4 medium severity. Each finding maps to a real code location and a real pattern. Exploitability depends on execution context — that is always true of static analysis output. But every one of these findings points to something a reviewer should examine.

Scan metadata: Branch: main · Date: May 22, 2026 · Scanner: RepoSignal v3

Note: React is an actively maintained repository. Some patterns may have been addressed in subsequent commits. The commit hash pins the exact state scanned.

---

What RepoSignal Surfaced

Severity	Pattern	Location
HIGH	Dynamic code execution (eval/exec)	compiler/packages/babel-plugin-react-compiler/src/Entrypoint/Program.ts
HIGH	Dynamic code execution (eval/exec)	compiler/packages/react-compiler-healthcheck/src/checks/libraryCompat.ts
HIGH	Dynamic code execution (eval/exec)	compiler/packages/react-compiler-healthcheck/src/checks/reactCompiler.ts
HIGH	Dynamic code execution (eval/exec)	compiler/packages/react-compiler-healthcheck/src/checks/strictMode.ts (×4)
HIGH	Dynamic code execution (eval/exec)	compiler/scripts/release/shared/utils.js
HIGH	Dynamic code execution (eval/exec)	packages/react-client/src/ReactFlightReplyClient.js
HIGH	Dynamic code execution (eval/exec)	packages/react-devtools-inline/playwright.config.js
HIGH	Dynamic code execution (eval/exec)	packages/react-devtools-shared/src/backend/utils/parseStackTrace.js
HIGH	Dynamic code execution (eval/exec)	packages/react-devtools-shared/src/backend/utils/views/utils.js
HIGH	Dynamic code execution (eval/exec)	packages/react-devtools-shared/src/devtools/utils.js
HIGH	Dynamic code execution (eval/exec)	packages/react-devtools-shared/src/devtools/views/Components/IndexableDisplayName.js
MEDIUM	Debug output may leak credentials	packages/react-devtools-shared/src/backend/fiber/renderer.js
MEDIUM	Debug output may leak credentials	packages/react-devtools-shared/src/backend/legacy/renderer.js
MEDIUM	Trust boundary violation	packages/react-devtools-shared/src/devtools/views/utils.js (×2)

---

Why RepoSignal Surfaces These Patterns in React

This is the first question anyone should ask, and it deserves a careful answer.

React is a heavily reviewed project. The Facebook engineering team runs security audits. Thousands of contributors read the code. And yet 20 patterns came back in 24 seconds.

This is not an indictment of React. It is a demonstration of something more important: static analysis and human code review are looking for different things.

Human reviewers are optimized for architecture, logic, API design, and performance. They are not optimized to systematically enumerate every eval() call across 400,000 lines of code spanning a dozen packages at every commit. Automated scanners are.

Most of the eval() instances in React appear in compiler tooling and devtools — infrastructure that runs in development environments, not production user-facing runtime. Many are likely intentional or controlled. The scanner correctly surfaces them as patterns that warrant examination, because eval() with untrusted input is a well-documented path to arbitrary code execution. The scanner surfaces the pattern; a human makes the exploitability call.

Static findings alone do not predict breakage. RepoSignal combines findings with repository-specific historical behavior because many corrected PRs contain no obvious security pattern at all — they break things for reasons that only become visible by looking at what similar changes to the same codebase have done before.

This division of labor — scanner covering pattern space, reviewer covering context, RepoSignal covering empirical history — is how systematic code review at scale works.

---

What Scanners See That Reviewers Miss

Static scanners and human reviewers are not competing — they cover different ground.

	Static Scanner	Human Reviewer
Systematically covers entire codebase	✓	✗
Catches architectural logic errors	✗	✓
Flags known dangerous patterns	✓	Inconsistently
Understands business context	✗	✓
Scales with commit velocity	✓	✗
Systematically predicts correction likelihood	✗	✗

That last row is where RepoSignal adds a layer that neither scanners nor reviewers provide: empirical PR risk scoring based on the repository's own correction history.

---

The Scale of the Pattern

Dynamic code execution via eval() is one of the most documented security risks in JavaScript and TypeScript development. The OWASP Top 10 has consistently included injection attacks — the class of vulnerability that uncontrolled dynamic execution enables — as a top risk category for over a decade.

The credential exposure context is also worth understanding. GitGuardian's 2024 State of Secrets Sprawl report found that 12.8 million new secrets were exposed in public GitHub repositories in 2023 — a 28% increase over the prior year.¹ By 2024 that number reached 23.8 million, based on analysis of 1.4 billion commits.² More striking: 70% of secrets leaked in 2022 were still active two years later.³

A 2024 peer-reviewed study published in ACM Proceedings on Software Engineering found that neural code completion tools can memorize and re-emit hard-coded credentials from their training data.⁴ As AI-assisted development accelerates, the credential exposure risk compounds across any codebase. GitGuardian's 2026 analysis found that AI-assisted commits expose secrets at roughly twice the baseline rate.⁵

Dynamic execution patterns like eval() carry a parallel risk profile. JavaScript's eval() function executes arbitrary code from a string — if that string includes user-supplied input, it becomes a direct injection vector. The pattern is well-documented: OWASP's 2021 injection category covers it directly. Developer tooling and compiler infrastructure deserve particular review because they often process external input during build and development workflows while receiving less production-focused scrutiny than runtime code. The React scan found 16 high-severity instances of this pattern concentrated in compiler and devtools infrastructure — packages involved in compiler and development workflows.

---

The Cost Argument for Earlier Detection

One of the most durable findings in software engineering research is that the cost to fix a vulnerability grows exponentially as it moves through the development lifecycle. IBM's Systems Sciences Institute research quantifies this: fixing a defect during implementation costs six times more than catching it during design.⁶ For vulnerabilities that reach production, the multiplier is 30x or higher by some estimates.⁷

The global average cost of a data breach in 2024 was $4.88 million.⁸

The practical argument for scanning at the PR level is not theoretical. Every pattern flagged on a pull request is a pattern that does not become a production incident, an emergency patch cycle, or a breach notification.

The React patterns RepoSignal surfaced are not production incidents. They are review signals surfaced at the point in the workflow where they are cheapest to address.

---

What RepoSignal Would Do on a React Pull Request

The scan above covers the repository at HEAD — a snapshot of what exists. The more powerful use of RepoSignal happens at the pull request level.

Imagine a contributor opens a PR that adds another dynamic execution path to the compiler. Here is what happens:

1. The scanner flags the pattern — same as the scan above, but scoped to the diff.
2. The repository model checks historical behavior — RepoSignal has learned from React's own commit and revert history. It knows which types of changes to the compiler have historically required correction.
3. The PR gets prioritized for senior review — not blocked automatically, but surfaced with context. For example, a message might look like: "Similar changes to this area were corrected 2.83× more often than baseline."
4. The reviewer sees findings with priority guidance — RepoSignal's KStar prioritization engine groups findings by shared architectural pattern. Multiple eval() detections in the same package are treated as one repeated structural concern rather than independent failures, reducing alert noise.

This is the combination that distinguishes RepoSignal from a standalone scanner: static pattern detection plus empirical PR prioritization based on the repository's own history.

---

How RepoSignal Prioritizes Findings

RepoSignal does not return a flat list of 20 findings. Its KStar prioritization engine groups findings by shared architectural pattern to reduce repeated alerts and surface what actually needs attention.

For the React scan, KStar grouped the findings into a shared architectural pattern centered on dynamic execution and tooling exposure. The practical guidance this produces:

These findings share a common architectural pattern. Start with the highest severity finding.

For React, that means starting with the highest-severity eval() instances in the compiler packages — specifically those in Entrypoint/Program.ts and the healthcheck utilities, where dynamic execution patterns concentrate in compiler infrastructure.

---

What This Means for Your Repository

facebook/react is not a cautionary tale about React's security posture. It is a demonstration of what systematic pattern detection surfaces in any sufficiently large codebase — including yours.

A team shipping 5-10 pull requests a day is merging code that no single reviewer reads end to end. Static analysis does not replace review. It ensures systematic coverage of the pattern space that human attention cannot maintain across an entire codebase at velocity.

Connect a repository and see what patterns exist today — and which pull requests history says deserve attention next.

Get started free → reposignal.io

---

References

---

RepoSignal combines repository learning, PR risk scoring, and static analysis so teams know both what patterns exist in their code today and which pull requests history suggests deserve extra review tomorrow. Free tier available at reposignal.io.

---

1. GitGuardian, State of Secrets Sprawl 2024, March 2024. https://www.gitguardian.com/state-of-secrets-sprawl-report-2024 ↩

2. MSSP Alert, More than 23.7 Million Hardcoded Secrets Publicly Exposed in GitHub Last Year, March 2025. https://www.msspalert.com/brief/more-than-23-7-million-hardcoded-secrets-publicly-exposed-in-github-last-year ↩

3. ZeroHost Security Blog, 23.8 Million Secrets Leaked on GitHub: The Case for Credentials That Expire, February 2026. https://zerohost.net/blog/github-secrets-leaked-case-for-expiring-credentials/ ↩

4. Huang et al., Your Code Secret Belongs to Me: Neural Code Completion Tools Can Memorize Hard-Coded Credentials, ACM Proceedings on Software Engineering, FSE 2024. https://arxiv.org/pdf/2309.07639 ↩

5. Snyk, Why 28 Million Credentials Leaked on GitHub in 2025, and What to Do About It, March 2026. https://snyk.io/articles/state-of-secrets/ ↩

6. Black Duck / Synopsys, Cost to Fix Bugs and Defects During Each Phase of the SDLC, citing IBM Systems Sciences Institute. https://www.blackduck.com/blog/cost-to-fix-bugs-during-each-sdlc-phase.html ↩

7. Cypress Data Defense, Finding Application Vulnerabilities Early: Why It Matters, March 2025. https://www.cypressdatadefense.com/blog/finding-application-vulnerabilities-early-why-it-matters-and-how-to-succeed-with-limited-resources/ ↩

8. IBM, Cost of a Data Breach Report 2024, cited in Security Compass, The High Costs of Delaying a Security by Design Program, September 2024. https://www.securitycompass.com/blog/the-high-costs-of-delaying-a-security-by-design-program/ ↩