Explore all React2Shell and framework vulnerability guides →
A social preview image can involve server-side code, dependencies and untrusted input, even when its output looks like an ordinary picture. On September 22, 2026, Next.js published GHSA-vcvr-r3jv-pc5j, a critical remote code execution advisory for its next/og ImageResponse implementation. This review focuses on locating the relevant image-generation routes and verifying their deployment.
Affected versions and runtime conditions
The vendor lists Next.js versions from 16.2.0 up to, but excluding, 16.3.6 as affected and 16.3.6 as patched. The issue concerns Node.js ImageResponse when attacker-controlled values enter SVG content, attributes or styles. The Edge implementation and applications without that input condition are excluded. The documented workaround is to stop passing attacker-controlled values into those SVG contexts when an immediate upgrade is unavailable.
Find the image routes that deserve review
Start by inventorying routes that generate social cards, profile banners, product previews or event images. Follow the value from its origin to the renderer. Query parameters are an obvious source, but stored values such as a user-editable display name also require an ownership decision. A value retrieved from your own database can still have been supplied by another person.
- Record the route owner, deployed runtime and resolved Next.js version for each image endpoint.
- Document which strings, attributes and styling values are fixed by your application and which originate outside that trust boundary.
- Include reusable image helpers and shared templates. Reviewing only the route file may miss where the image markup is actually assembled.
- Check previews and less frequently used sharing features; their deployment history may differ from the main website.
Patch the renderer and test ordinary image behavior
Choose a currently supported patched release after reviewing subsequent advisories. The version above is the minimum for this individual historical issue, not a claim that it addresses every later vulnerability. Rebuild the application so the dependency update becomes part of the artifact, deploy it and verify the release identifier serving the image route.
Use normal functional cases during validation: an empty title, a long product name, multilingual text, missing artwork and typical image dimensions. Check that the output remains readable and that failures return controlled responses. These tests help detect upgrade regressions; they do not themselves prove absence of the security flaw. Save the dependency evidence separately from the visual test results.
Make future social-image reviews easier
Keep the image endpoint inventory near the release checklist and assign a maintainer to shared rendering code. Review whether arbitrary styling input is a product requirement or whether a finite set of application-defined themes meets the same need. Record the decision in ordinary terms so a future change does not silently expand the renderer's input surface.
An image returned successfully is only a functional observation. When closing the patch ticket, include the deployment version, runtime, relevant data-flow review and owner approval. Mark inaccessible environments as unverified until their maintainers provide equivalent evidence. This is more useful than a single broad statement that all image features are safe.
Run MyPentest on a website you own or are authorized to assess for its supported security checks. Dedicated detection of GHSA-vcvr-r3jv-pc5j is not confirmed here. Establish exposure using the vendor advisory, deployed dependency evidence and image-route review; a general scan cannot certify this advisory absent.