CVE-2026-58192

Executive Summary

CVE-2026-58192 is a critical path traversal vulnerability in the Appium storage plugin, affecting versions prior to 1.1.6. The vulnerability resides in the POST /storage/delete endpoint, where the user-supplied name parameter is passed directly into path.join(storageRoot, name) and fs.rimraf() without any sanitization. This allows an unauthenticated remote attacker to escape the intended storage root directory using ../ sequences and recursively delete arbitrary writable files or directories on the server. The CVSS score of 8.6 reflects the high impact on integrity and availability, with no confidentiality impact. No public proof-of-concept (PoC) or exploit code has been identified at this time, but the attack vector is straightforward and could be weaponized easily.

Supply Chain & Package Security

This vulnerability affects the Appium storage plugin, which is distributed as an npm package (appium-storage-plugin). Organizations using this plugin in their Appium infrastructure should immediately audit their dependency trees and update to version 1.1.6 or later. The npm ecosystem is particularly susceptible to supply chain attacks, and while this specific CVE does not involve malicious package injection, the lack of input validation in a widely used automation tool could lead to downstream compromise of CI/CD pipelines and test environments.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – The vulnerability is exploitable remotely over the network.
• Attack Complexity (AC): Low (L) – No special conditions or complex attack sequences are required.
• Privileges Required (PR): None (N) – No authentication is needed to trigger the vulnerable endpoint.
• User Interaction (UI): None (N) – The attacker does not need to trick a legitimate user.
• Scope (S): Unchanged (U) – The vulnerable component and the affected resource are the same.
• Confidentiality (C): None (N) – The vulnerability does not lead to data disclosure.
• Integrity (I): High (H) – Arbitrary file deletion can corrupt system files or application data.
• Availability (A): High (H) – Deleting critical files or directories can cause denial of service.

Threat Level: Critical. The combination of network exploitability, no authentication, and high impact on integrity and availability makes this a high-priority vulnerability for remediation.

Deep Dive & Mechanics

The vulnerability is a classic path traversal (directory traversal) flaw in the POST /storage/delete endpoint of the Appium storage plugin. The handler function receives a name parameter from the request body and constructs a file path using path.join(storageRoot, name). The storageRoot is a predefined directory intended to contain only storage-related files. However, because the name parameter is not sanitized, an attacker can include path traversal sequences such as ../ to navigate up the directory tree.

For example, if storageRoot is /var/appium/storage, a request with name: ../../etc/passwd would result in the path /var/appium/storage/../../etc/passwd, which resolves to /etc/passwd. The fs.rimraf() function (a recursive delete utility) then deletes the target file or directory. Since rimraf is recursive, even a directory with contents can be removed entirely.

The attack does not require authentication, making it trivially exploitable by any network-accessible client. The only limitation is that the attacker must be able to reach the Appium server's HTTP endpoint.

Vulnerable vs. Patched Code

Vulnerable Code (prior to 1.1.6):

app.post('/storage/delete', (req, res) => {
  const name = req.body.name;
  const targetPath = path.join(storageRoot, name);
  fs.rimraf(targetPath, (err) => {
    if (err) {
      res.status(500).send('Delete failed');
    } else {
      res.send('Deleted');
    }
  });
});

Patched Code (version 1.1.6):

const path = require('path');
const fs = require('fs-extra');

app.post('/storage/delete', (req, res) => {
  const name = req.body.name;
  // Sanitize: resolve the path and ensure it stays within storageRoot
  const resolvedPath = path.resolve(storageRoot, name);
  if (!resolvedPath.startsWith(path.resolve(storageRoot))) {
    return res.status(400).send('Invalid path');
  }
  fs.rimraf(resolvedPath, (err) => {
    if (err) {
      res.status(500).send('Delete failed');
    } else {
      res.send('Deleted');
    }
  });
});

The fix adds a path resolution check: after joining storageRoot and name, the code resolves the full path and verifies that it still starts with the resolved storageRoot. This prevents any traversal outside the intended directory.

Exploitation & Lab Setup

Red Team

Lab Setup:

1. Deploy a vulnerable Appium server with the storage plugin version < 1.1.6.
2. Ensure the server is accessible on a network (e.g., http://target:4723).
3. Create a test file outside the storage root, e.g., /tmp/testfile.txt.

Exploitation Steps:

1. Send a POST request to /storage/delete with a crafted name parameter:

   curl -X POST http://target:4723/storage/delete \
     -H "Content-Type: application/json" \
     -d '{"name": "../../tmp/testfile.txt"}'
   

2. Verify that /tmp/testfile.txt is deleted.
3. For recursive deletion of a directory, use:

   curl -X POST http://target:4723/storage/delete \
     -H "Content-Type: application/json" \
     -d '{"name": "../../var/log"}'
   

Expected Outcome: The attacker can delete arbitrary files or directories writable by the Appium process user.

Blue Team

Detection:

• Monitor HTTP POST requests to /storage/delete for suspicious name parameters containing ../ or absolute paths.
• Alert on any deletion of files outside the expected storage root directory.
• Use file integrity monitoring (FIM) to detect unexpected deletions of critical system files.

Hunting:

• Search web server logs for requests to /storage/delete with name values containing path traversal sequences.
• Correlate with file deletion events in system logs (e.g., auditd on Linux).

Prevention:

• Apply the patch immediately (upgrade to version 1.1.6).
• If patching is not possible, implement a reverse proxy (e.g., Nginx) to block requests containing ../ in the request body.
• Restrict network access to the Appium server to trusted IPs only.

Indicators of Compromise (IOCs)

• Network: HTTP POST requests to /storage/delete with name parameter containing ../ or absolute paths.
• File System: Unexpected deletion of files or directories outside the storage root (e.g., /etc/passwd, /var/log, /tmp).
• Logs: Web server logs showing 200 responses to /storage/delete with suspicious name values.
• Process: Appium process (node) performing fs.rimraf on paths outside the intended storage directory.

Detection Engineering

YARA Rule

rule CVE_2026_58192_Appium_Path_Traversal {
  meta:
    description = "Detects path traversal attempts in Appium storage plugin delete requests"
    author = "Valters IT"
    date = "2025-04-14"
    cve = "CVE-2026-58192"
  strings:
    $traversal = /\.\.\// nocase
    $endpoint = "/storage/delete"
  condition:
    $endpoint and $traversal
}

Sigma Rule

title: Appium Storage Plugin Path Traversal Attempt
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects HTTP POST requests to /storage/delete with path traversal sequences
author: Valters IT
date: 2025-04-14
logsource:
  category: webserver
  product: generic
detection:
  selection:
    cs-method: 'POST'
    cs-uri-stem: '/storage/delete'
    cs-uri-query|contains: 'name='
  keywords:
    - '..%2F'
    - '%2e%2e%2f'
    - '..\\'
  condition: selection and keywords
falsepositives:
  - Legitimate use of relative paths within storage root (unlikely)
level: high

Suricata Rule

alert http $EXTERNAL_NET any -> $HOME_NET any (
  msg:"CVE-2026-58192 Appium Storage Plugin Path Traversal Attempt";
  flow:to_server,established;
  content:"POST"; http_method;
  content:"/storage/delete"; http_uri;
  content:"name"; http_client_body;
  pcre:"/\.\.\//Pi";
  reference:cve,2026-58192;
  classtype:attempted-admin;
  sid:1000001;
  rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Patch: Upgrade the Appium storage plugin to version 1.1.6 or later.
2. Workaround: If patching is delayed, implement a reverse proxy (e.g., Nginx) to block requests containing ../ in the request body:

   location /storage/delete {
     if ($request_body ~* "\.\.") {
       return 403;
     }
     proxy_pass http://appium_backend;
   }
   

3. Network Segmentation: Restrict access to the Appium server to only trusted IP addresses or internal networks.

Long-Term Measures:

• Conduct a security audit of all Appium plugins for similar input validation flaws.
• Implement input validation and path sanitization in all file operation endpoints.
• Use a Web Application Firewall (WAF) to detect and block path traversal attempts.
• Enable file integrity monitoring (FIM) on critical system directories.

Valters IT – Securing your digital frontier.