| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Fedify is a TypeScript library for building federated server apps powered by ActivityPub and other standards. This vulnerability allows a user to maneuver the Webfinger mechanism to perform a GET request to any internal resource on any Host, Port, URL combination regardless of present security mechanisms, and forcing the victim’s server into an infinite loop causing Denial of Service. Moreover, this issue can also be maneuvered into performing a Blind SSRF attack. This vulnerability is fixed in 1.0.14, 1.1.11, 1.2.11, and 1.3.4. |
| OpenDJ is an LDAPv3 compliant directory service. OpenDJ prior to 4.9.3 contains a denial-of-service (DoS) vulnerability that causes the server to become unresponsive to all LDAP requests without crashing or restarting. This issue occurs when an alias loop exists in the LDAP database. If an ldapsearch request is executed with alias dereferencing set to "always" on this alias entry, the server stops responding to all future requests. Fortunately, the server can be restarted without data corruption. This vulnerability is fixed in 4.9.3. |
| Loop with unreachable exit condition ('infinite loop') for some Intel(R) Platform within Ring 0: Kernel may allow a denial of service. System software adversary with a privileged user combined with a low complexity attack may enable denial of service. This result may potentially occur via local access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (none) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
| Azle is a WebAssembly runtime for TypeScript and JavaScript on ICP. Calling `setTimer` in Azle versions `0.27.0`, `0.28.0`, and `0.29.0` causes an immediate infinite loop of timers to be executed on the canister, each timer attempting to clean up the global state of the previous timer. The infinite loop will occur with any valid invocation of `setTimer`. The problem has been fixed as of Azle version `0.30.0`. As a workaround, if a canister is caught in this infinite loop after calling `setTimer`, the canister can be upgraded and the timers will all be cleared, thus ending the loop. |
| In WinZip through 29.0, there is a Mark-of-the-Web Bypass Vulnerability because of an incomplete fix for CVE-2024-8811. This vulnerability allows attackers to bypass the Mark-of-the-Web protection mechanism on affected installations of WinZip. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of archived files. When extracting files from a crafted archive that bears the Mark-of-the-Web, WinZip does not propagate the Mark-of-the-Web to the extracted files. An attacker can leverage this vulnerability to execute arbitrary code in the context of the current user. NOTE: a third party has reported that this is a false positive, and has observed that the original CVE-2025-33028.md file has been deleted on GitHub. Also, this is disputed because Mark-of-the-Web propagation can increase risk via security-warning habituation, and because the intended control sphere for file-origin metadata (e.g., HostUrl in Zone.Identifier) may be narrower than that for reading the file's content. |
| When reading binary Ion data through Amazon.IonDotnet using the RawBinaryReader class, Amazon.IonDotnet does not check the number of bytes read from the underlying stream while deserializing the binary format. If the Ion data is malformed or truncated, this triggers an infinite loop condition that could potentially result in a denial of service. Users should upgrade to Amazon.IonDotnet version 1.3.1 and ensure any forked or derivative code is patched to incorporate the new fixes. |
| In IZArc through 4.5, there is a Mark-of-the-Web Bypass Vulnerability. When a user performs an extraction from an archive file that bears Mark-of-the-Web, Mark-of-the-Web is not propagated to the extracted files. NOTE: this is disputed because Mark-of-the-Web propagation can increase risk via security-warning habituation, and because the intended control sphere for file-origin metadata (e.g., HostUrl in Zone.Identifier) may be narrower than that for reading the file's content. |
| An issue was discovered in the demo/LINUXTCP implementation of cwalter-at freemodbus v.2018-09-12 allowing attackers to reach an infinite loop via a crafted length value for a packet. |
| The Matrix specification before 1.16 (i.e., with a room version before 12) lacks create event uniqueness. |
| Memory corruptions can be remotely triggered in the Control-M/Agent when SSL/TLS communication is configured.
The issue occurs in the following cases:
* Control-M/Agent 9.0.20: SSL/TLS configuration is set to the non-default setting "use_openssl=n";
* Control-M/Agent 9.0.21 and 9.0.22: Agent router configuration uses the non-default settings "JAVA_AR=N" and "use_openssl=n" |
| Minder is an open source software supply chain security platform. In Minder Helm version 0.20241106.3386+ref.2507dbf and Minder Go versions from 0.0.72 to 0.0.83, Minder users may fetch content in the context of the Minder server, which may include URLs which the user would not normally have access to. This issue has been patched in Minder Helm version 0.20250203.3849+ref.fdc94f0 and Minder Go version 0.0.84. |
| In GNOME Shell through 45.7, a portal helper can be launched automatically (without user confirmation) based on network responses provided by an adversary (e.g., an adversary who controls the local Wi-Fi network), and subsequently loads untrusted JavaScript code, which may lead to resource consumption or other impacts depending on the JavaScript code's behavior. |
| A malformed DNS message in response to a query can cause the Lookup functions to get stuck in an infinite loop. |
| The protojson.Unmarshal function can enter an infinite loop when unmarshaling certain forms of invalid JSON. This condition can occur when unmarshaling into a message which contains a google.protobuf.Any value, or when the UnmarshalOptions.DiscardUnknown option is set. |
| Issue summary: Checking excessively long DSA keys or parameters may be very
slow.
Impact summary: Applications that use the functions EVP_PKEY_param_check()
or EVP_PKEY_public_check() to check a DSA public key or DSA parameters may
experience long delays. Where the key or parameters that are being checked
have been obtained from an untrusted source this may lead to a Denial of
Service.
The functions EVP_PKEY_param_check() or EVP_PKEY_public_check() perform
various checks on DSA parameters. Some of those computations take a long time
if the modulus (`p` parameter) is too large.
Trying to use a very large modulus is slow and OpenSSL will not allow using
public keys with a modulus which is over 10,000 bits in length for signature
verification. However the key and parameter check functions do not limit
the modulus size when performing the checks.
An application that calls EVP_PKEY_param_check() or EVP_PKEY_public_check()
and supplies a key or parameters obtained from an untrusted source could be
vulnerable to a Denial of Service attack.
These functions are not called by OpenSSL itself on untrusted DSA keys so
only applications that directly call these functions may be vulnerable.
Also vulnerable are the OpenSSL pkey and pkeyparam command line applications
when using the `-check` option.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are affected by this issue. |
| A hidden field manipulation vulnerability was identified in Issuetrak version 17.1 that could be triggered by an authenticated user.
When an authenticated user submits a ticket, the request can be intercepted and subsequently modified by using a proxy. The ticket requester can be changed from the original requester to another user in the same application,
which the application then accepts. |
| Tokens in CTFd used for account activation and password resetting can be used interchangeably for these operations. When used, they are sent to the server as a GET parameter and they are not single use, which means, that during token expiration time an on-path attacker might reuse such a token to change user's password and take over the account. Moreover, the tokens also include base64 encoded user email.
This issue impacts releases up to 3.7.4 and was addressed by pull request 2679 https://github.com/CTFd/CTFd/pull/2679 included in 3.7.5 release. |
| While assignment of a user to a team (bracket) in CTFd should be possible only once, at the registration, a flaw in logic implementation allows an authenticated user to reset it's bracket and then pick a new one, joining another team while a competition is already ongoing.
This issue impacts releases from 3.7.0 up to 3.7.4 and was addressed by pull request 2636 https://github.com/CTFd/CTFd/pull/2636 included in 3.7.5 release. |
| A vulnerability in the IKEv2 feature of Cisco IOS Software, IOS XE Software, Secure Firewall ASA Software, and Secure FTD Software could allow an unauthenticated, remote attacker to cause the device to reload, resulting in a DoS condition.
This vulnerability is due to the improper processing of IKEv2 packets. An attacker could exploit this vulnerability by sending crafted IKEv2 packets to an affected device. A successful exploit could allow the attacker to cause an infinite loop that exhausts resources and could cause the device to reload. |
| In the Linux kernel, the following vulnerability has been resolved:
fuse: fix readahead reclaim deadlock
Commit e26ee4efbc79 ("fuse: allocate ff->release_args only if release is
needed") skips allocating ff->release_args if the server does not
implement open. However in doing so, fuse_prepare_release() now skips
grabbing the reference on the inode, which makes it possible for an
inode to be evicted from the dcache while there are inflight readahead
requests. This causes a deadlock if the server triggers reclaim while
servicing the readahead request and reclaim attempts to evict the inode
of the file being read ahead. Since the folio is locked during
readahead, when reclaim evicts the fuse inode and fuse_evict_inode()
attempts to remove all folios associated with the inode from the page
cache (truncate_inode_pages_range()), reclaim will block forever waiting
for the lock since readahead cannot relinquish the lock because it is
itself blocked in reclaim:
>>> stack_trace(1504735)
folio_wait_bit_common (mm/filemap.c:1308:4)
folio_lock (./include/linux/pagemap.h:1052:3)
truncate_inode_pages_range (mm/truncate.c:336:10)
fuse_evict_inode (fs/fuse/inode.c:161:2)
evict (fs/inode.c:704:3)
dentry_unlink_inode (fs/dcache.c:412:3)
__dentry_kill (fs/dcache.c:615:3)
shrink_kill (fs/dcache.c:1060:12)
shrink_dentry_list (fs/dcache.c:1087:3)
prune_dcache_sb (fs/dcache.c:1168:2)
super_cache_scan (fs/super.c:221:10)
do_shrink_slab (mm/shrinker.c:435:9)
shrink_slab (mm/shrinker.c:626:10)
shrink_node (mm/vmscan.c:5951:2)
shrink_zones (mm/vmscan.c:6195:3)
do_try_to_free_pages (mm/vmscan.c:6257:3)
do_swap_page (mm/memory.c:4136:11)
handle_pte_fault (mm/memory.c:5562:10)
handle_mm_fault (mm/memory.c:5870:9)
do_user_addr_fault (arch/x86/mm/fault.c:1338:10)
handle_page_fault (arch/x86/mm/fault.c:1481:3)
exc_page_fault (arch/x86/mm/fault.c:1539:2)
asm_exc_page_fault+0x22/0x27
Fix this deadlock by allocating ff->release_args and grabbing the
reference on the inode when preparing the file for release even if the
server does not implement open. The inode reference will be dropped when
the last reference on the fuse file is dropped (see fuse_file_put() ->
fuse_release_end()). |
