OpenSCAP EUVD-2026-107542

Exploitation requires that the victim (a user or an automated system) actively decompose/split an attacker-crafted SCAP Source DataStream (SDS) file - for example via OpenSCAP's datastream split operation. The specific trigger is OpenSCAP's failure to validate relative file path attributes during SDS decomposition, so the attacker must supply a datastream containing directory traversal sequences. Limiting factors: the vector is LOCAL (AV:L) and demands user interaction (UI:R), so there is no remote, unauthenticated, default-configuration attack path - the attacker cannot proceed without the target choosing to process the malicious datastream, and the resulting file write is bounded by the permissions of the executing process.

This is a moderate-severity path traversal (CWE-22) with a CVSS 3.1 base score of 6.1 and a vector (AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L) that materially constrains real-world risk despite the HIGH integrity impact. The attack vector is LOCAL with REQUIRED user interaction (UI:R), meaning exploitation is not remotely triggerable on its own - an attacker must convince a user or an automated pipeline to decompose a maliciously crafted Source DataStream file. No EPSS score, CISA KEV listing, or public POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. Weighing the signals together: this is a credible but not urgent issue - the HIGH integrity impact (arbitrary file write with the running process's privileges) is the main concern, but the LOCAL vector plus mandatory social-engineering/supply-of-input step keeps it well below drop-everything priority. There is no conflict between the CVSS vector and the description; both agree exploitation hinges on a victim processing attacker-supplied content. Key missing signals: EPSS probability, KEV status, and POC availability are all absent and should be monitored, particularly because OpenSCAP is frequently invoked by automated compliance pipelines that could ingest untrusted datastreams.

An attacker crafts a malicious SCAP Source DataStream containing relative path traversal sequences (e.g. ../../) in its file path attributes and gets it ingested by a target - for example by submitting it to an automated OpenSCAP compliance-scanning pipeline or tricking an administrator into running oscap ds sds-split on it. When the application decomposes the datastream without validating the relative paths, it writes component files outside the intended output directory with the privileges of the scanning process, enabling unauthorized creation or overwriting of files such as scripts, cron entries, or configuration. No public exploit code is identified at time of analysis, but the technique is well-understood path traversal.