CVE scans not matching the expected CVE-2021-23017


Hi and thanks for your help with this. Unfortunately I now have a follow up question, because even with the updated NVTs I’m unable to see the expected CVE match.

Let me know it you’d prefer this in a new ticket.

I’ve updated and ran another OpenVAS scan against the same server. I did this today 11 Feb (and also did a ‘gvmd --rebuild’ to be sure).

greenbone-nvt-sync --feedversion                    -> 202202101102
greenbone-feed-sync --type SCAP --feedversion       -> 202202090230
greenbone-feed-sync --type CERT --feedversion       -> 202202090130
greenbone-feed-sync --type GVMD_DATA --feedversion  -> 202201281556

I’m pleased to report the new VTs are registering both the “nginx” and “f5” CPEs. Here’s a small fragment of the results showing this:

  <result id="b2b98965-2e3c-438e-8d3c-44ce508d0adb">
    <name>CPE Inventory</name>


Unfortunately subsequent CVE scans still aren’t matching the expected CVE-2021-23017 against cpe:/a:f5:nginx:1.18.0.

I believe I’m using the scanners correctly, e.g. adding results to Assets, and do get CVE matches for other software on other servers.

Further below is another XML fragment with part of the CVE-2021-23017 definition.

I admit I don’t know how to read this, but notice there’s only the one exact NGINX product “cpe:/a:f5:nginx:0.6.18” that’s listed. Other CVE definitions seem to have long lists individual product CPEs (and/or maybe even have ranges?) so I wonder if this is why it’s not matching.

So, my question:

  • Are you able to see why the GVM isn’t reporting CVE-2021-23017 against cpe:/a:f5:nginx:1.18.0? E.g. are there other changes to the feed that need to be made, or is it more likely it’s my GVM installation or how I’m using it?

Thanks again for you help (and the usual apologies if I’m doing something daft)!

<get_info_response status="200" status_text="OK">
  <info id="CVE-2021-23017">
      <description>A security issue in nginx resolver was identified, which might allow an attacker who is able to forge UDP packets from the DNS server to cause 1-byte memory overwrite, resulting in worker process crash or potential other impact.</description>
      <products>cpe:/a:f5:nginx:0.6.18 cpe:/a:openresty:openresty: cpe:/o:fedoraproject:fedora:33 cpe:/o:fedoraproject:fedora:34 cpe:/a:netapp:ontap_select_deploy_administration_utility:- cpe:/a:oracle:communications_control_plane_monitor:3.4 cpe:/a:oracle:communications_control_plane_monitor:4.2 cpe:/a:oracle:communications_control_plane_monitor:4.3 cpe:/a:oracle:communications_control_plane_monitor:4.4 cpe:/a:oracle:communications_fraud_monitor:3.4 cpe:/a:oracle:communications_fraud_monitor:4.4 cpe:/a:oracle:communications_operations_monitor:3.4 cpe:/a:oracle:communications_operations_monitor:4.2 cpe:/a:oracle:communications_operations_monitor:4.3 cpe:/a:oracle:communications_operations_monitor:4.4 cpe:/a:oracle:enterprise_telephony_fraud_monitor:3.4 cpe:/a:oracle:enterprise_telephony_fraud_monitor:4.2 cpe:/a:oracle:enterprise_telephony_fraud_monitor:4.3 cpe:/a:oracle:enterprise_telephony_fraud_monitor:4.4 </products>
      <raw_data><entry xmlns="" xmlns:cpe-lang="" xmlns:cvss="" xmlns:cvss3="" xmlns:patch="" xmlns:scap-core="" xmlns:vuln="" xmlns:xsi="" id="CVE-2021-23017">
1 Like

(Quick moderator note, I’ve broken out this post from a different thread and moved it to the Feed Services category. @khesterproton, I titled it from your post, but you can update the title if you’d like. Thanks!)


Yes, indeed it seems that this is originating from the following and has nothing to do with your setup or the VT / detection side:

NVD - CVE-2021-23017 is using a range From (including) 0.6.18 to Up to (excluding) 1.20.1 which seems to be not reflected in the posted .xml snippet.

IIRC there is already an internal ticket to evaluate that but not sure about the status and outcome. But there is a completely re-write of the feed deployment process ongoing so the published data could be more accurate when this is finished.


Great, thanks again for your help.

I’ll mark this as solved, because you’ve answered my question and confirmed where the issue lies.

1 Like

For the records, this specific problem should have been solved now according to Am I reading the CVE for CVE-2022-42889 Wrong? - #5 by bricks