CVE-2026-58192: Appium Path Traversal Vulnerability

CVE-2026-58192 Overview

CVE-2026-58192 is a path traversal vulnerability [CWE-22] in the Appium storage plugin affecting all versions prior to 1.1.6. Appium is a cross-platform automation framework for mobile, web, and desktop applications built on top of the W3C WebDriver protocol. The storage plugin exposes a POST /storage/delete endpoint whose handler passes user-supplied name values directly into path.join(storageRoot, name) and fs.rimraf() without sanitization. An unauthenticated remote attacker can supply ../ sequences to escape the storage root and recursively delete arbitrary writable files or directories on the host.

Critical Impact
Unauthenticated remote attackers can recursively delete arbitrary writable files or directories accessible to the Appium server process, resulting in data loss and service disruption.

Affected Products

Appium storage plugin (@appium/storage-plugin) versions prior to 1.1.6
Appium automation framework deployments exposing the storage plugin
Any host running an Appium server with the storage plugin enabled on a network-reachable interface

Discovery Timeline

2026-07-08 - CVE-2026-58192 published to NVD
2026-07-08 - Last updated in NVD database

Technical Details for CVE-2026-58192

Vulnerability Analysis

The flaw resides in the Appium storage plugin's delete handler. When a client submits a request to POST /storage/delete, the handler concatenates the client-supplied name field with the configured storageRoot using path.join(storageRoot, name). Because path.join normalizes ../ sequences without enforcing a containment boundary, the resulting absolute path can point anywhere on the file system. The path is then passed to fs.rimraf(), which recursively removes the target. The endpoint requires no authentication, so any network-reachable client can invoke it.

The issue is classified under [CWE-22] Improper Limitation of a Pathname to a Restricted Directory. Impact is limited to integrity and availability — the primitive is file deletion rather than read or write — but scope is changed because the affected files may belong to other components running under the same account.

Root Cause

The requireValidItemOptions function validated names supplied through the add/upload path using fs.sanitizeName, but the delete handler bypassed that validation entirely. The delete code path accepted arbitrary name values, allowing traversal sequences to reach fs.rimraf().

Attack Vector

Exploitation requires network access to the Appium server and a single crafted HTTP POST request. No credentials, user interaction, or prior compromise are required.

typescript

// Security patch in packages/storage-plugin/lib/plugin.ts
 import {BasePlugin} from 'appium/plugin';
-import {requireValidItemOptions, Storage, StorageArgumentError} from './storage';
+import {
+  requireValidItemOptions,
+  Storage,
+  StorageArgumentError,
+  validateStorageItemName,
+} from './storage';
 import {tempDir, fs, logger, util} from '@appium/support';
 import type {AddRequestResult, ItemOptions, StorageItem} from './types';
 import type {Express, Request, Response} from 'express';

Source: GitHub Commit 5fee0175

The patch refactors name validation into a shared validateStorageItemName helper and applies it to the delete request handler as well:

typescript

// Security patch in packages/storage-plugin/lib/storage.ts
 export function requireValidItemOptions(opts: ItemOptions): ItemOptions {
-  if (util.isEmpty(opts.name)) {
-    throw new StorageArgumentError(`The provided file name '${opts.name}' must not be empty`);
-  }
-  const sanitizedName = fs.sanitizeName(opts.name, {
-    replacement: '_',
-  });
-  if (opts.name !== sanitizedName) {
-    throw new StorageArgumentError(
-      `The provided name value '${opts.name}' must be a valid file name. ` +
-        `Did you mean '${sanitizedName}'?`,
-    );
-  }
+  validateStorageItemName(opts.name);
   if (opts.sha1?.length !== SHA1_HASH_LEN) {
     throw new StorageArgumentError(
       `The provided hash value '${opts.sha1}' must be a valid SHA1 string, for ` +

Source: GitHub Commit 5fee0175

Detection Methods for CVE-2026-58192

Indicators of Compromise

HTTP POST requests to /storage/delete containing .. or URL-encoded %2e%2e sequences in the JSON name field.
Unexpected deletion of files or directories owned by the account running the Appium server process.
Appium server logs recording delete operations whose resolved absolute path lies outside the configured storage root.

Detection Strategies

Deploy a reverse proxy or Web Application Firewall rule that inspects request bodies to /storage/delete and blocks payloads containing traversal sequences.
Enable file integrity monitoring on directories adjacent to and above the Appium storage root to identify unauthorized deletions.
Correlate Appium HTTP access logs with file-system audit events (Linux auditdunlink/unlinkat syscalls, Windows Object Access events) targeting the server user.

Monitoring Recommendations

Alert on any external network access to the Appium REST interface — Appium is normally bound to loopback in test environments.
Track the @appium/storage-plugin version in software inventory and flag hosts running versions below 1.1.6.
Baseline expected file paths under the storage root and alert on rimraf or equivalent recursive delete activity outside that baseline.

How to Mitigate CVE-2026-58192

Immediate Actions Required

Upgrade @appium/storage-plugin to version 1.1.6 or later on all Appium hosts.
Restrict network exposure of the Appium server to trusted management interfaces or loopback only.
Audit the file system for unexpected deletions since the storage plugin was first exposed on a reachable interface.

Patch Information

The issue is fixed in @appium/storage-plugin version 1.1.6. The fix introduces a shared validateStorageItemName helper and applies it to the delete handler so that names containing traversal sequences are rejected before reaching fs.rimraf(). See the Appium Release 1.1.6, the GitHub Pull Request #22362, and the GitHub Security Advisory GHSA-jwgx-mp9m-jwcr.

Workarounds

Disable the storage plugin until the upgrade to 1.1.6 can be applied.
Place the Appium endpoint behind an authenticating reverse proxy that rejects requests to /storage/delete containing .., %2e%2e, or absolute path characters.
Run the Appium process under a dedicated low-privilege account with write access limited to the storage root to reduce blast radius.

bash

# Configuration example: upgrade the vulnerable package
npm install @appium/storage-plugin@1.1.6

# Verify installed version
npm ls @appium/storage-plugin

# Optional: block traversal payloads at an nginx reverse proxy
# location /storage/delete {
#     if ($request_body ~* "\.\.") { return 403; }
#     proxy_pass http://appium_backend;
# }