Deny List Policy - Hash Deletion Failures and Immutable Naming Behavior

Products

• Endpoint Security Complete

Issue/Introduction

Recent reports have identified two distinct issues within the Deny List Policy workflow: one involving the inability to permanently delete hashes from a policy ("Deletion Bug") and another where re-added hashes retain their original, historical name regardless of new input ("Immutable Naming"). These issues impact the accuracy of policy management and user-defined naming conventions.

Cause

1. Deletion Bug (Hashes Reappearing)

Engineering has determined that a synchronization failure exists within the backend processing queue. When a user removes a hash and saves the policy, the backend fails to correctly commit the purge to the hash index. This results in the hash "sticking" to the policy and reappearing as soon as the policy is reopened.

2. Immutable Naming (Caching Logic)

The "Immutable Naming" behavior is a functional limitation of how the system calculates the "Most Prevalent Name" for a hash:

• The Logic: When a hash is added, the system stores the name. If the same hash is added later with a different name, the system attempts to calculate a prevalent name based on the device file path and the frequency of that name across the environment.

• The Limitation: For external hashes (manually added hashes not yet detected by an agent), there is no device file path. Because the unique combination of Hash + Path is missing, the system defaults to the name associated with the very first time that hash was recorded in the database.

Resolution

For the Deletion Bug

A fix has been developed to ensure that deletion operations are correctly committed to the database and reflected in the policy UI.

This fix will be included in the Refresh 2026.04 update.

For the Immutable Naming Issue

This is currently a known limitation of the PAS service's prevalence calculation logic.