NetScaler zero-day: stopped by SSL decryption

In October 2026, Citrix confirmed two critical zero-day vulnerabilities in NetScaler ADC and NetScaler Gateway. Attackers were already exploiting them before a patch existed.

One of them, CVE-2026-88771, lets an unauthenticated attacker run arbitrary commands on the appliance. For a while, there was nothing to install. Every organization running an affected NetScaler was exposed.

Yet several of our customers running a vulnerable NetScaler were not compromised. Their firewall saw the exploit traffic coming and blocked it before it reached the appliance.

The difference was not a better product or a faster patch. It was a setting most firewalls already have, and that many organizations never switch on: SSL decryption.

We explained why in 2015

Eleven years ago we published a blog on this site called "In het land der encryptie is eenoog koning", roughly: in the land of encryption, the one-eyed man is king. HTTP/2 was just arriving, with encryption on by default. The argument was simple. What you can't see, you can't act on. Encryption takes that visibility away, and the right setup gives it back.

That argument has not aged a day. What has changed is the scale. In 2015 encryption was spreading. Today roughly 95% of all web traffic is encrypted, and attackers use the same encrypted channels as everyone else. Exploit code, command injection and malware all travel inside them.

The envelope and the letter

A firewall that does not decrypt sees who is talking to whom, but not what is being said. It reads the envelope, never the letter. Its threat prevention, intrusion prevention and malware inspection are looking at sealed envelopes.

SSL decryption lets the firewall briefly open the envelope, check the contents, seal it again and send it on.

The 2015 blog also made a distinction that still decides how much work this is:

Start with inbound. Then do outbound.

Want the technical background? Watch the Threat Talks episode on why SSL decryption matters.

Proof: 60 days before and after at Inwood Bank

Inwood Bank, a US bank and one of our customers, switched on inbound and outbound decryption on 1 February 2026. No incident forced their hand. Our GSOC had been making the case for inbound decryption as one of the strongest mitigations against zero-days, and the bank's IT team saw it the same way: low risk, high reward. "I had the suspicion that we weren't fully utilizing the Palo Altos without the decryption," Rob Miller, their Director of IT, told us. "Common sense said: we need to do this."

Later they asked a fair question: can you show what it actually changed? There was no standard report for that, so our GSOC built one, comparing the 60 days before go-live with the 60 days after.

Inbound, on Citrix, Inwood Bank's front door for remote access:

Blocked requests included probing of login pages and path traversal attempts such as /../../bin/sh. The firewall can only see those paths when the session is decrypted.

Critical inbound attacks blocked since go-live:

Outbound, for the bank's own employees:

No hidden threat found in 60 days. That is a result too: they now know, instead of hope.

Protection in the gap between exploit and patch

When the NetScaler attacks came, Inwood Bank was ready. The attacks were cut short. Without decryption, they would have gone unnoticed until a successful compromise took place.

To be clear: decryption does not replace patching. Our advice to patch did not change. What decryption bought these customers was protection during the window when there was nothing to install yet. Zero-days will keep coming, and every one of them opens that window again. That is also why patching was never the whole solution.

"It's not complex"

How much work was it for Inwood Bank? "The process was pretty easy, because we already had the certificates," Miller said. "We uploaded them to Palo Alto, made a decryption rule, and it just worked."

There was one catch, and it is worth knowing up front: include the full certificate chain, root and issuing CAs. Until the chain was complete, macOS devices with strict certificate checking failed to connect and an SSL Labs scan returned a lower grade. That is where ON2IT stepped in: we helped resolve it, the Macs connected again and the high grade came back. One lasting cost: when certificates rotate, you now update two devices instead of one.

Inwood Bank's IT team is seven people, looking after 250 employees. "We're not a dedicated security team," Miller said. "That's why we have ON2IT to help. If we're constantly putting out fires because our controls are not implemented correctly, that takes away time from getting other things done."

Inwood Bank runs MDR Prevent™, which means our GSOC manages their firewalls for them. In practice that covers:

• Keeping the security configuration in line with best practice, including the decryption policy and its exclusions.
• Checking the configuration every day with Policy Validator, and opening a case automatically when a high-risk rule or a missing security control appears.
• Following new CVEs and vendor developments, and taking the initiative on firmware upgrades.
• Keeping threat signatures and content databases up to date.
• Recording improvements that can't be made yet as Security Improvement Advisories, so nobody forgets them, not even after staff changes on either side.
• Assessing the risk of every change before it goes in, and carrying it out under strict change management.
• 24x7x365 access to the GSOC by email and phone.

For a seven-person IT team, that is the difference between knowing a control works and hoping it does.

Three questions for your IT team

Let us take care of it

Our GSOC routinely implements inbound and outbound SSL decryption for customers. Start with inbound: it is a low-risk change that typically takes two to four hours, with nothing to change on user devices, and it closes the blind spot the NetScaler attackers relied on. Outbound takes more preparation, with certificates on devices, privacy exceptions and compatibility testing, and we guide you through each step.

FAQ