Common Weakness Enumeration

CWE-212

Allowed

Improper Removal of Sensitive Information Before Storage or Transfer

Abstraction: Base · Status: Incomplete

The product stores, transfers, or shares a resource that contains sensitive information, but it does not properly remove that information before the product makes the resource available to unauthorized actors.

156 vulnerabilities reference this CWE, most recent first.

GHSA-JJ45-JP8R-QCJX

Vulnerability from github – Published: 2022-04-30 18:19 – Updated: 2024-02-03 03:30
VLAI
Details

The Network Address Translation (NAT) capability for Netfilter ("iptables") 1.2.6a and earlier leaks translated IP addresses in ICMP error messages.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2002-0704"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-212"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2002-07-26T04:00:00Z",
    "severity": "MODERATE"
  },
  "details": "The Network Address Translation (NAT) capability for Netfilter (\"iptables\") 1.2.6a and earlier leaks translated IP addresses in ICMP error messages.",
  "id": "GHSA-jj45-jp8r-qcjx",
  "modified": "2024-02-03T03:30:26Z",
  "published": "2022-04-30T18:19:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2002-0704"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=102088521517722\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://online.securityfocus.com/advisories/4116"
    },
    {
      "type": "WEB",
      "url": "http://www.iss.net/security_center/static/9043.php"
    },
    {
      "type": "WEB",
      "url": "http://www.linux-mandrake.com/en/security/2002/MDKSA-2002-030.php"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2002-086.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/4699"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JMHJ-34RW-524W

Vulnerability from github – Published: 2022-05-24 17:35 – Updated: 2022-05-24 17:35
VLAI
Details

Some websites have a feature "Show Password" where clicking a button will change a password field into a textbook field, revealing the typed password. If, when using a software keyboard that remembers user input, a user typed their password and used that feature, the type of the password field was changed, resulting in a keyboard layout change and the possibility for the software keyboard to remember the typed password. This vulnerability affects Firefox < 83, Firefox ESR < 78.5, and Thunderbird < 78.5.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-26965"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-212"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-09T01:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Some websites have a feature \"Show Password\" where clicking a button will change a password field into a textbook field, revealing the typed password. If, when using a software keyboard that remembers user input, a user typed their password and used that feature, the type of the password field was changed, resulting in a keyboard layout change and the possibility for the software keyboard to remember the typed password. This vulnerability affects Firefox \u003c 83, Firefox ESR \u003c 78.5, and Thunderbird \u003c 78.5.",
  "id": "GHSA-jmhj-34rw-524w",
  "modified": "2022-05-24T17:35:38Z",
  "published": "2022-05-24T17:35:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26965"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1661617"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2020-50"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2020-51"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2020-52"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-M7MQ-37P8-WHP7

Vulnerability from github – Published: 2025-09-06 21:30 – Updated: 2025-09-06 21:30
VLAI
Details

Improper removal of sensitive information before storage or transfer in AMD Crash Defender could allow an attacker to obtain kernel address information potentially resulting in loss of confidentiality.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-0011"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-212"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-06T19:15:38Z",
    "severity": "LOW"
  },
  "details": "Improper removal of sensitive information before storage or transfer in AMD Crash Defender could allow an attacker to obtain kernel address information potentially resulting in loss of confidentiality.",
  "id": "GHSA-m7mq-37p8-whp7",
  "modified": "2025-09-06T21:30:19Z",
  "published": "2025-09-06T21:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0011"
    },
    {
      "type": "WEB",
      "url": "https://www.amd.com/en/resources/product-security/bulletin/AMD-SB-6018.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P3CX-FRRM-35M8

Vulnerability from github – Published: 2026-03-12 03:31 – Updated: 2026-03-12 03:31
VLAI
Details

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 8.14 before 18.7.6, 18.8 before 18.8.6, and 18.9 before 18.9.2 that could have allowed an authenticated user to gain unauthorized access to confidential issue title created in public projects under certain circumstances.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-1182"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-212"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-12T02:15:58Z",
    "severity": "MODERATE"
  },
  "details": "GitLab has remediated an issue in GitLab CE/EE affecting all versions from 8.14 before 18.7.6, 18.8 before 18.8.6, and 18.9 before 18.9.2 that could have allowed an authenticated user to gain unauthorized access to confidential issue title created in public projects under certain circumstances.",
  "id": "GHSA-p3cx-frrm-35m8",
  "modified": "2026-03-12T03:31:06Z",
  "published": "2026-03-12T03:31:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1182"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/3515716"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/work_items/586613"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PPWQ-6V66-5M6J

Vulnerability from github – Published: 2026-03-26 21:15 – Updated: 2026-03-26 21:15
VLAI
Summary
OpenClaw Exposes Credentials Embedded in baseUrl Fields via config.get and channels.status
Details

Summary

Read-scoped gateway snapshots could expose credentials embedded in channel baseUrl and related endpoint fields.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected: < 2026.3.22
  • Fixed: >= 2026.3.22
  • Latest released tag checked: v2026.3.23-2 (630f1479c44f78484dfa21bb407cbe6f171dac87)
  • Latest published npm version checked: 2026.3.23-2

Fix Commit(s)

  • f0202264d0de7ad345382b9008c5963bcefb01b7

Release Status

The fix shipped in v2026.3.22 and remains present in v2026.3.23 and v2026.3.23-2.

Code-Level Confirmation

  • src/channels/account-snapshot-fields.ts now strips URL userinfo from channel status snapshot fields.
  • src/config/redact-snapshot.ts now redacts credential-bearing baseUrl and httpUrl fields while preserving safe context.

OpenClaw thanks @zpbrent for reporting.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-212",
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-26T21:15:59Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\nRead-scoped gateway snapshots could expose credentials embedded in channel baseUrl and related endpoint fields.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Affected: \u003c 2026.3.22\n- Fixed: \u003e= 2026.3.22\n- Latest released tag checked: `v2026.3.23-2` (`630f1479c44f78484dfa21bb407cbe6f171dac87`)\n- Latest published npm version checked: `2026.3.23-2`\n\n## Fix Commit(s)\n- `f0202264d0de7ad345382b9008c5963bcefb01b7`\n\n## Release Status\nThe fix shipped in `v2026.3.22` and remains present in `v2026.3.23` and `v2026.3.23-2`.\n\n## Code-Level Confirmation\n- src/channels/account-snapshot-fields.ts now strips URL userinfo from channel status snapshot fields.\n- src/config/redact-snapshot.ts now redacts credential-bearing baseUrl and httpUrl fields while preserving safe context.\n\nOpenClaw thanks @zpbrent for reporting.",
  "id": "GHSA-ppwq-6v66-5m6j",
  "modified": "2026-03-26T21:15:59Z",
  "published": "2026-03-26T21:15:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-ppwq-6v66-5m6j"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/f0202264d0de7ad345382b9008c5963bcefb01b7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw Exposes Credentials Embedded in baseUrl Fields via config.get and channels.status"
}

GHSA-PW2R-VQ6V-HR8C

Vulnerability from github – Published: 2022-02-10 00:00 – Updated: 2022-02-14 22:27
VLAI
Summary
Exposure of Sensitive Information to an Unauthorized Actor in follow-redirects
Details

Exposure of Sensitive Information to an Unauthorized Actor in NPM follow-redirects prior to 1.14.8.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "follow-redirects"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.14.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-0536"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-212"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-02-11T21:18:03Z",
    "nvd_published_at": "2022-02-09T11:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Exposure of Sensitive Information to an Unauthorized Actor in NPM follow-redirects prior to 1.14.8.",
  "id": "GHSA-pw2r-vq6v-hr8c",
  "modified": "2022-02-14T22:27:56Z",
  "published": "2022-02-10T00:00:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0536"
    },
    {
      "type": "WEB",
      "url": "https://github.com/follow-redirects/follow-redirects/commit/62e546a99c07c3ee5e4e0718c84a6ca127c5c445"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/follow-redirects/follow-redirects"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/7cf2bf90-52da-4d59-8028-a73b132de0db"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Exposure of Sensitive Information to an Unauthorized Actor in follow-redirects"
}

GHSA-PW42-76J9-FCP3

Vulnerability from github – Published: 2026-02-03 00:30 – Updated: 2026-03-25 15:31
VLAI
Details

Vulnerability in Wikimedia Foundation MediaWiki. This vulnerability is associated with program files includes/recentchanges/RecentChangeRCFeedNotifier.Php.

This issue affects MediaWiki: from * before 1.39.14, 1.43.4, 1.44.1.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-61643"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-212"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-03T00:16:10Z",
    "severity": "LOW"
  },
  "details": "Vulnerability in Wikimedia Foundation MediaWiki. This vulnerability is associated with program files includes/recentchanges/RecentChangeRCFeedNotifier.Php.\n\nThis issue affects MediaWiki: from * before 1.39.14, 1.43.4, 1.44.1.",
  "id": "GHSA-pw42-76j9-fcp3",
  "modified": "2026-03-25T15:31:24Z",
  "published": "2026-02-03T00:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61643"
    },
    {
      "type": "WEB",
      "url": "https://phabricator.wikimedia.org/T403757"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:M/U:Green",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-PX79-JX9M-M5H5

Vulnerability from github – Published: 2023-05-31 21:31 – Updated: 2024-04-04 04:26
VLAI
Details

A known cache speculation vulnerability, known as Branch History Injection (BHI) or Spectre-BHB, becomes actual again for the new hw AmpereOne. Spectre-BHB is similar to Spectre v2, except that malicious code uses the shared branch history (stored in the CPU Branch History Buffer, or BHB) to influence mispredicted branches within the victim's hardware context. Once that occurs, speculation caused by the mispredicted branches can cause cache allocation. This issue leads to obtaining information that should not be accessible.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-3006"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-212",
      "CWE-226"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-31T20:15:11Z",
    "severity": "MODERATE"
  },
  "details": "A known cache speculation vulnerability, known as Branch History Injection (BHI) or Spectre-BHB, becomes actual again for the new hw AmpereOne. Spectre-BHB is similar to Spectre v2, except that malicious code uses the shared branch history (stored in the CPU Branch History Buffer, or BHB) to influence mispredicted branches within the victim\u0027s hardware context. Once that occurs, speculation caused by the mispredicted branches can cause cache allocation. This issue leads to obtaining information that should not be accessible.",
  "id": "GHSA-px79-jx9m-m5h5",
  "modified": "2024-04-04T04:26:48Z",
  "published": "2023-05-31T21:31:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3006"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=0e5d5ae837c8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q34C-CRF5-4984

Vulnerability from github – Published: 2024-10-08 18:33 – Updated: 2024-10-08 18:33
VLAI
Details

Windows Kernel-Mode Driver Information Disclosure Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-43554"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-212"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-08T18:15:21Z",
    "severity": "MODERATE"
  },
  "details": "Windows Kernel-Mode Driver Information Disclosure Vulnerability",
  "id": "GHSA-q34c-crf5-4984",
  "modified": "2024-10-08T18:33:16Z",
  "published": "2024-10-08T18:33:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43554"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-43554"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q7F2-RV22-2XGR

Vulnerability from github – Published: 2026-05-07 19:33 – Updated: 2026-05-19 16:09
VLAI
Summary
FacturaScripts Vulnerable to Unstripped Image Metadata (EXIF) Leakage via Library Module File Upload/Download
Details

Summary

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.


Affected Functionality Overview

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:

  • Full image upload (unrestricted image types observed)
  • Persistent storage of uploaded files
  • Direct download capability for any authenticated user with access
  • No server-side metadata sanitization at any point in the pipeline (upload, storage, or delivery)

Other modules (e.g., email attachments) were also tested but either did not render images or had limited upload/download exposure.


Technical Background

What Is EXIF/Image Metadata?

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

Why This Matters in an ERP Context

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.


Step-by-Step Reproduction

Prerequisites

  • A valid user account with access to the Library module (tested with Admin role; lower-privilege roles should also be tested)
  • A test image file containing rich EXIF/metadata (see Step 1)
  • An EXIF analysis tool: exiftool (CLI), or any online EXIF viewer

Step 1: Prepare a Metadata-Rich Test Image

Create 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).


Step 2: Log in to Fectura Scripts

  1. Navigate to the Fectura Scripts login page.
  2. Authenticate with valid credentials.
  3. Confirm access to the application dashboard.

Step 3: Navigate to the Library Section

  1. From the main navigation/sidebar, click on "Library" (or equivalent menu entry).
  2. Confirm the Library module loads and displays existing files/images (if any).

Step 4: Upload the Test Image

  1. Click the "Upload" button/action within the Library interface.
  2. Select the prepared test_image.jpg file.
  3. Complete the upload process (fill any required fields such as title/description if prompted).
  4. Confirm the image appears in the Library listing.

Step 5: Download the Image (as the Same or Different User)

  1. Locate the uploaded image in the Library.
  2. Click the "Download" button/link (or right-click → Save As on the rendered image, depending on UI).
  3. Save the file locally as 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.


Step 6: Extract and Analyze Metadata from the Downloaded File

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.


Step 7: Confirm GPS Resolution to Physical Location

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.


Root Cause Analysis

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:

  1. EXIF stripping (e.g., via libraries like Intervention Image, Imagick::stripImage(), Python Pillow's .save() without EXIF, or jpegtran -copy none)
  2. Re-encoding / reprocessing of the image (which would naturally discard non-image data)
  3. Selective metadata whitelisting (preserving only color profile / orientation data)
  4. Content-Disposition header enforcement to prevent inline rendering with metadata intact

This is a design-level omission rather than a bypassable control — there is simply no metadata handling logic present.


Impact Assessment

Direct Impacts

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

Contextual / Escalated Impacts

  • Regulatory Exposure: GPS coordinates and author names constitute personal data under GDPR (Art. 4(1)), CCPA, and similar frameworks. Failure to strip this data from shared/downloadable resources may constitute a data protection violation for organizations using Fectura Scripts.
  • Insider Threat Amplification: A malicious insider (employee, contractor) with Library download access can silently harvest geolocation and identity data of colleagues without any logging or indication to the victim.
  • Physical Security Risk: In sectors where employee physical safety is paramount (e.g., legal, law enforcement, journalism, NGOs, domestic violence support), leaking home GPS coordinates through an ERP system represents a direct physical safety threat.
  • Supply Chain Risk: If the Library is shared with external partners/vendors, the exposure surface extends beyond the organization.

Why CVSS 6.5 Understates the Risk

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:

  1. Users have no expectation that uploading an image to an ERP system will broadcast their home coordinates.
  2. The attack is completely passive — the attacker simply downloads a file; no exploitation toolkit or special skills are required.
  3. The leaked data (GPS, PII) is irrevocable — once downloaded, the victim cannot "un-leak" their location.
  4. The vulnerability affects every image ever uploaded to the Library, creating a retroactive exposure of historical data.

Recommended effective severity: HIGH for any deployment handling real employee/client data.


Recommended Remediation

Immediate (Short-Term)

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.).

Implementation Guidance (by Language/Stack)

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

Long-Term (Architectural)

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."

9. References

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/
Related CVE https://nvd.nist.gov/vuln/detail/CVE-2023-29850
---

11. Conclusion

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.

image

image

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "facturascripts/facturascripts"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2025.81"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27892"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-212"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T19:33:48Z",
    "nvd_published_at": "2026-05-18T22:16:38Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n**Fectura Scripts** is an open-source ERP application, a **sensitive information disclosure vulnerability** was identified in the **Library** module\u0027s 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\u0027s **GPS coordinates, device information, timestamps, embedded comments/notes, thumbnail previews, and other personally identifiable information (PII)** preserved in the image metadata.\n\nThis 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.**\n\n---\n\n## Affected Functionality Overview\n\nFectura 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:\n\n- **Full image upload** (unrestricted image types observed)\n- **Persistent storage** of uploaded files\n- **Direct download** capability for any authenticated user with access\n- **No server-side metadata sanitization** at any point in the pipeline (upload, storage, or delivery)\n\nOther modules (e.g., email attachments) were also tested but either did not render images or had limited upload/download exposure.\n\n---\n\n## Technical Background\n\n### What Is EXIF/Image Metadata?\n\nMost modern image formats (JPEG, TIFF, PNG with ancillary chunks, HEIC, WebP with XMP) embed metadata automatically at creation time. This metadata can include:\n\n| Metadata Category | Example Fields | Privacy Risk |\n|---|---|---|\n| **GPS / Geolocation** | GPSLatitude, GPSLongitude, GPSAltitude, GPSTimestamp | **Critical** \u2014 reveals exact physical location |\n| **Device Information** | Make, Model, Software, LensModel | Medium \u2014 device fingerprinting |\n| **Timestamps** | DateTimeOriginal, CreateDate, ModifyDate | Medium \u2014 behavioral profiling |\n| **User Comments** | UserComment, ImageDescription, XPComment, XPAuthor | **High** \u2014 may contain names, notes, PII |\n| **Thumbnails** | ThumbnailImage (embedded JPEG preview) | **High** \u2014 may preserve original uncropped image |\n| **Serial Numbers** | BodySerialNumber, LensSerialNumber, InternalSerialNumber | Medium \u2014 unique device tracking |\n| **Network/Software** | HostComputer, Software, ProcessingSoftware | Low\u2013Medium \u2014 infrastructure disclosure |\n| **XMP / IPTC** | Creator, Rights, Description, Keywords | Medium \u2014 organizational/authorship leakage |\n\n### Why This Matters in an ERP Context\n\nERP 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 \u2014 creating a **one-to-many PII exposure vector**.\n\n---\n\n## Step-by-Step Reproduction\n\n### Prerequisites\n\n- A valid user account with access to the **Library** module (tested with Admin role; lower-privilege roles should also be tested)\n- A test image file containing rich EXIF/metadata (see Step 1)\n- An EXIF analysis tool: `exiftool` (CLI), or any online EXIF viewer\n\n---\n\n### Step 1: Prepare a Metadata-Rich Test Image\n\nCreate or obtain a JPEG image with embedded GPS and descriptive metadata. You can inject test metadata using `exiftool`:\n\n```bash\nexiftool \\\n  -GPSLatitude=\"48.8566\" \\\n  -GPSLatitudeRef=\"N\" \\\n  -GPSLongitude=\"2.3522\" \\\n  -GPSLongitudeRef=\"E\" \\\n  -GPSAltitude=\"35\" \\\n  -UserComment=\"Confidential: Taken at employee home address\" \\\n  -XPAuthor=\"John Doe\" \\\n  -Make=\"Apple\" \\\n  -Model=\"iPhone 15 Pro Max\" \\\n  -DateTimeOriginal=\"2025:01:15 09:30:00\" \\\n  test_image.jpg\n```\n\nVerify metadata is present:\n\n```bash\nexiftool test_image.jpg\n```\n\nExpected output should show all injected fields including GPS coordinates resolving to **Paris, France (48.8566\u00b0N, 2.3522\u00b0E)**.\n\n---\n\n### Step 2: Log in to Fectura Scripts\n\n1. Navigate to the Fectura Scripts login page.\n2. Authenticate with valid credentials.\n3. Confirm access to the application dashboard.\n\n---\n\n### Step 3: Navigate to the Library Section\n\n1. From the main navigation/sidebar, click on **\"Library\"** (or equivalent menu entry).\n2. Confirm the Library module loads and displays existing files/images (if any).\n\n---\n\n### Step 4: Upload the Test Image\n\n1. Click the **\"Upload\"** button/action within the Library interface.\n2. Select the prepared `test_image.jpg` file.\n3. Complete the upload process (fill any required fields such as title/description if prompted).\n4. Confirm the image appears in the Library listing.\n\n---\n\n### Step 5: Download the Image (as the Same or Different User)\n\n1. Locate the uploaded image in the Library.\n2. Click the **\"Download\"** button/link (or right-click \u2192 Save As on the rendered image, depending on UI).\n3. Save the file locally as `downloaded_image.jpg`.\n\n\u003e **Note:** For stronger proof of impact, perform this step logged in as a **different user account** with Library access, demonstrating cross-user information leakage.\n\n---\n\n### Step 6: Extract and Analyze Metadata from the Downloaded File\n\nRun `exiftool` on the downloaded file:\n\n```bash\nexiftool downloaded_image.jpg\n```\n\n**Observed Result (Vulnerable):**\n\n```\nGPS Latitude                    : 48 deg 51\u0027 23.76\" N\nGPS Longitude                   : 2 deg 21\u0027 7.92\" E\nGPS Altitude                    : 35 m\nGPS Position                    : 48.8566\u00b0N, 2.3522\u00b0E\nUser Comment                    : Confidential: Taken at employee home address\nXP Author                       : John Doe\nMake                            : Apple\nModel                           : iPhone 15 Pro Max\nDate/Time Original              : 2025:01:15 09:30:00\n...\n[ALL original metadata preserved in full]\n```\n\n**Expected Result (Secure):**\n\nAll 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.\n\n---\n\n### Step 7: Confirm GPS Resolution to Physical Location\n\nTake the extracted GPS coordinates and resolve them:\n\n```\nhttps://www.google.com/maps?q=48.8566,2.3522\n```\n\nThis confirms the metadata resolves to a **precise, real-world physical location** \u2014 demonstrating the severity of the leak.\n\n---\n\n## Root Cause Analysis\n\nThe application\u0027s 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:\n\n1. **EXIF stripping** (e.g., via libraries like `Intervention Image`, `Imagick::stripImage()`, Python Pillow\u0027s `.save()` without EXIF, or `jpegtran -copy none`)\n2. **Re-encoding / reprocessing** of the image (which would naturally discard non-image data)\n3. **Selective metadata whitelisting** (preserving only color profile / orientation data)\n4. **Content-Disposition header enforcement** to prevent inline rendering with metadata intact\n\nThis is a **design-level omission** rather than a bypassable control \u2014 there is simply no metadata handling logic present.\n\n---\n\n## Impact Assessment\n\n### Direct Impacts\n\n| Impact | Description | Severity |\n|---|---|---|\n| **Geolocation Disclosure** | GPS coordinates in uploaded photos can reveal home addresses, office locations, client sites, travel patterns of employees | **High** |\n| **PII Leakage** | Author names, comments, device owner names embedded in metadata expose personal identity | **High** |\n| **Device Fingerprinting** | Camera make/model, serial numbers, and software versions enable tracking and targeting of specific individuals or devices | **Medium** |\n| **Behavioral Profiling** | Timestamps and sequential GPS data across multiple uploads can reconstruct an individual\u0027s movements and schedule | **High** |\n| **Embedded Thumbnail Leakage** | Thumbnails may preserve the original uncropped image, potentially exposing content the user intentionally cropped out (documented in prior CVEs) | **Medium\u2013High** |\n\n### Contextual / Escalated Impacts\n\n- **Regulatory Exposure:** GPS coordinates and author names constitute **personal data** under GDPR (Art. 4(1)), CCPA, and similar frameworks. Failure to strip this data from shared/downloadable resources may constitute a **data protection violation** for organizations using Fectura Scripts.\n- **Insider Threat Amplification:** A malicious insider (employee, contractor) with Library download access can silently harvest geolocation and identity data of colleagues without any logging or indication to the victim.\n- **Physical Security Risk:** In sectors where employee physical safety is paramount (e.g., legal, law enforcement, journalism, NGOs, domestic violence support), leaking home GPS coordinates through an ERP system represents a **direct physical safety threat**.\n- **Supply Chain Risk:** If the Library is shared with external partners/vendors, the exposure surface extends beyond the organization.\n\n### Why CVSS 6.5 Understates the Risk\n\nThe 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:\n\n1. Users have **no expectation** that uploading an image to an ERP system will broadcast their home coordinates.\n2. The attack is **completely passive** \u2014 the attacker simply downloads a file; no exploitation toolkit or special skills are required.\n3. The leaked data (GPS, PII) is **irrevocable** \u2014 once downloaded, the victim cannot \"un-leak\" their location.\n4. The vulnerability affects **every image ever uploaded** to the Library, creating a retroactive exposure of historical data.\n\n**Recommended effective severity: HIGH for any deployment handling real employee/client data.**\n\n---\n\n## Recommended Remediation\n\n### Immediate (Short-Term)\n\n| Priority | Action |\n|---|---|\n| **P0** | Implement **server-side EXIF/metadata stripping** on all image uploads in the Library module **before storage**. |\n| **P0** | **Retroactively strip metadata** from all existing images already stored in the Library. |\n| **P1** | Extend metadata stripping to **all other upload endpoints** across the application (email attachments, profile photos, product images, etc.). |\n\n### Implementation Guidance (by Language/Stack)\n\n**PHP (likely stack for Fectura Scripts):**\n\n```php\n// Using GD (built-in, no dependencies)\nfunction stripMetadata($sourcePath, $destPath) {\n    $image = imagecreatefromjpeg($sourcePath);\n    imagejpeg($image, $destPath, 95); // Re-encodes, discarding all EXIF\n    imagedestroy($image);\n}\n\n// Using Imagick (if available)\n$img = new Imagick($sourcePath);\n$img-\u003estripImage(); // Removes all EXIF, IPTC, XMP profiles\n$img-\u003ewriteImage($destPath);\n```\n\n**Python:**\n\n```python\nfrom PIL import Image\nimg = Image.open(\"uploaded.jpg\")\ndata = list(img.getdata())\nclean = Image.new(img.mode, img.size)\nclean.putdata(data)\nclean.save(\"clean.jpg\")\n```\n\n**Command-line (for retroactive cleanup):**\n\n```bash\n# Strip all metadata from all JPEGs in the library storage directory\nexiftool -all= -overwrite_original /path/to/library/uploads/*.jpg\n```\n\n### Long-Term (Architectural)\n\n| Priority | Action |\n|---|---|\n| **P1** | Establish a **centralized file upload processing pipeline** that all modules route through, ensuring consistent sanitization. |\n| **P1** | Add **Content Security Policy** and `Content-Disposition: attachment` headers on all file downloads to reduce inline rendering risks. |\n| **P2** | Implement a configurable **metadata policy** (e.g., allow admins to choose between full strip, preserve orientation only, or preserve color profile). |\n| **P2** | Add **file type validation** (magic byte checking, not just extension) to the upload pipeline. |\n| **P3** | Consider adding a **user-facing warning** at upload time: \"Note: Image metadata will be stripped for privacy.\" |\n\n---\n\n## 9. References\n\n| Resource | URL |\n|---|---|\n| CWE-200: Exposure of Sensitive Information | https://cwe.mitre.org/data/definitions/200.html |\n| CWE-212: Improper Removal of Sensitive Information Before Storage or Transfer | https://cwe.mitre.org/data/definitions/212.html |\n| NIST NVD CVSS v3.1 Calculator | https://www.first.org/cvss/calculator/3.1 |\n| GDPR Art. 4(1) \u2014 Definition of Personal Data | https://gdpr-info.eu/art-4-gdpr/ |\n| ExifTool by Phil Harvey | https://exiftool.org/ |\n| Related CVE | https://nvd.nist.gov/vuln/detail/CVE-2023-29850 |\n---\n\n## 11. Conclusion\n\nThe absence of image metadata sanitization in Fectura Scripts\u0027 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.\n\nWhile the CVSS base score of **6.5** categorizes this as \"Medium,\" the real-world privacy consequences \u2014 particularly under GDPR and in contexts where physical safety is relevant \u2014 warrant treating this with **High urgency**. The fix is straightforward, well-documented, and should be implemented immediately across all upload endpoints.\n\n\n\u003cimg width=\"1920\" height=\"1020\" alt=\"image\" src=\"https://github.com/user-attachments/assets/80cbdd80-fc80-45f2-b125-e0557e94ac40\" /\u003e\n\n\u003cimg width=\"1920\" height=\"1020\" alt=\"image\" src=\"https://github.com/user-attachments/assets/53fd80bb-cd41-48d6-a9b8-3129f307bce6\" /\u003e",
  "id": "GHSA-q7f2-rv22-2xgr",
  "modified": "2026-05-19T16:09:35Z",
  "published": "2026-05-07T19:33:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/NeoRazorX/facturascripts/security/advisories/GHSA-q7f2-rv22-2xgr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27892"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NeoRazorX/facturascripts/commit/b0725147a61a9a377b7180589af33ff52b4751e2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/NeoRazorX/facturascripts"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "FacturaScripts Vulnerable to Unstripped Image Metadata (EXIF) Leakage via Library Module File Upload/Download"
}

Mitigation
Requirements

Clearly specify which information should be regarded as private or sensitive, and require that the product offers functionality that allows the user to cleanse the sensitive information from the resource before it is published or exported to other parties.

Mitigation MIT-46
Architecture and Design

Strategy: Separation of Privilege

  • Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
  • Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
Mitigation MIT-57
Implementation Operation

Strategy: Attack Surface Reduction

  • Some tools can automatically analyze documents to redact, strip, or "sanitize" private information, although some human review might be necessary. Tools may vary in terms of which document formats can be processed.
  • When calling an external program to automatically generate or convert documents, invoke the program with any available options that avoid generating sensitive metadata. Some formats have well-defined fields that could contain private data, such as Exchangeable image file format (Exif), which can contain potentially sensitive metadata such as geolocation, date, and time [REF-1515] [REF-1516].
Mitigation MIT-33
Implementation

Strategy: Attack Surface Reduction

Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible.

Mitigation
Implementation

Avoid errors related to improper resource shutdown or release (CWE-404), which may leave the sensitive data within the resource if it is in an incomplete state.

CAPEC-168: Windows ::DATA Alternate Data Stream

An attacker exploits the functionality of Microsoft NTFS Alternate Data Streams (ADS) to undermine system security. ADS allows multiple "files" to be stored in one directory entry referenced as filename:streamname. One or more alternate data streams may be stored in any file or directory. Normal Microsoft utilities do not show the presence of an ADS stream attached to a file. The additional space for the ADS is not recorded in the displayed file size. The additional space for ADS is accounted for in the used space on the volume. An ADS can be any type of file. ADS are copied by standard Microsoft utilities between NTFS volumes. ADS can be used by an attacker or intruder to hide tools, scripts, and data from detection by normal system utilities. Many anti-virus programs do not check for or scan ADS. Windows Vista does have a switch (-R) on the command line DIR command that will display alternate streams.