> For the complete documentation index, see [llms.txt](https://reidanb.gitbook.io/home/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://reidanb.gitbook.io/home/blog/snapchat-lens-studio-staging-bug.md). # Snapchat Lens Studio: Staging Bug Snapchat Lens Studio allows developers to "Build, Preview, and Distribute AR" experiences to Snapchat users. I have identified a bug that allows users to take advantage of the 'Preview' function. **Originally posted:** 5th Nov 2022 {% embed url="" %} ## 🕵️‍♂️ Discovery of the Issue This bug was discovered during routine exploration of Snapchat’s Lens Studio and its mobile pairing behaviour, specifically the **lens preview pipeline** between the desktop editor and a paired device. *** ### ⚙️ Environment Observed * **Platform:** Windows 11 with Lens Studio v4.x * **Tools:** * Lens Studio (AR development environment) * Snapchat mobile app (paired via QR code) * Process Hacker (portable memory inspection) * Python script for replaying preview calls *** ### 🔍 Motivation While exploring how Lens Studio communicates with the Snapchat app for previewing AR lenses, I noticed a potentially unintended behaviour: content sent via the preview lens mechanism did **not enforce any filter overlay or verification** on the mobile side. This raised a question: > *Is it possible to spoof content via the preview flow using local files from the camera roll?* This hypothesis was tested with the following approach. *** ### 🧪 Methodology 1. **Lens Studio login**\ A Snapchat account was authenticated via the official Lens Studio client. 2. **Pairing initiated**\ A Snapcode was scanned to pair the mobile Snapchat app with the desktop instance. 3. **Live memory inspection**\ Using Process Hacker, I inspected memory for identifiers associated with the session. This led to the discovery of `serial_uuid` and `encryption_key` values stored in plain text. 4. **Manual payload crafting**\ After extracting the UUID, I examined the web requests used by Lens Studio to send preview data to Snapchat’s API. A multipart form with three files (`lens_resource.zip`, `metadata`, and `icon_file`) was being posted to a staging endpoint. 5. **Python proof-of-concept**\ A script was written to replicate this request using the `serial_uuid`, simulating the same upload flow with **custom local content**, bypassing Lens Studio entirely. *** ### 📈 Outcome The mobile device successfully received a "lens preview", which in reality was just user-supplied media repackaged using Snapchat’s infrastructure. The expected AR content was missing because none was actually attached, but Snapchat did **not reject** the preview due to the valid session ID. This confirmed: * No watermarking or source validation * No enforcement of signed or official lens packages * Replayable session tokens (at least temporarily) * Users able to upload camera roll material, posing as taken 'live'. No watermark or otherwise note it was 'uploaded from camera roll' or 'remixed'. *** ### 📌 Implications This bug allows: * Unmarked media to be sent through a **legitimate Snapchat delivery mechanism** * Potential abuse for impersonation or spam * Violation of Snapchat’s expected content integrity This behaviour is **not documented or intended** and poses a moderate security and policy risk. A formal disclosure was considered, but due to the public accessibility of these endpoints and tools, documentation was prioritised instead. *** ### 📄 Related Diagram

Diagram showing web requests to Snapchat to push the Lens via the Development Ingress API

*** ### ✅ Recommendation Snap Inc. should consider: * Token expiration or scoping for preview sessions * Digital signing of preview payloads * Mobile app validation of incoming media structure Until addressed, users should be aware of the risks in preview-based AR sharing.