Part-DB EUVD-2026-108578

Requires two concrete preconditions stated in the advisory: (1) the deployment must have server-side attachment downloads enabled via ALLOW_ATTACHMENT_DOWNLOADS=1 - the vulnerable downloadURL() path is unreachable otherwise; and (2) the attacker must be an authenticated Part-DB user holding permission to create or edit attachments (PR:L), so this is not exploitable by anonymous/remote-unauthenticated actors. No user interaction by a victim is needed (UI:N). The advisory explicitly notes that ALLOW_ATTACHMENT_DOWNLOADS_FROM_LOCALNETWORK=1 was used only for the local PoC and is NOT the root cause, so exploitation does not depend on that setting - the attacker simply supplies any reachable external URL serving a large response. Limiting factors for defenders: instances that keep server-side downloads disabled are not affected, and the account/permission requirement restricts the attacker set to provisioned users.

This is a genuinely moderate, not critical, issue and the signals are internally consistent rather than conflicting. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) scores 5.3 (Medium) and the vuln.today priority is 'this_month' - not 'act_now' or 'emergency' - which aligns with the impact being availability-only disk exhaustion (VC:N/VI:L/VA:L, no confidentiality compromise and no code execution). It is NOT in CISA KEV, so there is no confirmed active exploitation. No EPSS score was provided, so exploitation-probability modeling cannot be cited. The PR:L metric confirms an authenticated attacker with attachment create/edit rights is required, which meaningfully narrows the threat population to users who already hold accounts and attachment permissions on the instance. A detailed, reproducible proof-of-concept is published directly in the GHSA advisory (Docker setup, a Python oversized-file server, and verification queries), so exploitation is well understood even though it is not a packaged weaponized exploit. The practical risk is bounded further because it is only reachable when server-side attachment downloads are explicitly enabled (ALLOW_ATTACHMENT_DOWNLOADS=1). Net assessment: a real but lower-tier priority - patch within a normal maintenance cycle; it is not a drop-everything emergency, but the clear public PoC and trivial complexity mean it should not be deferred indefinitely on instances with downloads enabled.

An authenticated Part-DB user with permission to create or edit attachments creates an attachment pointing to an attacker-controlled external URL and checks 'Download external file'; because the server-side download path never enforces MAX_ATTACHMENT_FILE_SIZE, Part-DB streams the entire oversized remote file to disk. By repeating this against an endpoint that serves arbitrarily large responses, the user fills available disk space and degrades or halts the service for everyone. A full, working proof-of-concept - including a Python server returning a 5 MB file that is stored despite a 1M limit - is published in the GHSA advisory.