Part-DB EUVD-2026-108580

Requires an authenticated Part-DB account holding the '@parts.import' permission; the attacker imports a CSV where user-controlled part fields (e.g. the comment field) begin with a spreadsheet formula character (=, +, -, or @), which Part-DB stores without neutralisation. Exploitation only completes when a SECOND user with read access to those parts exports them as XLSX/XLS (via /parts/export) and opens the resulting file in spreadsheet software that evaluates formulas. Limiting factors that reduce realistic risk: the import permission is required, the payload does not execute in Part-DB itself (CWE-1236, no server-side code execution), success is contingent on a separate victim's export-and-open action (UI:R), and modern spreadsheet clients warn on or disable formula evaluation and external references by default. The flaw is most relevant in multi-user deployments where semi-trusted users can seed part data later exported by others.

This is a medium-severity, low-urgency issue rather than a top priority. The vendor CVSS of 4.6 (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) already reflects limited impact, and the decision signal is 'this_month' - not act_now or emergency. There is no CISA KEV listing and no EPSS score supplied in the input, so no evidence of active exploitation or mass-scanning pressure. The GHSA advisory includes a step-by-step proof of concept, but it uses a benign '=1+1' payload to demonstrate the flaw; a public PoC reference exists, but it is not verified as working weaponized exploit code. Signals are internally consistent: this is a stored spreadsheet (formula/CSV) injection, CWE-1236, that depends on a second user exporting and opening a crafted spreadsheet, which explains the scope change (S:C) and the mandatory user interaction (UI:R). I assess the attack vector as network (the attacker injects via the Part-DB web import feature) rather than the vendor's AV:L; the vendor's AV:L likely reflects that the formula only executes on the victim's local machine - this difference is worth noting but does not change the overall low-to-medium priority. Real-world impact is gated by the victim's spreadsheet client, which in modern Excel/LibreOffice warns on or disables formulas and external references by default.

In a multi-user Part-DB deployment, a lower-privileged user with import permission uploads a CSV whose part fields (e.g. the comment field) begin with a formula character such as '=', '+', '-' or '@'. The value is stored verbatim, and when an administrator or another user later exports those parts to XLSX and opens the file, their spreadsheet software may evaluate the injected formula - potentially triggering external URL requests or data exfiltration via formula-based references. A detailed public PoC reference exists in the GHSA advisory demonstrating the '=1+1' case; it is not verified as working weaponized exploit code, and exploitation requires AC:L but mandatory victim interaction (UI:R).