"Human in the Loop" Applied

Field notes from Black Hat USA 2026 and DEF CON 34

Last week I spent seven days in Las Vegas across Black Hat USA 2026 and DEF CON 34, two very different conferences back to back.

This isn't a schedule recap; the official Black Hat and DEF CON programs do that better than I can. These are the talks that stuck with me, why they matter for the work I actually do, pentesting, hardening, research, and what I'm going to write about next.

One thread ran through the whole week. DEF CON 34's theme was Agency, self-determination in how we use technology, and a striking amount of the vendor-facing research was about the opposite: companies wiring AI into products without controlling what they'd handed it. Agentic browsers that follow hidden instructions, AI features that quietly dissolve trust boundaries nobody meant to open. The researchers proved to be more careful in their use of agentic systems and AI features.

The talks I rated highest were led by people who deliberately kept a human in the loop (James Kettle's HTTP Terminator is the clearest case) and drove the work toward something that generalizes, instead of letting the automation run and calling the output a result. That distinction: "did the work produce a reusable insight, or just another 'random' CVE?" is the lens I ended up judging everything through, and it's the thread I keep returning to below.

Part 1: Black Hat USA 2026

The one that reframed the whole week: the HTTP Terminator

James Kettle, PortSwigger's Director of Research, asked a harder question than "can AI find bugs?". He asked whether an autonomous system can invent new attack techniques and use them to hack live websites at scale. Then he built it, pointed it at HTTP desync (an attack class he repopularized back in 2019 and has spent four years and four Black Hat/DEF CON talks on) and let it run. Well, sort of.

"Let it run" undersells the engineering. The pipeline he demoed is a four-stage factory: seeker extracts candidate desync techniques from RFCs, flamer generates malformed test-cases from them, a validator Burp extension fires those against live targets, and an investigator replicates, cascades, and reports.

He seeded it with 138 HTTP and SMTP RFCs, which produced ~15,000 micro-fragments of "inspiration" and ~30,000 unique desync vectors after dedup, then evaluated them against 30,000 websites around the clock.

The results weren't toy findings: CL.0 and dual-Content-Length triggers that hit an American bank (a long-lived API key fell out of one proof-of-concept), an F5 BIG-IP desync that exposed an airport's internal flight and baggage panels, and a zero-day in Apache Traffic Server now tracked as CVE-2026-63078.

But the details I keep coming back to are the ones about steering the model, not the bugs. Kettle's account of fighting the AI is the most honest thing I saw all week.

Frontier models kept making novice mistakes, like confusing HTTP pipelining for a smuggling vuln, insisting on client-side connection reuse. When he wired an agent into his tooling, it refused on the grounds that automating attacks against "real targets" increases offensive capability, so he renamed the interface "Turbo Simulator" and the agent, now believing it was in a simulation, complied (and occasionally got so reckless it tried to attack out-of-scope hosts).

He fed it a placebo connection-reuse toggle that did nothing, hid response headers that made it give up, and even renamed "Response Queue Poisoning" to the invented term "Victim Response Theft" because the model kept misunderstanding the real one.

What makes this the anchor of my whole trip isn't the exploits, it's what the experiment proved about method. Kettle's stated second objective was to push full autonomy until it broke, specifically to find where a human still adds value rather than just building the loop and stepping back.

His most significant find, Shared-Parser Confusion, the observation that servers reuse parsing code between requests and responses, so any response-processing feature becomes request-reachable attack surface, was not fully autonomous.

The system proposed it, he validated it. By his own account neither would have found it alone. His framing has stuck with me: it's not AI-vs-human, it's AI vs. code vs. human: Start AI-heavy, then push responsibility down into deterministic code as you learn what "correct" looks like.

Conclusion, in his words: humans are a massive power amplifier for AI research systems, not the other way around. That's the lens I ended up judging every other talk through.

Why it matters if you build or test systems. Two takeaways transfer immediately.

For anyone standing up an AI research or triage pipeline: the leverage isn't in removing the human, it's in actually owning the evaluation.
Kettle's own blueprint puts evaluation strategy first, because false positives at autonomy-scale drown every real finding in noise.
Treat the model as a hypothesis generator and gate it behind deterministic validation you control.

And for defenders: HTTP desync is emphatically not a solved problem you can file under "2019." His concrete hardening advice for anyone still forced onto upstream HTTP/1.1 is worth lifting straight into a checklist; enforce an allow-list of HTTP methods on both front-end and back-end, and separately allow-list which methods may carry a body (basically just POST, maybe PUT/PATCH; never GET/HEAD/OPTIONS). The real fix, of course, is to stop using upstream HTTP/1.1 at all.

📌 Deep dive coming. I want to build a version of his research loop myself to test his methodology on other research topics. Let's see where that takes me.

Pass-the-Passkey: the impact-to-effort winner of the week

Michael Grafnetter (SpecterOps; a Microsoft MVP, the researcher behind the Shadow Credentials attack and the DSInternals toolkit (and such a cool guy)) came at passwordless from a brutal angle: if passkeys are supposed to kill phishing, replay and relay, what happens when the implementation around them falls short? His answer was a whole family of attacks he calls Pass-the-Passkey, deliberately echoing Pass-the-Hash and NTLM Relay, anchored by three zero-days in Windows 11 and Microsoft Entra ID.

Two of them chain into the headline result.

First, Windows 11 was writing the complete WebAuthn assertion, challenge, authenticator data, signature, the lot, into the Microsoft-Windows-WebAuthN/Operational event log on every passkey sign-in, readable by any authenticated user (locally, membership in Users is enough; remotely, Event Log Readers).

Second, Entra ID wasn't enforcing the anti-replay checks WebAuthn assumes: it never verified challenge reuse, didn't bind challenges to sessions, and didn't track signature counters. Put those together and a low-privileged attacker on a shared machine can lift a Global Admin's logged assertion and replay it against the cloud, satisfying the "phishing-resistant MFA" requirement in conditional access, and firing no XDR alerts. Watching "unphishable" get walked around that cleanly was the most fun I had in a briefing room all week.

The part I keep thinking about is the human-factor attack that needs no Microsoft bug at all. Because malware calling the Windows WebAuthn API directly supplies the origin itself (browsers are what normally bind origin to the real page), it can request an assertion for any relying party and just show the user a genuine Windows Hello prompt. Combine that with a Credential UI window-handle spoofing flaw Microsoft declined to fix — the prompt's parent window isn't validated, so the dialog can be made to appear as though it came from Edge — plus prompt-flooding, and you can coerce a reflexive "yes." Grafnetter's own colleagues admitted to approving test prompts on autopilot (see p. 39). That's the passkey version of MFA fatigue, and it's a design property, not a patch-and-forget bug.

Why it matters if you're rolling out passwordless. The through-line: "phishing-resistant" describes the authentication ceremony, not the whole system.
Several of the critical anti-replay checks are the relying party's responsibility, and if they're skipped, the guarantee quietly degrades to something you can pass, relay or replay.

Grafnetter closes with concrete defensive advice. It splits cleanly by who you are.

If you run IT / identity for an organization:

• Patch Windows 11 to the latest version, it closes the event-log leak that makes the replay chain work.
• Don't treat the "phishing-resistant MFA" box in your conditional-access policy as sufficient on its own for high-value accounts (Global Admins above all). As this research shows, that box can be satisfied by a replayed assertion. Add attestation on top.
• Enforce passkey attestation, so only authenticator models you've approved can be enrolled.
• Block unsanctioned browser extensions, a malicious one can hijack the passkey ceremony from inside the browser.
• Watch for two specific signals: the Windows WebAuthn API being called by anything that isn't a browser, and new passkeys being registered through the Microsoft Graph or Okta APIs. The latter catches Grafnetter's "Shadow Passkey" trick. An attacker with enough privilege enrols their own passkey onto a victim's account, and because it's a separate credential, it keeps working even after the victim resets their password.

If you build a web app that accepts passkeys:

• Implement the full WebAuthn verification procedure, don't cut steps. In particular, bind each challenge to the user's session and track signature counters, since these are the checks that stop replay.
• Don't hand-roll this. Use a well-tested WebAuthn library rather than writing your own.. Microsoft, a co-author of the standard, still got it wrong.

One last point that reframes how you should think about passkeys. A synced passkey (one your password manager copies across your devices via the cloud) quietly inverts the security promise. The whole appeal of a passkey is that it's phishing-resistant, but a synced one is ultimately protected by the password guarding your cloud vault, which is phishable. So the "unphishable" credential is bootstrapped from a phishable one. Grafnetter's tooling drives the point home: it reads private keys straight out of KeePassXC .passkey exports and unencrypted Bitwarden JSON files, in cleartext. The takeaway: for a high-value account like a Global Admin, use a device-bound passkey (one that never leaves a piece of hardware). The convenience of syncing isn't worth it there.

One thing I'll flag honestly, since it matters for how you read the severity: Microsoft has already shipped fixes for the two chained bugs, the event-log disclosure was patched (assertions are now truncated to 6 bytes), and signature-counter tracking rolled out for FIDO2 keys, though Windows Hello passkeys reportedly still replay because they always send a counter of 0, and the window-handle spoofing was closed as "won't fix." So this isn't purely historical; parts of it still work, and the tooling is open-source for validating your own environment.

📌 Deep dive coming. This will get its own dedicated post, I'd like to build the replay chain in a lab and maybe walk through the defender detections (non-browser WebAuthn API calls, access to the WebAuthN event log, the \\.\pipe\WebAuthnHook named pipe). I think i can learn so much from this.

Whitepaper: Pass-the-Passkey Family of Attacks (Michael Grafnetter, SpecterOps)

Where I wanted more: the honest bit

Here's the thread I couldn't stop pulling on. The strongest work I saw, Kettle being the clearest example, shared one quality: the researcher stayed in the loop and drove toward a generalizable insight, not just a shippable CVE. A new attack class. A transferable methodology. Something that outlives the specific bug.

In a handful of talks, I felt that quality thin out. AI accelerates the path from "interesting anomaly" to "working exploit" so much that it's tempting to stop at "here's a CVE, have fun", before asking the question that actually advances the field: what does this generalize to?

Two talks left me wanting that second step:

• Compounding Interest: Exploiting the ATM Supply Chain (Matt Burch). Genuinely intricate work. My open question, and I mean open, is how realistic the access precondition is. The impact is gated behind a fairly privileged position in the supply chain, and the whole weight of the finding rests on how plausibly an outsider reaches that position. Supply-chain attacks are exactly about outsiders reaching insider positions, so this isn't a dismissal, I'd just have loved ten more minutes on precisely that reachability. The same point goes for the exploit itself, which was (from my perspective) extremely intricate, so as far as i understood it, you had to be in a very specific position and then use a very specific exploit.
• CSS: The Bomb Inside Your Inbox (CSS exfiltration from webmail). Creatively, one of my favourites. The sheer amount you can do with "just styling" is delightful, and CSS-only exfil from webmail is a real primitive. I came away impressed by the craft and curious about the impact ceiling: how far does this go past the demo? Kind of a compliment wearing a question mark.

Let me be clear about the register: both conferences were excellent, and I'm saying this as someone who'd love to be on that stage someday. This isn't "Black Hat was thin." It's that the best talks set a bar (did you generalize it?) and I'll try to hold my own work to that bar too.

Breaking Multi-Tenancy in Kubernetes

Two of my ERNW colleagues, Lorin Lehawany and Sven Nobis, presented Breaking Multi-Tenancy in Kubernetes Over and Over, and What We Can Learn From This.

I knew the work going in, but i wish i had attended it again. This is only made sadder by the fact that the Kettle talk i attended instead was also at Def Con, so i could've easily switched left it out at Black Hat.. my bad. Lesson filed for next year.

Worth the shout-out regardless, because it's a third instance of this post's whole
thread: an isolation boundary everyone assumes is solid that quietly isn't.
Kubernetes namespaces were originally a scoping mechanism, not a security boundary (RBAC and friends were bolted on later), so "namespace-based multi-tenancy" is soft isolation dressed up as hard isolation. Their paper walks three real, shipping open-source platforms and breaks tenant isolation in each:

• Kubeflow: a contributor in one namespace can create an Istio VirtualService
  that hijacks the shared gateway, swap the dashboard's favicon for an attacker-controlled route, and harvest every user's session cookie and bearer token cluster-wide. Even with the Istio permissions removed (that fix is CVE-2026-47237), a malicious Notebook served from the same origin as the dashboard gets you the same account takeover via plain phishing.
• Istio: because a VirtualService set as a mesh gateway applies its routing rules to every sidecar in the mesh regardless of namespace, a tenant who can create one can machine-in-the-middle traffic belonging to other tenants (addressed in ISTIO-SECURITY-2026-002).
• Traefik: cross-namespace isolation that's enforced for CRDs is silently not enforced for annotation-based references, so an attacker can pull another namespace's middleware or mTLS client cert into their own route and walk straight through the boundary.

The part that makes this generalize (and the reason it's a methodology talk, not
a bug-of-the-week talk) is the second half: a structured way to assess namespace
multi-tenancy (identify every component tenants can touch, map its control-plane and data-plane interactions, evaluate each against the CIA triad), plus the concept of "unobvious" multi-tenancy; the CI/CD runner, the ML platform, the app that runs user scripts, all of which are multi-tenant systems even when the cluster looks single-tenant. That reframing is the transferable insight.

Why it matters if you run Kubernetes. "We use namespaces" is not a tenancy
model. Namespaces separate things for convenience; they don't wall tenants off from each other on their own. And you might be running multiple tenants without having decided to. A shared CI/CD system is multi-tenant. So is an ML platform, or any app that runs user-supplied code. If workloads you don't fully trust share a cluster, you have a tenancy problem to solve, whether or not you set out to build one.

The baseline controls still matter here: RBAC, NetworkPolicies, Pod Security
Standards. Just don't mistake them for a complete answer. They stop the well-known attacks, not the cross-namespace tricks this talk demonstrates. So audit the gaps they miss, look at cross-namespace references in both CRDs and annotations.

Watch for any resource whose reach silently extends past its own namespace (an Istio mesh gateway is the obvious example). Then enforce those rules with admission control like Kyverno or OPA, so a misconfiguration gets rejected instead of shipped.

Whitepaper: Breaking Multi-Tenancy in Kubernetes (Lorin Lehawany & Sven Nobis, ERNW)

On my list to watch (missed it live)

• A 0-click exploit chain for the Pixel 10: sounded like some of the cleanest mobile work of the show. Catching the recording on the 14th.
• The 'Breaking' News: The OpenAI–Hugging Face Incident - A Technical Reconstruction and Its Implications for AI: OpenAI engineers and researchers reconstructing what happened? I'm so sad i missed that one.

Part 2: DEF CON 34

Same city, different register. DEF CON is where the Agency theme actually got argued, and where honestly, I felt more of that generalizing instinct per talk. A few standouts.

Rage Against the Sandbox - Yuval Sadde

Not an exploit so much as a research capability. Sadde rewrote memory to stand up a root shell inside a modern iPhone and run his own unsigned binaries over SSH, bypassing iOS's signing and sandbox model to do it. Sitting in that room watching someone turn a modern iPhone into a place you can just… run things was one of those "the ground shifted slightly" moments.

📌 Possible deep dive, as this is so intriguing but it'll cost me greatly to even understand what's going on haha.

CUDA've Done Better — Daniel Cohen Hillel (@0xDACA) & Noam Trobishi

Root on the host, from the GPU, via a container escape, and the path runs straight through the NVIDIA kernel driver, not the container runtime you'd expect.

The context is Pwn2Own's "NV Container Toolkit" target, where the rules require you to start inside a crafted container image and end with arbitrary code on the host. Of the three attack surfaces they mapped (the Go-based Container Toolkit (logic bugs), the Linux kernel module (a huge amount of complex C with highly controlled inputs), and the GSP, a closed-source RISC-V chip on modern GPUs), they went after the kernel module, which is the part that reorganizes how you think about GPU tenancy.

In the year of everyone renting GPUs for AI, "it's in a container" being one memory-corruption bug away from host root is not a niche concern.

Two things made this the best pure-exploitation talk I saw, and both generalize far past this one CVE. First, they responsibly withheld the bug itself (patch-gap timing) and instead assumed a use-after-free on a Subdevice object, then spent the talk on the techniques to weaponize it, which is the transferable part. The standout is a beautiful trick for winning the exploit race deterministically: because nearly every driver operation takes an "API lock" implemented as a Linux rw_semaphore, and rw_semaphore is writer-preferring (once a writer queues, new readers block behind it, even ones that could share with a reader already inside), they could abuse the lock's own scheduling discipline to force their allocation and their use-after-free into a guaranteed order, turning a flaky race into a reliable primitive.

That's the kind of insight that outlives the specific bug and applies to any race in kernel code guarded by the same primitive.

Second, the payoff. They chained the UAF into a memory-disclosure primitive (leaking every pointer written into the freed object by abusing linked-list unlink operations, with a controllable nodeOffset), located the driver's mmap object, and coerced NVIDIA's own mmap handler into mapping the entire physical address space into userspace: read/write over all of physical memory, from an unprivileged container. (In a nice touch, one bug in the chain was originally flagged as a debug assertion that an object was freed with refcount 0, which on investigation turned out to be the exploitable UAF.) The bugs were found by fuzzing the open-source open-gpu-kernel-modules with Syzkaller across 775 ioctl control commands and 100 GSP-routed commands.

Why it matters if you run GPU workloads.
The mental model most teams carry is that the container is the boundary and the GPU is just an accelerator behind it. This inverts that: the GPU driver is a path through the boundary, reachable from inside the container via ioctl. If you run untrusted or multi-tenant workloads on shared GPUs (the default posture of every GPU-rental and managed-inference platform right now), "it's containerized" is no longer a sufficient isolation story. The practical question to put to your platform (or your own stack): what isolates tenants at the driver layer, not just the container layer? This is a concrete argument for treating GPU nodes as their own trust zone, keeping the driver patched aggressively, and not co-tenanting untrusted workloads on the same physical GPU.

📌 Possible deep dive.. the rw_semaphore race-winning technique is genuinely elegant and worth a standalone explainer, yet again.. understanding what's going on is TOUGH. Let's see.

Dylib Hijacking on macOS: Dead or Alive? - Patrick Wardle

Apple mitigations that don't (properly) hold. It's the Patrick Wardle, and the "is this old technique actually dead?" framing is exactly the kind of generalizable question I was praising above. Strong candidate for a follow-up, and a great researcher to engage with directly if I do.

His books are on my pile of shame though, got to admit that.

📌 Possible deep dive, as i could test for this directly in my https://github.com/mev0lent/hardener tool.

And yes, Kettle again

The HTTP Terminator ran at DEF CON too. Watching it a second time, with the Black Hat framing already in my head, is half the reason Part 1 is built around it. haha.

On my list to watch (missed these live)

• Harvest Now, Decrypt Later: Practical Attacks on PQC Implementations (Aleksandr Krasnov): squarely my wheelhouse; post-quantum crypto is what I keep coming back to, and missing this one stung. High on the recording list.
• Hacking Jetskis - from Sea-Don't to Sea-Doo: my colleagues went to this one, what a fun talk from their descriptions alone haha, I have to see for myself.
• The Defender’s Dilemma: Releasing Dual-Use AI Models as Capabilities Climb: having a Senior Engineer at Google & Anthropic's Deputy CISO discuss "blue vs. red" capabilities of models sounds so interesting, i am looking forward to listening to this discussion.

The takeaway I flew home with

Put the two conferences side by side and a pattern falls out.

Industries are racing to hand agency to AI, into browsers, into product features, into anything that ships, while the researchers doing the best work are doing the opposite: staying in the loop, constraining the automation, and pushing until they find a result that generalizes beyond the demo.

The gap between those two postures is, increasingly, where the interesting bugs live. Agentic browsers, synced passkeys, GPU tenancy, none of these are exactly exotic. They're trust boundaries that got redrawn while everyone was looking at the capability instead of the boundary.

If there's one thing I'm taking into my own work, it's that bar the best talks set: not "did I find a bug?" but "did I learn something that transfers to the next target?" That's the standard I'll be holding the deep dives below to.

What I'm writing next

Turning the promises above into a public roadmap, in order:

1. Pass the Passkey: deep dive. The passwordless attack surface, explained.
2. Building a scaled-down autonomous research loop. Lessons from trying to reproduce the HTTP Terminator's method, not its payloads, on a new bug class.
3. CRA Article 14 × Vegas 2026. What this week's supply-chain and agentic-AI research means for the reporting duties going live in September.

If one of these is the one you want first, tell me, it genuinely shapes the order.

Corrections welcome, especially once the recordings are out. If I misrepresented your talk, tell me and I'll fix it with credit.