Eclipse SW360 EUVD-2026-67130

Two conditions must be simultaneously satisfied: (1) The SW360 instance must have the enable.attachment.store.to.file.system configuration key explicitly enabled - this is an opt-in, non-default setting; deployments using database-backed attachment storage (the default) are completely unaffected. (2) The attacker must hold a valid, low-privilege SW360 user account with attachment upload capability, as confirmed by PR:L in the CVSS 4.0 vector - unauthenticated exploitation is not supported. Exploitation is further bounded by the OS-level file permissions of the account running SW360; paths writable only by root would require the application to run as a privileged user. What limits exploitation: the non-default filesystem storage configuration dramatically narrows the attack surface to a subset of SW360 deployments; authentication prevents anonymous exploitation.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:L) accurately characterizes the risk profile. AT:P (attack requirements present) encodes the critical limiting factor: the enable.attachment.store.to.file.system feature must be explicitly enabled, making this a non-default, opt-in configuration. PR:L confirms that exploitation requires an authenticated, low-privilege SW360 account - unauthenticated exploitation is not supported by the available data. VI:H reflects the ability to write arbitrary content to any filesystem path accessible to the SW360 process account, which could include OS-level files enabling privilege escalation. VC:N indicates no direct confidentiality leak from the traversal primitive itself, though indirect disclosure via overwritten configs is possible. No KEV listing and no public exploit code exist at time of analysis, substantially reducing near-term threat urgency. The realistic priority is moderate-to-high for organizations running filesystem storage mode with untrusted authenticated users; organizations using default database-backed storage are entirely unaffected and need not act urgently.

An authenticated SW360 user with attachment upload rights submits a multipart HTTP upload request with a crafted filename such as ../../../../etc/cron.d/malicious_job targeting a deployment with enable.attachment.store.to.file.system enabled. The server resolves the filename against the attachment directory without sanitization and writes attacker-controlled file content to /etc/cron.d/malicious_job, enabling scheduled command execution as the OS user running SW360. No public exploit code has been identified.