When you share a ChatGPT conversation, the share page gets an Open Graph preview image served from a separate hostname. I found that deleting the conversation correctly invalidated the share page, but the preview image kept being served without authentication, with an excerpt of the deleted conversation still in it.
I reported it to OpenAI through Bugcrowd. It was a duplicate of a report filed six days before mine, and the submission has since been marked resolved. Every test described here used my own account and my own conversations. I have left the real conversation IDs out of this post.
Creating a share link gives you a page at https://chatgpt.com/share/<id>. Chat apps and social networks fetch the page's Open Graph metadata to build a link preview. For a live share, that metadata describes the conversation, and the preview image comes from a different host:
https://ogimg.chatgpt.com/conversation/<id>/response_multicolor_v1.png
The same conversation ID appears in both URLs. The PNG contains an excerpt of the response text on a colored background. The image request carries no cookies and needs no login, which makes sense for a resource that crawlers fetch.
So a single user action, sharing, produces two public surfaces. The question I wanted to answer was whether a single user action in the other direction, deleting, reaches both of them.
The sequence was:
The checks I ran, with the ID as a placeholder:
ID="<conversation-id>"IMG="https://ogimg.chatgpt.com/conversation/$ID/response_multicolor_v1.png"# before deletioncurl -s -D before.headers -o before.png "$IMG"md5sum before.pngcurl -s "https://chatgpt.com/share/$ID" | grep -i 'og:'# delete the conversation in the UI, then:curl -s -D after.headers -o after.png "$IMG?cb=$RANDOM"md5sum after.pnghead -n 1 after.headersgrep -i -E '^(cache-control|age|access-control-allow-origin):' after.headerscurl -s "https://chatgpt.com/share/$ID" | grep -i 'og:'
On September 5, more than 48 hours after deletion, the same URL still returned the same conversation-derived image.
This is the part where it is easy to overclaim, so here is what the evidence does and does not support.
The response advertised max-age=86400 and stale-while-revalidate=3600. A cache that follows those headers can serve an entry as fresh for 24 hours after it was stored, then serve it stale for at most one more hour while it revalidates in the background. If the origin had stopped serving the image at deletion time, the longest a compliant shared cache could keep returning it is roughly 25 hours.
I saw it at 48 hours or more. That does not prove anything about OpenAI’s internals, since tiered caches and misconfigured caches exist, but it moves ordinary TTL expiry down the list of likely explanations.
The cache-busting result narrows things too. Identical bytes on a request with a new query string means one of the following:
From the outside I cannot tell these apart, and my report said so. What I could establish was the externally observable behavior: a public, unauthenticated URL kept returning content derived from a deleted conversation for longer than the response headers would explain.
Later, the preview URL from my original test started returning a generic ChatGPT image. That looked like a remediation.
On September 30 I ran the whole sequence again with a brand new conversation. About 26 hours after deleting it, its preview image was still returning conversation-derived content. My reading, and it is only a reading, is that the first fix touched that specific asset rather than the deletion path. The report was moved back to Unresolved on October 4 and marked Resolved on October 6. I do not know what changed behind the scenes.
The triage team rated this P4, and I think that is reasonable. The limits are real:
Who can still use it? Anyone who already held the link: the people it was sent to, anyone who saw it in a chat history, browser history or log, and anything that stored the URL. Those are exactly the people a user is trying to cut off when they delete a shared conversation after changing their mind or sharing with the wrong person.
There is also a layer OpenAI does not control. Messaging and social platforms that generate link previews often keep their own copy of the image. Deletion cannot reach those. That makes the origin and CDN the only layers where the vendor can actually enforce a delete, which is a good reason to get those right.
The behavior also conflicts with what the product says. OpenAI’s documentation states that deleting a conversation removes its shared link. A user reading that does not expect a second URL to keep the content reachable.
Bugcrowd marked my report as a duplicate of one submitted on August 28, six days before mine. No bounty, which is how duplicates work, and I do not mind it. The second reproduction after the first apparent fix is probably the most useful thing my report added.
This is a design sketch based on what I could observe, not a description of OpenAI’s system.
Checking that the main database row is gone is not enough. A lifecycle test looks like this:
Step 5 with the changed query string is what separates a cache that is merely slow from a store that never got the delete.
All testing was done against my own account and my own conversations. No other user’s data was accessed. The issue was reported through OpenAI’s Bugcrowd program, marked Resolved and Duplicate, and this post was coordinated through Bugcrowd’s disclosure process. Conversation IDs are omitted.
Delete Is a Promise: A Security Researcher’s Look at AI Conversation Privacy was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.