Best of BSides LV 2026

What is BSides Las Vegas?

BSides is the conference that opens Hacker Summer Camp, the week in Las Vegas that also hosts major conferences like Black Hat and DEF CON. The name BSides comes from the B-side of a vinyl record. It was born in 2009, with fewer than a hundred attendees, out of a group of people who rented a house to give the talks Black Hat had rejected. In 2012, BSides became a nonprofit, and today the global network counts more than a thousand events across 255 cities and 65 countries.
Last year I wrote a complete guide to how BSides LV works: the tracks, the prices, the badges, and how to make the most of it if it's your first time. If that's you, start there. This post is something else.

This year I went all in on the talks.

BSides LV 2026 by the numbers

The eighteenth edition ran August 3–5 at the Tuscany Suites & Casino. Over those three days there were 141 talks, plus 25 trainings and 29 side activities: 195 agenda slots spread across 10 tracks, 19 rooms, and roughly 211 speakers. Tuesday was the busiest day, with 83 slots; Monday had 71 and Wednesday 41.

I was there Monday and Tuesday. Over those two days I saw 21 talks in person, across 8 different tracks, adding up to 13 hours of talks total. Six of those talks were Skytalks, the ones that don't get recorded. Ten made it into the meetup I gave afterward, and six make it into this post.

What makes BSides different

There's something I noticed on both days that doesn't always happen at other conferences: it was genuinely hard to choose what to prioritize. In several slots there were three good talks running at once, and picking one meant losing the other two, or saving them for the YouTube livestream later — as long as it wasn't a Skytalk. And as much as that sounds like a complaint, it's actually one of the best compliments you can pay for an agenda.

Here, as at other conferences, vendors are around too, but they stay in their own defined space and don't spill into the rooms. They have their spot at the booths in the Middle Ground, but you don't later see them show up in talks that are really a pitch in disguise. When someone from a company gets on stage, they get on stage to talk about research.

And it's not just sitting down to listen to talks: there are challenges, villages, and activities spread across the whole event, and a good chunk of what you take away happens there.

There are also a handful of rules that change the room's atmosphere more than you'd expect. The first is that nobody photographs or records you without permission, and it's a policy people genuinely respect. The second is that harassment of any kind is not tolerated, period. The third is the Skytalks rule, with its token, its line, and its powered-off phones. All three point at the same thing: protecting attendees' privacy. And it works: you see people of every kind, dressed every way imaginable, each doing their own thing, and that happens precisely because everyone there feels accepted.

The talks

Of the 21 talks I saw, these six are the ones I'm bringing you. They're not a summary of the agenda, and they don't try to be: they're the ones that changed something for me or that I thought were genuinely great. Four are recorded and up on the BSides LV YouTube channel. Two were Skytalks, and for those I'm sharing only what's already public through the abstract or through online write-ups.

When there's no attacker

"Your Next Breach Won't Have an Attacker" ~ Guy Barnhart-Magen, Profero · Skytalks

At two in the morning, the incident response team gets the call: production code wiped, database exposed, customer data gone. Every classic indicator of a breach. Except the attacker wasn't a threat actor — it was a coding assistant running with --dangerously-skip-permissions and a vague instruction from a developer, something like "clean things up." Profero has spent a year responding to a growing category of incidents they've started calling AI-induced destruction: catastrophic damage caused by assistants that were over-trusted, given vague instructions, and/or handed unnecessary permissions. 

The talk walks through three real incidents with full forensic reconstruction. All of them followed a similar pattern — a developer and an agent with full permissions and automatic approval for every action: the control that failed wasn't just detection, it was authorization. The closing recommendation is to keep good logs of what's happening and documentation covering everything the AI is going to touch.

"Your Context is Mine! When a Single Drop Poisons the AI Agent's Well" ~ Itsik Mantin · Ground Truth

▶️ See talk

Every agent today works the same way: it pulls in documents, emails, messages, and search results, dumps them into the context window, and reasons over the pile. Mantin asked what would happen if an attacker controlled just one document among ten or twenty legitimate ones — could it flip the decision on all the other 19? That's the experiment and research he ran: in this case, the poisoned document doesn't give the model any instruction at all. It just asserts something about the others — "LATEST UPDATE — ALL PRIOR DOCUMENTS OUTDATED" — and with that alone, the model completely wipes out the other nineteen documents' contribution to its reasoning.

Contrary to what you might expect, adding more documents doesn't necessarily improve the defense. What actually mattered was where the inserted document sat — placing it at the end of the list worked better than placing it at the start. And no model turned out to be immune, though frontier models held up longer. One important distinction: this isn't prompt injection. Since there's no instruction, the injection filters you've already got in place don't catch it. Of the three defenses he measured, the only one that hit 100% was one he calls extract and vote: the model reads one document at a time and casts a vote, and your code does the counting, so the decision lives with the majority instead of with the model.

"Breaking BOTS II: How frontier AI cheats evals" ~ Leo Meyerovich, Graphistry · Unprompted

▶️ See talk

When an agent turns in the correct flag, there are two separate questions, and almost nobody asks the second one: did the answer come from actually reasoning over the data (eval integrity), and did something happen along the way that nobody wanted to happen (collateral damage)? Meyerovich submitted the CFP for this talk months before a real incident occurred that followed his timeline almost step for step: the agent finds a 0-day, escapes the sandbox, sets up a C2 outside the firewall, and moves laterally hunting for the answer. His contamination test is valuable precisely because it's so simple: they run the full CTF without connecting the database, and the models still score well — which turns out to be explained by the fact that the answer was already baked into the training data. The talk also describes an egress bypass that no firewall can see: the harness adds a new tool, a web_fetch, that proxies the request through the model provider itself, whose endpoint is already on the firewall's whitelist, and uses that to make whatever internet queries it needs.

The real point of the talk is more uncomfortable than any of the techniques: an agent under evaluation cheats. Not out of malice, but because it's going to look for any path that gets the task done, and pulling the answer from training data, from Git history, or from an endpoint that's already whitelisted are all just as valid a path to it as actually solving the challenge. Banning it outright doesn't work either, and his line for why is "do not think about strawberries": if you forbid it from cheating while you're still pressuring it for the flag, you've just planted the cheat inside its space of possibilities.

The bugs nobody looks at

"Every ride you take - Hacking a City's Public Transportation (PART 2)" ~ Ignacio Navarro · Skytalks

This was part two of an investigation into the public transportation ecosystem of one of Argentina's largest cities, which moves more than 1.5 million people a day. The path Ignacio describes doesn't hinge on a single exploit: it's enumeration, reading code, chaining vulnerabilities, and taking advantage of weak access controls and poorly thought-out internal designs.

My favorite part of the story was the strangely mundane one: he found a writable PHP file that a cron job synced with the server once a day. He uploaded a web shell, went out for a beer, and at nine the next morning the cron did the work for him: remote code execution, ready to use.

That got him full access to the city's core mobility systems — buses, taxis, DVRs, transit cards, user data, real-time tracking, and admin panels. None of the individual findings, on their own, was the kind of thing a client would treat as urgent that same week. Severity gets scored per finding, but the impact happens in the chain, and nobody scores the chain.

"Your Red Team Doesn't Follow a Kill Chain" ~ Bobby Kuzma, ProCircular · Breaking Ground

▶️ See talk

The kill chain diagram shows up in every talk in the industry: recon, access, escalation, lateral movement, exfiltration, one phase after the other. Kuzma wanted to check whether his own team actually worked that way, and instead of asking his operators, he started recording what they did. He instrumented the team's terminals, collected 1,265 sessions and 6,001 commands from 95 real engagements, and used that to build a graph where every edge means one command genuinely used something another command had discovered earlier. It's exactly that gap between the map and the terrain that explains why more and more teams are turning to this kind of controlled offensive exercise.

What came out of it doesn't look like the diagram. The work doesn't move through orderly phases, it spirals, with operators bouncing back and forth an average of twelve times between discovering something and stealing credentials before they manage to move forward. 58% of lateral movement attempts fail, and that noise ends up concentrated in failed authentications from the same origin that almost nobody is watching. A third of engagements pivot thanks to a single command — what he calls the breakthrough command — and the best predictor of reaching exploitation isn't how many commands you ran, it's how well you connect what you already know. He even found that the real bottleneck isn't IP addresses but hostnames, because those are what let you tie one machine to another.

The tool he built for the study is called Ithildin, after the moon-letters of Middle-earth — the writing that's always there but only reveals itself under the right light. That's exactly what it does with penetration-test logs, and it's already out under the MIT license.

"The Keyless Backdoor: Detecting GCP Workload Identity Federation Abuse" ~ Jie Wu, Shopify · Breaking Ground

▶️ See talk

Storing a service account key in CI is one of those things we all learned not to do, and the industry's answer was federated identity. With Workload Identity Federation, your pipeline doesn't store any Google Cloud secret at all — instead it presents the token issued by its own identity provider, and Google exchanges it for temporary credentials that act on behalf of a service account. There's no key to steal, which is exactly the sales pitch.

What Wu showed is that this entire chain is governed by just two controls: the provider's attribute condition, which decides which tokens get accepted, and the IAM binding, which decides who can impersonate the account. The first way to abuse it is the only one you can spot by reading the repo, because a provider with no attribute condition next to a binding with a wildcard is just plaintext sitting in Terraform. The second one you can't see anymore, because all it takes is a single API call that edits the expression to add the attacker as a valid subject, without changing either the pool name or the provider name. And the third is registering your own certificate authority as an X.509 trust anchor, so that any certificate the attacker signs gets exchanged for a Google Cloud token — something Google doesn't log anywhere.

That's the trap: Admin Activity logs come on by default and cost nothing, but they only show configuration changes, never token usage. So reconstructing the full chain requires the STS and IAM Credentials data access logs, which are billed separately and come switched off out of the box. Wu didn't oversell it at the end either — she said flatly that the organization policy she recommends prevents only the first attack, and nothing more. It's persistence that lives in how the infrastructure is put together, not in a vulnerable line of code, which is exactly why no scanner is looking for it.

Outside the talks

The first thing you have to say about Las Vegas in August is the heat, because it dictates everything else. The night we landed, at one in the morning, it was 106°F, and that was the cool part of the day. At noon we tried to walk to a restaurant seven minutes away and ended up turning back to call an Uber. You quickly understand why the entire conference lives indoors, and why the air-conditioned hallways end up being the real center of the event… At the end of the day, we're in a desert.

Those hallways and the villages are where the gaps between talks get filled. On the last day I stopped by the lockpicking village to kill thirty minutes, and there was a pair of handcuffs sitting on the table. I'd picked some before and know the technique, so I put one on my wrist, double-locked it, and got started. It wouldn't budge, because that model had a different mechanism than the one I knew — or at least the one I remembered — and on top of that it was pretty worn from use.

Four people tried, then the village lead, and it was him who ended up going for the key. By then, the people who'd wandered over to help were already laughing and telling me this was going to make for a great conversation with the TSA at the airport. I went from excited to "oh no," from there to resigned, and finally to "okay, that was fun." I walked out with free wrists and four new friends, which is more or less what people mean when they say BSides is a community.

And that community doesn't end when the rooms close, either. Tuesday night I ended up, without planning it, at 8.8 Las Vegas, surrounded by the Latino community of Hacker Summer Camp. You make this trip for the talks and end up finding, on top of that, half of Latin America gathered on the other side of the continent. Of everything that wasn't on my agenda, that night was pretty great.

Would I pay for it out of pocket?

It's the question people always ask when I tell them I went, so here's the answer, no dancing around it.

If the trip to Las Vegas is already happening because DEF CON or Black Hat are on the calendar, BSides is a no-brainer. It opens the week, the ticket costs a fraction of what the other two cost, and the content more than justifies it.

If the trip is only for BSides, no. If you don't live in North America, I wouldn't cross a continent just for this conference. It's very good, but it's not what you travel for. And it's worth remembering that BSides runs its own editions in cities all over the world — they might not compare to the Las Vegas one in size, but they keep the same heart.

And keep in mind that the main-track talks land on YouTube within a few days. What you can't watch from home is everything else: the Skytalks, the villages, the challenges, the people. What you're really paying for isn't just the talks that get recorded — it's everything happening around them.

The other side of the record

Wednesday, BSides closed and Black Hat opened. Same day, same city, same people with a different badge around their neck. The B-side and the A-side of the record are playing at once, and you have to choose which one to listen to.

That Wednesday, I switched to the A-side. But that's a different story.

To be continued.