"Our site was built for us three years ago, and we haven't touched it much since. It displays without issues, so there's been no reason to touch it"—this is the situation we hear most frequently when speaking with companies that own websites. As long as it displays, it looks like it is working. In fact, on the surface, nothing is broken.
The problem is that the interior grows dangerous while appearances remain unchanged. The React vulnerability disclosed in late 2025, commonly known as React2Shell (CVE-2025-55182), carries a severity CVSS score of 10.0, the absolute maximum. A patched version was released almost simultaneously with its disclosure. Even so, now in July 2026, reports have surfaced from technical communities that traces of attacks were found when investigating environments left unmaintained for long periods. This means there are still production sites where holes that could have been plugged more than six months ago remain wide open.
Why React2Shell Is So Dangerous: Hijacked While Rendering Remains Normal
What makes this vulnerability tricky is its broad scope of impact. React2Shell is a remote code execution flaw originating in React Server Components (RSC) that allows arbitrary code execution on the server side—the kind of vulnerability that can escalate to website defacement, data exfiltration, or a foothold into internal corporate networks. Furthermore, applications utilizing RSC architecture can be susceptible even if the company did not write the relevant features directly. Particular caution was warranted when using Next.js in default configurations (Trend Micro's Analysis of CVE-2025-55182).
Moreover, this is not merely theoretical danger. As early as January 2026, JPCERT/CC issued an alert noting that they had confirmed incidents in Japan where malware was installed by exploiting this vulnerability (JPCERT/CC). Fixed versions have already been provided as React 19.0.3, 19.1.4, and 19.2.3. If you update, it is closed. If you do not update, it stays open. Something that simple continues to stall entirely because no one is there to perform the update.
A normal appearance is no evidence of security. For an attacker, there is no reason to disrupt the display of a compromised website. In fact, going unnoticed is far more advantageous. The state of "leaving it untouched because it displays without issues" is, in truth, the very hardest state in which to detect a problem.
The Vacuum Created by "Build-and-Done" Contracts
The reason things remain unmaintained for over six months is, in many cases, simply that it is nobody's job. If the contract with the agency concluded upon delivery, subsequent library updates lie outside the scope of that agreement. If there are no internal engineers, there is no channel through which information about necessary updates reaches the organization. Without malice or negligence, an empty gap emerges simply because no one is assigned responsibility.
This vacuum occurs in the exact same manner for sites using CMS platforms like WordPress. When core software or plugins require emergency updates, it is undefined who notices and who applies them. This is the exact same structural issue addressed in What Abandoned Sites Must Do Regarding Critical WordPress Core Vulnerabilities. Whether the underlying technology is React or WordPress, the fact remains that as long as you build by borrowing components, updates will be required due to circumstances on the component side. An overview of the comprehensive risks posed by this chain of "borrowed components" is detailed in our Article on Software Supply Chain Attacks.
Four Questions to Check in Maintenance Contracts
Merely saying "we have a maintenance contract" is not enough. What the term "maintenance" refers to differs completely from company to company. Open your contracts and estimates, and verify whether the following four points can be determined. If they cannot, that is ambiguity you should resolve right now.
- Who monitors vulnerability disclosures? When a critical vulnerability appears in technology used on the site, is it the agency's responsibility or your own to detect and notify? An agreement stating "we will respond upon notice" practically means no one is monitoring at all.
- How are turnaround times for emergency updates defined? Is there an explicit deadline based on severity (for example, within three business days for critical issues)? If the contract covers only scheduled monthly tasks, the vulnerability could remain unpatched for up to a month after disclosure.
- Are update tasks included in the maintenance fee, or quoted ad hoc? A contract that excludes updates is not inherently unreasonable, but "quoted each time" introduces decision-making delays that inevitably cause lag. You need to decide upfront how operations will be handled during emergencies.
- Is there a staging environment? Without a place to verify that updates will not break the site, you are left with two choices: applying them directly to production or avoiding updates out of fear. In reality, organizations tend to fall into the latter.
These four points can also be used directly as requirements when ordering new website development. Rather than focusing solely on deliverables, determine upfront how the post-delivery state will be maintained. Regarding what and how much to verify during acceptance, please also refer to Acceptance Testing Approaches When Receiving Ordered Systems.
Touching on costs, choosing based solely on the criterion of "cheaper maintenance is better" inevitably results in a contract where virtually nothing is done. Check how many hours of work are included in the monthly fee and whether those hours can be used for emergency responses. If you compare unit prices without verifying this, when an emergency arises, you will be met with "that requires a separate quote," and several days will vanish in deliberations and purchase orders. Confirming explicitly before signing whether lower cost means "merely a contact desk to accept inquiries" or "active monitoring and preemptive action" is a critical difference.
An Inventory You Can Do Today
Before diving into contract discussions, start by understanding your current situation. List all websites and web systems your company owns, and write down for each: "When was the last update performed?" and "Is there someone we can ask to do it now?" Simply creating this two-column table makes it immediately obvious where the gaps are.
In many companies, small campaign landing pages or recruitment sites launched several years ago surface first. While the main corporate site is maintained, such peripheral sites survive without falling under anyone's jurisdiction. In the eyes of an attacker, those represent the easiest entry points. Sudden outages due to expired certificates occur through this exact same channel, so conducting an inventory alongside Preparing for Shortened SSL Certificate Validity Periods is efficient.
"We don't even know what our company's site is built with" or "We have lingering sites with no one to handle maintenance"—GleamHub can assist starting from untangling such situations. Please consult us for everything from assessing your current state to deciding whether to rebuild or extend lifecycle via maintenance. Because the optimal approach varies depending on requirements, we provide customized estimates. You can contact us via Contact Us.
Sources
- About React Server Components Vulnerability (CVE-2025-55182) — JPCERT/CC
- Analysis of React2Shell "CVE-2025-55182", PoC Confusion, and Spread of Exploitation — Trend Micro
- New Vulnerability in React: React2Shell Measures Inadequate, Updating to Latest Version Urged — Mado no Mori
- React2Shell Continues to Attack Cloud Infrastructure — SB C&S DevOps Hub
