DEV Community: Aditya Sharma

What Is ASLR? How Does Randomizing Memory Addresses Stop Exploitation?

Aditya Sharma — Sun, 27 Sep 2026 13:45:52 +0000

What if the memory address an attacker needs today isn't the same address tomorrow?

That question is the core idea behind Address Space Layout Randomization. Before getting into how it works, it helps to understand the problem it addresses.

Many exploitation techniques rely on knowing where things are in memory. If you can corrupt memory in a running process, that corruption is only useful if you can direct it somewhere meaningful. Overwrite the right data, redirect execution to the right address, or interfere with the right memory region. Without knowing where those things are, the attacker has a harder time turning a vulnerability into reliable controlled behavior.

ASLR doesn't fix the underlying vulnerability. The buggy code still exists. What ASLR does is make the memory layout unpredictable, introducing uncertainty that makes reliable exploitation significantly harder.

Understanding Virtual Memory First

To understand ASLR, you need a clear picture of what "address space" means and what ASLR is actually randomizing.

When a program runs, it doesn't directly address physical RAM. The operating system gives it a virtual address space, a range of addresses the process can use as if it had access to a large, contiguous block of memory. The operating system and hardware (through the memory management unit) translate those virtual addresses to actual physical memory locations at runtime.

Process
   |
   v
Virtual Address Space
   |
   v
Virtual-to-Physical Mapping (page table)
   |
   v
Physical Memory

Each process has its own virtual address space. Two different processes can use the same virtual addresses while mapping to entirely different physical memory. This is why one process can't accidentally read another's memory: the same virtual address means different physical memory in different processes.

ASLR works within this virtual address space layer. It changes where different regions of a process's virtual address space are placed each time the program loads.

A Process's Memory Layout

A running process typically has several distinct memory regions, each serving a different purpose:

High Addresses
------------------
|    Stack       |   Local variables, return state, function call frames
------------------
|     ...        |
------------------
| Shared Libs    |   Dynamically linked code (libc, etc.)
------------------
|     Heap       |   Dynamically allocated memory
------------------
| Data / BSS     |   Global/static variables
------------------
|    Code        |   Program instructions (text segment)
------------------
Low Addresses

The exact layout depends on the operating system, architecture, executable format, linker, and loader. This is a conceptual model, not a universal specification. But the general principle holds: different types of data and code live in different regions of the virtual address space.

Without ASLR, these regions tend to load at fixed or predictable base addresses. The code segment starts at the same place every time. The stack begins at the same place. Shared libraries map to the same addresses. An attacker who studies the binary or observes memory once can often predict exactly where things will be in future runs.

Why Predictable Addresses Help Attackers

Consider a memory corruption vulnerability, a type confusion bug, an out-of-bounds write, a buffer overflow. The vulnerability lets an attacker write data somewhere in memory. That's a starting point, not an end goal. The question is what that write can accomplish.

Exploitation techniques often need to redirect execution, corrupt data structures at specific locations, or reference existing code that does something useful. All of these require knowing the addresses involved.

Without ASLR:

Run 1 → libc at address 0xf7400000
Run 2 → libc at address 0xf7400000
Run 3 → libc at address 0xf7400000

The attacker can work out those addresses through static analysis, running the application locally, or reading public information about the system. Once known, they stay known.

With ASLR:

Run 1 → libc at address 0xf7312000
Run 2 → libc at address 0xb76a1000
Run 3 → libc at address 0xf4a23000

The attacker's knowledge of where libc was in one execution doesn't help for the next. They face a new problem: before exploiting the vulnerability, they need to discover the current layout.

What ASLR Actually Randomizes

ASLR randomizes the base addresses of major process memory regions when the process loads. Depending on the operating system, configuration, and whether the executable is built with appropriate support, this can include:

The stack. Where the stack begins in virtual memory changes between runs. This affects the addresses of local variables, saved return state, and other stack-based structures.

The heap. Where the dynamic memory allocator starts its managed region changes between runs.

Shared libraries. Dynamically linked libraries are mapped into the process address space at load time. With ASLR, their base addresses are randomized, changing the addresses of all the code and data they contain.

Memory-mapped regions. Files or other resources mapped into memory also receive randomized addresses.

The main executable. This only receives randomization if the executable is built as a Position Independent Executable (PIE), discussed next.

PIE: Randomizing the Executable Itself

A normal compiled executable often assumes it will be loaded at a specific base address. Instructions in the binary may use hardcoded addresses relative to where the program expects to be. If the operating system tries to load it at a different address, the program breaks.

A Position Independent Executable is built differently. The compiler and linker generate code that works correctly regardless of where it is loaded in virtual memory. Instead of hardcoded absolute addresses, the code uses position-relative addressing. The loader can place the executable at any address and everything still functions.

This distinction matters:

ASLR = the OS mechanism that randomizes load addresses at runtime

PIE = the executable property that allows the main binary's base address to be randomized

ASLR can randomize shared libraries, the stack, and the heap without PIE. But without PIE, the main executable's code and data often remain at a predictable base address. That gives an attacker a fixed anchor point in an otherwise randomized address space.

Modern build toolchains default to PIE for executables on many platforms, but this isn't universal. Older software, software built with older toolchains, or software that explicitly disables PIE may lack it.

Entropy: How Much Randomization Is Enough?

Randomization is only as strong as the range of possible positions. If the stack can only land in one of a small number of locations, an attacker might attempt every possibility, a strategy sometimes called brute-forcing the layout.

The number of possible positions is described by the entropy: how many bits of randomness are applied to each region. With n bits of entropy, there are 2^n possible base addresses.

On 32-bit systems, the total virtual address space is limited (4 gigabytes, or 32 bits). Allocating space for code, libraries, stack, and heap leaves relatively little room for randomization. A region might have only 16 bits of entropy for its base address, meaning 65,536 possible positions. Still an obstacle, but potentially feasible to brute-force in certain scenarios.

On 64-bit systems, the virtual address space is vastly larger. More bits are available for randomization. A shared library might have 28 or more bits of entropy in its base address, which means over 268 million possible positions. Brute-forcing this is impractical under normal circumstances.

This is a primary reason why 64-bit systems generally offer meaningfully stronger ASLR protection than their 32-bit predecessors.

Information Leaks: ASLR's Biggest Practical Weakness

ASLR works by making addresses unknown. The obvious way to defeat it is to make them known.

An information disclosure vulnerability is a bug that reveals memory contents the attacker shouldn't be able to read. If one of those memory contents is a pointer to a known structure in a randomized region, the attacker now knows where that region is loaded. The randomization still happened; the secrecy it provided didn't last.

ASLR randomizes layout
        ↓
Addresses are unknown
        ↓
Information disclosure vulnerability reveals a pointer
        ↓
Attacker calculates region's base address
        ↓
Layout becomes known for this execution
        ↓
ASLR's protection is reduced

This is why modern exploitation often involves chaining multiple vulnerabilities. The first step is finding and using an information leak to defeat ASLR. The second step is using that knowledge to make the actual corruption or redirection work.

ASLR doesn't become worthless when information leaks exist, but it stops being the sole obstacle. The attacker's job gets harder overall, but not impossible.

ASLR and the Stack

The stack holds function call frames, local variables, and the saved return state that lets a function know where to go when it finishes. In terms of exploitation, the stack has historically been a target because stack-based buffer overflows can overwrite saved return state, potentially redirecting execution.

When the stack is randomized, the addresses of local variables and saved state change between runs. An attacker who wants to overwrite a specific location on the stack, or who wants to jump to a specific stack address, cannot rely on a hardcoded value.

Stack canaries are a related but distinct protection. A canary is a value placed between local variables and saved return state. Before a function returns, the runtime checks that the canary hasn't changed. If it has, something overwrote it, and execution is terminated rather than redirected. This detects certain stack corruption independently of whether the attacker knows the stack's location.

ASLR and stack canaries address different problems. ASLR makes the stack's location unpredictable. Canaries detect that the stack has been corrupted. Both can be present simultaneously, and modern systems typically deploy both.

ASLR and the Heap

The heap is where dynamically allocated memory lives. Every object allocated with malloc in C, or new in C++, lands somewhere on the heap. The heap allocator manages free and used regions, tracking metadata about each allocation.

Predictable heap addresses matter when an attacker wants to corrupt a specific heap object or craft a structure at a known location. Heap randomization changes where the heap begins and how the allocator distributes memory, introducing uncertainty about where specific objects will land.

The heap is more complex than the stack in how its randomization interacts with exploitation, because heap layout depends on the allocation sequence throughout the program's lifetime, not just on a base address. But randomizing the heap's starting location is still a meaningful obstacle.

DEP/NX: A Different Problem

ASLR and Data Execution Prevention (DEP), also called NX (No-eXecute) on systems that use that terminology, are often mentioned together. They solve different problems.

ASLR answers the question: "Where are the things I need to reach?"

DEP/NX answers the question: "Can I execute code in this memory region?"

With DEP/NX, memory pages that hold data (the stack, the heap, most data regions) are marked non-executable at the hardware level. A process that tries to execute code from a non-executable page triggers a fault. This directly counteracts a classic technique of placing executable code into a data region and then redirecting execution there.

Without DEP/NX:
Attacker places code in stack/heap
Redirects execution there
Code runs

With DEP/NX:
Attacker places code in stack/heap
Redirects execution there
Hardware fault: memory is not executable

ASLR and DEP/NX are complementary. DEP/NX makes it harder to inject new executable code. ASLR makes the addresses of existing executable code harder to predict. Together they force attackers to look for other approaches, and those approaches face their own obstacles.

A Conceptual Scenario

Consider a fictional application with a memory corruption vulnerability. Without any mitigations, an attacker who can trigger the vulnerability might be able to redirect execution by overwriting a return address, pointing it at useful existing code at a fixed, known address.

With ASLR and PIE enabled, the same vulnerability exists. The same corruption is possible. But the useful code isn't at a predictable address. Every run, the layout is different. To reliably exploit the bug, the attacker now needs:

A way to discover the current layout before or during exploitation.
Enough time and attempts to use that information before the target changes.

Application
     ↓
Memory Corruption Vulnerability
     ↓
Need to redirect execution somewhere useful
     ↓
ASLR: useful addresses are unknown
     ↓
Need an information leak to discover them
     ↓
Exploitation becomes a multi-step problem

The underlying vulnerability is unchanged. What changed is the difficulty of turning it into reliable controlled behavior. That is what ASLR is designed to do.

How Much Protection Does ASLR Actually Provide?

ASLR is a mitigation. It raises the cost and complexity of exploitation. It is not an elimination of exploitation risk.

The practical protection depends on entropy (how many possible positions exist), whether PIE is enabled for the executable, whether the operating system randomizes all relevant regions, and whether information leaks are present that can reveal runtime addresses.

On modern 64-bit operating systems with PIE-enabled executables and no information disclosure vulnerabilities, ASLR is a significant barrier. An attacker without a way to learn the runtime layout faces an enormous range of possible addresses.

On older 32-bit systems, or systems with limited entropy, or applications compiled without PIE, the protection is weaker.

ASLR is also not identical across platforms. Linux, Windows, and macOS all implement address randomization, but the entropy applied, the regions randomized, the loader behavior, and the interaction with executable formats differ. Comparing them requires looking at specific implementation details rather than assuming uniformity.

Defense in Depth

ASLR is one layer in a broader defense model:

Memory-Safe Code
      +
ASLR (randomized layout)
      +
PIE (randomized executable base)
      +
DEP/NX (non-executable data)
      +
Stack Canaries (stack corruption detection)
      +
Control-Flow Integrity (restrict execution targets)
      +
Sandboxing (limit process capabilities)
      =
Significantly higher exploitation difficulty

No single mitigation is expected to be impenetrable. The goal is layering defenses so that exploitation requires overcoming multiple independent obstacles. Defeating one mitigation leaves others intact.

For developers, this means compiling executables with PIE and modern hardening flags, keeping toolchains and operating systems updated to benefit from improved mitigations, and not treating ASLR as a substitute for writing memory-safe code. A vulnerability that ASLR makes harder to exploit today might become more exploitable as techniques evolve.

The Core Idea

A memory address is only useful to an attacker if they can depend on it being there.

ASLR attacks that dependability. The vulnerability can still exist. The memory can still be corruptible. But the address an attacker would need to make that corruption meaningful changes with every run.

Turning a bug into a reliable exploit requires more than finding a flaw. It requires knowing the terrain. ASLR changes the terrain.

What Is Privilege Escalation? How Can a Low-Privilege User Become Root?

Aditya Sharma — Sat, 26 Sep 2026 10:46:56 +0000

You already have access to the machine. The problem is that you're only supposed to have access to some of it.

You can read your own files. Run programs. Use network services. But you can't read other users' files, modify system configuration, install software globally, or change how the kernel behaves. Those actions require privileges you don't have.

Privilege escalation is what happens when that boundary breaks. An attacker who starts with limited access ends up with more authority than they were supposed to have, sometimes far more. Understanding how that happens requires understanding what privileges are and why operating systems enforce them in the first place.

What a Privilege Actually Is

A privilege is a permission to take an action the system doesn't allow by default.

Ordinary processes run under user accounts with restricted permissions. They can interact with resources their owner can access, and nothing else. A privileged account can do things that cross that boundary: install software, read any file on the system, manage other users, change system-wide configuration, load kernel modules.

Every operating system separates these levels of access because trust is not binary. Not every user should be able to do everything. Not every program needs access to every resource. Privilege separation is the mechanism that enforces this.

Privilege escalation occurs when an actor that was supposed to operate at one privilege level ends up operating at a higher one without being authorized to do so.

Vertical vs Horizontal Escalation

It helps to distinguish two kinds of privilege escalation.

Vertical escalation means moving up the privilege hierarchy:

Normal user account
        ↓
Administrator or root

A normal user becomes able to act with the authority of a privileged account. This is the most recognized form and the main focus of this article.

Horizontal escalation means moving sideways across accounts at the same privilege level:

User A's account
        ↓
User B's data and resources

User A can access files, sessions, or data belonging to User B, even though both are ordinary users. This is equally a security failure, but the mechanism and impact are different.

Both matter. A horizontal escalation can expose sensitive data belonging to another user. A vertical escalation can expose the entire system.

Why Privilege Separation Exists

The principle of least privilege is one of the oldest ideas in security: give each identity and process only the permissions it needs to do its job, and nothing more.

Operating systems implement this through account hierarchies:

Guest / Unauthenticated
          ↓
Standard User
          ↓
Privileged Service / Application
          ↓
Administrator / Root
          ↓
Kernel

Each level has more authority than the one above it, and that authority is intentionally restricted. A standard user account cannot modify system binaries because that would allow any compromised user process to affect every other user and every program on the machine. A service that only needs to read log files shouldn't have write access to configuration files.

When privilege separation works correctly, a compromise at one level doesn't automatically compromise everything else. When it fails, a foothold at a low level can become control of the entire system.

How Privilege Escalation Happens

Privilege escalation is not a single technique. It is a category of outcomes that can result from very different root causes.

Misconfigurations

Perhaps the most common source. Someone configures a service, file, or resource with broader permissions than intended. A service that runs as root to simplify setup. A directory that is writable by all users. A scheduled task that runs a script in a user-writable location. None of these are software bugs. They are administrative mistakes, but their effect is the same: a path from low privilege to high.

Vulnerable Privileged Programs

Some programs legitimately need elevated privileges to do their job. A program that manages network interfaces needs permissions an ordinary user doesn't have. A program that changes file ownership needs permissions an ordinary user doesn't have.

If one of these privileged programs contains a security flaw, it can become a path to privilege escalation. An attacker who can manipulate the program's behavior through its inputs, its environment, or a race condition can potentially cause it to perform operations on their behalf that they couldn't perform directly.

SUID Binaries on Linux

Linux has a mechanism called the setuid bit (SUID). When a program with SUID set is executed, it runs with the effective user identity of its owner rather than the user who executed it. Programs like passwd use this mechanism: a normal user needs to run passwd to change their password, but the actual operation requires writing to system files that only root can modify.

User executes SUID program
        ↓
Process runs with elevated effective privileges
        ↓
Program performs privileged operation safely
        ↓
Operation completes, privileges drop

This is legitimate and necessary. The problem arises when a SUID program has a security flaw. If the program can be manipulated into performing unintended privileged operations, it becomes a bridge across the privilege boundary:

User finds SUID program with a flaw
        ↓
Manipulates program behavior
        ↓
Program performs unintended privileged action
        ↓
User gains unauthorized elevated access

The distinction matters: SUID is not inherently dangerous, but every SUID binary is a privileged component that needs to be secure against misuse.

Linux Capabilities

Modern Linux systems can assign specific privileged operations to processes without giving them full root access. These are called capabilities.

Instead of a process being either ordinary or fully root, capabilities allow finer control. A process might have the capability to bind to privileged network ports without having the capability to read every file on the system. A process might have the capability to change its own group without having broad administrative access.

The security concern is that capabilities, when incorrectly assigned, can still create privilege escalation paths. A process with the capability to load kernel modules has enormous power over the system, arguably more than many root operations. Capabilities reduce the blast radius of privilege in well-designed systems, but only when assigned thoughtfully.

Windows Services and Access Tokens

On Windows, every process runs within a security context defined by an access token. The token carries the identity of the account, its group memberships, and the privileges assigned to it.

Standard users have limited tokens. Administrators have broader tokens. The SYSTEM account, which many Windows services run under, typically has more access than even a local administrator to system internals.

Privilege escalation on Windows often involves getting code to run within a more privileged security context:

A service running as SYSTEM that processes user-supplied data insecurely
A scheduled task running with elevated privileges from a location a normal user can modify
An administrative tool that can be manipulated into performing privileged operations The underlying pattern is the same as on Linux: find a privileged component and find a way to influence what it does.

Kernel Vulnerabilities

The kernel sits at the bottom of the privilege hierarchy. It manages everything below the software abstraction: memory, process scheduling, hardware access, the enforcement of all the access controls discussed above.

User Space Process
        ↓
System Call Interface
        ↓
Kernel
        ↓
Hardware

A vulnerability in the kernel is particularly significant because the kernel's trust boundary is the strongest boundary in the system. A process that successfully exploits a kernel vulnerability can potentially gain control over the kernel's execution, which means control over the entire machine. All the user-space privilege separation becomes irrelevant once the attacker is operating at the kernel level.

Credentials and Configuration

Not every privilege escalation involves a software flaw. An attacker who finds credentials for a privileged account, whether stored in a configuration file, a script, an environment variable, or a database, has effectively escalated their privileges through credential theft.

Similarly, finding that a root cron job processes attacker-writable data, or that a privileged service reads configuration from an attacker-writable location, achieves the same result through a configuration weakness rather than a code vulnerability.

A Conceptual Privilege Escalation Chain

To make this concrete without being operational, here is a generic scenario.

A system has two components: a low-privilege application that accepts user input and a privileged service that processes data from the application. The separation is intentional. The privileged service is supposed to do one specific thing, safely.

Low-privilege user
        ↓
Low-privilege application
        ↓
Data passed to privileged service
        ↓
Security flaw in privileged service
        ↓
Service performs unintended privileged operation
        ↓
Attacker influences outcome
        ↓
Effective escalation to higher privilege level

The attacker didn't break the privilege boundary directly. They found a component that legitimately crossed it and made it do something unintended. This pattern, using a privileged component as a bridge, is central to how privilege escalation works across many different contexts.

Vulnerabilities vs Misconfigurations vs Credentials

These three root causes produce similar outcomes but require different responses.

A software vulnerability means a privileged program contains a flaw that allows unintended behavior. The fix is patching the software.

A misconfiguration means a permission or trust relationship is set up incorrectly. The fix is correcting the configuration and understanding why the mistake was made.

A credential issue means an attacker obtained credentials belonging to a more privileged account. The fix involves credential rotation, better storage practices, and understanding how the credentials were exposed.

Treating a misconfiguration like a software vulnerability, or vice versa, leads to incomplete responses. A patch doesn't fix a misconfigured service. Fixing a configuration doesn't prevent the same code flaw from being exploited through a different path.

How Defenders Reduce the Risk

Least privilege as a design principle. Every user, service, and process should have only the permissions it needs. This limits the damage that any single compromised component can cause. A service running as a standard user with narrow permissions provides a much smaller bridge for privilege escalation than a service running as root.

Patch management. Privileged programs that contain vulnerabilities need to be updated. Kernel vulnerabilities in particular need rapid response.

Audit SUID binaries and capabilities. Every SUID binary and every process with elevated capabilities is a potential pivot point. Know what exists on each system and whether those elevated permissions are actually necessary.

Secure service configuration. Services running with elevated privileges should read from, write to, and process data from locations that unprivileged users cannot influence.

Credential protection. Passwords, tokens, API keys, and other credentials for privileged accounts should not appear in scripts, configuration files, environment variables, or log output where lower-privileged processes can read them.

Monitor privileged actions. Sudden changes in account privilege levels, unexpected processes running under privileged identities, or unusual access to sensitive system resources can be early indicators of privilege escalation attempts.

Isolation. Containers, virtual machines, and sandboxing mechanisms add additional layers of isolation, so a compromised component has fewer paths to privileged resources.

Least privilege doesn't eliminate privilege escalation as a possibility. A service needs some privileges to function, and those privileges can be abused. But minimizing privileges minimizes the available attack surface and the potential impact of any successful escalation.

Detecting Privilege Escalation

On a running system, defenders look for signs that privilege boundaries have been crossed:

New administrative accounts that weren't created through an expected provisioning process
Processes suddenly running under privileged accounts or with unexpected tokens
Unexpected modifications to files only privileged processes should touch
System logs showing privilege changes without corresponding administrative activity
Unusual access to system directories, shadow password files, service credentials, or kernel interfaces
Security tools reporting that a process is operating with elevated effective privileges it shouldn't have Privilege escalation typically doesn't announce itself. An attacker who has successfully escalated will often try to maintain persistence quietly. The window for detection is often before the escalation completes: catching the reconnaissance, the probing of privileged services, or the early stages of exploitation.

Privilege Escalation vs Initial Access

It is worth being explicit about where privilege escalation fits in the broader picture.

Initial access is how an attacker gains any foothold on a system: exploiting a public-facing service, using stolen credentials, social engineering, a vulnerable client application. At this point, the attacker may have very limited access.

Privilege escalation is what happens after. The attacker has some access and wants more.

The reason this distinction matters is that an initial access with limited privileges is not necessarily a contained incident. A normal user account on a system is often a starting point, not a final position. Defenders who focus entirely on preventing initial access sometimes underestimate the importance of limiting what an attacker can do once they're in.

A system where a compromised low-privilege account can quickly become root is more dangerous than a system where a compromised low-privilege account remains constrained. The goal of privilege separation is that limited access stays limited.

The Deeper Lesson

Operating systems make a promise: different accounts get different levels of authority, and those boundaries hold. Privilege escalation is what happens when that promise breaks.

The break can come from a software flaw in a privileged component. It can come from a configuration mistake that makes a trust relationship too broad. It can come from credentials that were stored where they shouldn't have been.

In every case, the mechanism is the same: a path from a lower privilege level to a higher one that shouldn't exist.

The attacker's job is to find that path. The defender's job is to make sure as few paths as possible exist, and that any path that does exist is difficult to traverse without being detected.

The security goal isn't just keeping attackers out. It's ensuring that wherever they enter, they cannot reach the parts of the system that matter most.

What Is Bootstrap Aggregation? How Does Bagging Make Machine Learning Models More Robust?

Aditya Sharma — Fri, 25 Sep 2026 05:30:43 +0000

A single ML model is just one opinion. It learned from one arrangement of training data, made specific decisions about what patterns matter, and internalized the noise in that particular dataset alongside the signal.

What if, instead of trusting that one opinion, you trained dozens of models on slightly different versions of the same data and took a vote?

That's the core idea behind Bootstrap Aggregation, usually called Bagging. It doesn't try to build a perfect model. It builds many imperfect models with deliberate variation between them, then combines their predictions into something more stable than any individual model could produce.

What "Bootstrap" Actually Means

Before the machine learning part, there's a statistical concept worth understanding.

A bootstrap sample is a new dataset created by sampling with replacement from the original dataset. The resulting sample has the same number of rows as the original, but it's not identical. Because each observation is drawn independently with replacement, some rows from the original dataset will appear multiple times, and others won't appear at all.

Here's a small example. Say your original training set has five examples:

Original: [A, B, C, D, E]

A bootstrap sample of size 5 might look like:

Bootstrap 1: [A, A, C, D, D]   (B and E omitted; A and D appear twice)
Bootstrap 2: [B, C, C, E, E]   (A and D omitted; C and E appear twice)
Bootstrap 3: [A, B, B, D, E]   (C omitted; B appears twice)

Each bootstrap sample represents a slightly different picture of the same underlying data. The statistical theory behind this goes back to work on estimating properties of a distribution from a sample, but for our purposes the key point is this: by sampling with replacement, you get genuine variation between samples without needing more data.

For a dataset with n observations, any given bootstrap sample will omit roughly 1/e of the original observations on average, which works out to about 36.8%. Those omitted observations become useful later.

The Bagging Pipeline

The full process looks like this:

Original Training Dataset
          |
          +----------+----------+----------+
          |          |          |          |
     Bootstrap 1  Bootstrap 2  Bootstrap 3  ...
          |          |          |          |
       Model 1    Model 2    Model 3    ...
          |          |          |          |
          +----------+----------+----------+
                         |
                    Aggregation
                         |
                  Final Prediction

Bootstrap sampling: Create k bootstrap samples from the original training set. Each sample has the same number of rows as the original but is different due to sampling with replacement.

Train independently: Train one model on each bootstrap sample. These models are trained completely independently of each other. This is important: they don't communicate, don't share gradients, and don't adjust based on each other's performance.

Generate predictions: For a new input, run it through all k models and collect their predictions.

Aggregate: Combine those predictions into one.

For regression, aggregation typically means averaging the numerical outputs:

Final prediction = (pred_1 + pred_2 + ... + pred_k) / k

For classification, it typically means majority voting:

Final prediction = most common class among (pred_1, pred_2, ..., pred_k)

Why Does Bagging Actually Work?

This is the important part. Bagging isn't magic. It works because of a specific property of aggregating independent, diverse predictions.

Start with the concept of variance in the context of a model. A high-variance model is sensitive to the specific training data it saw. Train it on one dataset, and it learns one set of patterns. Train it on a slightly different dataset, and it might make quite different predictions. Decision trees with no depth limit are a classic example: they'll fit their training data nearly perfectly but their predictions can shift dramatically if the training data changes slightly.

Now consider what happens when you average multiple high-variance predictions.

If the errors made by individual models are uncorrelated (or at least not perfectly correlated), their random mistakes tend to cancel out when averaged. One model overestimates on a particular region of the input space; another underestimates. Their average is closer to the truth than either individual prediction.

Formally, if you have k models each with variance sigma squared and zero covariance between their errors, the variance of their average is:

Var(average) = sigma^2 / k

As k increases, the variance of the ensemble prediction shrinks. This is the same reason that averaging many noisy measurements of a quantity gives you a better estimate than relying on a single noisy measurement.

The important caveat is the "uncorrelated" part. If all your models make the same mistakes because they're too similar to each other, averaging them doesn't help much. The formula for the average variance when models have pairwise correlation rho is:

Var(average) = rho * sigma^2 + (1 - rho) * sigma^2 / k

When rho approaches 1 (models are identical), the variance reduction from k models disappears. This is why the bootstrap sampling step matters: it deliberately creates variation between the training sets, which creates variation between the models, which reduces correlation between their errors.

Bagging primarily reduces variance. It does not reliably reduce bias. If all your models are systematically wrong in the same direction, averaging them will still give you a systematically wrong answer.

A Concrete Example

Say you're classifying whether an email is spam or not, and you train five small decision trees using bagging. For a particular email, they each make a prediction:

Model 1: Spam
Model 2: Not Spam
Model 3: Spam
Model 4: Spam
Model 5: Not Spam

Majority vote: Spam appears three times, Not Spam appears twice. Final prediction: Spam.

For a regression example, say you're predicting house prices and five models return:

Model 1: $412,000
Model 2: $395,000
Model 3: $428,000
Model 4: $407,000
Model 5: $418,000

Average: ($412,000 + $395,000 + $428,000 + $407,000 + $418,000) / 5 = $412,000

Any one of these models might be somewhat off. Their average tends to be closer to the true value than most of the individual predictions, assuming the individual errors aren't all biased in the same direction.

Why Not Just Train the Same Model Repeatedly?

The obvious question: why go through the trouble of bootstrap sampling? Why not just train the same model multiple times on the same data?

If your model is deterministic and you train it on the same dataset, you'll get the same model every time. Averaging five copies of the same model gives you exactly that model, with no variance reduction at all.

Bootstrap sampling is what creates the necessary diversity. Each sample contains a different subset of the training examples, with different duplications. A model trained on Bootstrap 1 never sees some of the original examples and sees others multiple times. A model trained on Bootstrap 2 has a different combination of repeated and missing examples. The result is k genuinely different models that learned slightly different things.

A secondary benefit: because each model is trained independently, the training process can be parallelized. Train k models simultaneously across k machines or k CPU cores. This is not possible with methods where models must be trained sequentially.

Out-of-Bag Samples

Remember that each bootstrap sample omits roughly 36.8% of the original training examples. Those omitted examples are called out-of-bag (OOB) samples for that particular model.

Since the model was never trained on its out-of-bag examples, those examples can be used to evaluate the model's performance on data it hasn't seen. For each original training example, it was out-of-bag for some fraction of the k models. You can collect predictions from those models (the ones that didn't train on this example) and use them to estimate the model's generalization error.

Aggregating these OOB predictions across the entire training set gives you an OOB error estimate: an estimate of how well the ensemble performs on unseen data, without needing to hold out a separate validation set.

This is a useful property. In situations where you want to use as much data as possible for training, OOB evaluation lets you get a generalization estimate without sacrificing any training examples to a held-out set.

OOB error is not always equivalent to k-fold cross-validation or other evaluation strategies, and the two can diverge depending on the dataset and model. But it's a practically useful tool that comes essentially for free when you're already doing bagging.

Bagging and Random Forests

Random Forest is one of the most successful applications of the bagging idea, but it's not identical to bagging.

Standard bagging: take bootstrap samples, train full models independently on each, aggregate predictions.

Random Forest: also uses bootstrap samples and independent training, but adds one more source of randomness. At each split point in each decision tree, instead of considering all available features, it considers only a random subset of features. This additional randomization makes the trees even more different from each other.

Why does this help? In standard bagging with decision trees, if there's one very strong predictor in the dataset, most of the trees will use that predictor near the top of each tree. The resulting trees will be more correlated with each other than bootstrap sampling alone would suggest, because they're all making similar early splits. Restricting feature selection at each split breaks this correlation and lets other predictors contribute meaningfully across different trees.

Random Forest therefore benefits from two distinct sources of diversity: bootstrap sampling (different training examples) and random feature selection (different features considered at each split). The result is typically lower correlation between trees and better ensemble performance than standard bagging with decision trees.

Bagging:
  Bootstrap samples + independent training + aggregation

Random Forest:
  Bootstrap samples + independent training + random feature subsets + aggregation

Bagging vs. Boosting

Boosting is another ensemble method, but it operates on entirely different principles.

	Bagging	Boosting
Training order	Independent, parallel	Sequential, each model trained on results of previous
Data weighting	Each model sees a bootstrap sample	Examples weighted by difficulty; hard examples emphasized
Primary effect	Reduces variance	Reduces bias (and variance in some formulations)
Model relationship	Each model stands alone	Each model corrects residuals of the previous ensemble
Examples	Random Forest	AdaBoost, Gradient Boosting, XGBoost

In boosting, model 2 is trained on what model 1 got wrong. Model 3 is trained on what the combination of model 1 and model 2 got wrong. Each new model is guided by the failures of the previous ones, which makes the ensemble increasingly accurate on hard examples.

Bagging makes models independent on purpose. Boosting makes models dependent on purpose.

Both can produce strong ensembles, but they're solving different problems. Bagging is most useful when your base model is high-variance and unstable. Boosting can sometimes help when your base model is too simple (high-bias), though this depends significantly on the specific boosting algorithm and configuration.

When Bagging Helps (and When It Doesn't)

Bagging is most effective when the base model is a high-variance, low-bias learner. Deep decision trees are the canonical example: they overfit individual training sets aggressively, and bagging provides substantial stability gains.

If your base model is already stable (low-variance), bagging provides little benefit. A linear regression model trained on reasonable data will produce nearly the same predictions regardless of small variations in the training set. Averaging many nearly identical linear models doesn't give you much.

Bagging also doesn't fix bias. If your model consistently underestimates a quantity because it lacks the capacity to fit the true relationship, averaging more such models will still underestimate.

The conditions where bagging provides meaningful improvement:

High-variance base models
Datasets where different bootstrap samples genuinely change model behavior
Sufficient diversity between the resulting models The conditions where bagging helps less:
Already-stable base models
Highly correlated base models despite bootstrap sampling
Problems where bias is the primary issue

The Deeper Intuition

Training one model is like asking one person for directions. They might know the area well, or they might give you confidently wrong advice based on a bad experience they had once.

Asking ten people who've each explored slightly different parts of the area gives you more coverage. Their individual answers might vary, but their collective answer tends to be more reliable than any single person's, especially if they each have genuine knowledge rather than all reading from the same map.

Bagging does the same thing with models. It doesn't make any individual model better. It creates genuine variation through bootstrap sampling, exploits the statistical property that averaging independent noisy estimates reduces variance, and produces an ensemble whose stability comes from the diversity of its components.

The robustness isn't in any single tree or any single decision. It emerges from the agreement across models that each learned from a slightly different slice of the data.

What Is a Polyglot File? How Can One File Be Valid as Multiple File Formats?

Aditya Sharma — Thu, 24 Sep 2026 06:02:21 +0000

You upload one file. The upload validator inspects the bytes and says: "That's a JPEG image. Safe to accept."

Later, a different component in the same system opens the exact same bytes. It says: "That's a ZIP archive."

Neither component is broken. Neither is guessing. Both are applying real parsing logic to the same byte sequence, and both are finding something valid.

The question is: how can one sequence of bytes legitimately satisfy the syntax rules of two completely different file formats?

A File Format Is a Grammar for Bytes

Before getting into polyglots, it helps to be precise about what a file format actually is.

A file format is a specification that describes how bytes should be structured and interpreted. It defines things like:

Where the file begins (often a recognizable sequence of bytes called a magic number or file signature)
How the header is structured
Where the actual content data lives
How size, offset, and length values are encoded
Where the file ends, or what markers signal the end of meaningful content A PDF begins with %PDF-. A JPEG begins with FF D8 FF. A ZIP typically begins with PK (the initials of Phil Katz). These are not conventions the parser ignores. They are required structural elements that a conforming parser expects to find.

A filename extension like .jpg or .pdf is just a label. It tells the operating system which application to open the file with, but it doesn't affect the bytes themselves. A parser that receives raw bytes typically doesn't look at the filename. It looks at the content.

What a Polyglot File Actually Is

A polyglot file is a byte sequence that simultaneously satisfies the structural requirements of more than one file format.

Same byte sequence
        ↓
 ┌──────────────────────┐
 ↓                      ↓
Parser A              Parser B
 ↓                      ↓
Valid format A        Valid format B

The file has not been corrupted. The bytes have been deliberately (or sometimes accidentally) arranged so that two different parsers, each applying its own grammar, both find a valid structure.

This is different from a renamed file. Renaming malware.exe to photo.jpg is extension spoofing. The bytes inside don't satisfy any JPEG parser. A robust validator that actually parses the content will reject it. A polyglot is more subtle: the bytes genuinely satisfy more than one parser's expectations.

Why Two Formats Can Coexist in One File

Different file formats make different structural assumptions. Those differences create space for coexistence.

Some parsers care only about the beginning of the file. If the magic bytes match, they accept the file. They may not validate every subsequent byte.

Some parsers care about structures at specific offsets. A format might require its header at byte 0, then allow arbitrary content until a particular marker appears.

Some formats define what they are interested in and treat anything else as ignorable. A parser that encounters bytes it does not recognize in a region it considers padding or metadata may simply skip past them.

Some formats place their critical structures near the end of the file. ZIP archives, for example, locate their central directory at the end. A parser reading a ZIP starts near the end-of-central-directory signature rather than at byte 0. This means the beginning of the file is largely irrelevant to a ZIP parser.

These structural properties create regions where two formats can coexist without conflict.

Byte offset 0
│
├── Format A header (magic bytes, required header)
│
├── Region ignored by Format A
│   ↕
│   Format B-compatible structures live here
│
├── Shared data
│
└── Format A/B terminal structures

The exact possibilities depend entirely on the specific formats involved. A JPEG parser and a ZIP parser make very different demands on the same byte sequence, and those demands happen to be compatible in ways that allow a single file to satisfy both.

Magic Bytes Are Not the Same as Full Validation

A common validation approach checks the first few bytes of a file against known signatures. If the file starts with FF D8 FF, it's probably a JPEG. Accept it.

This answers one question: "Does the file begin like format X?" That is not the same as "Does the entire file conform to format X?"

A file can begin with valid JPEG magic bytes and still contain structures elsewhere that another parser will successfully interpret as a different format. A thorough validator parses the entire file using the expected format's grammar: validating headers, checking that declared lengths match actual content, ensuring all structures fall within expected boundaries, and rejecting anything that doesn't conform. That is a fundamentally different operation from reading the first four bytes.

When Parser Disagreement Becomes a Security Problem

A polyglot file by itself is not inherently malicious. The security concern arises when different components in the same system interpret the same bytes differently, and those components sit at different points in a security decision.

Consider a typical file upload flow:

User uploads file
        ↓
Upload validator (checks magic bytes, MIME type, extension)
        ↓
"Looks like a JPEG. Accepted."
        ↓
File stored on disk
        ↓
Another component processes the same file
        ↓
This component finds a different valid structure in the bytes

The upload validator made a decision about what the file is. A downstream component made a different decision about the same bytes. The security boundary was crossed using the conclusion from the first parser, but the second parser operates by different rules.

This is the key insight: a security check is only meaningful if the component enforcing the check and the component eventually consuming the file agree on what the file is.

Polyglots and File Upload Validation

Security-sensitive file upload handling typically involves several layers of validation.

Extension checks verify that the filename ends with an expected suffix. These are easy to spoof and should not be the primary defense.

MIME type checks look at the Content-Type header in the upload request. This is client-supplied data and equally easy to manipulate.

Magic byte checks inspect the first bytes of the file. More reliable than the above, but as discussed, insufficient on their own.

Full format parsing validates the entire file structure using a library that implements the expected format's grammar. This is more robust but depends on the library being used correctly and on the format being parsed matching what downstream components will use.

Transcoding and re-encoding take a different approach: instead of validating the uploaded file, the system decodes it and immediately re-encodes it into a clean, known-good representation. If someone uploads an image, the server converts it to a pixel buffer and writes a fresh image file from scratch. Any structures in the original file that didn't belong to the image data are discarded in the process. This approach is strong precisely because it doesn't need to understand everything the attacker might have embedded.

The limitation with any single-stage validation is that it captures only one interpretation of the bytes. The component doing the validation may reach a different conclusion than the component eventually consuming the file.

Polyglot Files vs. Related Concepts

Extension spoofing: A file with a misleading name. The bytes don't satisfy the spoofed format. A parser-level check catches it.

MIME-type spoofing: A file uploaded with a false Content-Type header. Also client-supplied and trivially manipulated.

Parser differential: Two components receiving the same input and interpreting it differently. A polyglot can create parser differentials, but parser differentials can occur without a polyglot. An ambiguous HTTP header or a malformed request can also cause two components to disagree without involving a file format at all.

Content-type confusion: A broader term for situations where a component makes incorrect assumptions about what type of content it is handling. A polyglot can produce content-type confusion, but the term covers more than just file formats.

A polyglot is specifically about the underlying byte sequence satisfying multiple format grammars simultaneously. That is a stronger property than simply misleading a label.

Why the Processing Pipeline Is the Real Boundary

Modern frameworks often provide upload validation utilities, file-type detection libraries, and secure storage helpers. The security properties of the entire system still depend on how the whole pipeline behaves together.

Upload validator
        ↓
Storage
        ↓
Image processing library
        ↓
Web server serving the file
        ↓
Browser parsing the response

Each step has its own notion of what the file is. If the validator uses one parser and a downstream component uses another, there is potential for disagreement. A file can pass the validator's check while still containing structures that a later component interprets differently. Security testing that covers only the upload endpoint misses this entirely.

Defenses That Follow From the Mechanism

Do not rely on file extensions or MIME types from the client. Both are trivially manipulated by the sender and tell you nothing about the actual bytes.

Validate using the correct parser for the expected format. The parser used at validation should match the parser that will ultimately consume the file. A mismatch between those two creates exactly the kind of gap a polyglot exploits.

For image uploads, consider re-encoding. Decoding to a pixel buffer and writing a fresh image from scratch discards any embedded structures that don't belong to the image data. This sidesteps validation entirely in favor of producing a known-clean output.

Reject ambiguous or malformed content. A file that is partially valid under one format should not pass a lenient check silently.

Store uploads outside executable or directly web-accessible paths. Even if validation is incomplete, a file that cannot be executed or served directly limits the impact.

Test the full processing chain. Each component that touches the file is a potential point where interpretation diverges from what earlier stages assumed. Testing only the upload endpoint misses this entirely.

The Deeper Lesson

A file does not carry its own authoritative interpretation.

Meaning is assigned by parsers, and parsers differ. When a byte sequence passes through multiple components that each apply their own grammar, the same bytes can mean different things at different points in the system.

This is not a flaw in any particular file format or library. It is a property of how parsing works. Different grammars, applied to the same bytes, can reach different conclusions.

The security model collapses when a decision made by one parser is trusted by components that operate with a different parser. The validation check confirmed one interpretation. The eventual consumer operated on another.

That is what a polyglot exploits. Not that validators are broken. Not that parsers are buggy. The file is read in one way at the checkpoint, and in another way once it is past it.

What Is Web Cache Deception? How Can an Attacker Make a Cache Store Private Data?

Aditya Sharma — Wed, 23 Sep 2026 06:14:07 +0000

A user authenticates. They request a page that only they should see. The application checks their session, confirms they are authorized, and returns their private data. No authorization check was skipped. No SQL was injected. The application behaved correctly.

But somewhere between the user's browser and the origin server, a cache stored that response. Later, someone else requested the same cache key. The cache returned the previous user's private page.

The application didn't leak the data. The cache did.

This is the core question: how can a system designed to make websites faster accidentally become a place where private data is stored and served to the wrong person?

How Web Caches Work

When a user requests a web page, the request doesn't always travel directly to the origin server. Most production applications sit behind one or more intermediaries: CDNs, reverse proxies, load balancers. These components can serve responses from a local store rather than forwarding every request upstream.

Browser
  ↓
CDN / Reverse Proxy / Cache
  ↓
Origin Server
  ↓
Application

A cache stores a response associated with a cache key, typically derived from the request URL and sometimes other request attributes. When a subsequent request arrives with a matching key, the cache can return the stored response without contacting the origin. This reduces latency and origin load.

Caching is a performance mechanism. The security problem arises when a cache stores a response that should not have been stored, or serves it to a request that should not receive it.

The Interpretation Mismatch

Modern web applications often route requests flexibly. A path like /account/profile might be handled by the application's routing logic, which checks the session cookie, fetches the relevant data, and returns a personalized response. The URL is not a path to a file. It is a route to application behavior.

Caches, however, often make cacheability decisions using different signals: URL path patterns, file extensions, explicit cache-control headers, or cache rules configured by an administrator. Those rules may or may not agree with what the application actually does.

The vulnerability class called web cache deception exploits the gap between these two interpretations.

Consider:

/account/profile

The application routes this to the authenticated profile handler and returns private content.

Now consider:

/account/profile/style.css

Whether this URL reaches the same handler depends entirely on how the application's routing is configured. Many frameworks will match the most specific route and fall back to the parent route when nothing more specific is found. Some serve the same profile content regardless of a trailing path segment they don't recognize. Others return 404.

If the application returns the same private profile response for /account/profile/style.css because its routing treats the unknown suffix as a parameter or falls through to the profile handler, then the origin's behavior is unchanged. The user gets their private data.

But the cache may see a .css extension and classify the response as a static resource, eligible for caching. The origin said "here is private user data." The cache heard "here is a stylesheet. I'll remember this."

Origin interpretation:   /account/profile/style.css → private profile data
Cache interpretation:    /account/profile/style.css → static CSS → cacheable

Same URL. Different meanings to different components.

The Attack Sequence

The conceptual attack flow has several steps:

Victim authenticates
    ↓
Victim visits deceptive URL
    ↓
Origin returns private response (correctly authorized)
    ↓
Cache stores response under that URL's cache key
    ↓
Attacker requests the same URL
    ↓
Cache returns victim's private response

For this to succeed, specific conditions need to align. The application must return the same private content for the crafted URL as for the original one. The cache must consider the crafted URL cacheable when it would not cache the original URL. The cache must not include session cookies or other user-specific attributes in its cache key for that request. And the response headers must not instruct the cache to treat the response as private.

These conditions are not guaranteed to exist. Whether a given system is vulnerable depends on the application's routing, the cache's configuration, the response headers, and how those components interact. Cache deception is a configuration and design problem, not an inherent flaw in any particular technology.

Cache Keys, Cacheability, and Why Authentication Does Not Save the Victim

To understand why this matters at a deeper level, it helps to understand how caches make decisions.

A cache key identifies which stored response to return for a given request. The key is often the URL, but many caches include or exclude other request attributes based on the Vary response header or configuration rules. If a session cookie is not included in the cache key, two requests with different sessions but the same URL may receive the same cached response.

Cacheability is a separate question. A cache determines whether a response can be stored based on the HTTP method, response status code, Cache-Control directives, and sometimes configured rules that override headers.

The dangerous scenario is when the cache key does not include user identity, the cache considers the response cacheable based on the URL pattern, and the application returns user-specific content for that URL.

It is important to be precise about authentication here. Cache deception does not bypass the application's authentication. The origin correctly authenticates the victim and correctly generates their private response. The authorization logic works. The problem occurs afterward: the cache observes a response already authorized by the origin and stores it, then serves that stored response to the next matching request without involving the application at all.

"The application authorized this response for this user."

vs.

"The cache should have stored this response for anyone who asks."

These are different questions. The application answered the first correctly. The cache answered the second incorrectly.

HTTP Headers and Cache Control

HTTP provides mechanisms for controlling caching behavior through the Cache-Control response header.

Cache-Control: private tells shared caches not to store the response. Cache-Control: no-store tells caches not to store it at all. The Vary header specifies which request headers should differentiate cached responses: Vary: Cookie tells the cache to treat requests with different cookies as separate cache entries. RFC 7234 also specifies that caches should not store responses to requests carrying an Authorization header unless the response explicitly permits it.

These mechanisms work when correctly implemented and when the cache actually respects them. CDN cache rules that override response headers, misconfigured cache exceptions, or rules that prioritize URL matching over response headers can undermine what the application intends. The headers are necessary but not sufficient on their own.

Cache Deception vs. Cache Poisoning

These two vulnerability classes involve caches behaving in unintended ways, but the direction of the problem is different.

Cache deception: A victim's private, authorized response gets stored under a cacheable-looking URL. A subsequent request retrieves that private response from the cache.

Cache poisoning: An attacker causes a malicious or undesirable response to be stored in the cache, so legitimate users receive it.

In cache deception, the attacker benefits from something the victim received. In cache poisoning, the attacker puts something into the cache that other users receive. The mechanism involves caches in both cases, but the goal and the exploit structure are different.

Normal caching is neither: a public response is stored and reused, which is exactly what was intended.

Why Frameworks and CDNs Do Not Automatically Solve This

Modern frameworks often provide sensible defaults for authenticated routes. Many CDNs allow fine-grained cache rules. But security depends on the entire configuration working correctly together.

A framework that sets Cache-Control: private on authenticated responses does not help if a CDN rule overrides cache headers for URLs ending in .css. An application that routes unknown suffixes to dynamic handlers does not help if it does not set appropriate headers for those responses. A CDN configured to cache static assets does not distinguish between a real stylesheet and a URL that merely resembles one if no other signal is present.

The interaction between application routing, response headers, and cache configuration determines actual behavior. Assuming any single layer handles this correctly without testing the combination is where security gaps appear.

Defenses

Set appropriate Cache-Control headers on private responses. Cache-Control: no-store or Cache-Control: private tells shared caches not to store the response. This is the most direct defense and must be present on every response carrying user-specific content.

Ensure cache rules and application routing agree. If the cache caches all URLs with .css extensions, the application should not serve private content for those URLs.

Do not treat file extension alone as evidence of cacheability. URL pattern-based cache decisions without consulting response headers can override application intent.

Test URL normalization and routing differences. Check whether the application serves the same content for variations of a private URL: unknown path segments, trailing content, encoded characters, and unusual extensions.

Include user-identifying attributes in the cache key where appropriate. If personalized content must be cached, the cache key must reflect the attributes that differentiate responses between users.

Inspect actual CDN and reverse proxy behavior. Test the full request path under production-like conditions. Configuration and runtime behavior can differ.

Include cache behavior in security testing. Testing the application in isolation does not reveal how caches interact with it.

The Deeper Lesson

Authorization is not the only layer that determines whether a response reaches the right person.

An application can correctly authenticate a user, correctly generate a private response, and correctly close the connection. If the response was stored by a cache in between, the application's authorization decision no longer governs what happens next.

The security boundary for a web response includes every component that stores, transforms, routes, or reuses that response. A cache is not passive. It makes decisions, and those decisions can diverge from what the application intended.

Web cache deception exists in that gap. The application authorized a response. The cache decided to share it.

What Is Zip Slip? How Can a ZIP File Write Files Outside Its Extraction Folder?

Aditya Sharma — Tue, 22 Sep 2026 05:40:04 +0000

A user uploads a ZIP file. The server extracts it into a temporary directory. Nothing seems wrong. The files are written. The process completes cleanly.

But one of those files didn't land in the temporary directory. It landed somewhere else on the filesystem entirely. Somewhere it shouldn't have reached.

The ZIP file didn't execute any code. No memory was corrupted. The extraction library worked exactly as designed. The problem was that the application trusted a filename inside the archive to be safe, and used it directly to construct a filesystem path.

That's Zip Slip.

How ZIP Archives Store File Paths

A ZIP archive is not just a collection of compressed file contents. Each entry in the archive has metadata: a filename, compression method, timestamps, and other attributes. That filename can contain a path, not just a bare name.

When you create a ZIP containing reports/2024/summary.csv, the archive entry stores reports/2024/summary.csv as the entry name. Extraction software reads this name and uses it to reconstruct the directory structure at the destination.

The critical point is that the archive itself defines the filename. The extraction software reads whatever string is stored in the entry metadata and uses it as a filesystem path. If that string contains ../ sequences, the path can escape the intended extraction directory.

How Path Traversal Works in This Context

../ is a standard filesystem path component meaning "go up one directory level." It is not a special attack payload. It is valid in any operating system's path resolution rules.

So if an archive entry's name is ../important.conf, and the extraction directory is /tmp/upload/, the extracted destination becomes:

Extraction directory:    /tmp/upload/
Entry name:              ../important.conf
Joined path:             /tmp/upload/../important.conf
Resolved path:           /tmp/important.conf

The file lands one level above the extraction directory. Extend this further:

Entry name:              ../../etc/cron.d/job
Joined path:             /tmp/upload/../../etc/cron.d/job
Resolved path:           /etc/cron.d/job

Each ../ walks up one level. Enough of them can reach anywhere on the filesystem from the extraction root.

The normal flow versus the vulnerable flow:

Safe archive entry
      ↓
Extraction directory + entry name
      ↓
Resolved path inside extraction directory
      ↓
File written safely

Malicious archive entry (../../etc/cron.d/job)
      ↓
Extraction directory + entry name
      ↓
Resolved path escapes extraction directory
      ↓
File written to arbitrary location

Why Checking the Filename Alone Is Not Enough

A naive defense might look for ../ in the entry name and reject any entry that contains it. That catches the obvious case. But it doesn't catch everything.

URL encoding and other representations. Some extraction code may decode entry names before writing. An entry named ..%2F or %2e%2e/ may be decoded into ../ after any string-level check has already run. The check sees a safe string; the filesystem sees a traversal.

Absolute paths. An archive entry can also store an absolute path like /etc/passwd rather than a relative one. If the extraction code joins the extraction directory with an absolute path on some platforms, or simply uses the path as-is, the result skips the extraction directory entirely.

Mixed separators. On Windows, both / and \ are valid path separators. An entry named ..\config\app.ini may pass a check that only looks for ../ while still traversing upward.

Normalization after joining. The important check is not whether the entry name looks suspicious. The important check is whether the fully resolved destination path still falls inside the intended extraction directory. These are different questions.

The Role of Path Canonicalization

Canonicalization is the process of resolving a path to its definitive form: expanding .. components, resolving symlinks, collapsing redundant separators, and producing an absolute path.

The correct approach is:

entry_name = read from archive
destination = extraction_dir + entry_name
canonical = canonicalize(destination)

if not canonical.startswith(extraction_dir):
    reject entry

This check happens after resolution, not before. It doesn't matter what the entry name looks like. What matters is where the file would actually end up.

The naive approach that fails:

entry_name = read from archive

if ".." in entry_name:
    reject
else:
    write to extraction_dir + entry_name   # still vulnerable

Checking the entry name in isolation cannot account for how the operating system will interpret the joined path. The filesystem is the authority on where a path points. Any security check that doesn't consult the filesystem's own resolution is working with incomplete information.

Symlinks Complicate Extraction Further

Zip Slip becomes more complex when the archive contains symbolic links rather than regular files.

A symlink is a filesystem object that points to another path. If an archive contains an entry that creates a symlink at extract/link pointing to /etc, and then a second entry that writes a file to extract/link/cron.d/job, the second write follows the symlink. The file ends up at /etc/cron.d/job.

Step 1: Extract symlink
  archive entry "link" → symlink to /etc
  written to /tmp/upload/link → points to /etc

Step 2: Extract file using symlink path
  archive entry "link/cron.d/job"
  resolved: /tmp/upload/link/cron.d/job
  followed: /etc/cron.d/job

Both entries individually may pass a path traversal check. The first creates a symlink inside the extraction directory. The second writes a file to a path inside the extraction directory. But the combination results in a write outside it.

Safe extraction requires either rejecting symlinks from untrusted archives, or resolving intermediate symlinks before checking whether the final destination is inside the intended extraction root.

Where Zip Slip Appears

The vulnerability isn't specific to ZIP. Any archive format that stores filenames with paths can carry the same problem: tar, jar, war, ear, apk, gem. The extraction logic, not the format, determines the exposure.

Web applications that accept archive uploads are the most obvious case. A user uploads a ZIP, the server extracts it, and if the extraction code doesn't validate entry paths, the archive controls where files land.

CI/CD pipelines and build systems unpack artifacts and dependencies regularly. Package managers in several ecosystems have historically been affected. Backup and restore systems often extract with elevated privileges, which increases the reach of any malicious entries. Any automated pipeline that accepts archives from external sources and extracts them programmatically is in scope.

Impact Depends on What the Process Can Reach

Zip Slip enables arbitrary file write within what the extraction process can access. A web application running as a low-privilege user has limited reach. A build pipeline with broader system access might allow overwriting configuration files, startup scripts, or application code. An extraction process running as root can reach anything writable on the filesystem.

The vulnerability enables writing, not reading, and does not by itself provide code execution. But overwriting a configuration file, an application startup script, or a cron job can be a path to execution depending on the system. Whether an existing file can be overwritten also depends on filesystem permissions and other constraints. The impact is contextual.

Zip Slip vs Ordinary Path Traversal

Classic path traversal attacks manipulate URL parameters or form fields to cause a server to read a file outside its intended scope: GET /files?name=../../etc/passwd.

Zip Slip is a path traversal in archive extraction. The traversal string doesn't come from a URL parameter or an HTTP header. It comes from the filename stored inside an archive entry.

The ZIP format itself is not executing anything and is not inherently malicious. The vulnerability is in the extraction logic that treats the archive-controlled filename as a safe basis for constructing a filesystem path. The archive is just the delivery mechanism for a filename the application should not have trusted.

Defenses

Resolve before checking. Compute the canonical absolute path of the destination before writing any file. Verify that it starts with the canonical absolute path of the extraction directory. Reject any entry whose resolved destination falls outside.

Handle symlinks explicitly. Decide whether your extraction logic should allow symlinks at all. If symlinks are necessary, resolve intermediate symlinks during path verification, not just the final path.

Use a well-maintained extraction library. Many languages and ecosystems now have extraction libraries that perform these checks by default. Prefer those over manual path construction.

Do not rely on entry name inspection. Checking whether an entry name "looks safe" is insufficient. The resolution happens at the filesystem level, and the check must happen there too.

Treat extraction as a privilege boundary. If the extraction process runs with elevated privileges, the blast radius of a successful Zip Slip is larger. Run extraction with the minimum necessary permissions.

Test with adversarial archives. A test suite that only extracts well-formed archives will not catch this. Explicitly test with entries containing ../ sequences, absolute paths, null bytes in filenames, and symlinks pointing outside the extraction root.

The Technical Takeaway

Archive filenames are attacker-controlled input. An archive produced by a user, a third-party system, or an external package source defines its own entry names, and those names can contain any string the format allows.

The code that converts those names into filesystem paths is the security boundary. Not the archive format. Not the filename extension. Not a string check on the entry name. The security boundary is the moment the application decides where to write the file, and whether it verified that decision against the filesystem's own resolution before acting on it.

A ZIP file that writes outside its extraction folder is not doing anything the ZIP format prohibits. It is doing exactly what the extraction code allows.

What Is Rowhammer? How Can Repeated Memory Access Flip Bits in RAM?

Aditya Sharma — Mon, 21 Sep 2026 05:12:07 +0000

You are not allowed to modify this memory.

The operating system says no. The CPU's memory protection says no. The page table marks the region as belonging to a different process.

So you don't write to it.

Instead, you repeatedly access the memory next to it. Thousands of times per second. You stay entirely within your own allocated region.

And eventually, a bit in the protected memory changes.

No permission was violated. No buffer was overflowed. No kernel bug was triggered. The hardware did it.

That's Rowhammer.

How DRAM Actually Stores a Bit

To understand why this happens, you need a basic picture of how DRAM works at the physical level.

Each bit in DRAM is stored in a cell that consists of a capacitor and an access transistor. The capacitor holds charge. Charge present represents one binary state; charge absent represents the other. The transistor connects the capacitor to a bitline, a wire that runs through the memory array and is used during read and write operations.

Cells are arranged in a grid. Wordlines run horizontally, connecting the transistors of all cells in a row. Bitlines run vertically. To access a row, the memory controller asserts the wordline, which opens all the transistors in that row simultaneously, connecting every cell's capacitor to its corresponding bitline. Sense amplifiers at the end of each bitline then detect and amplify the tiny charge signal.

         Bitline   Bitline   Bitline
            |         |         |
Row A ──[T]─C─    ──[T]─C─    ──[T]─C─
            |         |         |
Row B ──[T]─C─    ──[T]─C─    ──[T]─C─
            |         |         |
Row C ──[T]─C─    ──[T]─C─    ──[T]─C─

T = access transistor, C = capacitor

This physical arrangement is what makes Rowhammer possible. Rows are physically close to each other. The cells are packed tightly.

What Happens When You Activate a Row

When the memory controller accesses a DRAM row, it activates the entire row: the wordline is asserted, all the transistors open, and the capacitors interact with the bitlines and sense amplifiers. This is not a subtle operation at the hardware level.

From software, you see addresses and bytes. From the hardware perspective:

Virtual Address
       ↓
Page Table
       ↓
Physical Address
       ↓
Memory Controller
       ↓
DRAM Bank and Row
       ↓
Row Activation / Sense Amplifiers

The gap between what software sees and what hardware does is where Rowhammer lives.

The Hammering Mechanism

DRAM cells are densely packed. When a wordline is asserted and a row is activated, the electrical disturbance is not perfectly contained. Neighboring rows can experience small amounts of interference.

In normal usage, this doesn't matter. A row is activated occasionally, and DRAM refresh operations periodically restore charge to cells before they drift too much.

But if an attacker repeatedly activates a row in a tight loop, hundreds of thousands of times per second, the cumulative electrical disturbance in neighboring rows can grow. The capacitors in those adjacent rows get disturbed more than the refresh mechanism expected. In some DRAM chips and configurations, this can cause a bit in a neighboring row to flip from its correct value to the opposite state.

Victim Row
─────────────────────────────────────
    ↑ electrical disturbance
─────────────────────────────────────

Hammer Row A       Hammer Row B
█████████████      █████████████
activate           activate
activate           activate
activate           activate
...                ...

Double-sided hammering, where rows on both sides of the victim row are repeatedly activated, concentrates the disturbance from two directions. This can increase the chance of inducing a flip in a susceptible system compared to hammering one side.

Susceptibility varies. Not every DRAM module experiences this, and behavior depends on the DRAM design, manufacturing process, access pattern, timing, temperature, and what mitigations are present.

Why Software Isolation Doesn't Stop It

This is the counterintuitive part.

The operating system creates an abstraction: each process has a virtual address space, and the page table ensures that accesses to one process's memory don't reach another process's pages. When Process A tries to read Process B's memory, the CPU checks the page table and refuses.

Rowhammer doesn't ask the CPU to access another process's memory. It stays within its own legal pages.

Process A (attacker)

Legal pages
████████████████
       ↓
   repeated activation
       ↓
Physical DRAM disturbance
       ↓
Nearby physical cells
       ↓
████████████████
   Victim memory (different process or OS)
       ↓
possible bit flip

The CPU's page-table permission check is bypassed not because it was defeated, but because the attacker never triggered it. The hardware underneath the abstraction is doing something the abstraction wasn't designed to account for.

From a Bit Flip to a Security Consequence

A random bit flip in an unused region of memory is just data corruption. Annoying, not dangerous.

The security question is whether an attacker can cause a bit to flip in a location that matters: a page table entry, permission bits on a memory page, metadata used by the OS to track ownership, or values the program trusts as authoritative.

Physical disturbance
       ↓
Bit flip
       ↓
Security-sensitive location
       ↓
Corrupted metadata or permission structure
       ↓
Potential isolation violation

For this to go from bit flip to exploit, several things need to align: the flip has to happen in the right location, the attacker needs some ability to influence physical memory placement, the corrupted value has to be security-sensitive, and the system has to act on it before detecting the inconsistency.

This makes Rowhammer exploitation significantly harder than pointing it at a target and waiting. But researchers have demonstrated that, in certain configurations, this chain can be constructed.

Rowhammer vs. Software Memory Corruption

It's worth being precise about the distinction.

A buffer overflow is a software bug. The program writes past the end of a buffer because bounds checking failed or was absent.

A use-after-free is a software lifetime bug. The program accesses memory it no longer owns.

Rowhammer is neither. The attacker performs memory accesses that are within their permissions. No application bug is involved. The disturbance occurs in the physical DRAM subsystem, not in a software buffer.

Buffer overflow:
program writes outside intended bounds (software bug)

Use-after-free:
program accesses freed memory (software bug)

Rowhammer:
program performs legitimate accesses
→ hardware disturbance
→ bit flip in different physical location

This means traditional software mitigations like address-space layout randomization, stack canaries, or safe languages don't address the underlying phenomenon. The vulnerability exists at a layer below them.

Why Mitigations Are Difficult

Several mitigations exist, and each operates at a different layer.

Increased refresh rates. Refreshing DRAM cells more frequently reduces the window during which a cell can drift. This trades power and bandwidth for resilience.

Targeted Row Refresh (TRR). The memory controller or DRAM monitors row activation frequency. When a row crosses a threshold, neighboring rows are proactively refreshed. TRR implementations vary, and some have gaps under certain access patterns.

ECC memory. Error-correcting code memory can detect and correct certain bit errors. For single-bit errors, most ECC schemes can correct the flip transparently. But ECC doesn't prevent the flip from occurring, and multi-bit or unusual error patterns may fall outside what the scheme can correct.

OS-level strategies. Careful physical memory allocation can reduce the chance that attacker pages are physically adjacent to sensitive structures. This changes what a flip can reach but doesn't prevent the underlying disturbance.

No single mitigation addresses all configurations. Rowhammer is partly a hardware problem and partly an architectural one, and the mitigations reflect that.

The Deeper Lesson

Security boundaries in software depend on the layers underneath behaving as expected.

The operating system's isolation model assumes that one process cannot influence another's memory without going through software primitives that the OS controls. That assumption is correct at the software layer.

Rowhammer reveals that the physical implementation of memory can introduce a side channel that crosses that boundary without touching any of the software mechanisms guarding it.

This isn't a failure of the page table, the CPU, or the operating system. It's a reminder that software abstractions are built on physical systems, and those physical systems have their own properties.

The attacker can access Row A.

The victim's data is in Row B.

The attacker cannot write Row B.

But repeated activation of Row A
can disturb nearby DRAM cells.

If a bit in Row B flips,
software observes a state it never intentionally created.

Rowhammer doesn't break the rule that you can't write someone else's memory.

It attacks the hardware underneath the rule.

What Is DOM Clobbering? How Can HTML Elements Change What JavaScript Thinks a Variable Is?

Aditya Sharma — Sun, 20 Sep 2026 06:56:42 +0000

You didn't inject a script tag. You didn't modify any JavaScript. You didn't find a way to execute code directly.

You added an HTML element.

And somewhere in the application's JavaScript, a value that the developer assumed would be their own configuration object suddenly resolved to something else entirely.

No new code ran. The existing JavaScript behaved differently because the environment it ran in had changed.

That's the strange thing about DOM Clobbering. The browser isn't misbehaving. The HTML is valid. JavaScript is doing a perfectly normal property lookup. The problem is an assumption the developer made about what that lookup could return.

What "Clobbering" Actually Means

The DOM (Document Object Model) isn't just a tree of elements you manipulate with JavaScript. It participates in name resolution in ways that aren't always obvious.

Browsers expose certain HTML elements through named properties. When an element has an id, the browser may make it accessible through the window object's named property collection. When certain elements like forms or iframes use name attributes, similar behavior applies.

"Clobbering" describes what happens when attacker-controlled HTML introduces a name that collides with a property the application's JavaScript expects to control.

The application reaches for window.config expecting its own configuration object. But a DOM element with id="config" has been introduced. The lookup resolves to something the developer didn't put there.

DOM Clobbering isn't simply "every id becomes a global." The behavior is more nuanced than that. It depends on the element type, the property being accessed, which object is being queried, and specific browser named-property rules. But when the conditions align, an HTML element can change what a JavaScript name resolves to.

The Browser Behavior Behind It

Browsers expose what the HTML specification calls "named properties" on window and on certain DOM objects. This is a deliberate feature, not a bug. It exists for historical reasons and backward compatibility.

When you access window.someIdentifier, the browser doesn't only look at JavaScript variables you defined. It also checks whether any HTML element with a matching id exists on the page, among other named-property resolution rules.

window.config

Browser checks:
→ JavaScript variable named config?
→ Named property collision with a DOM element?
→ Something else in the named-property chain?

If an attacker can inject HTML into a page, they may be able to introduce an element whose id or name matches something the application's JavaScript relies on.

The browser then has two candidates for what that name means. Depending on the specifics, the DOM-introduced element may win.

Why `id` and `name` Matter Differently

Not all HTML attributes participate equally. Elements with id attributes can be reached through window named properties in many browsers, but the behavior isn't universal across all contexts. Certain elements have additional named-property behavior: forms and iframes are the most commonly relevant. A <form name="something"> creates a named property accessible through document. An iframe with a name attribute can be accessible through window.

This is also why the element type matters, not just the attribute. A <div id="config"> and a <form id="config"> both introduce the same name, but what you can do with the resulting named property differs.

A Concrete Example

Consider an application that initializes itself like this:

const config = window.config;

if (config && config.endpoint) {
    fetch(config.endpoint + "/api/data");
}

The developer expects window.config to be a JavaScript object they defined elsewhere. It has an endpoint property pointing to their API.

Now suppose an attacker can inject HTML into the page before this code runs:

<div id="config"></div>

In browsers where id attributes participate in window named property resolution, window.config no longer necessarily returns the developer's JavaScript object. It may return the DOM element.

Application assumption:
window.config → { endpoint: "https://api.example.com" }

After HTML injection:
window.config → <div id="config"> element
config.endpoint → undefined (or something unexpected)

The fetch doesn't happen. Or it happens with an unexpected value. Depending on what the application does with this, the consequences range from a broken feature to something more significant.

The attacker never touched the JavaScript. They changed what the JavaScript operated on.

Forms, Iframes, and Nested Property Access

With a plain <div id="config">, window.config resolves to the element, and property access like config.endpoint returns undefined. Not always dangerous on its own.

But certain element types allow nested named properties. A <form> element named config with a child <input name="endpoint"> can make config.endpoint resolve to the input element rather than undefined. This happens because form elements expose their named child inputs as named properties.

<form id="config">
    <input name="endpoint" value="...">
</form>

window.config → the form element
window.config.endpoint → the input element

This is why clobbering research often involves structured HTML rather than a single element. The goal is to satisfy the application's property-access pattern, not just the top-level lookup. This doesn't let an attacker construct arbitrary JavaScript objects, but it can produce enough structure to satisfy a conditional check and feed unexpected values into subsequent logic.

Why `document.getElementById()` Is Different

There's an important distinction between implicit named property resolution and explicit DOM queries.

// Implicit - subject to named property resolution
const config = window.config;

// Explicit - clearly queries the DOM
const el = document.getElementById("config");

These look similar but behave differently. document.getElementById("config") is an explicit API call. You get a DOM element, and you know you're getting a DOM element. The code is clearly asking for an element.

window.config is a named property lookup. The developer may intend it to resolve to a JavaScript object they defined. The lookup doesn't make that distinction for you.

DOM Clobbering exploits the gap between the developer's assumption and the browser's actual resolution behavior. Explicit APIs make the intent and the result clearer. They don't prevent you from making other mistakes, but they avoid one specific class of implicit name collision.

DOM Clobbering vs. XSS

These are different mechanisms and shouldn't be conflated.

XSS means attacker-controlled input becomes executable JavaScript. A script runs that the attacker introduced.

DOM Clobbering means attacker-controlled HTML changes the DOM environment in a way that influences existing JavaScript. The attacker's code doesn't execute. The application's own code executes against a different environment than it expected.

The attacker may not be able to run JavaScript at all. Perhaps the application has a strict Content Security Policy that blocks inline scripts and untrusted script sources. DOM Clobbering doesn't require script execution. It requires only the ability to introduce certain HTML.

This makes it a relevant technique in scenarios where traditional script injection is blocked but HTML injection is still possible.

How It Becomes a Security Problem

DOM Clobbering by itself isn't a vulnerability. It becomes one when the clobbered value influences something security-sensitive.

Attacker can influence page HTML
        ↓
Application relies on implicit named property resolution
        ↓
A security-sensitive lookup resolves to attacker-influenced value
        ↓
Application trusts the resolved value without type-checking
        ↓
Unexpected behavior

What matters is what the application does with the unexpected value: URL construction, configuration, resource loading, security checks, application initialization. In code paths that don't touch anything sensitive, the practical impact may be minimal. In code paths that do, the consequences scale with what the clobbered value controls.

Why Frameworks Don't Automatically Solve It

React, Vue, and similar frameworks run inside a browser. Browser semantics don't change because a framework is in use. If application code, or a library the application depends on, performs named property resolution on window or other browser-exposed objects, the underlying behavior still applies. Framework abstraction doesn't change how the browser resolves named properties.

Defenses

Avoid implicit named property resolution for security-sensitive values. Don't assume window.someIdentifier must refer to an application-defined object.

Keep configuration in explicitly controlled scope. A JavaScript module that exports a configuration object is not subject to named property collision in the same way a window-level reference is.

Validate type and structure, not just existence. Checking if (config) tells you the value is truthy. A DOM element is truthy. Verify that the value has the expected type and the properties you actually need before using it in sensitive operations.

Sanitize attacker-controlled HTML. If the application accepts user-supplied HTML, an appropriate sanitizer can strip id and name attributes that could participate in clobbering.

Prefer explicit DOM queries when querying the DOM. document.getElementById("config") clearly asks for an element and returns one. window.config makes an implicit assumption about what that name resolves to.

CSP and Trusted Types address related script-injection risks but don't fix the core issue: an unsafe assumption about named property resolution. The fix is removing that assumption and controlling attacker-influenced HTML at the source.

The Deeper Lesson

Nothing in a DOM Clobbering scenario is technically broken.

The browser exposes named properties exactly as specified. The HTML is valid markup. The DOM is constructed the way browsers construct DOMs. JavaScript performs a normal property lookup and gets back a value.

The problem is a developer assumption: that the lookup can only return what the developer put there.

That assumption is wrong. The DOM is a shared environment. HTML that an attacker introduces participates in that environment. Browser name resolution doesn't distinguish between developer-controlled and attacker-controlled elements.

HTML is not just markup.
HTML creates the DOM.
The DOM participates in browser name resolution.
JavaScript operates in that environment.

When application code assumes a name belongs entirely to the application's own JavaScript, it's assuming something the browser doesn't guarantee.

The attacker didn't change the JavaScript. They changed the environment the JavaScript was running in. The JavaScript did exactly what it was written to do.

What Is a Parser Differential? How Can the Same Input Mean Different Things to Different Systems?

Aditya Sharma — Sat, 19 Sep 2026 14:18:22 +0000

A request arrives at a web application. Before it reaches the application, it passes through a security gateway. The gateway reads the request, checks it for anything suspicious, and decides it is safe. The request continues.

The application receives what looks like the same request. But it interprets one part of it differently from how the gateway did.

The application does something the gateway didn't expect.

No one modified the request between the gateway and the application. The gateway made a correct decision based on how it understood the input. The application made a correct decision based on how it understood the input. Both components behaved exactly as designed.

The problem wasn't that either component was wrong. The problem was that they disagreed.

What Is a Parser Differential?

Every component that handles data has a parser: logic that reads raw input and turns it into structured meaning. Parsers make decisions about where values begin and end, how encoding should be handled, which characters are special, what to do with unexpected input.

Different parsers follow different rules. They may be written by different teams, implement different versions of a specification, or handle edge cases in different ways. That's normal and usually harmless.

It becomes dangerous when two parsers disagree across a security boundary.

A security boundary is the point where one component decides whether input is safe to pass to another component. If the component making that decision parses the input differently from the component that will eventually consume it, the security decision may have been made against a representation that doesn't match what the downstream system will see.

Same Input
    ↓
┌──────────────────┬───────────────────┐
↓                  ↓
Security           Application
Component          Component
↓                  ↓
"Safe"             Different meaning
                   ↓
             Unexpected behavior

The dangerous part: both components receive the same bytes. The disagreement is in how those bytes are interpreted.

Where the Disagreement Comes From

Parsers disagree for several reasons, most of them mundane.

Encoding and decoding. URLs and other data formats can represent characters through encoding schemes, and different components may decode those representations at different stages. A percent-encoded sequence like %2F represents a forward slash. A security filter that inspects the raw encoded form sees %2F as a literal string. An application that decodes before routing sees a /. A path like /safe%2F../admin might look safe to a filter examining the encoded form while resolving to /admin for an application that decodes first.

Path normalization. Paths often contain redundant segments. /../ refers to the parent directory. /a/b/../c is equivalent to /a/c. Components may normalize these differently, or not at all. A security filter that sees /api/v1/../private and treats it as a path to /api/v1/ may be passing something an application resolves differently.

Duplicate parameters. A URL query string can contain the same parameter name twice: ?id=1&id=2. Different frameworks and parsers handle this in different ways: some use the first value, some use the last, some combine them, some reject the request entirely. If a security filter validates one value while the application selects another, the filtered value was never the one that mattered.

Whitespace and delimiters. HTTP headers, content-type values, and structured data fields have rules about how whitespace works. Parsers that are lenient about extra spaces or unusual characters can interpret boundaries differently from stricter parsers, which creates opportunities for one component to see a different field structure than another.

Malformed input. When input doesn't follow the specification, parsers have to decide what to do. Many try to recover rather than reject. Two parsers following different recovery strategies can arrive at very different results from the same malformed bytes.

A Simple Example

Consider a security filter that checks the path in a URL before passing it to an application.

The filter receives:

GET /api/v1/%2e%2e/admin HTTP/1.1

The filter parses the path as /api/v1/%2e%2e/admin. It checks this string against a blocklist. The path starts with /api/v1/, which is an allowed prefix. It passes.

The application receives the same request. But the application decodes percent-encoded characters before routing. It resolves %2e%2e to .., giving it /api/v1/../admin, which normalizes to /admin.

The filter checked one path. The application routed a different one.

Request:  GET /api/v1/%2e%2e/admin

Filter sees:     /api/v1/%2e%2e/admin  → allowed prefix → pass

Application:     /api/v1/%2e%2e/admin
                 decode percent-encoding
                 /api/v1/../admin
                 normalize
                 /admin  → serves protected resource

Neither component made an error by its own rules. The filter correctly identified that the string started with an allowed prefix. The application correctly decoded and normalized the path. The problem is that they were operating on different representations of the same bytes.

Why Security Filters Are Especially Exposed

A WAF, API gateway, reverse proxy, or authentication middleware is in the business of making a decision about input before that input reaches the application. The security decision is meaningful only if the validator and the application agree on what the input means.

When they don't, the validator is effectively checking one thing and the application is processing another. The validation still happened. The check was real. But it wasn't checking the value that actually matters.

This is why "the input was validated" is a weaker guarantee than it sounds. Validated against which representation? Using which normalization rules? Compared to what the application will see?

A security check is only meaningful when it is made against the same interpretation the eventual consumer will use.

Parser Differential vs. Related Problems

HTTP request smuggling is a specific class of parser differential: disagreement between a front-end proxy and a back-end server about where one HTTP request ends and the next begins. Not every parser differential is request smuggling.

Path traversal describes an outcome, not a mechanism. A parser differential in path normalization is one mechanism that can produce it.

Canonicalization issues are directly related. When different components reduce the same input to different standard forms, the result is a parser differential.

Input validation can fail silently here. A validator may be correct about the representation it examined while the application consumes a different one entirely.

Why "Just Validate the Input" Isn't Always Enough

The instinct when hearing about parser differentials is to say "just validate more carefully." But the issue isn't the quality of the validation. It's the sequence.

Raw input
↓
Validator parses and normalizes
↓
Makes security decision
↓
Application re-parses the original input
↓
Interprets it differently
↓
Acts on a representation the validator never examined

The safer model is one where the security decision is made against the same canonical representation the application will consume: the form that results after the relevant decoding, normalization, and transformation steps have already been applied. The goal isn't just "parse before validating" as a rule of thumb. It's ensuring that the security component and the eventual consumer are working from the same interpretation of the input. If they aren't, validation is checking the wrong thing regardless of how carefully it's done.

Raw input
↓
Decode and normalize (same rules the application applies)
↓
Canonical representation
↓
Validate against this
↓
Application consumes the same representation

Where This Appears in Modern Systems

Parser differentials are an architectural problem, not a product-specific one. They appear wherever multiple components process the same input in sequence: reverse proxies inspecting paths before routing, API gateways validating parameters before forwarding, WAF rules applied to raw HTTP before the application framework parses request parameters, authentication middleware checking tokens before handing off to application code.

The more independently those components are developed and configured, the more likely a parsing disagreement exists somewhere. Browser and server interpretation differences are also a real category: security tools that analyze traffic from the browser's perspective can miss what the server actually receives.

Defenses That Actually Follow From the Mechanism

Parse before validating. Make security decisions against the representation the application will use, not an earlier form of the input.

Normalize consistently. If normalization happens, apply it once before validation, using the same rules the application would apply.

Reject ambiguous input. Don't let individual components silently recover from malformed input in different ways. Inconsistent recovery is a common source of parser disagreements.

Minimize parsing layers. Each component that independently parses the same input is another opportunity for disagreement. When security decisions need to be made, fewer intermediate parsers mean fewer chances for interpretation to diverge.

Test across the full path. Testing the WAF in isolation tells you what the WAF thinks about the input. Testing the application in isolation tells you what the application thinks. Neither test tells you how they compare. Security testing should cover the combination.

The Core Insight

A security component can behave perfectly and still miss something, if what it analyzes isn't what the eventual consumer processes.

Input doesn't have a single canonical meaning that every system agrees on. Meaning is assigned by parsers, and parsers differ. The security boundary only protects against what it actually understands.

The most important gap to watch for in a system isn't always between trusted and untrusted input. Sometimes it's between two trusted components that receive the same bytes and arrive at different conclusions about what those bytes say.

What Is eBPF? How Can Linux Safely Run Programs Inside the Kernel?

Aditya Sharma — Fri, 18 Sep 2026 05:11:14 +0000

Linux can take a program written in user space, analyze it, compile it, and run it inside the kernel.

That sentence deserves a second read.

User space and kernel space are supposed to be separated. Kernel code runs with enormous privilege. A bug in kernel code can crash the system, corrupt memory, or break security boundaries in ways that a bug in an ordinary application cannot. The whole point of the user space / kernel space divide is to keep untrusted code far away from that level of the system.

So how is Linux allowing code supplied from outside the kernel to run inside it?

The answer is eBPF, and the interesting part isn't the feature. It's how Linux keeps that boundary from collapsing entirely.

The Boundary That eBPF Crosses

To understand why this is unusual, it helps to be clear about what the boundary normally looks like.

When an application wants to do something privileged, it asks the kernel through a system call. The application doesn't execute inside the kernel. It makes a request, the kernel handles it, and control returns to user space. The separation is deliberate.

User Space
    ↓
System Call
    ↓
Kernel
    ↓
Hardware / Resources

Kernel code itself is trusted by definition. Operating system developers wrote it. It was compiled into the kernel image. It went through code review and extensive testing. When the kernel runs something, it isn't asking permission.

An eBPF program comes from somewhere else entirely. A developer writes it, compiles it to eBPF bytecode, and asks the kernel to load it. That request goes through a very different path than anything the kernel normally trusts.

User Space
    ↓
eBPF Program Submitted
    ↓
Kernel Verifier
    ↓
JIT Compilation
    ↓
Attached to Kernel Hook
    ↓
Executes When Event Fires

The pipeline between "submitted" and "executes" is where the security model lives. Skip any step and the whole thing breaks.

What eBPF Actually Is

eBPF (extended Berkeley Packet Filter, though the name is now largely historical) is a kernel subsystem that allows sandboxed programs to run at specific points inside the Linux kernel. These attachment points include system calls, network events, kernel functions, scheduler events, and more.

The important thing isn't the list. It's the constraint: an eBPF program doesn't execute wherever it wants. The kernel decides where it can attach and what context it receives there. The program runs when that specific event fires, with access to only what that context provides.

That controlled attachment is the first layer of restriction. But it's not the important one.

The Verifier: Where Linux Decides Whether to Trust the Program

Before an eBPF program runs a single instruction, the kernel's verifier analyzes it.

The verifier is a static analysis engine. It reads the eBPF bytecode and analyzes possible execution paths before the program runs, tracking things like register states, pointer types, and memory-access bounds at each point. It doesn't execute the program. It reasons about what the program could do across all reachable paths and determines whether those possibilities satisfy a defined set of safety constraints.

This includes:

Control flow. The verifier checks that execution can't jump to arbitrary instructions, that every path terminates, and that the program doesn't loop indefinitely. eBPF programs must have bounded execution.

Memory access. The verifier tracks what each register holds at every point. It knows whether a register contains a valid pointer, what kind, what memory region it addresses, and what bounds apply. If the program tries to dereference a pointer the verifier can't confirm is in-bounds, the program is rejected.

Pointer types. A pointer into an eBPF map has different rules from a pointer to packet data. The verifier enforces these distinctions. A program can't take an arbitrary integer, cast it to a pointer, and dereference it.

Helper calls. eBPF programs can't call arbitrary kernel functions. Only a defined set of helper functions per program type is allowed. The verifier checks every call.

To make pointer tracking concrete: a networking program might load with a register pointing to packet data and another holding the packet length. The verifier asks whether every memory access using that pointer stays within the available data on every possible execution path. If it can't establish that, the program is rejected before it runs.

r1 → pointer to packet data
r2 → packet length

        ↓

Verifier asks:

Is r1 a valid pointer to packet data?
Is this offset within bounds for all code paths?
Can this access become invalid on any reachable path?

        ↓

All constraints satisfied → accepted
Any constraint fails → rejected

The security model isn't "trust the developer." It's closer to: "the program must satisfy a defined set of safety constraints before it touches the kernel."

Helpers: A Controlled Interface Into the Kernel

Instead of letting eBPF programs call arbitrary kernel functions, the kernel exposes a set of approved helper functions for each program type.

A networking eBPF program might have helpers for reading packet data, modifying it, or redirecting it. A tracing program might have helpers for recording events. All of these are controlled interfaces. The eBPF program can't reach past them into arbitrary kernel internals.

eBPF Program
     ↓
Helper Function
     ↓
Kernel-managed operation

Helpers are defined per program type. A networking hook doesn't get the helpers meant for a tracing hook. The scope is intentionally narrow.

Maps: Shared State Between Kernel and User Space

eBPF programs use maps: structured key-value stores accessible by both the in-kernel eBPF program and user-space applications. This is how security monitors and observability tools get data out of kernel-attached programs without needing a persistent kernel connection. The program writes events into the map; user space reads them.

JIT Compilation: Performance, Not Security

Once verified, the kernel can JIT-compile the eBPF bytecode into native machine instructions. This matters because eBPF programs can run in extremely performance-sensitive paths like network packet processing.

JIT compilation is not the security step. The verifier is. By the time JIT runs, the kernel has already decided the program is acceptable. Compilation is an optimization, not a trust decision.

eBPF vs. Kernel Modules

A kernel module is the traditional way to extend the kernel. A loaded module executes with kernel privileges and can interact directly with kernel APIs and memory, giving it a much broader capability set than a verified eBPF program. Kernel modules are powerful, but the trust model is simple: you either trust the module completely or you don't load it.

eBPF operates differently. The kernel doesn't trust the submitted program. It verifies it. The program executes in a restricted environment with controlled helpers, bounded execution, and verified memory access. The restriction is the point.

This doesn't mean eBPF programs are less capable at the specific things they're designed to do. It means the capability they have is defined and constrained rather than open-ended.

eBPF As a Security Tool (And a Security Boundary)

Security teams use eBPF because it can observe the system at a layer that application-level logging can't reach. A system-call monitoring tool built with eBPF can attach to kernel instrumentation points and observe system-call activity across processes, with coverage determined by the attachment points used and the permissions the tool holds. That kind of visibility is genuinely difficult to achieve from user space.

The flip side: because eBPF operates inside the kernel, vulnerabilities in the verifier, JIT compiler, or helper implementations are kernel-level vulnerabilities. Bugs in the verifier have historically allowed privilege escalation. The security benefit comes with a significant responsibility: the components that implement eBPF's safety model are themselves security-critical.

"eBPF has a verifier" and "eBPF can never have security vulnerabilities" are not the same statement.

Who Can Load eBPF Programs?

Not everyone. Loading eBPF programs requires appropriate Linux capabilities, and the specific requirements depend on the program type, kernel version, and system configuration. The security model isn't just the verifier: it's capability controls plus verification plus restricted execution plus controlled helpers, all together. Removing any layer changes the security properties.

The Answer to the Original Question

How can Linux allow a program supplied from user space to execute inside the kernel without simply giving that program unrestricted access?

By making the boundary programmable but not removing it.

The kernel doesn't simply trust the submitted program. It analyzes the bytecode and requires it to satisfy a set of safety constraints before allowing it to execute anywhere near kernel memory. The verifier enforces those constraints. The helper interface constrains what the program can do even after verification. The attachment model constrains where it runs. Capability requirements constrain who can load it.

What eBPF offers isn't unrestricted kernel access dressed up with a safety label. It's a constrained execution model where the kernel decides what "safe enough for kernel execution" means, and then enforces that definition before a single instruction runs.

The boundary still exists. eBPF just made it programmable.

What Is Subdomain Takeover? How Can an Abandoned Subdomain Become Dangerous?

Aditya Sharma — Thu, 17 Sep 2026 05:12:22 +0000

A company owns company.com. That much is clear. Their registrar shows it. Their DNS is configured by them. Nobody disputes it.

But one of their subdomains, blog.company.com, starts serving content the company didn't put there.

The company didn't lose their domain. The DNS record is still theirs. So what happened?

Two Different Things Called "Ownership"

When an organization creates a subdomain like blog.company.com, they control the DNS record for it. That record typically points somewhere: a cloud hosting platform, a SaaS documentation tool, a CDN distribution, a third-party service.

Here's the part that trips people up: controlling the DNS record and controlling the resource it points to are not the same thing.

The DNS record says: "When you ask for blog.company.com, go here."

But "here" is often infrastructure owned and operated by an external provider. The organization doesn't own that infrastructure. They have a project or account on it.

company.com (organization owns this)
    ↓
blog.company.com DNS record (organization controls this)
    ↓
CNAME → company-blog.hosting-platform.example
    ↓
Hosted resource (external provider owns and manages this)

That separation is normal and useful. The issue appears when one side of that relationship goes away.

What a Dangling DNS Record Is

Organizations create infrastructure constantly: marketing pages, documentation sites, staging environments, developer tools, short-lived campaign sites. Resources get provisioned and later deleted. Teams change. Projects wind down.

When an external resource is deleted, the DNS record that pointed to it often doesn't get cleaned up. Nobody removes it because nobody thinks to. The original team moved on. The infrastructure list wasn't updated.

The DNS record still exists. It still points to where the resource used to be. But the resource itself is gone.

This is a dangling DNS record: a valid hostname pointing to an external destination where the referenced resource no longer exists.

A dangling record by itself isn't necessarily dangerous. The next question is whether that vacancy can be filled by someone else.

When It Becomes a Takeover

Some external providers allow new users to claim a resource at the same identifier that a previous account used. This is often by design. Platforms need to recycle project names, subdomains, or endpoints so they can be reused.

If that's possible, an attacker can do the following:

Find a subdomain that still points to an external platform.
Discover that the resource on that platform is no longer active.
Create a new account on that platform and claim the same identifier.
The organization's DNS record now points to the attacker's resource.

User visits blog.company.com
       ↓
DNS resolves via CNAME
       ↓
Hosting platform
       ↓
Attacker's claimed resource
       ↓
Attacker-controlled content served under company's subdomain

The attacker didn't touch company.com. They didn't modify the DNS record. They simply occupied a vacancy that the DNS record kept pointing at.

Why That Subdomain Context Matters

Content served under blog.company.com inherits the visual and reputational context of the organization. A visitor navigating there sees the company's domain in the address bar. It looks legitimate. The TLS certificate may resolve without errors because it's issued for a valid hostname.

Depending on what the subdomain was previously used for and how the organization's other applications are configured, consequences can range from reputational damage and phishing risk to more significant issues in some architectures.

That said, the exact impact isn't fixed. It depends on what the subdomain was used for, how cookies are scoped, whether other services trust that hostname, and what the attacker actually does with it. Subdomain takeover doesn't automatically break session security or compromise parent domain applications. But serving attacker-controlled content under a trusted hostname is still a meaningful security failure.

The Ownership Boundary Is the Core Idea

It's worth being precise here because the setup is counterintuitive.

The organization did not lose its domain. company.com is still registered in their name. Their DNS is still under their control. Nothing was stolen.

What happened is that DNS ownership and resource ownership have separate lifecycles, and only one of them was maintained.

Who controls company.com?
    → The organization.

Who controls the DNS record for blog.company.com?
    → The organization.

Who controls the resource that record points to?
    → The external provider manages the platform.
      The organization controlled a resource on it.
      That resource no longer exists.
      The provider may allow someone else to claim it.

The organization's authority stops at the DNS record. It doesn't extend into the external provider's resource namespace. When the resource was deleted, that external slot opened up.

How This Differs From Similar Problems

DNS rebinding works differently. It involves changing DNS resolution over time, causing a client to connect to a different IP address than it resolved initially. The manipulation happens through DNS TTL and timing. Subdomain takeover is a static configuration problem, not a dynamic resolution problem.

Domain hijacking is about unauthorized control of the domain registration itself or the DNS authority. The attacker gains the ability to change DNS records for the domain. In a subdomain takeover, the organization retains full control of their DNS. The attacker never touches it.

Dangling DNS is the underlying condition. Subdomain takeover is the security consequence when an attacker can claim the external resource that the dangling record points to.

Defenses That Follow From the Mechanism

Because the problem is a configuration drift between DNS records and external resources, the defenses are about keeping those two things synchronized.

Remove DNS records when external resources are deleted. This is the most direct fix. When a project is decommissioned, the DNS record should be decommissioned with it. The challenge is that this requires DNS and infrastructure changes to be coordinated rather than handled by separate teams independently.

Inventory subdomains and track what they point to. Many organizations don't have a clear map of which subdomains exist and which external services they depend on. Without that visibility, stale records are easy to miss.

Include DNS in infrastructure lifecycle processes. Provisioning a new resource and creating a DNS record should be a paired operation. Deleting a resource and removing its DNS record should be equally paired.

Monitor for dangling references. Organizations can periodically verify that DNS records resolve to resources they still control. A record that points to an unclaimed external resource is a signal worth acting on.

Monitoring catches drift, but the more fundamental fix is keeping DNS and external resource lifecycles synchronized from the start.

The Mental Model

A domain name is an address. An address tells you where to go. It doesn't say anything about who currently controls the destination.

When an organization creates a subdomain that points to an external service, they're establishing a relationship between a hostname they own and a resource they control on someone else's infrastructure. Both sides of that relationship need to stay maintained.

If the external resource is deleted and the DNS record isn't, the address still exists. The destination is just vacant. And in some cases, vacant can be claimed.

The company still owns the domain. The DNS record is still valid. The problem is what that record has been pointing to.

A hostname can continue looking legitimate long after the infrastructure behind it changed hands.

What Is a Confused Deputy? How Can a Trusted Program Be Tricked Into Using Its Own Permissions?

Aditya Sharma — Wed, 16 Sep 2026 07:00:27 +0000

You don't have access to the file. The rules are clear about that. Your account can't read it.

But there's a service running on the same system that can. It's trusted. It has elevated permissions. And it accepts requests.

So instead of reading the file yourself, you ask the service to read it for you.

The service checks whether it can access the file. It can. So it does.

You just read something you weren't allowed to read. And the service did exactly what it was designed to do.

What Just Happened

The attacker didn't steal any permissions. Nothing was compromised. No vulnerability was exploited in the traditional sense.

What happened is simpler and, in a way, more interesting: a trusted component used its own authority to fulfill a request that the caller wasn't authorized to make.

The deputy didn't get hacked. The deputy got confused.

In security terms, a deputy is a component that acts on behalf of others. A file service, a cloud function, a privileged API, a system daemon. These components often hold more authority than their callers, because they perform operations users can't or shouldn't perform directly.

A deputy becomes confused when it can't distinguish between what it is allowed to do and what the caller is allowed to ask it to do. It applies its own authority when it should be applying the caller's.

Those are two very different things.

The Central Problem: Two Separate Authority Questions

When a caller sends a request to a privileged service, there are two questions the service needs to answer:

What can I (the service) access?

What is this caller allowed to access through me?

A secure design answers the second question. A confused deputy only answers the first.

Caller: "Give me resource X"
         ↓
Trusted service
         ↓
"Can I access resource X?" → Yes
         ↓
Returns resource X

The service validates its own authority. It never validates the caller's authority. So the caller's permissions are irrelevant. Whatever the service can access, the caller can access through it.

The correct version of that flow looks different:

Caller: "Give me resource X"
         ↓
Trusted service
         ↓
"Is this caller allowed to access resource X?" → ?
         ↓
Allow or deny based on that answer

The service's own permissions are a prerequisite for performing the operation. They are not authorization for the caller to request it.

Why This Happens in Real Systems

Confused deputy problems appear naturally in systems that delegate work.

Delegation is useful. A privileged service often needs broader permissions than individual users because it operates across many users' contexts. A file processing service needs to read many files. A cloud function needs to call many downstream APIs. A logging daemon needs write access to system directories.

The architecture isn't the problem. The problem is the security question that gets lost inside it.

When a service acts on behalf of a user, whose authority should govern what the service is allowed to do? The service's authority tells you what it is technically capable of. It says nothing about what this particular caller is entitled to cause.

If the service never asks the second question, its entire permission set becomes accessible to anyone who can send it a request.

The Same Pattern in Cloud Systems

This isn't a problem specific to operating systems or classic privileged programs. The same structure appears constantly in modern cloud architectures.

A user can call Service A. Service A has an IAM role that allows it to access storage buckets, query databases, invoke other services. The role exists because Service A legitimately needs those permissions to function.

If Service A accepts an arbitrary resource identifier from the user and blindly uses its IAM role to access whatever was requested, the user can reach anything Service A can reach:

User (limited permissions)
     ↓
Service A
     ↓
Service A's IAM role (broader permissions)
     ↓
Resource the user couldn't access directly

The IAM role isn't the problem. The role is doing exactly what IAM roles are supposed to do. The problem is that Service A treats its own IAM authority as authorization for any caller, rather than enforcing what each caller is actually entitled to request.

How This Differs From Similar Vulnerabilities

It's worth being precise here, because confused deputy gets conflated with a few other patterns.

SSRF is about influencing where a server makes a network request. The attacker's goal is often to reach internal infrastructure. A confused deputy is a different question: the attacker isn't just redirecting a request, they're causing a trusted component to apply its own authority on their behalf. There can be overlap in real systems, but the underlying mechanism is distinct.

IDOR is about accessing an object through a predictable identifier that isn't properly access-controlled. The resource is exposed directly. A confused deputy involves an intermediary that holds the authority, not a directly accessible resource.

Privilege escalation is a broad category. Confused deputy can lead to unauthorized access, but the mechanism isn't about exploiting a flaw to gain new permissions. The deputy already has the permissions. The problem is that it applies them without checking whether the caller deserves the result.

Defenses That Follow From the Mechanism

Because the core issue is authority confusion, the defenses are about making the authority distinction explicit.

Enforce authorization at the right boundary. The service must evaluate whether the caller is allowed to perform the requested operation, not just whether the service itself can perform it. These are different checks and both are required.

Carry caller context through delegation chains. When a service acts on behalf of a user, the user's identity and permissions need to be part of the authorization decision, not discarded at the service boundary. A request that passes through multiple layers should not lose track of whose request it originally was.

Constrain what callers can request. A service that can access a hundred resources doesn't need to expose all of them to every caller. Scope the operations each caller can invoke rather than exposing the service's full capability set.

Apply least privilege to the service itself. A service should only hold the permissions it actually needs. This doesn't eliminate confused deputy problems, but it limits what an attacker can access if the deputy does get confused.

None of these individually close every confused deputy scenario. The fundamental requirement is that authorization decisions account for the caller's authority, not just the deputy's.

The Core Insight

The intuitive assumption is that a trusted component is safe because it's trusted. Its permissions are legitimate. Its operations are intentional.

But trust in a component is not the same as trust in every request that component receives. A service can be completely legitimate and still be the mechanism through which unauthorized access happens. It doesn't need to be compromised. It just needs to fail at one question.

The most important mental model from this article:

What the deputy can do and what the caller can cause the deputy to do are two separate things. A confused deputy forgets the difference.