Clarification on CDB Value Limits

[CRIZ]

Hi Team,

Could you please confirm whether there is a maximum limit on the number of values a CDB can hold (for example, 100, 1,000, or 10,000)?
Or is it possible to add values without a defined limit?

Thanks in advance.

[CRIZ]

[hasitha.u...@wazuh.com]

Hi CRIZ,
Wazuh doesn't have a fixed maximum limit on how many values (or entries) you can put in a CDB list, like there's no rule saying only 100, 1,000, or 10,000 are allowed.

You can keep adding values without hitting a strict cap. The lists are just plain text files turned into a fast database format, and Wazuh loads them into memory when the manager starts or restarts.

In real use, people have made very large ones successfully. For example:

• One case handled a list with 37.6 million entries (about 1.2 GB file size), and the analysis part worked fine for checking rules.
• Another had around 6 million entries (213 MB), but the API had trouble showing or fetching it all at once.

So yes, it's possible to go big, but there are some practical things to watch out for:

• The Wazuh manager uses RAM to hold the whole list in memory for quick lookups. Really huge lists can eat a lot of memory.
• If the list gets massive, rule checks might slow down a bit, especially if you have lots of events hitting those rules.
• Uploading or managing super-large files through the dashboard or API can sometimes fail or timeout (like files over 1 MB or 10 MB in some older versions).

The official docs don't mention any hard limit on entry count or file size for CDB lists. Limits usually come from your server's resources (mainly RAM) or how the API/dashboard handles big files.

If you're planning something large, I'd suggest:

• Start smaller (maybe 10k–50k entries) and test how it feels.
• Watch the memory usage of the wazuh-analysisd process after a restart (use top, htop, or something similar).

Here are the main places this info I gathered from.

• Official docs on using CDB lists: https://documentation.wazuh.com/current/user-manual/ruleset/cdb-list.html
• GitHub issue about API issues with a 6-million-entry list (but analysisd handled even bigger): https://github.com/wazuh/wazuh/issues/14020
• Another issue on high memory/crashes with extremely large lists: https://github.com/wazuh/wazuh/issues/24980 (mentioned in earlier chats)
• Upload problems with big files via dashboard: https://github.com/wazuh/wazuh-kibana-app/issues/4288

Let me know if you need further assistance on this.

[CRIZ]

Hi,

Is CDB lists case sensitive?

the operation name "MICROSOFT.NETWORK/NETWORKPROFILES/WRITE" and " Microsoft.Network/networkProfiles/write" landing in 2 different rules.

[CRIZ]

Hi,

could you please help with this?

[hasitha.u...@wazuh.com]

Hi CRIZ,

I have replicated the issue and confirmed that Wazuh's CDB list performs case-sensitive matching.

A custom rule was created referencing rule ID 5502, with a CDB list configured to check the username field:

1. <group name="newteest,">
2.  
3.   <rule id="800200" level="3">
4.     <if_sid>5502</if_sid>
5.     <list field="user" lookup="match_key">etc/lists/list-user</list>
6.     <description>Test cdb.</description>
7.     <group>pci_dss_10.2.5,gpg13_7.8,gpg13_7.9,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
8.   </rule>
9.  
10. </group>

When the CDB list entry was added with the key ROOT (uppercase), but the ingested log contained root (lowercase), the custom rule did not trigger. Once the CDB list entry was updated to match the exact casing of the username in the log (root), the rule triggered successfully.
Conclusion

This confirms that Wazuh's CDB list lookup performs exact, case-sensitive string matching. Keys in the CDB list must match the field value in the log exactly, including letter casing, for the rule to fire correctly.

Please let me know if you need any further assistance.

Ref: https://documentation.wazuh.com/current/user-manual/ruleset/cdb-list.html

[CRIZ]

Hi Hasitha,

Thanks for the response,
 Is it possible to make the matching case-insensitive instead of requiring an exact match? The CDB is already large, and creating multiple combinations for different cases would increase its size further, potentially impacting server resources. Is there a way to normalize or change the field’s case during decoding using the default JSON decoder?