Current Behavior

In CSAF VEX files, the workaround remediation includes products that are explicitly marked as known_not_affected with the vulnerable_code_not_present flag.

This is a systematic issue affecting many CVEs:

Example: CVE-2025-4574

The workaround remediation contains 141 products:

• known_affected: 79 products
• known_not_affected: 62 products

Products like red_hat_directory_server_11 and red_hat_directory_server_12 appear in:

1. flags with vulnerable_code_not_present label
2. known_not_affected list
3. workaround remediation

Expected Behavior

I would expect that products in known_not_affected should NOT be included in any remediation (including workaround), because:

• known_not_affected means the product is not vulnerable
• vulnerable_code_not_present flag explicitly states the vulnerable code does not exist in the product
• A workaround is typically needed only for vulnerable products

The workaround remediation should only include products from known_affected.

Or am I missing something? Is the workaround category intentionally designed to include non-affected products as well?

Steps to Reproduce

1. Check products in known_not_affected

curl -s "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-4574.json" | jq -r '.vulnerabilities[0].product_status.known_not_affected[]' | grep directory_server

Output:

red_hat_directory_server_11:redhat-ds:11/389-ds-base
red_hat_directory_server_12:redhat-ds:12/389-ds-base

2. Check that these products have vulnerable_code_not_present flag

curl -s "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-4574.json" | jq -r '.vulnerabilities[0].flags[] | select(.label == "vulnerable_code_not_present") | .product_ids[]' | grep directory_server

Output:

red_hat_directory_server_11:redhat-ds:11/389-ds-base
red_hat_directory_server_12:redhat-ds:12/389-ds-base

3. Check that the same products appear in workaround remediation

curl -s "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-4574.json" | jq -r '.vulnerabilities[0].remediations[] | select(.category == "workaround") | .product_ids[]' | grep directory_server

Output:

red_hat_directory_server_11:redhat-ds:11/389-ds-base
red_hat_directory_server_12:redhat-ds:12/389-ds-base

4. Verify workaround = known_affected + known_not_affected

curl -s "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-4574.json" | jq -r '.vulnerabilities[0] | {known_affected: (.product_status.known_affected | length), known_not_affected: (.product_status.known_not_affected | length), workaround: ([.remediations[] | select(.category == "workaround") | .product_ids[]] | unique | length)}'

Output:

{
  "known_affected": 79,
  "known_not_affected": 62,
  "workaround": 141
}

79 + 62 = 141, confirming that workaround includes ALL products regardless of affected status.

Impact Statement

We are building a vulnerability scanner that parses CSAF VEX data. We can work around this issue by first retrieving known_affected products and then filtering out any workaround remediation entries that are not in that list.

However, the core question is: should the workaround category's product_ids only contain affected products in the first place? If so, the current data may not be accurate.

If the workaround remediation is intended to include only affected products, shouldn't it match the known_affected list rather than including all products?

Attachments & Links

• CSAF VEX file: CVE-2025-4574
• flags section (vulnerable_code_not_present): GitHub link
• known_not_affected section: GitHub link
• workaround remediation: GitHub link
• CVE page: CVE-2025-4574