Part Db Server
Monthly
Password-reset link poisoning in Part-DB Server (through 2.13.2) lets an unauthenticated remote attacker who can reach the public /pw_reset/request endpoint obtain a valid reset token for any known account, including the seeded admin, by submitting a forgot-password request with a spoofed HTTP Host header; the victim is emailed a genuine, valid token inside a link pointing at an attacker-controlled hostname, which the attacker then replays against the real instance to set a new password and take over the account. Exploitation is limited to installations that have email-based password reset enabled (ALLOW_EMAIL_PW_RESET=1) and leave TRUSTED_HOSTS empty, which the shipped configuration does by default, and the token only reaches the attacker if the victim opens the legitimate-looking email or an inbound URL scanner pre-fetches the link. The vendor advisory includes a detailed end-to-end reproduction; there is no CISA KEV listing and no confirmed active exploitation at time of analysis, and the vendor released a fix in 2.13.3.
Authenticated file upload in Part-DB Server 2.12.0 and earlier lets any member of the default users group obtain remote code execution as the www-data web user by uploading a .phar attachment that the shipped Apache configuration routes to PHP-FPM. The upload handler rewrites a fixed denylist of dangerous extensions to .txt but omits phar, and a freshly created attachment type carries an empty file-type filter, so the client-supplied .phar extension survives into the web-served public/media/ directory under the document root. The stock Docker image is exploitable by default, the public advisory documents a live-verified reproduction against jbtronics/part-db1:v2.12.0, and the issue is fixed in 2.12.1.
Spreadsheet formula injection in Part-DB through 2.13.1 lets an authenticated user who holds the '@parts.import' permission store formula-prefixed strings (for example =1+1) in user-controlled part fields via CSV import, which are later written into XLSX/XLS exports as live formula cells instead of plain text. The payload does not execute inside Part-DB itself; it only becomes dangerous when a second user with read access to those parts runs the export at /parts/export and opens the file in spreadsheet software that evaluates formulas, so impact is limited to data exposure, external reference requests, or misleading content in the victim's client (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N, medium). A detailed public PoC using a benign =1+1 payload accompanies the GitHub advisory; it is a demonstrated reference and is not verified as working exploit code for data exfiltration, and there is no KEV listing or evidence of active exploitation. Risk is concentrated in multi-user deployments where semi-trusted users can seed part data that more privileged users later export.
Authenticated users holding the API access permission can bypass the configured maximum attachment file size in Part-DB by submitting base64-encoded file data through the JSON-LD attachment API, which decodes and stores the payload without applying the MAX_ATTACHMENT_FILE_SIZE check enforced for browser uploads. Repeated oversized uploads let such a user gradually exhaust server disk space, degrading or denying service to other users; confidentiality and integrity are unaffected. The flaw is fixed in Part-DB 2.13.2, and a working proof-of-concept (a 5 MB attachment stored despite a 1M limit) is published in the vendor advisory; no confirmed active exploitation is known, and the decision label is 'this_month'.
Authenticated users with attachment create/edit permissions can bypass the configured MAX_ATTACHMENT_FILE_SIZE limit in Part-DB when server-side attachment downloads are enabled, because the 'Download external file' code path (downloadURL() in src/Services/Attachments/AttachmentSubmitHandler.php) streams the remote response directly to disk without checking Content-Length or counting bytes. Repeatedly storing oversized files can exhaust disk space, causing failed uploads, database or cache write failures, and denial of service for other users. The issue affects Part-DB versions through 2.13.1 (composer package part-db/part-db-server, CPE cpe:2.3:a:part-db:part-db-server) and is fixed in 2.13.2; no public exploit code is confirmed beyond the advisory's own proof of concept, and EPSS/KEV data were not provided in the source material.
Stored cross-site scripting in Part-DB Server 2.12.2 and earlier allows an authenticated user with attachment-upload permission to plant a JavaScript-bearing SVG that executes in the Part-DB origin whenever another user opens the attachment inline at /attachment/{id}/view. Because sanitization is decided from the user-controlled filename extension, naming the SVG payload with a non-SVG extension such as .jpg skips the sanitizer entirely, while the response still carries Content-Type: image/svg+xml; this can lead to session hijacking or account takeover of whichever user - potentially an administrator - views the file. Rated CVSS 5.4 (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) with the vendor also citing CWE-434 alongside CWE-79; not listed in CISA KEV, and the advisory ships a public proof-of-concept reproduction (curl upload steps) rather than confirmed working exploit code; fixed in 2.12.3.
Stored HTML injection in Part-DB through 2.12.0 lets an authenticated user with edit rights on an entity store a crafted name on a named collection sub-element (Part Parameter, Attachment, PartLot, Orderdetail and similar) and have that markup emitted unescaped when a higher-privileged victim opens the activity log at /log (requires system.show_logs, typically an admin or auditor) or the affected element's history table; the root cause is a single missed htmlspecialchars() in the CollectionElementDeleted branch of LogEntryExtraFormatter. The vendor advisory documents a proof-of-concept in which the stored payload parses into live img-onerror and script nodes in the victim's page, but the shipped Content-Security-Policy (script-src 'self' 'wasm-unsafe-eval', no unsafe-inline, plus X-Content-Type-Options: nosniff) blocks inline JavaScript execution, so on a default deployment the realistic impact is HTML and inline-CSS injection, content spoofing, UI redressing and img-src beaconing rather than script execution; full script execution requires a relaxed or non-default CSP or another rendering context. The issue is fixed in 2.12.1, and the overall read is a genuine but moderate-priority defect rather than a drop-everything emergency.
Password-reset link poisoning in Part-DB Server (through 2.13.2) lets an unauthenticated remote attacker who can reach the public /pw_reset/request endpoint obtain a valid reset token for any known account, including the seeded admin, by submitting a forgot-password request with a spoofed HTTP Host header; the victim is emailed a genuine, valid token inside a link pointing at an attacker-controlled hostname, which the attacker then replays against the real instance to set a new password and take over the account. Exploitation is limited to installations that have email-based password reset enabled (ALLOW_EMAIL_PW_RESET=1) and leave TRUSTED_HOSTS empty, which the shipped configuration does by default, and the token only reaches the attacker if the victim opens the legitimate-looking email or an inbound URL scanner pre-fetches the link. The vendor advisory includes a detailed end-to-end reproduction; there is no CISA KEV listing and no confirmed active exploitation at time of analysis, and the vendor released a fix in 2.13.3.
Authenticated file upload in Part-DB Server 2.12.0 and earlier lets any member of the default users group obtain remote code execution as the www-data web user by uploading a .phar attachment that the shipped Apache configuration routes to PHP-FPM. The upload handler rewrites a fixed denylist of dangerous extensions to .txt but omits phar, and a freshly created attachment type carries an empty file-type filter, so the client-supplied .phar extension survives into the web-served public/media/ directory under the document root. The stock Docker image is exploitable by default, the public advisory documents a live-verified reproduction against jbtronics/part-db1:v2.12.0, and the issue is fixed in 2.12.1.
Spreadsheet formula injection in Part-DB through 2.13.1 lets an authenticated user who holds the '@parts.import' permission store formula-prefixed strings (for example =1+1) in user-controlled part fields via CSV import, which are later written into XLSX/XLS exports as live formula cells instead of plain text. The payload does not execute inside Part-DB itself; it only becomes dangerous when a second user with read access to those parts runs the export at /parts/export and opens the file in spreadsheet software that evaluates formulas, so impact is limited to data exposure, external reference requests, or misleading content in the victim's client (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N, medium). A detailed public PoC using a benign =1+1 payload accompanies the GitHub advisory; it is a demonstrated reference and is not verified as working exploit code for data exfiltration, and there is no KEV listing or evidence of active exploitation. Risk is concentrated in multi-user deployments where semi-trusted users can seed part data that more privileged users later export.
Authenticated users holding the API access permission can bypass the configured maximum attachment file size in Part-DB by submitting base64-encoded file data through the JSON-LD attachment API, which decodes and stores the payload without applying the MAX_ATTACHMENT_FILE_SIZE check enforced for browser uploads. Repeated oversized uploads let such a user gradually exhaust server disk space, degrading or denying service to other users; confidentiality and integrity are unaffected. The flaw is fixed in Part-DB 2.13.2, and a working proof-of-concept (a 5 MB attachment stored despite a 1M limit) is published in the vendor advisory; no confirmed active exploitation is known, and the decision label is 'this_month'.
Authenticated users with attachment create/edit permissions can bypass the configured MAX_ATTACHMENT_FILE_SIZE limit in Part-DB when server-side attachment downloads are enabled, because the 'Download external file' code path (downloadURL() in src/Services/Attachments/AttachmentSubmitHandler.php) streams the remote response directly to disk without checking Content-Length or counting bytes. Repeatedly storing oversized files can exhaust disk space, causing failed uploads, database or cache write failures, and denial of service for other users. The issue affects Part-DB versions through 2.13.1 (composer package part-db/part-db-server, CPE cpe:2.3:a:part-db:part-db-server) and is fixed in 2.13.2; no public exploit code is confirmed beyond the advisory's own proof of concept, and EPSS/KEV data were not provided in the source material.
Stored cross-site scripting in Part-DB Server 2.12.2 and earlier allows an authenticated user with attachment-upload permission to plant a JavaScript-bearing SVG that executes in the Part-DB origin whenever another user opens the attachment inline at /attachment/{id}/view. Because sanitization is decided from the user-controlled filename extension, naming the SVG payload with a non-SVG extension such as .jpg skips the sanitizer entirely, while the response still carries Content-Type: image/svg+xml; this can lead to session hijacking or account takeover of whichever user - potentially an administrator - views the file. Rated CVSS 5.4 (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) with the vendor also citing CWE-434 alongside CWE-79; not listed in CISA KEV, and the advisory ships a public proof-of-concept reproduction (curl upload steps) rather than confirmed working exploit code; fixed in 2.12.3.
Stored HTML injection in Part-DB through 2.12.0 lets an authenticated user with edit rights on an entity store a crafted name on a named collection sub-element (Part Parameter, Attachment, PartLot, Orderdetail and similar) and have that markup emitted unescaped when a higher-privileged victim opens the activity log at /log (requires system.show_logs, typically an admin or auditor) or the affected element's history table; the root cause is a single missed htmlspecialchars() in the CollectionElementDeleted branch of LogEntryExtraFormatter. The vendor advisory documents a proof-of-concept in which the stored payload parses into live img-onerror and script nodes in the victim's page, but the shipped Content-Security-Policy (script-src 'self' 'wasm-unsafe-eval', no unsafe-inline, plus X-Content-Type-Options: nosniff) blocks inline JavaScript execution, so on a default deployment the realistic impact is HTML and inline-CSS injection, content spoofing, UI redressing and img-src beaconing rather than script execution; full script execution requires a relaxed or non-default CSP or another rendering context. The issue is fixed in 2.12.1, and the overall read is a genuine but moderate-priority defect rather than a drop-everything emergency.