#dos

# Summary A denial of service vulnerability was discovered in ntpd-rs where an attacker can induce a message storm between two NTP servers running ntpd-rs. # Details Since ntpd-rs version 1.2.0, when configured as a server, incorrectly responded to all NTP messages sent to the server's port with a time reply, including to responses from other servers. As a consequence, a message with a spoofed IP address of another server could cause two servers running ntpd-rs to continually respond to each other, consuming significant amounts of resources. # Impact Any time server running ntpd-rs with version between 1.2.0 and 1.6.1 inclusive which allows non-NTS traffic is affected. Client-only configurations are not affected. Affected users are recommended to upgrade to version 1.6.2 as soon as possible. # Workarounds Should upgrading not be possible, the impact of the issue can be mitigated by: - Whitelisting access to only IP addresses of clients using the server, using the ignore filter ...

### Impact A vulnerability has been identified within Rancher Manager in which it did not enforce request body size limits on certain public (unauthenticated) and authenticated API endpoints. This allows a malicious user to exploit this by sending excessively large payloads, which are fully loaded into memory during processing. This could result in: - Denial of Service (DoS): The server process may crash or become unresponsive when memory consumption exceeds available resources. - Unauthenticated and authenticated exploitation: While the issue was initially observed in unauthenticated `/v3-public/*` endpoints, the absence of request body size limits also affected several authenticated APIs, broadening the potential attack surface. It's worth noting that other areas in Rancher do implement safeguards: requests proxied to Kubernetes APIs are subject to built-in size limits enforced by the [Kubernetes API server itself](https://github.com/kubernetes/kubernetes/blob/v1.33.4/staging/src/k8s...

### Impact A denial-of-service was found in Exiv2 version v0.28.5: a quadratic algorithm in the ICC profile parsing code in `jpegBase::readMetadata()` can cause Exiv2 to run for a long time. Exiv2 is a command-line utility and C++ library for reading, writing, deleting, and modifying the metadata of image files. The denial-of-service is triggered when Exiv2 is used to read the metadata of a crafted jpg image file. ### Patches The bug is fixed in version v0.28.6. ### References Issue: https://github.com/Exiv2/exiv2/issues/3333 Fixes: https://github.com/Exiv2/exiv2/pull/3335 (main branch), https://github.com/Exiv2/exiv2/pull/3345 (0.28.x branch) ### For more information Please see our [security policy](https://github.com/Exiv2/exiv2/security/policy) for information about Exiv2 security.

### Impact An out-of-bounds read was found in Exiv2 versions v0.28.5 and earlier. Exiv2 is a command-line utility and C++ library for reading, writing, deleting, and modifying the metadata of image files. The out-of-bounds read is triggered when Exiv2 is used to write metadata into a crafted image file. An attacker could potentially exploit the vulnerability to cause a denial of service by crashing Exiv2, if they can trick the victim into running Exiv2 on a crafted image file. Note that this bug is only triggered when writing the metadata, which is a less frequently used Exiv2 operation than reading the metadata. For example, to trigger the bug in the Exiv2 command-line application, you need to add an extra command-line argument such as delete. ### Patches The bug is fixed in version v0.28.6. ### Credit Thank you to @dragonArthurX for reporting this issue. ### Details (from original report by @dragonArthurX ) **Version:** Tested on v0.28.5 (latest official release) Commit: 907169fa...

A malicious user may submit a specially-crafted complex payload that otherwise meets the default request size limit which results in excessive memory and CPU consumption of Vault. This may lead to a timeout in Vault’s auditing subroutine, potentially resulting in the Vault server to become unresponsive. This vulnerability, CVE-2025-6203, is fixed in Vault Community Edition 1.20.3 and Vault Enterprise 1.20.3, 1.19.9, 1.18.14, and 1.16.25.

View CSAF 1. EXECUTIVE SUMMARY CVSS v4 6.9 ATTENTION: Exploitable remotely/low attack complexity Vendor: Mitsubishi Electric Equipment: MELSEC iQ-F Series CPU module Vulnerability: Missing Authentication for Critical Function 2. RISK EVALUATION Successful exploitation of this vulnerability could allow an attacker to read or write the device values of the product. In addition, the attacker may be able to stop the operation of the programs. 3. TECHNICAL DETAILS 3.1 AFFECTED PRODUCTS Mitsubishi Electric reports the following versions of MELSEC iQ-F Series are affected: MELSEC iQ-F Series FX5U-32MT/ES: 1.060 and later MELSEC iQ-F Series FX5U-32MT/DS: 1.060 and later MELSEC iQ-F Series FX5U-32MT/ESS: 1.060 and later MELSEC iQ-F Series FX5U-32MT/DSS: 1.060 and later MELSEC iQ-F Series FX5U-64MT/ES: 1.060 and later MELSEC iQ-F Series FX5U-64MT/DS: 1.060 and later MELSEC iQ-F Series FX5U-64MT/ESS: 1.060 and later MELSEC iQ-F Series FX5U-64MT/DSS: 1.060 and later MELSEC iQ-F Series FX5U-80MT/ES...

Cisco Talos’ Vulnerability Discovery & Research team recently disclosed ten vulnerabilities in BioSig Libbiosig, nine in Tenda AC6 Router, eight in SAIL, two in PDF-XChange Editor, and one in a Foxit PDF Reader. The vulnerabilities mentioned in this blog post have been patched by their respective vendors, all in

Citrix has released fixes to address three security flaws in NetScaler ADC and NetScaler Gateway, including one that it said has been actively exploited in the wild. The vulnerabilities in question are listed below - CVE-2025-7775 (CVSS score: 9.2) - Memory overflow vulnerability leading to Remote Code Execution and/or Denial-of-Service CVE-2025-7776 (CVSS score: 8.8) - Memory overflow

### Impact User control of the first argument of the addImage method results in CPU utilization and denial of service. If given the possibility to pass unsanitized image data or URLs to the addImage method, a user can provide a harmful PNG file that results in high CPU utilization and denial of service. Other affected methods are: `html`. Example payload: ```js import { jsPDF } from "jpsdf" const payload = new Uint8Array([117, 171, 90, 253, 166, 154, 105, 166, 154]) const doc = new jsPDF(); const startTime = performance.now(); try { doc.addImage(payload, "PNG", 10, 40, 180, 180, undefined, "SLOW"); } finally { const endTime = performance.now(); console.log(`Call to doc.addImage took ${endTime - startTime} milliseconds`); } ``` ### Patches The vulnerability was fixed in jsPDF 3.0.2. Upgrade to jspdf@>=3.0.2. In jspdf@>=3.0.2, invalid PNG files throw an Error instead of causing very long running loops. ### Workarounds Sanitize image data or URLs before passing it to the a...

## Summary Passing a geometry string containing only a colon (":") to montage -geometry leads GetGeometry() to set width/height to 0. Later, ThumbnailImage() divides by these zero dimensions, triggering a crash (SIGFPE/abort), resulting in a denial of service. ## Details **Root Cause** 1. `montage -geometry ":" ...` reaches `MagickCore/geometry.c:GetGeometry().` 2. `StringToDouble/InterpretLocaleValue` parses `":"` as `0.0;` then: https://github.com/ImageMagick/ImageMagick/blob/0ba1b587be17543b664f7ad538e9e51e0da59d17/MagickCore/geometry.c#L355 `WidthValue` (and/or `HeightValue)` is set with a zero dimension. 3. In MagickCore/resize.c:ThumbnailImage(), the code computes: https://github.com/ImageMagick/ImageMagick/blob/0ba1b587be17543b664f7ad538e9e51e0da59d17/MagickCore/resize.c#L4625-L4629 causing a division by zero and immediate crash. The issue is trivially triggerable without external input files (e.g., using `xc:white`). ### Reproduction Environment ``` Version: ImageMagick 7.1...