React2Shell vs Log4Shell vs Shellshock: which affects your website?

React2Shell, Log4Shell and Shellshock are different vulnerabilities in different software layers. React2Shell concerns React Server Components, Log4Shell concerns Apache Log4j Core, and Shellshock concerns Bash. Similar names and the possibility of remote code execution do not make their affected versions, detection methods or fixes interchangeable. Start with the component and CVE, then map the advisory to your deployed services.

React2Shell: check the server-side React integration

React's December 3, 2025 advisory identifies CVE-2025-55182 as an unauthenticated remote code execution vulnerability in React Server Components. It names affected react-server-dom packages and framework integrations. The advisory distinguishes these deployments from React code that does not use a server or an integration supporting Server Components. A React logo, browser bundle or frontend technology detector cannot establish which server package is installed.

Ask the application owner for the framework, server runtime, resolved dependency inventory and active deployment identifier. If a framework bundles the relevant implementation, use that framework's instructions. Do not conclude that a customer-facing page is unaffected merely because its source code does not explicitly declare a server function.

Log4Shell: check Java applications and their logging dependencies

Apache tracks Log4Shell as CVE-2021-44228 in log4j-core. Its advisory describes a problem involving JNDI lookups and attacker-controlled logging input. Apache explicitly distinguishes applications using only log4j-api without log4j-core. Review the actual Java application artifacts and vendor products, rather than searching the website's HTML for the word Log4j.

A Java service can sit behind a JavaScript storefront, so the frontend stack is not a complete inventory. Include internal APIs, search services and packaged business software when the owners identify them as relevant. Use the vendor's current supported remediation guidance; an old article's minimum fix version may not address subsequent advisories.

Shellshock: check the operating-system shell and invocation path

Red Hat's Shellshock guidance covers Bash flaws including CVE-2014-6271 and follow-up issues. It explains how specially crafted environment variables can lead to command execution under relevant conditions. CGI scripts that invoke Bash are one web-related example. This is a different component and execution path from React Server Components or a Java logging library.

Ask the infrastructure owner to check the distribution's package and advisory records, including containers or appliances that carry their own operating-system packages. Use the distribution's security status when it backports fixes. A raw upstream version string alone may not accurately represent the vendor-patched package.

Build one decision record per component

1. Record the precise CVE and official advisory. Keep the nickname as a helpful label, not the identifier used for closure.
2. Name the responsible owner and the service, container or vendor product where the component could run.
3. Collect the installed component version and advisory prerequisites from that environment, not a different developer machine.
4. Choose an evidence-backed result: affected, not applicable, remediated or unresolved. Keep unknown inventory entries open.
5. Retain the patch or retirement evidence for each reachable deployment, including the time it was verified.

Use a website scan for the checks it actually covers

Run MyPentest on your authorized site to collect supported website security observations and review its findings and coverage limits. Pair that report with the relevant component inventory. Specific detection of React2Shell, Log4Shell or Shellshock is not established by this article; when the report does not document an applicable check, the named CVE remains unverified by that scan. This avoids using one reassuring result to close three unrelated security questions.