Part-DB vulnerabilities

Part-DB prior to version 2.13.3 builds the absolute URL of the password-reset link it emails from the client-supplied HTTP Host header without trusted-host validation. An unauthenticated attacker can submit a forgot-password request for a known account with a spoofed Host header, causing Part-DB to email a reset link with an attacker-controlled hostname but the genuine reset token. When the victim or an automated mail scanner opens the link, the token is disclosed to the attacker, who can replay it to take over the account, including the seeded admin account.

Part-DB prior to version 2.13.2 contains a spreadsheet formula injection vulnerability in the part import/export workflow. An authenticated user with import permission can import a CSV file containing formula-prefixed values, such as =1+1, into user-controlled part fields. When the part is later exported as an XLSX spreadsheet, Part-DB writes the value using setCellValue() without neutralizing formula characters, so the exported file may contain an executable formula that could be evaluated by another user's spreadsheet software.

Part-DB prior to version 2.13.2 allows authenticated API users to bypass the configured maximum attachment file size by uploading attachments through the API using base64-encoded file data. The application enforces the size limit for normal browser-based uploads, but the API base64 upload path does not apply the same validation. As a result, an authenticated user with API access and permission to create attachments can upload files larger than the configured maximum, potentially exhausting disk space and causing a denial of service.

Part-DB prior to version 2.13.2 allows authenticated users to bypass the configured maximum attachment file size when using the server-side “Download external file” attachment feature. When server-side attachment downloads are enabled, Part-DB downloads the remote file and streams it directly to disk without enforcing the MAX_ATTACHMENT_FILE_SIZE limit. As a result, an authenticated user who can create or edit attachments can cause Part-DB to store files larger than the configured maximum, potentially exhausting disk space and causing a denial of service.

Part-DB prior to version 2.12.3 sanitizes SVG files based solely on the user-controlled filename extension rather than the actual file content type. An authenticated attacker can upload a malicious SVG with a JavaScript payload using a non-SVG extension (e.g., .jpg), bypassing sanitization entirely. When any user views the attachment inline, the browser receives Content-Type: image/svg+xml and executes the embedded script in the Part-DB origin.

In Part-DB before version 2.12.2, BOM validation messages are rendered using Twig's |raw filter and include translated placeholders populated with user-controlled Part names. A user who can edit a Part name can store HTML markup that is rendered in another user's BOM validation result page, resulting in cross-user stored HTML injection.

In Part-DB before version 2.12.1, the committed .env file contains a fixed APP_SECRET value that the official jbtronics/part-db1 Docker image does not override or randomize at container start-up. Since Symfony uses APP_SECRET as the HMAC key for signing remember-me cookies, an attacker who knows the secret can forge an arbitrary-user remember-me cookie and gain a fully authenticated session without credentials.

Part-DB, an open source inventory management system for electronic components, prior to version 2.12.1 contains a stored XSS vulnerability. The LogEntryExtraFormatter class in the CollectionElementDeleted branch interpolates getOldName() and getCollectionName() into HTML without htmlspecialchars(), allowing a low-privileged content editor to store an HTML/script payload as the name of a sub-element and have it executed in the browser of a higher-privileged victim viewing the activity log or element history.

In Part-DB before version 2.12.1, the attachment upload handler's dangerous-extension blocklist does not include phar. A .phar file uploaded as an attachment is stored in public/media/ (the Apache document root), and the shipped Apache configuration routes .phar to PHP-FPM, allowing execution of arbitrary PHP.