EXIF Metadata Leakage

Some web applications accept image uploads and later serve those images to other users or publicly via a CDN without stripping the embedded EXIF (Exchangeable Image File Format) metadata. Digital cameras and smartphones automatically embed metadata into photos at capture time, including GPS coordinates, timestamps, device make and model, lens information, and free-text fields such as artist name and comments.

When this metadata is not sanitized before storage or serving, the application unintentionally discloses private information about the original photographer. An attacker can download the served image and extract precise geolocation, capture time, and device fingerprints using readily available tools.

Bright uploads canary images containing unique, traceable EXIF markers to file upload endpoints and then searches the application for served copies of those images (in upload responses, redirects, API responses, rendered HTML, and linked image URLs). If any of the controlled fields are found intact in a served copy, an issue is reported.

This vulnerability allows an attacker to:

• Track user locations via GPS coordinates embedded in photos
• Fingerprint devices using camera make, model, lens, and serial number fields
• Establish timelines from original capture timestamps
• Harvest personal information from free-text fields (Artist, ImageDescription, UserComment)

Scenario: Profile photo leaks home address

1. A user uploads a photo taken at home as their profile picture on a web application.
2. The application stores and serves the original file without processing.
3. An attacker downloads the profile image and extracts the EXIF GPS coordinates using a tool like ExifTool:

   exiftool profile-photo.jpg

4. The output reveals:

   GPS Latitude  : 40.7128 N
   GPS Longitude : 74.0060 W
   Date/Time Original : 2025:12:15 08:32:17
   Camera Model  : iPhone 15 Pro

5. The attacker now knows the user's home location, the date the photo was taken, and the device used.

Scenario: Leaked metadata in API response

1. A mobile application uploads an image via a multipart POST to /api/v1/uploads.
2. The API responds with a JSON body containing a url field pointing to the stored image.
3. A GET request to that URL returns the original bytes, including all EXIF/XMP/IPTC metadata from the user's device.

• The issue can be found in image upload endpoints on the server side.
• The issue can be found in served image files accessible via direct URLs, CDN paths, API responses, or rendered HTML pages.

• Re-encode images server-side. Decode the uploaded image into a raw bitmap and write a new file rather than serving the original upload. This naturally discards all metadata.
• Strip all metadata before storage. Use a library or tool (e.g., ExifTool, libvips, Pillow, Sharp) to remove EXIF, XMP, and IPTC metadata from uploaded images before persisting them.
• Apply data minimization. Do not retain metadata that is not required for the application's business purpose, especially GPS coordinates and timestamps.
• Serve processed copies, not originals. Even if originals are stored for backup, ensure that the publicly accessible version is a sanitized copy.
• Add regression tests that verify downloaded images do not contain GPS, timestamp, or device identifier EXIF fields.
• For images that must retain metadata (e.g., professional photography platforms), serve them with Content-Disposition: attachment so browsers do not render them inline, reducing casual exposure.

• CWE-1230
• CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

• CWE-1230: Exposure of Sensitive Information Through Metadata
• OWASP Application Security Verification Standard 5.0 — Control 14.2.8
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations
• CIPA DC-008-2012: Exchangeable image file format for digital still cameras (Exif 2.3)