During ZBX-24691, it was found that the frontend was sending incomplete SNMPv3 item configurations, omitting the authentication and privacy protocol specs.

When the server receives and deserializes the request, the structure holding the session description gets zero-initialized, and due to our choice of using 0's as valid values for the auth and privacy hash methods/ciphers, we open SNMPv3 agent sessions with a MD5:DES combination.

This went unnoticed until Red Hat disabled DES support for privacy protocols in their build of the net-snmp library, making the code matching this spec. be omitted from Zabbix (we have a code guard in place that checks whether the library exports this cipher), and reporting the privacy protocol as unsupported (correctly). The fact we accepted incomplete SNMPv3 auth specs. resulted in us never matching any other method, and reporting that the protocol was unsupported regardless of the hash method and cipher combination they selected (as seen in ZBX-24691).

I suggest being more stringent, and in the case of SNMPv3, always require the auth and privacy protocols to be specified, and rejecting the request otherwise.