ChatGPT Share Bug Leaves Preview Images Public After Conversation Deletion

However, the preview image URL continued to return the exact same image with an identical MD5 checksum (665c039d3d994998affa52b2835cba50). Even when using cache-busting query parameters to bypass local browser caches, the image remained accessible. Although OpenAI's response headers specified a maximum cache lifetime of 24 hours (max-age=86400) and a one-hour revalidation window, the researcher observed the conversation-derived image persisting more than 48 hours after deletion. This suggested that either the cache key ignored query strings, the image service served stored files without checking if the source conversation still existed, or a cache layer was configured to serve stale content when the origin returned an error.

Severity and Disclosure Timeline

The researcher submitted the finding to OpenAI via its Bugcrowd vulnerability disclosure program. The triage team rated the issue as a P4 severity, a classification the researcher agreed was fair. The impact is relatively constrained: an attacker cannot easily guess the long, complex conversation IDs, the image only reveals a short excerpt rather than the full chat, and the issue only affects conversations that the user had already explicitly chosen to share.

Nonetheless, the privacy risk is real for users who change their minds or accidentally share sensitive information. Anyone who previously accessed the link—including people in a chat history, browser logs, or third-party platforms that store URLs—could still view the excerpt.

According to the disclosure timeline, the report was marked as a duplicate of a submission filed six days earlier on August 28. Although an initial remediation attempt appeared to replace the specific test asset with a generic placeholder, a second test conducted by the researcher on September 30 revealed that the underlying issue was not fully resolved, as a new deleted conversation's preview image persisted for 26 hours. The report was subsequently reopened on October 4 and marked as resolved on October 6.

What it means for developers

For software engineers and system architects, this vulnerability serves as a vital lesson in managing the lifecycle of derived assets. When a user requests the deletion of a primary data object, that action must trigger a cascading "fan-out" deletion process that purges all associated thumbnails, previews, and metadata.

Developers should implement several defensive strategies to prevent similar leaks:

• Purge by key, not URL: Tag cached objects with the primary resource ID so that a single purge command invalidates all variants and query-string permutations.
• Active validation on cache misses: Ensure that the image generation endpoint actively checks if the parent resource or share link still exists before serving an asset.
• Keep TTLs short: Avoid excessively long cache lifetimes for assets derived from highly dynamic or deletable user content.
• Do not fail open: Avoid configuring CDN or cache layers to serve stale content when the origin server returns an error, as this can inadvertently keep deleted data online.

As teams build and deploy applications utilizing large language models, managing data privacy and API overhead is increasingly critical. For developers looking to experiment with these technologies, services like Apixo (https://apixoai.online) offer cheap, pay-per-token access to top AI models like Claude, GPT, Gemini, and Grok through a single API key, making it easier to prototype and test robust deletion lifecycles.

Ultimately, verifying database deletions is only the first step. Developers must conduct comprehensive lifecycle testing, fetching every derived URL—including Open Graph images and sitemaps—before and after deletion to ensure no cached remnants remain.

Source: Delete Is a Promise: A Security Researcher’s Look at AI Conversation Privacy — Towards AI. Written by the Apixo team from that report.