CVE-2024-40711 – Immediate actions for Veeam Backup & Replication

What is CVE-2024-40711 and who needs to read this?

If your organisation runs Veeam Backup & Replication, a critical flaw identified as CVE-2024-40711 is now publicly known. The vulnerability carries a CVSS score of 9.8, placing it in the highest risk tier. It allows an unauthenticated attacker to execute arbitrary code on the backup server. The United States Cybersecurity and Infrastructure Security Agency (CISA) has listed it as a known‑exploited vulnerability and reports that ransomware groups have already weaponised it. If you rely on Veeam for protecting production data, you should treat this as an emergency.

For the wider picture, our Known Exploited Vulnerabilities tracker lists every flaw CISA has confirmed under active attack.

This page skips the fluff. It tells you exactly what the bug does, whether your deployment is at risk, and the precise commands you need to run to protect yourself.

Technical background

Vulnerability class

The flaw belongs to the class of insecure deserialization bugs. In simple terms, Veeam takes data that arrives from a client, turns that data back into an object, and then works with the object. If the incoming data is crafted in a particular way, the deserialization routine can be tricked into creating objects that run code on the server. Because the routine does not require any authentication, anyone on the network – or even the internet if the service is exposed – can send the malicious payload.

The NVD description is brief, but the class of the bug tells us a lot. Deserialization attacks are powerful because they bypass most traditional input validation. The attacker does not need to find a buffer overflow or an SQL injection; they simply feed the application a specially‑formed byte stream that the runtime interprets as executable logic.

Specific attack path

Veeam exposes a management endpoint that accepts configuration objects over HTTP/HTTPS. The vulnerable code path reads the object, deserialises it with the.NET binary formatter, and then proceeds to apply the configuration. The binary formatter is known to be unsafe when handling untrusted data. By sending a payload that contains a malicious.NET type, the attacker can cause the server to instantiate that type and run its constructor, which can launch any command the attacker chooses.

Because the endpoint does not enforce authentication before deserialising, the attacker does not need valid credentials. The exploit can be launched from any host that can reach the service – typically the internal network, but also from the internet if the management port is exposed.

The exploit chain has been confirmed in the wild. CISA’s catalog records its use in ransomware campaigns, meaning that attackers are already using it to encrypt backups and demand payment.

Am I affected?

Only installations of Veeam Backup & Replication that fall within a specific range of releases are vulnerable. The exact range is listed in the table below. If your installation appears in that range, you are at risk.

Do not rely on the version number you see in the UI alone – the UI sometimes shows a short build identifier that does not map directly to the vulnerable range. The safest way to know is to compare the exact build string reported by the product with the entries in the table.

Remember: the vulnerability is not limited to a particular operating system or deployment size. Any server that runs the affected Veeam service is exposed.

How to check your environment

Run one of the following commands on the Veeam server. The command prints the exact build identifier that Veeam reports at start‑up. Compare the output with the table below.

• Get-Item "C:\Program Files\Veeam\Backup\Backup.exe" | Select-Object -ExpandProperty VersionInfo | Select-Object -ExpandProperty FileVersion – PowerShell on Windows.
• /opt/veeam/backup/Backup --version – Linux installations, if you use the Linux agent.
• cat /etc/veeam/veeam.conf | grep "Build=" – another quick way to locate the build string in the config file.

If the output matches any entry in the table, you are running a vulnerable version. If you cannot locate the version string, contact your Veeam administrator or consult the product logs – they always contain a line similar to “Veeam Backup & Replication version …”.

Mitigation and remediation

The vendor has released a patched build that resolves the deserialization flaw. The fix removes the unsafe binary formatter and replaces it with a safe, custom deserializer that validates input before object creation. The patch is available through the normal Veeam update channel.

To remediate, follow these steps:

• Back up your current configuration. Export the Veeam job definitions and credentials to a safe location.
• Download the latest release for your branch. Use the Veeam console or the command‑line updater to pull the newest package. The vendor’s release notes explicitly state that the deserialization issue is addressed.
• Install the update. On Windows, run the installer and accept the default options. On Linux, use the package manager command provided by Veeam (for example, dpkg -i veeam‑backup‑replication_latest.deb).
• Restart the Veeam services. A simple Restart-Service -Name VeeamBackup in PowerShell or systemctl restart veeam on Linux will do.
• Verify the version. Re‑run the version‑checking command from the previous section. The output should now show a build that is not listed in the vulnerable range.

After the upgrade, run a quick test to ensure the management endpoint is still reachable but no longer accepts unauthenticated deserialization payloads. Veeam’s test suite includes a “health check” that you can invoke with veeam‑healthcheck –run. The report will confirm that the unsafe code path is disabled.

Because the vulnerability is critical, CISA advises you to apply the fix as soon as possible. Delaying the upgrade leaves the backup server open to ransomware that can encrypt your recovery points and cripple your business.

If a patch is not yet available for your environment

In rare cases you may be running a custom build or a version that cannot be upgraded immediately. The vendor recommends the following temporary mitigations until you can apply the official fix:

• Restrict network access. Use a firewall to allow only trusted IP ranges to reach the Veeam management port (default 9392/TCP). Block any traffic from the internet or from untrusted subnets.
• Enable transport‑level authentication. Turn on mutual TLS for the management endpoint. This forces a client certificate check before any payload is processed, effectively preventing unauthenticated callers.
• Disable the vulnerable endpoint. If you do not use the remote management API, you can stop the service that listens on the port. On Windows, run Stop-Service -Name VeeamBackupService and set the startup type to manual. On Linux, use systemctl disable veeam‑service.
• Monitor for exploitation attempts. Enable logging for the management API and set up an alert that triggers on any request that contains the string “BinaryFormatter”. A sudden spike is a strong indicator of an active attack.

These mitigations reduce the attack surface but do not eliminate the flaw. They are meant to buy you time while you arrange for the official update.

Final checklist

• Confirm your Veeam build against the table below.
• If vulnerable, download and install the patched release for your branch.
• Restart services and verify the new build string.
• If you cannot patch immediately, apply network restrictions and enable mutual TLS.
• Log and monitor for any suspicious activity on the management port.

Time is the most valuable resource in a ransomware scenario. The longer a vulnerable server stays online, the greater the chance that an attacker will strike. Follow the steps above, and you will dramatically lower the risk to your backups and, by extension, to the whole organisation.

For reference, the table below lists the affected range and the point at which the fix was introduced.

Affected versions

Straight from the NVD record for CVE-2024-40711. If your build is inside one of these ranges, treat it as vulnerable.

Product	Affected range	Fixed in
veeam_backup_\&_replication	12.0.0.1420 up to 12.2.0.334	12.2.0.334