Attackers chained three Ivanti zero-days to gain root on *fully patched* VPN appliances

What happened

On 8 January 2025, Ivanti disclosed that attackers had chained three zero-day vulnerabilities in its Connect Secure VPN appliances to gain root access on fully patched systems ^[1]. The vulnerabilities—CVE-2025-0282, CVE-2025-0283 and CVE-2025-0284—worked together like a three-stage lock pick: the first got them in, the second raised their privileges and the third gave them full control.

The appliances were running version 22.7R2.5, the latest patch available at the time. That's the part that stings: organisations had done what they were supposed to do, and it wasn't enough.

Once inside, the attackers collected credentials, exfiltrated configuration data and set up persistence mechanisms that survived reboots ^[1]. They had the keys to the kingdom, and they kept them even when the front door was locked again.

Ivanti released emergency patches and urged customers to apply them immediately, reset all credentials and review logs for indicators of compromise ^[1]. The company also published forensic guidance to help organisations work out whether they had been hit.

The evidence question

When an attacker chains three exploits to gain root access, the question every CISO faces is: what did they do while they were in there?

Logs are the obvious place to look, but they're also the obvious place for an attacker to clean up. Someone with root access can edit, delete or replace log entries. By the time you notice the breach, the record of what happened may have been quietly rewritten.

That's the gap between having logs and being able to trust them. It's like finding out someone broke into your house and then wondering whether the security camera footage has been edited. The footage exists, but can you show it hasn't been tampered with?

Under DORA's technical standard on ICT risk management, financial firms must protect logs against tampering, deletion and unauthorised access ^[3]. The Cybersecurity Act, which implements NIS2 in Sweden, requires essential and important entities to report significant incidents: an early warning within 24 hours, an incident notification within 72 hours and a final report within a month ^[4]. The clock starts when you became aware of the incident, not when it suits you.

Both rules assume you have logs you can rely on. The question is how you show a supervisor, an auditor or an insurer that the logs you're handing over are the ones written at the time, not a tidied-up version from afterwards.

Why this one matters

Zero-days are rare but not unheard of. What makes this case interesting is that the exploit chain worked on fully patched systems. Organisations that had followed the vendor's guidance, applied updates promptly and kept their systems current were still vulnerable.

That puts a dent in the idea that patching is a silver bullet. It's necessary, obviously, but it isn't sufficient when attackers find a chain of flaws before the vendor does.

It also highlights the detection problem. If an attacker has root access, they control what the system reports about itself. Standard monitoring tools may not catch them, because those tools rely on the same logs the attacker can now edit.

For financial firms under DORA, and for essential entities under the Cybersecurity Act, that creates a reporting headache. You have to tell the supervisor what happened, but if the logs have been altered, you may not know.

How a digital witness helps here

A digital witness doesn't stop an attacker from getting in. It doesn't patch vulnerabilities or detect exploits. What it does is make it harder for an attacker to hide what they did.

In this case, the thing to seal is log segments as they are written, every few minutes. The log itself stays on your systems. The witness takes a fingerprint of each segment and seals it on a chain where any later change would show, even one made by someone with root access.

If an attacker edits a log entry to cover their tracks, the fingerprint won't match when you check it later. That doesn't tell you exactly what they changed, but it tells you the log has been altered, which is often enough to know you need to dig deeper.

Anyone you share the log with—internal audit, a supervisor, an incident response team—can check the fingerprint themselves. You don't have to ask them to trust that you haven't edited it, because the check doesn't rely on you.

What it doesn't do is replace access control, monitoring or backups. It's one piece of the puzzle, not the whole thing. It also doesn't prove the log is complete; an attacker with root access could stop logging altogether. But it does make quiet edits detectable, which changes the game when someone has to explain what happened during a breach.

Your system sends a fingerprint of each log segment, not the segment itself, to WitniumChain through the REST API, the SDK or the MCP server, and gets a witness ID back. To check, anyone you share the log with calculates the fingerprint again and compares it with the sealed one. The first 2,000 witnesses a month are free.

How it would work

1. Every few minutes, your logging system closes a segment and sends its fingerprint to the witness.
2. The witness seals the fingerprint and returns an ID.
3. When the breach is discovered, you check each segment's fingerprint against its sealed version. A match means that segment hasn't changed; a mismatch means it has.

What this means for you

If you run VPN appliances, apply Ivanti's emergency patches now, reset credentials and review your logs for the indicators of compromise the company has published ^[1].

More broadly, ask yourself: if an attacker gained root access to one of our systems tonight, could we show a supervisor what our logs said tomorrow, in a way that would hold up if someone questioned them?

Patching matters. Monitoring matters. But when an exploit chain works on fully patched systems, detection and evidence become the last line of defence. Logs that can be quietly edited are diaries; logs that can be checked are evidence.

Under DORA and the Cybersecurity Act, you're already required to keep logs and report incidents on tight deadlines. The next question is whether the logs you're reporting on can be trusted, by you and by the people you're reporting to.

What to watch

The Cyber Resilience Act, which applies to products with digital elements placed on the EU market, requires manufacturers to report actively exploited vulnerabilities within 24 hours of becoming aware of them ^[2]. For software and hardware vendors, that's a short window, and it starts the moment you know, not the moment it's convenient.

Ivanti's disclosure came on 8 January 2025, the same day it released patches ^[1]. Whether that timing reflects when the company became aware of the exploits, or when it had patches ready, isn't public. Either way, the clock has started ticking for vendors across the sector.

Sources

1. Attackers chained three Ivanti zero-days to gain root on fully patched VPN appliances, Help Net Security, 14 October 2026, https://www.helpnetsecurity.com/2026/10/14/ivanti-zero-days-gain-root-patched-vpn-appliances/
2. Regulation (EU) 2024/2847 on cybersecurity requirements for products with digital elements (Cyber Resilience Act), European Commission, https://eur-lex.europa.eu/eli/reg/2024/2847/oj
3. Commission Delegated Regulation (EU) 2024/1774, Article 12(2)(d), European Commission, https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj
4. Cybersäkerhetslagen (2025:1506), Riksdagen, https://data.riksdagen.se/dokument/sfs-2025-1506.html