CVE-2020-25900 is now public. The issue affects HelloTalk, a language-exchange social app, through version 3.4.1. In NVD’s words, the app “stores full-precision GPS coordinates even when the user had intended to share only a country or city. Furthermore, these coordinates are placed into a database on the client of other users.”

That second sentence is the part worth dwelling on. The privacy control in the app was real in the sense that the interface honoured it, but it was applied at presentation time only. The underlying record still carried coordinates precise to roughly a tenth of a metre, and that record was replicated into an unencrypted SQLite database on the devices of every other user who had viewed the profile. A user who selected “country only” was, in practice, handing their home address to strangers, and anyone with access to a device could recover the home addresses of everyone that device’s owner had browsed.

NVD scores the issue 5.3 (Medium) under CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N. We think the score understates it. CVSS has no vocabulary for the difference between leaking an opaque identifier and leaking where a person sleeps, and this is a case where the confidentiality impact rating and the real-world consequence diverge sharply.

Why this pattern keeps recurring

Location coarsening is one of the most commonly requested privacy features in consumer applications and one of the most commonly implemented incorrectly. The mistake is almost always the same shape: the coarsening is applied in the view layer while the storage and synchronisation layers continue to move the exact value around. Everything looks correct in the interface, and the leak only becomes visible when you stop looking at the app and start looking at what it has written to disk.

Two habits catch this class of bug in an assessment. The first is to treat the app’s own local storage as an artefact to be examined rather than an implementation detail, because caches, backups, and offline databases routinely retain fields the interface has already discarded. The second is to check what a client receives about other users, not only what it sends about itself, since the interesting failures are usually in the data pushed down to a peer rather than the data pushed up to the server.

Disclosure timeline

The coordination on this one was unusually long, and we are publishing the timeline because it illustrates a situation researchers run into more often than the tidy case studies suggest.

• 2019-03-30 — The unencrypted htbackup/ SQLite database was found during an on-device review of the Android client.
• 2019-04-16 — Reported to the vendor with a proof-of-concept row and a Google Maps lookup demonstrating the precision.
• 2019-08 (approximate) — The vendor encrypted the local backup database. No advisory was published and no CVE was requested.
• 2020-09-16 — Follow-up asking for permission to disclose publicly and to apply for a CVE. The vendor replied that the issue was “not fixed completely” and asked for continued silence, then stopped responding.
• 2023-08-12 — CVE-2020-25900 assigned by MITRE, held in RESERVED state for want of a public reference.
• 2026-06-05 — Technical writeup published as the public reference, moving the record out of RESERVED.

A CVE that sits in RESERVED indefinitely helps nobody. The defect was fixed years ago, so publication carries no incremental risk to users, while the record itself gives downstream security teams something citable when they ask an app vendor how location data is stored on the device.

The full technical writeup, including the database schema and the extraction steps, is on our research blog. The CVE record is at NVD.