Enterprise server platforms are the bedrock of the modern internet. It would stand to reason that the foundation of IT infrastructure, the firmware and hardware of those systems, would be especially well audited and secured against advanced attackers. Unfortunately, history shows that the resilience of these components has suffered from an ever-increasing attack surface and insufficient scrutiny; today, this trend is only accelerating with the mass adoption of complex AI infrastructure at unprecedented rates.

In this work, we focus on analyzing the security of the Data Processing Unit (DPU), which has become ubiquitous in AI datacenters. This computer-in-front-of-a-computer promises to shield its host server by offloading networking, encryption, and security-related logic away from the host processor. But what happens when the DPU itself becomes the weak link? In this presentation, we demonstrate a UEFI secure boot bypass on the Nvidia Bluefield 3 DPU, and use it to build the first known DPU bootkit. We then show how it is possible to launch a DMA attack from the DPU targeting the host.

Microsoft's Resilient File System (ReFS) is a filesystem primarily found on Windows Server machines, designed for large-scale storage with built-in data integrity and resiliency. Its kernel driver parses a complex set of on-disk structures, most of which have very little official documentation, though the ReFuzz paper (2022) provided an extended foundation that proved invaluable during this research. In this talk, I will walk through the internals of ReFS, the strategies used to attack the driver, and the vulnerabilities discovered along the way. Multiple vulnerabilities were found including CVE-2026-49793 and CVE-2026-49792, which can be triggered by just mounting a crafted disk and performing some basic I/O with standard user privileges. The vulnerabilities were found in ReFS on-disk structures, particularly compression-related ones that have never been publicly documented previously.

This talk will walk through the internals of ReFS, the different strategies used to attack the driver, and the vulnerabilities discovered along the way.

Leveraging large language models for vulnerability discovery has become an important paradigm in security research. However, large-scale automated deployment still faces two major obstacles. First, LLM-generated vulnerability reports often suffer from high false-positive rates, creating substantial manual review costs. Second, vulnerability research requires more than report generation: it must integrate discovery, validation, PoC construction, and patch generation. In this talk, we present an end-to-end automated vulnerability research agent system for large codebases.

When using LLMs to audit large codebases, we frequently observe performance degradation as more code is added to the model context, even before the context window is full. Context management is therefore a primary focus of our work. We introduce three context-management mechanisms: reasoning-trace-driven adaptive compression, semantics-aware context separation, and report-directed context construction. With this design, our system identifies substantially more vulnerabilities than Claude Code in our experiments while maintaining a low false-positive rate.

We further extend our system with dynamic validation for Linux kernel vulnerabilities. Using a specially designed harness, the system iteratively debugs candidate vulnerabilities inside a QEMU environment and constructs PoCs capable of triggering KASAN.

For automated patch generation, we use multi-agent collaboration and fine-grained context management to reduce incorrect or incomplete fixes, unintended side effects, and new vulnerabilities introduced by generated patches. By separating patch generation and patch validation into dedicated agents, we establish a review-and-refinement loop that improves patch correctness and completeness.

To date, maintainers have confirmed 90 zero-day vulnerabilities identified by our system across projects including the Linux kernel, VirtualBox, and open-vm-tools. Of these, 62 have been fixed and 51 have been assigned CVE identifiers.

Apex Ghost: Unmasking Online Predators examines how Sadistic Online Exploitation (SOE) and Nihilistic Violent Extremist (NVE) networks identify, groom, and coerce young people—and what cybersecurity professionals can do to stop them. Through real-world cases, Ralph Logan shows how intelligence gaps allow known offenders to continue operating and how Apex Ghost combines threat hunting, open-source intelligence, data analysis, and cross-verified evidence to unmask perpetrators and deliver actionable intelligence to law enforcement. The session offers a stark look at adversary tradecraft, the limits of fragmented reporting, and how the security community can apply its capabilities and partnerships to protect children and drive real-world intervention.

Can higher order descriptive metadata alone aid automated exploitation of code repositories? Or are we stuck waiting for more sophisticated language models? 

A Cyber Reasoning System (CRS) is a program that can use threat information and source code to find and patch vulnerabilities in a code repository automatically. These systems increasingly use large language models for search with great effect, and the solution space for these systems has become very diverse. In this talk I will argue that while there is a very valid space for using a cyber reasoning system to protect key libraries, the solution space it often produces is narrower than desired.

To explore this notion of implementation versus algorithmic flaws in code, we will walk through a cyber security harness that produces code for the Lean 4 proof assistant as an intermediate representation language. The demo will explore this in practice with the Anthropic Glasswing demo harness, displaying the trade offs of using proof metadata as part of a cyber reasoning system. We'll contrast this with a larger parallel system that operates proof metadata in the context of an implementation of OSS-CRS. 

We analyze an AI-native smartphone where a language model acts as an execution layer, perceiving screen content and autonomously performing user interactions (e.g., clicks, swipes) across apps—effectively granting a GUI agent system-level control.

We present a security analysis of this architecture and showcase its security concerns. Despite built-in safeguards around sensitive operations and personal data, we demonstrate that the system can be systematically steered into performing attacker-controlled actions, enabling access to private data (e.g., memory, messages, media) and even participation in multi-stage attack chains.

We further study the evolving defence mechanisms deployed on the cloud side and observe a continuous attacker–defender dynamic and a clear tradeoff between security and usability. Our findings include a prompt-based exploitation technique that remains effective against recent mitigations (as of Feb. 2026), as well as insights into cloud-side logic obtained after achieving root access on the device.

This work highlights the security implications of treating LLMs as execution layers and frames prompt injection as a practical, persistent exploitation primitive in real-world smartphone systems.

Modern inference systems load model artifacts they did not create. A checkpoint from a model hub, fine-tuning vendor, or conversion pipeline is parsed into tensors and consumed by native C++, CUDA, HIP, and Triton code. Offsets, shapes, block sizes, scale counts, and group indices eventually become allocations, loop bounds, and memory addresses. A file can parse successfully while unsafe relationships between individually valid fields remain unchecked.

This talk maps that boundary across vLLM, SGLang, llama.cpp, TensorFlow Lite, ONNX, and quantization tooling. Through public findings, assigned CVEs, maintainer-merged fixes, and matched negative controls, I show recurring failure patterns involving extent disagreement, cardinality mismatch, and invalid index domains. A public GPTQModel case traces checkpoint-controlled state to an out-of-bounds device read at the production Triton dequantization launcher.

The point is not a crash count. It is a reproducible method for separating source hypotheses, loader reachability, native-sink evidence, and demonstrated impact. Attendees leave with a practical approach for treating model artifacts as untrusted input and auditing the native consumers in their own inference stacks.

Counter-UAS is a crowded field, and if your use case and budget can tolerate an expensive, exquisite, or bespoke system, or one that is permanently installed or mounted on a vehicle or trailer, there are many to choose from. Our interest is the low-SWaP (size, weight, and power) end of the counter-UAS space: something small and light that a person can easily carry and set up in minutes, or already has in their pocket. Over the past year we have been exploring how much passive EO detection, tracking, and classification of small UAS you can get out of USB cameras, single-board computers such as the Raspberry Pi, and ordinary mobile phones. We wanted to understand what they can do, whether that holds up under real-world conditions, where their practical limits are, and how they fit as a layer in larger systems without depending on one.

This talk will demonstrate two threads of that work, both in progress. The first is synthetic training data: you cannot collect real imagery of every airframe you may need to recognize, so we render it, starting with 3D models of the airframes. We built those 3D models from photographs, technical drawings and blueprints, hand sketches, and plain verbal descriptions. All of them produced usable training data, and we will show what each gave us and what it cost. The second is the sensors themselves: fixed nodes built from a Pi, an AI accelerator, and a camera, plus an Android app that turns an ordinary phone into an acoustic-cued camera for detection and tracking. We will cover what we learned building and range-testing them, what we changed, and what we are taking back to the range in October.

Every Docker image tells a story, but most developers don't realise how much of that story is written in the .git directories they accidentally ship. After analyzing more than half a million image layers from Docker Hub, we found around 500,000 .git repositories embedded in public images: each one an unintended archive of source code, full commit history, author identities, and hard-coded secrets. Over 228,000 of those images reference private or deleted repositories that were never meant to be visible, now permanently accessible to anyone with a docker pull. This talk presents the methodology and findings of the first large-scale study of .git exposure in Docker Hub. We cover: how git commit metadata enables identity attribution at scale; how 497 self-hosted internal git hostnames, including those of a cloud infrastructure provider, a semiconductor manufacturer, and a GPU vendor, were revealed by images their own owners published; and how ephemeral CI tokens (GitHub Actions ghs_ and GitLab CI job tokens) embedded in git configs can be raced to confirm live access before they expire. We close with concrete mitigations any developer can apply today.