Abusing Samsung Find’s Notification API to Send Trusted Emails to Arbitrary Recipients

How a client-controlled notification flow enabled arbitrary email delivery through Samsung’s trusted infrastructure

Daniele ArmentanoAugust 2, 2026 9 min Read on Medium

Summary

In April 2026, I discovered a server-side authorization flaw in Samsung Find. The endpoint that configures the “device found” notification accepted two client-controlled fields without validating them against the authenticated account:

email — used as the destination address, never verified against the account's own addresses;
displayName — inserted into the subject and body of the generated email.

Saving a modified configuration and then triggering a legitimate device-found event caused Samsung’s infrastructure to deliver a genuine notification email, from Samsung’s real sender address and with Samsung’s normal branding, to an arbitrary third-party recipient, containing attacker-supplied text in the subject line and body.

Samsung confirmed the vulnerability and deployed a security update.

Affected Component

Service: Samsung Find

Environment: Production

Web application: samsungfind.samsung.com

API host: api.samsungfind.com

Affected endpoint: PUT /devices/{deviceId}/notifications/found

Samsung Find used this endpoint to configure the email notification sent when a registered device was found.

Discovery

I found the vulnerability while analyzing the requests generated by Samsung Find’s notification feature. The normal application flow sent an authenticated request similar to:

PUT /devices/{deviceId}/notifications/found HTTP/2
Host: api.samsungfind.com
Content-Type: application/json
Origin: https://samsungfind.samsung.com
X-Sec-Find-Client-Type: web
X-Sec-Sa-AuthToken: <AUTH_TOKEN>
X-Sec-Sa-UserId: <USER_ID>

The request body contained the destination email address and the device display name:

{
  "item": {
    "enabled": true,
    "userId": "<USER_ID>",
    "email": "owner@example.com",
    "language": "en",
    "displayName": "Galaxy Buds",
    "units": "L"
  }
}

Both values came directly from the client. The email field determined where the notification would be delivered. The displayName field was reused in the generated email subject and body.

Legitimate Samsung Find notification interface

I intercepted the request and replaced the original recipient with a different email address. I also changed the device display name to a longer message containing urgent language, a telephone number and a URL.

The notification request accepts both the destination email address and the device display name from client-controlled input.

The backend accepted the modified request:

{
  "requestId": "[redacted]",
  "timeCurrent": 1775756840349
}

The supplied recipient then received a genuine Samsung Find email.

Delivery Model

The PUT request does not itself send an email. It stores the notification configuration for the device. The email is generated and delivered when the device subsequently reports as found — in my testing, whenever the registered Galaxy Buds were powered on and reconnected to the paired phone. Each delivery therefore requires a device-found event.

I did not test whether a found-event can be induced programmatically (for example by emulating the device’s BLE advertisement) rather than physically. If it can, the throughput constraint largely disappears.

Arbitrary Recipient Control

The API accepted the destination address from the email field without binding it to the authenticated Samsung account. A request could specify any recipient:

{
  "item": {
    "enabled": true,
    "userId": "<USER_ID>",
    "email": "external-recipient@example.net",
    "language": "en",
    "displayName": "Galaxy Buds",
    "units": "L"
  }
}

The backend used that address for the outbound notification. The recipient did not need to match the email address associated with the Samsung account. No verification step was required for the supplied destination. This allowed an authenticated Samsung account to direct Samsung-generated transactional emails toward unrelated third-party addresses.

Attacker-Controlled Subject and Body Content

The displayName value appeared in the notification subject and message body. Samsung’s template wrapped the supplied value as {displayName} found!.

A test value such as:

[URGENT] Device compromised - Call Samsung Support +39 333 1234567 or visit www.example.com - a new vulnerability

produced a subject similar to:

[URGENT] Device compromised - Call Samsung Support +39 333 1234567 or visit www.example.com - a new vulnerability found!

Dear customer, [URGENT] Device compromised - Call Samsung Support +39 333 1234567 or visit www.example.com - a new vulnerability is found. If you want to check the location, please click the link below. https://samsungfind.samsung.com

The controlled content occupied the most visible areas of the message:

the email subject;
the inbox preview;
the device-name section near the beginning of the body.

Plain-text URLs and telephone numbers were preserved. Email clients could automatically render the supplied URL as a clickable link.

Samsung Find generated a legitimate notification email containing attacker-controlled content in both the subject and body.

Abuse of Samsung’s Trusted Email Infrastructure

The message was generated by Samsung Find and delivered using Samsung’s real outbound notification channel (noreply@samsungfind.samsung.com). The message included Samsung branding, Samsung’s notification structure and a link to the legitimate Samsung Find website. This gave the attacker-controlled content the trust context of a real Samsung transactional email.

A recipient would see:

a legitimate Samsung sender;
Samsung’s normal email branding;
Samsung-controlled surrounding text;
an attacker-controlled warning or instruction in the subject;
the same controlled content near the beginning of the body.

The notification was delivered through Samsung Find’s legitimate outbound email infrastructure.

This created a high-trust delivery primitive suitable for phishing, impersonation and spam campaigns.

Rate Limiting

No rate limiting was observed on the configuration endpoint during testing: repeated PUT requests continued to return successful responses. I did not attempt to establish a precise threshold, and given the delivery model the practical constraint on abuse was the device-found event rather than the request rate.

Proof of Concept

curl 'https://api.samsungfind.com/devices/<DEVICE_ID>/notifications/found' \
  -X 'PUT' \
  -H 'accept: application/json, text/plain, */*' \
  -H 'content-type: application/json' \
  -H 'origin: https://samsungfind.samsung.com' \
  -H 'referer: https://samsungfind.samsung.com/' \
  -H 'x-sec-find-client-type: web' \
  -H 'x-sec-sa-authtoken: <AUTH_TOKEN>' \
  -H 'x-sec-sa-countrycode: ITA' \
  -H 'x-sec-sa-userid: <USER_ID>' \
  -H 'x-sec-tab-name: DEVICES' \
  --data-raw '{
    "item": {
      "enabled": true,
      "userId": "<USER_ID>",
      "email": "external-recipient@example.net",
      "language": "en",
      "displayName": "[URGENT] Device compromised - Call Samsung Support +39 333 1234567 or visit www.example.com - a new vulnerability",
      "units": "L"
    }
  }'

Successful response:

{
  "requestId": "[redacted]",
  "timeCurrent": 1775756840349
}

The external recipient received the resulting Samsung Find notification shortly afterward.

Testing Notes and Boundaries

To scope the finding, I tested several adjacent variants that did not work. Recording them defines the boundary of the vulnerability:

HTML injection in displayName — blocked. Markup was escaped in the rendered email; only plain text was reflected.
CRLF / header injection in displayName — blocked. Newline sequences did not permit injection of additional headers or recipients.
deviceId manipulation — the identifier was correctly bound to the authenticated account; no IDOR was possible against other users' devices.
userId in the request body — no exploitable effect observed.
displayName length — a server-side cap was enforced, but the permitted length comfortably exceeded that of a plausible phishing message, so the cap did not constrain the attack.

Security Impact

The vulnerability allowed an authenticated Samsung account to emit genuine Samsung transactional email to a recipient of its choosing, with attacker-controlled text in the most visible parts of the message.

Targeted phishing and impersonation.

The recipient sees noreply@samsungfind.samsung.com, Samsung's own template and branding, and a legitimate link to samsungfind.samsung.com — alongside attacker-supplied content in the subject line, the inbox preview, and the opening of the body. Plain-text URLs and telephone numbers were preserved and were auto-linked by some email clients. Because the surrounding message is authentic, the usual signals a recipient uses to identify a phishing attempt are absent. A single message of this kind against a chosen target is the realistic risk; the attack does not depend on volume to be effective.

Persistent misdirection of legitimate notifications.

Because the recipient address is stored rather than supplied per-message, a device’s genuine found-notifications continued to be delivered to the substituted address until the configuration was changed back.

Sender reputation.

Any use of the flaw consumed Samsung’s own sending reputation. Recipient-side spam reports would be attributed to Samsung’s notification domain, with knock-on effects for the deliverability of legitimate Find notifications.

Root Cause

The vulnerability resulted from three server-side design decisions.

Client-controlled destination

(CWE-863, with CWE-807 as the underlying pattern). The backend used the client-supplied email value as the notification recipient. The recipient should have been resolved from an address already verified and authorized for the authenticated Samsung account.

Unrestricted device-name reuse

The notification template reused the device display name in the email subject and body. Device names are user-controlled values. Their use in trusted outbound communications allowed attackers to transform a device label into message content.

Missing anti-abuse controls

(CWE-799). The endpoint accepted repeated notification requests without an effective rate limit. An email-generating endpoint requires controls based on: account, device, recipient, delivery volume, time window, recipient changes, abnormal usage patterns.

Resolution

Samsung confirmed the vulnerability and later completed a security update. During post-update testing, I was no longer able to reproduce the original vulnerability. Samsung subsequently closed the report.

Disclosure Timeline

9 April 2026: Vulnerability reported to Samsung Mobile Security.

10 April 2026: Samsung assigned the report to a security analyst.

22 May 2026: Samsung confirmed the vulnerability and began working on the fix.

16 July 2026: Samsung completed the security update and closed the report.

16 July 2026: Final post-remediation testing performed.

28 July 2026: Requested permission to publicly disclose the vulnerability and shared the draft of this article with Samsung Mobile Security for review.

31 July 2026: Samsung confirmed that the draft was consistent with their analysis and had no requested changes prior to disclosure.

2 August 2026: Public disclosure.

Conclusion

Samsung Find treated two client-controlled values as trusted in an outbound notification workflow. The email parameter selected the destination without any check against the authenticated account, and the displayName parameter controlled prominent text in the subject and body. Samsung's backend then generated and delivered the message through its own email infrastructure.

The result was a delivery primitive with the trust properties an attacker normally has to forge: a genuine Samsung transactional email, sent from Samsung’s own address, carrying Samsung’s branding and template, with attacker-chosen text in the subject line and the opening of the body. Nothing in the message is spoofed. Authentication passes, the sender is real, and the link at the bottom points to the legitimate Samsung Find site. The recipient has no signal available to distinguish it from a notification Samsung intended to send.

The finding illustrates why notification endpoints deserve the same authorization scrutiny as invitation systems, password-reset flows and other features that emit mail on a user’s behalf. Any endpoint that causes an email to be sent is an authorization surface, and a device label that reaches a subject line stops being a label.