OWASP Global AppSec EU 2026 Vienna

When an attacker lands on a user’s machine, your SSO should not hand them the keys to your network. Yet many enterprise systems do because they assume localhost subdomains are safe. They are not.

This talk shows how a common DNS misconfiguration (localhost.target.com → 127.0.0.1), combined with domain-wide cookies (Domain=.target.com), allows a locally executed request context to inherit an authenticated session. No XSS. No phishing. Just browser-native behavior.

This flaw is rarely detected by scanners or standard penetration tests, yet it appears in real enterprise deployments today. The session presents a practical testing methodology, a defensive checklist, and research-based validation techniques to assess this class of trust boundary failure safely.

Attendees will leave able to identify and fix this issue in their own SSO deployments next week.

AI app builders now enable production apps to ship without repositories, CI/CD, or security review, often by non-traditional developers outside established engineering workflows. These Shadow AI apps bypass AppSec pipelines and governance, creating a growing blind spot in enterprise environments. This talk demonstrates how DNS, TLS, and hosting signals can detect shadow AI apps that existing controls miss.

WebAuthn was supposed to replace passwords on the web: uniform, secure, manageable authentication for everyone! One of its unique selling points was supposed to be the impossibility of phishing attacks. When Passkeys were introduced, some of WebAuthn's security principles were watered down in order to achieve some usability improvements and thus reach more widespread adoption.

This presentation discusses the security of Passkeys against phishing attacks. It explains the possibilities for an attacker to gain access to accounts secured with Passkeys using spear phishing, and what conditions must be met for this to happen. It also practically demonstrates such an attack and discusses countermeasures.

Participants will learn which WebAuthn security principles still apply to Passkeys and which do not. They will learn why Passkeys are no longer completely phishing-proof and how they can evaluate this consideration for their own use of Passkeys.

Security testing of GenAI systems is often reduced to "LLM red teaming": probing a model in isolation to see what unsafe/offensive content it will generate. In practice, this approach falls short. As security practitioners, we need to assess complete LLM application use cases, focusing on how inputs and outputs propagate through application logic and enable concrete security risks such as data exfiltration, cross-site scripting, and authorization bypass.

In this talk, we share practical experience and supporting open-source tooling we developed for assessing LLM applications. These focus on testing systems where the LLM is embedded in application logic rather than exposed as a simple inference endpoint.

It covers approaches for testing non-conversational GenAI workflows, WebSockets, and custom APIs; building scoped prompt injection datasets aligned with application logic and engagement constraints; applying effort-based jailbreak techniques (e.g. anti-spotlighting, best-of-n, crescendo, ...) to evaluate guardrail robustness and demonstrate practical bypasses; and conducting meaningful testing in isolated or air-gapped environments.

Agentic browsers are quickly becoming one of the most powerful—yet dangerous—applications of agentic AI. By combining web navigation, content interpretation, and direct action taking, they act as a universal gateway to almost any service or application on the internet.

That power quietly reintroduces web security risks many teams assumed were behind us. Agentic browsers read and react to untrusted web content, follow instructions embedded in pages, images, and hidden text, and then execute actions inside real sessions.

The result is that classic web attack patterns made popular 20+ years ago when the first OWASP Top 10 was introduced may be back.

Things like injection manipulations, cross-site scripting payload delivery, CSRF-style action abuse, broken access control, and cross-origin boundary failures—now executed by autonomous agents instead of users.

This talk examines why current agentic browser designs break core web security assumptions around origins, cookies, and session boundaries, and why common mitigations such as human-in-the-loop controls introduce friction and fatigue without solving the underlying problem. We'll argue that unrestricted multi-site agents are fundamentally unsafe, and share better approaches based on domain-scoped agents, strict isolation, and secure multi-agent orchestration.

When AI coding tools entered mainstream development, the application security community reacted fast and loudly. Many warned that AI would dramatically increase vulnerabilities. The most common argument was simple and intuitive. AI models were trained on vast amounts of real-world code, including insecure and vulnerable code. Garbage in, garbage out. If AI learned from vulnerable code, it would inevitably reproduce those vulnerabilities at scale.

This claim quickly became accepted wisdom, despite the fact that almost no one could actually prove it.

This session presents a data-driven examination of that assumption. By correlating reported security vulnerabilities with automated line-level code attribution, we were able to determine whether a vulnerability originated in AI-generated code or human-written code. This allowed us to move the discussion from fear and intuition to measurable evidence.

The results are more nuanced and more interesting than the prevailing narrative suggests. In some scenarios, AI-generated code showed higher vulnerability density. In others, it performed comparably to, or even better than, human-written code. The differences are not accidental. They correlate strongly with the model used, the tooling, and how developers interact with AI, rather than AI usage alone.

This talk challenges the notion that AI coding is inherently insecure. It replaces the garbage-in, garbage-out argument with concrete data, identifies where the real risks actually emerge, and explains what this means for modern AppSec strategy. Attendees will leave with evidence they can use to recalibrate policies, controls, and conversations around AI-assisted development, without slowing teams down or relying on assumptions.

Penetration testing is a crucial part of application security practices, yet attackers often succeed in ways no test ever reported. No injection, no memory corruption, no failed authentication. The applications behaved exactly as designed — and that was enough.

In this talk, we will explore what penetrating testing is intended to detect and how attackers actually compromise the systems. This talk will address why well-scoped penetration testing frequently revealed "no critical findings" while attackers later leveraged legitimate workflows, permission assumptions, and trust boundaries to cause serious harm.
Based on real world examples and post incident analysis, this talk will walk through security issues that were frequently overlooked during testing, not because testers lacked skills, but because the testing process made assumptions that attackers did not follow. We will focus on examining the blind spots in the penetration testing process, which include behaviors that only appear in production, cross-feature chaining, abuse of business logic, and trust assumptions built into system architecture.

The objective of this talk will be to comprehend where pen testing ends and how defenders might modify their testing tactics accordingly, rather than to replace it. This talk will break down the classes of issues pen tests routinely miss, how attackers discover them post-deployment, and what changed when testing strategies shifted from endpoint coverage to adversary-aware validation.

Attendees will leave with practical techniques to evolve their AppSec testing without increasing cost or abandoning penetration testing.

OWASP Demo Lab - Hands-On Workshop / Small Group Session
Zone 1

Internal development teams and external suppliers love producing binaries for ease of deployment and distribution. Binary formats, however, make security analysis and compliance more complex for the security and OSPO teams. The good news is that the team behind OWASP dep-scan maintains a couple of binary analysis tools (OWASP blint and OWASP dosai). We show how these two tools can help defenders find strange things in binaries and help with your software transparency journey.

The session will be technical showcasing blint and dosai to analyse complex binaries to identify capabilities, risks, and threats. Users can walk away with new knowledge about modern techniques related to binary SBOM generation, Source line to Assembly instruction mapping, security capabilities analysis, and more.

https://github.com/owasp-dep-scan/blint
https://github.com/owasp-dep-scan/dosai

Kubernetes features are moving fast, and its networking layer is constantly adapting for all new kinds of workloads. However we still lack a basic but essential feature: a way to filter and protect incoming web traffic.

The Gateway API is the natural place to add security, and many enterprises mandate such a thing. In this session, we introduce a new project that connects OWASP Coraza WAF directly with Kubernetes.

Join us to learn more on how Coraza Kubernetes Operator is proposing to bring the well known CoreRuleSet (CRS) filtering approach to Kubernetes, on a structured way, allowing cluster and gateway admins to provide traffic filtering on Gateway API and lift the security features to another level.

This is the story of a single CI bug with the potential of compromising more than 10 million workstations - with a full takeover - for anyone using popular tools like Cursor and Windsurf (so every developer, really).

Learn about a critical flaw - that will be shared by the team who first identified it - in [open-vsx.org](http://open-vsx.org/), the open-source marketplace powering nearly every VSCode fork, including Cursor, Windsurf, Gitpod, StackBlitz, and Google Cloud Shell Editor.

The vulnerability sat in the project's GitHub Actions workflow, which automatically builds and publishes extensions using a privileged service token. By triggering the workflow with a crafted dependency, an attacker could run arbitrary code during npm install, exfiltrate the marketplace's OVSX_PAT token, and use it to overwrite or republish any extension in the registry. From there, the blast radius is absolute and devastating.
Any developer using a VSCode fork that auto-updates extensions would receive malicious payloads without interaction — compromising local machines, CI/CD environments, and downstream software.

This session breaks down the exploit path, the disclosure timeline, and the architectural weaknesses that made it possible. It highlights the systemic risk of ungoverned extension ecosystems and how "app store" mechanics in developer tooling have quietly become high-value attack surfaces.

But don't panic. We'll wrap with concrete mitigations like: isolating build runners from publishing credentials, auditing workflow environments for untrusted dependency execution, and implementing continuous marketplace governance to prevent similar full-ecosystem takeovers.

Your AI agent has access to your database, your APIs, and your users' data. But would you give a new hire admin credentials on day one? We do this with AI agents constantly - deploying them with full system access before they've proven they won't hallucinate a DROP TABLE or leak sensitive data to a prompt injection attack.

Guide dog training programs solved this problem decades ago. They take untested puppies and transform them into autonomous agents trusted to make life-or-death decisions - through a systematic process of graduated trust. A guide dog doesn't get to navigate traffic until it's mastered basic commands. It doesn't work unsupervised until it's proven reliable across thousands of scenarios. And critically, it's trained in "intelligent disobedience" - knowing when to refuse a direct command because following it would cause harm.

In this talk, I'll introduce the Progressive Trust Framework - a practical approach to AI agent deployment inspired by 90+ years of service animal training. You'll learn how to implement graduated permission systems where agents earn expanded access through demonstrated reliability. We'll explore the "3 D's" testing methodology (Distance, Duration, Distraction) for validating agent behaviour before promotion. And we'll tackle the hardest problem: training agents that refuse harmful requests without becoming unhelpfully paranoid.

Whether you're building autonomous coding assistants, customer service bots, or internal automation tools, you'll leave with concrete patterns for deploying AI agents that earn trust instead of demanding it. Because the question isn't whether your AI agent will make mistakes - it's whether you've built the guardrails to catch them before they hit production.

This session highlights our 6-year journey of building and sustaining a Security Community of Practice (CoP) from the ground up. We shifted from a project-centric organization with detailed, mandatory quality gates to an Agile model. This challenged us to scale and approach our self-reliant tribes in a new way. We will share which concepts worked and which were scrapped after initial trials. Additionally, we will deep dive into how we used CTFs for continuous content creation usingself developed and readily available challenges. We evolved from a manual "mail-in your solutions" approach to leveraging platforms like OWASP Juice Shop and OWASP UnCrackable Apps, creating a consistent content source and an engaging game experience for all our Security Champions.

As AI transitions from stateless tools to autonomous agents, the context window has become the primary attack surface. By giving agents the ability to remember, summarize, and collaborate, we have created a machine that can be gaslit. This session moves beyond transient prompt injections into the realm of persistent memory corruption. We explore how an adversary can rewrite an agent’s history, bias its knowledge base, and plant sleeper instructions that trigger long after the initial interaction. We will dissect the systematic subversion of the agentic memory stack and demonstrate why developers must stop treating agent memory as a passive data store and start defending it as the engine of the agent’s survival

Most teams don’t have a "container security problem." They have a "Dockerfile hygiene" problem that quietly becomes a supply chain problem. Dockerfiles are often treated as simple build instructions, but in practice they introduce real security risk. Even teams with mature AppSec programs regularly ship Dockerfiles that run as root, rely on untrusted base images, or hide supply-chain risks inside multi-stage builds. Scanners catch many of these issues, yet the same mistakes keep showing up.

In this talk I will share lessons learned from building and using DockSec, an open-source Dockerfile security analysis tool adopted by OWASP, in real development pipelines. The focus is not on introducing a new scanner, but on understanding why Dockerfile issues persist and what actually helps developers fix them.

Using real examples from production pipelines, I’ll walk through common Dockerfile patterns that lead to security problems and explain how those risks translate into real attack paths. I’ll also discuss what worked, and what didn’t, when trying to integrate Dockerfile security checks into CI/CD without slowing teams down or turning security into a constant blocker. I will also cover what "good" looks like in CI: turning findings into developer-friendly feedback, using policy gates sparingly (and correctly), and keeping scan noise under control.

This is not a product demo or a sales talk. It’s a practical discussion about Dockerfile security, developer behavior, and how AppSec teams can reduce repeat mistakes using clearer feedback, better explanations, and OWASP-aligned guidance. Attendees should leave with concrete ideas they can apply immediately, even if they never use DockSec.

Organizations deploying GenAI systems quickly discover that safety controls do not automatically enforce organizational policies. Real environments operate under large and evolving sets of domains, organization-specific and external policies driven by legal requirements, industry regulations, and internal governance rules, and they change periodically. Enforcing these rules in production is not a one-time setup problem; it is a continuous governance and operations challenge.

Existing guardrail solutions are not designed to handle custom, large-scale, and continuously evolving organizational policies. When AI agent developers or AI security teams attempt to stretch these safety-oriented systems into general policy enforcement, their underlying design assumptions no longer hold because they assume a small, static policy space rather than a broad and heterogeneous one. Static rules such as regex become unmaintainable and produce unreliable detection at scale, fine-tuned classifiers require constant retraining, and LLM-as-a-judge pipelines, even when carefully calibrated, are expensive to run, introduce non-trivial latency and are difficult to audit.

This talk describes how we stress-tested existing compliance approaches, including static guardrails, fine-tuned detectors, and LLM-as-a-judge pipelines, and analyzed how they degrade under realistic policy complexity.
We present a reframing of the problem: instead of relying solely on output-level judgments, policy violations can also be detected directly in the model’s internal space with a training-free approach. We explain what this shift enables in practice, including continuous compliance monitoring, policy updates without retraining loops, and improved auditability. We also discuss the limitations of this advanced approach.

We also address a deeper conceptual issue that emerged from our error analysis: in practice, the boundary between “policies” and “instructions” is often unclear, and treating instructions as if they were policies leads to confusing and brittle failure modes. Today, both alignment boundaries and performance or business objectives are commonly expressed using the same mechanism—rules or instructions—blurring fundamentally different concerns under a single notion of “policy.” This separation is critical: some instructions define organizational and alignment constraints, while others encode task goals and performance requirements. Conflating these concepts results in misaligned controls, as they require different enforcement strategies and, in many cases, different ownership and roles within the organization.

The goal of this talk is to provide AppSec and GRC teams with a clearer mental model for operating LLM policy compliance in production, a checklist of questions to ask about existing guardrail solutions, and a better understanding of what it actually takes to keep LLM systems compliant over time.

There is a common saying that "every problem in cryptography can be reduced to key management problem". OWASP's Cheat Sheet series even has a whole document dedicated to "Cryptographic Storage". What if we could make life easier for us in this area?

TPMs (Trusted Platform Modules) have been a fixed part of every standard PC for many years, providing all users with a "free" hardware that can be used for all kinds of cryptography.
They are already widely in use by most operating systems and firmwares, but haven't really found usage for userspace applications yet.

This talk elaborates why this is the case and how to change this fact. We are going to discuss the capabilities of a TPM and demonstrate them live with a sample application, a TOTP client which stores its secrets securely.

Drawing on large-scale telemetry from real-world production environments, this talk examines what modern application and supply-chain security actually look like in 2025–2026. The data paints a clear picture: many organizations ship vulnerable dependencies, exposed secrets remain surprisingly common, infrastructure logging is frequently incomplete, and malicious packages can reach production environments.

We’ll connect these observations to recent supply-chain incidents, from SolarWinds to self-replicating npm worms, and explore why vulnerabilities often persist long after disclosure. More importantly, we’ll discuss which security controls measurably reduce risk in practice, and which tend to generate noise without improving outcomes.

This talk focuses on the gap between defensive effort and attacker leverage - where defenders lose time, and where attackers gain scale.