Customer configured IngressNodeFirewall to allow ingress traffic only from specific CIDRs.  
When they conducted scan for vulnerabilities using Qualys from CIDRs outside the allowed range, they discovered a vulnerability, which does not have CVE.

    4.16.41

    Always when scan vulnerability using Qualys

    1. Create IngressNodeFirewall to allow ingress traffic only from specific CIDRs.

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
  name: ingressnodefirewall
spec:
  ingress:
    - rules:
        - action: Allow
          order: 12
          protocolConfig:
            protocol: TCP
            tcp:
              ports: '22'
        - action: Allow
          order: 13
          protocolConfig:
            protocol: TCP
            tcp:
              ports: '443'
        - action: Allow
          order: 14
          protocolConfig:
            protocol: TCP
            tcp:
              ports: '9001'
        - action: Allow
          order: 15
          protocolConfig:
            protocol: TCP
            tcp:
              ports: '9100'
        - action: Allow
          order: 16
          protocolConfig:
            protocol: TCP
            tcp:
              ports: '9099'
        - action: Allow
          order: 17
          protocolConfig:
            protocol: TCP
            tcp:
              ports: '22623'
        - action: Allow
          order: 24
          protocolConfig:
            protocol: TCP
            tcp:
              ports: '6443'
      sourceCIDRs:
        - 10.119.151.84/32
        - 10.119.151.0/24
    - rules:
        - action: Deny
          order: 18
          protocolConfig:
            protocol: TCP
            tcp:
              ports: '22'
        - action: Deny
          order: 19
          protocolConfig:
            protocol: TCP
            tcp:
              ports: '443'
        - action: Deny
          order: 20
          protocolConfig:
            protocol: TCP
            tcp:
              ports: '9001'
        - action: Deny
          order: 21
          protocolConfig:
            protocol: TCP
            tcp:
              ports: '9100'
        - action: Deny
          order: 22
          protocolConfig:
            protocol: TCP
            tcp:
              ports: '9099'
        - action: Deny
          order: 23
          protocolConfig:
            protocol: TCP
            tcp:
              ports: '22623'
      sourceCIDRs:
        - 0.0.0.0/0
  interfaces:
    - br-ex
  nodeSelector:
    matchLabels:
      kubernetes.io/os: linux

    3. The results of vulnerability scan on Qualys is like:
   
If malicious users fragment IP packets in a special way, they can make the filtering device of your firewall accept packets that it would normally reject.
We check for this vulnerability by running six different tests.
 Test 1: Simple Fragmentation, No Overlap
A TCP SYN packet is split into two fragments. The first fragment contains the first eight bytes of the TCP header with the "More Fragments" (MF) flag set and a "Fragment Offset" (Offset) of zero. The second fragment contains the remaining twelve bytes of the TCP header with the MF flag unset and an Offset of one (which equals 8 octets).
If this check succeeds against a firewalled port, the firewall is vulnerable.
 Test 2: TCP Flag Overlap
Two fragments are sent. The first contains MF=0, Offset=1 and contains the
last twelve bytes of a TCP header with Flags=SYN. The second contains MF=1, Offset=0 and a full TCP header with Flags=ACK.
The hope is that the firewall will see what appears to be a TCP ACK packet, thereby allow the fragments through, and the host behind the firewall will assemble them to a SYN packet and respond to it.
 Test 3: TCP Flag Overlap (reverse)
This test is same as the above test (#2) but with the order of the fragments sent in the reversed order.
 Test 4: TCP Port Overwrite
Three fragments are sent. The first contains MF=1, Offset=0 and the payload is 16 bytes of a TCP header with Flags=SYN and a destination port (dport) of a port known not to be firewalled. The second fragment contains MF=1, Offset=0 and eight bytes of a TCP header. The third packet contains MF=0, Offset=2 (16 octets) and the last four bytes of the TCP header.
The hope is that the first fragment, containing the dport of a known allowed port, will get through the firewall along with the other fragments, but at the host the second fragment (containing only source port, destination port and sequence number) will overwrite the dport of the first fragment.
 Test 5: TCP Port Overwrite (different order)
The test is same as #4 but the order in which the first and second fragments are sent is reversed.
 Test 6: IPFilter Fragmentation Cache Vulnerability
Five fragments are sent:
 First: MF=0, Offset=0, Payload=36 bytes of TCP packet with Flags=SYN,
dport=port known not to be firewalled
 Second: MF=1, Offset=0, Payload=first 24 bytes of the same TCP packet as #1
 Third: MF=0, Offset=4 (32 octets), Payload=last 4 bytes of the same TCP
packet
 Fourth: MF=1, Offset=3, Payload=only 8 bytes of the same TCP packet
 Fifth: MF=0, Offset=0, Payload=20 bytes of a TCP header with Flags=SYN,
dport=the port to scan
These fragments are designed to exploit a vulnerability in ipfilter --
which has a flaw in its 'decision cache' -- to scan forbidden ports. When
receiving a new fragment, ipfilter checks if this fragment should be
accepted or not (based on its normal rules) and saves the results in its
decision cache based on IP ID, protocol number, source and destination
addresses. If the firewall contains this vulnerability, the target server
will see the last fragment.
In the Result section, "No-reply port <number>" means that the firewall drops normal, unfragmented, TCP SYN packets sent to this port. But we are able to use one of the above techniques to bypass the firewall to reach this port on the target host.
In the Result section, "RST-firewalled port <number>" means that the firewall responds with TCP RST packets to normal, unfragmented, TCP SYN packets sent to this port. But we are able to use one of the above techniques to bypass the firewall to reach this port on the target host.
By exploiting this vulnerability, malicious users can bypass firewall policies and access services which are normally protected by the firewall. This makes the firewall almost useless.
No-reply port 22 - Simple Fragmentation, No Overlap;#     

results of scan indicate vulnerability

No vulnerability