The setup

HoneyLens runs four sensors. One of them — call it sensor3 — sits on a public OVH IPv4 with the captive-portal surface (TCP/4443, 6080, 6082) exposed deliberately. The other two reachable in this window — sensor1 and the LAB — sit on internal networks; their captive-portal surface is bound but not internet-routable. The fourth (sensor2, in a partner office DC) was offline for unrelated reasons through the entire hunt window. So in practice, this writeup covers what one public-internet honeypot saw between 2026-04-09 and 2026-05-08, with two internal sensors as control surfaces.

If you came here expecting CL-STA-1132 IOCs from our infrastructure, you can stop reading: we didn't see them, and we didn't expect to. State-affiliated clusters with the operational discipline that Palo Alto Networks attributed to this actor — nginx-worker shellcode injection, crash-log clean-up, AD enumeration, EarthWorm and ReverseSocks5 deployment — do not waste burn-time on three honeypots. They hit the real PA firewalls they identified in advance, log into them quietly during business hours, leave, and erase the trace. A honeypot's job during a campaign like this isn't to catch the apex actor. It is to catch the tail: the opportunistic re-runs, the script-kiddie bouncing the public PoC at every captive portal Shodan can find, the half-built scanners that leak unmistakable strings, and the operators who confuse signal for noise by routing through residential VPN exit nodes. That is where a wide-cast detection net pays off, and that is what this writeup is about.

What the public PoCs look like (and why they don't actually work)

Within hours of the CVE being published on 2026-05-06, two PoCs landed on public GitHub:

• qassam-315/PAN-OS-User-ID-Buffer-Overflow-PoC — a 122-line Python script that opens a TCP socket to --target:6082, sends an HTTP POST /php/login.php with Content-Length: 2248, body = 2,048×0x41 ('A') padding + a placeholder return address 0xdeadbeef + 64×0x90 NOP sled + 128×0xcc (INT3 — debugger breakpoint, not shellcode). On any timeout or empty response, the script prints EXPLOIT SUCCESS (TIMEOUT).
• p3Nt3st3r-sTAr/CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300-POC — same template, but the INT3 sled is replaced with real msfvenom linux/x64/shell_reverse_tcp shellcode (~95 bytes) and a --lhost/--lport parameter pair. Content-Length bumps to 2,279. NOP sled grows to 128.

Both have the same fundamental issues against a real Palo Alto firewall: they target /php/login.php (web management UI) instead of /php/uid.php (where CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300 actually lives, on the User-ID Authentication Portal — a.k.a. Captive Portal); they ship plaintext HTTP at TCP/6082, which is the HTTPS captive-portal redirect port (the TLS handshake fails before any HTTP parser sees the body); and they declare Content-Type: application/x-www-form-urlencoded while sending a body that is mostly raw binary, which the PAN-OS request parser would reject before any vulnerable code path is reached. The placeholder 0xdeadbeef return address ensures that even on a hypothetical exploitable build, no actual code execution would occur — there is no information leak, no ROP gadget, no real RIP target.

None of which matters. Within 6 hours of the qassam-315 repo landing, sensor3 took its first byte-perfect copy.

What we actually saw

Two confirmed exploit attempts (qassam-315 PoC, byte-perfect)

Both fired the script unmodified at sensor3. Different actors, different countries, ~21 hours apart:

Both IPs sent the same 2,248-byte payload — 2,048×0x41 + 0xdeadbeef + NOP sled + INT3 sled. The first hit came on 6082 (the script's default), the second on 4443 (the management UI port). Source port 12414 (the second SYN) and 7178 respectively — the actor #2 looks like they ran from inside a NAT or proxy chain that compressed the ephemeral range, but neither IP touched anything else in the window.

Honeypot interception: on a real PAN-OS firewall, neither attempt could exploit anything. On our honeypot, also nothing — there is no real PAN-OS code path behind /php/login.php for the BoF to land on. The honeypot accepts the request, records the bytes, returns a stock JSON success response (so the script prints its bogus success message and goes home), and adds the IP to the hunting list. That last step matters: actor #2 surfaced retroactively only because we widened the time window during a backfill — chained delta queries had walked right past it. Lesson written into our process: delta queries should overlap their predecessor's cutoff by at least 6 hours.

One CVE-aware enumeration scanner with a give-away User-Agent

On 2026-05-06 13:35-13:36 — about 5 hours after the CVE was published, and 5 hours after the first qassam firing — sensor3 took 47 GET probes from 42[.]116[.]36[.]252 (AS18403 FPT Telecom, Vietnam) in a single 30-second burst. They hit /php/login.php, /php/uid.php, /portal/, /auth/, /guest/, and (sic) /captivedportal/. Every single request advertised the User-Agent string:

Mozilla/5.0 (CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300-Checker)

This is the good kind of operational mistake. Whoever wrote this scanner literally named their tool after the CVE in the UA. There is no benign product in the world that calls itself a CVE-checker — that string in an HTTP request is not ambiguous. We added a generic detection pattern Mozilla/.*\(CVE-\d{4}-\d{4,5}-Checker\) at the same time the IP went on the hunting list, on the assumption that the same template will get reused for the next CVE this actor cares about.

The /captivedportal/ typo is also informative: the scanner-writer was operating from memory, not from documentation. They knew there was a Captive Portal somewhere on PAN-OS and built a target list. They did not, as the public PoCs also did not, look up that the actual vulnerable endpoint is /php/uid.php.

Four UA-rotation evasion campaigns

Between 2026-05-07 and 2026-05-08 we observed four distinct campaigns whose calling card is the same: GETs to /php/login.php or /php/uid.php from a single IP, cycling through a UA pool that includes obviously-impossible browser versions. The point is to defeat naïve UA-based filters that allow-list "modern Chrome / Firefox" but don't sanity-check the version field.

None of these progressed to oversize POSTs, shellcode-shape bodies, or anything else exploit-flavoured. They are all in enumeration mode — building target lists. But they are not Censys / Shodan / Driftnet / Modat: none of those research scanners would ever advertise Firefox 3.6.7. These are bespoke tools built specifically for the CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300 wave by operators who decided to invest in evasion before they invest in actually exploiting anything. The two-IP clusters (Hosteons SG, DTAG, China Unicom) are a notable signal — same campaign distributed across multiple residential / SMB connections to bypass per-IP rate limits.

One first cross-sensor scanner

On 2026-05-08 between 01:20 and 03:17 (under two hours), 130[.]94[.]90[.]164 (AS154177 LIGHT NODE LIMITED HK) hit two of our sensors with the same Chrome 92 + Edg 92 UA. This is the first IP we've seen post-disclosure that's running a sweeper against multiple distinct targets in our address space inside a tight window. They didn't fire the exploit; the activity was GET-only enumeration. But the cross-sensor footprint upgrades them from "scanner" to "scanner with a target list", which is the difference between someone running ProjectDiscovery against the entire IPv4 space and someone running a tool against a curated set.

Heavy mass scanners (volume but no exploit shape)

For completeness — these IPs hit sensor3 with five-figure event counts during the four-week window but never with anything exploit-flavoured. All GET-only fingerprinting / enumeration:

• 172[.]105[.]102[.]42 — AS63949 Akamai/Linode — 4,709 hits in 14 days, with single-day bursts of 2,041 (2026-04-26), 1,566 (04-17), 1,102 (04-30). Cloud-hosted, persistent, broad-spectrum.
• 44[.]220[.]185[.]164 / 44[.]220[.]185[.]28 / 98[.]80[.]4[.]69 — AS14618 AWS — single-day bursts of 1,862 (04-12), 1,313 (04-25), 1,338 (05-05) respectively. Three different /24s on the same ASN; looks like a commercial scanning service running on AWS spot instances.
• 212[.]102[.]40[.]218 — 594 events spread across 2026-04-13 → 05-07; persistent low-rate recon.

None of these is the apex actor in this CVE. They are the background of an internet-scanning ecosystem that runs continuously regardless of which CVE is current. The interesting thing for our purposes is what they didn't do: with the captive-portal surface available, none of them probed the Captive Portal endpoint specifically (/php/uid.php on 6082) until after 2026-05-06. They knew about the management UI surface (/php/login.php on 4443) for years; the captive-portal surface only became interesting once the CVE was public.

Detection coverage we ended up with

The detection rule set deployed on 2026-05-06 (one hour after the first qassam firing, which is uncomfortable but worth being honest about) and refined through 2026-05-08:

• 3 attack-classifier rules: paloalto_cve_2026_0300_qassam_poc (forensic ID for the qassam variant), paloalto_captive_portal_long_a_run (≥256 'A' run on captive-portal POSTs — variant-agnostic), paloalto_captive_portal_oversize_post (CL ≥ 2000 — generic).
• 5 Suricata rules in the dedicated 9026300-9026309 SID range: qassam fingerprint with NOP+INT3 hex match, generic A-run, plaintext HTTP on TLS port 6082 (PoC tell), oversize POST, and /bin/sh\0 shellcode-marker match in any captive-portal POST body (catches the p3Nt3st3r-sTAr variant and any future ROP-based body that drops the 'A' padding entirely).
• Capture-path widening: kernel-side eBPF payload sample 16 → 256 bytes (per-CPU scratch map, single bulk bpf_skb_load_bytes), userspace ingest cap 4 KB → 16 KB, and the honeypot's POST handlers (/php/login.php, /php/uid.php, /global-protect/login.esp, /unauth/*, createRemoteAppwebSession.php) now capture raw request bodies as base64 with an 8 KB cap. The last item matters because TLS-protected captive-portal traffic terminates at the honeypot, and the eBPF/PCAP path sees only encrypted bytes for those connections — without honeypot-side body capture, the binary tail of any future BoF lands nowhere queryable.

Coverage matrix against the two known PoCs: 5 of 7 rules trigger on each, with the misses being intentional (the qassam-specific rules don't trigger on p3Nt3st3r-sTAr because the Content-Length is different and the INT3 sled is replaced by shellcode — those are diagnostic rules, meant to forensically identify the qassam variant, not catch all variants).

What this hunt taught us

Three operational lessons that generalise beyond this CVE:

1. Wide-cast generic rules earn their keep. The qassam-specific Suricata rule (sid 9026300) triggered exactly twice — on the two firings already documented above. The generic A-run rule (sid 9026301) and the oversize-POST rule (sid 9026303) would trigger on those two and on the p3Nt3st3r-sTAr variant and on a hypothetical custom-padding-byte variant and on a future copy-paste with different Content-Length. The diagnostic-grade rules are useful for IDing which PoC ran. The variant-agnostic rules are what you'll still be relying on six months from now.

2. The implausible-version UA is a hard signature. Our four UA-rotation campaigns all leak some impossible browser version (Firefox 3.6.7, Firefox 7.0, Firefox 150.0). A regex that catches Firefox/[12]?[0-9]\b on captive-portal endpoints — i.e. Firefox versions ≤ 30 in 2026 — has essentially zero false-positive risk and immediately segments these scanners away from the legitimate-recon noise. Same logic applies to Chrome 49 and Edge 92.

3. Process discipline beats query complexity. The second qassam firing was missed by three consecutive delta sweeps that all chained their cutoffs cleanly — a row landing at 05:03:30 was outside the 16:00 cutoff (the next sweep started at 09:07) so it fell through the seam. The retroactive backfill caught it on a wider window. The fix is not better queries, it is better hygiene: every delta should overlap its predecessor's cutoff by ~6 hours, and significant findings should always trigger a wider re-check.

What we are still watching for

The vendor patches drop 2026-05-13. After that, we expect:

• The actual exploit details to surface (which form field, what the offending parser does wrong, how to land RIP control on a real PA build). The qassam-specific rules will get retired and replaced with byte-precise rules against the actual offending parameter. The generic rules stay.
• A second wave of public PoCs from operators who waited for the patch diff to know what to actually target. Those will probably hit /php/uid.php properly and use TLS, which means our eBPF/PCAP path will see only encrypted bytes — the honeypot's raw-body capture (deployed 2026-05-07) becomes the only place that tail of the body lives.
• The tail of opportunism continuing — small actors copy-pasting the second-wave PoCs, more UA-rotation evasion campaigns, more cross-sensor sweepers building target lists. We expect the (CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300-Checker) UA pattern to be cloned for the next high-profile vendor advisory; that detection has been generalised to (CVE-NNNN-NNNN-Checker).

And no, we still don't expect to see CL-STA-1132 itself. If we do, something else has gone wrong.

IOC summary

Update — 2026-05-10 (T+4 days post-disclosure)

Three substantive deltas in the last 12 hours, none of them an exploit attempt.

1. The partner-office sensor (sensor2) is back on the captive-portal surface. sensor2 had gone dark on 2026-05-09 after a NIC-driver hang on its host; the diagnosis at the time pinned it on an upstream-firewall DNAT issue. That diagnosis was wrong. The actual root cause was on sensor2 itself: its persistent firewalld public zone was missing 4443/6080/6081/6082/tcp (and many other honeypot ports), so external SYNs were silently dropped before they reached the listening socket. After yesterday's reboot, firewalld came up with the persistent zone config — which simply never had those ports added in the first place. The ports were re-opened overnight; sensor2 has logged 35 captive-portal events from 9 unique src IPs in the 12 h since the fix landed. First post-fix exploit-coverage on that sensor since 2026-05-09 11:44.

2. The fake-Firefox-150 cluster grew to four IPs across three ASNs and pivoted off the captive-portal surface entirely. The new member 77[.]243[.]184[.]190 (AS9009 M247 Europe SRL, Zurich CH) hit sensor3's Kubernetes honeypot endpoints (TCP/6443 + 30000) — not /php/login.php. UA across all 7 hits was the same impossible Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:150.0) Gecko/20100101 Firefox/150.0 string the prior cluster members used. The cluster now: DTAG (DE) × 2, Interserver (US) × 1, M247 (CH) × 1. The pivot off captive-portal onto k8s suggests the fake-Firefox-150 UA template has been forked into multiple campaigns by the same operator group — it is not necessarily a PAN-OS-specific signature anymore. Still worth tracking as a UA-evasion fingerprint, but treating it as a PAN-OS IOC alone would now miss the bulk of its use.

3. The 45[.]82[.]78[.]x / 45[.]131[.]155[.]x cluster from yesterday's evening delta returned overnight, escalated. What was three IPs hitting sensor3 on port 6082 only is now five IPs across two /24s, hitting both sensor3 (port 6082, yesterday) and sensor1 (port 4443, today), all five mapping to AS212512 Detai Prosperous Technologies Limited (registered SG, geo-distributed across SG and US-NYC per ipinfo). One IP — 45[.]82[.]78[.]109 — sustained 36 GETs of /php/login.php on sensor1 over a 1-hour burst (08:08–09:08 CEST). The cross-/24 burst at 08:08 (four IPs in 4 seconds) is a target-list-driven sweep with rate distributed across the operator's IP pool to evade per-IP limits. Still no exploit shape — every hit is GET-only with a plausible-looking Chrome 135 / OPR 120 UA. But the cross-sensor + cross-/24 + sustained-burst progression is enough to promote them from "watch-only" to hunting-list MEDIUM with tag as212512-detai-prosperous. Worth watching for progression to oversize-POST or to /php/uid.php (the actual CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300 surface that no public PoC has hit yet).

The detection grid stayed silent on real traffic. Zero qassam-byte-perfect (CL=2248), zero p3Nt3st3r-sTAr (CL=2279), zero 165[.]22[.]26[.]204-style CL=2120 third-variant, zero /bin/sh\0 shellcode markers, zero msfvenom prologue patterns, zero (CVE-2026-0300' target='_blank' style='color:#f87171;text-decoration:none;font-weight:600'>CVE-2026-0300-Checker) UA, zero paloalto_* AI-classifier hits, zero Suricata SIDs 9026300-9026310 firings on real traffic. The synthetic verification test of 2026-05-09 14:26 remains the only HONEYLENS-rule entry in sensor3's DB. The campaign tail since disclosure has not produced a body that would trigger any of our rules. The next inflection point is the vendor patch on 2026-05-13, which we expect will give the operator pool the precise vulnerable form-field name to target — at which point the qassam-specific rule retires and gets replaced by a byte-precise rule against the actual CVE surface.