Detecting Recon Activity for CVE-2026-3055 on NetScaler Gateways
Just saw the report from The Hacker News regarding CVE-2026-3055 (CVSS 9.3) impacting NetScaler ADC and Gateway. It's a memory overread vulnerability caused by insufficient input validation, which can lead to sensitive information leakage.
Defused Cyber and watchTowr are already reporting active reconnaissance. Given the severity and the fact that scanning is likely ramping up, we should be hunting for this in our logs immediately. While a full PoC isn't public (and we shouldn't be testing on production), the recon phase usually involves probing specific endpoints.
I've put together a quick bash snippet to help identify IPs that might be scanning for this vulnerability by looking for excessive requests to common NetScaler paths associated with SAML or OAuth configurations, which are often the target for input validation bugs:
#!/bin/bash
# grep for suspicious activity on /vpn or /oauth paths
LOG_FILE="/var/log/ns.log"
awk '{print $6, $7}' $LOG_FILE | grep -E '(/vpn/|/oauth/)' | sort | uniq -c | sort -nr | head -20
Keep an eye on your management interfaces too. Has anyone else started seeing an uptick in weird User-Agents hitting their gateways today? Curious what your detection thresholds look like for this kind of scanning behavior.
Good catch on the log hunting. I'm seeing a spike in requests targeting /oauth/idp/.well-known/openid-configuration coming from a few ASNs in Eastern Europe.
If you're using Sentinel or Splunk, here is a quick KQL query to isolate the scanners looking for configuration endpoints which might be tied to the recon phase:
CommonSecurityLog
| where RequestURL contains "/oauth/" or RequestURL contains "/vpn/"
| summarize count() by SourceIP, UserAgent
| where count_ > 50
We're blocking anything that doesn't match our known partner IPs at the firewall level for now.
Just finished patching our non-prod instances. The tricky part here is that since it's an info leak (memory overread), standard WAF signatures might be lagging on the detection side compared to an RCE.
Make sure you check if your NSIP (NetScaler IP) is exposed to the internet. The management interface shouldn't be reachable from outside the LAN. We forced a policy to drop all traffic from non-management subnets to the NSIP:
# Example nscli command to restrict NSIP access
add ns acl ALLOW_MGMT ALLOW -srcIP = 10.0.0.0/24 -destIP = -protocol TCP -destport 80 -portAction ALLOW
add ns acl DENY_ALL_MGMT DENY -destIP = -protocol TCP -portAction DENY
apply ns acls
Better safe than sorry until the patches are fully deployed.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access