Lost in translation: when your bank texts you — but it isn’t your bank

Imagine this: you open your messaging app and see a link from your bank, your employer, or a close friend. The link is part of an ongoing message chain, and you know the sender. Because you see nothing suspicious, you tap the link.

It isn't until later that you realize the message never came from who you thought it did.

Until recently, this scenario was possible under specific carrier, device and messaging-client conditions, say researchers from the University of California San Diego and Carnegie Mellon University.

The security dangers of legacy email-to-SMS infrastructure

In May 2026, these research teams presented their Distinguished Paper Award-winning paper "Lost in Translation: Text Message Spoofing via Email" at the IEEE Symposium on Security and Privacy.

The paper showed how researchers could exploit legacy email-to-SMS infrastructure to inject spoofed messages across several major North American carriers.

Under specific carrier, device and messaging-client conditions, these spoofed messages could appear inside trusted conversation threads on Android and iOS devices. Under vulnerable conditions, Android messaging clients could interpret some crafted sender strings as phone-number-like identities. On iOS, conversation association across messaging channels could, in certain scenarios, make sender provenance less obvious to users.

While the researchers responsibly disclosed their findings to each of the carriers in their study and the mobile carriers largely mitigated these vulnerabilities before the paper's public release, these paper findings highlight a broader challenge facing the mobile security industry.

Increasingly, attackers exploit connections between legacy infrastructure and modern applications — as well as user expectations.

In this post, we examine what the researchers found and why it matters for organizations securing mobile fleets at scale.

Researchers revealed how to spoof inside mobile message threads

At first glance, this might sound like just another SMS spoofing story. It is not.

The most important finding wasn’t simply that attackers could forge text messages. SS7 abuse, SIM swapping, smishing and rogue infrastructure taught the industry that years ago.

What made this research different was something subtler and far more dangerous: the forged message could inherit the trust of an existing conversation.

That distinction changes everything. A suspicious text from an unknown number is easy to question. A malicious message appearing inside the same thread as your bank’s legitimate alerts is far more convincing.

Security practitioners have warned about SMS for years.

The existence of SIM swaps, OTP interception, smishing campaigns and SS7 exploitation all teach the same lesson: SMS should not be treated as a high-assurance channel.

Exploiting end-user trust

Most users, however, still assume that if a message appears inside an existing trusted conversation, it is probably legitimate.

This is how thread injection changes the threat model.

Traditional phishing relies on urgency and has noticeable red flags: unfamiliar numbers, odd formatting or new conversations. Thread injection removes many of those defenses.

Picture a long thread full of legitimate bank alerts, OTPs and account notifications. Now insert this:

 > Suspicious transaction detected. Verify immediately: [link] 

Mobile interfaces present clean, human-friendly identities while suppressing the uncertainty and provenance beneath them. The victim evaluates the message within a trusted context, not in isolation. Users rarely inspect protocols; they trust what the interface tells them.

Humans trust continuity, and attackers exploit that instinct.

Phishing attacks at work are widespread.

Jamf's Security 360: Mobile Devices 2026 report found that one in four organizations reported having a user fall victim to a phishing link. This research highlights an additional dimension of that problem: attackers do not always need to disguise malicious content if they can instead manipulate the identity and context surrounding it.

Under specific conditions, both carrier infrastructure and messaging clients could contribute to that deception by making spoofed messages appear more trustworthy than they actually were.

The ease of this attack method

What makes the attack especially notable is what it didn’t require:

• Carrier compromises
• Privileged telecom access
• Rogue base stations
• Network-level interception

Instead, it leveraged a forgotten interoperability feature.

The forgotten bridges between email and text: a history

In the early 2000s, carriers introduced email-to-text gateways to bridge internet and cellular messaging. These services let users send emails to addresses like <phone-number>@vtext.com (Verizon) or <phone-number>@tmomail.net (T-Mobile), which the gateway would translate into native SMS or MMS.

Gateway evolution

Originally built for pagers, enterprise alerts and automated notifications, these gateways evolved incrementally over years of operational patches and compatibility updates rather than through a deliberate security-first redesign. That persistence created inconsistent translation semantics and significant security debt.

Email and SMS were designed with very different trust models.

Email includes rich metadata such as 'From' headers, display names and SMTP envelope sender. Email has protections like SPF, DKIM and DMARC. SMS is simpler: it relies mainly on phone numbers, short codes or alphanumeric identifiers.

The translation step at the gateway became a critical attack surface. The exact behavior depended on each carrier's implementation, including differences in identity handling and translation logic.

Vulnerability emerged at the composition boundary

Neither email nor SMS was fundamentally broken in isolation.

The flaw was a classic composition failure: two well-understood systems became insecure when joined through ambiguous translation logic.

The researchers found inconsistent identity mapping across carriers.

One class of attacks illustrates the issue: A gateway evaluated authentication against the visible From: header. Downstream logic, however, derived the displayed SMS sender from the SMTP envelope sender (MAIL FROM).

That mismatch created a dangerous gap between validated identity and what the recipient ultimately saw. In certain cases, attackers could satisfy checks on a controlled domain while influencing the visible sender identity downstream. This created exploitable ambiguities rather than universal spoofing.

The phone helped complete the illusion

The carrier gateway was only half of the attack. Modern messaging apps finished the job by normalizing identities in service to a clean user experience.

Conceptually, a sender string like 987@6543.210 illustrates the issue. Under vulnerable parsing logic, separators such as `@` and `.` could be treated differently by different layers of the software stack, allowing downstream logic to interpret the sender as a numeric phone identifier rather than an email address.

Mobile presents unique challenges

Users attempting to assess trust face smaller displays, limited visibility into URLs and message metadata, and the highly personal nature of smartphones. These limitations often encourage users to rely on visual cues rather than technical indicators when deciding whether a message is legitimate.

The deeper lesson: cross-protocol trust collapse

This research’s biggest insight isn’t about SMS specifically. It’s about identity in modern systems.

As software merges signals from multiple trust domains into unified interfaces, the gap between “displayed identity” and “authenticated identity” becomes a recurring vulnerability. We see the same pattern in email: display-name spoofing, caller ID abuse and business messaging impersonation.

The most unsettling lesson from “Lost in Translation”

Neither email nor SMS protocol had to be broken for this to work. The vulnerability lived in the invisible glue between them: translation layers, compatibility middleware and normalization logic.

These layers are easy to ignore because they’re designed to disappear. Yet they often carry outdated trust assumptions.

Practical approaches for IT admins

Modern software increasingly asks users to trust abstractions instead of protocols.

Traditional identity providers cannot prevent carrier-level message spoofing, but enterprise mobility and device-security platforms can reduce organizational exposure.

As this research shows, the most fragile security boundary may not be the protocol itself, but the invisible software translating one protocol into another and, in the process, redefining trust.

For security practitioners, the lessons from Lost in Translation are practical:

• Treat SMS as a low-trust notification channel, not as a high-assurance authentication factor.
• Educate employees that message thread placement does not prove sender authenticity — while also enforcing strong device posture controls.
• Prioritize phishing-resistant multi-factor authentications such as passkeys, FIDO2 keys, or certificate-based authentication.
• Ensure mobile fleets stay patched, policy-compliant and integrated into zero-trust access decisions through centralized device management such as Jamf.
• Integrate device trust signals into access decisions so that communication channel spoofing alone cannot compromise critical workflows.

For organizations securing Apple and mobile-first environments, the goal is not simply patching devices. It is ensuring that trust decisions incorporate device posture, identity assurance and resilient authentication rather than relying on legacy communication channels.

How Jamf helps mitigate

At Jamf, we regularly analyze emerging mobile attack vectors to understand how architectural weaknesses translate into real enterprise risk. For troubleshooting, many Apple admins find the Jamf Management Framework useful.