After more than 2 years Linux vulnerability reporting is still useless.

edvardgooijenga — Mon, 23 Mar 2026 08:32:53 GMT

It is about 2 years ago that the Linux vulnerabilities reporting issues where announced to Palo Alto.
It's still not fixed. 😞

It looks like Cortex does not look beyond the dash in the version numbers of installed applications. For example; Cortex is reporting a vulnerable zlib 1.2.11
The one actually installed was: zlib.x86_64 1.2.11-40.el9
which was the patched version.

Reported it again and so far no progress or action.
We're currently investigating a Cortex replacement due to Palo's lack of actions on this one and other reported Cortex issues.

Re: After more than 2 years Linux vulnerability reporting is still useless.

susekar — Mon, 23 Mar 2026 14:16:43 GMT

Hello @edvardgooijenga ,

Greetings for the day.

The behavior you’re seeing—where Cortex XDR Vulnerability Assessment flags a patched Linux package (e.g., reporting zlib 1.2.11 as vulnerable even though 1.2.11-40.el9 is installed)—is a known limitation related to how backported packages are evaluated.

Root Cause Analysis

Cortex XDR’s Vulnerability Assessment for Linux currently compares installed package versions against generic version ranges from the National Vulnerability Database.

The mismatch happens due to a few key reasons:

Backporting methodology
Enterprise Linux distributions like Red Hat Enterprise Linux, Ubuntu, and Debian often apply security fixes without changing the main version number.
Instead, they update the build suffix (e.g., -40.el9), which contains the actual patch status.
NVD limitation
The NVD tracks upstream versions (e.g., “< 1.2.12”) but does not account for distribution-specific build strings used in backporting.
Current engine logic
Cortex XDR primarily evaluates the base version (1.2.11) against NVD ranges and does not fully validate whether vendor-specific patches (via build suffixes) are already applied.

Current Status and Roadmap

Palo Alto Networks engineering is working on improving this behavior by enhancing how vulnerabilities are detected and correlated.

Ongoing improvements include:

Better handling of backported patches
Integration with vendor-specific security data (such as OVAL feeds)
A next-generation vulnerability scanning approach that goes beyond simple version matching

Recommended Management Actions

Until these improvements are fully implemented, you can handle these false positives manually:

1. Exclude the CVE

Go to Assets → Vulnerability Assessment
Locate the flagged CVE
Right-click and select Exclude
Choose Report CVE as incorrect to provide feedback to Palo Alto Networks

2. Verify Patch Status Locally

On your RHEL 9 system, you can confirm whether the vulnerability is actually patched:

rpm -q --changelog zlib | grep CVE

This command shows whether the relevant CVE fixes have been applied in the installed package build.

To move this forward as quickly as possible, the best approach is to escalate it through the proper support channels:

Raise a P1 support case
Submit a Priority 1 case in the Palo Alto Networks support portal and clearly describe the impact. Request that the case be escalated to the Engineering team for deeper investigation or to obtain the latest update.
Engage your account team
Reach out to your Palo Alto Networks account manager or SE. They can help internally track the issue, push for prioritization, and provide an estimated timeline (ETA) or roadmap updates.

If you feel this has answered your query, please let us know by clicking like and on "mark this as a Solution".

Thanks & Regards,
S. Subashkar Sekar