Bitcoin gets called a lot of things: digital gold, internet money, a scam, a revolution. This guide skips all of that. It is not about what Bitcoin is _for_. It is about what Bitcoin _is_: the parts, how they fit, and why they work.

We are going to build the idea up in layers, because that is genuinely how Bitcoin is put together. Each layer sits on top of the one below it. If you skip a layer, the ones above look like magic. If you take them in order, the magic turns into something more satisfying: plain engineering.

!btc-diagram-foundation-infra

A quick note on numbers. The _rules_ in this guide (how often blocks appear, the coin limit, how a block is structured) are fixed by the software and do not change. The _live figures_ (how much computing power is on the network, how busy it is, the price) change all the time. Where I mention one of those, treat it as "roughly true in mid-2026" and check a live site for today's value.

What we are actually looking at

Here is the one-sentence version of the whole thing:

> Bitcoin is a way for a huge group of strangers, who do not trust each other and have no boss, to agree on a single shared list of who owns what.

That is harder than it sounds. Normally, when a group needs to agree on something, someone is in charge. A bank keeps the official record of your balance. A referee makes the call. Bitcoin has no one in charge, and some of the people taking part may be actively trying to cheat. Somehow it still ends up with one agreed answer.

By the end of this guide you should be able to explain, in your own words, why a coin cannot be spent twice, why sending Bitcoin costs a fee, why the mining difficulty keeps adjusting up and down, why "running a node" and "mining" are two completely different jobs, and what actually happens in the roughly ten minutes between tapping send and the payment becoming permanent.

The one problem Bitcoin was built to solve

Everything starts here, so it is worth slowing down.

The problem is called double spending, and it only exists for digital money.

Think about a physical $20 bill. When you hand it to a shop, you no longer have it. The object moved from your hand to theirs. You physically cannot be in two shops spending the same bill at the same time.

Now think about anything digital: a photo, a song, a file. Copying it is free and perfect. You can send the exact same photo to a thousand people at once, and each copy is flawless. That is great for photos. It is a disaster for money. If a "coin" were just a file, you could send the same coin to a thousand different people, and each one would see a perfectly real coin. Only later would everyone realise they were all paid with the same money.

The usual fix is to put someone in charge. A bank keeps one official list. When you pay, the bank subtracts from your row and adds to someone else's row. Because there is only one list, controlled by one company, the same dollar cannot be in two places. This works, and most of the world runs on it. But it comes with a cost. You have to trust that company. It can freeze you, reverse payments, get hacked, go under, or simply charge you for the service.

So the question that led to Bitcoin was very specific:

> Can you keep one official list of who owns what, without anyone being in charge of the list?

Two pieces of math hold up everything else

Almost every surprising thing about Bitcoin comes from one of two tools. Neither was invented for Bitcoin. Both are decades old and used all over the internet.

Tool 1: the fingerprint machine (a hash)

A hash function is like a machine that takes anything you feed it (a word, a file, an entire book) and spits out a short jumble of characters. Bitcoin uses one called SHA-256, whose output is always 64 characters long. Feed in a single letter or the complete works of Shakespeare, and you still get exactly 64 characters back. People often call this output a fingerprint, and that is the word I will use.

Three things make it special, and the whole security of Bitcoin leans on them:

1. Same input, same fingerprint, every time. Anyone, anywhere, feeding in the same thing gets the same result. No coordination needed.
2. Change the input a tiny bit, and the fingerprint changes completely. There is no "close." Change one letter and about half the output flips, with no pattern connecting the two.
3. You cannot run it backwards. Given a fingerprint, there is no way to figure out what was fed in, other than guessing. And there are so many possible fingerprints that guessing is hopeless. (For scale: the number of possible outputs is far larger than the number of atoms on Earth.)

Point 2 is the one people underestimate, so here it is made concrete. Type a word below, and the second row will show the same word with a single letter changed. The characters that differ are highlighted:

This matters a lot later. Because there is no "getting warmer," you cannot be clever and steer a fingerprint toward a shape you want. Your only option is to try, check, and try again. Remember that.

A good way to build intuition is to feel it yourself. Use the playground below, type something, and change one letter at a time:

One more detail for the curious: Bitcoin usually runs this machine _twice_ in a row, taking the fingerprint of the fingerprint. You do not need to remember why. Just know that when you hear "the block's ID" or "the transaction ID," that is one of these fingerprints.

Tool 2: a lock only you can close, that anyone can check

The second tool answers a different question: how do you prove you are allowed to spend a coin, without giving away a secret that would let anyone else spend it too?

The answer is a matched pair of keys:

- A private key, which is basically a giant secret random number that only you know.
- A public key, which is calculated from the private key and which you can share freely.

Like the fingerprint machine, this only runs one way. It is easy to make the public key from the private key, and effectively impossible to go backwards.

With this pair you can do two things:

- Sign. Using your private key, you can stamp a specific message (a payment) with a unique signature. The signature only works for that key and that exact message.
- Verify. Anyone with your public key can check that the signature is real, which proves _you_ made it, without ever seeing your private key.

A helpful picture: think of a special wax seal that only your ring can press, but that anyone in the world can recognise on sight. You never hand over the ring. You just stamp things, and everyone can confirm the stamp is yours.

This is the entire idea of owning Bitcoin. A coin is not sitting "inside" a wallet like a file in a folder. To own Bitcoin simply means you know a private key that can produce a valid signature to move that coin. Lose the key and the coins are stuck forever. There is no support line and no reset button. That is what people mean by the phrase "not your keys, not your coins."

From a secret number to an address

You have probably seen a Bitcoin address, one of those long strings starting with bc1. Here is where it comes from, and it is just the two tools from the previous section (the fingerprint machine and the key pair) chained together.

The path runs in one direction only: private key to public key to address.

Each step is easy to walk forwards and practically impossible to walk backwards. You make the public key from the private key using the key math. Then you make the address by taking the fingerprint of the public key.

Because of that one-way street, two everyday facts fall out:

- Sharing your address is safe. It is downstream of everything secret, so it gives nothing away. People can send you money, and that is all.
- Sharing your private key is a catastrophe. It is the thing at the very start of the chain. Anyone who has it can sign, which means they can spend everything.

You may notice addresses start with different prefixes. A quick key:

- 1... is P2PKH (legacy), the original address style.
- 3... is P2SH, often used for shared or multi-key setups.
- bc1q... is native SegWit v0 (Bech32), cheaper and more efficient, from the 2017 SegWit upgrade.
- bc1p... is Taproot / SegWit v1 (Bech32m), the newest style, from the 2021 Taproot upgrade.

They all do the same basic job: they are a safe-to-share destination for money. As a quick rule of thumb, Taproot addresses commonly start with bc1p, and the older native SegWit addresses start with bc1q.

Blocks, and why they form a chain

Now we can build the record itself.

A block is simply a batch of transactions bundled together, plus a small label on top called the header. Think of a block as one page in a shared notebook. The page has a body (the list of payments) and a heading (the summary info). New pages are added roughly every ten minutes, and each page can hold a few thousand payments.

The header is small but it is where the clever part lives. Tap any field below to see what it does:

The single most important field is the previous block's fingerprint. Every block's header contains the fingerprint of the block right before it. That one detail is what turns a pile of separate pages into a connected chain.

!btc-diagram-fingerprint-blocks

Here is why that chain is so powerful. Imagine a cheater wants to secretly change a payment in an old block. The moment they change anything in that old block, its fingerprint changes (that is the fingerprint machine from earlier). But the _next_ block was carrying the _old_ fingerprint. So now the next block does not match, and its own fingerprint would need to change too, which breaks the block after that, and so on all the way to the present.

In other words, you cannot quietly edit page 400 of the notebook. Editing it visibly wrecks every page after it. To make the change stick, the cheater would have to redo every single page from 400 to now, faster than the rest of the world is adding new pages. The section on proof of work explains why that is effectively impossible.

Merkle trees: summing up thousands of payments with one fingerprint

You may have spotted a field in the header called the Merkle root. It sounds fancy. The idea is simple and genuinely elegant.

A block might hold thousands of transactions. The header does not want to store all of them, but it does want a way to lock them in so none can be swapped out later. The trick is to squash all of them down into a single fingerprint, built like a knockout tournament.

Pair up the transactions and take a fingerprint of each pair. Then pair up _those_ fingerprints and hash them. Keep going until only one fingerprint is left standing. That final winner is the Merkle root, and it goes in the header.

!btc-diagram-merkle-root

Two nice things come out of this:

- Nothing can be swapped. Change any single payment and its fingerprint changes, which changes its pair, which changes the root, which changes the whole block. The root locks everything in.
- You can prove one payment is in a block without downloading the whole block. This is how a phone wallet can confirm your payment landed without storing the entire history of Bitcoin. It only needs a short trail of fingerprints up the tree, not the thousands of other payments.

Coins are not a balance, they are more like cash

This is the part that trips up almost everyone, because it works differently from a bank.

Your bank account has a single number: your balance. When you spend, the number goes down. Bitcoin does not work that way. Bitcoin is more like a wallet full of actual bills and coins of odd sizes.

In Bitcoin, when you receive money, you receive it as a distinct chunk, like being handed a specific bill. The proper name for one of these unspent chunks is an unspent transaction output, usually shortened to UTXO. You do not need the jargon. Just picture bills of random sizes sitting in your wallet.

Now, here is the cash-like rule: you cannot spend part of a bill. Pick which coins to spend below and drag the payment amount around to see what comes back as change:

The tiny bit that does not come back as change is the fee, which the miner who includes your payment gets to keep. There is more on fees in the section on the waiting room below.

Two everyday consequences of this design:

- Your "balance" is not stored anywhere. Your wallet app just scans the record, finds every chunk that belongs to your keys, and adds them up to show you a number. Nobody wrote that number down.
- Privacy is fiddly. Because change comes back as a new chunk, following the trail of chunks is how blockchain analysts try to trace activity.

Two different jobs: nodes and miners

People mix these up constantly. They are separate roles, and most participants only do one of them.

Nodes are the referees. A node is a computer running the Bitcoin software that keeps a full copy of the record and checks every single rule. Is this signature valid? Does this person actually own the coins they are trying to spend? Is this block properly formed? If anything breaks a rule, the node rejects it and refuses to pass it on. There are tens of thousands of these referees around the world, and crucially, _anyone can run one on ordinary hardware._ This is the real backbone of Bitcoin. The rules are enforced by thousands of independent copies, not by any authority.

Miners are the record keepers who compete for the right to add the next page. Their job is to bundle waiting transactions into a new block and win the right to add it. This takes serious specialised equipment and a lot of electricity. The next section is all about what they are actually doing.

The key thing to take away: miners propose, nodes decide. A miner can build any block it likes, but if that block breaks the rules, every honest node simply throws it away and the miner wasted its effort for nothing. Power in Bitcoin is split on purpose.

Proof of work: the guessing game you cannot cheat

This is the heart of Bitcoin, and thanks to the two tools from earlier it is now easy to explain.

To add the next block, a miner has to win a guessing game. Remember the header has a field called the nonce, which is just a number the miner is free to change. The game is this: find a nonce so that when you take the fingerprint of the whole header, the result is small enough.

To be precise: a fingerprint is really just a very large number written in hex. The header also carries a target value (packed into a small field called nBits). A block only counts as valid if its fingerprint, read as a number, comes out below that target. The lower the target, the fewer fingerprints qualify, and the harder the puzzle. The easy way to picture "below the target" is "the fingerprint has to start with a certain number of zeros," and that is the mental model I will use, but keep in mind the real rule is the numeric comparison against the target.

That is it. Because of the fingerprint machine's "no getting warmer" rule from earlier, there is no smart way to find such a nonce. You cannot calculate it. You cannot nudge the number in the right direction. You can only try a nonce, take the fingerprint, check if it has enough leading zeros, and if not, add one and try again. Over and over, billions of times per second.

You can feel exactly how this works with the demo below. Type a message, choose how many leading zeros you want, and hit start. Your browser will do the same dumb loop a real miner does, just far slower. Add one more required zero and watch the work roughly multiply:

Now, why is this pointless-looking effort actually useful? Because of a beautiful lopsidedness:

- Very hard to do, instant to check. Finding a winning nonce takes the entire network huge effort. But _checking_ someone else's winning block takes any referee a split second: take the fingerprint once, count the zeros, done. Making the proof is expensive. Verifying the proof is free.
- Lying costs real money. A winning block represents real electricity that got burned. To rewrite an old block, a cheater would have to burn all that electricity again, plus redo every block since, plus keep outrunning the entire rest of the world adding new blocks in real time, forever. It is not that cheating is banned. It is that cheating is wildly more expensive than playing fair.

That last point is the whole security model in one line: behaving honestly pays better than attacking.

Why almost nobody mines alone

Winning a block is a lottery. If you mine by yourself, you might go months or years without ever winning, then win once, then nothing again. That wild unpredictability is unbearable for most operators trying to pay an electricity bill.

So miners team up into pools. A pool has thousands of miners all working on the same block and splitting any reward in proportion to how much work each one did. This turns a wild lottery into a steady, paycheck-like income. The downside is that it concentrates a lot of decision-making into a handful of large pools, which is one of the genuine worries about Bitcoin today.

Keeping blocks ten minutes apart, forever

Bitcoin aims for a new block roughly every ten minutes. But the amount of computing power aimed at the network is always changing. More miners join, better machines arrive, prices swing and some switch off. So how does the gap stay near ten minutes?

The network retunes the difficulty automatically. Every 2,016 blocks (which at ten minutes each works out to about two weeks), every node does the same simple check: did the last stretch of blocks arrive faster or slower than the ten-minute target? The difficulty then adjusts up or down accordingly. If the last period was mined too fast, the puzzle gets harder (the target drops, so more leading zeros are needed). If it was too slow, the puzzle gets easier. It can and regularly does move in both directions.

A good mental image is a treadmill that speeds up as more runners jump on, so that a runner still crosses the line about every ten minutes no matter how many are racing. This is why you cannot make Bitcoin produce coins faster by throwing more machines at it. Add more power and the puzzle simply gets harder to match.

Every node calculates this adjustment independently and arrives at the same answer, because they all follow the same rule on the same shared record. No committee, no announcement. Just math everyone runs.

New coins, the halving, and the 21 million limit

So where do new coins come from, and who gets them?

Whoever wins a block gets to include one special payment at the top that creates brand new coins out of nothing and pays them to the winner. This is the reward, and it is the incentive that makes people spend money on mining in the first place. The winner also collects all the fees from the transactions in that block.

Here is the famous twist. That reward cuts in half every four years (more precisely, every 210,000 blocks). It started at 50 coins per block in 2009. It dropped to 25, then 12.5, then 6.25, and in 2024 to 3.125. This is called the halving.

Because the reward keeps halving, the total number of coins that can ever exist adds up to a fixed ceiling: 21 million, and not one more. New coins trickle out more and more slowly until, sometime around the year 2140, the reward rounds down to zero and no new coins are ever made again.

This fixed limit is a large part of why supporters compare Bitcoin to gold. There is a hard cap, and no one can vote to print more. As of mid-2026, roughly 20.06 million of the 21 million already exist. (That figure keeps ticking up slowly, so treat it as a snapshot and check a live source for today's exact number. The 21 million cap itself never moves.)

There is an obvious question hiding here: if the reward eventually falls to zero, why would anyone keep mining? The intended answer is fees. As the new-coin reward shrinks, transaction fees are meant to become the main thing miners earn. Whether fees alone will be enough to keep the network secure that far out is a real and openly debated question. Nobody knows for certain.

The waiting room and why fees exist

When you send Bitcoin, it does not go straight into a block. First it waits in the mempool as an unconfirmed transaction until a miner picks it up. It is tempting to picture one single worldwide queue, but that is not quite how it works. Each node keeps its _own_ local pool of the valid, unconfirmed transactions it has heard about. These local pools overlap heavily, so they look similar, but there is no one official global waiting room. Think of it as many nearly-identical waiting rooms rather than a single one.

Here is the catch: a block only has room for so many transactions. When more people want in than there is space, miners have to choose. And they choose the way you would expect anyone paid by tips to choose: they prefer the payments offering the highest fee for the space they take up.

Think of a miner as a taxi with limited room and a line of passengers, each waving a different tip. The driver naturally picks whoever pays the most per seat. If you attach a generous fee, you get into the next block. If you attach a stingy fee during a busy period, you wait, sometimes a long time.

One important detail: the fee is not based on how much money you are sending. It is based on how much _space_ your transaction takes up in a block. That space is measured in virtual bytes (also called weight), a size measure introduced by the 2017 SegWit upgrade. What miners actually rank by is the fee rate: the fee divided by that virtual size. So a payment moving a fortune can be cheap if it is small and simple, and a payment moving pocket change can be expensive if it is large and complicated. You are paying for room on the page, not for the value being moved.

Two features exist to help when you guess the fee wrong:

- Bumping the fee lets you resend a stuck transaction with a higher fee to jump the line.
- Child pays for parent lets a follow-up transaction attach a big fee to drag a stuck earlier one along with it, since a miner has to include the earlier one to collect the juicy later fee.

What happens when two miners win at once

Sometimes two miners find a valid block at nearly the same moment, in different parts of the world. For a short while, the network disagrees. Part of it heard about block A, part of it heard about block B. This is called a fork, and it is normal and expected, not a crisis.

The tie does not last. Miners keep working, and soon someone builds the _next_ block on top of one of the two. Say the next block lands on top of A. Now the "A" side of the record is longer, and the rule everyone follows is simple: the version with the most work built on it wins. Everyone switches to the longer branch. Block B, the loser, is abandoned, and its transactions (which are almost always also in A) go back into the waiting room to be included normally.

!btc-diagram-blocks

This is exactly why people say to wait for a few confirmations on a big payment. One confirmation means your payment made it into a block. Each additional block stacked on top makes it exponentially harder to ever reverse, because a cheater would have to redo that block and all the ones after it faster than the whole network. For large amounts, waiting for about six blocks (roughly an hour) is the traditional comfort zone.

The "51 percent attack," in plain terms

You may have heard that if someone controlled a majority of the network's mining power, they could attack Bitcoin. That is true, but it is worth being precise about what they could and could not do.

Could do: with the majority of power, an attacker could out-build the honest network and rewrite _recent_ history, which would let them undo one of their own recent payments and effectively spend the same coins twice.

Could not do, even with all that power: steal coins from an address they do not have the key for (they still cannot forge a signature), create coins out of thin air beyond the rules, or change the rules everyone else's nodes enforce. The referees would simply reject anything invalid.

So even the scariest attack is limited, expensive, and easy to notice. It cannot quietly drain your wallet.

Upgrading a system with no boss

If nobody is in charge, how does Bitcoin ever get updated? Carefully, and with the agreement of the people running nodes. There are two flavours of change:

- A soft fork tightens the rules in a way that older software still accepts. It is backwards compatible, so it can roll out smoothly. The 2017 upgrade known as SegWit and the 2021 upgrade known as Taproot were both soft forks. They made transactions more efficient and more private without forcing everyone to upgrade on the same day.
- A hard fork changes the rules in a way older software will _reject_. If some people upgrade and some do not, the network can split permanently into two separate coins. This is a much bigger deal and much rarer, because it needs near-universal agreement to avoid a messy divorce.

The short version: Bitcoin can improve, but only by broad agreement, and it strongly prefers changes that do not break anyone who has not upgraded yet.

Going faster: layers on top

Every payment we have described so far gets written into the shared record, checked by every referee on Earth. That is wonderfully secure, but it is not built for buying a coffee. It is a bit like asking the whole world to witness and file paperwork for a $3 purchase.

The common solution is to add a faster layer on top, the best known being the Lightning Network. The idea in plain terms: two people (or a chain of people) open a private tab between them, make as many instant, nearly free payments back and forth as they like, and only write to the main record twice, once to open the tab and once to close it and settle the final total.

It is the same instinct as running a bar tab instead of paying the bank for every single sip. The slow, heavily witnessed main chain becomes the final settlement layer, and the fast layer on top handles the everyday small stuff.

The machines and the electricity question

Early on, people mined Bitcoin on ordinary computers. That did not last. Because mining is just the same fingerprint calculation repeated as fast as possible, hardware makers built chips that do _only_ that one calculation and nothing else, insanely fast. These are called ASICs, and today serious mining happens in warehouses full of them.

This is where the well-known energy debate comes from, and it is worth stating both sides fairly rather than picking one:

- The concern: all that guessing burns a genuinely large amount of electricity for a task that, from the outside, produces no physical product. Critics argue that is wasteful and adds to carbon emissions.
- The response: supporters argue the electricity is the _point_, since that real cost is exactly what makes cheating too expensive. They also point out that miners chase the cheapest power, which is often surplus, stranded, or renewable energy that would otherwise go unused, and that plenty of other industries use comparable amounts of energy with less scrutiny.

Both sides have real arguments. Where you land tends to depend on how much value you think a boss-free, tamper-resistant global record actually provides. This guide is not going to settle that for you, and honest people disagree.

A few myths worth clearing up

- "Bitcoin is anonymous." Not really. Every payment is public and permanent. Names are not attached directly, but the trail of coins can often be followed and linked to real identities. It is more like writing in a public ledger under a pen name than being invisible.
- "A bitcoin is a coin sitting in a file somewhere." No. There is no coin object. There is only the record of which keys control which chunks of value. Owning Bitcoin means holding a key that can sign.
- "You have to buy a whole bitcoin." No. Each coin divides into 100 million tiny units, so you can own and send a very small slice.
- "Miners approve or reject your payment based on who you are." No. Miners mostly just take the highest fees. The rules are enforced by the referee nodes, not decided by miners' opinions of you.
- "If the price crashes, the coins vanish." No. Price is what people will pay. The record of who owns what does not care about the price and keeps working exactly the same either way.

The whole life of a payment, start to finish

Let us tie every layer together by following one payment from the moment you tap send to the moment it is permanent.

!btc-diagram-pay-cycle

Look back at what each step used:

- Step 1 is the UTXO model (coins as cash): whole coins in, payment and change out.
- Step 2 is a digital signature: the wax seal only you can press.
- Steps 3 and 4 are the nodes doing their referee job.
- Step 5 is the mempool and fees: the waiting room and the tip.
- Steps 6 and 7 are proof of work: the guessing game.
- Step 8 is the chain and confirmations: each new block locks the ones below it.

That is the entire machine. Fingerprints at the bottom. Signatures for ownership. Transactions built from signatures. Blocks built from transactions. A chain built from blocks. Agreement built from work. And an economy built on top of all of it.

None of it needs a boss. It needs only a rule that everyone can check for themselves, and a game that makes honesty the cheapest option. That is the quiet, stubborn idea at the centre of Bitcoin.

Next in this series

We have covered _why_ mining works and _what_ the guessing game is. In the next post we will get our hands dirty and actually watch proof of work happen on a real machine, using a mining program called XMRig to make the loop visible and tangible.

Small but important heads-up for later: XMRig cannot mine Bitcoin. Bitcoin mining today needs those special ASIC chips from the hardware section above, not a regular computer's processor. XMRig mines a different, processor-friendly coin. We are using it purely as a clear, hands-on window into the same guess-and-check idea you met here. See you there.

_Reference figures (network size, coins mined) reflect roughly mid-2026 and drift over time. The protocol rules (ten-minute target, the halving schedule, the 21 million cap, the block layout) are fixed by the software. When in doubt about a live number, check a public block explorer._
]]> https://devarshi.dev/blog/how-the-bitcoin-network-actually-works https://devarshi.dev/blog/how-the-bitcoin-network-actually-works Sat, 25 Jul 2026 00:00:00 GMT devarshishimpi@gmail.com (Devarshi Shimpi) Technology Programming Development Introduction

If you run workloads on Kubernetes, you already know how easy it is for small mistakes to slip into production. A missing resource limit here, a container running as root there, and suddenly your cluster has problems nobody planned for. This is exactly the kind of thing policy as code was built to fix, and Kyverno is one of the easiest tools to start with.

Kyverno is a policy engine built specifically for Kubernetes. Instead of learning a new language to write rules, you write policies in plain YAML, the same format you already use for your deployments and services. That alone makes it a great starting point if you are new to Kubernetes security. Kyverno is also a CNCF Graduated project, which means it has passed a high bar for stability and community trust, and it is already used in production by companies like Spotify, LinkedIn, and Adidas.

In this post, we will walk through five Kyverno policies. We will start simple and end with something a bit more advanced, verifying container image signatures. Each one comes with a small demo so you can see exactly what happens when a policy blocks something. By the end, you will have a solid feel for how Kyverno works and a few policies you can actually use.

!how-kyverno-works-diagram

Before we get into the policies, here is a quick picture of how Kyverno fits into the request flow. Every time you or your CI pipeline sends something to Kubernetes, Kyverno gets a chance to check it first.

A quick note before we start. Kyverno recently introduced a newer, CEL based way of writing policies, and the classic format used below (ClusterPolicy) is now marked as deprecated in the official docs, though it is still fully supported and works today. It is still the easiest format to learn as a beginner, and this guide points you to the migration path at the end, once you are ready for it.

1. Require Resource Limits

One of the most common problems in a shared cluster is a single pod using up all the CPU or memory on a node. This is often called the "noisy neighbor" problem, and it can slow down or crash other workloads running nearby.

This policy makes sure every pod defines both requests and limits for CPU and memory before it is allowed to run. You can see the full syntax for this kind of rule in the Kyverno validate rules docs.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-requests-limits
spec:
  background: true
  rules:
    - name: validate-resources
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: "CPU and memory resource requests and limits are required."
        pattern:
          spec:
            containers:
              - resources:
                  requests:
                    memory: "?*"
                    cpu: "?*"
                  limits:
                    memory: "?*"
                    cpu: "?*"

Once this is applied, any pod that does not set these values will simply be rejected. It is a small rule, but it prevents a lot of headaches later.

Demo: what happens if you skip resource limits

Say you try to apply this pod, which has no requests or limits set.

apiVersion: v1
kind: Pod
metadata:
  name: no-limits-pod
spec:
  containers:
    - name: app
      image: nginx:1.27

kubectl apply -f no-limits-pod.yaml

Error from server: error when creating "no-limits-pod.yaml": admission webhook "validate.kyverno.svc-fail" denied the request:
resource Pod/default/no-limits-pod was blocked due to the following policies
require-requests-limits:
  validate-resources: 'CPU and memory resource requests and limits are required.
    Validation rule validate-resources failed at path /spec/containers/0/resources/'

Now add the missing fields and try again.

apiVersion: v1
kind: Pod
metadata:
  name: with-limits-pod
spec:
  containers:
    - name: app
      image: nginx:1.27
      resources:
        requests:
          memory: "128Mi"
          cpu: "100m"
        limits:
          memory: "256Mi"
          cpu: "250m"

kubectl apply -f with-limits-pod.yaml
pod/with-limits-pod created

That's it. The pod goes through as soon as it meets the policy.

2. Block the "latest" Image Tag

It is tempting to just use image: myapp:latest when you are getting started. The problem is that "latest" can point to a different image every time it is rebuilt. This makes deployments unpredictable and makes it very hard to know exactly what version of your app is actually running.

This policy blocks any pod that uses the "latest" tag, or no tag at all.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  background: true
  rules:
    - name: require-image-tag
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: "An image tag is required."
        pattern:
          spec:
            containers:
              - image: ":"
    - name: validate-image-tag
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: "Using a mutable image tag like 'latest' is not allowed."
        pattern:
          spec:
            containers:
              - image: "!*:latest"

This forces every team to use a proper version tag, which makes rollbacks and debugging much easier down the road. This exact example is adapted from the sample policy library that ships with the Kyverno project.

Demo: what happens if you use "latest"

apiVersion: v1
kind: Pod
metadata:
  name: latest-tag-pod
spec:
  containers:
    - name: app
      image: myapp:latest

kubectl apply -f latest-tag-pod.yaml

Error from server: error when creating "latest-tag-pod.yaml": admission webhook "validate.kyverno.svc-fail" denied the request:
resource Pod/default/latest-tag-pod was blocked due to the following policies
disallow-latest-tag:
  validate-image-tag: 'Using a mutable image tag like ''latest'' is not allowed.
    Validation rule validate-image-tag failed at path /spec/containers/0/image/'

Swap in a real version and the pod goes through without any trouble.

apiVersion: v1
kind: Pod
metadata:
  name: versioned-pod
spec:
  containers:
    - name: app
      image: myapp:1.4.2

kubectl apply -f versioned-pod.yaml
pod/versioned-pod created

3. Require Labels

Labels are how Kubernetes keeps things organized. They help you filter resources, connect them to monitoring tools, and figure out who owns what. Without labels, a growing cluster turns into a pile of unlabeled boxes nobody can identify.

This policy requires every pod to have a specific label before it can be created. If you want a refresher on what labels are for, the Kubernetes labels documentation is a good place to start.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-labels
spec:
  rules:
    - name: check-for-labels
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: "The label 'app.kubernetes.io/name' is required."
        pattern:
          metadata:
            labels:
              app.kubernetes.io/name: "?*"

You can add more required labels over time, like team name or environment, once this basic rule feels comfortable.

Demo: what happens if a label is missing

apiVersion: v1
kind: Pod
metadata:
  name: unlabeled-pod
spec:
  containers:
    - name: app
      image: myapp:1.4.2

kubectl apply -f unlabeled-pod.yaml

Error from server: error when creating "unlabeled-pod.yaml": admission webhook "validate.kyverno.svc-fail" denied the request:
resource Pod/default/unlabeled-pod was blocked due to the following policies
require-labels:
  check-for-labels: 'The label ''app.kubernetes.io/name'' is required.
    Validation rule check-for-labels failed at path /metadata/labels/'

Add the label and the same pod is accepted right away.

apiVersion: v1
kind: Pod
metadata:
  name: labeled-pod
  labels:
    app.kubernetes.io/name: myapp
spec:
  containers:
    - name: app
      image: myapp:1.4.2

kubectl apply -f labeled-pod.yaml
pod/labeled-pod created

4. Restrict Privileged Containers

A privileged container can do almost anything the host machine can do, including accessing other containers and system resources it should never touch. This is one of the biggest security risks in Kubernetes, and it is usually not something you want to allow unless there is a very specific reason for it.

This policy blocks any pod from running in privileged mode. It is also one of the checks covered by the Kubernetes Pod Security Standards, which Kyverno has its own dedicated guide for if you want to enforce the whole standard at once instead of writing individual rules.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-containers
spec:
  background: true
  rules:
    - name: privileged-containers
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        failureAction: Enforce
        message: "Privileged mode is not allowed."
        pattern:
          spec:
            containers:
              - =(securityContext):
                  =(privileged): "false"

This is one of the simplest changes you can make that meaningfully reduces your attack surface.

Demo: what happens if a pod asks for privileged mode

apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
spec:
  containers:
    - name: app
      image: myapp:1.4.2
      securityContext:
        privileged: true

kubectl apply -f privileged-pod.yaml

Error from server: error when creating "privileged-pod.yaml": admission webhook "validate.kyverno.svc-fail" denied the request:
resource Pod/default/privileged-pod was blocked due to the following policies
disallow-privileged-containers:
  privileged-containers: 'Privileged mode is not allowed.
    Validation rule privileged-containers failed at path /spec/containers/0/securityContext/privileged/'

Remove the privileged flag, and the pod is created normally.

apiVersion: v1
kind: Pod
metadata:
  name: safe-pod
spec:
  containers:
    - name: app
      image: myapp:1.4.2

kubectl apply -f safe-pod.yaml
pod/safe-pod created

5. Verify Container Image Signatures

This last one is a step up in complexity, but it is worth learning because it solves a real problem, how do you know the image running in your cluster is actually the one your team built, and not something tampered with along the way?

This is where image signing comes in. Tools like Cosign, part of the Sigstore project, let you cryptographically sign container images when you build them. Kyverno can then check that signature before allowing the image to run, and reject anything that is not signed or does not match. The full details of this feature are in the Kyverno Sigstore verification docs.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: check-image-signature
spec:
  background: false
  rules:
    - name: check-signature
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/yourorg/*"
          failureAction: Enforce
          attestors:
            - entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      
                      -----END PUBLIC KEY-----

This is the same idea behind supply chain security, which has become a major topic in the industry after several high profile attacks where malicious code got smuggled into trusted software. Signing and verifying images is one of the clearest ways to close that gap, and it is a great skill to have even if you are still early in your Kubernetes journey.

Demo: what happens with an unsigned image

First, you would sign your image once, when you build it.

cosign sign --key cosign.key ghcr.io/yourorg/myapp:1.4.2

Now if someone tries to deploy an image that was never signed, Kyverno stops it. Note that image verification is handled through Kyverno's mutating webhook, so the error will mention "mutate" rather than "validate" even though the outcome is a rejection.

apiVersion: v1
kind: Pod
metadata:
  name: unsigned-image-pod
spec:
  containers:
    - name: app
      image: ghcr.io/yourorg/myapp:1.0.0

kubectl apply -f unsigned-image-pod.yaml

Error from server: admission webhook "mutate.kyverno.svc" denied the request:
resource Pod/default/unsigned-image-pod was blocked due to the following policies
check-image-signature:
  check-signature: 'image verification failed for ghcr.io/yourorg/myapp:1.0.0:
    signature not found'

Deploy the signed version instead, and it goes through.

apiVersion: v1
kind: Pod
metadata:
  name: signed-image-pod
spec:
  containers:
    - name: app
      image: ghcr.io/yourorg/myapp:1.4.2

kubectl apply -f signed-image-pod.yaml
pod/signed-image-pod created

Conclusion

None of these policies are complicated on their own, but together they cover a lot of ground: resource limits, image tagging, labeling, privilege restrictions, and image signing. If you are new to Kyverno, a good approach is to start with the first two policies, get comfortable applying them with kubectl apply -f policy.yaml, watch how Kyverno reports violations, and then work your way down the list. You can try all of this without a real cluster using the Kyverno Playground.

Kyverno is actively evolving too. As of version 1.18, the ClusterPolicy style shown in this guide is marked deprecated in the docs in favor of newer CEL based policy types like ValidatingPolicy. It still works fully today and remains the easiest format for a beginner to learn, but once you are comfortable, it is worth reading the guide to migrating to CEL policies to see where the project is headed.

If you want to go further, the official Kyverno documentation has a large library of sample policies you can copy and adapt for your own cluster, and the Kyverno GitHub repository is where the project itself lives if you want to see what is being worked on next.

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

- Profile
- Linkedin
- Twitter
- Youtube

Read more

- React (RSC) Exploits Are Real and It's Hurting Engineering Teams
- Managing Dependencies and Security in JavaScript with NPM
- Deploy MinIO on Amazon EKS: Self-Host S3 Storage
]]> https://devarshi.dev/blog/five-kyverno-policies-to-secure-kubernetes-cluster https://devarshi.dev/blog/five-kyverno-policies-to-secure-kubernetes-cluster Tue, 07 Jul 2026 00:00:00 GMT devarshishimpi@gmail.com (Devarshi Shimpi) Technology Programming Development I wanted AI code review I could actually own.

Not access through a subscription or a black-box service with its own limits. The deployment, credentials, providers, and usage under my control.

I kept hitting usage limits mid-week during deep building sessions. The models were capable. The workflow was useful. But access still depended on somebody else's weekly allowance, and centralized platforms can change whenever the company behind them decides to. Pricing, quotas, models, plan boundaries.

A workflow that fits this month may sit behind another subscription next month. I could not find a reliable open-source option that gave me the ownership model I wanted. So I built one.

!codra-ai-code-review-dashboard

That became Codra: A self-hosted AI review engine built around bring-your-own models, your own data boundary, and no Codra-imposed usage ceiling.

What Codra Is

Codra is an open-source, self-hosted AI code review engine for GitHub pull requests.

It listens to pull request events, reviews changed files, posts inline findings, and provides a dashboard for jobs, repositories, model routing, history, usage, and failures.

!codra-github-inline-pr-comment

It runs on Cloudflare Workers and uses:

- Cloudflare Queues for review jobs
- PostgreSQL through Hyperdrive for storage
- KV for sessions and cache
- A React dashboard for operations

The GitHub App, model credentials, database, and review history are yours. Provider keys are encrypted with AES-GCM using your deployment secret.

Bring Your Own Model, Bring Your Own Limits

Changing providers does not require replacing your review history, configuration, or workflow.

You configure the provider and model. Supported:

- OpenAI-compatible APIs
- OpenRouter
- Anthropic
- Google / Gemini
- Cloudflare Workers AI

Why Self-Hosted Matters Here

A large frontend repo and a tiny backend repo should not need the same review strategy.

Each repository gets its own review settings. You tune triggers, skip generated files, ignore drafts, use mention-triggered reviews, configure labels, set file limits, and define custom rules.

What Codra Actually Does

Codra is not just a prompt wrapped around a diff.

It includes the pieces needed to operate AI review as a system:

- Automatic and mention-triggered reviews
- Inline comments, summaries, and check runs
- Per-repository rules and skipped paths
- Provider fallbacks and size-based model routing
- Queue-backed, chunked processing with retries
- Dead letter queue recovery
- Job history, usage, repository, and model dashboards

The boring pieces are the point.

!codra-dashboard-job-issues

Production software is mostly unhappy paths: provider outages, malformed output, large diffs, stale jobs, superseded reviews, and failed queue runs.

Codra exists because those details matter.

Open Source Is Part of the Product

Codra is AGPL-licensed because "own your AI review loop" only means something when the system is inspectable.

Developers can inspect how jobs, diffs, prompts, fallbacks, comments, failures, and repository settings work. AI code review is still early, and those questions are better answered in the open:

AI code review is still early. There are open questions everywhere:

- Which models work best for different kinds of PRs?
- How strict should automated review be?
- How should local models and repository context fit in?
- How do we reduce noise without missing real bugs?

Those questions are better answered in the open.

Codra should improve through real codebases and community contributions to prompts, providers, docs, tests, and defaults.

What Comes Next

Still in beta, but the foundation is there. The next phase has three tracks.

The next phase has three main tracks.

Deployment Targets

Cloudflare Workers stays the primary target. These paths are for teams and
individuals who want to run Codra on infrastructure they already control.

!discord-other-hosting-support-cloudflare-issue

- Vercel Functions adapter and other serverless runtime support
- Conventional server deployment via Node.js and PM2 for EC2 or any VM
- A Docker-first deployment path for platforms like Hetzner, DigitalOcean, and Coolify

Stability and Developer Experience

The review pipeline works. The focus now is making it hold up under real-world load
and easier to get running without friction.

- A more robust pipeline that handles large PRs reliably
- Cleaner installation, configuration, and debugging flows for first-time deployers
- Community-driven defaults and real-world review config examples

Provider and Model Support

Inference should not be locked to hosted APIs. Local and self-hosted models will
become a first-class option alongside the existing provider list.

- Improved support across existing providers
- Routes for local and self-hosted models, Ollama, LM Studio, and similar
- More language-aware review behavior per file type

Own the Review Loop

Providers, pricing, and quotas will keep changing. Your review engine should not have to change with them.

!codra-cta-banner

Codra is open source on GitHub. Try it, star it, break it, file issues, and help shape where it goes next.

Docs: https://codra.run/docs

Read more

- I Wanted AI Code Review I Could Actually Own. So I Built Codra.
- Self-Hosting Your Own Cloud Storage on AWS using NextCloud
- How to create a new Next.js project with Cloudflare Pages and Workers
]]> https://devarshi.dev/blog/codra-self-hosted-ai-code-review https://devarshi.dev/blog/codra-self-hosted-ai-code-review Wed, 24 Jun 2026 00:00:00 GMT devarshishimpi@gmail.com (Devarshi Shimpi) Technology Programming Development I thought this was just an hour of work. It wasn't. Here's everything that went wrong and what actually worked in the end.

Starting with the obvious choice

window.SpeechRecognition is built into Chrome. No API keys, no server, completely free. It felt like the perfect starting point for adding voice search to my extension.
After a day of testing, I dropped it.
The mic permission popup was all over the place. Sometimes it would show up randomly mid-session. Sometimes it would just stop listening with no error, no warning, nothing. Results were different depending on the machine and OS. For a new tab extension that's meant to feel polished, that just wasn't good enough.
I switched to Deepgram's Nova-3 model. It's fast, accurate, and sends results back in real time over WebSocket, so you don't have to wait for a full sentence before seeing any output.
But now I needed a server, which kicked off a whole chain of problems.

!old-flow-browser-rec

Why you can't call Deepgram directly from the extension

Chrome extensions are easy to unpack and read. Any secret you put in the code is basically public. So keeping a Deepgram API key in the client was never going to work.
I needed a server in the middle. My first thought was Railway. I've used it before and getting a Node server running there takes maybe five minutes. But I second guessed that pretty quickly. A server on Railway means it has to start up cold sometimes, it costs money every month, and the speed depends on where the server is located. Cloudflare Workers runs closer to the user since it runs at the edge, and the free plan is generous enough that a voice search API would run for free forever. Easy choice.
The setup I had in mind: the extension sends raw audio to the Worker, the Worker passes it to Deepgram, and the text comes back the same way.

Simple enough on paper. Actually building it was another story.

Hono looked like the right tool. It wasn't.

I use Hono for pretty much everything on Cloudflare Workers. Clean, fast, easy routing. So I reached for it without thinking twice.
Set up a /transcribe route, handled the WebSocket upgrade, deployed it. The Worker just froze. No error from my code, just Cloudflare eventually killing the request with a 500 and a message saying the Worker "would never generate a response."
Took me a while to figure out what was going on. Cloudflare needs a special webSocket property on the Response object to finish a WebSocket connection. That's how it knows which socket to hand back to the client.
Hono wraps the built-in Response to add its own features. Somewhere in that process, the webSocket property gets lost. Cloudflare gets a response with no socket, doesn't know what to do, and kills the request.
The fix was to skip Hono for this route and just write it raw:

export default {
  async fetch(request, env) {
    if (url.pathname === "/transcribe") {
      const pair = new WebSocketPair();
      const [client, server] = pair;
      server.accept();
      return new Response(null, { status: 101, webSocket: client });
    }
  },
};

101 Switching Protocols. Finally.

The timing bug I should've seen coming

Audio was flowing but the Worker kept logging Deepgram not ready. Pretty obvious in hindsight.
The moment the client gets a 101 back, it starts sending audio right away. But the Worker had only just started its own connection to Deepgram. That connection wasn't open yet. So audio was showing up before Deepgram was ready to take it.
My first fix was to wait for the Deepgram connection to open before sending the 101 back:

await new Promise((resolve) => {
  deepgramSocket.onopen = resolve;
});
return new Response(null, { status: 101, webSocket: client });

This worked. But it quietly created a new problem I didn't notice until later.

Cloudflare's 10ms CPU limit is real

The free plan on Cloudflare Workers gives you 10ms of CPU time per request. Not total time, just active processing time. Waiting on a network call doesn't count, so in theory waiting for Deepgram to connect should be fine.
In practice, keeping the request open through the whole connection process added enough overhead that CPU usage was sitting at 40 to 90ms. Cloudflare was going to start dropping requests.

!cf-workers-cpu-spike

The fix was to stop waiting. Return the 101 right away, let Deepgram connect in the background, and just hold any audio that comes in too early:

let deepgramReady = false;
const pendingChunks = [];
deepgramSocket.addEventListener("open", () => {
  deepgramReady = true;
  for (const chunk of pendingChunks) deepgramSocket.send(chunk);
  pendingChunks.length = 0;
});
server.addEventListener("message", (event) => {
  if (!deepgramReady) {
    pendingChunks.push(event.data);
  } else {
    deepgramSocket.send(event.data);
  }
});
return new Response(null, { status: 101, webSocket: client });

CPU usage dropped to around 2ms. Deepgram still connects, it just doesn't hold everything else up while it does.

AudioWorklet and Manifest V3 don't work together

This was the most painful part of the whole thing.
MV3 extensions only let you run scripts that are part of your own extension package. No inline scripts, no scripts from other websites, nothing generated at runtime. AudioWorkletNode is the standard modern way to process audio in a background thread, and it needs you to load a separate file using addModule(url). You can already see where this is going.

First try was using Vite's ?url import:

import processorUrl from "./processor.js?url";
// Output: data:text/javascript;base64,...

Blocked. Makes sense, data URIs aren't allowed.
Second try was putting the file in the public/ folder and loading it with chrome.runtime.getURL:

const url = chrome.runtime.getURL("audio/pcm-processor.js");
await ctx.audioWorklet.addModule(url);

This really should have worked. A chrome-extension:// URL is from your own extension, so the policy should allow it. I was pretty sure this was the answer.
It failed with AbortError: Unable to load worklet module. No extra info, no useful error message.
After going through Chromium bug reports, turns out this is a known broken behaviour in how Chrome handles extension files in Worklet threads. There are open issues, no fix in sight.

The old deprecated API that actually works

I gave up on AudioWorklet and used ScriptProcessorNode instead. It's been marked as deprecated for years but it runs directly in the page using a callback, so there's no extra file to load and no policy issues. For converting Float32 audio to Int16, the performance hit is basically nothing.

const processor = audioCtx.createScriptProcessor(4096, 1, 1);
processor.onaudioprocess = (e) => {
  const input = e.inputBuffer.getChannelData(0);
  const int16 = float32ToInt16(input);
  ws.send(int16);
};

Works every time without fail. The modern recommended way broke. The old way just works. That's extension development.

A few smaller things worth knowing

Cleaning up properly is harder than it sounds. Web Audio can leak memory if you don't clean up after yourself. When voice search stops, you need to close the WebSocket, disconnect the ScriptProcessor, stop all microphone tracks (this turns off the mic light in the browser toolbar), and close the AudioContext. Skip any one of these and you'll have audio processes running in the background that you can't see.
Silence detection matters a lot. Without it, the mic just stays on forever. Every time Deepgram sends back a transcript or a speech_started event, reset a 2.5 second timer. When the timer runs out, stop listening. It makes the whole thing feel much less annoying to use.
Add the Worker URL to host_permissions in your manifest. You need to allow wss://your-worker.workers.dev/* or the browser blocks the connection before it even gets to any policy check.

What actually changed

Before all of this, the extension was using window.SpeechRecognition with around 500ms before it even started listening, results that changed between machines, and random failures. After the rewrite, it connects in around 100ms, the Worker uses 1 to 3ms of CPU per request, and it works the same way every time.
Every single problem in this build came from the same place: the standard tools weren't built for this environment. Hono breaks WebSockets on Cloudflare. AudioWorklet breaks in MV3 extensions. Once you understand why something fails, the fix is usually obvious. The hard part is getting there.

Happy Coding!!!

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

- Profile
- Linkedin
- Twitter
- Youtube
- Hashnode
- DEV

Read more

- Self-Hosting Your Own Cloud Storage on AWS using NextCloud
- Creating Your First Droplet - DigitalOcean Tutorials
- Complete Markdown Tutorial for Beginners
]]> https://devarshi.dev/blog/voice-search-in-chrome-extensions https://devarshi.dev/blog/voice-search-in-chrome-extensions Mon, 16 Mar 2026 00:00:00 GMT devarshishimpi@gmail.com (Devarshi Shimpi) Technology Programming Development If you work in web engineering, the transition into 2026 hasn’t been defined by new features, but by a single, terrifying realization: The boundary between your client and server is broken.

In December, "React2Shell" (CVE-2025-55182) exposed a critical RCE in React Server Components. Barely after teams patched, two more high-severity exploits emerged in the same subsystem. This is the definitive technical post-mortem.

The "React2Shell" RCE (CVE-2025-55182)

To understand why this vulnerability (CVSS 10.0) was so devastating, we first have to understand the machinery it destroyed, the React Flight Protocol.

For years, the mental model for React developers was simple: React renders UI in the browser, and an API (REST/GraphQL) fetches data. The server and client were distinct worlds, separated by a clear network boundary.

React Server Components (RSC) erased that boundary.

!react-flight-protocol

In the RSC world, the server doesn't send HTML to the client. It streams a proprietary serialization format called "Flight." This stream contains descriptions of UI components, serialized data, and crucially Promises that resolve to data.

How React2Shell Works

React2Shell was not standard SQL injection or XSS. It was logic abuse targeting a deserializer. Attackers crafted HTTP POST requests with specific "Flight" payloads. These binary-like streams mimicked valid component trees while hiding a "Thenable" Object, or fake Promise.

1. Injection: Attacker sends serialized object containing malicious __proto__ keys.
2. Deserialization: Server parses stream and tries resolving fake Promise.
3. Prototype Pollution: Lack of sanitization lets __proto__ overwrite Object.prototype on running Node.js process.
4. Gadget Chain: Modified prototype triggers internal calls targeting Function constructor.

Accessing Function constructor means game over. Arbitrary strings like require('child_process').exec(...) compile and execute immediately.

How Next.js was Affected

Because Next.js App Router enables RSC by default, every Next.js application (versions 15.x, 16.x, and canary builds) was vulnerable out of the box. You didn't need to write a buggy Server Action to be hacked. You didn't even need to use Server Components explicitly. If your application booted up react-server-dom-webpack, it was listening for these Flight payloads.

!client-server-components

_Credits: Next.js for the image_

The DevOps Nightmare

For DevOps engineers, "React2Shell" was a worst-case scenario.

- WAF Blindness: Standard Web Application Firewalls (WAFs) are trained to look for SQL injection (' OR 1=1) or script tags (