Path Traversal Vulnerability

This information is intended for developers with app(s) that contain the Path Traversal Vulnerability.

What’s happening

Beginning January 16th, 2018, Google Play started to block the publishing of any new apps or updates which contain the Path traversal Vulnerability. Please refer to the notice on your Play ConsoleAfter the deadlines shown in your Play Console, any apps that contain unfixed security vulnerabilities may be removed from Google Play.

Action required​

  1. Sign in to your Play Console, and navigate to the Alerts section to see which apps are affected and the deadlines to resolve these issues.
  2. Update your affected apps and fix the vulnerability.
  3. Submit the updated versions of your affected apps.

Upon resubmission, your app will be reviewed again. This process can take several hours. If the app passes review and is published successfully, then no further action is required. If the app fails review, then the new app version will not be published and you will receive an email notification.

Additional details

Implementations of openFile and openAssetFile in exported ContentProviders can be vulnerable if they do not properly validate incoming Uri parameters. A malicious app can supply a crafted Uri (for example, one that contains “/../”) to trick your app into returning a ParcelFileDescriptor for a file outside of the intended directory, thereby allowing the malicious app to access any file accessible to your app.

There are two recommended strategies for eliminating a Path Traversal Vulnerability in a ContentProvider.

1. If your ContentProvider does not need to be exposed to other apps:

2. If your ContentProvider needs to be exposed to other apps:

You must correctly ensure that inputs to openFile that contain path traversal characters cannot cause your app to return unexpected files. You can do this by checking the file’s canonical path. For example:

public ParcelFileDescriptor openFile (Uri uri, String mode)
   throws FileNotFoundException {
 File f = new File(DIR, uri.getLastPathSegment());
 if (!f.getCanonicalPath().startsWith(DIR)) {
   throw new IllegalArgumentException();
 return, ParcelFileDescriptor.MODE_READ_ONLY);



1. Note that calling getLastPathSegment on the Uri parameter is not safe. A malicious app can supply an encoded Uri path like %2F..%2F..path%2Fto%2Fsecret.txt so the result of getLastPathSegment will be /../../path/to/secret.txt. For example, the following implementation is still vulnerable to attack.

public ParcelFileDescriptor openFile(Uri uri, String mode) {
 File f = new File(DIR, uri.getLastPathSegment());
 return, ParcelFileDescriptor.MODE_READ_ONLY);

2. Note that UriMatcher match is not sufficient to sanitize or restrict path patterns ending in * like public/*. A malicious app can supply an encoded Uri path like public/%2E%2E%2Fprivate%2Fsecret.txt and, when combined with getLastPathSegment or getPath, the result will be public/../private/secret.txt

We’re here to help

If you have technical questions about the vulnerability, you can post to Stack Overflow and use the tag “android-security.” For clarification on steps you need to take to resolve this issue, you can contact our developer support team.

Was this helpful?
How can we improve it?
Google apps
Main menu
Search Help Center