Threats

A common mechanism used to support cybersecurity controls is blocking things from happening. This includes firewalls, which block unwanted network traffic; traditional antivirus or anti-malware products, which block known malicious files from executing; email security gateways, which block phishing attempts and malicious attachments; and web content filters, which block access to known dangerous websites.

However, a common tenet of cybersecurity is that, rather than creating a list of things you don't want to happen, it's more robust to create a list of things you will allow to happen and only allow these specific things to happen. If you are not completely familiar with the difference between accept-listing (or whitelisting) or deny-listing (aka blacklisting), then you can read our more detailed explanation here.

In this article, we will examine a specific case that popped up recently when a software embedded flaw occurred due to deny-listing.

When Deny-Lists Fail: Remote Code Execution in Veeam Backup and Restoration

In early 2025, a critical vulnerability (CVE-2025-23120) was identified in Veeam Backup & Replication, highlighting the shortcomings of deny-list-based security mechanisms. This flaw, discovered by watchTowr Labs, allowed any authenticated domain user to execute arbitrary code on domain-joined Veeam backup servers, posing a significant threat to enterprise environments.

In this instance, the .NET DataSet class, known for its deserialization capabilities, was used to bypass a deny-list and execute malicious code. The deny-list was implemented within Veeam’s internal deserialization logic in their .NET-based components, specifically attempting to prevent known dangerous classes from being deserialized during the XML-based deserialization process. Thistdeny-list of .NET object types was found to be insecure and exploitable for remote code execution (RCE) attacks by instantiating unsafe objects.

Although a fully weaponized public exploit has not yet been released, proof-of-concept (PoC) details demonstrating the vulnerability are available from watchTowr’s research. As of this writing, there is no confirmed evidence of widespread active exploitation in the wild, but given the nature of the flaw and its potential impact, exploitation is considered plausible—especially in environments where unpatched, domain-joined Veeam servers are exposed. Backups are in general, a highly valuable target for ransomware threat actors, and Veeam CVEs have a higher than average conversion rate - flaws in Veeam products are often developed into malware and exploited by hackers in ransomware attacks.

Accept- or Deny-List? Best Practices Are Case by Case

While accept-listing provides a better security outcome, the need for flexibility often makes whitelisting infeasible, forcing defenders to fall back on to deny-listing. For example, in large enterprise environments where thousands of third-party applications are used, it’s nearly impossible to pre-approve every valid file or behavior in advance. Similarly, in dynamic development environments or cloud-native applications, where containers and microservices are constantly spun up or modified, defining a comprehensive accept-list becomes impractical. 

On the flip side, deny-lists require continuous updates and cannot account for all potential malicious classes, especially in complex software ecosystems. In contrast, accept-lists (whitelists) offer a more robust defense by explicitly defining permissible classes for deserialization, thereby reducing the attack surface.

Accept-lists are used in many use-cases such as application allow-listing (e.g., Windows AppLocker), USB device control (allowing only specific hardware IDs), and yes, even secure deserialization frameworks that define explicitly safe object types, which would have prevented the vulnerability in Veeam discussed above. Accept-lists are also critical in industrial control systems and embedded environments where the operating parameters are narrow and well-defined.

So how can defenders know when to use an accept-list or deny-list? In general, use accept-listing when the environment is controlled and the range of valid inputs or behaviors can be explicitly defined. Deny-lists may be more suitable when flexibility is needed, but they require constant updates and are more vulnerable to bypasses. Organizations should perform a risk assessment and threat modeling to decide the appropriate model for each system.

Some factors in choosing an accept- or deny-list solution include:

• Predictability of the Environment: If the system operates in a tightly controlled or stable environment (e.g., industrial control systems or embedded systems), it's easier to define exactly what should be allowed, making accept-listing more feasible and effective.

• Scope of Possible Inputs: In environments with a limited and well-defined set of valid inputs or software (e.g., point-of-sale systems), accept-listing is more practical. In contrast, large and variable input scopes (e.g., general-purpose endpoints) make deny-listing more manageable, though riskier.

• Operational Overhead: Accept-listing is generally more secure but requires significant effort to manage—keeping lists up to date, validating new entries, and avoiding false positives. If this overhead is too high, especially in fast-changing environments, deny-listing is more practical.

• Potential Impact of a Security Bypass: In high-risk systems where a single bypass could lead to catastrophic outcomes (e.g., financial systems, infrastructure control), the stronger guarantees of accept-listing are preferable. In less critical systems, the trade-off for using deny-listing may be acceptable.

To deepen your understanding of when and how to use application whitelisting effectively, especially in high-assurance or industrial environments, we recommend reviewing the following expert resources. CISA provides detailed implementation guidance in its Guidelines for Application Whitelisting in Industrial Control Systems and the Application Whitelisting Strategic Planning Guide. Additionally, NIST’s Special Publication 800-167 offers a robust framework for software whitelisting practices in federal systems. These documents provide valuable technical and strategic insight to help defenders apply accept-listing where it matters most.

Conclusion

Deny-lists can be bypassed and require constant maintenance, making them risky in dynamic environments. Accept-lists offer stronger protection by explicitly defining trusted behaviors but aren't always practical. Understanding when to use each approach is critical—especially as real-world cases like CVE-2025-23120 show how deny-list failures can lead to serious vulnerabilities.

The most important determining factors for choosing between accept- or deny-listing include the predictability of the environment, the scope of possible inputs, the level of operational overhead incurred by implementing the more secure choice (accept-listing), and the potential impact of a security bypass. In tightly controlled or high-security systems, accept-listing results in a more reliable security control and therefore preferable. In more dynamic or heterogeneous environments, deny-listing may be the only feasible choice and a necessary compromise—albeit one that must be closely monitored and updated as the threat environment changes.

Check out our Application Security and Infrastructure Security pentesting guides to understand more about creating IT architecture resilient against vulnerabilities such as the ones discussed in this article.