DEV Community: Devam Chaudhari

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

🚀 How I Migrated My Frontend Project to Vite (and Why You Should Too)

Devam Chaudhari — Mon, 11 Aug 2025 13:07:19 +0000

Recently, I decided to give my project a serious performance boost by migrating from Create React App (CRA) with Webpack to Vite.

I’d been hearing about Vite’s insane speed and developer experience for months — and yes, it totally lived up to the hype.

Here’s my full migration story, including upgrading Node.js, modernizing SCSS, updating TypeScript paths, and making Vite work with my existing setup.

🧐 Why I Switched

CRA served me well for years, but lately:

Slow dev server start — waiting 20–40s just to load the app.
Sluggish HMR — changes took seconds to reflect, breaking flow.
Longer builds, heavier output.

Vite, on the other hand:

Near-instant startup (native ES modules in dev)
Millisecond HMR
Simpler config & smaller builds

📦 Step 1 – Upgrade Node.js

Vite works best on modern Node versions.
I upgraded from Node 18 → Node 22:

nvm install 22
nvm use 22

This ensures maximum compatibility and speed.

🧹 Step 2 – Remove CRA (react-scripts)

CRA’s react-scripts is no longer needed. I uninstalled it:

npm uninstall react-scripts

And removed CRA-specific config files like serviceWorker.js if not used.

📂 Step 3 – Install and Configure Vite

npm install vite @vitejs/plugin-react --save-dev
npm install path --save

Then I created vite.config.js:

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import path from 'path';

export default defineConfig({
  plugins: [react()],
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
    },
  },
});

🖊 Step 4 – Update TypeScript Config

In tsconfig.json, I adjusted the paths to remove the "./" prefix, and made sure to include Vite’s type declarations:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    }
  },
  "include": ["src", "src/vite-env.d.ts"]
}

This ensures TypeScript recognizes the alias and Vite’s types.

🎨 Step 5 – Migrate SCSS (with Automation)

Vite supports SCSS out of the box, but I also updated some old Sass syntax to match the modern spec.

Instead of manually editing dozens of files, I used the Sass migrator:

npm install -g sass-migrator
sass-migrator module --migrate-deps src/**/*.scss

This automatically replaced deprecated @import with modern @use & @forward.

⚙️ Step 6 – Environment Variables

Vite requires env variables to be prefixed with VITE_.

Example change:

REACT_APP_API_URL → VITE_API_URL

And accessed in code via:

import.meta.env.VITE_API_URL

📜 Step 7 – Update Scripts in package.json

"scripts": {
  "dev": "vite",
  "build": "vite build",
  "preview": "vite preview"
}

🚀 Step 8 – Test & Deploy

Locally:

npm run dev

Blazing fast — <1s startup time. 🎉

Production:

npm run build

On Vercel, I just updated the build command to:

npm run build

and set the output directory to dist/.

📈 Results After Migration

Metric	CRA (Webpack)	Vite
Dev Start	28s	< 1s
HMR Update	2–3s	< 100ms
Prod Build	~50s	~12s
Bundle Size	~1.3MB	~900KB

💡 Tips

Upgrade Node.js before switching
Remove CRA packages completely
Add path alias in vite.config.js
Update tsconfig.json to include vite-env.d.ts
Automate SCSS migration instead of doing it manually
Check dependencies for ES module support

🎯 Final Thoughts

Migrating to Vite gave me an instant speed boost, cleaner config, and a more enjoyable dev experience.
If you’re tired of slow builds and outdated tooling, this upgrade is worth every minute.

🛡️ 7 Frontend Security Vulnerabilities You Should Know (And Fix)

Devam Chaudhari — Sun, 04 May 2025 09:03:14 +0000

Web security is often associated with backend protection, but frontend vulnerabilities can be equally dangerous. From Reflected XSS to Missing CSP headers, overlooking security at the client side can expose your application to a range of attacks.
In this article, we’ll explore 7 common frontend vulnerabilities — what they are, why they matter, and how you can secure your app against them.

1. 🚨 Reflected XSS (Cross-Site Scripting)

What is it?

Reflected XSS occurs when an attacker injects malicious scripts via the browser's URL (e.g., query parameters), which are then immediately reflected back by the web app without sanitization.

Frontend Example:

<!-- A vulnerable example -->
<p>Hello, <span id="name"></span>!</p>
<script>
  const name = new URLSearchParams(window.location.search).get("name");
  document.getElementById("name").innerHTML = name;
</script>

Exploit URL:

https://yourdomain.com?name=<script>alert('XSS')</script>

How to fix it:

Always sanitize or escape user input before rendering.
Use textContent instead of innerHTML when inserting text.

document.getElementById("name").textContent = name;

2. 🛑 Missing HSTS Header

What is it?

HSTS (HTTP Strict Transport Security) forces browsers to interact with the site over HTTPS only.

Why it matters?

Without it, attackers could intercept or downgrade requests from HTTPS to HTTP.

How to fix it (on server):

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Note: While this is a server-side header, frontend developers must be aware during deployment and review that HSTS is enforced, especially for SPAs hosted on CDNs or static hosting platforms.

3. 📝 Log Forging

What is it?

When user input is logged directly without sanitization, attackers can inject line breaks or misleading content into logs (e.g., support tickets, error tracking).

Example:

console.log("User input: " + userInput);

Attack input:

\n[ERROR] Something went wrong

Resulting log:

User input:
[ERROR] Something went wrong

How to fix it:

Encode or sanitize line-breaking characters like \n, \r, or delimiters before logging.

4. 🔁 Client DOM-Based Open Redirect

What is it?

If your frontend redirects users based on a query string or fragment without validation, attackers can trick users into visiting malicious sites.

Example:

const redirectTo = new URLSearchParams(window.location.search).get("next");
window.location.href = redirectTo;

Exploit:

https://yourapp.com?next=https://malicious-site.com

How to fix it:

Allow only known, whitelisted URLs.
Use relative paths, not full URLs from query strings.

const allowedRoutes = ["/dashboard", "/profile"];
if (allowedRoutes.includes(redirectTo)) {
  window.location.href = redirectTo;
}

5. 🖼️ Use of Without sandbox

What is it?

Using iframes without sandboxing can give embedded content more power than it should have (e.g., running JS, submitting forms, top-level navigation).

Example (vulnerable):

<iframe src="https://third-party.com/form.html"></iframe>

Better:

<iframe src="https://third-party.com/form.html" sandbox></iframe>

Best practice:

Use a strict sandbox attribute with only required permissions:

<iframe src="..." sandbox="allow-scripts allow-forms"></iframe>

6. 📦 JSON Hijacking

What is it?

An older but still relevant attact where sensitive JSON data ( like user info) is exposed via GET request, allowing attacker to "hijack" it via <script> tags.

How?

If your API returns user JSON data on GET requests like:

fetch("/user-info")

An attacker can include:

<script src="https://yourdomain.com/user-info"></script>

Fixes:

Use proper Content-Type: application/json.
Require authenticated POST requests for sensitive data.
Add anti-CSRF measures.

7. 🔐 Missing CSP (Content Security Policy)

What is it?

CSP is a browser feature that helps prevent XSS by declaring what content is allowed to load or execute.

Why it matters?

Without it, attackers can inject inline scripts or load malicious scripts.

Example CSP header:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';

Frontend impact:

Avoid inline and <style> tags.</li> <li>Use hashes or nonces if inline scripts are necessary.</li> </ul>