Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessInstall malicious app on device
-
DeliveryRegister ContentProvider with traversal _display_name
-
ExploitSend ACTION_SEND intent to exported ShareReceiveActivity
-
ExecutionTickTick copies file via unsanitized getDisplayNameFromUri path
-
ImpactArbitrary file write with TickTick privileges
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V5 - File Handling Path canonicalization, traversal prevention
MITRE ATT&CK
2 techniques across 2 tactics: Discovery, Collection The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires a malicious application to already be installed on the same Android device as TickTick 8.2.2.0. That app must register a ContentProvider that returns a _display_name value containing path-traversal sequences and send an ACTION_SEND intent carrying a crafted content:// URI to the exported ShareReceiveActivity; the unsanitized display name flows through FileManager.getDisplayNameFromUri and AttachmentFileHelper.copyFileDirectly to produce the write. Limiting factors: exploitation is local only (no remote/network path) and requires attacker-controlled code co-resident on the device; no special TickTick configuration is needed because ShareReceiveActivity is exported by default and no user interaction or authentication within TickTick is required. |
| Impact | This is a genuine but moderate-priority issue, not a high-urgency emergency. The CVSS 4.0 base score of 6.9 (Medium) reflects the key constraint: AV:L means exploitation requires a malicious application already present on the same Android device - this is not a remotely reachable or network-exploitable flaw. Complexity is low (AC:L/AT:N), no privileges or user interaction are needed (PR:N/UI:N), and the impact is confined to integrity (VI:H) via arbitrary file write with TickTick's own sandbox privileges; there is no confidentiality (VC:N) or availability (VA:N) impact and no scope change to other apps. No EPSS probability was provided in the input and the CVE is not listed in CISA KEV, so there is no signal of widespread or active exploitation. A referenced GitHub repository (actuator/com.ticktick.task) strongly suggests public proof-of-concept code exists, which raises practical exploitability, but PoC availability is distinct from active exploitation. Net: the signals are internally consistent - a credible, locally-exploitable integrity flaw with likely public PoC, but gated behind the attacker first getting a malicious app onto the victim's device, making it a targeted rather than mass-exploitation threat. |
| Exploit ScenarioDerived | A user installs a malicious or trojanized app that shares content with TickTick. That app registers a ContentProvider whose _display_name contains '../' traversal sequences and fires an ACTION_SEND intent at TickTick's exported ShareReceiveActivity, causing TickTick to copy an attacker-controlled file to an arbitrary location in its sandbox with its own privileges. Publicly available exploit code likely exists via the referenced actuator GitHub repository, and no user interaction is required because the activity is exported. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 19, 2026
Path traversal in the TickTick Android app (com.ticktick.task) 8.2.2.0 lets a malicious co-resident application write files to attacker-chosen locations using TickTick's own application privileges. The attacker must already have code installed on the same device and register a ContentProvider whose _display_name value contains traversal sequences, then deliver an ACTION_SEND intent with a crafted content:// URI to TickTick's exported ShareReceiveActivity; the unsanitized name passes through FileManager.getDisplayNameFromUri and AttachmentFileHelper.copyFileDirectly, yielding arbitrary-location writes with high integrity impact but no confidentiality or availability impact. No public exploit code or confirmed active exploitation was identified at time of analysis, and the impact is limited to local, same-device scenarios requiring the victim to have already installed the attacker's app.
RemediationAI
No vendor-released patch or exact fixed version is identified in the available data, so treat the status as 'No vendor-released patch identified at time of analysis' and confirm with the vendor whether a later TickTick Android build sanitizes the _display_name value in FileManager.getDisplayNameFromUri before it reaches AttachmentFileHelper.copyFileDirectly. Until a patched release is verified, apply compensating controls: require user confirmation before installing any newly released TickTick build and monitor the vendor's release notes for a fix to the share/attachment handling path; on managed device fleets, restrict sideloading and enforce app-allowlisting via Play Protect, Android Enterprise or an MDM so a hostile app cannot be co-resident with TickTick - the trade-off is reduced flexibility for legitimate third-party app installs. Additionally, on high-assurance devices, remove or disable sharing into TickTick where policy allows (for example by not granting it as a share target through work-profile configuration) so ACTION_SEND intents never reach ShareReceiveActivity, at the cost of losing TickTick's share-to-task workflow; and consider isolating TickTick in a separate work profile from untrusted apps, which limits the reachable filesystem locations an attacker-chosen traversal path can target.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is a classic CWE-22 path traversal arising from trust placed in data crossing an Android IPC boundary. TickTick exports ShareReceiveActivity to handle ACTION_SEND share intents, and when the intent carries a content:// URI, TickTick resolves it through a ContentProvider and reads the _display_name column - a value supplied by whichever provider owns that URI. Because FileManager.getDisplayNameFromUri passes the display name through without sanitization and AttachmentFileHelper.copyFileDirectly uses it to build the destination path, a name containing '../' sequences escapes the intended attachment directory and lands the copied file wherever the attacker specifies, written with TickTick's UID permissions. The relevant weakness class is improper neutralization of traversal sequences in a filename derived from an untrusted content provider; the exported-by-default activity means no special TickTick configuration is required, and because there is no network vector and the attacker must already run code on the device, the practical exposure is local privilege-boundary abuse between apps rather than a remote compromise path. The independent assessment scores this CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N, confirming high integrity impact with no confidentiality or availability impact.
Know when Android gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Exploited by a co-located malicious app via IPC so AV:L; exported activity needs no privileges or interaction (PR:N/UI:N); arbitrary file write within TickTick's sandbox gives I:H with no confidentiality or availability impact and no scope change.
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
DescriptionCVE.org
TickTick Android application (com.ticktick.task) 8.2.2.0 contains a path traversal vulnerability in its exported ShareReceiveActivity that allows a malicious local application to write files outside the intended attachment directory by supplying a crafted content:// URI with a traversal filename via ACTION_SEND intents. A malicious application can register a ContentProvider returning a _display_name value containing traversal sequences, which is passed unsanitized through FileManager.getDisplayNameFromUri and AttachmentFileHelper.copyFileDirectly, causing automatic file writes to attacker-chosen locations with TickTick's application privileges.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Path traversal exploits occur when applications use user-controlled input to construct file system paths without proper validation.
Adobe Flash Player before 13.0.0.292 and 14.x through 18.x before 18.0.0.160 on Windows and OS X and before 11.2.202.466
Integer underflow in the MPEG4Extractor::parseChunk function in MPEG4Extractor.cpp in libstagefright in mediaserver in A
Android 3.0 through 4.1.x on Disney Mobile, eAccess, KDDI, NTT DOCOMO, SoftBank, and other devices does not properly imp
Integer overflow in the SampleTable::setSampleToChunkParams function in SampleTable.cpp in libstagefright in Android bef
Apktool versions 2.9.1 and prior contain a path traversal vulnerability when processing Android APK files. Malicious APK
An elevation of privilege vulnerability in the Android system (art). Rated high severity (CVSS 7.8), this vulnerability
The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a
Use-after-free vulnerability in Adobe Flash Player before 13.0.0.292 and 14.x through 18.x before 18.0.0.160 on Windows
Use-after-free vulnerability in Adobe Flash Player before 13.0.0.292 and 14.x through 18.x before 18.0.0.160 on Windows
Android 1.6 Donut through 4.2 Jelly Bean does not properly check cryptographic signatures for applications, which allows
luni/src/main/java/java/io/ObjectInputStream.java in the java.io.ObjectInputStream implementation in Android before 5.0.
The Broadcom Wi-Fi driver in the kernel in Android 4.x before 4.4.4, 5.x before 5.1.1 LMY49G, and 6.x before 2016-02-01
EUVD-2026-104525
GHSA-vw56-52xp-9grq
NVD
CVE.org
EPSS
Exploit-DB