EUVD-2026-58087
GHSA-95cv-r8x4-vh75
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L
PR:L because a normal authenticated account with rename permission suffices; I:H for cross-boundary file rename; C:L for file-existence side-channel via response.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L
Lifecycle Timeline
4DescriptionCVE.org
OpenList a file list program that supports multiple storage. Prior to 4.2.4, the authenticated /api/fs/batch_rename handler in server/handles/fsbatch.go authorizes only the source directory produced by user.JoinPath(req.SrcDir) and validates renameObject.NewName with checkRelativePath, but does not validate attacker-controlled renameObject.SrcName, supplied as src_name, before concatenating it with the authorized path and passing the result to fs.Rename. A user with rename permission can use traversal segments in src_name to make path normalization select a file outside the authorized directory and configured base path, resulting in cross-user file integrity loss, limited availability impact, and file-existence disclosure through success or error responses. This issue is fixed in version 4.2.4.
AnalysisAI
Authenticated path traversal in OpenList's batch rename API allows any user with rename permission to move files outside their authorized storage boundary. The /api/fs/batch_rename endpoint in server/handles/fsbatch.go validates src_dir and new_name against path traversal, but leaves src_name unchecked before concatenating it with the authorized path and passing the result to fs.Rename. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires a valid authenticated OpenList session where the account has been explicitly granted rename permission on at least one directory - a normal (non-admin) user role plus rename permission is sufficient, as confirmed by the GHSA advisory PoC. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The CVSS 3.1 score of 7.6 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L) aligns well with the described behavior. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An authenticated OpenList user with rename permission sends a POST to `/api/fs/batch_rename` with `src_dir` set to a directory they legitimately control and `src_name` set to `../../other_team/sensitive_report.pdf`. The server authorizes the request against the constrained `src_dir`, but `path.Clean` resolves the concatenated path to `/other_team/sensitive_report.pdf`, which lies outside the attacker's base. … |
| Remediation | Upgrade to OpenList v4.2.4, which adds `checkRelativePath(renameObject.SrcName)` before the path concatenation in `server/handles/fsbatch.go`, rejecting traversal sequences and returning HTTP 403 for invalid inputs. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, inventory all OpenList deployments and identify versions prior to 4.2.4. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
OpenList Frontend versions prior to 4.1.10 contain a path traversal vulnerability in file operation handlers that allows
OpenList versions prior to 4.1.10 disable TLS certificate verification by default in storage driver communications, enab
Same weakness CWE-22 – Path Traversal
View allSame technique Path Traversal
View allShare
External POC / Exploit Code
Leaving vuln.today