This session presents a structured, security-focused analysis of the React2Shell vulnerability as a real-world case study in insecure design and broken trust boundaries in modern frontend frameworks.
The talk begins by establishing a clear threat model for React and Next.js applications that use Server Components and Server Actions. We define the relevant trust zones, browser, framework runtime, and application server, and explicitly highlight where data crosses from untrusted client control into trusted server-side execution.
From there, we analyze the React2Shell CVE and its underlying root causes, including: - Implicit trust in framework-generated client invocations - Insufficient verification of serialized input crossing the client–server boundary - A blurred separation between data and executable intent
The session then examines the security fix, explaining how changes to validation and execution flow resolved the issue and which assumptions were corrected at the framework level.
Building on this analysis, the talk transitions into defensive standards and verification strategies that can help prevent similar classes of vulnerabilities. Using threat modeling and OWASP guidance, we map the issue to relevant OWASP ASVS controls, including: ASVS V1 – Architecture, Design, and Threat Modeling ASVS V4 – Access Control ASVS V5 – Input Validation and Processing ASVS V14 – Configuration
We conclude with practical defensive patterns applicable beyond React and Next.js, such as: - Treating framework-managed invocations as untrusted input - Applying defense-in-depth across client, framework, and server layers - Improving observability and logging for server-side execution paths - The role and limitations of WAFs in this class of vulnerability
Tools & Techniques Used - Conceptual architecture and trust-boundary diagrams - Framework execution-flow diagrams - Threat modeling techniques - OWASP ASVS and WSTG cross-referencing
Intended Audience This session is intended for: - Application Security engineers - Security architects - Developers involved in secure design reviews
We disclosed four vulnerabilities in the widely used SQL parsers SQLGlot and SQLFluff, as well as issues affecting downstream applications such as Apache Superset (70k GitHub stars), Pathway (60k GitHub stars), and other tools that rely on these parsers. Some of these downstream vulnerabilities have also been disclosed.
These flaws allow syntactically valid queries to trigger crashes or out-of-memory errors via recursion and AST object inflation. Our findings demonstrate that even well-formed queries can be weaponized to disrupt data workflows. We provide practical mitigations to help maintainers and platform builders strengthen parsers against this class of attacks.
Apache Airflow has evolved far beyond a cron replacement. It now powers core machine learning workflows, data engineering platforms, CI/CD pipelines, and enterprise automation systems.
With tens of millions of monthly downloads and global enterprise adoption, Airflow represents a high-value target. Its dynamic DAG execution model, Python-based operators, and extensive provider ecosystem create powerful capabilities and a significant attack surface.
This session presents research-backed insights and controlled demonstrations covering:
1. Exposure in the Wild
* Adoption scale and ecosystem growth * Patterns of publicly exposed Airflow instances * Observed vulnerable version distribution * Common deployment mistakes
2. Vulnerability Classes
* Authorization and RBAC weaknesses * Privilege escalation via unsafe DAG design * Code execution surfaces in templating and operators * Secret leakage through logs and variables * Example DAG abuse * Provider-level weaknesses * Supply-chain risks in DAG CI/CD pipelines * Misconfiguration patterns (root execution, open UI, permissive file systems)
3. Live Demonstrations (Isolated Lab Environment)
All demos are performed in a controlled Docker-based lab.
We will demonstrate:
* How low-privilege users can trigger unintended execution paths * How secrets leak through logging misconfiguration * How example DAGs expand the attack surface * How unsafe provider parameters introduce injection risk
No public systems are targeted.
4. Defensive Playbook
* Secure DAG development practices * Proper RBAC architecture * Secret management integrations * CI/CD enforcement for DAG review * Log hygiene and detection controls * Network isolation strategies * Practical upgrade and patching strategy
5. Real-World Upgrade Challenges
Upgrading Airflow is not always straightforward. I will share operational lessons from attempting to migrate to newer secure versions.
Attendees leave with a practical hardening blueprint that goes beyond "just upgrade."
Security Researcher | Reflectiz, Secure From Scratch
Or Sahar is a security researche, with two decades of experience in software development and security, she specialises in penetration testing, AI and Security research and application security.
This session presents how Intuit's Data Protection team built and operates an internal platform for identity-based access to encryption keys and secrets across AWS, GCP, and third-party providers. The platform serves services and handles cryptographic operations at scale while keeping the developer experience simple.
The talk covers four components:
1. An identity broker that validates cloud workload identities and issues short-lived credentials. This eliminates secret sprawl and removes the need to rotate long-lived credentials.
2. A key management service built on a split-key architecture where the service itself never sees plaintext keys. Keys are encrypted client-side before reaching this service, so even a full database compromise would not expose key material. The system supports full key lifecycle management: creation, rotation, versioning, deactivation, and destruction; with state machine enforcement that prevents unsafe transitions. This design gives teams strong data protection guarantees without requiring them to understand cryptography.
3. An automation layer that creates time-limited access policies for cloud workloads on demand. When a new AWS IAM role or GCP service account needs access to encryption keys, the service provisions the policy automatically with an x-day expiration.
4. A browser-based developer UI integrated with Intuit's DevPortal, making secret management accessible with role-based access controls. Developers can manage secrets without needing SDKs or CLI tools, with different permission levels for admins, DevOps, developers, and data stewards. SDKs and CLIs are also available.
Key advantages of this approach: 1. Zero-knowledge key storage: the key management service never sees plaintext keys. Even an insider with database access cannot extract key material. 2. Least privilege by default: Access is provisioned as read-only and time-bounded automatically. Developers don't need to think about it. 3. Multi-cloud consistency: The same policy and access model works across providers, avoiding provider-specific tooling silos. 4. Developer experience: Security is embedded into the platform, not bolted on. Developers interact with a simple API or browser UI, not raw cryptographic primitives.
We'll discuss how these design patterns map to OWASP Top 10 categories and share practical lessons from operating this system at enterprise scale.
The session is aimed at security engineers and architects interested in practical approaches to multi-cloud secret and key management.
