When a vulnerability is four days old, the internet measurement question is narrower than it looks. You can count assets that resemble the product. You cannot count confirmed vulnerable firewalls from a banner alone.

What the advisory establishes

CVE-2026-0321 is a denial-of-service flaw in Palo Alto Networks PAN-OS network services. The CVE Record, published 14 October 2026, says crafted traffic sent to or through a dataplane interface can trigger a denial of service, and repeated attempts put the firewall into maintenance mode. It requires network access and no authentication, and it scores 6.6 under CVSS 4.0 with PR:N and VA:H.
Cloud NGFW and Panorama are not affected. Fixed releases exist in the 10.2, 11.1, 11.2, 12.1 and 12.2 branches. No workarounds are documented, and Threat ID 510038 offers limited coverage only with SSL Decryption enabled.

Choosing a query that answers a useful question

The productive framing for the dataplane issue is product population, not CVE population. A search dork of app="Palo Alto Networks" asks how much of the internet presents as this vendor's equipment. On 22 October 2026 that returned 22,599 matching assets.
A CVE filter of vul.cve="CVE-2026-0321" returned 0. That is expected at this age. ZoomEye indexes what it observes, and CVE attribution lags disclosure. A zero here is not evidence that nobody is exposed. It is evidence that the index has not yet associated this identifier with assets.
Two other probes are worth recording for context. product="PAN-OS" returned 3, and title="Palo Alto Networks" returned 1,225. The wide spread between 22,599 and 3 shows how much a single field choice changes the answer. Product fields need confirmation; broad application fingerprints return population, not precision.

The claim you can defend

A defensible sentence reads: roughly 22,599 internet-visible assets matched a Palo Alto Networks application fingerprint in late October 2026, and the subset running vulnerable PAN-OS builds is unknown from outside.
An indefensible sentence reads: 22,599 firewalls are vulnerable to CVE-2026-0321. The first is a measurement with a stated method. The second invents a claim the data cannot support, because version, patch level and interface exposure are invisible to a fingerprint query.

Turning measurement into prioritisation

The number is useful for sizing, not for ticking names off a list. Use it to justify asking asset owners a sharper question: which of our internet-facing firewalls run a branch listed as affected, and which of those expose a dataplane interface to untrusted networks?
Pair the external view with the internal one. Management-plane inventory gives versions. Traffic paths give exposure. The CVE record gives the fixed releases. Only when all three line up does a device become an upgrade candidate with a real deadline.

Measurement limits worth stating in the report

ZoomEye counts assets that match a query at a point in time. Firewalls behind NAT, on private ranges or presenting no fingerprint are invisible. Conversely, appliances that merely share a fingerprint can inflate the count. Timing matters too: a query run today may return a different figure next week, and CVE-level filters fill in over time as indexing catches up.
Write those limits into the deliverable. An exposure number presented without its method and caveats invites someone to act on a fiction.

What the dataplane angle changes

Most exposure discussions for firewall bugs focus on the management interface, because that is where authentication flaws live. This bug is different. The relevant surface is the dataplane, the interface carrying untrusted traffic, which is precisely the interface that tends to be internet-facing by design.
That makes population measurement more relevant than usual, and it makes version verification more important than usual. A device can match the fingerprint for years while its patch state changes silently.

A short operational sequence

Query the product fingerprint and record the timestamp and count. Query the CVE filter and record the result, including a zero. Probe two or three field variants to show sensitivity. Check internal inventory for affected branches. Rank devices by whether a dataplane faces untrusted networks. Then schedule upgrades against the fixed releases named in the record.
None of those steps requires a claim you cannot support, and together they produce a defensible answer to the only question that matters: which of our firewalls needs the patch first.