Coordinated disclosure · Case 01 · imo Messenger

The link that
tells on you.

You tell them you're in New York. But one link in the chat is enough: imo reveals your real IP address — and the city you're actually in — the moment it appears. You never open the link. Just seeing it in the chat does it. No tap, no server. Over 500 million installs.

On a call the recipient claims to be in New York on a call
Hey, where are you?
Can we meet today?
Sorry, I can't —
I'm in New York.
what they claim
SCENE 01 · the claim
The sender's webhook.site link quietly leaks the recipient's real IP; the recipient never taps it
SCENE 02

One link, sent from nothing

The sender drops a free webhook.site link in the chat. The recipient never taps it — just seeing it sit in the open chat is enough. imo fetches it from their phone on its own, and the real IP goes out with the request. No own server, no malware.

The leaked IP pins the recipient's real location to Berlin on a map
SCENE 03

The map says otherwise

That IP resolves to a city and a network. The sender now sees the truth the recipient tried to keep private.

Said on the call
New York
vs
What the IP reveals
Berlin, DE
from a single chat link
Why it matters

A location you never agreed to share.

An IP address is not just a number. It points to your city, your network, your rough position — enough to confirm you are home, to catch that you lied about where you are, or to track where you move. Here it costs the attacker nothing: a free link, and a messenger that answers for you.

Signal, WhatsApp and iMessage avoid this by fetching previews on a server or only on the sender's device. imo fetches from the recipient — the one person who should never touch the attacker's link.

Technical write-up

imo Messenger — findings & analysis

Summary & severity

imo Messenger (PageBites, Inc.) was tested on Android, iOS, macOS and Windows. Two findings are published here. A third observation — the spoofed Facebook User-Agent — is documented as part of F-PREVIEW rather than as a standalone issue, because on its own it is a behaviour, not a vulnerability.

IDFindingCWECVSS 3.1Severity
F-PREVIEWZero-click IP/metadata leak via link preview200/3194.3Medium
F-STORAGECleartext credential storage → account takeover3126.2Medium
F-UARequest spoofs facebookexternalhit (folded into F-PREVIEW)451—Context
F-PREVIEW · CWE-200 / CWE-319

Zero-click IP & metadata leak via link preview

Medium · CVSS 4.3

Description

On receiving a chat message that contains a URL, the recipient's client performs an HTTP GET to that URL to build a link preview. The fetch originates from the recipient's device, exposing their real IP address, User-Agent and online status to whoever controls the URL. No opt-out, no caching (the fetch repeats each time the chat is opened), and the request carries the User-Agent facebookexternalhit/1.1 Facebot Twitterbot/1.0. A free request-logging service such as webhook.site is enough — the attacker needs no infrastructure of their own.

request log behind the link
$ GET /t/aXk9 HTTP/1.1 Cf-Connecting-IP: 91.64.xx.xx ← recipient's real IP └─ geolocates to: Berlin, DE User-Agent: facebookexternalhit/1.1 Facebot Twitterbot/1.0 X-Forwarded-For: 91.64.xx.xx [=] recipient-side fetch — zero taps, zero consent [=] control: WhatsApp → sender-side fetch (no recipient IP) [=] control: Telegram → server-side fetch (datacenter IP)

Illustrative capture. The IP is an example; real tests used a disposable logging endpoint and confirmed the recipient-side origin against WhatsApp and Telegram.

Affected

imo Messenger for iOS 2026.1.3 and macOS 2.27 (and the current Android and Windows builds as of 1 March 2026). No fixed version available.

Why it matters on imo specifically

imo permits unsolicited contact through groups and phone-number messaging. An attacker needs no accepted contact relationship — a shared group, or a single reply, is enough to deliver a link and trigger the leak.

Expected behaviour

  • Server-side proxy fetching (Signal, WhatsApp, iMessage), or
  • Sender-only preview generation with metadata embedded in the encrypted message, or
  • Opt-in previews with informed consent about the IP exposure.

CVSS 3.1 breakdown

AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N → Base 4.3 (Medium)

The impact is limited to disclosure of an IP address plus a User-Agent, which is C:Low — this caps the score at Medium regardless of how little interaction is required. If the fetch fires without the recipient opening the conversation, the vector becomes UI:N and the score 5.3, still Medium.

F-STORAGE · CWE-312

Cleartext credential storage → account takeover

Medium · CVSS 6.2

Description

Authentication material (phone number, session cookie, UDID, auth tokens) is stored in cleartext in local application data — LevelDB on macOS, a data file on Windows. On Windows, the AES-CBC key is stored in cleartext alongside the encrypted data, which defeats the encryption entirely: anyone with filesystem read access can decrypt it.

Impact

An attacker with local file-read access (lost/stolen device without full-disk encryption, unencrypted backups on shared storage, malware running with user privileges, or forensic acquisition) can extract valid session credentials and impersonate the user against imo's backend without re-authentication.

CVSS 3.1 breakdown

AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N → Base 6.2 (Medium)

Confidentiality impact is High (full account credentials), but the requirement for local access (AV:Local) holds the base score in the Medium band.

A note on the severity scores

Why these numbers are deliberately not higher A CVSS base score is driven by the attack vector, the interaction needed and the confidentiality/integrity/availability impact — not by how alarming a finding sounds. A privacy leak that reveals an IP address is C:Low, so it cannot reach High no matter how "zero-click" it is; zero-click only lowers the interaction metric, not the impact ceiling. A cleartext-storage issue needs local access, so AV:Local keeps it in the Medium band. These findings are real and worth fixing — and honestly Medium. I would rather publish defensible scores than inflated ones.

Disclosure timeline


This write-up documents a privacy and data-protection weakness for defensive and research purposes. It contains no malware and no ready-to-run exploit beyond a minimal logging endpoint used to demonstrate the leak.