Quick answer
Direct answer
Risk scores
| CVSS metric | What it means |
|---|---|
| Attack vector (AV:N) | Network: reachable remotely |
| Attack complexity (AC:L) | Low complexity |
| Privileges required (PR:N) | No privileges required |
| User interaction (UI:N) | No user interaction |
| Scope (S:U) | Scope unchanged |
| Confidentiality (C:N) | No confidentiality impact |
| Integrity (I:N) | No integrity impact |
| Availability (A:H) | High availability impact |
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
About Freebsd
CVE-2026-2261 affects Freebsd, a product from Freebsd. Before acting, confirm where Freebsd runs in your estate, who owns it and whether it is reachable from the internet, because exposure decides real risk more than the score alone.
What the flaw is
In plain terms: Due to a programming error, blocklistd leaks a socket descriptor for each adverse event report it receives. Once a certain number of leaked sockets is reached, blocklistd becomes unable to run the helper script: a child process is forked, but this child dereferences a null pointer and crashes before it is able to exec the helper. At this point, blocklistd still records adverse events but is unable to block new addresses or unblock addresses whose database entries have expired. Once a second, much higher number of leaked sockets is reached, blocklistd becomes unable to receive new adverse event reports. An attacker may take advantage of this by triggering a large number of adverse events from sacrificial IP addresses to effectively disable blocklistd before launching an attack. Even in the absence of attacks or probes by would-be attackers, adverse events will occur regularly in the course of normal operations, and blocklistd will gradually run out file descriptors and become ineffective. The accumulation of open sockets may have knock-on effects on other parts of the system, resulting in a general slowdown until blocklistd is restarted.
Based on its CVSS vector, the flaw can be reached over the network, needs no login, and needs no user interaction. Apply the vendor fix and confirm exposure on internet facing and business critical assets first.
Affected versions and timeline
| Field | Detail |
|---|---|
| Product | Freebsd |
| Affected versions | Freebsd 15.0 |
| Published | Mar 9, 2026 |
| Last modified | Jun 17, 2026 |
| Added to CISA KEV | Not listed |
| Assigning CNA | secteam@freebsd.org |
How to detect it
- Inventory every instance of Freebsd and record the running version against the affected range above.
- Check external attack surface scans for internet facing instances of the component.
- Review logs on affected systems for unusual requests, errors or new processes around the vulnerable function.
- Confirm with an authenticated vulnerability scan once your scanner has a check for this CVE.
How to fix it
- Apply the fixed version of Freebsd named in the vendor advisory.
- If patching must wait, restrict network access to the affected service and put it behind authentication or a web application firewall rule.
- Rescan after the change to prove the exposure is gone, then close the ticket.
CTEM action plan
| CTEM stage | What to do for this CVE |
|---|---|
| Scope | Add every business service that depends on Freebsd to the current CTEM cycle. |
| Discover | Find all instances, including shadow and cloud deployments, and record versions and exposure. |
| Prioritize | Rank using EPSS and CVSS together with asset exposure and business impact. |
| Validate | Confirm the flaw is reachable and exploitable in your environment and that compensating controls work. |
| Mobilize | Assign the fix to the asset owner with a due date matched to the priority, then verify closure. |
CWE References
Technical References
Frequently asked questions
Related CVEs
If two sibling jails are restricted to separate filesystem trees, which is to say that neither of the two jail root directories is an ancestor of the other, jailed processes may nonetheless be able to access a shared directory via a nullfs mount, if the administrator has configured one. In this case, cooperating processes in the two jails may establish a connection using a unix domain socket and exchange directory descriptors with each other. When performing a filesystem name lookup, at each step of the lookup, the kernel checks whether the lookup would descend below the jail root of the current process. If the jail root directory is not encountered, the lookup continues. In a configuration where processes in two different jails are able to exchange file descriptors using a unix domain socket, it is possible for a jailed process to receive a directory for a descriptor that is below that process' jail root. This enables full filesystem access for a jailed process, breaking the chroot. Note that the system administrator is still responsible for ensuring that an unprivileged user on the jail host is not able to pass directory descriptors to a jailed process, even in a patched kernel.
By default, jailed processes cannot mount filesystems, including nullfs(4). However, the allow.mount.nullfs option enables mounting nullfs filesystems, subject to privilege checks. If a privileged user within a jail is able to nullfs-mount directories, a limitation of the kernel's path lookup logic allows that user to escape the jail's chroot, yielding access to the full filesystem of the host or parent jail. In a jail configured to allow nullfs(4) mounts from within the jail, the jailed root user can escape the jail's filesystem root.
Multer is a node.js middleware for handling `multipart/form-data`. A vulnerability in Multer prior to version 2.1.0 allows an attacker to trigger a Denial of Service (DoS) by dropping connection during file upload, potentially causing resource exhaustion. Users should upgrade to version 2.1.0 to receive a patch. No known workarounds are available.
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, the RedisArrayAggregator handler permanently leaks pooled direct-memory buffers when a Redis pipeline connection closes before a RESP array aggregate completes. The handler retains child messages in per-handler state (`depths` field) but defines no `channelInactive`, `handlerRemoved`, or `exceptionCaught` method to release them when the pipeline tears down. Because the leaked buffers are slices of `PooledByteBufAllocator` chunks, they prevent those chunks from being returned to the JVM-wide direct-memory pool. Repeated connection churn by any network peer monotonically drains this shared pool, eventually causing allocation failures on all Netty channels in the process. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mld: cancel mlo_scan_start_wk mlo_scan_start_wk is not canceled on disconnection. In fact, it is not canceled anywhere except in the restart cleanup, where we don't really have to. This can cause an init-after-queue issue: if, for example, the work was queued and then drv_change_interface got executed. This can also cause use-after-free: if the work is executed after the vif is freed.
Earn your free CTEM certification.
Learn to scope, prioritize, validate and mobilize fixes for CVEs like CVE-2026-2261 with a free CTEM certification.
Beginner / Practitioner / Program Leader
Explore certifications