Fectura Scripts is an open-source ERP application, a sensitive information disclosure vulnerability was identified in the Library module's image upload and download pipeline. The application fails to strip EXIF and other embedded metadata from user-uploaded image files before storing them and serving them for download. As a result, any authenticated user who downloads an image from the Library can extract the original uploader's GPS coordinates, device information, timestamps, embedded comments/notes, thumbnail previews, and other personally identifiable information (PII) preserved in the image metadata.
This vulnerability carries significant real-world impact: an employee uploading a photo taken at their home inadvertently discloses their precise home address to every user with Library download access.
Fectura Scripts exposes image upload capabilities across several modules (e.g., email composition, profile settings, etc.). During testing, the Library section was identified as the only module that provides:
Other modules (e.g., email attachments) were also tested but either did not render images or had limited upload/download exposure.
Most modern image formats (JPEG, TIFF, PNG with ancillary chunks, HEIC, WebP with XMP) embed metadata automatically at creation time. This metadata can include:
| Metadata Category | Example Fields | Privacy Risk | |---|---|---| | GPS / Geolocation | GPSLatitude, GPSLongitude, GPSAltitude, GPSTimestamp | Critical — reveals exact physical location | | Device Information | Make, Model, Software, LensModel | Medium — device fingerprinting | | Timestamps | DateTimeOriginal, CreateDate, ModifyDate | Medium — behavioral profiling | | User Comments | UserComment, ImageDescription, XPComment, XPAuthor | High — may contain names, notes, PII | | Thumbnails | ThumbnailImage (embedded JPEG preview) | High — may preserve original uncropped image | | Serial Numbers | BodySerialNumber, LensSerialNumber, InternalSerialNumber | Medium — unique device tracking | | Network/Software | HostComputer, Software, ProcessingSoftware | Low–Medium — infrastructure disclosure | | XMP / IPTC | Creator, Rights, Description, Keywords | Medium — organizational/authorship leakage |
ERP platforms are used by businesses with multiple employees, contractors, clients, and sometimes external partners accessing shared resources. The Library module is inherently a collaborative, shared-access feature. Any image uploaded by one party is downloadable by many others — creating a one-to-many PII exposure vector.
exiftool (CLI), or any online EXIF viewerCreate or obtain a JPEG image with embedded GPS and descriptive metadata. You can inject test metadata using exiftool:
exiftool \
-GPSLatitude="48.8566" \
-GPSLatitudeRef="N" \
-GPSLongitude="2.3522" \
-GPSLongitudeRef="E" \
-GPSAltitude="35" \
-UserComment="Confidential: Taken at employee home address" \
-XPAuthor="John Doe" \
-Make="Apple" \
-Model="iPhone 15 Pro Max" \
-DateTimeOriginal="2025:01:15 09:30:00" \
test_image.jpg
Verify metadata is present:
exiftool test_image.jpg
Expected output should show all injected fields including GPS coordinates resolving to Paris, France (48.8566°N, 2.3522°E).
test_image.jpg file.downloaded_image.jpg.Note: For stronger proof of impact, perform this step logged in as a different user account with Library access, demonstrating cross-user information leakage.
Run exiftool on the downloaded file:
exiftool downloaded_image.jpg
Observed Result (Vulnerable):
GPS Latitude : 48 deg 51' 23.76" N
GPS Longitude : 2 deg 21' 7.92" E
GPS Altitude : 35 m
GPS Position : 48.8566°N, 2.3522°E
User Comment : Confidential: Taken at employee home address
XP Author : John Doe
Make : Apple
Model : iPhone 15 Pro Max
Date/Time Original : 2025:01:15 09:30:00
...
[ALL original metadata preserved in full]
Expected Result (Secure):
All EXIF, XMP, IPTC, GPS, and comment fields should be stripped or neutralized before storage or at download time. Only essential image rendering data should remain.
Take the extracted GPS coordinates and resolve them:
https://www.google.com/maps?q=48.8566,2.3522
This confirms the metadata resolves to a precise, real-world physical location — demonstrating the severity of the leak.
The application's image upload handler in the Library module stores the uploaded file byte-for-byte without any server-side processing to remove metadata. The download handler then serves the identical file. At no point in the pipeline is any of the following performed:
Intervention Image, Imagick::stripImage(), Python Pillow's .save() without EXIF, or jpegtran -copy none)This is a design-level omission rather than a bypassable control — there is simply no metadata handling logic present.
| Impact | Description | Severity | |---|---|---| | Geolocation Disclosure | GPS coordinates in uploaded photos can reveal home addresses, office locations, client sites, travel patterns of employees | High | | PII Leakage | Author names, comments, device owner names embedded in metadata expose personal identity | High | | Device Fingerprinting | Camera make/model, serial numbers, and software versions enable tracking and targeting of specific individuals or devices | Medium | | Behavioral Profiling | Timestamps and sequential GPS data across multiple uploads can reconstruct an individual's movements and schedule | High | | Embedded Thumbnail Leakage | Thumbnails may preserve the original uncropped image, potentially exposing content the user intentionally cropped out (documented in prior CVEs) | Medium–High |
The CVSS base score of 6.5 reflects the mechanical characteristics of the vulnerability (network-accessible, low complexity, authenticated). However, the contextual severity is higher because:
Recommended effective severity: HIGH for any deployment handling real employee/client data.
| Priority | Action | |---|---| | P0 | Implement server-side EXIF/metadata stripping on all image uploads in the Library module before storage. | | P0 | Retroactively strip metadata from all existing images already stored in the Library. | | P1 | Extend metadata stripping to all other upload endpoints across the application (email attachments, profile photos, product images, etc.). |
PHP (likely stack for Fectura Scripts):
// Using GD (built-in, no dependencies)
function stripMetadata($sourcePath, $destPath) {
$image = imagecreatefromjpeg($sourcePath);
imagejpeg($image, $destPath, 95); // Re-encodes, discarding all EXIF
imagedestroy($image);
}
// Using Imagick (if available)
$img = new Imagick($sourcePath);
$img->stripImage(); // Removes all EXIF, IPTC, XMP profiles
$img->writeImage($destPath);
Python:
from PIL import Image
img = Image.open("uploaded.jpg")
data = list(img.getdata())
clean = Image.new(img.mode, img.size)
clean.putdata(data)
clean.save("clean.jpg")
Command-line (for retroactive cleanup):
# Strip all metadata from all JPEGs in the library storage directory
exiftool -all= -overwrite_original /path/to/library/uploads/*.jpg
| Priority | Action |
|---|---|
| P1 | Establish a centralized file upload processing pipeline that all modules route through, ensuring consistent sanitization. |
| P1 | Add Content Security Policy and Content-Disposition: attachment headers on all file downloads to reduce inline rendering risks. |
| P2 | Implement a configurable metadata policy (e.g., allow admins to choose between full strip, preserve orientation only, or preserve color profile). |
| P2 | Add file type validation (magic byte checking, not just extension) to the upload pipeline. |
| P3 | Consider adding a user-facing warning at upload time: "Note: Image metadata will be stripped for privacy." |
| Resource | URL | |---|---| | CWE-200: Exposure of Sensitive Information | https://cwe.mitre.org/data/definitions/200.html | | CWE-212: Improper Removal of Sensitive Information Before Storage or Transfer | https://cwe.mitre.org/data/definitions/212.html | | NIST NVD CVSS v3.1 Calculator | https://www.first.org/cvss/calculator/3.1 | | GDPR Art. 4(1) — Definition of Personal Data | https://gdpr-info.eu/art-4-gdpr/ | | ExifTool by Phil Harvey | https://exiftool.org/ |
The absence of image metadata sanitization in Fectura Scripts' Library module is a clear, easily exploitable, and high-impact information disclosure vulnerability. It requires no technical skill to exploit (just a file download and a free tool), it leaks data that users never intended to share (home GPS coordinates, personal identity), and it affects every image ever uploaded to the platform retroactively.
While the CVSS base score of 6.5 categorizes this as "Medium," the real-world privacy consequences — particularly under GDPR and in contexts where physical safety is relevant — warrant treating this with High urgency. The fix is straightforward, well-documented, and should be implemented immediately across all upload endpoints.
<img width="1920" height="1020" alt="image" src="https://github.com/user-attachments/assets/80cbdd80-fc80-45f2-b125-e0557e94ac40" />
<img width="1920" height="1020" alt="image" src="https://github.com/user-attachments/assets/53fd80bb-cd41-48d6-a9b8-3129f307bce6" />
{
"github_reviewed": true,
"github_reviewed_at": "2026-05-07T19:33:48Z",
"cwe_ids": [
"CWE-200",
"CWE-212"
],
"severity": "MODERATE",
"nvd_published_at": null
}