Schedule

Abstract

A full-stack teardown of a commercial EV charger, from default credentials in the installation guide through to unauthenticated control of the AC power contactors.

This research covers multiple pre-auth RCE vulnerabilities including a Bluetooth attack requiring no network access, an unauthenticated manufacturing test mode that bypasses every safety interlock on the charger, and a design flaw that puts all safety mechanisms in a single Linux process with no independent hardware verification.

The affected firmware platform is used by multiple resellers globally. A single broadcast UDP packet can disable ground fault protection across an entire fleet.

Speaker

Abstract

Passkeys promise a cleaner future: no shared secrets, less phishing, and fewer humans being blamed for typing passwords into convincing nonsense. But what actually makes a passkey secure?

In this talk, I’ll use a small FIDO2 authenticator built on cheap microcontroller hardware to explore what is actually happening when a passkey is created and used. I’ll show the project, explain how it was put together, and use it as a practical way to examine where trust really lives in a passkey authenticator. Because a device can work perfectly and still be a terrible place to put your trust.

We’ll look at the security boundaries around private key storage, firmware, physical access, hardware, supply chain and the assumptions we make about the authenticator itself. Because “phishing resistant” does not mean “magically secure”. Attendees will leave with a practical mental model for how passkeys work, why they resist phishing, and where the remaining security boundaries sit.

For anyone who wants to build one themselves, I’ll provide the project resources and hardware details afterwards.

Speaker

Abstract

Go is pretty safe by default — mostly — which is exactly why the subtler problems go unnoticed. This talk picks up where our two-part Golang code review notes blog posts left off, hunting for the footguns that slip past code review, the compiler, and your linter alike. We’ll walk through representative examples from each part of the blog series — such as ReverseProxy dropping auth headers when an attacker sets the right Connection value, and silent integer overflows that only misbehave on certain architectures — before turning to the broader set of standard-library and web-layer pitfalls the rules cover.

We will then talk about how we used the Semgrep rules made during this research across a large slice of the most popular open-source Go projects on GitHub — the libraries and infrastructure much of the software supply chain quietly depends on. You’ll hear how the rules were written and tuned to survive real codebases, which footguns turned out to be widespread versus genuinely rare, and what that says about the gap between the language getting safer and anyone actually adopting the safer patterns. You’ll leave with the rules, the method to run them against your own dependencies, and a sharper eye for the Go patterns worth auditing by hand.

Speakers

Abstract

You land on a Spring Boot Admin console managing hundreds of containers. The environment is heavily restricted: there is no file upload functionality, no writable web root, no log poisoning opportunities, and zero usable CVEs. So, how do you get a shell?

This technical walkthrough dives deep into the internals of Java Spring and Tomcat to explore what happens when you are forced to rely entirely on first-principles thinking. Instead of hunting for traditional memory corruption bugs, this talk breaks down how these servers operate by design.

By dissecting a highly predictable behavior in Tomcat’s internal mechanics and chaining it with exposed Jolokia JMX endpoints, we will explore how to turn expected server state into exploit primitives. Join this session to see how a perfectly timed race condition can weave intended features together into a reliable path for Remote Code Execution.

Speaker

Abstract

OpenClaw is the most popular AI agent framework of the year, with 390,000 GitHub stars. Install it, hand it your API keys, OAuth tokens, database credentials and private keys, and a single agent will run your email, calendars, shells, cloud accounts, messaging and payment tools for you. That is the appeal, and that is the problem. These agents only work well when they are over-privileged, so users grant everything and least privilege quietly disappears. Adoption was viral. Security was an afterthought.

Early 2026 showed what that costs. ClawHavoc pushed over a thousand malicious skills into the OpenClaw marketplace, and an exposed Moltbook database leaked roughly 1.5 million API keys. The response focused on scanning skills before publication. Nobody was asking where the stolen data was ending up, so I went looking. To date I’ve identified close to 3,000 leaked secrets across nearly 1,400 breaches.

The biggest pattern is OpenClaw leaking itself: Firebase and GCP keys embedded in agent JSON configs, gateway tokens committed as environment variables, session logs pushed to version control with auth tokens still intact, and SOUL.md personality files exposing the agent’s system prompt with credentials baked straight in. And because an agent never leaks just the AI parts of an .env file, everything else comes with it: AWS IAM keys, live Stripe keys, GitHub PATs, database connection strings, SSH private keys. On the exfil side I’ll cover Telegram bot exfiltration with the bot token embedded in the skill, a long tail of drop services, and hardcoded C2 ranges.

Once the find rate held up I built BreachClaw, a free live hunter anyone can use to check their own exposure by email or by SHA-256 hashed secret. I’ll walk through what it has found so far, which types of keys leak most, and run a short live demo.

I’ll close on reinstating least privilege. Agents need broad access to be useful, for now, so the practical move is to automate the things where a breach wouldn’t be catastrophic, treat every privilege you grant as a breach waiting to happen, stick to official skills, rotate credentials, and monitor the output side so you find out when something leaks rather than when someone uses it.

Speaker

Abstract

In this talk, Danielle will introduce the concept of path dependence in a technology setting. Using three examples of network protocols (BGP, ARP, and Spanning Tree Protocol) that have shaped and constrained later network capabilities and introduced significant challenges to securing networks, she will explain why path dependence can be useful as a lens for understanding how legacy technologies cause many of the security issues of today. The audience will be encouraged to reflect on how they can think critically to reduce the impact of their present assumptions on the security posture of technologies being developed using several key questions.

Speaker

Abstract

Remember Copy.Fail (CVE-2026-31431), the Linux Kernel vulnerability that went viral earlier this year? If you missed it, here’s all you need to know: it was a local privilege escalation bug found by researchers at Theori; for the past 10 years, almost every kernel from every major distro was vulnerable; the bug was exploitable with a 732-byte Python script with 100% reliability; and over the weeks following disclosure, numerous variants were found. Of course, online discourse was fuelled by the fact that it was one of the first critical Linux kernel bugs found using AI.

In this talk, I’ll break down what the Copy.Fail bug is, how it was exploited, discuss the variant vulnerabilities, and give my thoughts on the future of this bug class in general. The hype cycle may have now passed, but I think it’s still a very interesting bug, and taking the time to understand it properly can lead to interesting insights.

Never looked at the Linux kernel before? Don’t worry – there is absolutely no code in this talk. I’ll be explaining all of the core concepts from the ground up, and every slide is filled with hand-drawn diagrams to help you understand what’s going on.

Speaker

Abstract

A short presentation to set the stage on AI security, followed by audience Q&A.

Speaker

Abstract

This presentation will dive into the murky world of corporate shell companies, tax havens and the lengths companies will go to, to hide their true identities from their customers and appear legit. During this investigation the same name would continue to appear: Igor Gilmutdinov… but who is he?

Speaker

Abstract

TACACS+ is 42 years old and almost nobody thinks about it, yet it is still how most telcos, ISPs and large enterprises authenticate admin logins across every router, switch and firewall they own. Last year’s CISA advisory on Salt Typhoon has them harvesting credentials straight off TACACS+ servers. This talk covers a pre-authentication format string vulnerability that sat for 25 years in the daemon behind a large share of those deployments, giving code execution as root, along with the trick that recovers the shared key first so you can get there without credentials.

The rest is a case study in how software security works for critical services in 2026. The bug class was solved in 2001 and compilers have caught it for 20 years, none of which helps when nobody owns the code. Getting a fix out took several months of disclosure, across an archived project at Meta, a vendor who wasn’t answering, and Cisco PSIRT confirming the code hadn’t been theirs for decades.

Speaker

Abstract

In this presentation Bruce will outline the case for why Critical Infrastructure operators need to do purple teaming to ensure they are defensibly managing cyber security risks for their Operational Technology (OT).

This presentation will start with a primer on purple teaming and walk through how critical asset operators should develop purple team assessments for their OT systems. This presentation will discuss methods to gather relevant Cyber Threat Intelligence to inform their assessments. Critically for asset operators this presentation will discuss why purple teaming needs to happen in a representative test lab environment initially to give teams confidence in their assessments. The presentation will discuss useful tools and techniques to support asset operators plan and execute their purple team assessment and finally Bruce will discuss how he built his home lab to support this presentation.

Speaker

Abstract

Research and development into preventing supply chain attacks for all developers, which resulted in creating a tool that can prevent the installation of likely poisoned packages.

Tool: github.com/DerpyDinosaur/leukocyte

Speaker

Abstract

AI agents are no longer just generating text; they’re writing code, executing it, installing dependencies, calling APIs, and operating inside your infrastructure with varying degrees of autonomy. Products like coding assistants, autonomous dev agents, and tool-calling LLMs need to run untrusted, dynamically generated code as a core part of their functionality.

The AI workloads being non-deterministic means the user can manipulate the underlying system more easily and achieve a greater impact. Hence, it demands a fundamentally different approach to isolation.

And when we think of isolation, the first thing that comes up is sandboxing. But the word “sandbox” is doing a dangerous amount of heavy lifting, and it hides an enormous amount of complexity. How does one properly “sandbox” an AI-native workload? What are the common trade-offs, mistakes and architectural best practices?

This talk is a practitioner’s guide to getting sandboxing right for AI workloads, built from our experience building & securing AI products at Atlassian.

We’ll do a practical walkthrough of building a AI sandbox: what are the major isolation layers, explain what the trust boundary actually is, showcase how we evaluated and selected solutions at each layer for our AI products, and then drive the point home with mock vulnerabilities representative of real bugs we’ve seen in the industry, while building our own products.

You’ll see how a security & engineering team actually reasons through the complex challenges of sandboxing a non-deterministic workload. We’ll share the trade-offs we hit, the assumptions that broke, the actual vulnerabilities they caused, and the architectural decisions that survived contact with reality. So gather along and come hear our tale.

Speakers

Abstract

Fooling people through lies, scams, and manipulation are at the heart of many cyber attacks. A team of Year 6 (11 and 12 year old) students uncover what it means to be fooled, share our findings on fooling humans vs AI, and unpack the hypothesis that kids today are more likely to be fooled by technology than any generation previous. You’ll leave with an understanding of what we believe kids need to learn and some inspiration for future solutions.

Speaker