Planet CCC - Blogs and more around CCC, CCC-Hamburg and Attraktor

Das offizielle Opening der Quellc0d3. Wir werfen zu beging einen blick zurück auf das letztjährige Event und geben einen kurzen Überblick was euch die nächsten tage, erwartet. https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://pretalx.0x90.space/quellcode-2026/talk/JJRZWS/

Video:quellc0d3-53-deu-Opening_sd.mp4

Science depends on knowledge being shared, discovered, scrutinized, and built upon. Yet much of today’s scientific literature remains locked behind paywalls and is mediated by a handful of commercial publishers and platforms that increasingly control how research is accessed, organized, and made visible. In this talk, we examine how the current scholarly publishing ecosystem emerged, why it has become increasingly dependent on proprietary infrastructures, and what this means for science and society. We also introduce _paperstacks.io_, an open European infrastructure developed at Technische Hochschule Nürnberg for discovering, organizing, and sharing scientific knowledge. https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://pretalx.0x90.space/quellcode-2026/talk/MAY8KV/

Video:quellc0d3-34-deu-Who_Owns_Science_On_Paywalls_Publishers_and_paperstacksio_sd.mp4

Research shows that up to 50% of security fixes in open source repositories are committed silently — no CVE, no advisory, no changelog entry — and more than 10% have active exploits in the wild before anyone outside the project knows (Li & Paxson, CCS 2017; Dong et al., DSN 2025). Traditional detection techniques like binary patch classifiers can tell you whether a patch is a security fix — but not what the vulnerability was or how to exploit it. Until now, reconstruction still required a skilled analyst and hours of work. This all changes with the advent of Large Language Models. In this talk, we present Lacuna, a tool that diffs two versions of an npm, Maven, or PyPI package and runs a three-phase LLM pipeline to produce a full vulnerability reconstruction — attack scenario, CWE, CVSS vector — and determine whether it was ever disclosed. In our testing, roughly one in six version bumps in popular packages contained undisclosed security fixes — including packages with tens of millions of weekly downloads. We found silent fixes for SSRF, prototype pollution patches described as a performance improvement, and a critical TLS bypass update with no changelog entry at all. The uncomfortable implication: any attacker with enough tokens can turn a silent patch into a working exploit. Maintainers who have relied on quiet fixes to buy their users time need to reckon with that. When the window between patch and working exploit has collapsed to minutes, publishing an advisory is no longer optional. Without a CVE, your SBOM lists the dependency clean and your software composition analysis scan stays green. That raises a question the industry hasn't fully answered: should tools be analysing what actually changed between versions, not just what was disclosed? Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110770-eng-Silent_but_Deadly_Reconstructing_Undisclosed_Security_Vulnerabilities_in_Public_Package_Registries_sd.mp4

CI/CD pipelines have become prime targets for supply chain attacks, enabling persistent compromise of distribution builds and secrets. In the GitHub Actions ecosystem specifically, documented attack techniques typically focus on developer mistakes, such as environment injections and pwn requests. However, research scanning Docker Hub has revealed a different class of vulnerability: over 240,000 GitHub authentication tokens leaked through a seemingly benign workflow pattern using legitimate, official actions, in particular the combination of actions/checkout and the common COPY . Docker antipattern. This presentation will explain the complete vulnerability chain from workflow execution to token exposure, demonstrate exploitation techniques that overcome default security mechanisms — racing against token expiration while exploiting elevated workflow permissions — and provide a multi-layered defense strategy including critical action version updates and Docker hardening best practices. Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110769-eng-Race_Against_The_Workflows_Stealing_GitHub_Tokens_from_Docker_Images_sd.mp4

Kubernetes is the backbone of modern applications with a very fast development cycle. To address new threats the OWASP Kubernetes Top 10 received a major update in 2025. This session brings these theoretical risks to life. We will review the new 2025 security risks and explain how they work. Then we move into action. Through live practical demonstrations you will see how attackers exploit these flaws to steal secrets, escape containers, or take over whole clusters. For every attack shown we immediately switch to defense. You will learn how to detect these malicious actions and protect your workloads using cloud native tools. This presentation is for engineers and security professionals who want a clear understanding of the new 2025 OWASP standard combined with hands-on hacking and defense. Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110768-eng-New_OWASP_Kubernetes_Top_10_in_Action_and_Explained_sd.mp4

Due to the rise of memory-safe languages like Rust, attention shifts towards logic bugs, which do not arise from insecure memory accesses. Identifying these bugs in large and complex codebases is hard, because bugs are mainly triggered by rare edge cases. Fuzzing is a great technique to induce random behavior and observe the edge cases in the application logic that are prone to logic bugs. However, fuzzing logic bugs requires a bug oracle, to detect whenever the application behavior deviates. Such models are hard to define, if they must infer correct or incorrect behavior based on the applications output. We propose a different approach: Oracles can be implemented effectively by applying small patches on the target application, because they can be defined as invariants that must hold across all random executions. This talk presents this approach exemplary on recent work, detecting site isolation bypass bugs in web browsers. Site isolation is one of the core security mechanisms of modern browsers. When using site isolation, the browser confines all processing related to a site to its own sandboxed renderer process. This, however, requires the central browser process to keep track of which renderer process belongs to which site. Logic bugs in this implementation, allow attackers to leak sensitive data, such as cookies, or achieve Universal Cross-Site Scripting. We implemented two oracles, the leak sanitizer and the process sanitizer, that detect a wide range of site isolation bypass bugs. Combined with a fuzzer that targets edge cases in cross-site communication and navigation, our oracles detected four site isolation bugs in Chrome and Firefox. This basic approach generalizes to other complex applications and classes of logic bugs. In this talk, we will explore how to set up a fuzzer for logic bugs and to inspire you to find logic bugs in more complex applications. Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110767-eng-How_To_Fuzz_for_Logic_Bugs_Building_Effective_Oracles_-_A_Case_Study_on_Site_Isolation_Bypass_Bugs_sd.mp4

Implementieren Sie OAuth noch nach einem Spec von 2012? Dann ist Ihre Anwendung vermutlich unsicher! OAuth 2.0 hat sich in 13 Jahren durch ein Labyrinth von RFCs und Best Practices entwickelt – Implicit Flow ist deprecated, PKCE ist Pflicht, Password Grant ein No-Go. Aber wer weiß das schon alles? OAuth 2.1 räumt endlich auf: Ein Draft, der alle modernen Security Best Practices vereint und unsichere Flows eliminiert. Klingt perfekt? Ist es auch! Nur leider wendet ihn fast niemand an. In diesem Talk zeigt Ihnen Martina Kraus, warum OAuth 2.1 Ihre OAuth-Implementierung von Grund auf sicherer macht, welche Breaking Changes auf Sie warten und wie Sie schon heute damit arbeiten können. Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110766-deu-Zeit_fuer_OAuth_21_-_Security_Best_Practices_als_neuer_Standard_sd.mp4

Der Cyber Resilience Act (CRA) stellt Sicherheitsanforderungen an Hersteller und Anbieter von Produkten mit digitalen Elementen. Viele Unternehmen haben bereits ein grundlegendes Sicherheitsniveau, doch der gezielte Abgleich mit den CRA-Anforderungen ist aufwändig und zeigt häufig unerwartete Lücken. Der Vortrag stellt ein Vorgehen vor, mit dem sich diese Gaps effizient identifizieren und daraus priorisierte Maßnahmen ableiten lassen. Die Basis stellt das OWASP SAMM Framework dar, das als Best-Practice für Secure Software Development Lifecycle (SSDLC) auch eine Standortbestimmung und kontinuierliche Weiterentwicklung mit individuellen Schwerpunkten ermöglicht. Ein hierfür entwickeltes Mapping von CRA auf den OWASP SAMM ermöglicht ein strukturiertes CRA-Assessment und kurzfristig eine zielgerichtete Umsetzung der regulatorischen Anforderungen. Gleichzeitig wird ein erweitertes Rahmenwerk geschaffen, das hilft, den sicheren Entwicklungsprozess langfristig zu verbessern. Das Vorgehen erlaubt die Automatisierung einzelner Aufgaben wie dem Compliance-Check, reduziert somit den manuellen Aufwand und beschleunigt die Umsetzung. Praxisbeispiele verdeutlichen, wie Unternehmen so nicht nur effizient und ggf. KI-unterstützt CRA-Compliance erreichen, sondern einen nachhaltigen und resilienten SSDLC etablieren. Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110765-deu-CRA_effizient_und_nachhaltig_umsetzen_sd.mp4

Eine E-Mail liegt im Posteingang. Niemand öffnet sie, niemand klickt. Tage später fragt jemand seinen KI-Assistenten nach den letzten Mails — und der Agent schickt still interne Daten an einen fremden Server. So lief EchoLeak gegen Microsoft Copilot (CVE-2025-32711, CVSS 9.3): kein Exploit-Code, keine kaputte Authentifizierung. Jede Komponente hatte ihr Security-Review bestanden. Der Angriff lebte im Pfad dazwischen. Wer agentenbasierte Systeme baut, kennt das Muster: Wir prüfen Komponenten einzeln, Angreifer denken in Ketten. Sobald ein Agent Daten abruft, Aufgaben plant, Tools aufruft, sich Dinge merkt und mit anderen Agenten redet, entstehen Angriffspfade quer über Vertrauensgrenzen, die kein Per-Komponenten-Review sichtbar macht. Gerade im Kontext von Agentic AI werden dabei die Grenzen klassischer STRIDE-Analysen sichtbar, weil sich Risiken oft erst entlang von Daten-, Entscheidungs- und Tool-Ketten über mehrere Komponenten hinweg entfalten. Ich zeige eine Methode, kein weiteres Framework zum Auswendiglernen. Die Fünf-Zonen-Brille — Eingabe, Planung, Tool-Ausführung, Speicher, Agent-zu-Agent-Kommunikation — sagt, wo man hinschauen muss; die OWASP Top 10 for Agentic AI Applications sagen, was man dort findet. Wir gehen drei reale Architekturen durch: RAG-Pipeline-Poisoning, Missbrauch einer MCP-Tool-Chain und eine Multi-Agent-Kaskade. Für jede bauen wir einen Attack Tree und trennen die Kontrollen, die strukturell halten (Tool-Scoping pro Aufgabe, Egress-Inspektion, Credential-Trennung), von den prompt-basierten, die nur beruhigend klingen. Am Ende habt ihr eine wiederholbare Routine für euer eigenes Agentic AI System: Zonen kartieren, Pfade ablaufen, einen Baum bauen, Single Points of Failure finden, Kontrollen anhängen und validieren. Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110764-deu-Vier_gruene_Haekchen_trotzdem_gehackt_Threat_Modeling_fuer_KI-Agenten_sd.mp4

Shift-left doesn't start with scanning the code for security vulnerabilities; it begins with designing for security. Too often, the shift-left mantra consists of implementing (AI-powered) code scanning and applying AI-powered security fixes for remediation. Also, don't forget to implement the AI-powered benchmark for AI-powered Security Fixes. Now, to be clear, I am not actually telling you to stop using these tools — if they work for you — instead, we should ask ourselves: What are we working on? What can go wrong? What are we going to do about it? Did we do a good job? In order to support that second question in particular, we have created the next version of OWASP Cornucopia (see: https://cybersecgames.com/pages/owasp-cornucopia-threat-modeling-collection). OWASP Cornucopia is a mechanism in the form of a card game to assist software development teams in identifying security requirements in Agile, conventional, and formal development processes. It is language, platform, and technology-agnostic. The formerly titled "Cornucopia — Ecommerce Website Edition" is now "Cornucopia — Website App Edition". This edition was originally created in August 2012, released as v1.0 in February 2013, and has undergone several minor updates/releases over the following ten to fifteen years. This has been substantially updated in v2.0, in which the most noticeable change was an update of the OWASP ASVS mapping from ASVS v3.0 to v4.0, together with the creation of translations into six languages (EN, ES, FR, NL, NO-NB, and PT-BR) due to the efforts of past and current volunteers. The new version, available in 11 languages (EN, ES, FR, HI, NL, NO-NB, PT-PT, PT-BR, RU, UK), will include all new cards and text that covers all OWASP ASVS 5.0 requirements and links them to more than 200 unique common attack patterns (CAPEC). Each of the common attack patterns will have a unique set of ASVS requirements, which means that you never need to stop playing the game! You will always be able to return to the same card to discover new threats and security requirements to consider when building your software. Additionally, we are publishing the OWASP Cornucopia Companion Edition that comes with 6 companion suits (see: https://cornucopia.owasp.org/edition/companion) covering new topics: Agentic AI (AAI), Automated Threats (BOT), Cloud (CLD), Frontend (FRE), Large Language Models (LLM), and DevOps (DVO). A suit in the companion deck may replace (or be used in addition to) suites in the existing Website Edition so that the players can add a specific focus to their threat modeling: For example, say you are building an LLM application and want to perform threat modeling specifically for LLM. You would then use the OWASP Cornucopia Website Edition and the LLM companion suite as your elected OWASP Cornucopia focus area. What's more, it is now possible to create your OWASP Cornucopia Threat Model in OWASP Threat Dragon using their brand new EoP Games diagram. The diagram allows you to easily select the right card from the OWASP Cornucopia suite and connect it directly to your threat model in OWASP Threat Dragon, thanks to the combined efforts of volunteers at Universidad Católica del Uruguay and the OWASP Threat Dragon project. All project leaders and contributors to the OWASP projects that have provided valuable input and guidance to OWASP Top 10, OWASP AISVS and the OWASP GenAI Security project. We also want to thank the people and contributors to Mitre's Common Attack Pattern Enumeration and Classification (CAPEC™) and Atlas, together with CSA Cloud Controls Matrix, which are all used in the cross-references provided. Failing to regularly assess your security isn't only costly; it can leave you vulnerable to threats. Several companies have implemented OWASP Cornucopia as part of their SDLC and use it for security requirements analysis, threat modeling, and secure design for every sprint and every user story. You should do the same! Don't let your business spiral out of control; consciously assess how you are doing by continuously threat-modeling your applications and infrastructure. To get started scaling your threat modeling efforts, OWASP Cornucopia v3.0 is the perfect tool. Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110763-eng-OWASP_Cornucopia_-_Gamifying_AI_Threat_Modeling_and_Security_Requirement_Analysis_sd.mp4

Threat models usually go out of date as soon as they are created. They reside on the tool used to create the threat model. So a developer without access to the threat modeling tool does not even open the threat model. On the other hand, threat models that are interoperable come with several advantages. It's easier to share them with team members. Vendors can be asked to provide their threat models in a ready-to-consume format by purchasers in sensitive industries like healthcare. With the advent of agentic systems, LLMs can even consume raw threat models in JSON format and generate threat models that can be viewed and deliberated upon by human reviewers. The CycloneDX project is pushing to release the TM-BOM (Threat Modeling Bill of Materials) and is targeting general availability later this year. This session discusses the nuts and bolts of the TM-BOM format. Participants will understand how various pieces like blueprints, business objectives, behaviors, threats, risks, use cases, and controls interact with each other. To ground this standard in reality, I will share insights from integrating this pre-release schema into an open-source threat modeling platform, exploring the friction points of translating complex data structures into human-centric visualizations. Outline (20 Minutes) The Interoperability Problem (3 mins): Why siloed threat models fail developers and compliance teams. Deconstructing the TM-BOM (7 mins): A focused look at the CycloneDX 2.0 schema and how its core components (Blueprints, Behaviors, Threats, Risks, Controls) interlock. Agents and the TM-BOM (5 mins): How standardizing into JSON unlocks the ability for agentic systems to reliably consume and generate models for human review. Implementation Realities (3 mins): Engineering lessons learned mapping a complex JSON standard to visual diagrams. Q&A (2 mins) Attendees will leave with a functional understanding of the upcoming CycloneDX 2.0 standard, the operational benefits of interoperable threat models, and how to prepare their security pipelines to generate and consume TM-BOMs. Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110762-eng-Understanding_the_Map_of_Threat_Modeling_Through_the_Lens_of_the_TM-BOM_sd.mp4

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110761-eng-Chapter_Lead_Thanks_meet_you_next_year_sd.mp4

Celebrating the 25th Anniversary of OWASP and the 22nd of the German Chapter Founded in 2001, OWASP began as a grassroots initiative and the debut of the OWASP Top Ten followed soon after. Established soon after in 2004, the German Chapter has grown to become one of the longest-running chapters in the global community. Join us as we celebrate these milestones with a quick look back at the history and achievements of the German Chapter. Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110760-eng-Celebrating_the_25th_Anniversary_of_OWASP_and_the_22nd_of_German_Chapter_sd.mp4

Amerikanische Cloud-Anbieter durch europäische zu ersetzen ist im aktuellen politischen Umfeld gewollt — technisch aber ein Kompromiss, denn europäische Anbieter sind kleiner und bieten entsprechend weniger Komfort- und Sicherheits-Features. Auch unser Projekt musste in eine europäische Cloud migrieren. Ähnliche Anforderungen wurden auch an andere unserer Projekte gestellt, wodurch ein projektübergreifender Betrieb entstand. Dieser Vortrag zeigt wie wir unseren Betrieb von AWS in einen europäischen Cloud-Dienst überführt haben. Dabei mussten wir inkompatible Sicherheitsanforderungen verschiedener Projekte managen und undokumentierte „Feature“ zähmen, um am Ende einen sicheren langlebigen europäischen Cloudbetrieb zu schaffen. Der Schwerpunkt liegt auf den sicherheitsrelevanten Entscheidungen — warum wir sie so getroffen haben, welche sich aus unserer Sicht bewährt haben und welche wir im Nachhinein anders treffen würden. Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110759-deu-Sicher_in_einen_neuen_Hafen_--_Die_Geschichte_einer_Migration_in_eine_europaeische_Cloud_sd.mp4

Moderne digitale Verwaltungsinfrastrukturen setzen auf eine containerbasierte Infrastruktur. Doch woher stammen die sicheren Container-Images? Derzeit stammen sie überwiegend von US-Anbietern, was mit all den bekannten Risiken hinsichtlich Anbieterabhängigkeit, Datenhoheit und Schwachstellen in der Lieferkette einhergeht. In einer Zeit, in der sich geopolitische Rahmenbedingungen innerhalb weniger Wochen ändern können und Angriffe auf die Software-Lieferkette (Shai-Hulud, npm-Würmer, kompromittierte Basis-Images) zur Norm geworden sind, stellt dies ein strategisches Problem dar. Im Rahmen der Secure Government Container Initiative (SGCI, ebenfalls Teil der sSDLC-Strategie) und der Plattform container.gov.de stellt ZenDiS für den Bund, die Länder und die öffentliche IT von openCode verifizierte, gehärtete Container-Images bereit, als offene Bausteine, die in Zusammenarbeit mit der Community entwickelt wurden. Wir berichten aus erster Hand: Wie härten wir Container gemäß den BSI-Standards und NIST SP 800-190 ab? Welche Toolchain entsteht dabei? Wo stehen wir nach der ersten Einrichtungsphase und was kann noch getan werden, um den Erfolg dieses Projekts letztendlich sicherzustellen? Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110758-deu-Public_Money_Public_Containers_sd.mp4

Chat Bots und AI Agents werden immer mehr produktiv eingesetzt. Oft sollen diese mit einer SQL Datenbank interagieren können. Wenn lediglich Daten gelesen, aber nicht verändert werden sollen, scheint es sinnvoll einen "Read-Only" SQL MCP Server dafür zu verwenden. Doch was wenn dieser doch nicht so "Read-Only" wie versprochen ist und zum Beispiel der Chatbot zur Kundenberatung auf einmal dazu benutzt werden kann die Preise von Produkten oder Passwörter von Benutzern zu ändern? Ich habe 19 "Read-Only" SQL MCP Server untersucht und in 18 innerhalb von je 30 Minuten Schwachstellen gefunden; so "Read-Only" waren diese dann doch nicht... Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110757-deu-How_to_Hack_Read-Only_SQL_MCP_Servers_Online_Fast_sd.mp4

Artificial intelligence is becoming a core building block of modern applications, yet the way we secure software has not kept pace with the unique properties of AI systems. Traditional approaches often rely on static assumptions and deterministic behavior, while AI introduces probabilistic outputs, dynamic decision-making, and new forms of interaction that challenge established security practices. The OWASP AI Security Verification Standard (AISVS) is an effort to address this gap by providing a structured and testable framework for securing AI-enabled applications. It builds on the idea that security should be verifiable and measurable, and adapts this principle to systems that incorporate machine learning models, large language models, and autonomous components. This talk presents the motivation behind AISVS, its design principles, and how it defines security requirements that can be consistently evaluated. It explores how developers and security teams can use AISVS to move from informal or reactive approaches toward a more systematic way of validating the security of AI systems throughout their lifecycle. By focusing on clarity, practical applicability, and alignment with real-world development workflows, AISVS aims to become a foundation for building trust in AI-driven applications. Attendees will gain an understanding of how a verification standard can help bring structure and confidence to a rapidly evolving and often uncertain security landscape. Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110756-eng-OWASP_AISVS_Bringing_Order_to_AI_Security_Chaos_sd.mp4

Large language models are starting to change both sides of application security: offensive work such as black-box penetration testing, and defensive work such as code review and vulnerability detection in source code. In this talk, I present practical lessons from my academic and independent work in both areas: AutoPentest, my research on autonomous black-box pentesting with LLM agents; Vuldra, my work on LLM-assisted static code analysis; and my recent hands-on evaluation of OpenAI Codex Security on a real open-source project. On the offensive side, I show what happens when an LLM agent is asked to carry out a black-box penetration test with a high degree of autonomy. I explain the architecture behind AutoPentest, including specialized worker agents structured around OWASP Top 10-relevant web vulnerability areas, and show where the system still struggles in longer attack chains. In my evaluation on three Hack The Box machines, AutoPentest completed 15 to 26 percent of subtasks and slightly outperformed a manual ChatGPT-based baseline on one target. On the defensive side, I explored two ways of using LLMs for code security testing. First, I discuss Vuldra as an example of how LLMs can be used for static code analysis, integrating them with traditional SAST tools. Second, I present my evaluation of Codex Security on TorMap, where I looked at real findings, proposed fixes, and practical limits in a developer workflow. The main message of the talk is simple: LLMs can already help security teams on both the attacker and defender side, but their strengths and weaknesses are different. Attendees will leave with a realistic view of where LLMs are already useful, where they still fail, and how to evaluate such tools in their own environment without treating them as magic. Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110754-eng-What_LLMs_Can_Do_in_Pentesting_and_Code_Security_sd.mp4

As LLMs are increasingly integrated into systems that browse, retrieve, summarize, and act on web content, webpages have become an untrusted input vector for downstream model behavior. This enables site owners, contributors, and adversaries to embed instructions directly in web resources, i.e., indirect prompt injections. While prior work demonstrates such attacks in controlled settings, their prevalence, deployment, and real-world impact remain unclear. We present one of the first large-scale empirical analyses of indirect prompt injections in webpages and HTTP responses. Analyzing 1.2B URLs from 24.8M hosts, we identify 15.3K validated instances across 11.7K pages. These are not isolated cases: a small number of recurring templates account for most cases. We characterize their objectives, delivery mechanisms, visibility, persistence, and impact, revealing a heterogeneous ecosystem spanning disruptive prompts, reputation manipulation, content-protection directives, and AI-bot detection, targeting systems such as crawlers, search pipelines, customer-support agents, and hiring workflows. A key finding is that most instructions target machines rather than humans: about 70% appear in non-rendered HTML (e.g., headers, comments, metadata), and many visible cases are hidden via rendering techniques. To assess practical risk, we run 5,200 controlled experiments across 13 models and four webpage representations. Our results show compliance is limited but non-negligible, reaching up to 8% for smaller models on plain-text inputs, while structured representations reduce compliance by preserving structural cues. Overall, prompt-based interference is already present in the web ecosystem and represents a growing source of tension between LLM-driven automation and the sites it consumes. Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110753-eng-Indirect_Prompt_Injection_in_the_Wild_An_Empirical_Study_of_Prevalence_Techniques_and_Objectives_sd.mp4

Autonomous pentesting tools have matured to the point where they can reliably find vulnerabilities, but finding vulnerabilities is not the same as doing a professional pentest. Bug bounty hunting optimizes for high-severity impact while a client engagement requires systematic coverage against a framework, with every control checked. In this talk we will explore how we designed an internal solution that layers the OWASP ASVS framework on top of existing agentic testing products. We will cover what we put in place to get reliable results, the guardrails we designed to ensure safe behavior in client environments, and how our harness improves the coverage of agentic testing solutions. Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110752-eng-Hackbots_under_control_Methodology_for_Autonomous_Pentesters_sd.mp4

The OWASP Top 10 for Agentic Applications 2026 clearly outlines risks like prompt injection, tool misuse, excessive agency, rogue and compromised agents, and untraceable actions. This talk shows how an open source tool addresses the risks as a control platform, a switchboard between the model and its actions. The separation means any hostile or compromised model is bound and can't reach or bypass these controls. Tool misuse and excessive agency hit per-action permission tiers that auto-allow, require human approval, or block. Compromised and rogue agents hit a gate so an "evil model" can't elevate. Untraceable action hits an append-only, hash-chained, signed audit log. Skill supply chain hits a signature verification at load. A live agent demo shows the risks, controls, source code, and design architecture. The reference implementation maps to the sovereignty posture the EU formalized in its June 2026 tech package. Documentation and source: https://wirken.ai Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110751-eng-Agentic_AI_Gateway_Enforcement_of_the_OWASP_Top_10_sd.mp4

AI is creating real breakthroughs, but also an ocean of slop, hype, fear, and confusion. Engineers are declared obsolete. Agentic AI is treated as magic. Security teams are asked to protect systems that are changing faster than their risk models. No wonder many of us feel dazed. This keynote offers a free therapy session for the AI-overwhelmed, including a grounded path through the chaos from your therapist. What are the truths we can rely on? Which AI risks matter most? How do we scope security concerns without drowning in them? And what about our careers? Bring your questions. There will be tissues. Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110750-eng-Keynote_sd.mp4

Eine E-Mail liegt im Posteingang. Niemand öffnet sie, niemand klickt. Tage später fragt jemand seinen KI-Assistenten nach den letzten Mails — und der Agent schickt still interne Daten an einen fremden Server. So lief EchoLeak gegen Microsoft Copilot (CVE-2025-32711, CVSS 9.3): kein Exploit-Code, keine kaputte Authentifizierung. Jede Komponente hatte ihr Security-Review bestanden. Der Angriff lebte im Pfad dazwischen. Wer agentenbasierte Systeme baut, kennt das Muster: Wir prüfen Komponenten einzeln, Angreifer denken in Ketten. Sobald ein Agent Daten abruft, Aufgaben plant, Tools aufruft, sich Dinge merkt und mit anderen Agenten redet, entstehen Angriffspfade quer über Vertrauensgrenzen, die kein Per-Komponenten-Review sichtbar macht. Gerade im Kontext von Agentic AI werden dabei die Grenzen klassischer STRIDE-Analysen sichtbar, weil sich Risiken oft erst entlang von Daten-, Entscheidungs- und Tool-Ketten über mehrere Komponenten hinweg entfalten. Ich zeige eine Methode, kein weiteres Framework zum Auswendiglernen. Die Fünf-Zonen-Brille — Eingabe, Planung, Tool-Ausführung, Speicher, Agent-zu-Agent-Kommunikation — sagt, wo man hinschauen muss; die OWASP Top 10 for Agentic AI Applications sagen, was man dort findet. Wir gehen drei reale Architekturen durch: RAG-Pipeline-Poisoning, Missbrauch einer MCP-Tool-Chain und eine Multi-Agent-Kaskade. Für jede bauen wir einen Attack Tree und trennen die Kontrollen, die strukturell halten (Tool-Scoping pro Aufgabe, Egress-Inspektion, Credential-Trennung), von den prompt-basierten, die nur beruhigend klingen. Am Ende habt ihr eine wiederholbare Routine für euer eigenes Agentic AI System: Zonen kartieren, Pfade ablaufen, einen Baum bauen, Single Points of Failure finden, Kontrollen anhängen und validieren. Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:god2026-110764-deu-Vier_gruene_Haekchen_trotzdem_gehackt_Threat_Modeling_fuer_KI-Agenten_hd.mp4

Building AI-Powered Databases to Overcome Outdated Practices and Advance Human-Based Research. Doctors Against Animal Experiments (DAAE), an NGO based in Cologne, advocates for a phase-out of animal experiments and a shift towards ethical, human-based research. Alongside public outreach, campaigns, and political advocacy, DAAE develops and maintains four databases designed to accelerate this transition and make Non-Animal Technologies (NATs) more accessible, transparent, and usable. Two of these projects — the NATworks Database and the TTV Database (Transparente Tierversuche) — integrate AI-based approaches to process, structure, and provide access to scientific and political information as well as court rulings. In this talk, Julia Radzwill, biologist and Scientific Officer at DAAE, will introduce the databases, the problems they were built to address, and how they can be used to challenge the status quo in animal-based research. Robert Wulff, IT Administrator and developer of the databases, will then take a look under the hood, providing technical insights into their architecture, implementation, and the role AI plays in turning complex domain specific data into accessible information. Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:openchaos-2609-eng-Data_Against_Animal_Experiments_sd.mp4

Akademy Awards (10-20 mins) Closing Announcements - GET TO THE PARTY (5-10 mins) https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:kde2026-60-eng-Akademy_Awards_Closing_Announcements_sd.mp4

https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:kde2026-59-eng-Sponsors_talks_sd.mp4

Eike's adventure using KDE/Qt/HMI software in the field on an archeological mission for a robotic system! https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:kde2026-58-eng-KDE_goes_to_the_Pyramids_sd.mp4

KDE Linux is two years old. Building an operating system turns out to be hard! Along the way, we've learned a lot about what users love. We'd like to share it with other OS builders as we've learned from them, and lay out what's next. https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:kde2026-50-eng-KDE_Linux_at_2_what_weve_learned_and_how_it_can_help_you_sd.mp4

What is Debian? What Debian gives the whole open source community, what is special about Debian? (Cross-compiling, Mulit-Arch, reproducible builds,..) You uses Debian? - Cern - Debian in outerspace Why are a distribution like Debian with "a normal release cycle" is still relevant for KDE? Can KDE Linux replace Debian? What it is about to package KDE software on Debian? Who is the current Qt/KDE Maintainer team. Why does Debian ship that old versions? Why can't we just ship master branch? Speak about what were/are the current challenges regarding packaging KDE software on Debian: - loosely coupled Palsma - kde pim (ABI) - transitions from 4->5, 5->6 - lts support - QML dependecy tracking - bring patches to Debian stable - bring current version to Debian stable https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:kde2026-5-eng-Packaging_KDE_on_Debian_sd.mp4

The Linux printing ecosystem is currently undergoing one of its biggest architectural transitions in decades. Since the [CUPS 2.2.x][1] series, printing has increasingly moved toward [IPP-native and driverless][2] workflows, allowing applications to print directly to discovered IPP print destinations without requiring manually created print queues, PPD files, or vendor-specific driver filters. With the upcoming transition to [CUPS 3.x][3], legacy printer drivers and classic PPD-based queue creation will be removed entirely from CUPS itself. Non-driverless printers will instead require Printer Applications that expose printers through modern IPP interfaces. These changes significantly affect desktop printing infrastructure and require desktop environments to adapt to more dynamic, asynchronous, and network-oriented workflows. This talk explores the ongoing modernization work in KDE Print Manager to prepare for these changes. It covers the migration away from older synchronous request handling, improvements to UI responsiveness and request lifecycle management, and the architectural challenges involved in modernizing mature desktop infrastructure software while maintaining compatibility with existing workflows. The session will also provide an overview of how KDE Print Manager interacts with CUPS and the broader Linux printing stack, discuss the implications of the CUPS 3.x transition for KDE and Linux desktops, and highlight future directions for modern desktop printing infrastructure. Whether you are interested in KDE internals, Linux desktop architecture, or the future of printing on Linux systems, this talk offers insight into the engineering challenges and design decisions involved in preparing KDE Print Manager for the next generation of Linux printing. Tarun Srivastava has started the work voluntarily in the end of 2024, continued it as [Google Summer of Code 2025 project for OpenPrinting][4] (his [final report][5]) and is currently working on its completion in the [Google Summer of Code 2026][6]. His main mentor is Mike Noe, responsible for the [printing support in KDE][7], and additional mentors are Till Kamppeter, co-founder and lead of [OpenPrinting][8], and Nico Fella. More about OpenPrinting: - [OpenPrinting News - 25 years of OpenPrinting][9] - [OpenPrinting in Google Summer of Code 2026][10] - [Destination Linux #351 - Till Kamppeter and Michael Sweet][11] - [Tech over Tea #299 - Till Kamppeter][12] ([highlight clips][13]) - [FOSDEM 2024 - OpenPrinting - We make printing just work!][14] [1]: https://openprinting.github.io/cups/ [2]: https://openprinting.github.io/cups/drivers.html [3]: https://openprinting.github.io/cups/cups3.html [4]: https://openprinting.github.io/OpenPrinting-News-Google-Summer-of-Code-2025-Our-most-successful-one/#kde-print-manager-vs-cups-3x-by-tarun-srivastava [5]: https://github.com/Lord-Morpheus/GSOC-2025?tab=readme-ov-file#google-summer-of-code-2025---project-summary [6]: https://summerofcode.withgoogle.com/programs/2026/projects/tmG5Q3X8 [7]: https://invent.kde.org/plasma/print-manager [8]: https://www.openprinting.org/ [9]: https://openprinting.github.io/OpenPrinting-News-25-years-of-working-full-time-for-printing-with-free-open-source-software/ [10]: https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-OpenPrinting [11]: https://youtu.be/CLEMiM0L2Jk [12]: https://www.youtube.com/watch?v=X8NoAXgGIP8 [13]: https://openprinting.github.io/OpenPrinting-News-Tech-over-Tea-300-Brodie-interviews-Till-Kamppeter/ [14]: https://fosdem.org/2024/schedule/event/fosdem-2024-1930-openprinting-we-make-printing-just-work-/ https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:kde2026-47-eng-Modernizing_KDE_Print_Manager_for_the_Future_of_Linux_Printing_sd.mp4

Activities are a very powerful, yet heavily under-appreciated (and under-explained) feature of Plasma. In this lightning talk I would like to convince you why they are cool and to join us in the Activities BoF to discuss how both Activities themselves and KDE’s messaging/documentation/onboarding about them could be improved. https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:kde2026-46-eng-Activities_BoF_sd.mp4

In this session the working groups of KDE e.V. will present their work of the past year. https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:kde2026-42-eng-Report_of_the_Working_Groups_sd.mp4

In this session the board will report on the activities of KDE e.V. over the past year. https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:kde2026-41-eng-Report_of_the_board_sd.mp4

Find out why it's important to license all your files from the get-go. https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:kde2026-36-eng-License_all_the_files_o_sd.mp4

A talk in three parts, building towards a vision for a sovereign desktop in 2026 (and a look back). 1. **Loved**. In 2003, together with Eva Brucherseifer, Jan's company relevantive ran the first large-scale usability study of the Linux desktop on behalf of decision-makers considering migration. KDE 3.1 on SuSE was tested by 60 office workers with no prior Linux experience; 87% enjoyed working with it, 80% estimated they could reach professional competence within a week. The Linux desktop wasn't a usability disaster — but realising its potential required deliberate configuration, honest naming, and treating migration as a human-resources problem, not a technical one. The findings shaped a decade of OpenUsability work inside KDE. They are, awkwardly, almost entirely still applicable. We'll look at what stuck, what didn't, and why "lovable" — not merely "usable" — is the bar today, and why getting it right cuts the cost and risk of every migration discussion that follows. 2. **AI-native**. A desktop that loves you back has to know you. Personal AI has crossed the threshold where the desktop itself can be compiled per user, per device, per moment, from a small portable model of the user — what we are sketching as Kadai: an encrypted, vendor-agnostic personal kernel from which Plasma assembles each Activity. Plasma is uniquely well-fit for this — Activities, Plasmoids, the existing scripting surface — but a handful of upstream changes (declarative reconciliation, per-widget capabilities, richer Activity metadata) would turn KDE into the first shell that treats AI as infrastructure rather than as a chat box bolted to the side. 3. **Sovereign**. Once a user owns their model and their tools, the same question returns at institutional scale. EU institutions, member countries, and a long tail of organisations are openly asking what a credible, non-colonialising desktop stack looks like. No project carries this alone — a sovereign desktop is an ecosystem question. KDE is uniquely positioned as the shell, the integration layer, the experience; but filesharing belongs with Nextcloud, the browser with Firefox, the office suite with .... The last third of the talk is about what KDE's partnership surface could look like — outward, to industry and public administration, and sideways, to the allied open-source projects that already do the rest of the work better than anyone could redo it. Who owns that surface, where it lives, what KDE e.V. would need, what not to build. Sovereignty, from this angle, is just lovability and AI-ownership scaled up to the organisation: the user not owned by a vendor, the institution not owned by a foreign supplier — and the stack not owned by anyone, because the right partners hold the right pieces. This talk is an invitation — from peple with a long arc inside this community — to take a serious swing at the question the 2003 study posed and never quite resolved: what would it take for KDE to be the desktop people actively choose, not just the one some of us settle for? Attendees will leave with: a concrete proposal (KaDAi) to react to or tear apart, a clear set of asks the project could direct at Plasma maintainers, and the framing for a sovereignty conversation that KDE is uniquely positioned to lead. Format: 30 minutes of content with an open structure that invites interruption; 10 minutes of Q&A. https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:kde2026-32-eng-What_would_it_take_A_lovable_sovereign_AI-native_KDE_sd.mp4

In September 2025, a few of us Open Source nerds heard that the Bavarian government wanted to "sneakily" "invest" another billion Euro in Microsoft Cloud, Teams and 365 – without a tender, and before the year ends (Base contract) I talked to friends, and we created an open letter. Soon we were like ten initiators. We found support among many Bavarian Open Source companies and NGOs, only weeks later > 160 companies and institutions had been signing the letter. When larger German NGOs like the Gesellschaft für Informatik (Society for Informatics) and the Bund der Steuerzahler (Tax Payers' Association joined, the Bavarian Government could not stay silent any more. Leading up of today, two secretaries and the minister president have engaged in a public blame game. At first they were angry about the unwanted, additional publicity - and publicly said so. The goal of sneakily accomplishing the deal until end of 2025 failed and it is still not finalized. But now - four weeks before an election, secretaries of state for digital and finance are fighting publicly, accusing each other of "fake news" and are saying silly things. On camera - and in parliament. "OSS is too expensive" or "We needed something federated, decentralized and secure, thus we had to go for MS 365" and similar. It's fun. What we can learn from this? PR for OSS works, timing is helpful, topics are important and claims like "ONE BILLION!!" are valuable. No one knew Trump, Greenland and Davos would come to help us, but they did and made it hard for the conservative Bavarian government to keep doing what they had always been. And we were a bunch of people that stuck it out. And it's so important that we the OSS community learn how to play against the lobbys. We need to apply the "divide and conquer" strategy against the real enemies, not internally. https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:kde2026-29-eng-How_we_hacked_the_Bavarian_State_with_an_Open_Source_Open_Letter_sd.mp4

Whenever a KDE Goals cycle comes to an end, it launches us into an upward spiral toward the next. In this panel, we’ll look back at the achievements of the 2024–2026 Goals cycle: - KDE Needs You - We Care About Your Input - Streamlined Application Development Experience And finally, announcing new goals & champions https://creativecommons.org/licenses/by-sa/4.0/ about this event: https://c3voc.de

Video:kde2026-25-eng-KDE_Goals_-_An_Upward_Spiral_sd.mp4