# 2 click Remote Code execution in Evernote Android

Evernote Android trusted the attachment filename from the content-disposition header, so a renamed attachment with ../ traversal was written into the app's lib dir, enabling native library code execution.

- Payout: hidden
- Severity: high
- Program: Evernote
- Found by: hulkvision_
- Disclosed: 2022-03-29
- Write-up quality: 8/10
- Original: https://hackerone.com/reports/1377748
- Library page: https://bugbountylibrary.com/r/h1%3A1377748
- Tags: area:mobile domain:mobile impact:rce kind:bounty platform:hackerone sev:high tech:android tech:react technique:incomplete-fix technique:source-review vuln:path-traversal vuln:rce

**Target:** Evernote Android app attachment download (React Native)
**Root cause:** The app extracts the attachment filename from the server's content-disposition header and writes the downloaded file to that path without sanitizing traversal sequences, allowing writes outside the cache/preview directory into the app's native library directory.
**Steps:**
1. Add a native-library PoC file to a note.
2. Rename the attachment to `../../../lib-1/libjnigraphics` (traversal in filename).
3. Invite the victim to the note (shareable link alone doesn't work on Android).
4. Copy internal/web/app link and send to victim; victim opens link (click 1).
5. Victim clicks the attachment in the opened note (click 2).
6. Close and reopen Evernote; from adb shell run `nc 127.0.0.1 6666` to confirm code execution (use physical arm64 device).
**How found:** Researcher noticed attachment renaming did not restrict special characters, and that a file named libjnigraphics.so could be renamed to ../../../lib-1/libjnigraphics.so. Suspected the download path was derived from the filename; confirmed the app reads filename from the content-disposition response header and does not sanitize it, unlike the previously reported _display_name provider issue.
**Exploitation:** Attacker shares a note containing a malicious native library renamed with a ../ traversal path. When the victim opens the note and taps the attachment, the app downloads it and writes it to /data/data/com.evernote/lib-1/libjnigraphics.so instead of the cache preview dir. On app restart the library is loaded, executing attacker code (reverse shell on localhost:6666).
**Escalation:** Chained with social engineering (note invite + deeplink) to achieve 2-click RCE; distinct root cause from prior report #1362313 so the earlier fix did not mitigate it.
**Insight:** When a prior report fixed one filename source (content provider _display_name), check other filename sources feeding the same sink — here the HTTP content-disposition header — since fixes often cover only one input path. Also target writes into the app's native lib directory, which yields code execution on next load.