EUVD-2026-42424Severity by source
AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H
Unauthenticated network request with trivial complexity deletes files outside the plugin's storage root (scope change), destroying data and availability with no confidentiality impact.
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
7DescriptionNVD
Appium is a cross-platform automation framework for all kinds of apps, built on top of the W3C WebDriver protocol. Prior to 1.1.6, the Appium storage plugin exposes POST /storage/delete, whose handler passes the user-supplied name value directly into path.join(storageRoot, name) and fs.rimraf() without path sanitization, allowing an unauthenticated remote client to escape the storage root with ../ sequences and recursively delete arbitrary writable files or directories. This issue is fixed in version 1.1.6.
AnalysisAI
Unauthenticated arbitrary file/directory deletion in the Appium storage plugin (versions prior to 1.1.6) lets a remote client abuse the POST /storage/delete endpoint to recursively remove any file or directory the Appium process can write to. The handler feeds the user-supplied name straight into path.join(storageRoot, name) and fs.rimraf() with no sanitization, so ../ sequences escape the intended storage root. SSVC marks a proof-of-concept as available and the flaw as automatable; publicly available exploit code exists, though it is not listed in CISA KEV and EPSS is low (0.34%).
Technical ContextAI
Appium is a W3C WebDriver-based cross-platform test-automation server; the affected component is its optional @appium/storage-plugin (Node.js), which provides file storage management endpoints. The root cause is CWE-22 (Improper Limitation of a Pathname to a Restricted Directory / path traversal): the delete handler in packages/storage-plugin/lib/plugin.ts passed the request's name field to storage.delete() with no validation, and lib/storage.ts joined it onto storageRoot before calling fs.rimraf(). Because path.join resolves ../ segments, a name like ../../../etc/something traverses outside storageRoot, and rimraf then recursively deletes it. The fix adds a validateStorageItemName() function that rejects empty names and any name that does not survive fs.sanitizeName() (e.g. names containing path separators), applied to both delete and item-creation paths.
RemediationAI
Vendor-released patch: upgrade @appium/storage-plugin to 1.1.6, which introduces validateStorageItemName() to reject empty names and any name containing path separators or other characters that fs.sanitizeName() would alter (release: https://github.com/appium/appium/releases/tag/%40appium/storage-plugin%401.1.6; fix commit 5fee01752f2782e96fbe64fd13520b433d4a7535; PR https://github.com/appium/appium/pull/22362). If you cannot upgrade immediately, disable the storage plugin (do not load it via --use-plugins) since it is optional - this removes the endpoint entirely at the cost of losing storage functionality; alternatively, block or firewall the /storage/* routes at a reverse proxy and restrict the Appium listener to trusted, authenticated networks/localhost so the unauthenticated endpoint is not reachable by untrusted clients. Running the Appium process under a low-privilege account that owns only its storage directory limits the blast radius of any successful traversal but does not close the vulnerability.
Same weakness CWE-22 – Path Traversal
View allSame technique Path Traversal
View allShare
External POC / Exploit Code
Leaving vuln.today