CVE-2025-34508

What it actually does

CVE-2025-34508 is an authenticated path traversal flaw in ZendTo file dropoff handling in versions 6.15-7 and earlier. Because user-supplied file or path input is not sufficiently constrained to the intended dropoff storage location, a remote authenticated user can reference paths outside the authorized dropoff context. Successful exploitation can expose other users’ uploaded files, disclose host-resident files readable by the web application account, modify or interfere with accessible files, and potentially trigger denial of service by requesting large or sensitive files or abusing file-handling logic.

Why it matters to the business

An attacker with any valid ZendTo account could access files they were not meant to see, including sensitive business documents exchanged through the platform and potentially local server files. This can lead to data leakage, privacy or contractual exposure, disruption of file-transfer operations, and incident response costs. Although it is not currently listed in CISA KEV and no ransomware association is reported, the EPSS score is high, so exposed ZendTo deployments should be treated as a priority for remediation.

How an attack unfolds

An attacker first obtains or uses a legitimate ZendTo account, then interacts with the file dropoff functionality over the network. Instead of requesting only files associated with their own dropoff, the attacker supplies crafted path traversal input that causes the application to resolve a file path outside the intended user-specific storage area. If the application process has read access, the attacker can retrieve other users’ dropoff files or host files; if write/delete paths are reachable, they may corrupt application data or cause operational disruption. Repeated or oversized retrieval attempts may also degrade service availability.

How to fix it

Upgrade ZendTo to a vendor-fixed release newer than the affected 6.15-7-and-earlier line as soon as a fixed package is available from the ZendTo project or distribution maintainer. If an immediate upgrade is not possible, restrict ZendTo access to trusted networks or VPN users, enforce strong authentication and MFA where supported, disable or limit file dropoff functionality if operationally acceptable, and ensure the web application account has the least filesystem permissions necessary. Review web server and application configuration so uploaded/dropoff files are stored outside sensitive system paths and cannot be accessed through arbitrary path input. Consider rotating credentials and expiring existing dropoffs if exploitation is suspected.

How to confirm the fix worked

Confirm the installed ZendTo version is newer than the affected versions and matches the vendor-fixed package or distribution advisory. Review package manager output, ZendTo application version pages, and deployed source/package metadata. Perform an authorized regression test using benign traversal input against file dropoff and pickup workflows and verify the application rejects traversal attempts, normalizes paths safely, and never returns files outside the requester’s authorized dropoff. Validate filesystem permissions by confirming the ZendTo web process cannot read sensitive host files or other users’ storage outside intended access paths. Re-check externally exposed ZendTo instances after patching to ensure only patched versions are reachable.

Typical attack path

1. Acquire valid ZendTo credentials through legitimate access, phishing, password reuse, or another compromise.
2. Authenticate to the ZendTo web interface.
3. Identify file dropoff or pickup request parameters that reference stored files or dropoff identifiers.
4. Submit crafted traversal sequences to escape the intended dropoff directory.
5. Retrieve files belonging to other ZendTo users or files readable by the ZendTo web server process.
6. Repeat enumeration across dropoffs or target known host file paths.
7. Optionally abuse file-handling behavior to disrupt service or exhaust resources.

How to detect it

Look for evidence of authenticated users sending traversal payloads to ZendTo file dropoff, pickup, or download endpoints. Useful sources include reverse proxy logs, web server access/error logs, ZendTo application logs, authentication logs, WAF events, EDR file access telemetry, and file integrity monitoring. Search for encoded and unencoded parent-directory sequences in request paths, query strings, POST bodies, and referrers, especially following successful login events. Investigate HTTP 200 responses, large response sizes, repeated 4xx/5xx errors, or downloads of files inconsistent with the authenticated user’s normal activity. On the host, review access by the web server process to files outside ZendTo’s expected dropoff/upload directories. If suspicious access is found, correlate the source IP, username, session identifier, requested path, response size, and subsequent file downloads or service instability.

• ../
• ..\\
• %2e%2e%2f
• %2e%2e%5c
• ..%2f
• ..%5c
• %252e%252e%252f
• %252e%252e%255c
• /etc/passwd
• /etc/shadow
• /proc/self/environ
• /proc/self/cmdline
• /var/zendto
• /opt/zendto
• /usr/local/zendto
• dropoff
• pickup
• download

What your security team should do

• Prioritize patching or upgrading ZendTo because the EPSS score indicates elevated likelihood of exploitation despite no current KEV listing.
• Inventory all externally reachable and internal ZendTo deployments, including appliances, packaged installs, and distribution-managed instances.
• Restrict access to ZendTo to trusted users and networks until patched, especially internet-facing deployments.
• Review authentication logs for unusual successful logins, new accounts, password-spray activity, or logins from unfamiliar geographies before suspicious file access.
• Hunt web and application logs for traversal patterns targeting dropoff, pickup, download, or file retrieval endpoints.
• Review recent file access patterns for users downloading files they do not own or unusually large numbers of files.
• Confirm the ZendTo service account has least-privilege filesystem access and cannot read sensitive operating system files unnecessarily.
• If exploitation is suspected, preserve web server logs, ZendTo logs, authentication logs, and copies of the dropoff storage metadata before cleanup.