Threats Tagged 'cwe-413'

NLnet Labs Unbound 1.14.0 up to and including version 1.25.0 has a locking inconsistency vulnerability that when certain conditions are met (multi-threaded, RPZ XFR reload, RPZ zone with 'rpz-nsip'/'rpz-nsdname' triggers) it could result in heap use-after-free and eventual crash. An adversary can exploit the vulnerability if conditions are first met on a vulnerable Unbound, i.e., multi-threaded, an RPZ zone with 'rpz-nsip'/'rpz-nsdname' triggers and an ongoing XFR for that RPZ zone. Local RPZ files do not trigger the vulnerability. If the timing is right and an XFR happens at the same time another thread needs to read that RPZ zone, the reader may not hold the lock long enough and the thread applying the XFR may free objects that the reader is about to walk causing the use-after-free. Unbound 1.25.1 contains a patch with a fix to the locking code.

Squid versions prior to 7.5 contain a vulnerability in the handling of ICP traffic that leads to premature resource release and heap Use-After-Free bugs. This flaw allows a remote attacker to reliably cause a Denial of Service (DoS) against the Squid service if ICP support is enabled. The vulnerability cannot be mitigated by denying ICP queries via icp_access rules. The issue is fixed in Squid version 7.5.

Squid is a caching proxy for the Web. Prior to version 7.5, due to premature release of resource during expected lifetime and heap Use-After-Free bugs, Squid is vulnerable to Denial of Service when handling ICP traffic. This problem allows a remote attacker to perform a reliable and repeatable Denial of Service attack against the Squid service using ICP protocol. This attack is limited to Squid deployments that explicitly enable ICP support (i.e. configure non-zero `icp_port`). This problem _cannot_ be mitigated by denying ICP queries using `icp_access` rules. This bug is fixed in Squid version 7.5.

Pterodactyl is a free, open-source game server management panel. Pterodactyl implements rate limits that are applied to the total number of resources (e.g.databases, port allocations, or backups) that can exist for an individual server. These resource limits are applied on a per-server basis, and validated during the request cycle. However, in versions prior to 1.12.0, it is possible for a malicious user to send a massive volume of requests at the same time that would create more resources than the server is allotted. This is because the validation occurs early in the request cycle and does not lock the target resource while it is processing. As a result sending a large volume of requests at the same time would lead all of those requests to validate as not using any of the target resources, and then all creating the resources at the same time. As a result a server would be able to create more databases, allocations, or backups than configured. A malicious user is able to deny resources to other users on the system, and may be able to excessively consume the limited allocations for a node, or fill up backup space faster than is allowed by the system. Version 1.12.0 fixes the issue.

MediumVulnerabilityGermanyUnited KingdomFrance+3#cve#cve-2025-69198#cwe-400

Inadequate lock protection within Xilinx Run time may allow a local attacker to trigger a Use-After-Free condition potentially resulting in loss of confidentiality or availability

HighVulnerabilityGermanyFranceUnited Kingdom+3#cve#cve-2025-0003#cwe-413

An Improper Resource Locking vulnerability in the SDM component of B&R Automation Runtime versions before 6.3 and before Q4.93 may allow an unauthenticated network-based attacker to delete data causing denial of service conditions.

CriticalVulnerabilityGermanyFranceItaly+5#cve#cve-2025-3450#cwe-413