Case 02 — imo Messenger

The link that
tells on you.

You say you're in New York. But one link sitting in the chat is enough for imo to reveal your real IP address — and the city you're actually in. You never open the link. No tap, no server. Over 500 million installs.

By Abbas Hoseiny· Independent security research· Vendor: PageBites, Inc.
Read the story ↓ The technical write-up

A link preview looks harmless — a little card under a web address. But someone had to fetch that page to build it, and for your privacy one question decides everything: whose device did the fetching? This is Mia’s evening at home, and imo answered it the worst possible way.

Mia reads a message on her sofa and replies that she is away
Hey Mia — can we meet today?
Sorry, I’m in New York this week.
Fig. 1 — the claim

Mia is home in Berlin, curled up on the sofa. When Jonas asks to meet, she’d rather not — so she says she’s away: “I’m in New York this week.”

Mia views a link without opening it as the automatic preview request reaches a remote request log webhook.site/aXk9 never tapped
Fig. 2 — the silent fetch

Jonas sends a free webhook.site link. Mia sees it sitting in her chat but never taps it — and just seeing it is enough. imo fetches it from her phone on its own, and her real IP slips out the door. No tap, no server, no malware.

Jonas reads the request log beside an approximate city map without a precise location marker
New York?
She’s in Berlin.
Fig. 3 — the map says otherwise

On Jonas’s screen, that IP resolves to a city. Not New York — Berlin. The place Mia is sitting right now.

Mia said
New York
vs
Mia’s phone
Berlin, DE
from a single chat link
Mia looks unsettled at her phone as a logged request suggests her city
You’re in Berlin.
How do you know where I am?
Fig. 4 — the part that should unsettle you

Mia never shared her location. She saw a message, never tapped a thing. Yet there it is. The unsettling part isn’t the little fib — it’s that she never had a say. Anyone she chats with could have done this.

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’re home, to learn where you really are, or to track where you move. Here it costs the sender 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

PoC & reproduction on GitHub ↗

Contents
  1. Summary & severity
  2. F-PREVIEW — zero-click IP leak
  3. F-STORAGE — cleartext credential storage
  4. A note on the severity scores
  5. Disclosure timeline

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 storage3126.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 build (tested 1 March 2026). Windows is not affected — its build has no client-side link preview. 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

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 read the stored authentication material in cleartext, including a live session token. Whether that token can be replayed to impersonate the user without re-authentication depends on imo's server-side session binding, which I did not test.

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 because the stored authentication material is fully exposed in cleartext; integrity and availability are unaffected. 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.