Those names then flow into:

• rename($tmpTailoringFile, "{$tmpDir}/{$newTailoringFilename}") — AuditFileLib.php:2307 (a file with arbitrary metachars in its name is created)
• the SCAP zip repack command — exec("{$settings['CommandZIP']} -9Tj $tmpZipFile $newTailoringFilenameEsc") where the unescaped $tmpZipFile derives from the client's filename param — the downstream command injection of CVE-2026-19681.

Lab-verified boundary: traversal is not part of the pre-6.9 flaw — both tailoring params reject / (error 146 Invalid syntax for attribute ... on a ../ payload). The missing piece is exactly the charset filter, which is what the CVE text means by "could contribute to a downstream command injection."

Patch (6.9.0)

AuditFiles::applySCAPTailoringFile():

plus basename() on both names and escapeshellarg() on the zip operands.

PoC

Differential version probe — one request, opposite outcomes per version:

• ≤ 6.8.x → HTTP 200 (audit file created with the metachar name) or error 106 (post-exec bounce; the name still reached rename()/zip) → no charset validation
• 6.9.0 → immediate "Invalid tailoring filename."

Operational notes (all lab-verified):

• upload resource is /rest/file/upload (multipart Filedata, context form field)
• the audit zip is staged with a blank context — context=auditFile runs content detection on the zip (error 107 on a dummy zip)
• the tailoring file must contain parseable datastream XML with ≥1 Profile (embedded)
• auditFile body needs type=scapLinux|scapWindows, version=1.2, benchmarkName, dataStreamName

Relationship to CVE-2026-19681

19679 is the validation gap; 19681 is the exec sink. The same upload flow exercises both: 19681 plants metachars in the staged filename (via the upload context prefix) and fires them through the unescaped $tmpZipFile; 19679 demonstrates the sibling parameters accept the same character class up to (and into) the same command string. 6.9.0 fixes both sides in one commit area: charset + basename + escapeshellarg.

Example run