Policy Drift on Application Delivery Controllers: The Setting Behind CVE-2026-88774

Application delivery controllers accumulate configuration the way coastlines accumulate sediment. A rule is added for a migration, a redirect for a campaign, an access restriction for a contractor project. Years later a bulletin arrives for which the affected configuration is exactly that sediment, and nobody can reconstruct what it was for.

The specific case

CVE-2026-88774 affects Citrix NetScaler ADC and NetScaler Gateway, scored 7.0, and is described by NCSC-NL as the incorrect use of HTTP URL-based policy expressions allowing a feature policy to be bypassed. The advisory scopes the issue to appliances where such expressions are configured, which makes the vulnerable condition a property of the estate's history rather than of the product version alone.

How drift produces this condition

Four mechanisms reliably produce unexplained policy expressions on an ADC.
Cloning. A production appliance is replicated from a build that carried policies for a decommissioned application. The virtual server may be gone; the expression remains bound to something.
Copy-paste engineering. An expression that works on one virtual server is reused on another where the URL structure differs. It is syntactically valid, bound correctly, and does not match what the author intended.
Temporary controls that stayed. An access restriction added during an incident, a migration or a vendor engagement is left in place because removing it requires confidence that nothing depends on it.
Vendor and partner handovers. Managed service transitions often lose the rationale for configuration, and the new operator inherits the rules without the reasons.

Why this matters more than usual here

Most vulnerabilities are indifferent to configuration history. This one is defined by it. An organisation cannot answer "are we affected" by looking at a version list; it has to answer "do we have this class of expression, and does it enforce something we care about".
That is an uncomfortable question because the honest answer is often "we think so, but the person who wrote it left". The good news is that the question has a finite scope. The affected class is narrow — expressions that reference URL components and the policies that consume them — and a configuration export answers it directly.

Building the register

The register does not need to be sophisticated. For each expression: the text, the policy name and type, the virtual server it binds to, the intended effect, and whether an external client exercises that effect.
The last field is what separates a list from a priority. An expression on an internal-only virtual server carries different weight from one on the internet-facing path that decides whether a request reaches a published application.
Where the intended effect cannot be established, mark it as unknown rather than guessing. Unknown is a defensible state; an invented rationale is not.

Making the register survive

Two practices keep this work from decaying immediately. Bind each expression to an owner, even if the owner is a team rather than a person. And attach a review date to expressions that were added for a temporary purpose, so their persistence becomes a decision rather than a default.
Neither practice is specific to CVE-2026-88774. Both were needed before the bulletin arrived, and both will be needed when the next one does.

Closing out

The remediation for this bulletin is the vendor upgrade in CTX697096, covering all eight vulnerabilities including the two that are actively exploited. The configuration work is what turns that upgrade into verified control rather than a version change. For an estate where policy has drifted, the register is the deliverable that outlives the incident.

References

• Citrix security bulletin CTX697096
• NCSC-NL advisory NCSC-2026-0394
• CERT-FR advisory CERTFR-2026-AVI-1235
• CISA alert on actively exploited NetScaler vulnerabilities, 27 September 2026
• CERT-In vulnerability note CIVN-2026-0479