Autonomous Discovery of Critical Zero-Days

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.

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
Clone-Voice Command Injection: From Voice Processing to Shell Access
Fonoster Voice Server LFI: Breaking Audio File Boundaries
LibrePhotos Arbitrary File Upload: From Upload to RCE

Vulnerability Distribution

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 rely on pattern matching and predefined rules, and miss complex vulnerabilities that do not fit known patterns (i.e. business logic problems, broken authentication flaws, or non-traditional sinks such as from dependencies). They also generate a high rate of false positives.

The beauty of LLMs is that they can reduce ambiguity in most of the situations that caused scanners to be either unusable or produce few findings when mass-scanning open source repositories. 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, you need to 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 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:

Identify directory boundaries for each application
Generate application descriptions and metadata, noting details like the auth procedure and tech stack
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 that provides fundamental functionality for:

User management (creating and listing users)
Content management (creating and listing posts)
User authentication (login and logout capabilities)

Below is an example of the method to retrieve users from the application:

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.:

(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:

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.

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:

Technical 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).
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)
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. Technical 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) and an adaptation of the ReAct framework.

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 technical 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 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.