ChatGPT Health is handling around 40 million health queries a day. Claude for Healthcare shipped to production in January 2026. Mayo Clinic and Microsoft just announced they are training a frontier model on 54 million de-identified patient records. Clinical AI is not a pilot program anymore. The governance infrastructure meant to catch degradation, assign accountability, and validate these systems before they reach patients remains voluntary, institution-dependent, and largely unbuilt — a structural gap the broader clinical AI governance architecture must bridge.
Financial services went through this already. In 2011 the Federal Reserve and the Office of the Comptroller of the Currency issued SR 11-7, a supervisory guidance that required US banks to maintain a complete model inventory, run independent validation, and continuously monitor every model in production. It assigned named roles: model owner, model validator, model risk committee. It was not optional. It was not aspirational. It was the architecture that emerged after the 2008 crisis made clear what happens when models operate without governance.
Healthcare is assembling its own frameworks in real time, through voluntary efforts like HAIRA and CHAI, while financial services has 15 years of mandatory infrastructure sitting one industry away. Healthcare can focus on what already works: practices that transfer without waiting for a healthcare-specific regulatory mandate.
SR 11-7 rests on three pillars: a mandatory model inventory, independent validation, and ongoing monitoring. Every model a bank deploys gets validated before production and re-examined on a regular cycle. Goldman Sachs ran Claude through exactly this process when it embedded Anthropic engineers over six months to co-develop autonomous agents for accounting and compliance. The governance was not an afterthought. It was the precondition for deployment.
Your health system operates without a comparable regulatory mandate. The Coalition for Health AI and The Joint Commission published joint guidance in September 2025, the first formal framework from a US healthcare accreditation body. The HAIRA maturity model, published in Nature in 2026, spans five levels across seven governance domains. But both are voluntary. You decide your own depth, and the result is wide variation in safety posture: 63% of healthcare organisations have no AI-governance policies in place, and shadow AI is present in 40% of hospitals.
The difference comes down to regulatory architecture, and that architecture transfers. Financial services governance is mandatory and model-level. Clinical AI governance is voluntary and institution-level, creating accountability gaps that emerging liability frameworks for clinical AI are only beginning to address. That produces different safety outcomes.
You can adopt several practices without waiting for a healthcare-specific regulatory mandate. Champion-challenger testing is the most directly transferable (more on that below). The Horizon Scan 001 report on AI governance in regulated industries provides the cross-industry analysis.
On 17 April 2026 the Federal Reserve issued SR 26-2, superseding SR 11-7 and modernising model risk management. It shifts toward materiality-based validation and explicitly places generative and agentic AI outside its scope, signalling future regulatory treatment elsewhere — a gap the FDA’s static-device regulatory model is not yet equipped to fill. The architecture evolves. You can borrow the architecture without waiting for the regulatory trigger.
Agentic AI means multi-agent architectures where LLMs are augmented with tool use: database queries, calculation, guideline retrieval, structured workflows. The pitch is that these systems address the “last mile” problem of clinical AI. Here is what that problem looks like in practice: an LLM might output “patient appears to have early sepsis,” but your EHR needs a structured alert with a risk score, relevant vitals, and a suggested protocol. Raw LLM output is unstructured text. Clinical decision support needs structured, coded data. That gap is the last mile.
The evidence says agentic AI closes some of that gap, but the improvement is real and small. A Nature benchmarking study found that OpenManus, using a Llama-4 backbone, reached 60.3% on the AgentClinic MedQA benchmark with more than 10 times the token usage of the baseline model. Across agentic systems, absolute accuracy gains ranged from 7% to 8.9%. On multimodal tasks, accuracy remained low at 15.5%. Response times more than doubled.
Token consumption tells the cost story in numbers anyone can understand: OpenManus used 92,954 tokens per scenario, the MedAssist variant used 168,957 tokens, while the Llama-4 baseline used 14,576. More than 10 times the compute for a single-digit percentage improvement.
There is an alternative. The four-step clinical NLP architecture, named entity recognition through to relation extraction, normalisation, and inference, is a specialised pipeline that for specific tasks outperforms general-purpose LLMs at lower computational cost. Healthcare NLP achieved 96% F1-score for PHI detection, compared to GPT-4o’s 79%. GPT-4o completely missed 14.6% of entities. The specialised system missed 0.9%.
Agentic systems also introduce failure modes that single-model evaluations do not capture: tool-use errors, inter-agent coordination failures, emergent behaviours that arise from component interaction rather than any individual model’s output, compounding the benchmark-to-bedside accuracy gap already documented in clinical AI deployment. Gray Swan AI’s benchmark of 22 frontier AI agents observed nearly two million prompt injection attempts, with over 60,000 successful.
The governance question is what level of evidence you should require before deploying a more complex, more expensive system for a marginal gain. Open-source frameworks like OpenManus and Manus lower the barrier to clinical experimentation, making the question pressing because deployment can happen outside institutional controls. Your governance framework should require evidence of superiority before approving architectural complexity — the same standard the accuracy problem driving governance reform demands of clinical AI evaluation as a whole.
The evidence-standard question gets sharper when you consider the scale of what is already under construction. Which brings us to Mayo Clinic and Microsoft.
On 2 June 2026 Mayo Clinic and Microsoft announced a collaboration to develop and deploy a frontier AI model for healthcare. The model will be trained on Mayo’s de-identified clinical health data and owned by the clinic. Microsoft described it as “building something healthcare has never seen before.” The scale alone makes it the largest known clinical AI data governance experiment.
The partnership tests every governance dimension simultaneously. First, data governance at scale: 54 million de-identified patient records. De-identification is a risk mitigation, not a guarantee. Re-identification risk increases with dataset size and linkage potential. Researchers have re-identified individuals from supposedly anonymised health datasets by cross-referencing with public records. What consent model applies to retrospectively used records? Can patients opt out? How do the Common Rule, HIPAA, and state privacy laws interact when AI model training is the use case?
Second, the regulatory question. The FDA released updated CDS guidance in January 2026 that relaxed key medical device requirements. Many generative AI tools that would have required FDA sign-off can now reach clinics without FDA vetting. What we know: the FDA’s CDS guidance carves out space for clinical decision support software that is not device-level. What is unresolved: whether a frontier model trained on 54 million population-level records falls inside or outside that carve-out. Does the current regulatory framework accommodate frontier-scale models trained on population-level clinical data?
The production context sharpens the question. ChatGPT Health, which tailors responses to users’ uploaded medical records, and Claude for Healthcare are already deployed. The governance frameworks described across this cluster, institutional committees, voluntary frameworks, episodic validation, are being asked to regulate systems that are not prospective. They are live.
The partnership is a stress test. It asks whether voluntary institutional governance can scale to 54 million records, and whether the architecture healthcare has built so far can catch what a frontier model might get wrong.
The three-lines-of-defence model separates frontline business units that own AI risk from independent oversight functions and from internal audit. In financial services, the first line is the business units that operate models day to day. The second line is independent risk oversight: validation, monitoring, and challenge. The third line is internal audit, providing assurance that lines one and two are functioning. Every line has a named owner. McKinsey’s 2026 AI Trust Maturity Survey found that only about a third of organisations reach governance maturity level three or higher.
Healthcare has a diffuse ownership problem. When an AI-influenced clinical decision causes harm, who is accountable? The clinician who used it? The IT department that deployed it? The vendor who built it? Without named owners, each team points elsewhere. The Horizon Scan 001 report describes it bluntly: product owns the model, engineering owns the infrastructure, compliance owns the policy, and when a decision is challenged the accountability dissolves.
Mapping the three lines to your health system is straightforward. Clinical departments are the first line: they use the AI, they own the risk. A centralised AI governance function is the second line: independent validation, champion-challenger testing, drift monitoring. Your board risk committee is the third line: assurance that the governance system works. For smaller health systems that cannot staff a dedicated second line, the HAIRA maturity model provides a tiered readiness assessment. The model scales down as well as up. Shared services and regional collaboratives are a practical starting point.
Champion-challenger testing is a core SR 11-7 technique. You run a candidate model (the challenger) in parallel with your production model (the champion) on live data, compare performance, and switch only when the challenger demonstrably outperforms. It is the most directly transferable governance practice clinical AI has not adopted, and it requires only monitoring infrastructure, not regulatory change.
Healthcare already has the building blocks. Shadow deployments, sometimes called silent evaluation, are used across the clinical AI literature as a pre-deployment risk evaluation method. The infrastructure and the mindset already exist. What is missing is systematisation: turning an ad hoc evaluation step into a governance decision point with defined comparison metrics and a formal sign-off.
Here is what it looks like in practice. Say your hospital runs a sepsis prediction model. You develop a new version and deploy it in silent mode alongside the incumbent for a defined evaluation period, three months, for example. You compare alert accuracy, false-positive rates, and clinician override patterns. Only if the challenger outperforms across your predefined metrics do you switch. No regulatory approval is required. Just operational discipline.
The limitation is that champion-challenger testing assumes model stability during the comparison period. Agentic systems that recalibrate autonomously challenge that assumption, which is why shorter evaluation windows or continuous comparison may be necessary. The SR 26-2 modernisation moves toward materiality-based validation rather than default annual cycles, a direction worth following.
Continuous monitoring catches degradation that point-in-time validation misses. The Erasmus MC study by van der Vorst and colleagues, published in BMJ Digital Health, proved this: an AI surgical-discharge tool was monitored across 6,800 admissions over 33 months. The AUC remained stable at 0.82. The performance metric looked fine. But input variables had silently drifted. New data-pipeline errors had appeared. Average respiratory rate had increased at one hospital. The model was generating predictions for patient profiles it had never seen during training.
Three types of drift can degrade your models. Data drift: the distribution of inputs shifts. Accuracy drift: the outputs degrade. Concept drift: the relationship between inputs and outputs changes. Each requires different monitoring, and the Erasmus MC study showed that tracking performance metrics alone is not enough. You need statistical drift dashboards that flag distributional shifts long before accuracy drops.
The FDA’s Total Product Lifecycle framework already requires post-market surveillance for AI-enabled medical devices. But most health system IT functions are not structured to deliver it. The gap is operational, not regulatory. You can implement combined univariate and multivariate drift dashboards with open-source tooling. Predefined thresholds keep the response proportionate: minor drift triggers increased monitoring, moderate drift schedules retraining, severe drift pauses clinical use pending investigation.
Continuous monitoring is the prerequisite for everything else. Champion-challenger testing, tiered validation cadences, and agentic AI safety controls all depend on monitoring infrastructure. Financial services built this infrastructure because regulation required it. You can build it because the evidence says you need it.
The architecture clinical AI governance needs already exists — and the regulatory architecture and accountability systems to institutionalise it are the subject of ongoing governance reform. Financial services built it over 15 years, stress-tested it through the 2008 crisis, and operationalised it through specific practices you can adopt today.
Three lines of defence solves the diffuse ownership problem by naming accountable owners at every level. Champion-challenger testing gives you a decision framework for model switching that requires only operational discipline. Continuous monitoring is your safety net, the only mechanism that catches degradation before patient harm occurs. Together they form a governance stack any health system can begin implementing.
Acknowledge what does not transfer. SR 11-7’s regulatory mandate does not extend to healthcare, and a voluntary adaptation of financial services practices is not the same as mandatory governance. But it is better than the current patchwork. And the highest-priority investment is clear: continuous monitoring infrastructure, because it enables everything else, and the Erasmus MC evidence proves that without it, degradation is invisible.
Financial services built mandatory governance infrastructure after the 2008 crisis demonstrated what happens without it. Healthcare can adopt that infrastructure before its own catastrophe forces the same outcome. ChatGPT Health, Claude for Healthcare, and the Mayo-Microsoft partnership are not waiting for governance to catch up. The question is whether you will adopt what already works, or learn the same lessons the hard way.
SR 11-7 is the Federal Reserve’s 2011 supervisory guidance that requires US banks to maintain a comprehensive model risk management framework for every model in production. It mandates a complete model inventory, independent validation, ongoing monitoring, and defined accountability roles including model owner, validator, and risk committee. It matters for healthcare because it demonstrates that mandatory, model-level governance is operationally feasible, and its architecture transfers without waiting for a healthcare-specific regulatory mandate.
The 2008 crisis is precisely why SR 11-7 exists. Financial services governance was not built on superior foresight; mandatory model risk management emerged from catastrophic failure. The lesson for healthcare is not that banking got it right but that governance infrastructure was built after disaster, at enormous cost. Healthcare has the opportunity to build governance before, rather than after, a patient-harm crisis forces regulatory intervention.
Champion-challenger testing is among the lowest-cost governance practices available. It requires monitoring dashboards, defined comparison metrics, and a governance decision point, not new regulatory approval or expensive software. Most hospitals already run shadow deployments of clinical AI tools before full adoption. The incremental cost is primarily operational: staff time to define metrics, review comparison reports, and make switching decisions. No capital investment is required.
When drift is detected, the response depends on severity. Minor data drift may trigger increased monitoring frequency. Significant accuracy drift should pause the model’s clinical use pending investigation and recalibration. The Erasmus MC study proved that input variables can shift while aggregate performance appears stable, so drift detection must trigger a structured governance response, not just an alert. Without a pre-defined escalation pathway, monitoring adds noise without improving safety.
No. De-identification reduces but does not eliminate re-identification risk, particularly at scale. The Mayo Clinic partnership involves 54 million records, and re-identification risk increases with dataset size and linkage potential. Researchers have re-identified individuals from supposedly anonymised health datasets by cross-referencing with public records. De-identification is a risk mitigation, not a guarantee, and governance frameworks must account for residual re-identification risk.
The governance principles are the same, but implementation can be tiered. Smaller health systems may not staff a dedicated second-line validation function, but they can share services through regional collaboratives, adopt phased timelines, and prioritise the highest-value practices first, starting with champion-challenger testing and continuous monitoring. The question is not whether to govern clinical AI but how to govern it proportionately to the organisation’s AI deployment footprint.
No. Production clinical AI systems, including ChatGPT Health and Claude for Healthcare, are already deployed while regulatory frameworks remain under construction. Waiting for regulation means operating AI without safety controls in the interim. The Mayo Clinic partnership, operating at unprecedented data scale, demonstrates that clinical AI deployment is accelerating faster than regulatory development. Voluntary governance implemented now is better than mandatory governance imposed after patient harm.
Model validation is a point-in-time assessment confirming a model meets its intended performance specifications before deployment. Model monitoring is the continuous observation of a model’s behaviour in production to detect degradation, drift, and unexpected outputs as they occur. Validation confirms a model is safe before use; monitoring confirms it remains safe during use. Both are necessary because validation alone cannot predict how a model will perform across changing clinical populations over months or years.
AI agents introduce failure modes that single-model systems do not exhibit. These include tool-use errors, where an agent queries the wrong database or misinterprets retrieved information; inter-agent coordination failures, where multiple agents produce conflicting recommendations; and emergent behaviours, where the combined system behaves in ways no single component was tested for. These failures are harder to detect because they arise from component interaction, not from any individual model’s output.
Clinicians can start by asking three questions about any AI system used in their practice: who is accountable if it produces a harmful recommendation, how is its ongoing performance monitored, and what evidence supports its superiority over existing decision support tools. These questions require no regulatory change or budget to ask. They surface governance gaps that clinical teams may not have identified and create institutional pressure for accountability structures.
The EU AI Act classifies many clinical AI systems as high-risk, imposing mandatory requirements for risk management, data governance, transparency, and human oversight. Non-European health systems using AI tools from EU-based vendors, or operating European clinical trial sites, may need to comply. More broadly, the Act is shaping global regulatory development, with its risk-classification framework being studied by regulators in multiple jurisdictions as a model for clinical AI governance.
Who Is Accountable When Clinical AI Causes Patient Harm: Legal Liability ExplainedImagine a clinician follows an AI-generated treatment recommendation. The recommendation is wrong. The patient is harmed. Who pays?
The answer right now depends on your state, your contract, and circumstances no appellate court has yet ruled on. Clinical AI is embedded in diagnostics, treatment recommendations, and insurer-side utilisation review, yet tort law was designed for human decision-makers and static products, not probabilistic outputs from opaque models deployed across multiple organisational layers. A patient receives a harmful AI-recommended medication dose. Was the developer negligent in training data selection? Did the hospital fail to audit the tool’s outputs? Did the clinician fail to question a recommendation any reasonable doctor would have caught? The patient must prove which of those failures caused their injury, and that is the problem sitting at the centre of clinical AI accountability.
No single party bears clear legal responsibility. Accountability may fall on the AI developer through product liability law, on the healthcare institution through vicarious liability or corporate negligence, or on the individual clinician through medical malpractice. It depends on jurisdiction, contractual arrangements, and the specific circumstances of the harm. And because AI in healthcare is still relatively new, there is little case law on how courts will handle these claims.
The core problem is what lawyers call the liability diffusion problem. The more actors in the clinical AI decision chain, the harder it becomes to assign legal responsibility to any single one. The injured patient bears the burden of proving which party’s failure caused the harm. Ambient scribe lawsuits, putative class actions alleging that providers illegally recorded patient visits using AI-powered tools without consent, are early indicators of where litigation is heading, but they reveal uncertainty, not settled precedent.
Which legal theory applies depends heavily on how the AI tool is classified, and this is where the product-liability-versus-malpractice question becomes central.
Two competing legal theories apply: medical malpractice targets the clinician’s deviation from the standard of care, while product liability targets the manufacturer for defects in the AI tool itself. The choice between them determines who bears primary risk. If the case is framed as malpractice, the clinician is the target. If framed as product liability, the developer is. The FDA’s classification of a given AI tool is an important factor in which framework courts will apply.
When the AI is not classified as a medical device, the physician’s clinical judgment usually determines who is held accountable. If the clinician follows an AI recommendation that does not fit the clinical picture, the case is framed as a deviation from the standard of care. But if the AI tool is FDA-regulated, federal preemption can block product liability claims against the manufacturer, even when the tool plays a role in patient harm.
In practice, patients must navigate both frameworks simultaneously, suing the clinician for malpractice while potentially pursuing a product defect claim against the developer, with no guarantee that either pathway will succeed. Vendor contracts further complicate things: indemnification clauses, liability caps, and warranty disclaimers often shift risk back to the healthcare organisation regardless of which legal theory nominally applies.
Here is where the legal analysis collides with clinical reality. AI vendors market their tools as “decision support only,” a label that helps them avoid FDA regulation and product liability exposure. But in pressured clinical environments, tools marketed as support routinely become de facto decision substitution.
Why does the distinction matter? Because it determines who gets sued and who pays. When AI is genuinely supporting clinician judgment, the clinician retains accountability. When AI is effectively replacing that judgment, traditional accountability models break down: the clinician claims they just followed the tool, the vendor claims it was marketed as support only, and the patient is left without a clear remedy.
The FDA’s January 2026 Clinical Decision Support guidance refines the boundary between regulated devices and exempt tools, but the line is contested and evolving. In practice, enforcement discretion means the FDA may choose not to pursue manufacturers of certain single-recommendation tools that would otherwise require clearance. Time-critical decision-making continues to be treated as higher risk, and the more opaque the algorithm, the more likely the FDA will deem it a device.
Automation bias is a predictable cognitive response to confident-seeming AI that operates below conscious awareness. It affects clinicians regardless of expertise or diligence. A 2023 randomised crossover study found that clinicians of all expertise levels were vulnerable to automation bias, and nearly half of AI-assisted errors were associated with its misleading effect. Every clinician in the study denied having been misled.
The black box problem amplifies this. When clinicians cannot inspect how an AI arrived at its recommendation, the cognitive effort required to override it increases. In understaffed environments with productivity demands and alert fatigue, deference becomes the path of least resistance. In one documented example, gastroenterologists who regularly used an AI polyp detection tool became significantly worse at the task when performing it without assistance. That skill atrophy reduces overall system resilience.
Mitigation strategies exist. AI suppression techniques, deliberately suppressing AI output to test independent clinician accuracy, have been shown effective at reducing errors. Presenting multiple predictions rather than a single recommendation helps keep complacency in check by giving clinicians a differential diagnosis to evaluate. Confidence-threshold-based handoff points that require human review when AI certainty drops below defined levels are another practical intervention available today.
Even with mitigation strategies in place, a deeper problem persists: patients themselves are largely unaware of AI’s role in their care.
The McKinsey AI Trust Maturity Survey (2026), as reported by Horizon Search, reveals that 74% of patients trust AI-generated medical answers and 78% assume their physicians are validating those outputs. The gap between those figures represents patients who trust AI outputs but may not know whether a human clinician meaningfully reviewed them.
This is a patient safety problem. When patients assume validation that may not be occurring, they may not seek second opinions, may decline alternative treatment options, and may not report symptoms that contradict an AI-generated diagnosis. Automation complacency, the reduced vigilance that comes from assuming a system is functioning correctly, is the clinical mechanism that makes the trust asymmetry dangerous.
The regulatory gap is significant. FDA regulates device safety. State laws increasingly mandate human review of insurer-side AI. But no regulation requires that patients be told when AI contributed to a clinical decision affecting their care. California AB 3030 requires disclosure for generative AI communications. Texas mandates written disclosure before any AI system is used in treatment. But these are exceptions, not the rule. Patients cannot exercise informed consent for risks they do not know exist.
Yes, and that is both progress and a problem. State legislatures are enacting healthcare AI accountability laws at a pace Congress has not matched. Louisiana SB 246 prohibits AI from replacing healthcare providers in adverse determinations and requires licensed physician review. California’s Physicians Make Decisions Act mandates human oversight for utilisation review. Colorado’s AI Act, signed May 2026, shifts compliance toward targeted consumer disclosures and human-review rights. Indiana, Alabama, Texas, and several other states have added their own requirements to the regulatory puzzle.
The prior authorisation battleground shows why this matters. Three in four health plans now use AI for prior authorisation approvals. The 82% Medicare Advantage appeal overturn rate suggests AI is producing decisions at scale that do not survive human review. Fewer than 1% of patients appeal their denials. Most incorrect denials result in care not being delivered with no formal challenge and no institutional accountability.
The federal picture remains unresolved. The AI LEAD Act and the Trump America AI Act discussion draft indicate congressional attention but no enacted law. Meanwhile, the DOJ has established an AI Litigation Task Force charged with challenging state AI laws. ERISA already preempts state insurance regulations for self-funded employer plans covering roughly 65% of insured workers. A future federal framework could override the state-law protections currently being built.
While the legal system works through the uncertainty, two voluntary frameworks provide the most actionable governance path available. The HAIRA Maturity Model, published in npj Digital Medicine, is a five-level framework for assessing your organisation’s AI governance readiness, progressing from ad hoc use through systematised governance to optimised continuous improvement. It uses a weakest-link rule: if any domain falls short, overall placement is capped at the next lower level, reflecting the reality that a single missing control can undermine otherwise mature capabilities.
The CHAI/Joint Commission Responsible Use of AI in Healthcare certification standards, published September 2025, represent the first formal framework from a US healthcare accreditation body. They cover governance structure, model validation, training data transparency, and ongoing monitoring, all building on the NIST AI Risk Management Framework adapted for healthcare contexts.
Both frameworks are voluntary, and that is the catch. No federal mandate requires your organisation to adopt them. The gap between framework availability and regulatory obligation is where Shadow AI flourishes. Shadow AI is present in 40% of hospitals, with 63% of organisations having no AI-governance policies in place. The Three Lines of Defence model (clinical users, AI governance and compliance function, independent internal audit) is designed to prevent this, but it requires integration into existing quality and safety reporting structures: a quarterly internal audit cycle, a chartered AI governance committee, and escalation pathways that match those already built for clinical incident reporting.
While organisations build governance structures, individual clinicians need practical defences available today.
If you are a clinician using AI tools, an effective malpractice defence in AI-augmented practice is contemporaneous documentation showing that you exercised independent judgment. The key elements to document include which AI tool was used, what it recommended, whether you accepted or rejected that recommendation, and your clinical reasoning behind the decision. Courts evaluating these claims focus on whether the physician exercised the judgment a reasonable doctor would, not whether the AI was right or wrong.
This documentation practice is increasingly expected by malpractice insurers who are updating their underwriting criteria for AI-related risk. Multiple state AI laws, including California SB 1120 and Louisiana SB 246, mandate human review of AI-driven decisions. Documentation provides the proof that review occurred. Your health system should develop standardised AI documentation templates and integrate them into EHR workflows, making documentation of AI usage as routine as recording medication orders.
Governance is the structural answer. The accountability vacuum is made up of multiple intersecting failures: unsettled law, predictable cognitive mechanisms, a trust asymmetry that is a safety liability, and fragmented regulation. Each requires a different response. The reader who entered asking “who pays?” should leave understanding that the more pressing question is “what prevents the harm in the first place?” Litigation, when it eventually settles through appellate rulings, state legislation, or federal preemption, will come too late for the patient harmed today. Voluntary governance adoption and documented independent clinical judgment are the practical defences available now, and your organisation can put them in place while the legal system catches up.
Start by requesting your complete medical records, including any AI tool outputs or recommendations that were generated during your care. Ask your treating clinician directly whether AI was used in any decision affecting your treatment. Then consult a medical malpractice attorney who can assess whether the AI’s involvement creates viable legal claims against the clinician, the hospital, or the AI developer. Early legal advice matters because these cases involve multiple potential defendants and novel legal questions.
There is no federal requirement that patients be told when AI contributed to a clinical decision. California Assembly Bill 3030 requires disclosure for generative AI communications, and several state laws mandate disclosure when AI is used in utilisation review, but no comprehensive right exists. This means many patients currently receive AI-influenced diagnoses or treatment recommendations without ever being informed, creating a consent gap that consumer advocates and some legislators are working to close.
That claim is oversimplified and often misleading. AI tools can match or exceed human performance on specific benchmark tasks under controlled conditions, but real-world clinical accuracy degrades significantly. The gap between benchmark performance and bedside reliability is well documented. Furthermore, AI errors are different from human errors: a human might miss one diagnosis, but an AI with a systematic flaw can produce the same mistake across thousands of patients before anyone notices.
Clinical AI errors fall into several categories. Hallucinations are fabricated or false outputs stated with high confidence. Data shift errors occur when the tool encounters patient populations different from its training data. Contextual failures happen when the AI misses information a human clinician would recognise as clinically significant. Propagation errors arise when AI-generated documentation, such as ambient scribe notes, introduces inaccuracies that then influence downstream clinical decisions. Each error type carries different implications for determining liability.
Coverage depends on the policy, and this is an area of active change. Many malpractice carriers are updating underwriting criteria to assess AI-related risk, and some are introducing specific exclusions or premium adjustments for clinicians who use AI tools without documented independent judgment. Clinicians should verify with their insurer whether their policy covers claims arising from reliance on AI recommendations and whether any documentation requirements or coverage limitations apply to AI-augmented practice.
FDA-regulated AI tools carry pre-market validation requirements and post-market monitoring obligations that can support both safety expectations and legal claims. Tools classified as unregulated clinical decision support, however, may enter clinical use without those safeguards. When an unregulated tool causes harm, product liability claims become harder to prove because there is no regulatory baseline establishing what adequate testing looks like, and the lack of FDA oversight may weaken a failure-to-warn argument against the developer.
You can request that your care proceed without AI involvement, but there is no guarantee your request will be honoured. In some settings, AI tools are embedded so deeply in clinical workflows that opting out may not be practical. A more realistic approach is to ask your clinician whether AI was used in any decision affecting your care, what the AI recommended, and how the clinician’s independent judgment was applied. That conversation itself may improve the quality of your care.
When an insurer uses AI to deny coverage for a treatment your doctor recommended, you may receive a denial that no human clinician meaningfully reviewed. The 82% Medicare Advantage appeal overturn rate suggests many AI-driven denials do not survive independent human assessment. Practically, this means patients should always appeal an AI-generated prior authorisation denial and request documentation confirming that a licensed physician conducted the review, as multiple state laws now require.
Yes. The legal analysis differs because the standard of care for nurses and allied health professionals does not typically include an expectation of fully independent diagnostic judgment. However, if a nurse follows an AI-generated recommendation that a reasonable practitioner in that role would have questioned, liability may still attach. The specific risk depends on the professional’s scope of practice, the AI tool’s intended use, and whether your organisation’s policies define clear boundaries for AI usage by non-physician staff.
Smaller practices face distinct risks. They often lack the legal and compliance infrastructure to negotiate vendor contracts with favourable indemnification terms, making them more vulnerable to liability-shifting clauses. They are also less likely to have formal AI governance committees or documented model validation processes. The absence of these structures does not reduce their legal exposure: courts assess liability based on the standard of care, not the size of the practice, and smaller organisations may struggle to demonstrate they met that standard.
A black box AI system produces outputs without revealing the reasoning that generated them, making it impossible for clinicians or courts to inspect how a decision was reached. For a malpractice claim, this creates a practical barrier: the plaintiff must prove the clinician’s reliance on the AI was unreasonable, but neither side can examine the AI’s internal logic to determine whether the output was obviously flawed. This evidentiary problem has not yet been tested at appellate level and represents an unresolved litigation challenge.
Start by requesting your complete medical records, including any AI tool outputs or recommendations that were generated during your care. Ask your treating clinician directly whether AI was used in any decision affecting your treatment. Then consult a medical malpractice solicitor who can assess whether the AI’s involvement creates viable legal claims against the clinician, the hospital, or the AI developer. Early legal advice matters because these cases involve multiple potential defendants and novel legal questions.
There is no federal requirement that patients be told when AI contributed to a clinical decision. California Assembly Bill 3030 requires disclosure for generative AI communications, and several state laws mandate disclosure when AI is used in utilisation review, but no comprehensive right exists. This means many patients currently receive AI-influenced diagnoses or treatment recommendations without ever being informed, creating a consent gap that consumer advocates and some legislators are working to close.
That claim is oversimplified and often misleading. AI tools can match or exceed human performance on specific benchmark tasks under controlled conditions, but real-world clinical accuracy degrades significantly. The gap between benchmark performance and bedside reliability is well documented. Furthermore, AI errors are different from human errors: a human might miss one diagnosis, but an AI with a systematic flaw can produce the same mistake across thousands of patients before anyone notices.
Clinical AI errors fall into several categories. Hallucinations are fabricated or false outputs stated with high confidence. Data shift errors occur when the tool encounters patient populations different from its training data. Contextual failures happen when the AI misses information a human clinician would recognise as clinically significant. Propagation errors arise when AI-generated documentation, such as ambient scribe notes, introduces inaccuracies that then influence downstream clinical decisions. Each error type carries different implications for determining liability.
Coverage depends on the policy, and this is an area of active change. Many malpractice carriers are updating underwriting criteria to assess AI-related risk, and some are introducing specific exclusions or premium adjustments for clinicians who use AI tools without documented independent judgment. Clinicians should verify with their insurer whether their policy covers claims arising from reliance on AI recommendations and whether any documentation requirements or coverage limitations apply to AI-augmented practice.
FDA-regulated AI tools carry pre-market validation requirements and post-market monitoring obligations that can support both safety expectations and legal claims. Tools classified as unregulated clinical decision support, however, may enter clinical use without those safeguards. When an unregulated tool causes harm, product liability claims become harder to prove because there is no regulatory baseline establishing what adequate testing looks like, and the lack of FDA oversight may weaken a failure-to-warn argument against the developer.
You can request that your care proceed without AI involvement, but there is no legal guarantee your request will be honoured. In some settings, AI tools are embedded so deeply in clinical workflows that opting out may not be practical. A more realistic approach is to ask your clinician whether AI was used in any decision affecting your care, what the AI recommended, and how the clinician’s independent judgment was applied. That conversation itself may improve the quality of your care.
When an insurer uses AI to deny coverage for a treatment your doctor recommended, you may receive a denial that no human clinician meaningfully reviewed. The 82% Medicare Advantage appeal overturn rate suggests many AI-driven denials do not survive independent human assessment. Practically, this means patients should always appeal an AI-generated prior authorisation denial and request documentation confirming that a licensed physician conducted the review, as multiple state laws now require.
Yes. The legal analysis differs because the standard of care for nurses and allied health professionals does not typically include an expectation of fully independent diagnostic judgment. However, if a nurse follows an AI-generated recommendation that a reasonable practitioner in that role would have questioned, liability may still attach. The specific risk depends on the professional’s scope of practice, the AI tool’s intended use, and whether institutional policies define clear boundaries for AI usage by non-physician staff.
Smaller practices face distinct risks. They often lack the legal and compliance infrastructure to negotiate vendor contracts with favourable indemnification terms, making them more vulnerable to liability-shifting clauses. They are also less likely to have formal AI governance committees or documented model validation processes. The absence of these structures does not reduce their legal exposure: courts assess liability based on the standard of care, not the size of the practice, and smaller organisations may struggle to demonstrate they met that standard.
A black box AI system produces outputs without revealing the reasoning that generated them, making it impossible for clinicians or courts to inspect how a decision was reached. For a malpractice claim, this creates a practical barrier: the plaintiff must prove the clinician’s reliance on the AI was unreasonable, but neither side can examine the AI’s internal logic to determine whether the output was obviously flawed. This evidentiary problem has not yet been tested at appellate level and represents a significant unresolved litigation challenge.
How the FDA Regulates Clinical AI: From Approval to Real-World Safety MonitoringFor years the conversation around clinical AI regulation was simple: how do I get my device cleared? The January 2026 Clinical Decision Support guidance from the FDA shifted that conversation from how to get cleared to what happens after clearance, and the answer is not what most people assume.
Over 1,400 AI-enabled medical devices have been authorised by the FDA as of March 2026. The vast majority reached market through a pathway that requires demonstrating similarity to an existing device rather than standalone clinical evidence. Fewer than 15 percent have published real-world outcomes data. Algorithmic drift, the gradual degradation of model performance when deployment conditions change, remains undetectable at scale under the current regulatory infrastructure. The gap between what clinicians believe FDA clearance represents and what the system actually verifies is where patient harm occurs. If you are responsible for evaluating or deploying these tools, understanding that gap — and where it sits within the wider governance picture — is where your work starts.
The FDA’s Total Product Lifecycle approach is the organising philosophy that regulatory oversight must span a device’s entire lifespan, from pre-market design and clearance through post-market surveillance to eventual decommissioning. It treats 510(k) clearance or De Novo authorisation as an early checkpoint, not a finish line.
The framework rests on two practical mechanisms. Good Machine Learning Practice principles, developed with Health Canada and the UK’s MHRA, provide cross-stakeholder guidelines for data management, model validation, and performance monitoring. The Predetermined Change Control Plan lets manufacturers pre-specify planned updates so they do not need a new submission for every model retraining.
Where things changed was the January 2026 CDS guidance, which revised how the FDA interprets the four statutory criteria under the 21st Century Cures Act Section 3060. The criteria themselves, codified at FD&C §520(o)(1)(E), determine whether clinical decision-support software counts as a medical device. The software must not acquire or process medical signals from a device. It must display or analyse medical information about a patient. It must support clinician-directed recommendations with independent review capability. And the basis for its recommendations must be transparent and understandable.
The 2026 guidance made four changes to how those criteria are applied. Time-critical CDS is no longer automatically classified as a device; it is treated as a risk factor instead. Tools that offer only one clinically appropriate option now receive enforcement discretion, provided other criteria are met and the use is not time-critical. The definition of “medical information about a patient” was broadened to include lab results, genetic tests, and peer-reviewed studies rather than only data commonly discussed in practice. And Criterion 4 now requires accessible documentation about the software’s logic and data sources: the more opaque the tool, the more likely the FDA will regulate it.
STAT News characterised the guidance as a deregulatory pivot. But as one horizon scan analysis notes, the CDS pullback should be read alongside the FDA’s January 2025 draft guidance proposing a lifecycle framework for AI-enabled devices. The agency is deregulating one category while building more structured controls for another. We explored where clinical AI sits in the broader regulatory picture in AI in Clinical Settings: From Helpful Tool to Regulated System. And when those controls fail, the question of who is accountable when clinical AI causes patient harm becomes the practical reality that regulation has not yet answered.
Locked AI models have fixed parameters after deployment. Updates happen only through batch retraining and new regulatory submissions. In IMDRF terminology, a model is “in a locked state when changes are not permitted.” Continuously learning systems, by the same IMDRF definition, undergo “training that leads to change of an MLMD with each exposure to data that takes place on an ongoing basis during the operation phase.” In plain terms, the model keeps learning from every new patient case it sees.
There is no universally safer model. Locked AI guarantees reproducibility and regulatory clarity but degrades silently under dataset shift, when the deployment population drifts away from training conditions. Continuous AI can adapt to changing environments but introduces catastrophic forgetting, where retraining on new data causes loss of previously learned capabilities, and creates validation problems because performance becomes a moving target.
The real-world evidence bears this out. IDx-DR, the first autonomous AI diagnostic, was a locked model cleared through the De Novo pathway in 2018. SkinVision, a CE-marked skin cancer detection app, is also a locked model. Both showed significant performance divergence from their controlled testing conditions once deployed across varied clinical settings. We will return to the specific numbers in Section 4, because they are not anomalies; they are what happens when locked models encounter real-world variation. HeartFlow FFRCT, an AI-based coronary artery disease assessment, shows the opposite problem: its continuously updated algorithm faced regulatory friction because its clinical performance could not be determined at a single point in time, the standard that static regulatory frameworks demand.
The PCCP is the FDA’s attempt to create a middle path between these two architectures, and the EU AI Act, mandatory from 2027, classifies medical AI as high-risk but currently lacks a pathway for continuous learning. Neither jurisdiction has solved this. The locked-versus-continuous choice has direct implications for liability when AI causes harm, and financial services has governed adaptive models for decades in ways that healthcare has not yet adopted.
Post-market surveillance is the ongoing monitoring obligation after clearance. For AI devices this extends to drift detection, bias monitoring, cybersecurity vigilance, and performance degradation tracking. It is where the TPLC philosophy gets operationalised, and where the gap between philosophy and reality is most visible.
The fewer-than-15-percent statistic reflects a structural problem rather than manufacturer negligence. Most devices reach market through the 510(k) pathway, which requires substantial equivalence to a predicate device rather than new clinical evidence. Post-market publication is not a regulatory requirement. The system does not demand what it does not fund or provide infrastructure for.
The primary surveillance mechanism, mandatory adverse event reporting through MedWatch, is reactive. It captures harm after it occurs rather than detecting degradation before it causes patient injury. As one comprehensive review notes, such reports may miss many AI-specific issues because misdiagnoses or errors may not be recognised as device-related.
The emerging solution, proposed in academic literature and by organisations including the Royal College of Radiologists, is a Green/Amber/Red tiered monitoring framework. Green represents routine operation within validated bounds. Amber means drift indicators have been triggered, requiring internal root cause analysis. Red signals a material safety concern requiring suspension and regulatory notification. For this to work, regulators and manufacturers need to agree on three things: what to measure, how to detect drift, and where the data comes from. None of this infrastructure exists at scale yet.
The Royal College of Radiologists usefully distinguishes post-deployment monitoring, the hospital-side activity, from post-market surveillance, the manufacturer and regulator activity. Both are necessary. Neither is resourced at scale. This surveillance gap is the regulatory dimension of the benchmark-to-bedside accuracy gap, and it is where liability questions crystallise when undetected drift causes harm — the kind of gap that accountability and liability frameworks must eventually close.
Algorithmic drift, also called model drift or dataset shift, is the degradation of model performance when deployment data diverges from training data. The causes are mundane: changing patient demographics, new imaging equipment, evolving clinical practices, emerging disease presentations. The effects are not: a model that was accurate at clearance becomes progressively less so, and the degradation may go undetected.
Drift comes in two forms worth distinguishing. Data drift, or covariate shift, happens when input feature distributions change while the underlying clinical relationships remain stable. If a model was trained on patients averaging 55 years old and the deployment population averages 62, performance degrades even though the clinical relationships have not changed. Concept drift is more insidious: the relationship itself changes, as when pre-COVID symptoms that reliably indicated pneumonia began indicating COVID-19 with the same features.
Catastrophic forgetting is the extreme case for continuously learning systems: new data overrides previously acquired knowledge.
Now the case studies. IDx-DR’s pivotal trial reported 87.2 percent sensitivity and 90.7 percent specificity, but a large German study of 875 patients found that in 26.1 percent of cases the system could not analyse the image at all. The high failure rate came from miotic pupils, a deployment condition the original clearance did not anticipate. When it could analyse images, it matched ophthalmologist grading in only about 54.2 percent of cases. SkinVision, the skin cancer detection app, showed real-world sensitivity ranging from 41 to 83 percent depending on the clinical setting, with specificity of 60 to 83 percent. For every 100 lesions, up to 40 false alarms would occur. Both are locked models. Both drifted. Neither had systematic monitoring in place.
Epic’s sepsis model provides a different cautionary tale. After deployment at more than 100 hospitals, the model achieved only 33 percent sensitivity, missing two-thirds of sepsis cases. This was one documented case at one point in time, not a universal outcome, but it illustrates the scale of what can go wrong without adequate monitoring.
Causal inference for post-market surveillance is an emerging approach that attempts to disentangle true model decay from effective clinical interventions: a model that prompted better treatment might appear to fail at predicting an outcome because that outcome was prevented. Current surveillance systems cannot make this distinction. Drift is the mechanism by which the benchmark-to-bedside accuracy gap widens over time, and financial services has the operational drift detection that healthcare entirely lacks.
A Predetermined Change Control Plan is a regulatory mechanism, finalised by FDA guidance in August 2025, that allows manufacturers to describe planned future algorithm modifications, validation methods, and impact assessments in their initial marketing submission. When approved, bounded updates within the PCCP scope proceed without a new 510(k) or PMA submission.
The PCCP has three components: a Description of Modifications covering what changes are planned, a Modification Protocol detailing how changes are developed and validated, and an Impact Assessment analysing how changes affect safety and effectiveness. The Algorithm Change Protocol is the technical sub-component specifying methods for retraining, adaptation, and validation.
The PCCP is the FDA’s bridge between static-device regulation and the reality of iterative AI development. Without it, every model retraining would trigger re-authorisation, making adaptive AI commercially unworkable.
Only about 10 percent of 2025 AI clearances included an authorised PCCP. The mechanism is new, untested at scale, and does not address unanticipated changes that fall outside the pre-approved scope. The FDA usually takes 90 days to review 510(k) submissions, and it is not clear whether PCCP reviews by technical experts will happen at the same rate. About half of AI/ML SaMD submissions get an Additional Information request that stops the review clock for 30 to 60 days. Building the PCCP into the original submission is the recommended approach; bolting it on later leads to back-and-forth with FDA reviewers.
The PCCP’s insufficiency as a complete answer means healthcare organisations cannot wait. Financial services has mature model change-management governance that healthcare has not yet adopted, and PCCP-regulated updates aim to close the accuracy gap without full resubmission.
Healthcare organisations deploying clinical AI are effectively self-insuring against drift risk, with minimal regulatory guidance on what to monitor or how. You need your own governance infrastructure, and you need it before the first AI tool goes live.
Before deployment, run shadow testing where the AI tool operates silently against current clinical standards. This establishes baseline performance, error rates, and subgroup accuracy in your actual patient population. Demand from vendors published real-world outcomes data, not just pivotal trial results, plus documented performance across demographics relevant to your patients, a Software Bill of Materials for cybersecurity assessment, and a clear post-market surveillance plan.
After deployment, implement tiered monitoring with pre-defined performance thresholds. As discussed in Section 3, the Green/Amber/Red framework gives you a template: Green for routine operation, Amber when drift indicators trigger investigation, Red when safety concerns require suspension. Continuous monitoring should detect emerging biases by analysing outputs across diverse patient populations.
The HAIRA Maturity Model provides a five-level framework spanning seven governance domains, from organisational structure through monitoring maintenance. It uses a weakest-link rule: your overall level is the highest level for which every domain meets the minimum standard. To qualify for Level 3, production deployment, you need a named governance body with decision rights, documented internal validation including subgroup and fairness checks, and live monitoring with an incident-reporting pathway. Most hospitals employ predictive models but only half assess them for bias and two-thirds for accuracy. The OPTICA Tool offers the most comprehensive single evaluation framework covering the full AI lifecycle, and the NIST AI Risk Management Framework provides a complementary governance structure built around four functions: govern, map, measure, and manage.
These frameworks are the operational response to the accuracy gap between benchmarks and bedside performance. The evaluation and monitoring you put in place are what shape liability outcomes when AI causes harm, and financial services model risk management provides a mature template that healthcare has not yet adopted.
The EU regulates medical AI through two overlapping frameworks: the Medical Device Regulation (MDR 2017/745), requiring CE marking through notified-body conformity assessment with clinical benefit demonstration, and the AI Act (2024/1689), mandatory from 2027, classifying medical AI as high-risk.
The structural differences are fundamental. The FDA uses a centralised agency review. The EU uses a distributed notified-body system. The FDA’s 510(k) pathway relies on substantial equivalence to an existing predicate. The EU MDR requires direct proof of clinical benefit through a Clinical Evaluation Report. The FDA’s PCCP provides a pathway for iterative AI updates. The EU MDR currently treats AI as static software with no equivalent mechanism.
The practical implications for manufacturers targeting both markets are significant. Transitioning an FDA-cleared Class IIb software application into the EU typically takes 12 to 18 months and costs between €170,000 and €382,000. The EU AI Act carries penalties up to €30 million or 6 percent of global revenue, far more punitive than FDA enforcement. And the AI Act requires that training and testing data sets come from multiple clinical sites reflecting variations across ages, genders, and ethnicities.
HeartFlow FFRCT, introduced in Section 2, is the paradigmatic case of adaptive AI confronting static EU regulation. Because its algorithm was constantly updating, its clinical performance could not be determined at a single point in time as the MDR requires. The FDA’s PCCP pathway was designed specifically to accommodate this kind of system. The EU has no answer for it yet, though the AI Act may eventually pave the way for specialised pathways for continuous learning AI.
The burden on healthcare organisations is not unique to the US regulatory model. The EU’s approach creates the same gap through different mechanisms. Neither system has operationalised lifecycle surveillance for adaptive AI. This places clinical AI regulation in the wider global governance picture, and again, financial services governance models transcend these jurisdictional boundaries in ways healthcare governance has not yet matched.
The FDA’s Total Product Lifecycle philosophy is the right idea: regulation must span a device’s entire lifespan, not end at clearance. The operational infrastructure to deliver on that philosophy does not exist. Algorithmic drift cannot be systematically detected under current regulatory architecture in any jurisdiction. The PCCP is an innovative partial answer, but with 10 percent adoption and no capacity to handle unanticipated changes, it cannot close the gap alone.
What this means for you: if you are deploying clinical AI, you are the de facto safety net. The governance infrastructure across healthcare offers the frameworks to build what you need — but the question is no longer whether a device has been cleared. It is who is watching it now, and with what tools.
No, and the distinction is important. FDA clearance refers to the 510(k) pathway where a device is found substantially equivalent to an existing predicate, without requiring new clinical evidence. FDA approval refers to the PMA pathway for high-risk devices, which does require independent clinical data demonstrating safety and effectiveness. About 95 to 97 per cent of AI medical devices are cleared not approved, meaning most have reached market by demonstrating similarity rather than standalone clinical benefit.
Most AI medical devices use the 510(k) pathway, which typically takes 90 to 180 days from submission to FDA decision. However, the preparatory phase (documentation, testing, predicate device analysis) often spans 12 to 18 months beforehand. De Novo classification for novel devices takes longer, and PMA approval for high-risk AI can exceed two years. Including a Predetermined Change Control Plan in the initial submission adds additional review time.
No. Under the 510(k) pathway used by 95 to 97 per cent of AI medical devices, the manufacturer only needs to demonstrate substantial equivalence to an existing predicate device. The FDA does not require head-to-head comparison against physician performance. This is a common misconception: clearance confirms the tool is similar enough to something already on the market, not that it outperforms standard care or even matches it in real-world conditions.
Ask three questions: what is the AI tool doing with my data, was it trained on people like me, and who is checking that it works correctly over time. You have a right to know whether an AI system is contributing to clinical decisions about your treatment. If the doctor cannot explain the tool’s intended use, validated population, and monitoring process, that is a reasonable basis to request care without AI involvement.
Yes. The FDA can issue a recall, withdraw clearance, or mandate a safety notification if post-market surveillance identifies material risks, including algorithmic drift that compromises diagnostic accuracy. The Total Product Lifecycle framework explicitly includes decommissioning as a regulatory endpoint. In practice, mandatory recalls of AI devices remain rare because the reactive adverse event reporting system often detects problems only after patient harm has already occurred.
It depends on the use case, and this is one of the most contested regulatory questions in 2026. General-purpose LLMs used for administrative tasks like scheduling fall outside FDA oversight. However, if an LLM analyses patient data and generates diagnostic or treatment recommendations, it may meet the medical device definition under the four Cures Act criteria examined in the 2026 CDS guidance. The FDA has not yet issued LLM-specific regulatory guidance.
Without active monitoring, they do not, and this is the core of the algorithmic drift problem. A hospital should demand that the vendor provide real-world performance data for the specific patient population being treated, not just pivotal trial results from years earlier. Internally, the hospital should implement tiered Green/Amber/Red monitoring with defined performance thresholds and run periodic validation against current clinical outcomes to detect degradation before it causes harm.
No, there is no automatic international recognition of FDA clearance. The EU requires separate CE marking under the Medical Device Regulation, and high-risk AI must also comply with the EU AI Act from 2027. The UK operates its own UKCA regime post-Brexit. The IMDRF promotes international harmonisation, but manufacturers targeting multiple markets confront separate regulatory submissions, divergent evidence requirements, and additional costs estimated at roughly €170,000 to €382,000 per transition.
The most common trigger is an adverse event report filed through the Mandatory Device Reporting system by a manufacturer, healthcare facility, or clinician. Reports of diagnostic errors, unexplained performance degradation, or patient harm linked to an AI tool can prompt an FDA review. The weakness of this system for AI is that it is reactive: it captures harm after it occurs rather than detecting algorithmic degradation before it causes patient injury.
A Software Bill of Materials is a formal inventory of every software component, library, and dependency inside an AI medical device. It matters because clinical AI systems incorporate numerous third-party and open-source components, each a potential cybersecurity vulnerability. When a critical flaw is discovered in a widely used library, the SBOM lets a hospital immediately determine whether its deployed AI tools are affected, rather than waiting for vendor notification.
The Clinical AI Benchmark to Bedside Accuracy Gap: Why 95% Scores Drop to 34% in Real DeploymentsWhen a clinical AI system scores 95% on a medical licensing exam and then gets things right only 34% of the time in a realistic diagnostic conversation, the 61-point drop exposes a measurement failure in how clinical AI is evaluated. That gap, documented by Bean and colleagues in a study of conversational diagnostic scenarios, is not something a better training run will fix. The entire evaluation infrastructure that decides which clinical AI tools reach patients needs to be rethought.
The gap has three structural roots. Benchmarks reward memorisation over clinical reasoning. The pipeline from benchmark performance to regulatory clearance proceeds without meaningful post-deployment evidence. And the space between the 95% headline and the 34% reality is precisely where fabricated medical information becomes an expected output rather than an anomaly.
The clinical AI field has spent years conflating exam performance with clinical competence, and the correction is overdue. Over a thousand AI-enabled medical devices have been cleared by the FDA and are in use right now, which makes the gap between what benchmarks predict and what actually happens at the bedside more than an academic concern. It sits at the centre of the broader clinical AI governance architecture.
The pattern is consistent. A systematic review of 39 medical LLM benchmarks found that models achieve 84 to 90% accuracy on knowledge-based exams like MedQA and USMLE, then drop to 45 to 69% on practice-based assessments. On safety-critical tasks, accuracy settles at 40 to 50%. GPT-4o managed just 34.2% in simulated diagnostic scenarios. The best model across 13 tested on PhysicianBench, which uses real EHR-based clinical tasks, achieved 46%.
The lifecycle runs in three phases. Benchmarks are created using curated, clean datasets. Models saturate them, exceeding physician performance within 12 to 18 months, but they overfit to dataset artefacts rather than learning transferable clinical reasoning. Then deployment happens, and the clean test environment bears no resemblance to messy, incomplete, multi-author EHR data.
Four mechanisms drive the collapse. Distribution shift means the populations at deployment differ from what was in the training data: a model trained on academic medical centre data may encounter a rural hospital population with different comorbidity profiles, different equipment, and different clinical practices. Data contamination inflates scores, and 88% of benchmarks lack contamination detection. Half of all benchmarks align with no formal medical standard. And the deepest problem is format: 91% of benchmarks never evaluate uncertainty handling. A multiple-choice question cannot tell you whether the model reasoned through the case or recognised a pattern in the answer options.
The emerging practice-based benchmarks try to close this gap. AgentClinic models multi-turn patient interactions with tool use and ambiguous presentations. MedAgentsBench tests EHR navigation, order entry, and multi-step clinical workflows. These reveal what static Q&A formats conceal. When models operate in environments that resemble clinical practice, the numbers tell a different story. Benchmarks use fixed datasets with known answers and no consequence for error. Real-world evaluation requires prospective monitoring across diverse patient populations, which is why the FDA’s lifecycle approach to regulating medical AI exists in the first place: pre-market benchmark performance predicts nothing about post-market clinical reality.
If individual benchmarks are broken, the evaluation pipeline behind them is incomplete. The ARISE Network, a Stanford-Harvard collaboration, released the State of Clinical AI Report 2026, the most comprehensive evidence synthesis on clinical AI evaluation to date. They examined the evidence base behind 1,200 FDA-cleared AI medical devices.
The headline finding: fewer than 15% of those 1,200 devices have published real-world outcomes data. The evaluation pipeline stops at regulatory clearance. Manufacturers obtain FDA authorisation based on pre-market testing and rarely generate post-deployment evidence. Only 6% of medical AI studies perform external validation, testing on data from different institutions or time periods.
The Epic sepsis model is a well-known example, though not the only one. Deployed at over 100 hospitals, it achieved strong internal metrics during development. In external validation, sensitivity dropped to 33%, missing two out of every three sepsis cases, and its positive predictive value fell to 12%, meaning 88% of alerts were false positives. This is what happens when you move from the lab to the ward without the evaluation infrastructure to catch the gap.
A three-level evaluation maturity framework gives this problem structure. Level 1 is static question-answer pairs, the dominant paradigm producing those 95% scores. Level 2 is simulated clinical workflows, emerging but not yet standard. Level 3 is prospective real-world monitoring with continuous drift detection, infrastructure that nobody has built at scale yet. The ARISE finding confirms the field is stalled at Level 1. As Stanford Medicine summarised, the field is “moving faster than its evaluation practices.”
For your health system, this changes procurement. Benchmark-only evidence is a red flag. You need per-task accuracy on practice-based benchmarks, external validation data from populations matching your patient demographics, and evidence of contamination detection protocols. You need to know the tool has been tested somewhere that looks like your hospital, with patients who look like your patients. Financial services learned this lesson years ago with model risk management frameworks that mandate exactly this kind of ongoing validation.
The accuracy gap has a clinical face, and it’s hallucinations. In the AgentClinic study, researchers detected 728 hallucinations across 208 clinical scenarios, a mean of 3.4 per scenario, affecting 97% of scenarios before filtering. The hallucinations included fabricated patient statements, invented test results, non-existent drug codes, and imaginary SNOMED CT identifiers. After combined interventions, diagnostically relevant hallucinations still affected about 30% of scenarios.
Hallucinations are the clinical expression of model behaviour in the accuracy-gap region, not a separate problem. When a model operating at 34% accuracy generates an output, the probability that output contains fabricated medical information is structural rather than marginal. When hallucinations intersect with safety-critical decisions, a fabricated drug code or a false-negative on a life-threatening condition, the consequences are patient harm.
The CSEDB framework tested models against 17 safety criteria across 2,069 clinical vignettes and found safety scores consistently lower than effectiveness scores. On drug interaction and contraindication scenarios, models managed 40 to 50% accuracy. These are the scenarios where getting it wrong means more than a scoring error.
Mitigation exists and helps. Retrieval-Augmented Generation grounds outputs in trusted knowledge bases by retrieving relevant medical literature before generating a response. Structured output constraints, the approach behind the Buffaly experiment, constrain models to bounded answer spaces and improved clinical term mapping from below 9% to about 80% accuracy by eliminating the possibility of fabricating codes that do not exist. Prompt engineering improves safety scores. Human-in-the-loop oversight remains a necessary backstop.
But none of these approaches eliminate the underlying accuracy gap. They reduce the damage. They do not close it. The systematic review concludes that autonomous deployment is not currently justifiable, and all implementation strategies must mandate practice-oriented validation and human oversight — the regulatory and liability dimensions the field has not yet resolved.
There is a related architectural lesson here. John Snow Labs found that a specialised 110-million-parameter BioClinicalBERT model outperformed GPT-4 by 5 to 30 F1 points on clinical named entity recognition. On the VAERS adverse-event corpus, GPT-4 scored 0.593 F1 against BioClinicalBERT’s 0.802. The Buffaly experiment confirmed the same principle from a different angle: the framework, not the model size, drives the result. Grounding models in domain-specific constraints is more effective than scaling general-purpose LLMs and hoping.
The benchmark-to-bedside gap is evidence that clinical AI evaluation is measuring the wrong thing with the wrong instruments and stopping before meaningful measurement begins. The 95% score is a measurement artefact. The 34% reality is the performance baseline.
The three revelations stack: benchmarks measure memorisation, the evaluation pipeline stops at clearance, and the gap between the two is where patient harm lives in the form of hallucinations that are not edge cases. The maturity framework makes the gap visible and gives it structure. Level 2 is emerging. Level 3 has not been built at scale. The path forward means building evaluation infrastructure that measures clinical AI performance in terms that matter in a hospital, not on a leaderboard — a challenge that demands the full clinical AI governance picture.
Clinical AI has already reached the bedside, over a thousand times. The question is whether evaluation will catch up before the gap claims patients.
Clinical AI is already embedded in real hospital workflows, not theoretical. The FDA has cleared over 1,200 AI medical devices, and models like the Epic sepsis prediction system have been deployed across more than 100 hospitals. The question is not whether these tools are in use. It is whether their real-world performance matches the benchmark scores that justified their deployment.
No, the data does not support an outright withdrawal. It supports a shift from blind trust to structured scepticism. Clinical AI tools deliver genuine value when deployed with continuous monitoring, external validation against the local patient population, and human-in-the-loop oversight. The ARISE audit found that the failure is not the technology itself. It is the evaluation pipeline that clears it for use.
Human diagnostic error rates sit at approximately 10 to 15 percent across general practice, and medical error is the third leading cause of death in the United States. The critical difference is failure mode: human errors distribute across predictable patterns of cognitive bias, while AI errors are opaque, can be confidently wrong, and cluster in safety-critical scenarios like drug interactions where models score only 40 to 50 percent accuracy. Different problems, not necessarily worse ones.
Patients should ask three questions. First, has this tool been tested on patients like me, or only on curated datasets? Second, what happens when the AI recommendation conflicts with the doctor’s clinical judgement? Third, is the hospital tracking how often the AI gets things wrong in day-to-day use? If the clinician cannot answer these questions, the tool has likely been deployed without the evidence infrastructure the ARISE audit identified as missing from 85 percent of cleared devices.
The FDA’s clearance pathway for most clinical AI tools uses the 510(k) process, which requires demonstrating substantial equivalence to an existing device, not independent proof of clinical benefit. Post-market surveillance is mandated in theory but rarely enforced with the rigour applied to pharmaceuticals. The ARISE audit found that fewer than 15 percent of cleared devices publish real-world outcomes, confirming that the regulatory system treats pre-market benchmark performance as sufficient evidence, a position the data no longer supports.
Yes, the gap widens significantly in specialties that depend on multi-turn reasoning and ambiguous presentations. Radiology and pathology, where tasks are image-based and answer formats are bounded, show smaller gaps. Emergency medicine, primary care, and internal medicine, where diagnosis requires iterative questioning, incomplete histories, and reconciling conflicting data, show the largest drops. The Bean et al. finding of a 34 percent accuracy rate comes from conversational diagnostic scenarios that mirror emergency department and general practice workflows.
A hallucination is a specific failure mode: the model fabricates information that has no basis in the input data or in medical reality, like inventing a SNOMED CT code that does not exist or reporting test results that were never ordered. A model being incorrect means it selected the wrong answer from a valid set of options. The clinical risk from hallucinations is greater because fabricated information can cascade through clinical decision-making and is harder for a supervising clinician to detect than a straightforward wrong answer.
For narrow, well-defined clinical tasks, the evidence suggests yes. The John Snow Labs finding that a 110-million-parameter BioClinicalBERT model outperformed GPT-4 by 5 to 30 F1 points on clinical named entity recognition demonstrates that domain-specific constraints beat raw scale. The Buffaly experiment confirmed the same principle: grounding a model in structured ontologies and bounded answer spaces improves accuracy more reliably than increasing parameter count. For complex multi-turn reasoning, however, the advantage narrows and both architectures struggle.
The systematic review underlying the ARISE audit states that autonomous deployment is not currently justifiable. No responsible timeline exists for removing human oversight entirely because the infrastructure for Level 3 prospective monitoring, continuous drift detection, and automated retraining does not yet exist at scale. The realistic near-term target is AI-assisted care with structured human review, not AI-replaced care. Autonomous deployment requires solving the measurement problem first, and that problem remains unsolved.
A clinician should apply three rapid checks. First, does the AI’s stated confidence align with the clinical complexity of the case? Models rarely express genuine uncertainty, so high confidence on an ambiguous presentation is a red flag. Second, can the AI cite the evidence or data supporting its recommendation? If it cannot, treat the output as a suggestion rather than a decision. Third, does the recommendation align with the patient’s actual presentation, or does it appear to be responding to a textbook version of the case? Distribution shift between training data and the patient in front of you is the most common cause of AI failure.
React2Shell Crisis: Analysing the React Server Components Security Vulnerability, Exploitation, and DefenceIn December 2025, the React ecosystem faced a CVSS 10.0 remote code execution vulnerability that required no authentication, no user interaction, and worked against default Next.js installations with zero custom server code. The vulnerability, dubbed React2Shell, exploited a framework abstraction: the React Flight protocol, designed to transparently transport component trees between server and client, had become the attack surface itself.
What followed was not a single patch cycle but six months of disclosures: four CVEs targeting the same deserialisation code path, a coordinated 13-advisory release from Vercel in May 2026, and confirmed in-the-wild exploitation by state-sponsored groups, cryptojacking operators, and initial access brokers within 48 hours of disclosure. This series maps the crisis across four dimensions — exploit mechanism, vulnerability pattern, trust-model failure, and operational defence — in articles that work together but can also be read independently depending on what you need to know first.
GreyNoise sensors, which monitor internet-wide scanning, recorded over 1.4 million exploitation attempts in a single week. Cloudforce One, observing traffic across Cloudflare‘s global network, counted 582 million hits across eight days at an average rate of 3.49 million per hour. The University of Michigan’s security team recommended sites not behind Cloudflare be taken offline — a telling indicator of real-world severity.
This crisis raises questions that extend beyond version numbers and patch schedules. Can framework abstractions that erase the client/server boundary ever be secured by treating server-side payloads as trusted? And if the default deployment is exploitable by design, where does developer responsibility end and framework vendor accountability begin?
This pillar page maps the full React2Shell crisis across four dimensions — exploit mechanism, vulnerability pattern, trust-model failure, and operational defence — and directs you to the detailed article that answers each question.
How React2Shell Turns Framework Abstractions Into Attack Vectors: The exploit chain explained: how a crafted HTTP request becomes shell command execution through the React Flight protocol’s deserialisation process.
The Recurring Deserialisation Vulnerability Pattern in React Server Components: Why four CVEs in the same code path across six months signal a systemic architectural weakness, not isolated bugs.
The React Server Components Trust Model and Why Default Next.js Was Vulnerable: How the implicit trust assumption baked into RSC architecture made default deployments exploitable and what that means for framework security accountability.
React2Shell in the Wild Exploitation Evidence and the Platform Defence Landscape: What attackers are actually doing with React2Shell access and how Cloudflare, Deno Deploy, and other platforms are absorbing the impact.
React2Shell is the informal name for CVE-2025-55182, a remote code execution vulnerability in React Server Components disclosed on 3 December 2025. It matters because it does not require a developer to make a mistake. The vulnerability exists in the framework’s normal operation. Any Next.js App Router deployment using default settings was exploitable. A single unauthenticated HTTP request containing a crafted Flight protocol payload could execute arbitrary shell commands on the server, with no user interaction and low attack complexity. The CVSS 10.0 score reflects the combination of network attack vector, low complexity, no privileges required, no user interaction, and complete confidentiality, integrity, and availability impact.
The blast radius is defined by framework adoption, not application-specific misconfiguration. Wiz Research found that 39% of cloud environments contained vulnerable instances, and 44% of all environments ran publicly exposed Next.js applications. That is not a long tail of misconfigured apps. That is the default deployment profile.
Unlike Log4Shell (CVE-2021-44228), which required a log message to reach a vulnerable Log4j instance, or Rails YAML deserialisation (CVE-2013-0156), which required an endpoint accepting YAML parameters, React2Shell required only that your application used React Server Components. That is the default for Next.js App Router since version 13.
The vulnerability emerged from a structural property of the React Flight protocol’s trust assumptions: the deserialiser was designed assuming serialised payloads were inherently trustworthy because they originated from the same codebase. No eval(), no child_process.exec(), no insecure configuration flag was involved. When Next.js deployed that deserialiser on the server side and accepted Flight payloads from HTTP requests, the trust boundary collapsed. This is the question the cluster explores: when framework abstractions designed to simplify development become the attack surface, who bears the security burden?
The CVE was reported through Meta‘s bug bounty program on 29 November 2025 by security researcher Lachlan Davidson. The React team turned around a patch in four days. By 5 December, exploitation was detected in the wild. CISA added it to the Known Exploited Vulnerabilities catalog.
Read the full story: How React2Shell Turns Framework Abstractions Into Attack Vectors covers the exploit mechanism in detail, including the thenable abuse and prototype pollution chain that makes this attack class novel.
The exploit chain has four stages. First, an attacker crafts an HTTP request containing malicious JSX properties embedded in a Flight protocol payload. Second, the server’s Flight deserialiser encounters a “thenable” (a JavaScript object with a .then() method) and eagerly resolves it, executing attacker-controlled code during deserialisation. Third, the attacker uses prototype pollution to inject properties onto Object.prototype that the framework later interprets as executable references. Fourth, the corrupted prototype chain causes the server to evaluate the attacker’s expressions, resulting in shell command execution. The entire chain executes before any application-level authentication, authorisation, or validation occurs.
React Server Components use the Flight protocol to serialise component trees — JSX, props, state, and module references — into a binary-like format that travels between server and client. When a Next.js App Router page renders, the server serialises the component tree and sends it to the client. When the client navigates or submits a server action, it sends a Flight payload back. The server-side deserialiser that reconstructs these payloads is the attack surface. Here is the insight that makes this vulnerability class different: the deserialiser runs before any framework middleware, authentication layer, or application logic. Malicious payloads execute in a pre-authorisation context. How the trust model enabled this is analysed in depth in our examination of why default Next.js was vulnerable.
In JavaScript, a “thenable” is any object with a .then() method. The language’s await keyword automatically invokes it. The Flight deserialiser uses await to resolve component data, so when an attacker supplies a thenable whose .then() callback contains malicious code, the deserialiser unwittingly executes it. Meanwhile, the attacker uses __proto__ keys in the serialised payload to modify Object.prototype globally on the server process. When the framework later checks a polluted property expecting a benign value, it finds the attacker’s injected function reference instead.
The combination — thenable auto-invocation plus prototype chain corruption — transforms data deserialisation into code execution without any explicit eval() or exec() call in user code. The attacker does not exploit application logic or developer error. They exploit the framework’s design. The Flight protocol’s chunk resolution mechanics ($id references, $@ raw references, $B blob references) were designed for server-to-client data marshalling, not for adversarial input.
The vulnerability resides in React’s reviveModel function within ReactFlightReplyServer.js. When traversing chunks during reference resolution, React failed to verify whether a requested key was an own property of the object versus an inherited prototype property. In JavaScript, obj[key] can return values inherited from Object.prototype, not just the object’s own properties. The vulnerable code used this approach, asking the untrusted object itself whether a property existed anywhere in its prototype chain rather than checking only its own properties. Trend Micro’s analysis described the effect plainly: “much like asking a burglar if they’re supposed to be in your house.”
The complete walkthrough: How React2Shell Turns Framework Abstractions Into Attack Vectors walks through every stage of the exploit chain with the technical detail you need before evaluating risk or defences.
The React Flight protocol is the serialisation format and transport mechanism that makes React Server Components possible. It streams serialised component trees, props, state, and module references between server and client. It was vulnerable because it was designed for a trusted communication channel. The original design space assumed Flight payloads originated from a React server rendering its own component tree, not from HTTP request bodies. When Next.js deployed the same deserialiser on the server side to handle client-submitted payloads (for server actions, form submissions, and client navigations), it inherited the “payloads are trusted” assumption without adding an untrusted-input validation boundary.
Unlike a REST API that returns structured JSON data, or traditional SSR that renders HTML templates, the Flight protocol transmits a serialised representation of the entire component tree, including which components to render, their props, their internal state, and references to server-side module code. That richness is the protocol’s strength: it enables the seamless server/client component model that makes RSC architecturally compelling. But that same richness — object graphs, module references, thenables, blob handles — is also what makes it an attack surface. Every feature that enables expressive component serialisation is a potential exploitation primitive.
The protocol was developed within Meta for internal use, where server-to-client communication was inherently trusted. When the protocol was open-sourced and adopted by Next.js for public-facing deployments, the trust assumption travelled with it. The server-side deserialiser was not architected for adversarial input. It lacked strict type validation, cycle detection, property allow-listing, and input sanitisation. These are not implementation oversights. They reflect a design philosophy that treated deserialisation as an internal data-marshalling operation rather than a security boundary.
This is the tension at the heart of the crisis. The Flight protocol needs to be expressive enough to represent arbitrary component trees, but expressive serialisation formats are dangerous when exposed to untrusted input. This is the same tension that produced vulnerabilities in Java’s ObjectInputStream, PHP’s unserialize(), and Python’s pickle. The difference is that those deserialisation functions required an explicit developer choice to use them on untrusted data — a well-understood antipattern. The Flight protocol deserialises by default, as part of normal framework operation, and the developer never explicitly opts into accepting untrusted input.
Deeper context: How React2Shell Turns Framework Abstractions Into Attack Vectors maps the Flight protocol’s technical surface. The React Server Components Trust Model and Why Default Next.js Was Vulnerable analyses the trust-model implications.
React2Shell differs from historical framework vulnerabilities in three ways. First, it does not require developer error. The attack surface exists in default installations with zero custom code. Second, the vulnerability is architectural rather than configurational: the Flight protocol’s deserialiser is invoked by normal framework operation, not by an explicit developer choice to handle untrusted input. Third, the exploit executes before authentication, authorisation, or application-level validation. A malicious payload reaches the deserialiser before any middleware or security layer can inspect it. This combination makes React2Shell closer to a protocol-level vulnerability than a typical application-level CVE.
Benchmark it against the vulnerabilities you are most likely using as mental models. Log4Shell (CVE-2021-44228) required a crafted string to reach a Log4j logging call. Configuration-dependent and mitigable at the logging layer. Rails YAML deserialisation (CVE-2013-0156) required an endpoint accepting YAML parameters. Opt-in by application design. PHP unserialize() vulnerabilities required a developer to call unserialize() on user input. A well-known antipattern with established defences.
React2Shell requires none of these conditions. If your application uses React Server Components, the deserialiser is active. There is no configuration flag to disable it, no function call to audit for, no middleware position where you can insert a validation layer before the deserialiser runs. This is what security researchers mean when they call it an “architectural” vulnerability. The attack surface is baked into the framework’s design, not introduced by how you use it.
The blast-radius comparison is instructive. Log4Shell’s blast radius was large because Log4j was embedded in thousands of Java applications across every industry, but each affected application had to log a user-controlled string. React2Shell’s blast radius is defined by a single architectural choice: whether the application uses React Server Components. That choice is the default for Next.js App Router, the most popular React framework. The result is a vulnerability class where the exposed population is essentially every Next.js App Router deployment that has not patched.
React2Shell also represents a new category of framework vulnerability: the abstraction-attack. Most framework vulnerabilities exploit implementation bugs — a missing bounds check, an incorrect permission check, an injection vector in a template engine. React2Shell exploits a design decision: the assumption that serialised component payloads are trustworthy. That assumption was reasonable when the Flight protocol operated within Meta’s internal infrastructure, where server-to-client communication was inherently trusted. It became dangerous when Next.js deployed the same deserialiser to handle HTTP request bodies from any client on the public internet. This category of vulnerability is likely to recur as more frameworks adopt serialisation-based protocols that blur the client/server boundary.
The full comparison: How React2Shell Turns Framework Abstractions Into Attack Vectors provides the detailed comparative analysis against Log4Shell, Rails YAML, and other benchmark vulnerabilities.
If React2Shell were a single vulnerability, it would still be significant. But it was not. Across six months, four distinct CVEs targeted the same RSC deserialisation code path: the original RCE (CVE-2025-55182), a separate protocol-level flaw (CVE-2025-66478, also CVSS 10.0), a cyclic deserialisation denial-of-service (CVE-2026-23869, CVSS 7.5), and a further deserialisation DoS (CVE-2026-23870). By May 2026, Vercel’s coordinated security release patched 13 advisories in a single batch, covering middleware bypass, SSRF, cache poisoning, and XSS alongside the RSC-specific flaws. The crisis scope reveals that the attack surface is wider than any single CVE: it encompasses the Flight protocol, the surrounding server infrastructure, and the dependency chain connecting them.
CVE-2025-66478 demonstrated a separate flaw in the RSC protocol itself — not just an implementation bug, but a design-level weakness in how the protocol handled certain payload structures. CVE-2026-23869 showed that the deserialiser lacked cycle detection: an attacker could crash the server by sending a Flight payload containing circular object references, triggering infinite recursion during deserialisation. CVE-2026-23870 continued the pattern even after the cyclic-DoS patch, revealing that each fix addressed one vector without closing the systemic weakness.
And then there were the others. CVE-2025-55184 exploited recursive deserialisation of Promises within the Flight Protocol, inducing Microtask Queue Starvation that rendered the server process comatose while keeping TCP ports open. Its fix was incomplete (CVE-2025-67779), requiring yet another upgrade cycle. CVE-2025-55183 allowed source code exposure through Server Function argument coercion. The May 2026 Vercel batch expanded the scope further: SSRF through the RSC rendering pipeline, cache poisoning through manipulated Flight responses, and XSS through the boundary where serialised components meet HTML rendering.
These are symptoms of the same underlying pattern: the Flight protocol deserialiser and its surrounding server infrastructure were under-explored at release, each patch revealed adjacent attack surface, and the complexity of the deserialisation codebase made root-cause fixes harder than targeted patches.
The advisory sequence — December 2025, January 2026, May 2026 — suggests three interpretive possibilities that are all likely true: independent researchers found different vectors on different timelines, each patch revealed adjacent attack surface to follow-up researchers, and the complexity of the deserialisation codebase meant root-cause fixes were harder than targeted patches. The pattern itself is the evidence: the attack surface was under-explored at release, and hardening it is an ongoing process, not a one-time fix.
Sonatype’s security research team put it plainly: “Don’t treat React2Shell, 55183, 55184, and 67779 as four surprises. Treat them as four early members of a React RSC vulnerability family you’ll be living with for a while.”
The full crisis scope: The Recurring Deserialisation Vulnerability Pattern in React Server Components catalogues every CVE, the version sprawl problem, and the architectural diagnosis.
The advisory cadence reflects three converging factors. First, the Flight protocol’s attack surface was larger than the initial disclosure captured. Independent researchers found different exploitation paths (DoS, source-code leaking, protocol-level RCE) on separate timelines. Second, each targeted patch revealed adjacent weaknesses to researchers who studied the fix commits. Third, the deserialisation codebase’s complexity made root-cause fixes harder than incremental patches. Each CVE addressed one exploitation vector without redesigning the trust boundary. The coordinated 13-advisory May 2026 release from Vercel was an acknowledgement that reactive patching was not closing the surface fast enough.
Unlike a simple input validation bug — where the fix is a clear bounds check and the attack surface is closed — the Flight protocol deserialiser handles a rich object graph with multiple resolution paths, reference types, and execution contexts. When researchers studied the patch for CVE-2025-55182, they identified the thenable resolution path. When that path was hardened, they identified cyclic reference handling. Each fix narrowed the surface but did not eliminate it because the deserialiser’s design — eagerly resolving structured data into executable objects — remained intact.
The version sprawl problem was significant. Different advisory waves covered different React version lines (19.0.x, 19.1.x, 19.2.x) and different Next.js release channels (14.x, 15.x, 16.x, canary). The May 2026 coordinated release required upgrading across multiple packages — react, react-dom, react-server-dom-webpack, next — rather than a single version bump. For organisations with complex dependency trees, this created a multi-stage patching process where partial upgrades could leave some attack vectors closed and others open. Vercel shipped an automated patching tool (npx fix-react2shell-next) to help operators navigate the complexity.
This is why the advisory pattern matters in practice: it is not just about whether you patched, but whether you can be confident you patched everything.
The advisory pattern analysed: The Recurring Deserialisation Vulnerability Pattern in React Server Components provides the complete version matrix and patch sequencing. The React Server Components Trust Model and Why Default Next.js Was Vulnerable addresses the architectural root cause.
React2Shell works on default Next.js installations because the App Router enables React Server Components by default. Any app/ directory with page.tsx files automatically participates in the Flight protocol. The framework serialises component trees, sends them to clients, and accepts Flight payloads back via server actions and client navigations. The server-side deserialiser that processes these incoming payloads is active by default, with no configuration flag to disable it. The attack surface is present simply by using Next.js as documented.
When you run create-next-app and choose the App Router, your application immediately has server components, server actions, and Flight protocol endpoints. The /_rsc endpoint — which handles client navigations and server action submissions — accepts Flight protocol payloads from any HTTP client. The framework does not ask you whether you want this. It is the architectural foundation of the App Router. The Flight deserialiser that processes these payloads runs in the same Node.js process as your application code, with the same filesystem access, environment variables, and network privileges. This is not a misconfiguration. It is the design.
Most developers understand that user input is untrusted and must be validated — form fields, URL parameters, API request bodies. But a serialised component tree does not feel like user input. It feels like framework internals. The Flight payload format is not documented as a public API surface; it is generated by the framework’s own serialisation code. This creates a dangerous trust assumption: if the framework generates it, and the framework receives it back, it must be trusted. The React2Shell exploit demonstrates that this assumption is false. Any HTTP client can craft a Flight payload, and the deserialiser will process it with the same trust it grants to payloads generated by its own serialiser.
The accountability question is unavoidable. When a framework’s default deployment is exploitable, the traditional security responsibility model — developers secure their code, framework vendors secure the framework — breaks down. The developer did not introduce the vulnerability; the framework’s architectural decision did. But the developer’s server is the one that gets compromised. This tension — between framework design authority and operational security responsibility — is the question the trust-model article investigates.
Next.js 13.x, Next.js 14.x stable, Pages Router applications, and the Edge Runtime are not affected. The vulnerability requires the App Router specifically. This architectural distinction is important when you are evaluating your own exposure surface.
The trust-model analysis: The React Server Components Trust Model and Why Default Next.js Was Vulnerable explores the accountability framework and vendor security posture questions. How React2Shell Turns Framework Abstractions Into Attack Vectors explains the exploit mechanism that default configurations enable.
Traditional server-side rendering (SSR) has a clear security boundary: the server renders trusted templates, and untrusted user input passes through explicit escaping and validation layers before reaching the rendering engine. The attack surface is the template engine’s handling of user-controlled data — a well-understood and actively managed boundary. React Server Components invert this. The user input is the entire serialised component tree — a rich object graph containing module references, thenables, and prototype chains — and the framework processes it as trusted data before any application-level validation can occur. The attack surface is the deserialiser itself, not the rendering output.
In a traditional Express with EJS or Rails ERB application, the rendering pipeline looks like this: HTTP request, routing, controller logic, template rendering with escaped user inputs, HTML response. The user’s data flows through explicit validation and escaping checkpoints. The template engine receives pre-sanitised inputs. Even if a developer makes an escaping error, the vulnerability is typically cross-site scripting — client-side impact — rather than remote code execution.
In Next.js App Router with server components, the pipeline is: HTTP request, Flight payload deserialisation, component rendering, serialised response. The key difference is that deserialisation happens first, before any routing, middleware, or application logic. A malicious Flight payload reaches the deserialiser intact, and the deserialiser executes logic — resolving thenables, traversing prototypes, reconstructing object graphs — based on attacker-controlled data. The attack surface is broad. Every feature the deserialiser supports is a potential exploitation primitive.
RSC’s architectural difference — deserialise first, validate later — makes its trust model more permissive than alternatives.
REST APIs make this boundary even more explicit. Every request component is untrusted: headers, query parameters, body, content type. Validation is explicit, programmable, and positioned before business logic. RSC treats the Flight payload as an internal data structure and processes it before validation can occur. JSON is “dumb” in exactly the right way: there is no deserialisation of execution contexts, no automatic invocation of client-specified code paths, no blurred boundaries between data and code. The Flight protocol needed to be smarter than JSON, capable of serialising promises, closures, and complex object graphs. That meant it needed to be more complex, more powerful, and more dangerous.
The architectural question is whether this difference is a temporary maturity gap that better input validation will close, or a property of serialisation-based protocols that will always create a pre-validation attack surface. The React2Shell cluster evidence — four CVEs in six months, each exploiting different deserialisation paths — suggests the answer is not simple.
The trust-model comparison: The React Server Components Trust Model and Why Default Next.js Was Vulnerable provides the full analysis of how RSC’s architectural choices compare to SSR and REST security models.
There are two defensible interpretations, and the React2Shell evidence supports both. The maturity argument: the Flight protocol is a young serialisation format compared to JSON or Protocol Buffers. Its deserialiser was not battle-tested against adversarial inputs because its original design space assumed trusted server-to-client communication. The four CVEs represent growing pains — a deserialiser maturing under fire.
The fundamental argument: any serialisation format rich enough to represent executable code patterns — thenables, prototype chains, cyclic references — will always have an attack surface when exposed to untrusted input, regardless of maturity. Each new deserialiser feature is a new potential exploitation primitive.
The Flight protocol needs to be expressive: it serialises component trees with module references, async values (thenables), object graphs with shared references, and blob handles. Each of these features maps to a well-known attack primitive. Module references enable code execution through the module loader. Thenables enable auto-invocation through JavaScript’s await semantics. Shared references — the $id system — enable prototype chain traversal. Blob handles enable resource confusion. No amount of input validation can eliminate these primitives without also eliminating the features that make the protocol useful.
If the protocol needs to be this expressive, and expressiveness creates attack surface, then the security problem is structural. It can be managed through defence-in-depth — sandboxing, capability dropping, WAF inspection — but not solved through deserialiser hardening alone. The recurring vulnerability pattern documented in our analysis of the deserialisation crisis reinforces this: each patch closed one vector, but the structural tension between expressiveness and safety kept producing new ones.
The React team’s 4-day turnaround on the initial patch is impressive. The fact that researchers kept finding new vectors in the same code path for six months afterwards is telling. The pragmatic question is not “is RSC secure?” — it is “is the residual risk acceptable for my deployment’s threat model, given the current state of hardening and the available platform-level defences?” The trust-model article explores this through the lens of vendor accountability and adoption risk assessment. The exploitation article provides the operational evidence to inform your evaluation.
Make your own assessment: The React Server Components Trust Model and Why Default Next.js Was Vulnerable presents both arguments in full. React2Shell in the Wild Exploitation Evidence and the Platform Defence Landscape provides the real-world data.
Exploitation began within 48 hours of the 3 December 2025 disclosure. GreyNoise telemetry recorded over 1.4 million exploitation attempts within seven days. Cloudforce One observed 582 million hits across eight days at an average rate of 3.49 million per hour. Two IPs alone generated 56% of all observed exploitation traffic in one week. The initial wave was dominated by mass scanning and opportunistic exploitation, but within the first week, evidence of targeted post-exploitation activity emerged from multiple threat hunting teams.
The attacker profile spans four categories. China-nexus groups — CL-STA-1015 and Earth Lamia — deploying espionage backdoors. DPRK-linked actors (UNC5342, also known as Contagious Interview) using EtherRAT for cryptocurrency theft, with C2 resolution through Ethereum smart contracts. Cryptojacking operators deploying XMRig miners via the C3Pool Monero mining pool. And initial access brokers deploying SNOWLIGHT, VShell, and KSwapDoor for onward access sales.
The post-exploitation malware catalogue is diverse. Huntress observed PeerBlight — a Linux backdoor — CowTunnel — a reverse proxy tunnel — ZinFoq — a Go-based implant — and a Kaiji botnet variant. Google’s Threat Intelligence Group identified MINOCAT tunneler, HISONIC backdoor, and COMPOOD backdoor. ThreatLocker even observed exploitation against IIS servers on Windows, with attackers deploying XMRig via PowerShell after initially attempting Linux commands.
A Metasploit module and Nuclei template were publicly available, lowering the barrier to exploitation. Automated scanning used identifiable User-Agents like “Nuclei – CVE-2025-55182” and “React2ShellScanner/1.0.0.” The 48-hour gap between disclosure and active exploitation reflects the availability of public tooling and the fact that attackers understood the Flight deserialiser was an architectural weak point, not an application-specific bug. Understanding the exploit mechanism itself clarifies why attackers moved so quickly: the attack surface was universal, not application-specific.
The exploitation data validates the trust-model analysis: attackers exploited it at internet scale because they understood it was a framework-level vulnerability, not a developer mistake. But the data also shows that platform-level defences — Cloudflare’s automatic WAF rules, Deno’s runtime isolation — absorbed a significant portion of the impact. The question for your organisation is not just “are we patched?” but “what is our exposure surface, and which defensive layers sit between the internet and our RSC endpoints?”
The complete exploitation picture: React2Shell in the Wild Exploitation Evidence and the Platform Defence Landscape covers the full threat actor landscape, post-exploitation payload catalogue, and IoC categories.
Platform defences fall into two strategies. Cloudflare deployed WAF rules automatically for all users — including Free tier — within hours of disclosure, inspecting HTTP traffic for malicious Flight payload patterns before they reach the origin server. The Cloudflare Workers runtime adds V8 isolate-based sandboxing that limits blast radius even if exploitation succeeds. Deno Deploy takes a different approach: its permission-based runtime denies filesystem, network, and subprocess access by default, so even if a malicious Flight payload is deserialised, post-exploitation capabilities are curtailed at the runtime level. Vercel’s response focused on framework-level patching at the source — the coordinated 13-advisory May 2026 release addressed deserialisation vulnerabilities directly.
Cloudflare’s dual-layer defence is worth understanding. The WAF layer inspects HTTP traffic at the network edge, applying signatures that detect malicious Flight payload patterns — __proto__ traversal attempts, thenable injection, chunk reference manipulation. Because Cloudflare manages these rules centrally, users received protection without any configuration changes. The Workers runtime layer provides process-level isolation: each worker runs in a separate V8 isolate with no shared memory, so a compromised worker cannot access other tenants’ data or the host system. Cloudflare describes React-based applications deployed on Workers as “inherently immune.”
There is a limitation to keep in mind: WAF signature-based detection can be bypassed through payload obfuscation. The 703-byte to 375MB payload size range observed in the wild suggests attackers are actively probing signature boundaries. Effective WAF rules need to block more than just __proto__ — the maple3142 exploit variant does not use __proto__ at all. They need to inspect $@ chunk references, resolved_model strings, constructor:constructor patterns, and _formData.get patterns.
Deno Deploy’s runtime-isolation approach is different from WAF inspection. Rather than trying to detect malicious payloads, Deno makes the post-exploitation environment incapable of executing the attacker’s objectives. A React2Shell exploit that deserialises a malicious payload and attempts to spawn a shell, write to disk, or establish an outbound connection hits the permission boundary before reaching the host.
The platform comparison is a trade-off analysis, not a winner-takes-all. Cloudflare’s approach — automatic WAF plus sandbox isolation — provides the broadest coverage because it protects all Cloudflare-proxied applications regardless of where the origin server is hosted. Deno’s approach — runtime-level capability denial — provides the strongest post-exploitation containment but only for Deno-deployed applications. Vercel’s approach — framework-level patches at the source — eliminates the vulnerability class but requires applications to upgrade, and the multi-wave advisory pattern suggests patching is an ongoing process, not a one-time event.
Microsoft published WAF rule guidance for Azure Web Application Firewall. CrowdSec released a dedicated virtual patching detection rule within hours of disclosure plus a React2Shell IP blocklist. Fortinet deployed IPS signatures (2066027, 2066028). The optimal strategy combines all three layers: deploy behind a WAF that inspects Flight payloads, run on a runtime that limits post-exploitation capabilities, and keep the framework patched.
The platform defence comparison: React2Shell in the Wild Exploitation Evidence and the Platform Defence Landscape provides the complete WAF comparison, runtime isolation analysis, and defence verification dimensions.
Five questions should guide your evaluation. First, what is your framework vendor’s current deserialiser input validation boundary — does it still assume trusted payloads, or has the Flight protocol been redesigned with an explicit untrusted-input posture? Second, what is the vendor’s security advisory process and typical patch latency for RSC vulnerabilities? Third, how does your deployment platform isolate RSC execution from the host environment — V8 isolate sandboxing, permission-based runtimes, or process-level containment? Fourth, what is your ability to deploy WAF rules that inspect Flight protocol payloads — does your CDN or API gateway understand the binary Flight format? Fifth, what is your fallback strategy if RSC adoption introduces unacceptable residual risk — can you migrate back to Pages Router or a traditional SSR architecture without a complete rewrite?
Each question maps to a dimension of the crisis that was exposed during the December 2025 to June 2026 period: the original Flight protocol’s trust assumptions, the multi-wave advisory pattern and version sprawl problem, the observed post-exploitation payloads and the platforms that blocked them, the WAF bypass techniques observed in the wild, and the reality that some organisations may conclude the residual risk is unacceptable for their threat model.
These questions are not about whether React Server Components are “safe” or “unsafe.” They are about whether the residual risk is acceptable given your threat model, deployment architecture, and operational security capability. A financial services organisation with regulatory requirements for data isolation may reach a different conclusion than a content website. An organisation already behind Cloudflare with managed WAF rules may have different residual risk than one running on bare metal.
The framework ecosystem is in active motion. The React team and Vercel have demonstrated rapid-response capability. Platform vendors have absorbed significant defensive burden on behalf of their users. The vulnerability cluster has driven deserialiser hardening that will benefit all future RSC deployments. But the structural questions — whether expressive serialisation formats can ever be secured against adversarial input without sacrificing the expressiveness that makes them useful — remain open. Your adoption decision should account for both the current state and the trajectory.
The evaluative framework: The React Server Components Trust Model and Why Default Next.js Was Vulnerable provides the full vendor-question analysis. React2Shell in the Wild Exploitation Evidence and the Platform Defence Landscape provides the operational context to ground your evaluation.
How React2Shell Turns Framework Abstractions Into Attack Vectors: The complete exploit chain: how a crafted HTTP request traverses the Flight protocol’s deserialisation process, abuses thenable auto-invocation and prototype pollution, and achieves shell command execution without exploiting developer-introduced code. Start here if you need the technical mechanism before evaluating risk or defences.
The Recurring Deserialisation Vulnerability Pattern in React Server Components: Why four CVEs in the same deserialisation code path across six months signal a systemic architectural weakness rather than isolated implementation bugs. Covers the full vulnerability cluster (CVE-2025-66478, CVE-2026-23869, CVE-2026-23870) and the multi-wave advisory pattern that revealed the attack surface’s breadth.
The React Server Components Trust Model and Why Default Next.js Was Vulnerable: The architectural analysis of why React2Shell worked on default installations: how the Flight protocol’s trusted-payload assumption, combined with Next.js App Router’s default RSC enablement, created an exploitable-by-design deployment profile. Includes the accountability framework for evaluating framework vendor security posture.
React2Shell in the Wild Exploitation Evidence and the Platform Defence Landscape: What attackers are actually doing with React2Shell access, from XMRig cryptomining to state-sponsored espionage backdoors, and how Cloudflare, Deno Deploy, and other platforms are absorbing the impact through WAF detection and runtime isolation. Read this if you are in an operational security or platform engineering role.
Suggested reading order: Start with the exploit mechanism article (ART001) for technical grounding, then the vulnerability pattern article (ART002) for crisis scope, then the trust-model article (ART003) for architectural analysis, and finally the exploitation and defence article (ART004) for operational response. If you are evaluating immediate risk to your own deployments, the trust-model and operational articles (ART003 and ART004) are the most directly actionable.
What is CVE-2025-66478 and how does it relate to React2Shell?
CVE-2025-66478 was the original Next.js-specific CVE identifier for the React2Shell vulnerability, issued alongside CVE-2025-55182 (the React-level identifier). NIST subsequently rejected CVE-2025-66478 as a duplicate. If you encounter references to the Next.js CVE number in older advisories or scanner output, it refers to the same vulnerability as React2Shell. CVE-2025-55182 is the authoritative identifier. Both React and Next.js patches are required for complete remediation.
What versions of React and Next.js are vulnerable?
React versions 19.0 through 19.2.0, and Next.js versions 14.x (App Router), 15.x, and 16.x prior to their respective patched releases, are vulnerable. The specific patched versions depend on your release line: React 19.0.1, 19.1.2, and 19.2.1; Next.js 14.2.35, 15.0.5+, and 16.0.7+. The May 2026 coordinated Vercel release added additional patches across multiple packages. Consult the official React and Next.js security advisories for version-specific guidance. The Recurring Deserialisation Vulnerability Pattern in React Server Components provides the complete version matrix.
How is React2Shell different from Log4Shell?
Both are remote code execution vulnerabilities exploiting unsafe deserialisation or log-injection in ubiquitous frameworks via single unauthenticated HTTP requests. The key difference is architectural: Log4Shell required a crafted string to reach a Log4j logging call — configuration-dependent — while React2Shell exploits a framework deserialisation path that is active by default in all Next.js App Router deployments. Log4Shell could be mitigated at the logging configuration layer; React2Shell’s deserialiser runs before any middleware or application logic can inspect the payload. How React2Shell Turns Framework Abstractions Into Attack Vectors provides the detailed comparative analysis.
Is Server-Side Rendering (SSR) also vulnerable to React2Shell?
No. Server-Side Rendering — where React components render to HTML on the server and the client hydrates the resulting markup — does not use the Flight protocol and does not expose the RSC deserialisation attack surface. SSR alone does not create React2Shell exposure. The vulnerability requires React Server Components, which are enabled by default in Next.js App Router but not in Pages Router or traditional SSR setups. The React Server Components Trust Model and Why Default Next.js Was Vulnerable addresses the SSR vs RSC distinction in detail.
What are the signs that a React2Shell compromise has already occurred?
Indicators cluster around unusual process behaviour: Node.js processes spawning unexpected child processes (especially sh, bash, curl, wget); outbound network connections from the RSC rendering process to unknown IP addresses or cryptocurrency mining pools; anomalous CPU utilisation patterns consistent with cryptomining; and Flight protocol request bodies containing __proto__, constructor, or .then patterns in positions inconsistent with normal RSC traffic. These are observable artefact categories rather than definitive indicators. Their presence warrants investigation, but their absence does not guarantee safety. React2Shell in the Wild Exploitation Evidence and the Platform Defence Landscape covers IoC categories in depth.
Should I migrate away from Next.js App Router to Pages Router?
This is a risk-acceptance decision, not a technical one. Pages Router does not use React Server Components and is not affected by React2Shell, so migrating eliminates this specific attack surface. But migration from App Router to Pages Router is architecturally significant. It may require restructuring your component tree, abandoning server actions, and losing performance benefits of RSC streaming. The decision depends on your threat model, your deployment’s exposure surface — are you behind a WAF? on an isolated runtime? — your organisation’s patching velocity, and your tolerance for architectural churn. The React Server Components Trust Model and Why Default Next.js Was Vulnerable provides the evaluative framework.
How do WAF rules actually detect React2Shell payloads?
WAF detection faces a challenge: Flight protocol payloads are binary-like structured data, not human-readable HTTP parameters. Traditional WAF rules that inspect URL query strings or form-encoded bodies will not see the exploit. Effective detection requires parsing the Flight protocol format to identify malicious patterns — __proto__ property traversal, thenable injection via .then method references, chunk reference manipulation via $id and $@ syntax, and unusual status field values. Cloudflare’s managed rules perform this parsing automatically. Payload obfuscation — varying chunk sizes, encoding variations, and reference indirection — remains an active cat-and-mouse game. React2Shell in the Wild Exploitation Evidence and the Platform Defence Landscape provides the complete WAF comparison.
Is the React ecosystem likely to see more vulnerabilities of this class?
The evidence suggests yes, for two reasons. First, the Flight protocol’s expressiveness — component tree serialisation with module references, async resolution, and shared object graphs — creates a rich attack surface that is difficult to exhaustively validate. Second, the framework trend toward serialisation-based client/server protocols — not just React, similar patterns are emerging in other frameworks — means the class of “abstraction-as-attack-surface” vulnerabilities is likely to grow. The React ecosystem’s rapid hardening pace is encouraging, but the structural tension between protocol expressiveness and adversarial safety is not unique to React and is not fully resolved by any current approach. The Recurring Deserialisation Vulnerability Pattern in React Server Components covers the pattern analysis. The React Server Components Trust Model and Why Default Next.js Was Vulnerable covers the architectural implications.
The React2Shell crisis tests whether framework abstractions that erase the client/server boundary can ever be secured by treating server-side payloads as trusted. The operational evidence shows the ecosystem is absorbing the impact through platform-layer defences: Cloudflare’s automatic WAF rules, Deno Deploy’s runtime isolation, and Vercel’s coordinated patching. But the trust-model analysis suggests the structural questions remain open.
React maintained a clean security record over 13 years. One minor XSS vulnerability (CVSS 6.1) in 2018. Then React2Shell landed, and four more CVEs followed in the same code path within six months. That pattern is not a coincidence. It is what happens when a protocol designed for internal trusted communication gets deployed on the public internet without a security boundary redesign.
The good news: the framework ecosystem is responding fast. Platform vendors are absorbing defensive burden on behalf of users who never had to configure a thing. The deserialiser hardening driven by this vulnerability cluster will benefit every future RSC deployment.
The open question: is the residual risk acceptable for your deployment, given your threat model and the platform defences available to you? That is not a question anyone can answer for you. But the articles in this cluster give you the evidence to answer it yourself.
If you need the exploit mechanism explained, start with How React2Shell Turns Framework Abstractions Into Attack Vectors. If you are evaluating architectural risk across your own deployments, read The Recurring Deserialisation Vulnerability Pattern in React Server Components and The React Server Components Trust Model and Why Default Next.js Was Vulnerable. If you are in an operational security or platform engineering role, go directly to React2Shell in the Wild Exploitation Evidence and the Platform Defence Landscape.
React2Shell in the Wild: Exploitation Evidence and Platform Defence Strategies That Stopped Real AttacksThe University of Michigan‘s operational security team did something unusual in the hours after CVE-2025-55182 was disclosed. They advised that sites not behind Cloudflare should be taken offline. Not patched quickly. Taken offline. When an academic security team publicly recommends decommissioning production infrastructure, something has fundamentally changed.
That something is the asymmetry at the heart of React2Shell: attackers needed one working exploit chain to compromise thousands of servers. Defenders needed to secure every React Server Components deployment across every platform simultaneously. Darktrace researchers put a honeypot online and watched attackers land on it within two minutes of deployment. Cloudflare recorded 582 million exploit attempts in the first eight days, peaking at 12.72 million hits in a single hour. Unit 42 identified 968,000-plus exposed React and Next.js instances.
While the React2Shell crisis from every angle provides the full strategic overview, this article answers two questions that build on each other: what actually happened in the wild, and which defensive strategies worked against it. The comparison across Cloudflare Workers, Deno Deploy, and Vercel Edge reveals that the decisive variable was platform architecture, not patching speed.
CVE-2025-55182 was disclosed on December 3, 2025. Within 30 hours, GreyNoise had documented the first in-the-wild exploitation attempts. A public proof of concept emerged, the Metasploit module followed, and by December 5 Trend Micro recorded the first Cobalt Strike beacon, the first Sliver implant, and the first cryptomining campaigns. CISA added it to the Known Exploited Vulnerabilities catalog on December 6.
The attack surface discovery was methodical. Attackers used Shodan fingerprinting, Nuclei templates, and the Assetnote react2shell-scanner to enumerate vulnerable instances at internet scale, filtering by icon hashes, SSL certificate attributes, and framework metadata. Cloudflare noted that some threat actors excluded Chinese IP space while focusing enumeration on Taiwan and Xinjiang Uygur networks.
What began as mass scanning in early December had, by January and February, consolidated into sustained campaigns. GreyNoise observed two IPs generating 56 percent of all React2Shell traffic between them. One retrieved cryptomining binaries. The other opened reverse shells directly back to the scanner on port 12323. The actor diversity, China-nexus clusters like UNC6586 alongside DPRK-affiliated operations and cryptomining operators, meant no single motivation drove the exploitation — but every campaign traced back to the same mechanism. Understanding how the exploit chain works under the hood is essential for grasping what made this campaign diversity possible.
The payload landscape reveals that the exploitation volumes represent something more structured than mass opportunism. Every category of threat actor operated through the same entry point at the same time.
Cryptominers were the most common payload. XMRig deployments targeted Node.js processes, connecting to C3pool, SupportXMR, and HashVault. Huntress documented a bash script that pulled XMRig from GitHub, installed it as a systemd service named “system-update-service,” and connected to HashVault over TLS. Alibaba Cloud specific variants uninstalled the provider’s own threat detection agent.
Cobalt Strike beacons, generated via CrossC2 for Linux targets, provided persistent access. Trend Micro found beacons installed under systemd services masquerading as “Rsyslog AV Agent Service,” with scripts containing AI-generated code and Chinese comments never removed. Sliver C2 implants followed the same pattern.
The credential harvesting was automated and indiscriminate. Cisco Talos documented UAT-10608’s campaign using TruffleHog, Gitleaks, and custom scripts to walk filesystems from working directory to root, reading every .env file, SSH key, and cloud credential. The NEXUS Listener web application catalogued credentials from over 766 servers, including OpenAI and Anthropic API keys, Stripe secrets, and Azure subscription credentials. Microsoft confirmed attackers targeted cloud IMDS endpoints across AWS, Azure, GCP, and Tencent Cloud.
Then there were the backdoors nobody had seen before. PeerBlight uses the BitTorrent DHT network for C2. CowTunnel tunnels through attacker-controlled FRP proxies. ZinFoq provides SOCKS5 proxying with timestomping, its file timestamps defaulting to 2016-01-15. Unit 42 found KSwapDoor, a P2P mesh backdoor with AES-256-CFB encryption, mimicking a kernel swap daemon. Botnet operators recruited servers into Mirai, RondoDox, and Kaiji botnets. Every category of payload, through a single deserialisation vulnerability in a framework protocol.
The defence answer changes depending on where the application runs, and why default configurations exposed so many deployments explains why the differences between platforms reveal more about architectural security than any CVE score.
Cloudflare Workers are immune to React2Shell exploitation. The Workers runtime uses V8 isolates with no shared process memory and no Node.js API surface. The process object, child_process, and require do not exist. This is architectural protection, not a patch response. Trend Micro confirmed that Edge Runtime is not vulnerable because it lacks the Node.js APIs that React2Shell RCE depends on for post-exploitation.
Cloudflare added WAF Managed Rules within hours of disclosure with default Block action across all plan tiers, creating a two-layer defence: the WAF blocks known exploit patterns at the network layer, and the V8 isolate sandbox neutralises any bypass that reaches the runtime. The limitation is that binary Flight protocol payloads challenge signature-based detection. WAF rules that block __proto__ keywords miss the minimum viable exploit entirely, and Trend Micro documented nearly 145 in-the-wild exploits with WAF bypass features.
Deno Deploy takes a different path to the same result. Deno’s security model denies filesystem, network, and subprocess access by default. Any exploit payload that lands and attempts execSync or a filesystem write hits the permission boundary before reaching the host. This is isolation at the runtime level, and it curtails post-exploitation capabilities even if deserialisation succeeds. The limitation is adoption: Deno Deploy’s market share is smaller, so fewer deployments benefit from this protection model.
Vercel’s Edge Runtime sits in a different category. As the default deployment for many Next.js applications, Vercel was the most directly affected. Its response was the coordinated May 2026 patch release across 13 advisories, fixing the deserialiser at the framework level. This fixes the root cause. Both strategies are valid, but they protect against different parts of the threat lifecycle: framework-level patching addresses the vulnerability directly, while runtime isolation contains what happens when it is exploited.
While runtime isolation limits what a compromised process can do, WAF detection aims to stop the exploit before it reaches the runtime. The effectiveness of that detection depends on a specific technical capability: whether the WAF can parse the React Flight protocol’s binary serialisation format. Most WAFs were designed to inspect HTTP headers and form-encoded bodies. React2Shell exploits live inside POST bodies as chunk references and prototype pollution chains.
Cloudflare deployed WAF Managed Rules with default Block action across all plan tiers within hours of disclosure. Users received protection without touching their configuration. The detection engineering burden was absorbed centrally.
CrowdSec’s community-driven virtual patching takes a different approach. The vpatch-CVE-2025-55182 rule correlates multiple signals: HTTP POST method, React Server Action headers, tampering with internal Flight parameters, and suspicious $@ payload patterns. The strength is speed, because practitioners encountering novel payloads can contribute signatures rapidly. The weakness is uneven coverage.
Fortinet’s signature-based approach, with IPS rules deployed through FortiGuard outbreak alerts, benefits from enterprise integration but introduces a customer-side deployment gap. Centrally published signatures still require someone to push them to production.
F5 Labs captured the core tension: most exploit attempts are constrained by recognisable behaviours that generic WAF signatures can block, such as prototype pollution keys and references to process.mainModule.require. But legitimate RSC traffic uses the same chunk reference syntax that signatures target, so aggressive Flight protocol inspection risks breaking server-rendered content. WAF operators must balance detection coverage against the risk of blocking valid traffic.
WAFs are fallible, and the payload diversity from December’s campaigns confirms that some exploits will reach the runtime. When they do, blast radius assessment maps what the compromised process could reach. Organisations that assessed their exposure across four dimensions were able to scope the damage quickly.
Runtime privilege level. The exploit inherits the full privilege set of the compromised Node.js process. Organisations that confirmed whether the process ran as root or a restricted user knew immediately whether filesystem access was unlimited. Containerised deployments add a second boundary, and teams that assessed privileged mode, hostPath mounts, and elevated capabilities understood whether container escape was feasible.
Network egress posture. Security teams that mapped what the compromised process could reach, external IPs enabling reverse shells and credential exfiltration, or egress filtering constraining communication, identified the extent of post-exploitation options. Microsoft’s observation of Cloudflare Tunnel abuse confirmed that attackers actively probe egress boundaries.
Data access scope. As the Cisco Talos documentation of NEXUS Listener confirmed, credential harvesters systematically read every configuration file from working directory to root. Organisations that assumed all environment variables, .env files, mounted secrets, and cloud IMDS credentials had been exfiltrated made better decisions than those that waited for forensic confirmation.
Lateral movement potential. Teams that mapped whether the RSC server shared a network segment with databases, internal APIs, or Kubernetes control planes understood whether harvested SSH keys and cloud IAM tokens enabled further access. These are architectural questions about deployment topology, not post-breach forensics.
The behavioural signatures persist across campaigns because they are tied to how React2Shell exploitation works, even as specific IPs, hashes, and domains age out. Security teams that hunted across four observable dimensions caught compromises that single-dimension searches missed.
Process-level indicators are immediate. Teams that looked for unusual child processes spawned from Node.js, especially sh, bash, curl, and wget originating from the server-rendering process, detected exploitation before persistence was established. Unit 42 documented the value of reviewing all child processes spawned by the node process for suspicious file operations and network connections. XMRig processes were observed masquerading as kernel threads under names like [ksoftirqd].
Network indicators include outbound connections to unknown IPs on non-standard ports, connections to mining pool domains, reverse shell callbacks on ports 12323 and 8899, and traffic to credential exfiltration endpoints. Cloudflare Tunnel endpoints emerged as a common bypass technique.
Filesystem artefacts reveal persistence. Incident responders found that checking for new systemd service files masquerading as legitimate services, crontab @reboot entries, modified shell RC files, and new SSH authorised keys surfaced compromises even when process-level monitoring had been evaded. ZinFoq’s default timestomp timestamp of 2016-01-15 provided a specific forensic marker.
Flight protocol indicators are the hardest to inspect because they require WAF or logging infrastructure that can parse the binary serialisation format. Trend Micro’s pattern table documents Next-Action headers, $@ chunk references, resolved_model strings, and constructor:constructor access chains. Huntress published Sigma rules for detecting suspicious shell processes and YARA rules for ZinFoq, CowTunnel, and PeerBlight. Microsoft Defender triggers on React2Shell-specific alerts. The detection tooling exists.
The platform defence comparison does not declare a winner, because each approach protects against a different part of the threat lifecycle. Vercel’s framework-level patching fixed the root cause. Cloudflare’s V8 isolate sandbox contained the blast radius regardless of patch status. Deno Deploy’s permission model denied post-exploitation capabilities by design. Deployments that combined approaches fared best.
For the architectural analysis behind the headlines, the full crisis overview connects these operational findings to the deeper questions about framework trust and accountability that React2Shell raised. The University of Michigan’s advice now reads as an implicit recognition that architecture was the decisive defensive variable. Patching speed alone could not replicate the structural insulation that Cloudflare’s V8 isolate sandbox and automatic WAF deployment provided.
The question React2Shell leaves behind is whether your platform architecture makes the next RSC deserialisation vulnerability survivable, regardless of how quickly you patched CVE-2025-55182. The blast radius assessment framework and behavioural IoC hunting methodology give you tools that work regardless of what that next vulnerability looks like, because they evaluate exposure at the architectural level, not the CVE level.
React2Shell targets the React Flight Protocol serialisation format, which is the foundation of React Server Components. Next.js is the most widely deployed RSC framework, so it bore the brunt of exploitation, but any framework that implements React Server Components with the vulnerable react-server-dom-webpack or react-server-dom-turbopack packages is susceptible. The vulnerability lives in React’s core deserialisation logic, not in Next.js specific code. GreyNoise telemetry confirmed exploitation attempts against non-Next.js RSC deployments within the first week of scanning.
Containerisation does not prevent the initial exploitation, which occurs at the application layer through deserialisation of a malicious Flight payload. However, containers do constrain the post-exploitation blast radius. A restricted container without privileged mode, hostPath mounts, or elevated capabilities limits what an attacker can access after achieving RCE. The credential harvesting campaigns documented by Cisco Talos were most devastating when the compromised Node.js process ran with broad filesystem access and cloud IMDS reachability, both of which proper container hardening would restrict.
Yes, patching remains essential even behind Cloudflare. Cloudflare’s WAF Managed Rules block known exploit patterns before they reach the origin server, providing a critical buffer during the exposure window between disclosure and patch deployment. But WAF rules are signature based, and novel bypass payloads that avoid blocked keywords will eventually emerge. Cloudflare’s own documentation notes that binary Flight protocol payloads inherently challenge signature-based detection. Patch your react-server-dom-webpack and react-server-dom-turbopack packages to the versions specified in the May 2026 coordinated advisories.
Check the installed version of react-server-dom-webpack or react-server-dom-turbopack in your dependency tree. Use npm ls react-server-dom-webpack or yarn why react-server-dom-webpack to identify all instances, including transitive dependencies. The patched versions were published as part of the 13 coordinated advisories in May 2026. After updating, run the Assetnote react2shell-scanner against your own deployment in a staging environment to confirm the patch is effective, then audit your lockfile to verify no older version has been reintroduced by a subsequent install.
Isolate the affected host from the network immediately. Preserve forensic evidence by capturing memory dumps and disk images before shutting down. Hunt for the behavioural IoCs documented by security researchers: unusual child processes spawned from Node.js, outbound connections to unknown IPs on non-standard ports, new systemd service files masquerading as legitimate services, and modified shell RC files. Rotate all credentials accessible to the compromised process, including environment variables, .env file secrets, cloud IAM tokens, and SSH keys. Assume complete credential exfiltration until forensic analysis proves otherwise.
The University of Michigan security team made an operational risk calculation. Cloudflare was the only provider that had deployed automatic WAF Managed Rules with default Block action across all plan tiers, including Free, within hours of disclosure. Other providers required customer-side configuration changes or offered protection only on enterprise plans. For an organisation managing hundreds of web properties across diverse teams, recommending a single provider that removed the configuration burden was operationally pragmatic. It was not an endorsement of Cloudflare’s technology over alternatives; it was a recognition that automatic protection works at institutional scale.
Yes, several free scanning options exist. The Assetnote react2shell-scanner is an open-source command-line tool that sends benign Flight protocol probes to identify vulnerable servers without delivering a payload. Nuclei templates are available from the community template repository, enabling integration with existing vulnerability scanning workflows. GreyNoise offers a free React2Shell tag that identifies IPs actively scanning for the vulnerability, which helps defenders distinguish opportunistic background noise from targeted scanning against their infrastructure. Each tool targets a different defensive use case: internal validation, CI/CD integration, and threat intelligence enrichment.
Statically generated Next.js sites that do not use React Server Components at runtime are not directly vulnerable to React2Shell exploitation. The vulnerability requires an active server-side rendering path that deserialises Flight protocol payloads from client requests. A purely static site, served as pre-rendered HTML and JSON files from a CDN, has no server-side RSC deserialisation endpoint for an attacker to target. However, be thorough in your assessment: many Next.js deployments use a hybrid model where most pages are static but specific routes, like search or admin dashboards, invoke server components dynamically.
Most Node.js deserialisation vulnerabilities exploit unsafe use of eval, vm.runInNewContext, or serialize-javascript to achieve code execution. React2Shell is different because it attacks the framework’s own serialisation protocol, React Flight, which is designed to be deserialised safely. The vulnerability emerged from Flight’s chunk reference mechanism: $@ and $B prefixes create object references during deserialisation, and attackers discovered that these references could be manipulated to achieve prototype pollution and ultimately arbitrary code execution through the framework’s own internals, not through a misused third party library.
Not necessarily just the latest version. The fix for CVE-2025-55182 was backported across multiple release lines as part of the May 2026 coordinated advisories, so the patched version depends on which major release you are running. Simply running npm update next may pull a version without the backport if your project pins a major version range. Consult the specific advisory for your Next.js version line and verify that react-server-dom-webpack or react-server-dom-turbopack in your dependency tree matches the patched release. Blindly updating without checking the dependency tree leaves room for error.
React2Shell earned a CVSS score of 10.0. Exploitation requires no authentication, no user interaction, and no custom code. A project scaffolded with create-next-app, built for production exactly as documented, was remotely exploitable the moment it deployed. This was not a misconfiguration. It was the default.
The question that follows is: how did default become vulnerable? This article examines one dimension of the React Server Components security landscape: the trust model that made the default exploitable. The answer sits in the React Server Components trust model, a design decision that assumed Flight payloads were trustworthy, and then deployed that assumption to every App Router application. By the end of this analysis, you will have a framework for evaluating whether your own architecture assumes trust where it shouldn’t.
React2Shell exploits default Next.js App Router installations because the app/ directory structure with page.tsx files automatically participates in the Flight protocol. No eval(), no custom child_process usage, no configuration flag is required to activate the deserialisation path. Testing by Wiz Research indicates near-100% exploitation reliability, and their data shows 39% of cloud environments contain vulnerable instances. The affected range covers React 19.0 through 19.2 (patched in 19.0.1, 19.1.2, and 19.2.1), plus Next.js 15.x, 16.x, and canary builds from 14.3.0-canary.77.
Every App Router deployment exposes RSC endpoints: /_rsc, /__flight, /_react, and Server Action POST endpoints. These accept and deserialise Flight payloads from HTTP requests. The server-side deserialiser inherited the payloads-are-trusted assumption from a protocol originally designed for server-to-client communication. When the Next.js App Router made the server also a receiver of client-sent Flight payloads, nobody re-evaluated whether those payloads should be treated as hostile.
The exploit chain is deterministic logic abuse, not memory corruption. Attackers craft fake Chunk objects with custom then methods in the Flight payload. React’s deserialiser resolves them as Promises, and the attacker-controlled then handler hijacks the internal _response object to achieve arbitrary code execution. OffSec characterised it as pure logic abuse built on expected JavaScript features like promise resolution and nested deserialisation.
Server Functions and Server Actions infrastructure is auto-exposed on every App Router deployment, even when no "use server" directives exist in your code. The Pages Router is not affected because it does not participate in the Flight protocol. If your application runs on the Pages Router with no App Router routes, you are not vulnerable to CVE-2025-55182. That architectural distinction is why the vulnerability caught so many teams off guard: the exploit path was introduced when Next.js made the App Router the documented default. For the full technical walkthrough — from crafted HTTP request to remote code execution — see the React2Shell exploit mechanism in detail.
In traditional SSR (Express plus EJS, Rails ERB, Django templates), the server renders HTML from trusted templates. Untrusted user inputs pass through explicit escaping boundaries. The attack surface is the template rendering engine’s handling of user-supplied data. Every input is untrusted by convention, and the framework’s job is to prevent that untrusted data from becoming executable.
In RSC, the attack surface is the Flight deserialiser itself. The user input is the entire serialised component tree, a richer attack surface containing function references, module references, Promise-like objects, and cyclic data structures. All of it is treated as trusted by default. As Kodem Security noted, React’s server runtime was never built to handle untrusted input.
The REST API comparison sharpens the distinction. REST enforces an explicit security boundary where every request parameter, header, and body is untrusted by convention and validated before processing. RSC’s deserialisation-first model means exploitation occurs before any application-level validation can execute, as the RCE occurs before any routing logic or auth gates. Where REST limits its attack surface to the narrow set of validated inputs reaching application logic, RSC exposes the Flight deserialiser’s entire object graph reconstruction, handling arbitrary object shapes, prototype chains, and thenable resolution before the application ever sees the data.
The Flight protocol’s wire format is a hybrid row-based streaming format designed to resolve component trees incrementally with references and module imports. JSON, by contrast, is deliberately limited: it carries no execution context, no code, no object methods. That limitation is a security feature, and it is one RSC does not share.
This is the question that divides security researchers, and the honest answer is that the evidence supports both interpretations.
The maturity argument goes like this: the Flight protocol is a young serialisation format compared to JSON or Protocol Buffers. It was designed for a trusted server-to-client communication space. Its deserialiser was not battle-tested against adversarial inputs, and the recurring CVE pattern (CVE-2025-55182 for RCE, CVE-2025-55184 for DoS, CVE-2025-55183 for source code exposure, and CVE-2025-67779, an incomplete fix) represents growing pains. The initial patch for CVE-2025-55184 was bypassed within days, leading to a second CVE. This looks like a protocol hardening under fire. The patch frequency across React 19.x supports this reading.
The fundamental argument says any serialisation format rich enough to represent executable code patterns (thenables, prototype chains, cyclic references, function markers $F, module references $L) will always carry an attack surface when exposed to untrusted input, regardless of maturity. The CVE diversity supports this: RCE, DoS, information disclosure, all from the same deserialisation boundary. Java’s ObjectInputStream vulnerabilities persisted across years of patching because the deserialisation model was permissive at the architectural level. Python’s pickle documentation explicitly warns against unpickling untrusted data, yet the warning is routinely ignored in practice. PHP’s unserialize() created gadget chains where legitimate classes from widely used libraries became attack vectors. You cannot fix this by “not using dangerous classes” because your dependencies contain the gadgets.
So the patch frequency supports maturity, while the CVE diversity supports fundamental. Whichever interpretation you favour, both demand the same defensive posture: adding validation boundaries that treat Flight payloads as untrusted by design. Those measures (schema enforcement, process isolation, input sanitisation) are architecturally sound regardless. Even the maturity reading implies a multi-year hardening process during which adopters bear the risk, and as DebugBear noted, security is the biggest challenge facing RSCs today.
The vulnerability follows the Flight protocol implementation, not the framework brand. Understanding how different frameworks handle the trust boundary gives you a concrete sense of the options available.
Next.js App Router enables RSC and Flight protocol endpoints by default, with Server Action infrastructure auto-exposed on every deployment. This is the maximum-default-exposure model. Remix (acquired by Shopify) uses loaders and actions with explicit data boundaries: server functions return plain JSON objects, not serialised component trees, and there is no Flight protocol deserialisation step on the server. The trust boundary is explicit because every response is treated as application data, not executable instructions.
TanStack Start provides server functions with a serialisation model that avoids reconstructing arbitrary object graphs from client input in the manner of the Flight protocol. The architectural choice to avoid Flight’s expressive format reduces the deserialisation attack surface. Waku, a minimal RSC framework, bundles the same react-server-dom-* packages as Next.js and was explicitly affected by CVE-2025-55182, demonstrating that minimalism offers no inherent protection against protocol-level trust-model flaws. Traditional React SPAs without RSC have no server-side deserialisation attack surface at all: the server sends static assets and API responses, and the attack surface is the API layer, which follows the REST validation-before-processing model.
The comparison reveals a spectrum: minimal attack surface (traditional SPA with REST API), moderate (Remix or TanStack with explicit data boundaries), maximum (Next.js App Router or Waku with Flight protocol deserialisation). Teams evaluating framework migrations should understand where their candidate framework sits on this spectrum. The CVE-2025-66478 and CVE-2025-55182 duplicate relationship, where the Next.js advisory was later rejected as a duplicate of the primary React CVE, illustrates that the vulnerability flows from upstream, not from any single downstream framework.
Which brings us to the practical question: if you are evaluating an RSC framework, what should you be asking its vendor before adopting server components?
These are not prescriptive checklist items. They are the analytical dimensions you should probe when evaluating an RSC framework vendor, with the React2Shell evidence as motivating context.
The first dimension is the deserialiser input validation boundary. Does the vendor’s RSC implementation assume Flight payloads are trusted, or does it enforce structural validation before deserialisation begins? React2Shell succeeded because the deserialiser treated client-supplied Chunk objects as legitimate. The React team’s fix required tightening validation and eliminating code paths that allowed untrusted instructions to survive deserialisation. Use that as your benchmark for what vendor hardening should include: validation guardrails around function markers, module references, and Promise resolution paths.
Second is the security advisory process and patch latency. What is the vendor’s CVE disclosure cadence, coordinated release process, and typical time-to-patch? Vercel‘s coordinated release in May 2026 demonstrates the operational cost framework vendors absorb, and the standard is worth comparing.
Process isolation forms the third dimension. How does the vendor isolate server-side RSC execution from the host environment? Look for process-level isolation, capability dropping, and whether the default deployment model limits post-exploitation blast radius. Vercel-hosted apps benefit from platform-level request filtering, but platform protections reduce blast radius, they do not close the deserialisation vulnerability.
The fourth dimension is the Flight protocol dependency chain. Does the vendor maintain their own fork of react-server-dom-webpack or react-server-dom-turbopack, or track upstream React directly? Understanding who owns the deserialisation implementation determines where patches originate and how quickly they propagate.
Fifth, and perhaps most revealing: is hardening treated as ongoing investment or reactive patching? A vendor answering “reactive” implicitly expects you to absorb discovery-to-patch risk. The maturity-versus-fundamental debate from the previous section makes this question essential, because the patch frequency and CVE diversity suggest the deserialisation surface still holds undiscovered issues.
For your own deployment, assessing exposure means asking whether you use App Router with server components (exposed), whether your WAF inspects Flight payloads (mitigating), whether your runtime provides process isolation (reduces blast radius), and whether you run patched versions (remediated). The prioritisation case is straightforward. GreyNoise recorded over 1.4 million exploitation attempts in a single seven-day observation period. If your application processes untrusted Flight payloads and you have not patched, this vulnerability ranks above other issues in your backlog because exploitation is deterministic, unauthenticated, and actively occurring.
React2Shell was patched. The architectural question it surfaced remains open — and how the exploitation evidence shapes the accountability question is something every team adopting RSC must confront. The Flight protocol’s serialisation format carries executable patterns that traditional web frameworks avoid by design, and exposing that format to untrusted client input creates an attack surface whose boundaries are still being mapped. Real-world exploitation data validates the trust-model analysis: attackers understood the trust boundary weakness and exploited it at scale. Teams adopting RSC are not just adopting a rendering strategy. They are adopting a trust model whose hardening is still underway, and the gap between default and secure is one attackers are exploiting right now.
Yes. The Pages Router does not participate in the Flight protocol and has no server-side deserialisation of client-sent component payloads. The attack surface exists exclusively in the App Router’s RSC architecture. If your entire application runs on the Pages Router with no App Router routes, you are not vulnerable to CVE-2025-55182. This architectural distinction is why the vulnerability caught so many teams off guard: the exploit path was introduced silently when Next.js made the App Router the documented default.
No, and this is a common misconception. Server Actions infrastructure is auto-exposed on every App Router deployment regardless of whether you have authored any "use server" functions. The Flight protocol endpoints that accept and deserialise client payloads are active by default. There is no configuration flag to selectively disable the deserialisation path while keeping the App Router running. Patching is the only reliable mitigation for this attack surface.
Look for unusual child processes spawned by the Node.js runtime, unexpected outbound network connections from your server, and new files written to directories like /tmp or the application root. The publicly documented post-exploitation payloads deployed XMRig cryptominers, Cobalt Strike beacons, and several RAT variants (KSwapDoor, EtherRAT, Noodle RAT). Check your process tree and network logs for these indicators. Note that skilled attackers may have cleaned forensic artefacts, so patching alone does not substitute for a compromise assessment if you ran an unpatched version during the exposure window.
Vercel’s infrastructure adds some mitigating factors (containerised isolation, limited filesystem write access, and their own edge network inspection) but the vulnerability itself exists in your application code regardless of hosting platform. Vercel cannot prevent the Flight deserialiser in your application from processing a crafted payload. The CVSS 10.0 score reflects that the exploit path exists at the application layer. Platform-level protections reduce post-exploitation blast radius; they do not close the deserialisation vulnerability.
The Edge Runtime is not affected by CVE-2025-55182 because it does not participate in the Flight protocol in the same way as the Node.js runtime. However, this is not a general security guarantee. The Edge Runtime has a different capability profile (no filesystem access, restricted Node.js APIs) that limits what an attacker can do after exploitation, but it runs the same React Server Components infrastructure. Treating the Edge Runtime as inherently safe misunderstands the problem: the vulnerability follows the Flight protocol implementation, not the runtime environment.
Yes, and this is one of the more significant implications of React2Shell. The "use server" directive implies a security boundary: code marked this way runs on the server and cannot leak to the client. But the directive is a build-time instruction to the bundler, not a runtime security enforcement mechanism. It does nothing to validate or constrain what the server-side deserialiser accepts from incoming Flight payloads. The naming convention creates an intuition about security that the implementation does not deliver, which is a documentation and developer-experience problem the React team should address directly.
The patch added validation guards around the Flight deserialiser’s handling of Chunk objects, specifically preventing attacker-controlled then methods from hijacking the internal _response object during Promise resolution. The fix introduces a runtime check that rejects Chunk types from client payloads that should only originate from server-side serialisation. This is a targeted hardening of the deserialisation path rather than a fundamental protocol redesign. It closes this specific exploit chain but does not eliminate the broader attack surface associated with deserialising expressive payloads from untrusted clients.
No. React2Shell is exclusively a server-side vulnerability. The exploit targets the Flight deserialiser running on the server, not the React runtime in the browser. Client-side React applications, including those built with Create React App or Vite, have no Flight protocol endpoints and no server-side deserialisation step to exploit. The confusion arises because “React” is the branding, but the vulnerability lives in react-server-dom-webpack and react-server-dom-turbopack, packages that only exist in server-side RSC deployments.
A WAF rule blocking requests to known Flight protocol endpoint paths (/_rsc, /__flight, /_react) and POST requests with Flight-specific content types can provide partial mitigation. However, this approach has two meaningful limitations: it may break legitimate application functionality, and determined attackers can potentially route payloads through alternative paths. Network-layer blocking is a temporary stopgap, not a substitute for patching. The deterministic nature of the exploit means every unauthenticated request to a Flight endpoint on an unpatched server represents a successful compromise.
CVE-2025-55182 is the most severe RSC vulnerability disclosed to date, but the recurring deserialisation pattern across React 19.x (including prior DoS vulnerabilities) strongly suggests that additional issues will surface as the protocol receives more adversarial scrutiny. The Flight deserialiser was designed for a trusted communication channel and is now being stress-tested against the reality that client-sent payloads are attacker-controlled. Security researchers and the React team are actively auditing the deserialisation surface. Teams running RSC in production should assume further CVEs will emerge and plan their patch response cadence accordingly.
The Recurring Deserialisation Vulnerability Pattern in React Server Components: Architecture, Exploits, and LessonsA Flight payload containing circular $ references lands on your server. The deserialiser in ReactFlightReplyServer.js chases those references forever. That’s CVE-2026-23869: a server that stays alive (ports open, handshakes responding) yet cannot answer a single request.
CVSS 7.5, no authentication required.
What makes this interesting isn’t the denial of service itself. It’s that this CVE was disclosed in January 2026, months after the React2Shell RCE patch landed in December 2025. If the critical bug was supposed to be fixed, why were new deserialisation vulnerabilities still surfacing in the same code?
Four CVEs in the same Flight Protocol deserialisation code path across six months is not an incident. It’s a pattern — one that forms a key part of the React2Shell crisis overview. And the pattern tells us something about the architecture that the individual bugs don’t. Start with the most tangible member of the cluster: the one exploit that makes the pattern visible in a single payload.
The Flight Protocol uses $ prefixed references (like $1 or $B0) to resolve shared objects and chunk references within a payload. It’s a compression mechanism. An attacker constructs a payload where $1 references an object whose properties reference $1 back, forming what researchers call a Directed Cyclic Graph.
The deserialiser’s resolution algorithm follows these references without tracking visited nodes. That’s the bug.
But the exploit’s destructiveness comes from where it runs. Cyclic Promise references exploit the V8 engine’s microtask scheduling: Promise resolution callbacks are microtasks, and the microtask queue must drain completely before the event loop processes macrotasks like timers and I/O. The cyclic payload creates an unending chain of Promise resolutions. Your server is alive at the network level but brain-dead at the application level.
Penligent’s researchers developed a safe probing technique for this: send a finite-depth cyclic reference and measure latency drift. If response time scales with depth, the server is vulnerable. If it doesn’t, the patch is holding. The technique exists because you can’t safely distinguish a patched server from an unpatched one with a full payload. A full cycle takes the server offline either way.
The payload itself is often under 1KB, sliding past WAFs looking for SQL injection signatures or oversized request bodies. Deserialisation attacks don’t look like attacks.
Bigger than most people registered at the time.
The RSC security crisis spans at least seven CVEs beyond React2Shell. CVE-2025-55183 exposes server source code through Server Function stringification (CVSS 5.3). A cluster of five DoS vulnerabilities (CVSS 7.5 each) includes CVE-2025-55184, its incomplete fix CVE-2025-67779, and the follow-ons CVE-2026-23864, CVE-2026-23869, and CVE-2026-23870. CVE-2025-66478 tracked a protocol-level flaw at the Next.js layer, later rejected as a duplicate by NVD. Each targets the same deserialisation codebase through different vectors: Promise resolution, Map/Set iteration, $-reference cycles, and processValue.
As Sonatype’s security team put it at the time: “These issues don’t replace React2Shell; they stack on top of it. While one bug gives you RCE, the others give you ways to knock over servers and leak code, all in the same RSC machinery.” Understanding how a single crafted HTTP request achieves remote code execution requires the full exploit chain in detail.
Then came the May 2026 Vercel coordinated release: 13 advisories in a single batch covering middleware and proxy bypass, SSRF, cache poisoning, and XSS. The deserialisation boundary had extended into the surrounding server infrastructure. SSRF and cache poisoning mean crafted Flight payloads can influence server-side request routing and cache behaviour, well beyond the deserialiser itself.
The version sprawl made patching its own operational problem. Affected ranges spanned React 19.0.x through 19.2.x (patches reaching 19.2.5), Next.js 13.3 through 16.x, and downstream frameworks including React Router, Waku, Parcel RSC, Vite RSC, RedwoodSDK, and Expo. Cloudflare observed 582.1 million React2Shell-related hits in the first eight days after disclosure, averaging 3.49 million per hour. A Metasploit module was published shortly after disclosure, and exploitation attempts were observed within two days.
The timeline tells the story. November 29, 2025: Lachlan Davidson reports RCE through the Meta Bug Bounty programme. December 3: CVE-2025-55182 disclosed. December 11: CVE-2025-55183 (source exposure) and CVE-2025-55184 (DoS) disclosed, plus CVE-2025-67779 on the same day as an incomplete fix for the DoS. January 2026: CVE-2026-23864, CVE-2026-23869, and CVE-2026-23870. May 2026: Vercel’s 13-advisory batch.
Three dynamics were at play, and likely all three simultaneously. Independent researchers (Andrew MacPherson, RyotaK, Mufeed VH, and others) found different vectors and reported on staggered timelines through the Meta Bug Bounty programme. Each patch revealed adjacent attack surface: the initial DoS fix in CVE-2025-55184 was bypassed within days, producing CVE-2025-67779, which then drew attention to the createMap and createSet functions that became CVE-2026-23869. And the Flight Protocol deserialiser’s architecture is sufficiently intricate that root-cause fixes were harder than incremental, targeted patches.
The React team themselves acknowledged this dynamic: “Security researchers have found and disclosed two additional vulnerabilities in React Server Components while attempting to exploit the patches in last week’s critical vulnerability.” The patch sequence tells the same story: 19.0.1 to 19.0.2 to 19.0.3 to 19.0.4 to 19.0.5, with parallel tracks in 19.1.x and 19.2.x. Even the React team could not anticipate the full vulnerability surface in a single remediation cycle.
It reveals that the Flight Protocol was designed for trusted payloads and deployed at an untrusted boundary.
The incremental-patch trap is the clearest evidence: CVE-2025-55184 (initial DoS), then CVE-2025-67779 (incomplete fix bypass), then CVE-2026-23864 (additional DoS cases), then CVE-2026-23869 (cyclic deserialisation), then CVE-2026-23870. Each patch closed one vector without addressing the structural weakness. The deserialiser was retrofitted with input validation incrementally rather than architected for an untrusted boundary from the start.
CVE-2026-23869 signals this directly. Why does a production deserialiser shipping in a widely deployed framework lack cycle detection? Because the Flight Protocol’s original design assumed a trusted channel (server-to-server or server-to-client) where cycles would never appear maliciously. As described earlier, the attacker sends a Flight payload with circular $ references and the deserialiser enters unbounded recursion. The unpatched processValue function lacked depth limiting or cycle detection for reference types because, in the design model, those guards were unnecessary.
It’s worth distinguishing the two mechanisms here. CVE-2025-55184 uses Promise-based microtask starvation: cyclic Promise references flood the microtask queue so the event loop never reaches macrotasks. CVE-2026-23869 uses unbounded recursion in createMap, createSet, and extractIterator without necessarily involving Promises. Two attack paths, same architectural root.
As Qualys observed: “React’s server runtime was never built to handle untrusted input. Traditionally, client input is sanitized and filtered by APIs before any server logic is executed. By contrast, React Server Components blurred that separation.”
And here is why that blur exists structurally in RSC.
Server Components are an architectural innovation: component code stays permanently server-side while accepting structured client payloads. But that innovation eliminates the traditional request/response boundary and replaces it with a serialisation boundary.
Each 'use server' directive creates an HTTP endpoint that accepts Flight Protocol payloads. These payloads are not data. They encode component trees, module references, and object graphs that the server reconstructs and executes. The traditional web-application pattern (parse input, validate, execute) collapses into deserialise-then-execute. That makes the deserialiser the security boundary, whether you designed it to be or not.
The Flight Protocol’s expressiveness is what makes RSC powerful and what makes it dangerous. It’s a row-based streaming format rich enough to represent component trees with lazy-loaded chunks, shared object references, and Promise-based streaming. The $ reference resolution mechanism, designed for efficient wire-format compression, becomes the exploitation primitive for prototype pollution, gadget chains, and cyclic DoS. A format this expressive makes the deserialiser an unusually capable attack surface: it reconstructs attacker-controlled execution contexts, not just data structures.
A standard Next.js application created with create-next-app and built for production is exploitable without any code changes. The vulnerability is present in default configurations. That’s the boundary blur in practice: the framework exposes a deserialisation endpoint by default, and the developer may never know it exists.
The mechanism is the same.
In Java deserialisation, an attacker chains through legitimate classes (Commons Collections, Spring) where method-invocation side effects eventually reach Runtime.exec(). In RSC deserialisation, the attacker chains through Flight $ references: pollute Object.prototype via $1:__proto__:then, rebind _formData.get to the Function constructor via $1:constructor:constructor, inject arbitrary code via _response._prefix. Same pattern: reconstruct attacker-controlled object graphs before validation, exploit legitimate method-chaining side effects to reach dangerous sinks.
Java deserialisation vulnerabilities have been known since at least 2015 with CVE-2015-4852 in Apache Commons Collections, affecting WebSphere, WebLogic, JBoss, and Jenkins. Python’s pickle documentation explicitly warns against unpickling untrusted data. PHP’s unserialize() has produced decades of POP chain vulnerabilities. The RSC vulnerability cluster is not a novel class of attack. It’s a framework-specific instance of OWASP A08 (Insecure Deserialization) that the security community has understood for over a decade.
The question worth asking is why a new serialisation format shipped without the safety mechanisms the broader industry learned were necessary. The Flight Protocol needed to be smarter than JSON, capable of serialising promises, closures, and complex object graphs. That meant it needed to be more complex, more powerful, and more dangerous.
If the pattern is cross-framework, then the takeaway isn’t React-specific.
The React2Shell cluster is the latest chapter in a security pattern the industry has documented in every serialisation format expressive enough to reconstruct object graphs. It happens to have played out in React, but the same pattern has surfaced in Java, Python, PHP, and Ruby before. The Flight Protocol’s trusted-payload assumption, retrofitted incrementally with input validation across six months of advisories, reproduces the architectural mistake that made Java ObjectInputStream, Python pickle, and PHP unserialize() widely documented attack surfaces.
The multi-wave advisory cadence is what happens when a complex deserialisation codebase designed for trust encounters adversarial input for the first time in production — a pattern explored in the complete timeline and defensive response. Each new CVE in the same code path confirms that incremental patches address vectors while leaving the structural assumption intact. The May 2026 Vercel batch demonstrates this boundary is still being mapped. SSRF, cache poisoning, and proxy bypass mean the attack surface extends beyond the deserialiser itself into the surrounding infrastructure. The safe assumption is that it’s larger than what’s been mapped so far.
The vulnerability lies in the decision to deploy a deserialiser designed for co-operating peers at an untrusted Internet-facing boundary — the trust-model failures behind the advisory pattern that made default Next.js deployments exploitable. The implementation flaws follow from that decision. When a framework accepts structured, serialised payloads from clients to drive server-side execution, the deserialiser is the security boundary. Designing it as anything else is the vulnerability.
Yes, if you are running any Next.js App Router version from 13.3 through to pre-patch 16.x releases without the latest security updates. The App Router uses React Server Components by default, and every CVE in this cluster affects the RSC deserialisation path that the App Router exposes. Check your React version: 19.0.5, 19.1.3, or 19.2.5 (or higher in each line) is the minimum safe state. The May 2026 Vercel coordinated release also requires Next.js patches that address vulnerabilities beyond the React package itself, including middleware bypass and cache poisoning vectors.
Prototype pollution is the ability to modify Object.prototype from attacker controlled input, which then affects every object in the JavaScript runtime. In RSC deserialisation, the Flight Protocol $ reference mechanism lets an attacker set $1:__proto__:then to inject a then function onto Object.prototype. This matters because once Object.prototype is polluted, the attacker can rebind internal framework methods (like _formData.get) to dangerous sinks (like the Function constructor), enabling arbitrary code execution. It turns a data manipulation bug into a full remote code execution chain.
You cannot know without reviewing server access logs for unusual Flight Protocol payloads, specifically requests to Server Action endpoints containing $ reference patterns or chunk-encoded payloads with circular reference structures. The Penligent research demonstrated a safe probing technique that sends bounded depth cyclic references to detect vulnerable servers without crashing them. If your application has not been probed, you may have been scanned without incident. The more concerning scenario is that exploitation payloads look identical to legitimate Flight traffic in server logs, making detection of past compromise difficult without specialised analysis.
Yes, but only after upgrading past the patched version thresholds and applying a defence in depth approach. Patching to React 19.0.5, 19.1.3, or 19.2.5 (or later) addresses all known CVEs at the deserialisation level. Beyond patching, production deployments should add WAF rules that inspect Flight Protocol payloads for unusual $ reference depth, rate limit Server Action endpoints aggressively, and monitor for microtask starvation symptoms (healthy TCP but unresponsive HTTP). The architectural lesson is that the deserialisation boundary must be treated as an untrusted input surface, not as a trusted internal channel.
Check your package.json lockfile for the React and Next.js versions against the full affected ranges: React 19.0.0 through 19.0.4 (patch to 19.0.5), 19.1.0 through 19.1.2 (patch to 19.1.3), and 19.2.0 through 19.2.4 (patch to 19.2.5). Next.js requires separate patches for the May 2026 Vercel batch that covers SSRF, cache poisoning, and middleware bypass. Note that CVE-2025-67779 was an incomplete fix for CVE-2025-55184, so applying only the first patch in a version line does not close all known vectors. Run npm audit and cross reference the output against the CVE identifiers listed in the article.
Deploy a WAF rule set that inspects and blocks Flight Protocol payloads exceeding a safe reference depth (for example, $ reference nesting beyond 20 levels) and restrict Server Action endpoints to authenticated sessions only where possible. Rate limit Server Action endpoints to a handful of requests per second per IP to limit the blast radius of any DoS attempt. Disable Server Actions entirely if your application does not use them: the attack surface exists only where 'use server' directives create publicly reachable HTTP endpoints. These are stopgap measures, not permanent solutions. Upgrade as soon as operationally feasible.
No. The vulnerability cluster reveals a design assumption (trusted payload channel) that was incorrect for Internet facing deployments, not a flaw in the Server Components concept itself. The Flight Protocol wire format is expressive and efficient for its intended purpose. The mistake was shipping it to production without the safety guards (cycle detection, recursion limits, input validation) that every serialisation format handling untrusted input requires. The architecture can be made safe, as the patches demonstrate, but the lesson is that security boundaries must be designed into serialisation formats from the start rather than retrofitted after the fact.
The Flight Protocol was designed for a trusted communication model between cooperating peers (server to server, or server to browser under the framework’s own control). In that model, cycle detection, recursion limits, and input validation are unnecessary because payloads originate from code the developer wrote or the framework generated. The security review operated within that trusted scope assumption. The gap appeared when Server Functions exposed those same Flight Protocol endpoints to arbitrary Internet traffic, transforming what was an internal serialisation format into a public attack surface without a corresponding security boundary review. The Meta Bug Bounty programme eventually surfaced what the design assumptions had concealed.
No widely available open source scanners exist yet, though the Penligent research demonstrated a technique. Their bounded recursion probing method sends a finite depth cyclic $ reference payload to a Server Action endpoint and measures latency drift. A vulnerable server shows increasing response time as depth increases, or hangs entirely on a fully cyclic payload. This technique is delicate (test against staging first, never against live production without authorisation) but effective. Expect commercial vulnerability scanners to incorporate RSC specific checks as this vulnerability class matures from novel research into standard detection patterns.
Other framework authors should be worried. The RSC cluster is the latest confirmation of a cross language pattern: every serialisation format expressive enough to reconstruct complex object graphs (Java ObjectInputStream, Python pickle, PHP unserialize, Ruby Marshal) has been weaponised for deserialisation attacks when deployed at an untrusted boundary. Any framework that accepts structured, serialised component descriptions from clients over a network boundary faces the same architectural question: is the deserialiser designed for untrusted input, or was it built for an internal trusted channel? If the latter, the same vulnerability class will appear under sufficient researcher attention.
On 3 December 2025, Meta disclosed CVE-2025-55182, a CVSS 10.0 remote code execution vulnerability in React Server Components. The security community named it React2Shell. A single HTTP POST request to a server endpoint is sufficient: no authentication, no user interaction, no prior foothold, and no developer error in your application code. The vulnerability lives in the framework itself.
React2Shell is not a story about a bug. It is part of the broader React Server Components security crisis — a story about what happens when a framework’s internal communication protocol, designed assuming trusted origins, gets exposed to untrusted HTTP by architectural default. This article walks through the exploit mechanism, explains why the React Flight protocol’s deserialisation process created the attack surface, and places React2Shell in context against decades of unsafe deserialisation vulnerabilities across other ecosystems. By the end, you will understand why this vulnerability class is different from what the industry has seen before.
CVE-2025-55182, colloquially named React2Shell, is a remote code execution vulnerability in the React Flight protocol’s server-side deserialiser. Security researcher Lachlan Davidson privately reported it to Meta’s bug bounty programme on 29 November 2025. The React team shipped a patch within 48 hours, and public disclosure followed on 3 December.
The CVSS 10.0 score reflects a worst-case vector: network attack vector (AV:N), low attack complexity (AC:L), no privileges required (PR:N), no user interaction (UI:N), and scope changed (S:C) with high impact across confidentiality, integrity, and availability. In practice, this means any internet-facing React Server Components application running a vulnerable version is easily exploitable.
To understand why, you need to know where the vulnerability sits. React Server Components (RSC) run on the server with access to databases, filesystems, and environment variables. They communicate with clients through the React Flight protocol, which serialises component trees, props, and execution context into chunked streams. The affected packages are react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack, the server-side Flight deserialisers used by Next.js, React Router, Waku, and others.
The blast radius data is substantial. Wiz Research found that 39% of cloud environments contain vulnerable React or Next.js instances, and 44% of all cloud environments have publicly exposed Next.js applications. Default Next.js App Router configurations were vulnerable out of the box because RSC support is the default. This ended React’s 13-year security record, the only previous blemish being a minor XSS in 2018. Cloudflare observed 582 million React2Shell-related hits in the first eight days after disclosure. Exploitation began almost immediately, accelerated by public proof-of-concept code and a Metasploit module.
That volume of attacks is why understanding the exploit mechanism matters. Let’s walk through exactly how a single request achieves code execution.
The exploit chain relies on three JavaScript mechanisms, each explored below: prototype pollution, thenable resolution, and context confusion. None of them require you to have written vulnerable code. The framework’s own deserialiser does all the work.
Here is the chain, step by step. First, the attacker crafts a Flight payload containing malicious JSX properties with __proto__ key paths. A path like $1:__proto__:constructor:constructor traverses the JavaScript prototype chain from any data object to the global Function() constructor. When the server deserialises this payload, the Flight deserialiser assigns the __proto__ property without checking if the object actually owns it, polluting Object.prototype globally on the server process.
This is prototype pollution: every plain object in the entire Node.js process now carries the attacker’s injected properties. When the attack sets Object.prototype.then to point at Function(), the deserialiser’s behaviour changes in a predictable and exploitable way.
JavaScript treats any object with a .then() method as a “thenable” under the promise specification. When the runtime encounters await obj and obj.then exists, it automatically invokes .then(resolve, reject) with two internal callbacks. The Flight deserialiser eagerly resolves thenables via await, and because Object.prototype.then now points to Function(), calling .then(resolve, reject) on any deserialised object invokes Function(resolve, reject). The attacker now has a code execution primitive.
The third mechanism is context confusion, a Confused Deputy attack. The reviveModel() function is a privileged internal function that processes chunk data during deserialisation. By supplying a malicious _response object as the revival context, the attacker redirects reviveModel() to dereference _response._formData.get as the Function() constructor and _response._prefix as the code payload. The function executes with server privileges but reads from attacker-controlled context objects. The $@chunkId raw reference syntax is abused to return raw chunk objects with their metadata and prototypes intact, breaking the boundary between data and runtime.
Weaponised payloads in the wild use Chunk.prototype.then rather than Object.prototype.then for stability, avoiding global side effects. Blob resolution through $B references provides an alternative pathway by redirecting through a hijacked _response._formData.get. The entire chain is deterministic across all vulnerable instances because Function(), the prototype chain, and thenable resolution exist in every Node.js runtime.
This is not a code defect. It is an architectural exposure.
The React Flight protocol was designed to transport component trees, module references, props, state, promises, and execution contexts between server and client as incremental chunks. It was built for trusted client-to-server communication where the client is a React application, not an attacker.
When React Server Components expose this protocol through HTTP, that trust assumption collides with reality. In Next.js App Router, Flight payloads arrive at /_rsc endpoints by default, without authentication required. The server’s Flight deserialiser reconstructs objects and resumes execution through a pipeline that begins with decodeReply() and flows into reviveModel(). Server Actions, the 'use server' directive, expose Flight deserialisation endpoints even when you have written no explicit Server Functions. The framework registers these endpoints automatically.
The deserialisation pipeline lacked three validations that would have prevented exploitation: property ownership checks (hasOwnProperty), restrictions on __proto__ traversal in property paths, and restraint around eager thenable resolution. All three behaviours are safe when processing trusted internal payloads. They become dangerous when processing attacker-supplied HTTP request bodies.
The comparison with JSON is instructive. JSON is a deliberately limited data format carrying no execution context, no code, no object methods, just data structures. REST APIs using JSON avoid the entire class of deserialisation vulnerabilities by design. The Flight protocol, by contrast, carries rich execution semantics like promises, closures, and module references to enable seamless server-client integration. Those same semantics become exploitation primitives when the deserialiser processes untrusted input.
A protocol designed for trusted internal use was made accessible from untrusted HTTP, and the security properties of that protocol became the security properties of every application using the framework. The trust-model analysis of why the trust model made this attack possible explores this architecture in depth.
Understanding why the Flight protocol created this surface at all helps explain how React2Shell differs from every deserialisation vulnerability that came before it.
Traditional unsafe deserialisation follows a well-worn pattern across Java, PHP, Python, and Ruby. A developer explicitly accepts and deserialises untrusted data using mechanisms like Java’s ObjectInputStream, PHP’s unserialize(), Python’s pickle, or Ruby’s Marshal.load. It is a documented antipattern with decades of CVEs. The fix is straightforward: stop deserialising untrusted input, or switch to a safe format like JSON.
React2Shell breaks that pattern. You never choose to deserialise untrusted data. The framework does it automatically as part of its normal server-side rendering pipeline. You may not even know deserialisation is occurring. It is invisible infrastructure, not an explicit application-level decision.
The gadget chain comparison makes this difference concrete. Java ObjectInputStream exploitation requires specific vulnerable classes on the classpath, tools like ysoserial generate payloads for known chains, and exploitation is often application-specific. React2Shell’s gadget chain is universal: every RSC server has Function(), the prototype chain, and thenable resolution. Exploitation is deterministic across all vulnerable instances, with no application-specific vulnerable classes required.
PHP unserialize() attacks typically need magic methods like __wakeup and __destruct to form a Property-Oriented Programming chain, and they require the application to explicitly deserialise user input from cookies or POST parameters. React2Shell needs neither explicit developer acceptance of untrusted data nor application-specific magic methods. The JavaScript runtime provides the gadgets universally.
The Log4Shell comparison is particularly useful. Both are CVSS 10.0 framework-level RCE vulnerabilities with the X-to-Shell naming pattern. Both triggered widespread emergency patching and were exploited by attackers at scale. But Log4Shell exploited a feature, JNDI lookups in log messages, that organisations could disable as a workaround. React2Shell exploits the communication protocol of the framework, which cannot be disabled without abandoning React Server Components entirely.
The blast radius comparison reinforces the point. Log4Shell required a crafted log message reaching a vulnerable Log4j instance. Rails YAML deserialisation required an endpoint accepting YAML parameters. React2Shell requires only that your application uses React Server Components, which is the default for Next.js App Router. The blast radius is defined by framework adoption, not your specific configuration choices.
What distinguishes React2Shell as a vulnerability class is this: when a framework’s internal communication protocol carries execution context and is exposed to untrusted input by architectural default, the framework’s abstractions become the attack vectors, and adoption becomes exposure. This is a supply-chain vulnerability pattern, not a coding-error pattern.
The exploit mechanism described here is the foundation for understanding the recurring vulnerability pattern that followed in React Server Components. The real-world exploitation evidence at /react2shell-in-the-wild-exploitation-evidence-and-the-platform-defence-landscape shows how attackers operationalised this unique attack surface at scale.
What React2Shell demonstrates is that the security properties of a framework are not just about the code you write on top of it. They are about the internal protocols the framework exposes, the trust assumptions baked into those protocols, and whether those assumptions survive contact with untrusted networks. For React Server Components, the answer turned out to be no. Understanding why is the starting point for assessing every other framework your organisation depends on. For the full picture, how the ecosystem is defending against exploitation is covered in the pillar overview.
Your application is vulnerable if it uses React Server Components with a react-server-dom-* package version prior to 19.0.1, 18.3.2, or 18.2.1, or a Next.js version prior to 14.2.22 (14.x), 15.0.5 (15.x), or 15.1.4 (15.1.x). The vulnerability exists by default in Next.js App Router. Check your lockfile for the affected packages. If your application registers RSC endpoints (commonly /_rsc paths), it processes Flight payloads and may be exploitable.
Only server-side React is affected. The vulnerability exists in the Flight protocol deserialiser, which runs exclusively on the server to reconstruct component trees from client requests. Client-side React rendering, including react-dom, createRoot, and all browser-based React code, is not vulnerable to CVE-2025-55182. However, a compromised server can serve malicious content to clients, so the blast radius extends to users of an exploited application.
React 19.0.1, 18.3.2, and 18.2.1 include the fix. For Next.js users, patched versions are 14.2.22, 15.0.5, 15.1.4, and 15.2.0 or later. React Router 7 in library mode requires version 7.2.0 or later, while Waku requires 0.21.20 or later. The React team shipped patches within 48 hours of the private disclosure on 29 November 2025. Upgrading the framework is the only complete mitigation.
A WAF can provide partial defence by detecting known payload signatures, particularly __proto__ in request bodies and Flight protocol chunk patterns. However, signature-based detection is inherently fragile. Attackers can mutate payload encoding, use blob resolution pathways ($B references), or shift to Chunk.prototype.then instead of Object.prototype.then to evade static rules. WAFs are a useful stopgap but not a substitute for patching the framework.
Current evidence suggests no. The vulnerability was reported privately to Meta on 29 November 2025 and patched before public disclosure on 3 December 2025. However, exploitation began within days of the public announcement, accelerated by proof-of-concept code and a Metasploit module. Wiz and other security vendors observed scanning and exploitation attempts targeting internet-facing Next.js instances shortly after disclosure.
No. React Native does not use React Server Components or the React Flight protocol. The vulnerability is specific to the server-side Flight deserialiser packages (react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack). React Native applications render entirely on the client and do not expose Flight deserialisation endpoints. However, if a React Native app communicates with a vulnerable RSC backend, that backend remains exploitable independently.
The attacker achieves code execution with the privileges of the Node.js process running the React server. This grants access to environment variables, database credentials, filesystem operations, and outbound network connectivity. In observed attacks, payloads have deployed cryptominers, exfiltrated environment secrets, established reverse shells, and enumerated cloud metadata endpoints. The entire server process is compromised at the operating system level, not just the application layer.
The name mirrors the X-to-Shell naming convention popularised by Log4Shell (CVE-2021-44228), indicating a framework-level remote code execution vulnerability that grants shell access. “React2Shell” describes the attack trajectory: a crafted React Flight payload (React) leads to shell command execution on the target server (Shell). Security researchers adopted the name during the disclosure period, and it became the vulnerability’s colloquial identifier across the industry.
Vercel deployed mitigations for its platform infrastructure shortly after the disclosure, but this does not automatically protect individual applications. The Vercel platform can apply WAF-like filtering at the edge, but the application itself remains vulnerable if running an unpatched framework version. Vercel recommended customers upgrade their Next.js deployments. Platform-level protections are a supplementary defence layer, not a replacement for patching.
Applications using only the Pages Router are not affected by React2Shell because Pages Router does not implement React Server Components or expose Flight protocol deserialisation endpoints. The vulnerability requires the react-server-dom-* deserialiser to process untrusted Flight payloads. However, if your application uses both App Router and Pages Router (a common hybrid migration pattern), any RSC-enabled route creates an exploitable surface regardless of which router serves the majority of traffic.