Part-DB CVE-2026-54615

Requires an authenticated account with edit rights on an entity that owns a named collection sub-element (Part Parameter, Attachment, PartLot, Orderdetail, etc.) so the attacker can store an arbitrary string as that sub-element's name and then delete it, which is what writes the CollectionElementDeleted log entry. Exploitation only yields impact when a higher-privileged victim subsequently views the data: a user with system.show_logs opening /log (typically an admin/auditor), or a user with show_history opening the affected element's history table. The key limiting factor is the application's default Content-Security-Policy (script-src 'self' 'wasm-unsafe-eval', no unsafe-inline, plus X-Content-Type-Options: nosniff), which prevents the injected inline <script>/onerror JavaScript from executing - so on a default deployment this is HTML/CSS injection (content spoofing, UI-redress, img-src beaconing) rather than JavaScript execution. Full script execution requires a relaxed/non-default CSP or a rendering context where the markup executes. Affected: Part-DB-server <= 2.12.0; fixed in 2.12.1.

This is a genuine but moderate-priority issue, not a drop-everything emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N, VI:H) and the 6.0 MEDIUM score indicate a network-reachable flaw that an authenticated low-privileged user can trigger, but with an attack requirement (AT:P): a higher-privileged victim must actually view the activity log or element history for the payload to fire. The vulnerability is NOT in CISA KEV (no confirmed active exploitation) and no EPSS score was provided in the input, so widespread opportunistic exploitation cannot be quantified. The vuln.today decision label is 'this_month' - meaningful but below act_now/emergency urgency. A detailed, author-verified proof-of-concept (payload plus end-to-end headless-Chrome reproduction showing live DOM injection) is published in the GHSA advisory itself, so exploitability is demonstrated even though no standalone weaponized exploit tool is distributed. The most important mitigating signal, stated by both the advisory and the vendor release notes, is the default Content-Security-Policy (script-src 'self' 'wasm-unsafe-eval', no unsafe-inline): under a default deployment inline JavaScript does NOT execute, so real-world impact is downgraded from script execution to HTML/CSS injection (content spoofing, UI-redress, phishing in a trusted admin page) plus img-src beaconing. Signals are consistent here rather than conflicting; the main caveat is that deployments which relax the default CSP, or render this content in a non-CSP context, escalate to full script execution in an admin session.

A low-privileged content editor creates a named part sub-element (e.g. a Part Parameter) whose name is an HTML/script payload, then deletes it, which writes a CollectionElementDeleted log entry carrying the unescaped name. When an administrator or auditor with system.show_logs opens /log (or any user opens the element's history tab), the payload is inserted as raw HTML and parsed into live DOM nodes in the victim's privileged session. The GHSA advisory includes an author-verified end-to-end PoC demonstrating the injection; on a default deployment the shipped CSP blocks the inline JavaScript, limiting the effect to HTML/CSS injection and image beaconing rather than arbitrary script execution.