Live › vulnerability › CVE-2026-11319
Go to dashboardThe TickTick Android app (com.ticktick.task, version 8.2.2.0) exports a share-receiving activity that trusts the display name supplied by a content provider. A malicious installed app can make TickTick write attachment files to attacker-chosen paths with TickTick's privileges.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Android users who have TickTick 8.2.2.0 installed and also have another app installed that could be malicious. The flaw needs a local app on the same device to send a crafted share intent, so teams that manage Android devices should look at installed app versions. Users on iOS, the web, or other TickTick versions are not covered by this description.
No product ranges from the sources yet.
adb shell dumpsys package com.ticktick.task | grep versionName, and see whether it reads 8.2.2.0.8.2.2.0; the sources do not name the fixed version, so check the Play Store listing or the vendor notes.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-11319")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.