Category: Deep Dives

A BadUSB attack starts with a device that lies about what it is. It looks like an ordinary flash drive, but the tiny controller chip inside has been reprogrammed to tell your computer it is a keyboard. The moment you plug it in, it starts typing commands on its own, far faster than any person could, and the machine obeys because keyboards are trusted by design. There is no virus file to find, because the trick is not a file at all. It is the device claiming an identity it should never have.

What does HID mean, and why does your computer trust keyboards?

HID stands for Human Interface Device. It is the standard category the USB specification uses for the things a person operates directly: keyboards, mice, game controllers, and similar input hardware. When you plug one in, the device introduces itself with a small description of what it is and what it can send. Your operating system reads that description, sees the word keyboard, and loads a generic driver that is already built into the system. No installation, no prompt, no scan. You expect a keyboard to send keystrokes, so a keyboard is allowed to send keystrokes the instant it arrives.

That trust is deliberate and it is also the whole problem. A keyboard is the one peripheral that is assumed to speak for the human sitting at the desk. Whatever it types, the computer treats as your intent. There is no meaningful check on whether a keyboard is real, whether a human is actually pressing keys, or whether the typing speed makes any sense for a person. The identity a USB device announces is taken at face value, and the identity is exactly what a BadUSB attack forges.

How a BadUSB attack forges an identity at the firmware level

Every USB device runs a small piece of software of its own, called firmware, on its controller chip. That firmware decides the descriptor the device shows the host: this is a mass storage device, or this is a keyboard, or both. On many cheap controllers that firmware can be rewritten. Once it is rewritten, the same physical stick that used to say flash drive can instead say keyboard, and it will hold that story every time it is plugged into any machine.

Picture a made up example. An attacker leaves a plain looking USB stick in the parking lot of an office we will call Acme. A curious employee finds it, plugs it into a work laptop to see who it belongs to, and expects a folder of files. Instead the stick has been reprogrammed. Its firmware announces a keyboard, the laptop loads the trusted keyboard driver without asking, and the device fires off a short burst of keystrokes it had stored on board. To the laptop, a person just sat down and typed very quickly. Nothing about the traffic looks wrong, because as far as the operating system knows, a keyboard did what keyboards do.

There is no malware to scan for. The attack is the device claiming to be a keyboard, and your computer has no habit of doubting a keyboard.

Why antivirus does not see it

Antivirus works by inspecting files and processes for known bad patterns. A BadUSB attack hands it nothing to inspect. The malicious part lives in the device firmware, not on disk, and the firmware never copies a suspect file onto your machine. What reaches the computer is a stream of keystrokes, which is the most normal input a computer can receive. You cannot quarantine a key press. You cannot flag a keyboard as malware without flagging every keyboard.

This is why the defense cannot be a scanner. The failure is a trust decision made before any file exists: the decision to believe a device’s claim about its own identity. Fixing it means changing who is allowed to become a trusted keyboard, and under what conditions, rather than hunting for something to delete.

How is this different from juice jacking?

It is easy to lump every USB threat together, but these are two different problems and the fix for one does not fix the other. Juice jacking is about a charging port or cable that carries data as well as power, so a public charging station could try to pull files off your phone or push something onto it while it charges. It abuses the fact that one USB connector moves both power and data. We cover that risk on its own in juice jacking explained.

A BadUSB attack is not about power or file transfer. It is about identity. The device is not reading your data or sneaking a file across, it is pretending to be a class of hardware your computer trusts and then acting as that hardware. One is a data over power problem. The other is an identity problem. A data blocker that strips the data pins can help against juice jacking, but a device you deliberately plug in as a keyboard still gets to be a keyboard.

How do you defend against it?

• Never plug in a device you did not buy. A found stick, a giveaway drive, a cable of unknown origin. The single most reliable defense is refusing the physical introduction in the first place.
• Use USB device control and allowlisting. Tools such as USBGuard on Linux let you approve devices by their properties and block everything else by default, so a brand new keyboard appearing out of nowhere is refused rather than trusted.
• Require confirmation before a new keyboard is trusted. A policy where a freshly connected input device has to be approved by the person at the machine removes the whole point of a device that types the instant it is plugged in.
• Disable unused USB ports or fit port blockers. If a port does not need to accept input hardware, close it. Fewer open ports means fewer places a forged keyboard can introduce itself.
• Lock your screen and use short timeouts. A device that types into a locked machine reaches almost nothing. Short idle timeouts shrink the window in which a burst of typed commands can land on a desktop left open.
• Treat trust as physical, not just digital. The same mindset that governs an evil maid attack applies here: once someone can touch your hardware, software controls alone are not enough.

Peripherals earn trust by claiming an identity, and that claim is rarely checked. The same theme runs through how Bluetooth LE pairing breaks, where a trusted wireless channel can be set up more loosely than people assume. The lesson under all of it is one worth carrying into software too: an identity a system merely announces is not the same as an identity a system has verified. That gap between assumed trust and proven trust is exactly the kind of assumption we care about testing, and you can read more about how we think on our about page.

Frequently asked questions

What is a BadUSB attack?

It is an attack where the firmware inside a USB device is reprogrammed so the device lies about what it is. A stick that looks like a flash drive tells your computer it is a keyboard, and the moment you plug it in it types a burst of commands the computer trusts, because keyboards are trusted by design.

What does HID mean and why does it matter here?

HID stands for Human Interface Device, the USB category for input hardware like keyboards and mice. Your operating system loads a built in driver for a keyboard automatically and lets it send keystrokes right away. A BadUSB attack abuses that trust by announcing itself as a keyboard when it is really something else.

Why does antivirus not catch a BadUSB attack?

Because there is no malicious file to scan. The trick lives in the device firmware, and what reaches your computer is a stream of keystrokes, which is the most normal input a machine can receive. You cannot flag a keyboard as malware without flagging every keyboard, so the defense has to be about controlling which devices are trusted, not scanning for files.

How is a BadUSB attack different from juice jacking?

Juice jacking is about a charging port or cable that moves data as well as power, so it might read or plant files while your phone charges. A BadUSB attack is not about power or file transfer at all. It is an identity problem, where the device pretends to be a class of hardware the computer trusts and then acts as that hardware.

How do you defend against a BadUSB attack?

Never plug in a device you did not buy, especially a found or giveaway stick. Use USB device control and allowlisting such as USBGuard, require confirmation before a new input device is trusted, disable unused ports or fit port blockers, and keep your screen locked with short idle timeouts so typed commands reach almost nothing.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.

A DMA attack abuses Direct Memory Access, the feature that lets some peripherals read and write system RAM directly, without asking the CPU for each byte, because that is faster. A malicious device plugged into a Thunderbolt or PCIe port can ride that same channel to read and write memory behind the operating system’s back. It can scrape secrets straight out of RAM, or patch the code that checks the lock screen, while the machine sits locked on a desk. The login prompt never mattered here, because the attack never went near the keyboard.

What is Direct Memory Access and why does it exist?

Moving data through the CPU is slow. If a disk controller, a network card, or a graphics card had to interrupt the processor for every chunk of data it copied, the processor would spend most of its time shuffling bytes instead of running programs. Direct Memory Access solves that. The device is handed the ability to talk to main memory on its own, so it reads and writes RAM while the CPU gets on with other work. When the transfer finishes, the device raises one interrupt to say it is done.

This is a deliberate design and a good one. A high speed capture card writing video frames, or a network card receiving packets, needs to place data in memory fast. The point to remember is what the feature grants: a device that can do DMA is trusted to reach into system memory directly. On a machine that hands out that trust freely, the port becomes a door into RAM.

How a DMA attack turns a plugged in device into a memory reader

Thunderbolt is the part that surprises people. A Thunderbolt port is not only a data port. It carries PCI Express, the internal bus that expansion cards sit on, out to a socket on the side of the laptop. A device on that bus is treated much like a card installed inside the case, which means it can be granted the same DMA rights an internal card has.

So the attacker does not need to break a password. They build or buy a small device that presents itself as a normal peripheral, plug it into the exposed port, and ask the bus for memory. If nothing restricts the request, the device reads whatever addresses it likes.

With direct reach into RAM, two moves open up:

• Read secrets out of memory. Disk encryption keys, session tokens, cached passwords, and private data all live in RAM while the machine is on. A device that can read arbitrary memory can copy them out, even though the screen is locked.
• Write memory to change behavior. The routine that decides whether your password is correct is just bytes in RAM. Overwrite the check so it always returns success, and the lock screen accepts anything you type.

The lock screen is a question the operating system asks itself in memory. A device that can rewrite that memory gets to answer the question for it.

A locked laptop on an open desk

Picture an invented machine, the Acme laptop, left locked on a desk while its owner steps away for coffee. The screen shows a password prompt. Everything looks safe. But a Thunderbolt port on the side is open and active.

An attacker walks up, plugs a prepared device into that port, and the device requests a sweep of system memory. Because the machine grants DMA to the device without restriction, the request succeeds. In one path the attacker copies the region holding the disk encryption key and walks away with it. In another the attacker locates the password check and patches it in place, then types any password and is let in. The owner returns to a laptop that looks exactly as they left it. Nothing was typed at the prompt, and no keyboard log would show a thing, because the keyboard was never used.

This is close in spirit to the evil maid attack, where brief physical access to an unattended machine is enough to tamper with it. It also overlaps with the cold boot attack, another route to reading secrets out of memory, though that one chills and reboots the RAM rather than riding a live bus.

Why the login prompt was never the barrier

It helps to compare this with a threat that looks similar and is not. In juice jacking, a hostile charging port pushes power and data over USB and tries to trick the operating system into mounting the device or accepting a payload. That attack still goes through the software stack. It knocks on the front door.

A DMA attack skips the door. It does not send input the operating system will read and validate. It reaches under the operating system and touches memory directly, so the checks that guard the login path are never consulted. That is why a strong password does not help here on its own. The password matters only if something forces the attacker’s device to go through the code that checks it, and raw DMA does not.

How do you defend against it?

The fix is to stop trusting a plugged in device with unrestricted memory, and to time that distrust for the moment the machine is most exposed.

• Turn on the IOMMU. The IOMMU, called Intel VT-d on Intel platforms and given an equivalent name by AMD, sits between devices and memory and translates the addresses a device may use. With it configured, a device sees only the small window it was assigned, not all of RAM. It is the single most important control here, so confirm it is enabled in firmware and used by the operating system.
• Enable Kernel DMA Protection. On modern systems this feature blocks DMA from Thunderbolt and similar ports until a user has logged in, and keeps blocking newly attached devices while the screen is locked. That closes the exact window in the Acme example, the locked and unattended desk.
• Set Thunderbolt security levels and require approval. Thunderbolt can be told to require a human to approve each new device before it is granted access, rather than trusting anything inserted. Set the security level so an unknown device gets nothing until someone says yes.
• Deny DMA before login and while locked. The dangerous moments are the ones with no user present: before boot finishes and whenever the machine is locked. Configure the system so external DMA is refused in both states, and only allowed once an authenticated user is active.
• Disable ports you do not use. If a laptop never needs Thunderbolt or an external PCIe path, turn it off in firmware. A port that grants no access is not a door at all.

The theme across all of these is the same. Speed features are safe until they are handed to an untrusted device at an unguarded moment, and the defense is to narrow both what a device can reach and when it is trusted at all.

This class of problem is about an assumption the machine makes, that a device on the bus is allowed in memory, rather than about a malformed input. That is the kind of hidden assumption an autonomous researcher built to test assumptions, rather than to match known payloads, is meant to probe. You can read more about how we think about that on our about page.

Frequently asked questions

What is a DMA attack?

It is an attack that abuses Direct Memory Access, the feature that lets some peripherals read and write system RAM directly without going through the CPU. A malicious device plugged into a Thunderbolt or PCIe port uses that channel to read secrets out of memory or to patch the lock screen check, all while the machine sits locked.

Can a DMA attack work while my laptop is locked?

Yes. That is the point of it. The attack reaches memory directly and never sends input through the login path, so the lock screen is not consulted. A device with unrestricted DMA can copy encryption keys out of RAM or overwrite the password check even though the screen shows a locked prompt.

Why is Thunderbolt a risk when USB feels safe?

A Thunderbolt port carries PCI Express out to the side of the machine, so a device on it is treated much like an expansion card inside the case and can be granted the same direct memory rights. Threats like juice jacking still go through the software stack over USB, while a DMA attack goes under the operating system entirely.

How do I defend against a DMA attack?

Enable the IOMMU so a device sees only the memory window it was assigned, turn on Kernel DMA Protection so external ports are blocked before login and while locked, set Thunderbolt to require approval for each new device, and disable ports you never use. The goal is to narrow both what a device can reach and when it is trusted at all.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.

A cold boot attack recovers secrets from a computer’s memory after the power is cut, using a physical fact that surprises most people: RAM does not forget instantly. For a short window the bits stay readable, and the most valuable of them is the disk encryption key that a running system keeps in memory so it can work. An attacker with the machine in hand cuts power, boots a tiny program that reads memory back out, and walks away with the key that was supposed to protect an encrypted drive.

What a cold boot attack actually exploits

Dynamic RAM stores each bit as a charge in a tiny capacitor. Those capacitors leak, so the chip refreshes every cell many times a second to hold the value. When you remove power the refresh stops, but the charge does not vanish. It drains over a period that ranges from a fraction of a second to several seconds at room temperature, and the pattern of bits stays mostly intact for that whole time. This slow fade is called DRAM remanence, and it is the gap the attack lives in.

The trick that makes the window longer is temperature. Cold capacitors leak slower. If you chill the memory chips with a can of compressed air held upside down, or colder still, the contents can survive for minutes instead of seconds, long enough to move the chips into another machine and read them there at leisure. That chilling step is where the name comes from.

A locked laptop that is only asleep is holding its own decryption key in a place an attacker can read.

Why the disk key sits in RAM in the first place

Full disk encryption protects data at rest. When the machine is off, the drive is a block of ciphertext and the key is derived from your passphrase or unwrapped by the TPM at boot. But once the system is running it needs to read and write files constantly, and it cannot ask you for the passphrase on every block. So it keeps the master key, or a key derived from it, resident in RAM for the whole session. That is not a bug. It is how the drive stays usable in real time.

The consequence is the whole point of the attack. A machine that is powered on, even locked, even suspended to RAM, is a machine whose decryption key is loaded and waiting. Sleep does not clear it. The lock screen only blocks the keyboard and mouse; it does nothing to the contents of memory. So the security of an encrypted disk quietly depends on the state the laptop was left in, not just on the strength of the passphrase.

An example: the Acme laptop left suspended

Picture a work laptop from an invented company, Acme. An employee closes the lid at an airport gate and the machine suspends to RAM. The drive is encrypted, the login screen is up, and the employee assumes the data is safe because the disk is locked. Someone takes the laptop. Instead of guessing the passphrase, the attacker cuts power, then immediately powers the machine back on into a small purpose built program loaded from USB. That program does one job: copy the raw contents of memory to an external drive. Somewhere in that dump, in a predictable structure, is the disk key. The encryption did its job perfectly and still lost, because the key was sitting in RAM the entire time the lid was closed.

How the key is found in a memory dump

A raw memory image is a large, messy blob, but disk encryption keys are not hidden in it well. Cipher key schedules have a recognisable structure, so an attacker scans the dump for byte patterns that match an expanded key and confirms candidates by trying to decrypt a known block. Because remanence is not perfect, some bits in the dump will have decayed to their ground state. Key finding tools account for this by correcting a handful of flipped bits until a valid key falls out. The upshot is that even a partly faded image is often enough.

The defenses that close the window

There is no single switch that removes the risk, but several measures each shrink it, and together they close most of the gap. The right mix depends on how exposed the machine is.

• Shut down instead of sleeping in high risk situations. A full power off gives the memory time to fade and lets the system clear keys on the way out. If a laptop crosses a border or is left unattended, shut it down rather than suspending it. Hibernation writes state to the encrypted disk and powers off, which is safer than suspend to RAM as long as the hibernation image lands on the encrypted volume.
• Scrub keys on shutdown and reboot. The operating system can overwrite key material with zeroes as it powers down, so a dump taken a moment later finds nothing useful. Wiping memory early in the boot sequence closes the reboot into a tiny program path, because the attacker’s tool arrives to find the secrets already gone.
• Keep keys out of plain RAM. Some designs hold the key in CPU registers or on chip cache rather than main memory, or seal it in the TPM and release it only under strict conditions. A key that never sits in DRAM cannot be read out of DRAM.
• Use hardware memory encryption. Modern platforms can encrypt the contents of RAM with a key held inside the memory controller. A dump of the chips then yields ciphertext, and moving the chips to another machine yields noise, because the decrypting key never leaves the processor package.
• Refuse to boot untrusted code. Boot protections that check the loader before running it stop the classic reboot into a rogue memory dumper. See how secure boot works for the mechanism that verifies each stage before handing over control.

Where this sits among physical access attacks

A cold boot attack needs the attacker to hold the machine, which places it in the same family as the evil maid attack, the umbrella for threats that assume brief physical access to a device you left behind. It is a close relative of the DMA attack over Thunderbolt, which reaches the same target, the contents of RAM, but through a fast peripheral port instead of by pulling power. Encrypting the data on the disk is not the finish line; the memory of a running machine is a second copy of your secrets, and it is far softer.

The common thread across all three is that a defense which looks complete on paper can leave a live copy of the very thing it protects sitting in an easier place. That gap, between what a system claims to secure and what it actually leaves exposed, is exactly the kind of assumption an autonomous researcher built to test assumptions is meant to probe. More about how we think about that on our about page.

Frequently asked questions

What is a cold boot attack?

It is a physical attack that reads secrets out of a computer’s RAM after the power is cut. Because memory chips hold their contents for a short window rather than clearing instantly, an attacker can reboot into a small program, or move the chips to another machine, and dump memory to recover the disk encryption key the running system kept there.

Why does data stay in RAM after the power is off?

Dynamic RAM stores each bit as a charge that leaks slowly once the chip stops refreshing it. At room temperature the bits fade over a period from a fraction of a second up to several seconds, and chilling the chips stretches that window to minutes. This slow fade is called DRAM remanence.

Does full disk encryption stop a cold boot attack?

Not on its own. A running system keeps the disk key resident in RAM so it can read and write files, so a machine that is powered on, locked, or asleep is holding its own key in memory. The encryption protects the drive at rest, but the key in RAM is a second copy an attacker can read.

How do you defend against a cold boot attack?

Shut the machine down fully instead of sleeping in high risk situations, scrub keys to zero on shutdown and early in boot, keep keys in CPU registers or the TPM rather than plain RAM, use hardware memory encryption where the platform supports it, and enable boot protections that refuse to run untrusted code.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.

An evil maid attack is what a stranger can do to your laptop during a few unsupervised minutes while it sits powered off in a hotel room, on a coworking desk, or in a bag handed over at a border checkpoint. The name comes from the picture of a hotel maid who slips into your room, does something to the machine on the desk, and slips out again in the time it takes to change the towels. Full disk encryption keeps the data safe while the device is off, but it does nothing for the code that runs before you type your password, and that gap is exactly where this attack lives.

How the evil maid attack works

Picture an invented machine, the Acme laptop, encrypted with full disk encryption and left in a hotel room for the afternoon. The attacker does not need to break the encryption. They need to change what happens the next time you turn the device on.

The trick is that a small piece of code has to run before the disk can be decrypted. Something must draw the password prompt, take your keystrokes, and hand the key to the disk. That code sits in the firmware and the bootloader, in the early boot chain, and on an unprotected machine it is not itself encrypted, because it is the thing that does the decrypting. It has to be readable to run. So the attacker replaces it.

They power on the Acme laptop, or boot it from a USB stick, and overwrite the bootloader with a look alike. Their version shows the same password prompt you expect. When you come back, sit down, and type your passphrase, the tampered code captures it, tucks it somewhere on the disk or sends it out over the network, and then quietly hands control to the real boot path so the machine behaves normally. You notice nothing. The attacker returns later, enters the password they stole, and now the encryption that protected the whole disk simply opens for them.

Encryption answers the question of whether someone can read a disk they stole. It says nothing about whether the machine you are about to log into is still the machine you left behind.

Why encryption alone does not stop it

Full disk encryption is built to defend against a lost or stolen device. If the laptop never comes back to you, the attacker holds a locked box and no key, and the design works as intended. The evil maid attack breaks a different assumption. Here the device does come back to you, and you type your password into it yourself.

Think about what the encryption actually covers. It protects the data at rest, the files on the drive. It cannot protect the code that runs before the drive is decrypted, because that code is what asks you for the key. On a machine with no boot integrity checking, nothing verifies that the password prompt in front of you is the real one. You trust the screen, you type the secret, and a full disk encryption setup has no way to know the screen was swapped. The key exists only in your head until the moment you enter it, and that moment is what the attacker is patient enough to wait for.

The defenses that actually address it

The fix is not stronger encryption. It is making tampering with the boot chain either impossible or obvious, and treating your physical control of the device as part of the security model.

Verify the boot chain

Secure boot and measured boot are the technical core of the answer. Secure boot checks that each stage of startup is signed by a key the firmware trusts, so a swapped bootloader that is not signed will refuse to run. Measured boot goes further: a Trusted Platform Module, or TPM, records a fingerprint of each component as it loads, and the disk key is released only if those fingerprints match the known good machine. Tamper with the early code and the measurements change, so the TPM will not hand over the key and the tampering is caught before you ever type anything. If you want the mechanics of that signing and measurement, see how secure boot works.

Add pre boot authentication

Pre boot authentication puts a secret in front of the boot process itself, so an attacker cannot even reach a normal prompt without something they do not have. Paired with a TPM that expects a specific boot state, it narrows the window in which a fake prompt could be shown to you at all.

Make tampering visible

Low tech defenses matter here because the whole attack depends on you not noticing. Tamper evident seals over screws and ports mean that opening the case leaves a mark you can check. Some people photograph the exact pattern of a glitter nail polish blob over a seam, because it is effectively impossible to reproduce. None of this stops a determined attacker, but it turns a silent swap into something you can see.

Keep the device with you

The cleanest defense is to deny the physical access the attack requires. Keep the laptop on you rather than in the hotel safe. If it must be left, power it off fully rather than leaving it asleep, so keys are not sitting in memory. And treat any device that was out of your sight, through a border check, a repair counter, or an afternoon in a room, as potentially compromised. Reflash the firmware from a trusted source, or in a high stakes setting, retire the machine rather than trusting it again.

Where this sits among physical access attacks

The evil maid attack is one of a family that all start from brief hands on time with your hardware. A cold boot attack pulls encryption keys straight out of RAM in the seconds after power is cut, when the chips still hold their charge. A DMA attack over Thunderbolt reads live memory through a port without ever passing the lock screen. And a BadUSB device pretends to be a keyboard and types commands the moment it is connected. Each one sidesteps encryption by going after the machine while it runs or before it locks, rather than the data sitting still.

What ties them together is a lesson worth carrying: a threat model that stops at data at rest is only half a model. The other half is the integrity of the device you decrypt and the memory it holds while it runs. That second half is the kind of assumption an autonomous researcher built to test assumptions, rather than match a list of known payloads, is meant to probe. More on how we think about that sits on our about page.

Frequently asked questions

What is an evil maid attack?

It is an attack in which someone gets brief unsupervised physical access to your powered off device and tampers with its boot chain. The tampered code captures your disk encryption password the next time you type it, then the attacker returns to collect the password and decrypt everything.

Does full disk encryption stop an evil maid attack?

No. Full disk encryption protects data at rest, which defends a lost or stolen device. It does not protect the bootloader and firmware that run before you type your password, so an attacker who returns the machine to you can swap that early code to steal the password you type.

How do secure boot and a TPM help?

Secure boot refuses to run boot code that is not signed by a trusted key. Measured boot with a TPM records a fingerprint of each startup component and releases the disk key only if those fingerprints match the known good machine, so tampering is caught before you enter your passphrase.

What should I do if my laptop was left unattended?

Treat it as potentially compromised. Check any tamper evident seals, and if the device was out of your sight at a border check, a repair counter, or a hotel room, reflash its firmware from a trusted source or, in a high stakes setting, stop trusting that machine.

How can I reduce the risk in practice?

Keep the device with you, power it off fully rather than leaving it asleep, and turn on secure boot, measured boot, and pre boot authentication. Tamper evident seals make a silent swap visible, and treating any unattended device as suspect closes the gap the attack relies on.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.

In July 2026 Hugging Face disclosed that an intruder who gained a foothold on a single dataset processing worker escalated to node level access, harvested cloud and cluster credentials, and moved across multiple internal clusters over a weekend. A Cloud Security Alliance post mortem read Hugging Face’s July 2026 disclosure as a textbook case of lateral movement: the break in touched one machine, but what followed turned that one machine into the run of the whole estate. We walk the shape of that problem here on an invented example app, Acme Cluster, and the controls that actually contain it.

The break in is rarely where the damage comes from

Most incident write ups spend their energy on the entry: the unpatched service, the leaked token, the phishing click. But a single compromised host is usually a small problem. It becomes a large one because of what the attacker does next, and what they do next is almost always the same move repeated. Land on one machine, read the credentials sitting on it, use those credentials to reach the next machine, and start again.

The damage scales with how far that loop can travel before something stops it. If the first host holds a credential that opens ten more, and each of those opens ten more, one foothold is the whole cluster within a few hops. The thing worth controlling is not only whether someone gets in. It is how far they get once they are in.

The entry is a door. The blast radius is the building. Guarding the door while leaving every internal room open is how one worker becomes every cluster.

What lateral movement actually looks like

Strip away the tooling and lateral movement is a plain sequence. Consider Acme Cluster, a typical machine learning platform with a fleet of worker nodes, a few internal services, and a cloud account behind them. An attacker gets code execution on one worker, perhaps through a poisoned dependency in a job. From there the steps are boring and reliable:

• Read what is in reach. Environment variables, files mounted into the container, an on disk cache of tokens. Secrets handed to a process at start up tend to stay readable for the life of that process.
• Ask the platform who it is. On a cloud host, the instance metadata endpoint hands back the machine’s own role credentials to anything that can make an HTTP request from that host. On a Kubernetes node, a mounted service account token names a workload identity the API server already trusts.
• Reuse to reach the next hop. Those credentials were minted for the workload, not the person, so they work the same from an attacker’s shell as from the real job. A database password, an internal API key, or a cloud role is now in hand.
• Repeat. Each new host is searched the same way, and standing trust between services means each hop rarely asks for a fresh proof of identity.

Two of those credential sources deserve a closer look, because they are where a single host quietly turns into many. The cloud metadata endpoint is covered in our piece on the instance metadata service, and the Kubernetes case in service account token abuse. Both describe the same failure: a credential that a compromised host can read and replay with no extra check.

Why over scoped and long lived credentials do the real work

The loop only pays off when the credential it finds is worth more than the host it was found on. Two properties make that true. First, scope: a token that can touch the whole cluster is far more useful than one that can touch a single queue. Second, lifetime: a credential that never expires can be harvested today and used next week, which is exactly what a weekend long intrusion needs. An over scoped, long lived credential sitting on a low value worker is a bridge from that worker to everything the credential can reach.

Technique matters too, not just theft. Some moves never read a stored secret at all. An NTLM relay forwards a victim’s authentication to a third service in real time, so the attacker moves sideways without ever seeing a password. Same shape, different mechanism: one identity, reused where it should never have reached.

Containing the blast, not just guarding the door

If the loop is read, reuse, repeat, then the defenses all aim at breaking one link in it. None of them stop the initial break in, and that is the point. They stop the second host from falling.

• Least privilege and tightly scoped credentials. The worker that runs a data job needs the one bucket and the one queue for that job, and nothing else. When its token is stolen, the blast radius is that bucket, not the account. Scope is the wall between hops.
• Short lived over long lived. Swap static keys for credentials that expire in minutes and refresh through the platform. A token harvested from a worker is close to worthless if it dies before the attacker can reach the next host with it.
• Network segmentation. A worker node has no business opening a raw connection to the billing database or another team’s cluster. Default deny between segments means a foothold can only talk to what its job genuinely needs.
• Remove standing trust between services. “Any workload inside the network is trusted” is the assumption that turns one hop into all of them. Make every service prove who it is on every call, so a stolen identity is checked, not waved through.

Notice that these are access control decisions, not intrusion detection ones. Most of them live in the same family as the failures we cover under access control: a system trusting a caller because of where it sits rather than checking what it is allowed to do.

How do you catch it while it is happening?

Prevention narrows the blast radius, but you still want to see the loop in motion. The signal is reuse in the wrong place. A worker’s service account normally talks to two endpoints, then suddenly enumerates the whole cluster. A credential minted for a job in one region is used from an address in another. A node identity that has read the same three secrets for months reaches for a fourth it has never touched.

None of these are malformed requests. Each one is a valid credential used by the wrong hands, which is why the useful detections watch behavior against a baseline rather than scan for bad payloads. Log which identity touched which resource, learn the normal shape per workload, and alert when a credential steps outside the path it has always taken.

This is the kind of assumption an autonomous researcher is built to probe: not “is there a known payload here” but “does this system trust a caller it has no reason to trust, and can that trust be walked from one host to the next.” In our own early testing, a frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before. More of our writing sits under access control and on our about page.

Frequently asked questions

What is lateral movement?

Lateral movement is what an attacker does after the first break in: read the credentials sitting on a compromised host, reuse them to reach the next host, and repeat until they hold the whole environment. The initial entry touches one machine, but this loop is what turns one machine into many.

Why does blast radius matter more than the initial entry?

Because a single compromised host is a small problem until the attacker can move off it. If the credentials on that host are tightly scoped and expire quickly, the damage stays contained to one machine. Over scoped, long lived credentials are what let one foothold become the whole cluster.

How do short lived credentials help?

A credential that expires in minutes is close to worthless once stolen, because the attacker has to reach the next host before it dies. Long lived static keys can be harvested today and replayed next week, which is exactly what a slow, multi day intrusion needs.

What credentials do attackers look for on a compromised host?

Environment variables, secrets mounted into the container, an instance metadata endpoint that returns the host’s cloud role, and a Kubernetes service account token. Each one names an identity the rest of the system already trusts, so it can be replayed to reach further.

How do you detect lateral movement in progress?

Watch for a valid credential used in the wrong place: a service account that suddenly enumerates the whole cluster, a token used from an unexpected region, or a node identity reaching for a secret it has never read. The requests are well formed, so detection works off behavior against a baseline, not bad payloads.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.

An exposed .env file is one of the fastest ways a working app turns into a breached one. That single file holds the secrets your code needs to run: the database URL, your cloud keys, the API key for your model provider, the signing secret behind your sessions. When a stranger can read it, they do not have to break anything clever. They log in with your own keys. This post walks through how a .env ends up reachable, what an attacker gets from it, how to check your own app, and how to recover once one has leaked.

The examples use an invented app called Acme Notes, so nothing here points at a real target.

What is a .env file and why does it matter?

A .env file is a plain text list of name and value pairs that your app reads at startup. It exists so that secrets live outside your code instead of being pasted into it. A typical one looks like this.

DATABASE_URL=postgres://acme:s3cr3t@db.internal:5432/acme
STRIPE_SECRET_KEY=sk_live_51Hxxxxxxxxxxxxxxxxxx
OPENAI_API_KEY=sk-proj-xxxxxxxxxxxxxxxxxxxxxxxx
SESSION_SECRET=9f2b7c1a4e8d
SMTP_PASSWORD=hunter2hunter2

Every line is a key to something real. The database URL opens your data. The payment key moves money. The model provider key spends your budget. The session secret lets an attacker forge a signed cookie and become any user. This is why the file is meant to stay on the server and never reach a browser, a public repository, or a public bucket. The moment it does, all of those doors open at once.

How does a .env file get exposed?

There are two paths that account for most cases, plus a few quieter ones.

The first is serving it over the web. If the file gets deployed into a public web root, or the web server is willing to hand back dotfiles, then a plain request returns it. An attacker does not guess a password. They ask for the file by name.

GET /.env HTTP/1.1
Host: acme-notes.example.com

If the response is your key list, the app is already compromised and you will not see it in any login log, because nobody logged in. They read a file.

The second path is git. Someone commits the .env before adding it to .gitignore, then pushes to a repository that is public, or private now and public later. Deleting the file in a later commit does not help, because git keeps history. The secret still sits in an old commit that anyone can check out. A repository that went public for one hour is a repository whose entire history is public forever.

The quieter paths matter too. A .env can leak through a storage bucket that was set to public, through a JavaScript source map that bundles server config by mistake, through a Docker image layer where the file was copied in and never removed, or through a backup archive left in a reachable folder. Same file, different door.

Deleting a leaked secret does not un leak it. Once a value has left your control, the only safe assumption is that a stranger has a copy.

Why does an exposed .env file happen so often in AI built apps?

Because the fast path skips the safe step. When you build with an AI coding tool or an app generator, the generator writes your secrets straight into a .env for you, which is correct. What it usually does not do is wire up the deployment so that file stays private. Tutorials say “just deploy” and move on. The step where you add .env to .gitignore before the first commit gets skipped, because the first commit felt like a formality. The result is an exposed .env file sitting one request or one git clone away from anyone who looks.

This is the same shape as other secret leaks in quickly built apps. It is a cousin of hardcoded API keys in the frontend, where the secret ships inside the browser bundle instead. Both come from the same habit: treating a secret like configuration instead of like a live credential. For the wider picture, the vibe coded app security hub maps the five failure shapes that keep showing up, and this is one of them. It also sits squarely in the access control category, because a leaked key is an access control failure that skipped the front door entirely.

The stakes are not abstract. A leaked model provider key lets an attacker run their own traffic on your account until the bill arrives, which is the same money drain covered in denial of wallet. A leaked database URL hands over every row. A leaked cloud key can spin up servers in your name.

How do you check your own app?

Three checks, all read only, all on an app you own.

• Request the file over the web. From a browser or with curl, ask for /.env on your own domain, then try the common variants: /.env.local, /.env.production, /.env.bak, and /env. Anything other than a clean not found is a problem.
• Grep your git history. The file can be gone from your working tree and still live in an old commit. Search the whole history, not just the current files.
• Scan the repository with a secret scanner. A tool that walks every commit will flag keys you forgot were ever there, including ones in files that are not named .env.

The git history check is the one people miss. A single command reads the past.

git log --all --full-history -- .env
git log -p --all -S 'sk_live_'

If either returns a commit, that secret has been in your history and must be treated as leaked, even if the file is deleted today.

How do you fix it and recover?

Fixing the leak and recovering from it are two different jobs. Do both.

Stop serving the file. The .env should never sit in the web root in the first place. Keep it outside the folder your web server publishes, and configure the server to deny dotfiles so a request for /.env returns nothing. Better still, move secrets into your platform’s secret manager and stop shipping a file at all.

Keep it out of git from the first commit. Add these lines to .gitignore before you commit anything, and commit an example file with blank values so teammates know which keys exist.

.env
.env.*
!.env.example

Rotate every secret that was ever exposed. This is the part that gets skipped, and it is the part that matters most. Deleting the file, making the repository private, or force pushing a cleaner history does not help you, because a copy may already be gone. Every key that appeared in an exposed .env file has to be regenerated at its source: new database password, new payment key, new model provider key, new session secret, new SMTP password. Until you rotate, the old keys still work for whoever grabbed them.

Rotation is uncomfortable because it means touching live services, but a deleted secret that still works is not fixed. It is just hidden from you.

What should you take away?

A .env leak is a quiet failure. No alarm fires, the app keeps working, and the only sign is a request for a file that should never have answered. That is exactly the kind of assumption an autonomous researcher is built to test: does the server hand back what it should keep, and does an old key still open a door. In our own early work, a frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before. If checking your own assumptions before an attacker does sounds useful, you can read more about UnboundCompute.

Frequently asked questions

What is an exposed .env file?

It is a .env file holding your app’s secrets that has become reachable by someone who should not see it. The two common paths are the file being served over the web, so a request for /.env returns it, and the file being committed to a git repository that is or becomes public. Either way an attacker reads your keys without breaking in.

What can an attacker do with a leaked .env?

Whatever the keys allow. A database URL opens your data, a payment key can move money, a model provider key spends your budget, and a session secret lets an attacker forge signed cookies and act as any user. Because these are live credentials, the attacker skips the login screen entirely and there is no failed login to alert you.

I deleted my .env from git. Am I safe?

No. Git keeps history, so the secret still lives in the old commit even after you delete the file. Anyone who cloned the repository, or who reads a public history, still has the values. Deletion does not un leak a secret. You have to rotate every key that was ever committed.

How do I check if my .env is reachable over the web?

From a browser or with curl, request /.env on your own domain and try the common variants like /.env.local, /.env.production, and /.env.bak. Only test an app you own. Anything other than a clean not found means the file is being served and the app is already exposed.

How do I keep a .env out of git?

Add the file to .gitignore before your first commit, using lines like .env and .env.* while keeping an .env.example with blank values so teammates know which keys exist. If a secret has already been committed, scan the full history with a secret scanner and treat every value it finds as leaked.

What is the single most important recovery step?

Rotate every secret that was ever exposed. Regenerate the database password, payment key, model provider key, session secret, and any other value at its source. Until you rotate, the old keys still work for whoever grabbed a copy, so a deleted or hidden secret is not a fixed one.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.

SMTP smuggling is an email spoofing technique that slips a second, forged message past SPF, DKIM, and DMARC by exploiting a disagreement between two mail servers about where a message actually ends. It was disclosed in December 2023 by researcher Timo Longin, working with SEC Consult, and it earned a reputation as uncommon but popular: rare in the wild, yet widely studied, because it defeats the exact controls built to stop spoofing. The trick is not that it breaks those checks. It is that the sending server and the receiving server read one byte stream two different ways, and the attacker lives in the gap between the two readings.

Where a message is supposed to end

To see the bug you have to see the protocol. When one mail server hands a message to another, it opens a session and issues the DATA command. Everything typed after that is the message body. The body finishes with a specific marker: a carriage return and line feed, then a single dot on a line by itself, then another carriage return and line feed. On the wire that is <CR><LF>.<CR><LF>. The receiving server watches for exactly that sequence. When it sees the lone dot, it knows the body is over and it accepts the message.

The standard is precise about this. The problem is that the world is not. Some servers, trying to be forgiving of clients that send slightly malformed line endings, also treat non standard variants as an end of data marker. A bare line feed with a dot, written <LF>.<LF>, or a lone carriage return version, <CR>.<CR>, might be accepted as the end of the body even though it is not the sequence the standard names. One server is strict. Another is lenient. That difference is the whole attack.

The message never changes on the wire. What changes is where each server decides it stopped, and an attacker who controls that split controls what the receiver thinks was sent.

How SMTP smuggling turns one message into two

Here is the mechanism in plain terms, using invented hosts. An attacker has a normal, authenticated account on an outbound provider, call it send.example. They compose a message to a victim domain served by receive.example. The visible message looks harmless. But buried in the body, the attacker places a sequence that the outbound server does not recognise as the end of data, while the inbound server does.

Because the outbound server does not see an end marker there, it keeps treating everything as body text and forwards the entire blob over its trusted, already authenticated connection to receive.example. The inbound server, being lenient, reads that same non standard sequence as a real end of data. It closes off the first message, then starts reading what follows as a brand new SMTP conversation on the same connection. That second conversation is fully attacker written. It can name any MAIL FROM sender it likes.

A stripped down, clearly sanitized illustration of the idea, not a working payload:

MAIL FROM:<attacker@send.example>
RCPT TO:<victim@receive.example>
DATA
Subject: a normal looking first message

Nothing to see here.
[a NON STANDARD end sequence the sender ignores
 but the receiver treats as end of data]
MAIL FROM:<ceo@trusted-brand.example>
RCPT TO:<victim@receive.example>
DATA
Subject: please approve this transfer

This is the smuggled message.
<CR><LF>.<CR><LF>

The outbound server sees one message with a slightly odd body. The inbound server sees two messages: the innocent one, and then a second one that claims to come from ceo@trusted-brand.example. Nobody forged a cryptographic signature. The two parsers simply disagreed on where the first message ended, and the attacker wrote their forgery into the space that disagreement created.

Why the smuggled message inherits trust

This is the part that makes SMTP smuggling matter. SPF, DKIM, and DMARC all answer one question: did this message come from a server authorized to send for its claimed domain? SPF checks the connecting IP against the sending domain’s published list. DKIM checks a signature. DMARC ties the two together and tells the receiver what to do on failure.

The smuggled message rides in on the outbound provider’s own connection, from the outbound provider’s own IP, inside a session the provider already authenticated for the attacker’s legitimate account. So when the inbound server evaluates that second message, the connection it arrived on belongs to a well known, authorized sender. The checks look at the trusted infrastructure the message rode in on and pass it. The forgery inherits the reputation of the connection it was smuggled through. The controls did their job correctly on the wrong message, because they were never told a second message existed.

The email cousin of HTTP request smuggling

If this shape feels familiar, it should. It is a parser differential attack: two parsers, one stream, two interpretations. That is exactly the pattern behind HTTP request smuggling, the parser differential cousin, where a front end and a back end disagree about where one HTTP request ends and the next begins. Same idea, different protocol. In HTTP the disagreement is over content length and chunk framing. In SMTP the disagreement is over the end of data marker. In both, an attacker who understands the boundary better than the servers do can hide a whole second message in the seam.

How to detect SMTP smuggling exposure

You detect this by testing your own parsing, not by watching for a signature.

• Probe the end of data handling. In a controlled test, send messages whose bodies contain bare <LF>.<LF> and lone <CR>.<CR> sequences. A standards compliant receiver should treat only <CR><LF>.<CR><LF> as end of data and should never split the stream on the non standard variants.
• Watch for phantom second messages. If a single inbound session ever yields a second MAIL FROM that your outbound path did not intend, that split is the fingerprint of the bug.
• Look for authentication that passes on impossible senders. A message that passes SPF and DMARC while claiming a sender that has nothing to do with the connecting infrastructure is worth a hard look.
• Compare outbound and inbound behavior side by side. The vulnerability only exists when your sender and your receiver disagree. Test them against the same set of odd line endings and see if their answers match.

How to fix it

The fix is alignment and strictness. Neither server should be creative about where a message ends.

• Parse the end of data marker strictly. Accept only the standard <CR><LF>.<CR><LF> sequence as the terminator. Do not treat bare line feed or lone carriage return dot sequences as end of data.
• Reject or normalise malformed line endings. A message that mixes bare <LF> or lone <CR> into its framing is either broken or hostile. Normalise it to the standard form before any parsing decision, or refuse it outright.
• Align outbound and inbound handling. The bug is a disagreement. If the server that sends and the server that receives apply the same strict rule, there is no gap to hide in.
• Take the provider side fixes. After disclosure, major email providers were found affected and updated their parsers. Keep your mail infrastructure patched, because the durable fix lives in the servers that frame and unframe the message.

Notice that none of these fixes touch SPF, DKIM, or DMARC. Those controls were never the weak point. The weak point was an assumption underneath them: that the sending server and the receiving server agree on what a message even is. Fix the framing and the authentication starts guarding the right message again.

That gap between two parsers is the kind of thing an attacker finds by questioning an assumption everyone treated as settled. UnboundCompute is an autonomous security researcher built to do exactly that, to test the assumptions a system makes rather than replay a fixed list of payloads, and in this case the assumption is a quiet one: that two parsers reading the same stream will always agree on where it ends. You can read more about that approach on our about page.

Frequently asked questions

What is SMTP smuggling?

It is an email spoofing technique that hides a second, forged message inside a first one by exploiting a disagreement between two mail servers about where a message ends, letting the forged message ride a trusted, already authenticated connection.

How does it get past SPF, DKIM, and DMARC?

It does not break those checks. The smuggled message arrives on the outbound provider’s authenticated connection and IP, so the checks evaluate trusted infrastructure and pass a message they never knew was there.

How is it like HTTP request smuggling?

Both are parser differential attacks: two parsers read one stream and split it differently. In HTTP the disagreement is over where one request ends, in SMTP it is over the end of data marker that closes a message body.

How do you prevent SMTP smuggling?

Parse the end of data marker strictly, accepting only the standard sequence, reject or normalise bare line feed and lone carriage return variants, and align outbound and inbound handling so there is no gap to hide a second message in.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.

On SAP Security Patch Day, June 9 2026, SAP shipped Security Note 3746332 for CVE-2026-44748, a CVSS 9.9 flaw in SAP NetWeaver Application Server ABAP that opens a full SAML authentication bypass. The root cause is filed as CWE-347, improper verification of a cryptographic signature, and the mechanism is a classic that keeps coming back: XML Signature Wrapping. An attacker takes a genuine, correctly signed login assertion and rearranges the document so the server checks the signature over one part while reading the user’s identity from another. There was no confirmed exploitation in the wild at disclosure, but the pattern is worth understanding because it defeats a signature check without ever breaking the signature.

What a SAML assertion actually promises

SAML is how one system tells another “I already logged this person in, and they are who they say.” The system that checks credentials is the Identity Provider (IdP). The system that grants access is the Service Provider (SP). When you sign in to a company dashboard through single sign on, the IdP builds an XML document called an assertion that says, in effect, this subject is alice@acme.com, valid until this time, for this audience. The IdP signs that XML with its private key. The SP holds the IdP’s public key and verifies the signature. If it checks out, the SP trusts the identity inside and creates a session.

The whole model rests on one belief: if the signature is valid, then the identity the SP reads is the identity the IdP vouched for. That link between what was signed and what is read is the only thing standing between a visitor and any account. If you have not thought about how signing and reading can drift apart, our note on authentication vs authorization is a useful warm up, because this bug lives entirely on the authentication side.

How the signature points at what it covers

An XML Signature does not sign the whole document by default. It signs specific elements, named by an ID, through a <Reference URI="#..."> inside the <Signature> block. The verifier follows that reference, canonicalizes the target element, and checks the digest. So the signature says “I cover the element with this ID.” Nothing forces the rest of the code to then read identity from that same element. That gap is where the trouble starts.

The XML Signature Wrapping move behind the SAML authentication bypass

Picture a made up IdP and SP pair, “Acme SSO.” A legitimate assertion for a low privilege user might look like this, trimmed for clarity:

<Response>
  <Assertion ID="A">
    <Subject><NameID>guest@acme.com</NameID></Subject>
  </Assertion>
  <Signature>
    <Reference URI="#A"/>   <!-- signs the element with ID "A" -->
    ...
  </Signature>
</Response>

An attacker who can capture any one valid assertion, even their own low privilege login, now has a signature they cannot forge but can move. They keep the signed Assertion ID="A" intact so the signature still validates, then they inject a second, unsigned assertion carrying the identity they want:

<Response>
  <Assertion ID="EVIL">
    <Subject><NameID>admin@acme.com</NameID></Subject>
  </Assertion>
  <Assertion ID="A">
    <Subject><NameID>guest@acme.com</NameID></Subject>
    <Signature>
      <Reference URI="#A"/>   <!-- still valid over "A" -->
      ...
    </Signature>
  </Assertion>
</Response>

Now two things happen in the SP, and they look at different elements. The signature layer walks the Reference URI="#A", finds the original signed assertion, canonicalizes it, and the digest matches. Signature valid. A separate piece of code then asks “which assertion do I use for identity?” and, because of how it queries the parsed tree, grabs the first Assertion it finds, or the one nearest the document root, which is now ID="EVIL". It reads admin@acme.com. The signature was real, the identity was not, and nothing in the flow noticed that the verified element and the consumed element were two different things.

The attacker never breaks the signature. They break the assumption that the signed element and the element the server actually reads are the same one.

The variations are all the same idea: move the signed element into a wrapper, bury it, or reference it by an ID that the identity reader resolves differently than the signature verifier does. XML is flexible about structure and ID resolution, and that flexibility is exactly what lets the two lookups disagree. If you want the deeper protocol walk through, we cover the variants in SAML signature wrapping.

How to spot it

You are looking for any place where signature verification and identity extraction are decoupled. A few concrete checks:

• Count the assertions. A well formed response has one assertion in play. If a parsed message contains more than one Assertion, or more than one Subject, treat it as hostile rather than picking a winner.
• Compare the two elements by identity, not by value. After verification, confirm that the exact node whose signature you checked is the same node object you then read NameID from. Not an element with the same ID, the same one.
• Watch for reference by string search. Code that finds the assertion with getElementsByTagName("Assertion")[0] or an XPath that returns the first match is reading position, not the signed target. That is the classic wrapping foothold.
• Log signed IDs against consumed IDs. In real time, record which ID the signature covered and which element supplied the identity. If they ever differ, you have either a bug or an attack.

How to prevent it

The fix is to force the signed element and the consumed element to be one and the same, and to remove the ambiguity that lets a document contain a decoy.

• Validate that the signature covers the exact element you consume. Extract identity only from the node that verification returned as signed. Never re query the document for “an assertion” afterward.
• Use schema aware and position aware validation. Validate the message against a strict schema before trust decisions, and reject any structure that adds elements the schema does not expect or places them where they do not belong.
• Reference by a canonicalized ID and pin resolution. Make sure the ID the signature resolves and the ID the identity reader resolves use the same rules, so an injected ID="EVIL" cannot win a second lookup.
• Reject assertions whose signed element is not the one used. If the message carries more than one assertion, or the signed element is not the top level assertion you act on, fail closed.
• Prefer a well tested SAML library and mark the IdP public keys. Pin the exact keys you accept, and lean on libraries that have already been hardened against wrapping rather than hand rolling XML verification.

CVE-2026-44748 is a reminder that “the signature is valid” is not the same claim as “this identity is the one that was signed.” Improper verification of a cryptographic signature, CWE-347, is rarely a broken crypto primitive. It is almost always this drift between what was checked and what was trusted, and it hides in the seam between two functions that each look correct alone. This is exactly the kind of assumption an autonomous researcher that tests how an application actually reads a request, and proves the finding with evidence, is built to surface. More on that approach on our about page.

Frequently asked questions

What is a SAML authentication bypass?

It is an attack where a valid signed SAML assertion is rearranged so the service provider checks the signature over one element but reads the user’s identity from a different, attacker added element. The signature is real, the identity is forged.

What is XML Signature Wrapping?

It is the technique behind the bypass. The attacker keeps a genuinely signed element intact so the signature still validates, then injects a second unsigned assertion in the spot where the identity reader looks first.

Does it break the cryptographic signature?

No. The signature stays valid over the original element. The flaw is that the verified element and the consumed element are not the same one, so a real signature ends up vouching for an identity it never covered.

How do you prevent it?

Read identity only from the exact node the signature verified, reject any message that carries more than one assertion, validate against a strict schema before trusting structure, and use a well tested SAML library instead of hand rolled XML checks.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.

Most write ups about server side request forgery assume you get to read the answer. You send a URL, the server fetches it, and the page or image comes back to you. A blind ssrf is the harder cousin: the server still makes the attacker controlled request, but the response never returns to the attacker. You are firing requests into the dark and have to infer what happened from indirect signals. This post explains how that works, why it stays dangerous even when you cannot see the reply, and how to shut it down. Everything below uses an invented app, so nothing here points at a real target.

If you want the plain version of classic SSRF first, read that, then come back. Here we focus on the case where the body you get back tells you nothing.

What blind ssrf is and how it differs from classic SSRF

Picture an invented app called Acme Notes. It has a webhook feature: you register a URL, and when something changes in your account the server sends a POST to that URL. The server code looks roughly like this.

POST /webhooks
{ "url": "https://hooks.example.com/acme" }

# later, on an event:
# Acme server -> POST {your url}  with a JSON body

In classic SSRF the app hands the fetched response straight back to you on screen. You point the URL at http://localhost:8080/admin and the admin page renders in your browser. You see it. In a blind case the server fires the request but keeps the result to itself. The webhook delivery happens on a background worker. The HTTP status, the body, the headers, all of it stays server side. The app shows you, at most, “delivered” or “failed”.

So the server is still borrowing its trusted position on the network. You just lost your window into the result. That is the whole difference, and it changes how you confirm a finding rather than whether one exists.

Blind does not mean safe. It means the proof moves from the response body to the side channels, and the request still reaches wherever you aimed it.

Why blind ssrf is still dangerous

The damage from SSRF was never really about reading one page. It was about reaching addresses the outside world cannot. A blind version keeps that reach intact.

• Internal services. Admin panels, message queues, caches, and databases that only listen on private ranges. A POST that triggers an action, like flushing a cache or creating an account, does damage whether or not you read the reply.
• Cloud metadata. Most cloud providers expose an instance metadata service at a fixed link local address. Even blind, a request aimed there can cause server side effects, and some exfiltration tricks below can pull the data back out of band.
• State changing requests. Many internal endpoints act on a plain GET or POST. You do not need the response to trip them. You need the request to land.

So the question for a defender is not “can the attacker read the reply”. It is “where is the server willing to send a request, and what happens when it gets there”.

Detecting it with out of band signals

Because the body is gone, you confirm the request another way. Three signals do the work: a callback you control, timing, and error differences.

Out of band callbacks

Stand up a server you own, say probe.attackercontrolled.example, and point the feature at it. If the app reaches out, your listener records the hit. Two layers matter here.

• DNS. Watch the authoritative DNS server for your domain. A lookup for abc123.probe.attackercontrolled.example proves the server at least resolved your name, even if a firewall blocks the outbound HTTP. DNS often leaks where HTTP cannot.
• HTTP. If the full request arrives, you also learn the user agent, source address, and any headers the fetcher adds.

A neat trick for the metadata case: some internal endpoints return data that the app then includes in a later outbound request. If you can get a value placed into a hostname your DNS server sees, the blind channel quietly hands you the data. Defenders should assume this is possible and not rely on “the response is hidden”.

Timing

When you cannot get a callback, latency talks. Point the feature at a closed internal port and an open one and compare how long the app takes to answer.

url = http://10.0.0.5:9999/   -> fails fast,  ~5 ms   (connection refused)
url = http://10.0.0.5:6379/   -> hangs then errors, ~2000 ms (something is listening)

A consistent gap maps which internal hosts and ports are alive. It is slow and noisy, but it works when every other channel is closed.

Error differences

The app may say more than it means to. “Invalid response” versus “connection timed out” versus a generic failure are three different states, and each one leaks something about what the server reached. Compare the messages across a public URL, a refused port, and a filtered address. The pattern tells you the request is real.

How to fix it

The fix is the same as for any SSRF, and it does not depend on whether the bug is blind. You decide, on the server, exactly where an outbound request may go. A block list of bad strings loses, because there are too many ways to spell the same address.

• Allow list outbound destinations. If the webhook only ever needs to reach a few known providers, allow those hosts and refuse the rest. For open ended user webhooks, restrict to public addresses and verify the host before every request.
• Block link local and internal ranges. Resolve the hostname to an IP first, then reject loopback, private ranges, and the link local metadata address. Do the check after resolving so a name that quietly points inside cannot slip past.
• Re check on every redirect. A public URL can redirect to an internal one. Validate the destination on each hop, not just the first.
• Do not accept raw user URLs into a privileged fetcher. Run the part that makes outbound calls with no route to internal systems, so even a landed request reaches nothing useful.
• Require credentials on metadata. Where your cloud supports a session protected metadata endpoint, turn it on so a bare request returns nothing.

Notice that none of these care about the response body. They constrain the request, which is the only thing a blind attacker still controls.

Closing

Blind ssrf is quiet by nature. The feature works, the screen says “delivered”, and the only thing wrong is where the server agreed to send a request you wrote. Finding it means reading the app for the trust it places in a URL and then proving the request landed through a side channel, not a tidy response. That is exactly the kind of assumption an autonomous researcher that tests how an app is meant to work is built to find. In early testing, a frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before. You can read more about UnboundCompute if that approach is interesting.

Frequently asked questions

What is blind ssrf?

Blind ssrf is a server side request forgery flaw where the server makes a request you control but the response never comes back to you. You cannot read the reply, so you confirm and exploit the bug through side signals like a callback to a server you own, timing, or differences in errors.

How is blind ssrf different from classic ssrf?

In classic ssrf the server returns the fetched content, so you see the result directly. In blind ssrf that channel is closed, so you rely on out of band evidence. The server still makes the request, you just have to infer what happened rather than read it.

Is blind ssrf still dangerous if you cannot see the response?

Yes. The server can still be steered to reach internal services and cloud metadata endpoints, which can expose credentials or trigger actions. Out of band confirmation tells the attacker the request landed even when the body is hidden.

How do you detect blind ssrf?

Point suspect inputs at a server you control and watch for DNS or HTTP callbacks that prove the target reached out. Compare response times and error messages between reachable and unreachable destinations, since those gaps reveal the request even when the content is hidden.

How do you prevent blind ssrf?

Do not let users supply raw destinations. Use an allowlist of approved hosts, block link local and internal address ranges, strip redirects, and isolate the egress path so a request cannot reach the metadata service or internal systems.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, a say in what it looks for, and founding pricing. If your team ships software worth pressure testing, apply to the design partner program.

Stalkerware is covert monitoring software that someone installs on your phone, usually a partner, ex, or family member who had physical access to the device for a few minutes. It hides itself, then quietly forwards your messages, location, calls, and photos to whoever set it up. This guide explains what stalkerware is, the signs that point to it, how to check an iPhone or Android, and how to remove it in a way that keeps you safe.

Read the safety note first. If you think someone abusive is watching you, removing the app too fast can warn them and escalate the situation. Plan before you act.

What stalkerware is and how it differs from normal apps

Stalkerware is a category of app built to spy on a specific person without their knowledge. It is different from the parental controls or device finders you opt into and can see. The defining traits are that it runs in the background, hides its own icon, and reports your activity to a remote account.

Installation almost always needs hands on the phone. Someone unlocks your device, turns off a security setting, sideloads an app or signs in to a hosted account, then hands it back looking normal. On iPhone the data can also flow through stolen iCloud credentials instead of an installed app, which matters for how you check.

This is a close cousin of identity attacks like SIM swapping, where the goal is also silent access to your private life. The difference is that stalkerware usually comes from someone you know, which is what makes it both common and dangerous.

The danger of stalkerware is not only the spying. It is that the person watching is often close enough to react if they think they have been caught.

The warning signs of stalkerware on your phone

No single sign proves anything. Look for a cluster of these together, especially if they started after someone else handled your phone.

• Battery drain. The phone dies much faster than it used to, with no new heavy app to explain it.
• The phone runs warm when you are not using it, because tracking and uploading keep working in the background.
• Data spikes. Your mobile data use jumps for no clear reason, since recordings and location logs get sent out.
• Unknown profiles or admin apps. A configuration profile, VPN, or device admin app you do not remember adding.
• The other person knows too much. They reference private messages, plans, or places you never told them about.
• Settings changed. Security toggles are off, or a feature you locked is suddenly open.

Context is the strongest signal. If these started right after a breakup, a fight, or a moment when your phone left your sight, take them seriously.

How to check an iPhone

iPhones are harder to load with hidden apps, so checks focus on profiles, account access, and sharing settings.

Look for configuration profiles and device management

Open Settings, then General, then VPN and Device Management. A personal iPhone should normally show nothing here. A profile you do not recognize can force the phone to route data or accept monitoring, so treat an unexpected one as a red flag.

Check who can see your location and account

• In Find My, review the people listed under Share My Location and remove anyone you did not intend.
• In Settings at the top, tap your name, then check the device list. Sign out any device you do not own.
• Change your Apple ID password and turn on two factor authentication so stolen credentials stop working.

Update iOS

Installing the latest iOS update removes many monitoring tricks that rely on older software, and it is a safe first move that looks routine.

How to check an Android phone

Android allows app installs from outside the store, so hidden apps are more common here.

Review device admin apps and accessibility

Open Settings, then Security, then Device admin apps. Stalkerware often asks for admin rights so it cannot be deleted easily. Also check Settings, then Accessibility, because spying tools abuse accessibility permissions to read your screen and log what you type.

List every installed app

Go to Settings, then Apps, and show system apps. Look for names that sound generic, like “System Service”, “Update”, or “Sync”, that you cannot match to anything real. Check Settings, then Apps, then Special app access, and review which apps can install other apps or use data in the background.

Turn on Play Protect

Open the Play Store, tap your profile, then Play Protect, and run a scan. It will not catch everything, but it flags many known monitoring apps.

How to remove stalkerware safely

Removing the app is the easy part. Doing it without putting yourself at risk is the part that needs a plan.

Plan before you act if you may be in danger

Many of these tools alert the person watching when monitoring stops. If that person could hurt you, do not pull the app first. Use a safer device, a friend’s phone or a public computer, to reach a domestic abuse helpline and make a plan. In the United States you can contact the National Domestic Violence Hotline. The Coalition Against Stalkerware lists support organizations in other countries. Talk to them before you change anything.

Steps once you have a plan

• Document first. Take photos or screenshots of the suspicious apps, profiles, and settings, stored somewhere the other person cannot reach.
• Change passwords from a clean device. Update your Apple ID or Google account, email, and bank logins, then turn on two factor authentication.
• Remove the admin right, then the app. On Android, revoke device admin and accessibility access for the app first, then uninstall it.
• Delete unknown profiles on iPhone and sign out unfamiliar devices from your account.
• Update the operating system to close the door the tool used.
• The full reset. A factory reset, followed by setting the phone up as new rather than from a recent backup, is the most reliable way to clear hidden monitoring.

One honest warning. Do not use any of this to spy on another person. Installing monitoring software on someone else’s device without consent is illegal in many places and is exactly the harm this article exists to stop.

Keep the door shut afterward

After you are clean, lock the phone with a passcode only you know, turn off installs from unknown sources on Android, and review your accounts every few months. Privacy is a habit, not a one time fix. For more plain explainers on protecting your accounts and devices, see the blog.

Threats like this work by hiding and by exploiting trust, the same way the subtle logic bugs an autonomous security researcher is built to find hide inside an app. If you want to know what we are building toward, read more about our work.

Frequently asked questions

What is stalkerware?

Stalkerware is covert monitoring software that someone installs on another person’s phone, usually with physical access, to track location, messages, calls, and activity without consent. It hides itself and reports back quietly, which is what separates it from open parental or workplace tools.

What are the signs of stalkerware on a phone?

Watch for faster battery drain, a phone that runs warm while idle, unexpected data spikes, and settings that change on their own. On Android, check for an unknown device admin app or a profile you did not add. On iPhone, review configuration profiles and any account you do not recognize.

Can stalkerware be installed remotely?

On a normal, updated phone, most stalkerware needs brief physical access and your passcode to install. Fully remote installs are rare and usually require the device to be already compromised, so guarding your passcode and keeping the phone updated removes most of the risk.

How do I remove stalkerware safely?

If you are in an unsafe situation, read the safety note first, because removing the app can alert the person watching. When it is safe, update the operating system, run a reputable security scan, remove unknown admin apps or profiles, and as a last resort back up your data and reset the device.

Where can I get help if I think I am being monitored?

Contact a domestic abuse helpline before you change anything, since they can help you plan a safe next step. They understand that removing stalkerware can escalate a situation, so reaching out first protects you better than acting alone.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, a say in what it looks for, and founding pricing. If your team ships software worth pressure testing, apply to the design partner program.