Part-DB CVE-2026-86019

Exploitation requires an authenticated account that has been granted the @api.access_api permission AND permission to create attachments - without the API permission the endpoint returns HTTP 403. The specific trigger is the API base64 upload path (the AttachmentUpload DTO 'data' field / HandleAttachmentsUploadsProcessor → AttachmentSubmitHandler::handleUpload), which decodes and stores base64 file data without applying the MAX_ATTACHMENT_FILE_SIZE check that Symfony's File(maxSize) constraint enforces for browser form uploads. Limiting factors: it is authenticated (PR:L) and depends on the deployment granting API and attachment-creation rights to users; the impact is gradual disk exhaustion from repeated oversized uploads rather than an instant crash; confidentiality and integrity are unaffected. Browser-based uploads are NOT affected because form-layer validation applies there.

This is a genuinely moderate, not high, priority. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) with a base score of 5.3 describes a network-reachable, low-complexity flaw but one that requires privileges (PR:L) - specifically an authenticated user holding the @api.access_api permission and attachment-creation rights - and whose only impact is availability (VC:N/VI:N/VA:L; no confidentiality or integrity effect). The decision framework signal (vuln.today 'this_month') is consistent with a lower-urgency, availability-only defect rather than an emergency. No EPSS score and no KEV listing are present in the input, so there is no evidence of active exploitation or high predicted exploitation probability; exploitation status is therefore 'no public exploit identified' in the KEV sense, though a detailed public PoC reference does exist in the GHSA advisory (see exploit scenario). The signals are internally consistent: a network vector gated by authentication, low technical impact (disk exhaustion / DoS), and no scope change (SC/SI/SA:N). The main caveat is that impact severity depends on deployment - exploitation requires that non-admin users be granted API access, and the DoS is a gradual disk-exhaustion condition requiring repeated oversized uploads rather than a single crashing request. Overall this is a real but bounded insider/low-privilege availability issue, not a widely-weaponizable critical flaw.

An authenticated Part-DB user who has been granted API access and attachment-creation permission crafts an API POST to /api/attachments with base64-encoded file data exceeding the configured MAX_ATTACHMENT_FILE_SIZE, which the API path stores without enforcing the size limit. By scripting repeated oversized uploads the attacker consumes available disk space until uploads, cache, logging, or database writes fail, causing denial of service for all users. A detailed public PoC with full reproduction steps (storing a 5 MB file against a 1M limit) is published in the GHSA advisory, though it is not labeled as verified weaponized exploit code.