Mitigating CVE-2025-68615: A Deep Dive into the Net-SNMP Issue

January is in full swing, and we are looking as always to fix the attackers' candy: exposed management services and local footholds that lead into SYSTEM. So far this month we focused on an internet-facing daemon risk (SNMP traps), an admin-console authentication bypass, and a Windows task-host link-following EoP. Here’s why we chose these CVEs and how we mitigated them. CVE-2025-68615 — Net-SNMP snmptrapd Buffer Overflow Why we picked it This module, snmptrapd, is one of those “set-and-forget” daemons that often ends up enabled for legacy monitoring and then quietly drifts into the internet-exposed zone. The issue is triggered by a specially crafted packet and can crash the daemon. Our approach This is everything our script does (I’m quite amazed myself): Service termination: Stops snmptrapd if it is currently running (via systemctl when available, with a fallback to direct process termination). Service disablement: Disables snmptrapd at boot so the host does not silently re-expose itself after a restart. Firewall hardening (iptables): Adds a rule to drop inbound traffic on UDP/162 (SNMP traps). Firewall hardening (firewalld): Applies rich rules to block UDP/162 and removes any existing SNMP-trap allow rules. Firewall hardening (ufw): Adds an explicit deny for UDP/162 on systems using ufw. Use it now on vsociety: https://www.vicarius.io/vsociety/posts/cve-2025-68615-mitigation-script-buffer-overflow-vulnerability-affecting-net-snmp Educational Quick Lesson: SNMP traps are typically delivered to UDP port 162, and the safest default assumption is that this should never be exposed to untrusted networks. When the vendor guidance says “firewall it or upgrade,” the operational takeaway is simple: treat it like a management plane service and enforce network containment first, then patch. CVE-2023-32315 — Openfire Admin Console Authentication Bypass Why we picked it Admin consoles are high-value because they are not just “apps". They are control planes. In this case, the bypass comes from a dangerous combination: path traversal behavior plus wildcard-based authentication excludes. In other words, an attacker doesn’t need to break auth if they can route around it. Our approach We decided to apply the temporary workaround by modifying Openfire’s Admin plugin web.xml to remove wildcard entries from the AuthCheck filter block. How we did it (or what the script does): Locates the target file: plugins/admin/webapp/WEB-INF/web.xml (or uses OPENFIRE_WEBXML if set). Creates a timestamped backup before changes. Finds the exact containing AuthCheck. Removes all * characters within that block only, leaving the rest of the XML untouched. Use it now on vsociety: https://www.vicarius.io/vsociety/posts/cve-2023-32315-mitigate-openfire-vulnerability Educational Quick Lesson: Wildcard exclusions feel convenient (“match everything under setup/*”), but convenience is exactly what turns into bypass surface when traversal/encoding edge-cases appear. Removing wildcards tightens the auth boundary immediately, buying time to upgrade to fixed releases (and reducing the chance that a single pattern mistake becomes an admin-console breach). CVE-2026-20941 — Host Process for Windows Tasks Link-Following EoP Why we picked it Link-following privilege escalations tend to be repeatable, low-friction, and highly chainable once an attacker has any local execution. This one is explicitly a local elevation of privilege via improper link resolution, which makes it a classic “post-compromise accelerator.” Our approach Scheduled Task mitigation: Per the Microsoft Security Research Center official workaround guidance, we disable the \Microsoft\Windows\WindowsAI\Recall\PolicyConfiguration scheduled task (there is no more to it to say than patch ASAP!). Use it now on vsociety: https://www.vicarius.io/vsociety/posts/cve-2026-20941-mitigation-script-host-process-for-windows-tasks-eop-vulnerability-affecting-windows-ai-recall Educational Quick Lesson: Disabling a specific task is not a long-term fix, but it is a practical containment step when you need immediate risk reduction while updates roll through change windows. In this issue, we learn that the more we recognize repeating mechanics, the faster we can ship mitigations that reduce blast radius while patching catches up. Once again, thanks for reading! Written by Nahuel Benitez , Security Analyst at Vicarius About Vicarius Founded in 2016, and headquartered in New York, Vicarius specializes in vulnerability remediation and exposure management for organizations of all sizes. Their flagship product, vRx, consolidates vulnerability management and offers cutting-edge remediation with patch management, patchless protection, and a scripting engine to safeguard business assets at all times. The unified platform is designed to help security and IT teams discover, prioritize, and fix software security vulnerabilities—not just detect them.