Iran-linked cyber activity targets industrial systems, data leaks, and human vulnerabilities, with risk centred on access, exposure, and operational control


The headline story this week is the North Korean-linked attack on Axios, one of the most widely used Node.js libraries out there, pulling in over 100 million downloads a week.
This wasn’t sloppy. The attackers compromised the package and deployed a remote access Trojan across Linux, Mac, and Windows environments. That means once the malicious version was installed, they potentially had full access to production environments, including secrets and credentials.
The uncomfortable part is how invisible this kind of attack can be. Developers trust dependencies. Pipelines trust automation. And suddenly you’ve handed over the keys without realising it.
What to do:
Start by confirming whether any compromised Axios versions were deployed in your environment. If there’s any doubt, assume exposure. Rotate all credentials tied to affected systems. Then take a hard look at your dependency management and software supply chain controls. Trust is not a strategy.
There’s also a critical vulnerability in Citrix that allows unauthenticated attackers to send crafted requests to the SAML endpoint. No login required, which should already set off alarms.
From there, attackers can potentially access session information, including tokens tied to admin sessions. At that point, you’re looking at possible full appliance takeover.
This is another example of identity infrastructure becoming the attack surface. If session tokens are exposed, the attacker doesn’t need credentials. They just step in as someone who already has them.
What to do:
Check that you’ve applied the latest patches immediately. Then review audit logs for any unusual activity targeting the SAML endpoint. Look for reconnaissance patterns as well as exploitation attempts. If you’re only checking for confirmed breaches, you’re already behind.
On the breach front, Lloyds disclosed an issue during a deployment in March where a concurrency flaw exposed customer transaction data.
In simple terms, if a user refreshed the transactions page at the right moment, they could see data belonging to other users. Not exactly the kind of “feature” customers expect from a banking app.
There’s no advanced threat actor here. Just a failure to properly handle concurrency and caching under load. The kind of thing that gets missed until it’s very public and very uncomfortable.
Regulators don’t care whether it was a nation-state or a race condition. Data was exposed. That’s the only metric that matters.
What to do:
Revisit your testing strategy, especially around concurrency and caching behaviour. Peak load scenarios aren’t edge cases. They’re when your system is most likely to break in ways that matter. Validate that data isolation holds up under stress, not just in ideal conditions.
The common thread is control. Over what you run, who gets access, and how your systems behave under stress. Lose control in any one of those areas and attackers don’t need to force their way in. They just step into the gaps.
Tightening those gaps is still the difference between an incident and a headline.
We protect your on-premise/cloud/OT environments - 24x7x365