Deleting another user's Instagram video note with a reused ID

Instagram lets you post a short note — including one in video form — that the people you follow back see at the top of their inbox, and only you can take it down. I found that by attaching another account's video-note media to a note of my own, deleting my note also deleted theirs, with no action from the victim. The flaw affected accounts that mutually follow each other, and Meta has since fixed it.

What does Instagram promise about notes?

A note is a short, personal message you share with the people you follow back. It sits at the top of their direct-messages inbox and disappears on its own after about a day. Instagram added the option to share a note in video form.

The quiet promise behind the feature is ownership: your note is yours. You decide when it appears, and you — not another account — decide when it comes down, short of the automatic expiry. The behaviour below breaks exactly that promise. A second account removed a note it never created.

How the attack worked

In plain words

Think of a note as a sticky label you place on a shared board. Each label points to one video pinned to the board. I found I could print my own label but aim it at the video you had pinned. When I later peeled off my label, the board also threw away the video it pointed to — and your label, pointing at the same video, had nothing left to show, so it vanished too.

What happened

The attack is three ordinary API calls, in order.

First, read the victim's note to learn the ID of its underlying video media.

GET /api/v1/notes/get_notes/ HTTP/1.1
Host: i.instagram.com

The response lists each active note. Inside a note's video_dict is the media pk — the ID I needed.

Second, create a note of my own, but tell the server to reuse the victim's media ID instead of uploading my own video.

POST /api/v1/notes/create_note/ HTTP/1.1
Host: i.instagram.com
Content-Type: application/x-www-form-urlencoded

note_style=7&text=test&audience=0
&_uuid=<DEVICE_UUID>
&note_create_info={"note_pog_video_create_info":
  {"note_pog_media_id":"<VICTIM_MEDIA_ID>"}}

(The request body is wrapped for narrow screens.) The server accepted the media ID without checking that it belonged to me, and linked my new note to the victim's existing media object.

Third, delete my own note.

POST /api/v1/notes/delete_note/ HTTP/1.1
Host: i.instagram.com
Content-Type: application/x-www-form-urlencoded

id=<YOUR_NOTE_ID>

Deleting my note removed the shared media object, and the victim's note — which pointed at the same object — disappeared with it. The victim did nothing and saw no prompt.

Reproduction

You need two accounts you own that follow each other, and an active video note on the account that will play the victim.

1. From the victim account, share a video note.
2. From the attacker account, call get_notes and copy the victim note's media pk from its video_dict.
3. Call create_note with note_pog_media_id set to that pk.
4. Call delete_note with the ID of the note you just created.
5. Both notes are gone.

What was the impact?

An attacker could silently delete the video note of anyone they mutually followed, as often as they liked, with no interaction and no notification to the victim. It is a data-integrity and denial problem, not a disclosure one: the attack removes content rather than reading it.

Scope and limits

Confirmed:

• Deleting a mutual's video note without any interaction from them, demonstrated on my own test accounts.
• The create call accepts another account's media ID.

Not confirmed:

• Reading or copying a victim's video note by guessing random media IDs. I did not test ID enumeration for read access and make no claim about it.
• Any effect on accounts that do not follow you back, which I could not reproduce against.
• Any effect beyond video notes.

Why did it happen?

The create-note endpoint trusted a caller-supplied media ID. When I sent note_pog_media_id, the server attached my note to whatever media that ID named, without asking whether the media was mine to use. That one missing check let two notes — mine and the victim's — share a single underlying object, and the delete path then treated that object as safe for me to remove. The identifier in my request, rather than the server, decided whose data was touched, which is why the catalog of software weaknesses files this pattern as Authorization Bypass Through User-Controlled Key.

How was it fixed?

Meta confirmed the issue was patched as of 2024-08-20. From the outside I can only observe that the create call no longer links a note to another account's media. In general, an endpoint closes this class of bug by checking ownership before it acts on any caller-supplied ID: before linking a note to a media object, confirm the signed-in account owns that media; before deleting, confirm the account owns the note and that removing it will not take down another user's content.

What can developers learn?

1. Treat every ID in a request as untrusted input, and confirm the caller owns the object it names before acting on it.
2. Check ownership at write time, not only at read time. A create or link call that accepts a foreign ID can do as much harm as a leak.
3. Watch for shared objects. If two records can point at one underlying object, deleting one record must not silently destroy another account's.
4. Scope destructive actions tightly, so a delete touches only what the caller owns and never cascades into content they do not. The OWASP API Security Top 10 lists this as its first risk.

FAQ

Is this fixed?

Yes. Meta confirmed the video-note deletion issue was patched as of 2024-08-20.

Was anyone's data exposed?

No. This bug deleted content; it did not read or leak private data. I tested only on accounts I own.

Who could be affected while it was open?

Only accounts that mutually followed the attacker — you follow each other — and that had an active video note.

What should affected users do now?

Nothing. The fix is server-side and needs no action from users.

What was the root cause?

The create-note API accepted another account's media ID without checking ownership, so deleting one note could take a victim's note down with it.

Timeline

• 2024-02-15: Reported with step-by-step reproduction.
• 2024-02-16: Provided a proof-of-concept demonstration.
• 2024-02-23: Triaged and routed to the product team.
• 2024-02-28: Meta awarded a bounty for the report.
• 2024-08-20: Vendor confirmed the issue was patched.
• 2026-10-19: Write-up published.