Round 2: Vulnerable React CVEs

The notification that never ends

It's December 11th, 2025 just 8 days after the critical RCE vulnerability (CVE-2025-55182/66478). I'm enjoying my morning coffee, feeling pretty good about patching all my projects to React 19.0.1, 19.1.2, and 19.2.1.

Then React drops another blog post: Denial of Service and Source Code Exposure in React Server Components.

THREE new CVEs. And here's the kicker: some of the previous patches were incomplete.

If you updated to 19.0.2, 19.1.3, or 19.2.2 thinking you were safe? You're still vulnerable to one of the new CVEs (CVE-2025-67779).

Time to fire up the Bash script again. ☕️

The new threat landscape

This time we're dealing with three CVEs:

CVE-2025-55184 & CVE-2025-67779 (CVSS 7.5 - High Severity)

Denial of Service - Malicious HTTP requests to Server Functions endpoints can cause infinite loops that hang your server and consume CPU resources.

The scary part: You're affected even if your app supports React Server Components but doesn't implement Server Function endpoints. Just having the capability is enough.

CVE-2025-55183 (CVSS 5.3 - Medium Severity)

Source Code Exposure - Malicious HTTP requests can unsafely return source code of Server Functions, potentially exposing hardcoded secrets.

The good news: Runtime secrets like process.env.SECRET are NOT affected. Only hardcoded values in your source.

The bad news: How many of us have hardcoded an API key "just for testing" that never got removed? 😬

The incomplete patch problem

Here's what made this particularly frustrating:

Vulnerable versions: 19.0.0, 19.0.1, 19.0.2, 19.1.0, 19.1.1, 19.1.2, 19.2.0, 19.2.1, 19.2.2

Wait, 19.0.2? 19.1.3? 19.2.2? Those were supposed to be the patches from December 3rd!

Turns out, the initial patches for the RCE vulnerability were incomplete. They fixed CVE-2025-55182/66478 but left the door open for CVE-2025-67779.

Fixed versions: 19.0.3, 19.1.4, 19.2.3

So if you followed best practices and patched immediately after the first disclosure, you're running a version that's still vulnerable to the new DoS attack.

Security is hard.

Building the new checker

I already had the infrastructure from the first CVE checker, so this was mostly about updating the vulnerability logic. But there were some interesting challenges.

Challenge #1: Detecting incomplete patches

The hardest part was communicating to users that some "patched" versions are still vulnerable:

check_react_vulnerable() {
    local version=$1
    local main_version=$(echo "$version" | cut -d'-' -f1)

    # Handle "19.0" (same as 19.0.0)
    if [ "$main_version" = "19.0" ]; then
        return 0  # Vulnerable
    fi

    # Check 19.0.x series
    if version_compare "$main_version" ">=" "19.0.0" && version_compare "$main_version" "<" "19.0.3"; then
        return 0  # Vulnerable (includes 19.0.0, 19.0.1, 19.0.2)
    fi

    # Check 19.1.x series
    if version_compare "$main_version" ">=" "19.1.0" && version_compare "$main_version" "<" "19.1.4"; then
        return 0  # Vulnerable (includes 19.1.0, 19.1.1, 19.1.2, 19.1.3)
    fi

    # Check 19.2.x series
    if version_compare "$main_version" ">=" "19.2.0" && version_compare "$main_version" "<" "19.2.3"; then
        return 0  # Vulnerable (includes 19.2.0, 19.2.1, 19.2.2)
    fi

    return 1  # Not vulnerable
}

Notice how the ranges now include the previous patch versions. Anyone running 19.0.2, 19.1.3, or 19.2.2 needs to update again.

Challenge #2: Special warnings for false security

I added special detection for the incomplete patch versions with extra warning messages:

if check_react_vulnerable "$CLEAN_REACT"; then
    VULNERABLE=true
    WARNINGS+=("${RED}✗ VULNERABLE: React $CLEAN_REACT is affected${NC}")
    WARNINGS+=("  Patch to: 19.0.3, 19.1.4, or 19.2.3")

    # Special note for incomplete patch versions
    if [ "$CLEAN_REACT" = "19.0.2" ] || [ "$CLEAN_REACT" = "19.1.3" ] || [ "$CLEAN_REACT" = "19.2.2" ]; then
        WARNINGS+=("  ${YELLOW}⚠ NOTE: Version $CLEAN_REACT had incomplete patches and is still vulnerable to CVE-2025-67779${NC}")
    fi
fi

This way, users get a very clear message that their "patched" version isn't actually safe.

Challenge #3: Multiple CVEs with different severities

The output needed to communicate three different CVEs clearly:

echo -e "${YELLOW}Vulnerability Details:${NC}"
echo "• CVE-2025-55184 & CVE-2025-67779 (CVSS 7.5 - High):"
echo "  Denial of Service - Malicious HTTP requests can cause infinite loops"
echo "  that hang the server and consume CPU resources"
echo ""
echo "• CVE-2025-55183 (CVSS 5.3 - Medium):"
echo "  Source Code Exposure - Malicious requests can expose Server Function"
echo "  source code containing hardcoded secrets (runtime secrets are NOT affected)"

I wanted developers to understand both the severity and impact of each vulnerability without information overload.

The updated output

Here's what it looks like when it detects a vulnerable version:

========================================
React Server Components Security Checker
CVE-2025-55183 / CVE-2025-55184 / CVE-2025-67779
========================================

Checking package.json...

ℹ React found: ^19.0.2
  ℹ Installed React version: 19.0.2
✗ VULNERABLE: React 19.0.2 is affected
  Patch to: 19.0.3, 19.1.4, or 19.2.3
  ⚠ NOTE: Version 19.0.2 had incomplete patches and is still vulnerable to CVE-2025-67779

ℹ react-server-dom-webpack found: ^19.0.2
  ℹ Installed react-server-dom-webpack version: 19.0.2
✗ VULNERABLE: react-server-dom-webpack 19.0.2 is affected
  Update to patched React 19.x version (19.0.3, 19.1.4, or 19.2.3)
  ⚠ NOTE: Version 19.0.2 had incomplete patches and is still vulnerable to CVE-2025-67779

Other frameworks/bundlers:
  ℹ next: ^15.0.5
  ○ react-router: Not found
  ○ react-router-dom: Not found
  ○ waku: Not found
  ○ @parcel/rsc: Not found
  ○ @vitejs/plugin-rsc: Not found
  ○ rwsdk: Not found

========================================
Results:
========================================

VULNERABILITIES DETECTED:

✗ VULNERABLE: React 19.0.2 is affected
  Patch to: 19.0.3, 19.1.4, or 19.2.3
  ⚠ NOTE: Version 19.0.2 had incomplete patches and is still vulnerable to CVE-2025-67779

✗ VULNERABLE: react-server-dom-webpack 19.0.2 is affected
  Update to patched React 19.x version (19.0.3, 19.1.4, or 19.2.3)
  ⚠ NOTE: Version 19.0.2 had incomplete patches and is still vulnerable to CVE-2025-67779

════════════════════════════════════════
STATUS: VULNERABLE
════════════════════════════════════════

Vulnerability Details:
• CVE-2025-55184 & CVE-2025-67779 (CVSS 7.5 - High):
  Denial of Service - Malicious HTTP requests can cause infinite loops
  that hang the server and consume CPU resources

• CVE-2025-55183 (CVSS 5.3 - Medium):
  Source Code Exposure - Malicious requests can expose Server Function
  source code containing hardcoded secrets (runtime secrets are NOT affected)

Recommended Actions:
1. Update React to a patched version (19.0.3, 19.1.4, or 19.2.3)
2. Update all react-server-dom-* packages to patched versions
3. If using previous patches (19.0.2, 19.1.3, 19.2.2), upgrade immediately
   as these versions had incomplete patches and remain vulnerable
4. Run: npm audit fix --force (or yarn upgrade)
5. Review Server Functions for hardcoded secrets that may have been exposed

References:
- https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components
- CVE-2025-55184: https://nvd.nist.gov/vuln/detail/CVE-2025-55184
- CVE-2025-67779: https://nvd.nist.gov/vuln/detail/CVE-2025-67779
- CVE-2025-55183: https://nvd.nist.gov/vuln/detail/CVE-2025-55183

Clear. Actionable. Impossible to misunderstand (fingers crossed 🤞)

What I learned this time

1. Patches can be vulnerable too

This was a harsh reminder that security is iterative. Just because you patched doesn't mean you're safe. In this case:

• Dec 3: Critical RCE disclosed, patches released
• Dec 11: Those patches were incomplete, new patches released

Always verify patch completeness and watch for follow-up advisories.

2. Version ranges need careful testing

When I wrote the first script, I focused on exact version matches. This time I had to handle ranges that included previous patch versions:

# Before: 19.0.0 was vulnerable
# After: 19.0.0, 19.0.1, AND 19.0.2 are all vulnerable

if version_compare "$main_version" ">=" "19.0.0" && version_compare "$main_version" "<" "19.0.3"; then
    return 0  # All vulnerable
fi

Semantic versioning comparison isn't just about being correct it's about being comprehensively correct.

3. Communication is security

Half of security is fixing the problem. The other half is making sure people know they need to fix it.

That's why I added special warnings for incomplete patches:

⚠ NOTE: Version 19.0.2 had incomplete patches and is still vulnerable to CVE-2025-67779

Without this message, developers running 19.0.2 might think "I'm on the patched version, I'm fine!" and never update.

4. Reusable infrastructure pays off

Because I built the first CVE checker with good structure, adding support for the new CVEs took about 30 minutes instead of 3 hours:

• ✅ Semantic version comparison: Already working
• ✅ Package detection logic: Reusable
• ✅ Output formatting: Just needed new text
• ✅ CI/CD integration: Still works perfectly

Good architecture isn't about predicting the future. It's about making the unpredictable easier to handle.

The reality check

After running this on my projects:

Personal portfolio: ❌ Vulnerable (upgraded to 19.0.2 last week, now vulnerable again) The Tiki Social: ❌ Vulnerable (upgraded to 19.0.2 last week, now vulnerable again) VA.gov Frontend: ✅ Safe (still on React 18.x, dodging all this drama)

So one of my projects needed another emergency patch. Eight days after the last one.

This is why we can't have nice things. 😅

The timeline is wild

Let's recap the chaos:

• Nov 29, 2025: RCE vulnerability (CVE-2025-55182) reported
• Dec 3, 2025: First patches released (19.0.1, 19.1.2, 19.2.1)
• Dec 3, 2025: Source code exposure (CVE-2025-55183) reported by Andrew MacPherson
• Dec 4, 2025: Initial DoS (CVE-2025-55184) reported by RyotaK
• Dec 6-7, 2025: Issues confirmed, initial fixes created
• Dec 8, 2025: Hosting providers notified
• Dec 10, 2025: Provider mitigations in place
• Dec 11, 2025: New patches published (19.0.3, 19.1.4, 19.2.3)
• Dec 11, 2025: React team discovers CVE-2025-67779 (incomplete patches)

So in 8 days, we went from:

• ✅ Safe (React 19.0.0)
• ❌ Vulnerable (CVE-2025-55182 discovered)
• ✅ Patched (19.0.1)
• ❌ Incomplete patch (19.0.2 released)
• ❌ New vulnerabilities discovered (CVE-2025-55183/55184/67779)
• ✅ Actually patched (19.0.3)

React Server Components are having a rough month.

Should you use React Server Components?

This is the question everyone's asking. My take:

Yes, but...

• ✅ Use them in production if you keep dependencies updated
• ✅ Implement proper security monitoring
• ✅ Run automated CVE checks in CI/CD
• ❌ Don't use them if you're on a slow update cycle
• ❌ Don't use them if you can't monitor security advisories

Server Components are powerful. But power requires responsibility. If your team can't commit to rapid security updates, stick with client-side React for now.

Try the new script

The updated script is available on GitHub: check-cve

# Quick check
curl -O https://raw.githubusercontent.com/asg5704/check-cve/main/check-cve-2025-55183-55184-67779.sh
chmod +x check-cve-2025-55183-55184-67779.sh
./check-cve-2025-55183-55184-67779.sh

Or add it to your CI/CD pipeline to catch vulnerable deployments automatically.

Key takeaways

1. ✅ Patches can be incomplete - Don't assume the first patch is the last patch
2. ✅ Watch for follow-up advisories - Security disclosures often come in waves
3. ✅ Automate vulnerability detection - Manual checks don't scale
4. ✅ Build reusable tools - Good infrastructure pays dividends when chaos strikes
5. ✅ Communicate clearly - Users need to know WHY they need to update, not just THAT they need to update
6. ✅ React 19.x is having a moment - Maybe wait for 19.0.4 before adopting? 😅

What's next?

At this rate, I'll have a full CVE checker framework by New Year's. Maybe I'll add:

• Generic CVE definition format (JSON/YAML configs)
• Support for other package managers (pnpm, Bun)
• GitHub Action for automated PR comments
• Slack/Discord webhook notifications
• Historical vulnerability tracking

Or maybe I'll just keep writing Bash scripts at 9AM when React announces CVE round 3. 🙃

Stay safe out there. Update your dependencies. And maybe set up a Google Alert for "React Server Components vulnerability".

---

Related Posts:

• Detecting for CVE-2025-55182/66478 vulnerabilities
• Building OAuth Guardian: Part 1

---

Questions? Concerns? Found another React CVE? Open an issue on GitHub or reach out on LinkedIn.