In early October, Citrix warned of active exploitation of a new security flaw in NetScaler. Attackers were already using it before many organisations had the chance to update. Among those affected: the Dutch national government and several Finnish organisations. NetScaler isn’t some obscure piece of software. It’s exactly the kind of system companies use to let employees reach internal systems while working from home or on the road.
For many business owners, this reads like news about someone else’s company, somewhere else. But if your organisation enables remote work through a similar gateway, the question that actually matters is concrete: do you know whether this affects you, and how quickly could you find out.
What’s actually happening
NetScaler acts as the front door between the internet and the systems inside a company. Employees log in through it to reach their work environment from another location. Precisely because this kind of system needs to be reachable from outside to be useful, it’s also the first place attackers look.
Citrix reports that the new flaw is already being actively exploited against organisations that haven’t yet applied the update. That’s a different situation from a vulnerability that could theoretically be exploited. Here, the exploitation is already happening while many administrators are still working out whether their system is affected.
Why this is more than just another patch
This isn’t the first warning this year about an internet-facing system. We’ve written before about similar situations involving other vendors. The pattern is always the same: a vendor reports active exploitation, and companies have mere hours to figure out whether they run the affected system, which version, and who’s responsible for updating it.
That scramble is the real problem. Not the flaw itself, since flaws are an inevitable part of software that keeps evolving. The problem is that many companies start from zero every time a new warning appears, trying to work out whether they’re exposed. That takes time, and time is exactly what’s missing once a flaw is already being actively exploited.
Visibility before you can respond
We believe you can’t set policy on something you can’t see. That starts with clear answers to a few questions. Which of your systems are reachable from the internet? Which versions are running, and when were they last checked? Who’s responsible for updating them, and how quickly does that actually happen in practice?
Many companies assume they have this visibility, but it often lives in the heads of a few people, in outdated documentation, or with a vendor who set it up once and moved on. That’s not structural visibility, that’s guesswork with a reassuring feeling attached. The difference only becomes visible at the moment it matters: when a vendor issues a warning and you need to know within a day whether you’re exposed.
Policy comes before technology
Once the visibility is there, the next step follows naturally. Not immediately another technical measure, but agreements. Who is allowed external access to which systems, and under what conditions? What happens by default once a vendor issues a critical warning: who gets informed, within what timeframe does a patch get applied, and who makes that call?
This also means bringing people along before you make something mandatory. If remote work temporarily works differently because of an update, it lands better when employees understand why, rather than finding a locked door with no explanation.
What you can do this week
Start with a simple inventory of everything reachable from the internet: VPN solutions, access gateways like NetScaler, firewalls, and similar systems. Record which version each system runs and when it was last updated. Then agree who is responsible for tracking vendor warnings, and within what timeframe a critical warning leads to action.
This isn’t a one-off task you check off a list. It’s the foundation that means the next time a vendor issues a warning, you know where you stand within an hour instead of within a week.
A few questions we’re often asked
We don’t use NetScaler, do we still need to do anything?
If you don’t run NetScaler, this specific flaw doesn’t apply to you. The underlying issue does: any company with internet-facing systems will run into this kind of warning eventually, regardless of vendor. The visibility we describe here applies to any system reachable from the internet, not just Citrix products.
How do I know if our system has the vulnerable version?
That requires two things: knowing exactly which version is actually running, and comparing that against what the vendor lists as vulnerable. Many companies can’t answer the first part with certainty, because nobody structurally tracks which versions run where. That’s exactly the visibility this article is about.
Doesn’t our ICT provider handle this automatically?
Sometimes, but usually only for systems explicitly covered in a management contract. Access gateways that were set up separately at some point often fall outside that scope. It’s worth asking explicitly rather than assuming it’s covered.
How often should I update this overview?
A fixed overview goes stale the moment new systems appear or old ones disappear. Treat it as an ongoing process with a clear owner, not a document you create once and then set aside.
Want to know what your business has exposed to the internet? We can map it out for you and help you keep structural visibility, so the next flaw doesn’t mean starting from zero again.
