DEV Community: Devam Chaudhari

Why We Pair Next.js with Umbraco 17 ?

Devam Chaudhari — Wed, 08 Jul 2026 07:49:11 +0000

When building a content-driven website, there are two goals that are often in tension: give visitors a fast, modern, SEO-friendly site, and give the content team a CMS they can actually use without calling a developer every time a page needs to change.

Our answer is to split the problem in two and let each half of the stack do what it's best at:

Umbraco 17, running on .NET 10, as the content backend
Next.js 16 with React 19, running on the App Router, as the presentation layer

Here's why we made that call, and how it plays out in practice.

Two apps, one clean contract

Rather than bolting a headless CMS onto an existing site, we build the two halves as genuinely independent applications that only talk to each other over HTTP:

The Umbraco installation is the backoffice, the content types, the media library, the database. This is where content editors log in, build pages out of reusable blocks, and manage content like blog posts.
The Next.js app is a standalone frontend. It never touches the Umbraco database directly, every piece of content it renders comes from an HTTP call.

That separation is the whole point of a "headless" CMS: the people managing content and the people managing the website's code can move independently. CMS upgrades don't require a frontend deploy, and frontend releases don't require touching the CMS.

The content pipeline: Umbraco's Delivery API

Umbraco 17 ships with a Content Delivery API a built-in, versioned JSON API that exposes published content without any custom plumbing. We lean on it heavily rather than building a bespoke API from scratch, which saves real development time.

A page fetch from Next.js looks like this in practice:

GET /umbraco/delivery/api/v2/content/item/home?expand=properties[$all[properties[$all[properties[$all]]]]]

That expand parameter is doing a lot of work: pages are built by editors dragging and dropping content blocks (hero sections, feature grids, image-and-text panels, calls to action) using Umbraco's Block Grid editor, and those blocks can be nested. The expansion query lets us pull an entire page blocks inside blocks inside blocks in a single round trip instead of chasing references with follow-up requests.

On the Next.js side, a small typed fetch helper wraps every one of these calls, attaches an API key, and lets Next's own data cache handle short-lived revalidation. There's no GraphQL client, no heavyweight SDK just fetch(), TypeScript types that mirror the Umbraco content model, and a short cache window so published changes show up almost immediately without hammering the CMS on every request.

Rendering: server-rendered, block by block

Generic content pages funnel through a single catch-all route that renders server-side on each request. Instead of one big template, rendering is driven by content type: a dispatcher component looks at what kind of block came back from Umbraco a feature section, an image gallery, a testimonial, a two-column layout and hands it off to the matching React component.

The effect is that adding a new content block is mostly a two-sided change: define the element type in Umbraco, add a matching case in the renderer. Editors get a new building block to compose pages with; developers don't have to build new pages from scratch every time a new layout is needed.

Beyond the CMS defaults

The Delivery API covers page content well, but a few features need more than "fetch a page and render it":

Filtering and search. Category pages, tag pages, and "previous/next" navigation are backed by custom API endpoints that walk the content tree directly, and free-text search runs on Umbraco's built-in Lucene-based indexer rather than an external search service. That avoids standing up and paying for a separate search product just to let visitors search content.
Forms. Submissions are validated in the browser, sent through a Next.js API route, and stored by a small custom endpoint on the Umbraco side with a lightweight dashboard added to the Umbraco backoffice so the team can review submissions without leaving the CMS they already use every day.
Media handling. Images uploaded into Umbraco's media library are served through Next.js's image optimizer, so editors don't need to think about responsive image sizes or formats that's handled automatically on the way out.

What this stack gets you

Putting it together, the architecture gives:

Speed, from server rendering and Next.js's image and asset optimization
SEO control that lives with content, since page titles, descriptions, and indexing rules are authored directly in Umbraco and flow straight into page metadata no separate SEO tooling to keep in sync
A content team that isn't blocked by developers, because new pages are built from existing blocks rather than new code
A frontend that isn't blocked by the CMS release cycle, because the two halves deploy independently

Trade-offs worth naming

Being candid, this approach isn't free. Running on Umbraco 17 and Next.js 16 means running close to the front of both ecosystems fewer battle-tested examples to lean on, but a stack that stays current for years rather than needing a rewrite in one. And a headless setup means CMS preview/draft workflows, sitemaps, and secrets/hosting management all need to be built or configured deliberately they don't come for free just because the CMS has them out of the box in a traditional, non-headless setup.

For a site with a real content operation behind it, splitting "where content lives" from "how it's presented" is worth the extra moving part. It lets each side of the team content and engineering work at their own pace, without waiting on each other.

MCP vs API: Why Traditional APIs Are Failing AI Agents

Devam Chaudhari — Sat, 04 Jul 2026 04:15:29 +0000

As a frontend and full-stack developer who has spent the last four years building modern web applications, I’ve wired up more REST and GraphQL endpoints than I care to count. I know how to optimize a payload, handle state, and read a Swagger doc.

But over the last year, as the industry shifted from building deterministic web apps to deploying autonomous AI agents, I noticed a frustrating trend: Our battle-tested APIs are making our AI agents slow, expensive, and surprisingly brittle.

We’ve been treating LLMs like human frontend developers who just need an API endpoint to fetch data. That is a fundamental architecture mistake.

Enter the Model Context Protocol (MCP)—an open standard originally introduced by Anthropic and now backed by the Linux Foundation. If you are still building AI features by manually wrapping traditional REST endpoints in custom glue code, you are accumulating technical debt. Here is why traditional APIs are failing AI agents, and why MCP is the universal adapter we actually need.

The Root Problem: The $N \times M$ Integration Nightmare

When building traditional apps, if you want your frontend or backend to talk to GitHub, Slack, and Jira, you write three distinct integration layers. You map their custom JSON payloads, handle their specific authentication, and hardcode the execution paths.

This works because human-written code is deterministic.

But AI agents operate on reasoning and intent. If you have 5 different LLM frameworks (LangChain, LlamaIndex, or custom agent setups) and you want them to interact with 5 different enterprise tools, you are suddenly stuck writing and maintaining $5 \times 5 = 25$ custom connectors.

This is the classic $N \times M$ integration problem.

MCP collapses this into an $N + M$ architecture. Every tool implements one MCP server. Every AI agent framework implements one MCP client. The protocol acts as a universal adapter—the USB-C port for LLMs.

3 Reasons Traditional APIs Fail AI Agents

To understand why we need a new protocol, we have to look at where traditional REST/GraphQL APIs fall short when an LLM is the one consuming them.

1. APIs are Static; Agents Require Runtime Discovery

When we write code against a REST API, we hardcode the endpoint: GET /api/v1/users/{id}. The application cannot deviate from this path.

An AI agent, however, needs to look at a situation, evaluate its options, and decide at runtime what tool to use.

The REST Way: You have to feed the entire API schema into the LLM's system prompt so it knows what endpoints exist. If you add a new endpoint or update a parameter, you must update the prompt or code and re-deploy.
The MCP Way: MCP features dynamic discovery. When an MCP client connects to an MCP server, it issues a tools/list request. The server replies with a machine-readable list of available capabilities, natural-language descriptions, and structural constraints. The agent discovers what it can do on the fly.

2. The "Token Tax" and Context Bloat

In the frontend world, over-fetching is a minor performance nuisance. If a JSON payload returns 50 fields when you only need 2, your JavaScript objects handle it in microseconds.

In the AI world, tokens are literal currency.

If you pass a massive, bloated enterprise REST response directly to an LLM, you are wasting money, increasing latency, and worse—causing context rot. LLMs lose focus when drowned in irrelevant metadata. They miss critical data buried deep within deeply nested JSON objects.

Traditional APIs are designed for human developers who want comprehensive payloads. MCP servers are designed specifically to return data optimized for LLM context windows, separating executable tools, readable resources, and prompt templates.

3. Stateless vs. Stateful Architecture

REST APIs are deliberately stateless. Each request is an isolated event.

AI agents do not operate in a vacuum; they work via a continuous loop of thought, action, observation, and refinement.

MCP runs over a stateful JSON-RPC 2.0 session (typically via stdio for local tools or WebSockets/SSE for remote services). This allows the MCP server and the agent to engage in a stateful negotiation, allowing context to persist and influence subsequent actions without re-sending massive payloads back and forth across the wire.

The Architecture of MCP

MCP defines a clean separation of concerns across three core primitives:

Tools: Executable actions the model can take (e.g., "Run this git commit," "Execute this SQL query").
Resources: Read-only data sources that provide raw context to the model (e.g., log files, local markdown docs, API responses).
Prompts: Reusable templates that help guide the model's reasoning workflow.

+-------------------------------------------------------------+
|                         Host App                            |
|  (e.g., Cursor, Claude Desktop, Custom Agent Framework)     |
|                                                             |
|       +---------------------------------------------+       |
|       |                 MCP Client                  |       |
|       +---------------------------------------------+       |
+------------------------------|------------------------------+
                               |
                        JSON-RPC 2.0 
                  (stdio / WebSockets / SSE)
                               |
+------------------------------v------------------------------+
|                         MCP Server                          |
|  (Exposes: Tools, Resources, and Prompt Templates)          |
|                                                             |
|   Under the hood: Translates to Postgres, GitHub API, etc.  |
+-------------------------------------------------------------+

An important clarification: MCP does not replace your database or backend APIs. Your MCP server will still call your internal REST APIs or databases under the hood. What MCP replaces is the brittle, custom glue code we've been writing to expose those services to an LLM.

Moving Forward: Stop Wrapping, Start Structuring

If you're still writing custom JavaScript or Python functions to stringify JSON payloads and forcing them into a tools array inside your LLM API calls, you are building debt that you'll have to pay off later.

The industry is rapidly consolidating around MCP. Major IDEs, orchestration frameworks, and AI providers have adopted it as the standard.

As developers, our job isn't just to make things work; it's to build architectures that scale. Traditional APIs were built for deterministic, human-written software. MCP was built for the probabilistic, agentic future. It's time to update our stack.

What are your thoughts? Have you migrated any internal tooling to MCP yet, or are you still sticking with traditional custom function calling? Let’s discuss in the comments below!

The Vulnerability: CVE-2026-2441

Devam Chaudhari — Sun, 22 Feb 2026 15:31:42 +0000

CVE-2026-2441 is a Use-After-Free (UAF) vulnerability found within the Google Chrome "Blink" rendering engine. Specifically, it resides in how the browser handles CSS font feature values.

In memory-managed environments like a browser engine, "Use-After-Free" occurs when a program continues to use a pointer after the memory it points to has been released (freed). This is a classic memory corruption bug that can lead to arbitrary code execution.

What Causes the Issue?

The root of the problem lies in the manual memory management of C++, the language used to build the Blink engine.

1) Memory Allocation: When a website utilizes specific font features (like @font-feature-values), the browser allocates a block of memory to store those objects.

2) Premature Freeing: Due to a bug in the logic, Chrome may release this memory while the CSS engine still thinks the data is active.

3) The Dangling Pointer: The browser retains a "dangling pointer"—a reference that points to a now-empty or reallocated memory address.

4) Exploitation: An attacker can use JavaScript to "spray" the heap, filling that recently freed memory with malicious code. When the CSS engine eventually tries to access the font feature via the dangling pointer, it inadvertently executes the attacker's code instead.

Insights from the Proof of Concept (PoC)

The public PoC for this vulnerability targets the @font-feature-values CSS rule. By rapidly creating and removing stylesheets or manipulating DOM elements associated with these font features, the script triggers the memory corruption.

In a successful PoC execution, the browser tab typically crashes (often showing an "Error code: 11" or "Aw, Snap!" page). While a tab crash is a simple denial-of-service, in a real-world "in-the-wild" exploit, this is used as the first step in a chain to escape the browser sandbox and gain control over the underlying operating system.

Why Some Browsers Are Immune

A notable takeaway from this vulnerability is the difference in engine architecture. Firefox, for example, is largely unaffected by this specific class of CSS vulnerability because its styling engine (Stylo) is written in Rust.

Unlike C++, Rust’s compiler enforces "ownership" and "borrowing" rules that prevent Use-After-Free bugs at compile-time. If a developer tries to use a pointer after the data has been freed, the code simply won't compile, effectively neutralizing this entire category of security risks

Developer Takeaway

As developers, we often assume that vulnerabilities only live in our JavaScript logic or backend APIs. CVE-2026-2441 is a reminder that the platform itself—the browser—is a complex piece of software with its own attack surface.

Action Required: Ensure your browser is updated to the latest version. If you are running a version of Chrome or a Chromium-based browser (like Edge or Brave) older than 145.0.7632.275, you are likely vulnerable to this exploit.

References:

Vulnerability Report: CVE-2026-2441

Research & PoC: huseyinstif/CVE-2026-2441-PoC

Technical Deep Dive: CSS Got Hacked! - Mehul Mohan

Understanding CVE-2025-59471: Out-of-Memory DoS in Next.js

Devam Chaudhari — Thu, 12 Feb 2026 10:46:47 +0000

If you are running Next.js in a self-hosted environment and have configured remotePatternsfor image optimization, a newly disclosed vulnerability (CVE-2025-59471) could put your application's availability at risk.

This vulnerability allows an attacker to trigger a Denial of Service (DoS) by exhausting your server's memory.

The Vulnerability: Uncontrolled Resource Consumption (CWE-400)

The Next.js Image Optimization endpoint (/_next/image) is designed to resize images from allowed external domains.

The Root Cause

The vulnerability exists because the Image Optimizer loads external images entirely into memory without enforcing a maximum size limit.

An attacker can exploit this by:

Identifying a domain you have whitelisted in your remotePatterns.
Hosting an extremely large image file on that domain (or gaining control of a path on that domain).
Requesting that large image through your /_next/image endpoint.

Because the server attempts to pull the entire large file into RAM to process it, it can trigger an Out-of-Memory (OOM) condition, causing your Node.js process to crash and take your site offline.

You are at risk if:

You are self-hosting (the vulnerability does not affect Vercel's managed infrastructure).
You have images.remotePatterns configured in next.config.js.
You are running one of the following versions:
- Next.js 10.0.0 through 15.5.9
- Next.js 15.6.0-canary.0 through 16.1.4

How to Fix It

The official fix involves upgrading to versions where Next.js now enforces limits on the resources consumed during optimization.

1 . Update your dependencies immediately
Update your project to the first patched versions or higher:

Next.js 15.x: Upgrade to v15.5.10
Next.js 16.x (Canary/Pre-release): Upgrade to v16.1.5

npm install next@15.5.10
# or
yarn add next@15.5.10

2 . Audit your remotePatterns

As a security best practice, ensure your remotePatterns are as specific as possible. Avoid using broad wildcards that might allow an attacker to serve large images from unexpected subdomains of a trusted provider.

Node.js January 2026 DoS Vulnerability in Async Hooks

Devam Chaudhari — Thu, 15 Jan 2026 03:02:40 +0000

If you are running Node.js in production, it’s time to check your version numbers.

Earlier today, the Node.js team released a critical security update regarding a Denial of Service (DoS) vulnerability tied to the async_hooksmodule. If you use observability tools, tracing libraries, or AsyncLocalStorageyour application might be at risk.

In this post, we’ll break down what happened, why async_hooksis involved, and how to fix it.

What is async_hooks anyway?

Before we dive into the vulnerability, let’s recap. The async_hooks API is a powerful, low-level built-in module in Node.js that allows you to track the lifetime of asynchronous resources (like promises, timeouts, or TCP wraps).

It’s the engine behind many things we love:

AsyncLocalStorage: Used for keeping track of request IDs across different functions.
APM Tools: New Relic, Datadog, and OpenTelemetry use it to trace requests.
Logging Frameworks: To inject context into your logs. Because it hooks into the very core of Node.js’s event loop, any inefficiency or bug here can have massive performance implications.

The Vulnerability: The "January 2026" DoS

The security team identified a flaw in how Node.js manages memory and resource tracking when async_hooks are enabled.

The Exploit

A malicious actor could craft specific asynchronous patterns likely involving deeply nested or recursive async calls that cause the internal resource tracking mechanism to consume an unbound amount of memory or CPU cycles.

The result? An Out-of-Memory (OOM) crash or a CPU spike that makes the server unresponsive. Because this happens at the internal level, standard application-level try-catch blocks won't save you.

Who is affected?

You are likely affected if:

You are using an unpatched version of Node.js (v20.x, v22.x, or v24.x).
Your application (or its dependencies) uses async_hooks or AsyncLocalStorage.
Your server processes untrusted user input that triggers asynchronous logic.

The Fix: Update Now

The Node.js team has released patched versions for all active Long-Term Support (LTS) and Current branches.

1) Identify your version
Check your current Node.js version:

node -v

2) Update to the patched versions
Depending on your release line, you should update to at least:

Node.js v24.x -> Update to v24.X.X (Latest)
Node.js v22.x (LTS) -> Update to v22.X.X
Node.js v20.x (LTS) -> Update to v20.X.X

(Note: Replace the X with the specific version numbers mentioned in the official advisory)

3) How to update
If you use nvm (Node Version Manager):

nvm install 22 --reinstall-packages-from=22
nvm use 22

If you use Docker, update your base image:

# From
FROM node:22-slim
# To the latest patch
FROM node:22.14.0-slim (or similar)

I just finished upgrading my project, to the latest LTS version. Here is the exact workflow I used to secure the environment.

If you are on Windows and using nvm-windows, follow these steps to move to the latest, most secure Long-Term Support (LTS) version.

1) Update your Node Runtime
First, we need to grab the latest LTS version (currently v24.13.0) and tell our system to use it

# Install the latest Long-Term Support version
nvm install lts

# Switch your active version to LTS
nvm use lts

Pro Tip: You can verify you are on the right version by running node -v. You should see v24.13.0.

2) Align your TypeScript Definitions
Updating Node isn't enough if you're using TypeScript. Your @types/node package needs to match your runtime so your editor knows about the latest APIs and security features.

Check your package.json. If you're on Node 24 but your types are still on ^20, you're essentially "type-blind" to the new version's features.

Run this to sync them up:

npm install --save-dev @types/node@^24

3) The Final Security Sweep
Once your environment is updated, it's time to check your actual project dependencies. Thousands of packages are updated daily to patch vulnerabilities—npm audit is your best friend here.

npm audit

If you see vulnerabilities, you can attempt an automatic fix:

npm audit fix

Temporary Mitigation (If you can't update immediately)

If for some reason you cannot update your Node.js runtime today, consider these steps:

Audit Dependencies: Check if you are using libraries like cls-hooked or older tracing agents that rely heavily on async_hooks and see if they have issued their own workarounds.
Disable Non-Essential Tracing: If you are using AsyncLocalStorage only for non-critical logging, consider disabling it temporarily in high-risk environments.
Rate Limiting: Implement aggressive rate limiting at the Reverse Proxy (Nginx/Cloudflare) level to prevent attackers from flooding your event loop with complex async requests

For more details, read the full official security blog post at nodejs.org.

Next.js at the Speed of Bun: Why the Runtime is Your New Performance Bottleneck

Devam Chaudhari — Fri, 19 Dec 2025 07:21:03 +0000

For years, we’ve optimized our Next.js apps at the framework level—we’ve moved to Turbopack, adopted React Server Components (RSC), and fine-tuned our caching strategies. But there’s a fundamental layer we’ve ignored: the runtime.

In a recent talk at Vercel, Lydia Hallie (Head of Propaganda at Bun) made a compelling case for why the future of Next.js isn't just about the framework—it's about the engine under the hood.

The Node.js Bottleneck

Node.js was a revolution when it launched in 2009. However, it was designed for a different era of hardware (limited cores, slow storage). In 2025, our hardware is 50x faster, yet Node still pushes everything through an architecture that requires multiple layers of abstraction (V8 -> C++ Bindings -> libuv -> OS) just to read a file or make a network request.

In modern environments like serverless functions and hot-reloading dev servers, these milliseconds of overhead add up to significant latency.

Enter Bun: Re-engineered for 2025

Bun isn't just a "faster Node." It’s a runtime built from the ground up in Zig. By using Apple’s JavaScriptCore (the engine powering Safari), Bun prioritizes fast startup and low memory usage—perfect for the short-burst tasks typical of modern web development.

Key advantages of running Next.js on Bun include:

Direct System Calls: Bun eliminates layers of abstraction, making file access and HTTP streaming significantly faster.
Built-in Tooling: You get a package manager (up to 17x faster than Yarn), a bundler, a transpiler, and a test runner (up to 23x faster than Jest) out of the box.
The "Batteries Included" API: Need to connect to PostgreSQL or S3? Instead of installing heavy NPM packages, Bun provides native APIs that are up to 11x faster than their Node/NPM counterparts.

How to Use Bun with Next.js Today

The transition is designed to be seamless. Because Bun aims for 100% Node compatibility, you can start using it incrementally:

Step 1: Swap npm install for bun install. It’s faster and changes nothing in your codebase.

Step 2: Run your dev server with Bun:

bun run --bun next dev

The --bun flag tells Bun to use its own runtime even if the script specifies Node.

Step 3: Use Bun's native APIs (like bun.sql or Bun.S3) inside your Server Components to reduce bundle size and latency.

Deployment: Vercel + Bun

The most exciting news from the talk? Native Bun support is coming to Vercel. Internal tests have already shown up to a 30% drop in CPU usage just by switching the runtime. This means your apps won't just be faster; they'll be cheaper and more efficient to run.

Conclusion

We’ve spent a decade optimizing our JavaScript. Now, it’s time to optimize the environment where that JavaScript lives. By combining the developer experience of Next.js with the raw speed of Bun, we’re entering a new era of web performance.

Watch the full talk here: Next.js at the speed of Bun

CRITICAL: New React Server Component Vulnerabilities - Denial of Service and Source Code Exposure

Devam Chaudhari — Fri, 12 Dec 2025 03:51:08 +0000

Heads up, React developers! The React team just announced two new vulnerabilities in React Server Components that could lead to a denial of service or expose your source code. If you are using React Server Components in production, you should patch your application immediately.

This article covers the general React vulnerabilities and the specific impact on Next.js.

Here’s a breakdown of what you need to know.

The Vulnerabilities (React)

The two vulnerabilities are:

Denial of Service (DoS) - High Severity (CVSS 7.5, CVE-2025-55184)
Source Code Exposure - Medium Severity (CVSS 5.3, CVE-2025-55183)

Denial of Service (DoS)

A specially crafted HTTP request can trigger an infinite loop on your server. This will cause the server to become unresponsive, leading to a denial of service for your users. This is a high-severity vulnerability, and you should address it immediately.

Source Code Exposure

This vulnerability allows a malicious actor to potentially access the source code of your Server Functions. By sending a specially crafted HTTP request, they could expose your code, including any hardcoded secrets or other sensitive information. This is a medium-severity vulnerability but can have serious consequences.

Are You Affected? (React)

You are affected by these vulnerabilities if you are using React Server Components. This includes frameworks and bundlers such as:

Next.js
react-router
Waku
@parcel/rsc
@vite/rsc-plugin
rwsdk

If you are not using a server or your application does not support React Server Components, you are not affected.

The Fix (React)

The React team has released patched versions of the following packages:

react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack

You should immediately upgrade to the latest versions (19.0.3, 19.1.4, 19.2.3) to patch these vulnerabilities.

For React Native developers, the React team has provided specific instructions for updating the impacted packages in your monorepo.

What to Do Now (React)

Check if you are affected: Determine if your application uses React Server Components.
Upgrade your dependencies: If you are affected, upgrade your react-server-dom-* packages to the latest patched versions.
Audit your code: Even after patching, it’s a good practice to audit your code for any hardcoded secrets and move them to a secure location.

Next.js Specific Information (Update)

The Next.js team has released a security update addressing the downstream impact of the React Server Component vulnerabilities on applications using the App Router.

Important Note: The initial fix for the Denial of Service vulnerability (CVE-2025-55184) was incomplete. A complete fix has been issued under CVE-2025-67779. If you previously upgraded, you must upgrade again to the latest patched versions.

Affected and Fixed Next.js Versions

Your Next.js application is affected if you are using the App Router. The Pages Router is not affected.

Here are the patched versions you need to upgrade to:

Version	Fixed In
>=13.3	14.2.35
14.x	14.2.35
15.0.x	15.0.7
15.1.x	15.1.11
15.2.x	15.2.8
15.3.x	15.3.8
15.4.x	15.4.10
15.5.x	15.5.9
15.x canary	15.6.0-canary.60
16.0.x	16.0.10
16.x canary	16.1.0-canary.19

Required Action for Next.js Users

All users should upgrade to the latest patched version for their release line. There is no workaround.

You can use npm or yarn to install the patched version, for example:

npm install next@14.2.35  # for 14.x
npm install next@15.0.7   # for 15.0.x
npm install next@15.1.11  # for 15.1.x
npm install next@15.2.8   # for 15.2.x
npm install next@15.3.8   # for 15.3.x
npm install next@15.4.10  # for 15.4.x
npm install next@15.5.9   # for 15.5.x
npm install next@16.0.10  # for 16.0.x

npm install next@15.6.0-canary.60   # for 15.x canary releases
npm install next@16.1.0-canary.19   # for 16.x canary releases

Alternatively, you can use the interactive fix-react2shell-next tool to check your version and perform the upgrade:

npx fix-react2shell-next

Reference links:

Critical RCE Vulnerability in React Server Components: Understanding and Mitigating CVE-2025-6678 (React2Shell)

Devam Chaudhari — Mon, 08 Dec 2025 11:53:39 +0000

A Critical Vulnerability in the React Ecosystem

A critical remote code execution (RCE) vulnerability, nicknamed React2Shell and tracked as CVE-2025-6678, has been discovered in React Server Components. This is a high-severity flaw that could allow an attacker to take control of your server.

This post will break down what the vulnerability is, who is affected, and what you need to do immediately to protect your applications.

What is the React2Shell Vulnerability?

The React2Shell vulnerability is a critical security issue that affects applications using React Server Components. It allows an unauthenticated attacker to execute arbitrary code on the server by sending a specially crafted HTTP request.

The vulnerability resides in the react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack packages. The root cause is a deserialization issue in how React Server Components handle data from the client.

Are You Affected?

The vulnerability impacts specific versions of React and frameworks that use React Server Components.

Affected React Versions:

react-server-dom-webpack: 19.0, 19.1.0, 19.1.1, 19.2.0
react-server-dom-parcel: 19.0, 19.1.0, 19.1.1, 19.2.0
react-server-dom-turbopack: 19.0, 19.1.0, 19.1.1, 19.2.0

Affected Frameworks:

Next.js: Versions 15.0.0 through 16.0.6, and some canary versions of 14.x.
React Router: Unstable RSC APIs.
Other frameworks and bundlers: Waku, @parcel/rsc, @vitejs/plugin-rsc, and rwsdk.

How to Check Your Application

The community has quickly responded with tools to help you determine if your project is vulnerable.

You can check your project by running the following command in your project's root directory:

npx react2shell-guard

This command will analyze your dependencies and inform you if your project is using an affected version.

How to Fix the Vulnerability

The most critical step is to upgrade your dependencies to the patched versions.

For Next.js Applications

If you are using Next.js, you should upgrade to the latest version of Next.js, which will include the patched version of React. The patched versions for Next.js are:

15.0.x: 15.0.5 or newer
15.1.x: 15.1.9 or newer
15.2.x: 15.2.6 or newer
15.3.x: 15.3.6 or newer
15.4.x: 15.4.8 or newer
15.5.x: 15.5.7 or newer
16.0.x: 16.0.7 or newer

You can use the fix-react2shell-next tool provided by Vercel to automatically upgrade your dependencies.

Run the following command in your project's root directory:

npx fix-react2shell-next

This will update your package.json to use a patched version of Next.js. After running the command, be sure to install the updated dependencies:

npm install
# or
yarn install
# or
pnpm install

For other frameworks

If you are not using Next.js, you need to manually update your React packages to the patched versions:

React 19.0.x: Upgrade to 19.0.1
React 19.1.x: Upgrade to 19.1.2
React 19.2.x: Upgrade to 19.2.1

Rotate Your Secrets

Because this vulnerability allows for remote code execution, it is crucial that you rotate any secrets and credentials that your application has access to. This includes API keys, database passwords, and any other sensitive information.

Conclusion

The React2Shell vulnerability is a serious threat, but the fix is relatively straightforward. It is essential to act now to protect your applications and your users' data.

Check your application for the vulnerability using npx react2shell-guard.
Upgrade your dependencies using npx fix-react2shell-next for Next.js or by manually updating your React packages.
Rotate your secrets.

Stay safe, and keep your applications secure!

Disclaimer: This blog post is based on the information available from the official React and Vercel announcements. Please refer to the official sources for the most up-to-date information.

Solving React's "Zombie Children," Tearing, and Context Loss with Zustand

Devam Chaudhari — Mon, 24 Nov 2025 06:42:55 +0000

React is a powerful library for building user interfaces, but as applications grow in complexity, developers often run into a few tricky state management issues. Three of the most common are the "zombie child" problem, UI tearing in concurrent mode, and performance degradation from React's Context API.

Fortunately, a lightweight and elegant state management library called Zustand provides a simple solution to all three. Let's dive into what these problems are and how Zustand helps you sidestep them entirely.

The Problems We Face

1. The "Zombie Child" Problem (Stale Props)

The "zombie child" effect happens when a parent component re-renders, but a child component that has been unmounted (or is in the process of unmounting) still manages to trigger a state update. This child is a "zombie"—it's not really alive in the component tree, but its old logic (often from a closure with stale state) is still running.

This can lead to unpredictable bugs, memory leaks, and state updates that are based on outdated information.

2. React Concurrency and Tearing

React 18 introduced concurrent rendering, a powerful feature that allows React to pause and resume rendering work to keep the UI responsive. However, this can cause a problem called "tearing."

Tearing is a visual glitch where different components on the screen display different values for the same state. This happens when a state update is read by one component, but before another component can read it, React pauses the render. The result is a temporarily inconsistent UI. Libraries that aren't built with concurrency in mind are susceptible to this.

3. Context Loss (The Performance Pitfall of React Context)

React's built-in Context API is fantastic for passing state down the component tree without prop-drilling. However, it has a major performance drawback:

Any component consuming a context will re-render whenever any value in that context changes.

Imagine a context holding user settings, a shopping cart, and theme information. If a user adds an item to the cart, every component connected to that context will re-render, even the ones that only care about the theme. This causes unnecessary renders and can slow down your application.

// Any component using this context will re-render if 'cart' or 'theme' changes.
const AppContext = React.createContext({
  cart: [],
  theme: 'dark',
});

// This component only cares about the theme...
function ThemeToggler() {
  const { theme, setTheme } = useContext(AppContext); // ...but it will re-render when the cart changes!
  return <button onClick={toggleTheme}>{theme}</button>;
}

The Solution: Enter Zustand

Zustand is a small, fast, and scalable state management solution. It leverages a simple hook-based API but keeps state outside of the React component tree. This architectural choice is the key to solving all the problems above.

How Zustand Solves These Issues

1. Solving Context Loss with Selective Subscriptions

Zustand avoids the context performance trap by allowing components to subscribe to only the specific pieces of state they need. This is done through selectors.

A component will only re-render if the exact value returned by its selector function changes.

Creating a Zustand Store:

import { create } from 'zustand';

const useStore = create((set) => ({
  count: 0,
  theme: 'light',
  increment: () => set((state) => ({ count: state.count + 1 })),
  toggleTheme: () => set((state) => ({ theme: state.theme === 'light' ? 'dark' : 'light' })),
}));

Using the Store with Selectors:

// This component ONLY subscribes to `count`.
// It will NOT re-render when the theme changes.
function Counter() {
  const count = useStore((state) => state.count);
  const increment = useStore((state) => state.increment);
  return <button onClick={increment}>Count is: {count}</button>;
}

// This component ONLY subscribes to `theme`.
// It will NOT re-render when the count changes.
function ThemeDisplay() {
  const theme = useStore((state) => state.theme);
  return <div>Current theme: {theme}</div>;
}

2. Solving Concurrency Tearing and Zombie Children

Because Zustand's state lives outside of React, it doesn't suffer from the same lifecycle issues. To safely connect this external state to React's concurrent rendering, Zustand uses the useSyncExternalStore hook under the hood.

This is a special hook provided by React specifically for this purpose. It guarantees that subscriptions to external data sources (like a Zustand store) are safe from tearing and that components always read the most up-to-date information.

This completely eliminates tearing and makes the "zombie child" problem a non-issue, as any logic running from an unmounted component will be operating on a consistent, external state that won't cause inconsistent React renders.

Conclusion

While React's built-in tools are powerful, they come with trade-offs. For applications with complex, shared state, the "zombie child" problem, tearing, and context performance issues can become significant hurdles.

Zustand offers a clean and effective solution by:

Keeping state external to the React component tree.
Using selectors to prevent unnecessary re-renders.
Integrating with React's concurrent mode safely via useSyncExternalStore.

If you're looking for a state management solution that is both simple to use and highly performant, give Zustand a try in your next project. It provides the power you need without the common pitfalls.

JSON vs. TOON: A Token-Saving Showdown for LLMs

Devam Chaudhari — Sat, 08 Nov 2025 13:46:45 +0000

In the world of Large Language Models (LLMs), every token counts. As developers, we're constantly seeking ways to optimize our prompts and reduce token consumption, which directly translates to lower costs and faster response times. While JSON has long been the king of data interchange, a new contender has emerged: TOON (Token Object Notation). But what is TOON, and can it really save you tokens? Let's dive in.

What is JSON?

JSON (JavaScript Object Notation) is a lightweight data-interchange format that is easy for humans to read and write and easy for machines to parse and generate. It's built on two structures:

A collection of name/value pairs (e.g., an object, record, struct, dictionary, hash table, keyed list, or associative array).
An ordered list of values (e.g., an array, vector, list, or sequence).

A simple JSON example looks like this:

{
  "name": "John Doe",
  "age": 30,
  "isStudent": false,
  "courses": [
    {
      "title": "History",
      "credits": 3
    },
    {
      "title": "Math",
      "credits": 4
    }
  ]
}

While JSON is ubiquitous and well-supported, its verbosity can be a drawback when working with LLMs. The repeated keys and structural characters (curly braces, brackets, commas, and quotes) all contribute to the total token count.

What is TOON?

TOON (Token Object Notation) is a more compact, token-efficient data format designed with LLMs in mind. It aims to represent structured data with minimal overhead. TOON achieves this by using a more concise syntax that reduces the number of characters needed to represent the same information.

Here's the same data from our JSON example, but in TOON format:

(
  name: "John Doe",
  age: 30,
  isStudent: false,
  courses: [
    (title: "History", credits: 3),
    (title: "Math", credits: 4)
  ]
)

As you can see, TOON replaces the curly braces {} with parentheses () and eliminates the need for quotes around keys. This might seem like a small change, but it can lead to significant token savings, especially with large and complex datasets.

The Token-Saving Advantage

The primary benefit of TOON is its ability to reduce the number of tokens required to represent data. Let's break down the token counts for our examples:

JSON: The JSON example has 15 tokens (this can vary slightly based on the tokenizer used).
TOON: The TOON example has 12 tokens.

In this small example, we've already saved 3 tokens, a 20% reduction. Imagine a scenario where you're sending a large array of objects to an LLM. The savings from eliminating quotes around keys and using a more compact structure can quickly add up.

Furthermore, to maximize token savings with TOON, it's often beneficial to flatten nested JSON structures before conversion. Nested objects and arrays, while semantically rich, can introduce redundant keys and structural overhead. By flattening the data into a more linear structure, you can reduce the overall complexity and the number of tokens required to represent the information, making your prompts even more efficient.

When to Use TOON

While TOON offers clear advantages in token efficiency, it's not a universal replacement for JSON. Here are a few things to consider:

LLM-Specific Interactions: TOON is ideal for direct communication with LLMs where token count is a primary concern.
Tooling and Support: JSON is the industry standard and has vast support across languages, libraries, and APIs. TOON is newer and has a smaller ecosystem.
Readability: While TOON is still human-readable, some developers might find JSON's syntax more familiar and easier to parse visually.

Conclusion

TOON presents a compelling alternative to JSON for developers working with LLMs. Its token-efficient design can lead to significant cost and performance improvements. While it may not replace JSON entirely, it's a valuable tool to have in your arsenal for optimizing your LLM-powered applications. As the field of AI continues to evolve, we can expect to see more innovations like TOON that help us build more efficient and powerful applications.

The Future of Web Development: A Deep Dive into React v19 and Next.js 16

Devam Chaudhari — Tue, 04 Nov 2025 11:20:20 +0000

The web development landscape is constantly evolving, and the latest releases of React and Next.js are set to push the boundaries once again. React v19 and Next.js 16 bring a host of new features and improvements that promise to enhance performance, streamline development workflows, and empower developers to build more powerful and engaging applications.

React v19: A New Era of React

React v19 is a major release that introduces a number of long-awaited features and improvements. Here are some of the key highlights:

React Server Components (RSC): This is arguably the most significant new feature in React v19. RSC allows developers to write components that render on the server, reducing the amount of JavaScript that needs to be sent to the client. This can lead to significant performance improvements, especially for complex applications.
Actions: Actions provide a new way to handle data mutations and state updates. They automatically manage pending states, errors, and optimistic updates, making it easier to build robust and user-friendly forms.
useOptimistic Hook: This new hook makes it easy to implement optimistic updates, where the UI is updated immediately after a user takes an action, even before the server has responded. This can create a much more responsive and engaging user experience.
useActionState Hook: This hook is designed to simplify the handling of data mutations and state updates within Actions. It manages the pending state and returns the final result, making it easier to build complex forms and other data-driven components.
React Compiler: The React Compiler is a new tool that optimizes your React code behind the scenes. It can automatically memoize components and hooks, eliminating the need for manual optimizations and improving performance.
ref as a Prop: In React v19, you can now pass a ref to a function component as a prop, just like any other prop. This simplifies the process of working with refs and makes it easier to create reusable components.

Next.js 16: The Perfect Partner for React v19

Next.js 16 is the latest version of the popular React framework, and it's packed with new features and improvements that make it the perfect partner for React v19. Here are some of the key highlights:

Turbopack as Default Bundler: Next.js 16 now uses Turbopack as its default bundler. Turbopack is a new, high-performance bundler that's written in Rust. It's significantly faster than Webpack, which can lead to a much faster development experience.
Cache Components: This new feature allows you to cache components on the server, which can lead to significant performance improvements.
React Compiler Support: Next.js 16 includes built-in support for the React Compiler. This means that you can take advantage of the compiler's performance optimizations without having to configure it yourself.
Enhanced Routing: The routing system in Next.js 16 has been completely rebuilt. It's now faster and more flexible, and it includes a number of new features that make it easier to build complex routing scenarios.
proxy.ts (Replaces middleware.ts): The middleware.ts file has been renamed to proxy.ts. This change reflects the fact that middleware is now more powerful and can be used to proxy requests to other servers.

The Future is Bright

React v19 and Next.js 16 are two of the most exciting new releases in the web development world. They bring a host of new features and improvements that promise to enhance performance, streamline development workflows, and empower developers to build more powerful and engaging applications. If you're a web developer, you should definitely check out these new releases.

🚨 Largest NPM Compromise in History: A Deep Dive into the 2025 Supply Chain Attack

Devam Chaudhari — Tue, 09 Sep 2025 06:57:52 +0000

In what is being hailed as the most extensive supply chain attack in the history of the npm ecosystem, 18 widely-used JavaScript packages—including chalk, debug, and ansi-styles—were compromised with malicious code. This breach affected packages with over 2 billion weekly downloads, highlighting a critical vulnerability in the open-source supply chain.

🧩 The Attack Unfolded

The breach was traced back to a phishing attack targeting qix, the primary maintainer of several popular npm packages. The attacker impersonated npm support, convincing qix to update their two-factor authentication settings. Once compromised, the attacker published malicious versions of 18 packages, embedding a cryptocurrency drainer malware designed to hijack Web3 wallet transactions

📦 Affected Packages

The compromised packages included:

These packages are deeply integrated into major frameworks and tools, including React, Next.js, and Express, making the attack's reach extensive

🔍 Technical Details

The malicious code was designed to monitor for Web3 wallet addresses and replace them with the attacker's own address, redirecting cryptocurrency transactions in real-time. This sophisticated approach allowed the attacker to intercept funds without alerting the user.
Security experts have advised developers to audit their dependencies for the presence of the malicious code. One method suggested is searching for the string _0x112fa8 within the project's dependency tree

🛡️ Community Response and Mitigation

The npm community responded swiftly to the breach. The compromised versions were removed from the registry, and maintainers issued advisories to update to safe versions. Security tools like Semgrep and Aikido have been updated to detect the malicious code in affected packages.
Discussions on platforms like Reddit and Hacker News have highlighted the risks associated with deep dependency chains and the challenges of securing the open-source supply chain. Some community members have pointed out that the attack's focus on cryptocurrency transactions underscores the need for better security practices in handling sensitive data within the npm ecosystem

🔗 Further Reading

GitHub Issue #656 – Chalk

Reddit Discussion on r/programming

Security Alliance Report