deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-q834-8qmm-v933
Package: OpenTelemetry.Exporter.OpenTelemetryProtocol (NUGET)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: >= 1.13.1, < 1.15.2
Patched in: 1.15.2

Summary: OpenTelemetry dotnet: OTLP exporter reads unbounded HTTP response bodies

Details:
### Summary

When exporting telemetry to a back-end/collector over gRPC or HTTP using OpenTelemetry Protocol format (OTLP), if the request results in a unsuccessful request (i.e. HTTP 4xx or 5xx), the response is read into memory with no upper-bound on the number of bytes consumed.

This could cause memory exhaustion in the consuming application if the configured back-end/collector endpoint is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned by the response.

### Details

https://github.com/open-telemetry/opentelemetry-dotnet/pull/6564 introduced a change to read the response body when a non-200 HTTP status code is received when exporting telemetry to aid debugging by operators so that the error response is included in the logs emitted by the exporter for both [gRPC](https://github.com/open-telemetry/opentelemetry-dotnet/blob/640cf63628567b76b348b26988920dbc0b5c1662/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/ExportClient/OtlpGrpcExportClient.cs#L123-L134) and [HTTP/protobuf](https://github.com/open-telemetry/opentelemetry-dotnet/blob/640cf63628567b76b348b26988920dbc0b5c1662/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/ExportClient/OtlpHttpExportClient.cs#L36-L41).

An unintended consequence of this change is that the response body is [fully read into memory when received with no upper-bound](https://github.com/open-telemetry/opentelemetry-dotnet/blob/640cf63628567b76b348b26988920dbc0b5c1662/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/ExportClient/OtlpExportClient.cs#L68-L89).

This vulnerability was surfaced during the investigation of GHSA-w8rr-5gcm-pp58.

### Impact

If an application using the OTLP exporter is configured to use a back-end/collector endpoint that is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned by the response the application could have its memory exhausted and create a denial-of-service condition.

### Mitigation

The application's configured back-end/collector endpoint needs to behave maliciously. If the collector/back-end is a well-behaved implementation response bodies should not be excessively large if a request error occurs.

### Workarounds

None known.

### Remediation

[#7017](https://github.com/open-telemetry/opentelemetry-dotnet/pull/7017) updates the OTLP exporter for both gRPC and HTTP to:

- Limit the number of bytes read from the response body in an error condition to 4MiB (see https://github.com/open-telemetry/opentelemetry-proto/pull/781);
- Only attempt to read the response body if OpenTelemetry error logging is enabled.
GitHub Security Advisory: GHSA-jxpf-xq2m-q525
Package: OpenMcdf (NUGET)
Severity: MODERATE (CVSS 6.2)
CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: < 3.1.3
Patched in: 3.1.3

Summary: OpenMcdf has an Infinite loop DoS via crafted CFB directory cycle

Details:
### Summary
OpenMcdf does not detect cycles in the directory entry red-black tree of a Compound File Binary (CFB) document. A crafted CFB file with a cycle in the `LeftSiblingID` / `RightSiblingID` chain causes `Storage.EnumerateEntries()` and `Storage.OpenStream()` to loop indefinitely, consuming the calling thread with no possibility of recovery via `try/catch`.

### Details
CFB directory entries form a red-black tree linked by `LeftSiblingID` and `RightSiblingID` fields. OpenMcdf's `DirectoryTreeEnumerator` and `DirectoryTree.TryGetDirectoryEntry` traverse this tree without tracking visited node IDs, so a crafted cycle (e.g. entry A's `RightSiblingID` points to entry B, and entry B's `LeftSiblingID` points back to entry A) causes traversal to loop indefinitely.

Two distinct code paths are affected:

- **`Storage.EnumerateEntries()`** - `DirectoryTreeEnumerator.MoveNext()` never returns `false`; the same entry is yielded on every iteration and the caller's `foreach` never exits. Heap grows unboundedly as entries accumulate.
- **`Storage.OpenStream()`** - `DirectoryTree.TryGetDirectoryEntry` loops indefinitely inside `DirectoryEntries.TryGetSibling` during the name lookup.

### PoC
A crafted CFB file with a sibling cycle (see attached) triggers the issue with the following code:

```csharp
using OpenMcdf;

using var ms = new MemoryStream(File.ReadAllBytes("crafted.cfb"));
using var root = RootStorage.Open(ms);

// Never returns - EnumerateEntries loops indefinitely
foreach (var entry in root.EnumerateEntries())
{
    Console.WriteLine(entry.Name);

    if (entry.Type == EntryType.Stream)
        root.OpenStream(entry.Name); // also hangs depending on the cycle structure
}
```

### Impact
A denial of service affecting any application that opens untrusted CFB files with OpenMcdf. A small crafted input carrying a valid CFB magic header (`D0 CF 11 E0 A1 B1 1A E1`) is sufficient to pass initial format validation and reach the vulnerable traversal code. No exception is thrown, so `try/catch` cannot protect callers. The affected thread is unrecoverable without killing the process.
GitHub Security Advisory: GHSA-38h3-2333-qx47
Package: OpenTelemetry.Exporter.Jaeger (NUGET)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 1.6.0-rc.1
Patched in: unpatched

Summary: OpenTelemetry .NET has potential memory exhaustion via unbounded pooled-list sizing in Jaeger exporter conversion path

Details:
### Summary

> [!IMPORTANT]  
> There is no plan to fix this issue as `OpenTelemetry.Exporter.Jaeger` was deprecated in 2023. It is for informational purposes only.

`OpenTelemetry.Exporter.Jaeger` may allow sustained memory pressure when the internal pooled-list sizing grows based on a large observed span/tag set and that enlarged size is reused for subsequent allocations. Under high-cardinality or attacker-influenced telemetry input, this can increase memory consumption and potentially cause denial of service.

### Details

The Jaeger exporter conversion path can append tag/event data into pooled list structures. In affected versions, pooled allocation sizing may be influenced by large observed payloads and reused globally across later allocations, resulting in persistent oversized rentals and elevated memory pressure. In environments where telemetry attributes/events can be influenced by untrusted input and limits are increased from defaults, this may lead to process instability or denial of service.

### Impact

Availability impact only. Confidentiality and integrity impacts are not expected.

### Workarounds / Mitigations

* Prefer maintained exporters (for example OpenTelemetry Protocol format (OTLP)) instead of the Jaeger exporter.
GitHub Security Advisory: GHSA-h39g-6x3c-7fq9
Package: Zio (NUGET)
Severity: LOW (CVSS 3.8)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-179: Incorrect Behavior Order: Early Validation
Vulnerable versions: <= 0.22.1
Patched in: 0.22.2

Summary: Zio has SubFileSystem Path Confinement Bypass via Unresolved `..` Segment

Details:
# Summary

`SubFileSystem` fails to confine operations to its declared sub path when the input path is `/../` (or equivalents `/../`, `/..\\`). This path passes all validation but resolves to the root of the parent filesystem, allowing directory level operations outside the intended boundary.

# Affected Component

`Zio.UPath.ValidateAndNormalize`
`Zio.FileSystems.SubFileSystem`

`UPath.ValidateAndNormalize` has a trailing slash optimisation.

```csharp
if (!processParts && i + 1 == path.Length)
    return path.Substring(0, path.Length - 1);
```

When the input ends with `/` or `\`, and `processParts` is still false, the function strips the trailing separator and returns immediately before the `..` resolution logic runs.  The input `/../` triggers this path: the trailing `/` is the last character, `processParts` has not been set (because `..` as the first relative segment after root is specifically exempted), so the function returns `/..` with the `..` segment unresolved.

The resulting `UPath` with `FullName = "/.."` is absolute, contains no control characters, and no colon so it passes `FileSystem.ValidatePath` without rejection.

When this path reaches `SubFileSystem.ConvertPathToDelegate`:

```csharp
protected override UPath ConvertPathToDelegate(UPath path)
{
    var safePath = path.ToRelative();     // "/..".ToRelative() = ".."
    return SubPath / safePath;            // "/jail" / ".." = "/"  (resolved by Combine)
}
```

The delegate filesystem receives `/` (the root) instead of a path under `/jail`.

# Proof of Concept

```csharp
using Zio;
using Zio.FileSystems;

var root = new MemoryFileSystem();
root.CreateDirectory("/sandbox");
var sub = new SubFileSystem(root, "/sandbox");

Console.WriteLine(sub.DirectoryExists("/../"));           // True (sees parent root)
Console.WriteLine(sub.ConvertPathToInternal("/../"));     // "/" (parent root path)
```

# Impact

The escape is limited to directory level operations because appending a filename after `..` (e.g., `/../file.txt`) causes normal `..` resolution to trigger, which correctly rejects the path as going above root.  Only the bare terminal `/../` (which strips to `/..`) survives.  This means that exploitability is limited, and this vulnerability does not escalate to file read/write.
GitHub Security Advisory: GHSA-qr3m-xw4c-jqw3
Package: HotChocolate.Language (NUGET)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: >= 15.0.0, < 15.1.14
Patched in: 15.1.14

Summary: ChilliCream GraphQL Platform: Utf8GraphQLParser Stack Overflow via Deeply Nested GraphQL Documents

Details:
### Impact

Hot Chocolate's `Utf8GraphQLParser` is a recursive descent parser with no recursion depth limit. A crafted GraphQL document with deeply nested selection sets, object values, list values, or list types can trigger a `StackOverflowException` on payloads as small as **40 KB**.

Because `StackOverflowException` is **uncatchable in .NET** (since .NET 2.0), the entire worker process is terminated immediately. All in-flight HTTP requests, background `IHostedService` tasks, and open WebSocket subscriptions on that worker are dropped. The orchestrator (Kubernetes, IIS, etc.) must restart the process.

This occurs **before any validation rules run** — `MaxExecutionDepth`, complexity analyzers, persisted query allow-lists, and custom `IDocumentValidatorRule` implementations cannot intercept the crash because `Utf8GraphQLParser.Parse` is invoked before validation. The existing `MaxAllowedFields=2048` limit does not help because the crashing payloads contain very few fields.

**Severity:** Critical (9.1) — `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H`

### Patches

- **v12 line:** Fixed in `12.22.7`
- **v13 line:** Fixed in `13.9.16`
- **v14 line:** Fixed in `14.3.1`
- **v15 line:** Fixed in `15.1.14`

The fix adds a `MaxAllowedRecursionDepth` option to `ParserOptions` with a safe default, and enforces it across all recursive parser methods (`ParseSelectionSet`, `ParseValueLiteral`, `ParseObject`, `ParseList`, `ParseTypeReference`, etc.). When the limit is exceeded, a catchable `SyntaxException` is thrown instead of overflowing the stack.

### Workarounds

There is no application-level workaround. `StackOverflowException` cannot be caught in .NET. The only mitigation is to upgrade to a patched version.

Operators can reduce (but not eliminate) risk by limiting HTTP request body size at the reverse proxy or load balancer layer, though the smallest crashing payload (40 KB) is well below most default body size limits and is highly compressible (~few hundred bytes via gzip).

### References

- Fix for v15: https://github.com/ChilliCream/graphql-platform/pull/9528
GitHub Security Advisory: GHSA-qr3m-xw4c-jqw3
Package: HotChocolate.Language (NUGET)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: >= 14.0.0, < 14.3.1
Patched in: 14.3.1

Summary: ChilliCream GraphQL Platform: Utf8GraphQLParser Stack Overflow via Deeply Nested GraphQL Documents

Details:
### Impact

Hot Chocolate's `Utf8GraphQLParser` is a recursive descent parser with no recursion depth limit. A crafted GraphQL document with deeply nested selection sets, object values, list values, or list types can trigger a `StackOverflowException` on payloads as small as **40 KB**.

Because `StackOverflowException` is **uncatchable in .NET** (since .NET 2.0), the entire worker process is terminated immediately. All in-flight HTTP requests, background `IHostedService` tasks, and open WebSocket subscriptions on that worker are dropped. The orchestrator (Kubernetes, IIS, etc.) must restart the process.

This occurs **before any validation rules run** — `MaxExecutionDepth`, complexity analyzers, persisted query allow-lists, and custom `IDocumentValidatorRule` implementations cannot intercept the crash because `Utf8GraphQLParser.Parse` is invoked before validation. The existing `MaxAllowedFields=2048` limit does not help because the crashing payloads contain very few fields.

**Severity:** Critical (9.1) — `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H`

### Patches

- **v12 line:** Fixed in `12.22.7`
- **v13 line:** Fixed in `13.9.16`
- **v14 line:** Fixed in `14.3.1`
- **v15 line:** Fixed in `15.1.14`

The fix adds a `MaxAllowedRecursionDepth` option to `ParserOptions` with a safe default, and enforces it across all recursive parser methods (`ParseSelectionSet`, `ParseValueLiteral`, `ParseObject`, `ParseList`, `ParseTypeReference`, etc.). When the limit is exceeded, a catchable `SyntaxException` is thrown instead of overflowing the stack.

### Workarounds

There is no application-level workaround. `StackOverflowException` cannot be caught in .NET. The only mitigation is to upgrade to a patched version.

Operators can reduce (but not eliminate) risk by limiting HTTP request body size at the reverse proxy or load balancer layer, though the smallest crashing payload (40 KB) is well below most default body size limits and is highly compressible (~few hundred bytes via gzip).

### References

- Fix for v15: https://github.com/ChilliCream/graphql-platform/pull/9528
GitHub Security Advisory: GHSA-qr3m-xw4c-jqw3
Package: HotChocolate.Language (NUGET)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: >= 13.0.0, < 13.9.16
Patched in: 13.9.16

Summary: ChilliCream GraphQL Platform: Utf8GraphQLParser Stack Overflow via Deeply Nested GraphQL Documents

Details:
### Impact

Hot Chocolate's `Utf8GraphQLParser` is a recursive descent parser with no recursion depth limit. A crafted GraphQL document with deeply nested selection sets, object values, list values, or list types can trigger a `StackOverflowException` on payloads as small as **40 KB**.

Because `StackOverflowException` is **uncatchable in .NET** (since .NET 2.0), the entire worker process is terminated immediately. All in-flight HTTP requests, background `IHostedService` tasks, and open WebSocket subscriptions on that worker are dropped. The orchestrator (Kubernetes, IIS, etc.) must restart the process.

This occurs **before any validation rules run** — `MaxExecutionDepth`, complexity analyzers, persisted query allow-lists, and custom `IDocumentValidatorRule` implementations cannot intercept the crash because `Utf8GraphQLParser.Parse` is invoked before validation. The existing `MaxAllowedFields=2048` limit does not help because the crashing payloads contain very few fields.

**Severity:** Critical (9.1) — `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H`

### Patches

- **v12 line:** Fixed in `12.22.7`
- **v13 line:** Fixed in `13.9.16`
- **v14 line:** Fixed in `14.3.1`
- **v15 line:** Fixed in `15.1.14`

The fix adds a `MaxAllowedRecursionDepth` option to `ParserOptions` with a safe default, and enforces it across all recursive parser methods (`ParseSelectionSet`, `ParseValueLiteral`, `ParseObject`, `ParseList`, `ParseTypeReference`, etc.). When the limit is exceeded, a catchable `SyntaxException` is thrown instead of overflowing the stack.

### Workarounds

There is no application-level workaround. `StackOverflowException` cannot be caught in .NET. The only mitigation is to upgrade to a patched version.

Operators can reduce (but not eliminate) risk by limiting HTTP request body size at the reverse proxy or load balancer layer, though the smallest crashing payload (40 KB) is well below most default body size limits and is highly compressible (~few hundred bytes via gzip).

### References

- Fix for v15: https://github.com/ChilliCream/graphql-platform/pull/9528
GitHub Security Advisory: GHSA-qr3m-xw4c-jqw3
Package: HotChocolate.Language (NUGET)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: < 12.22.7
Patched in: 12.22.7

Summary: ChilliCream GraphQL Platform: Utf8GraphQLParser Stack Overflow via Deeply Nested GraphQL Documents

Details:
### Impact

Hot Chocolate's `Utf8GraphQLParser` is a recursive descent parser with no recursion depth limit. A crafted GraphQL document with deeply nested selection sets, object values, list values, or list types can trigger a `StackOverflowException` on payloads as small as **40 KB**.

Because `StackOverflowException` is **uncatchable in .NET** (since .NET 2.0), the entire worker process is terminated immediately. All in-flight HTTP requests, background `IHostedService` tasks, and open WebSocket subscriptions on that worker are dropped. The orchestrator (Kubernetes, IIS, etc.) must restart the process.

This occurs **before any validation rules run** — `MaxExecutionDepth`, complexity analyzers, persisted query allow-lists, and custom `IDocumentValidatorRule` implementations cannot intercept the crash because `Utf8GraphQLParser.Parse` is invoked before validation. The existing `MaxAllowedFields=2048` limit does not help because the crashing payloads contain very few fields.

**Severity:** Critical (9.1) — `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H`

### Patches

- **v12 line:** Fixed in `12.22.7`
- **v13 line:** Fixed in `13.9.16`
- **v14 line:** Fixed in `14.3.1`
- **v15 line:** Fixed in `15.1.14`

The fix adds a `MaxAllowedRecursionDepth` option to `ParserOptions` with a safe default, and enforces it across all recursive parser methods (`ParseSelectionSet`, `ParseValueLiteral`, `ParseObject`, `ParseList`, `ParseTypeReference`, etc.). When the limit is exceeded, a catchable `SyntaxException` is thrown instead of overflowing the stack.

### Workarounds

There is no application-level workaround. `StackOverflowException` cannot be caught in .NET. The only mitigation is to upgrade to a patched version.

Operators can reduce (but not eliminate) risk by limiting HTTP request body size at the reverse proxy or load balancer layer, though the smallest crashing payload (40 KB) is well below most default body size limits and is highly compressible (~few hundred bytes via gzip).

### References

- Fix for v15: https://github.com/ChilliCream/graphql-platform/pull/9528
GitHub Security Advisory: GHSA-pmpg-6pww-fg6q
Package: Magick.NET-Q8-x86 (NUGET)
Severity: LOW (CVSS 3.3)
CWE: CWE-125: Out-of-bounds Read, CWE-787: Out-of-bounds Write
Vulnerable versions: < 14.12.0
Patched in: 14.12.0

Summary: ImageMagick has out-of-bounds access in ConnectedComponentsImage() via CLI-controlled connected-components:* artifacts

Details:
When the `connected-components:*` define specifies an invalid index and out of bound operation will result in an access violation.
GitHub Security Advisory: GHSA-pmpg-6pww-fg6q
Package: Magick.NET-Q8-x64 (NUGET)
Severity: LOW (CVSS 3.3)
CWE: CWE-125: Out-of-bounds Read, CWE-787: Out-of-bounds Write
Vulnerable versions: < 14.12.0
Patched in: 14.12.0

Summary: ImageMagick has out-of-bounds access in ConnectedComponentsImage() via CLI-controlled connected-components:* artifacts

Details:
When the `connected-components:*` define specifies an invalid index and out of bound operation will result in an access violation.
GitHub Security Advisory: GHSA-pmpg-6pww-fg6q
Package: Magick.NET-Q8-arm64 (NUGET)
Severity: LOW (CVSS 3.3)
CWE: CWE-125: Out-of-bounds Read, CWE-787: Out-of-bounds Write
Vulnerable versions: < 14.12.0
Patched in: 14.12.0

Summary: ImageMagick has out-of-bounds access in ConnectedComponentsImage() via CLI-controlled connected-components:* artifacts

Details:
When the `connected-components:*` define specifies an invalid index and out of bound operation will result in an access violation.
GitHub Security Advisory: GHSA-pmpg-6pww-fg6q
Package: Magick.NET-Q8-OpenMP-x64 (NUGET)
Severity: LOW (CVSS 3.3)
CWE: CWE-125: Out-of-bounds Read, CWE-787: Out-of-bounds Write
Vulnerable versions: < 14.12.0
Patched in: 14.12.0

Summary: ImageMagick has out-of-bounds access in ConnectedComponentsImage() via CLI-controlled connected-components:* artifacts

Details:
When the `connected-components:*` define specifies an invalid index and out of bound operation will result in an access violation.
GitHub Security Advisory: GHSA-pmpg-6pww-fg6q
Package: Magick.NET-Q8-OpenMP-arm64 (NUGET)
Severity: LOW (CVSS 3.3)
CWE: CWE-125: Out-of-bounds Read, CWE-787: Out-of-bounds Write
Vulnerable versions: < 14.12.0
Patched in: 14.12.0

Summary: ImageMagick has out-of-bounds access in ConnectedComponentsImage() via CLI-controlled connected-components:* artifacts

Details:
When the `connected-components:*` define specifies an invalid index and out of bound operation will result in an access violation.
GitHub Security Advisory: GHSA-pmpg-6pww-fg6q
Package: Magick.NET-Q8-AnyCPU (NUGET)
Severity: LOW (CVSS 3.3)
CWE: CWE-125: Out-of-bounds Read, CWE-787: Out-of-bounds Write
Vulnerable versions: < 14.12.0
Patched in: 14.12.0

Summary: ImageMagick has out-of-bounds access in ConnectedComponentsImage() via CLI-controlled connected-components:* artifacts

Details:
When the `connected-components:*` define specifies an invalid index and out of bound operation will result in an access violation.
GitHub Security Advisory: GHSA-pmpg-6pww-fg6q
Package: Magick.NET-Q16-HDRI-OpenMP-x64 (NUGET)
Severity: LOW (CVSS 3.3)
CWE: CWE-125: Out-of-bounds Read, CWE-787: Out-of-bounds Write
Vulnerable versions: < 14.12.0
Patched in: 14.12.0

Summary: ImageMagick has out-of-bounds access in ConnectedComponentsImage() via CLI-controlled connected-components:* artifacts

Details:
When the `connected-components:*` define specifies an invalid index and out of bound operation will result in an access violation.
GitHub Security Advisory: GHSA-pmpg-6pww-fg6q
Package: Magick.NET-Q16-x86 (NUGET)
Severity: LOW (CVSS 3.3)
CWE: CWE-125: Out-of-bounds Read, CWE-787: Out-of-bounds Write
Vulnerable versions: < 14.12.0
Patched in: 14.12.0

Summary: ImageMagick has out-of-bounds access in ConnectedComponentsImage() via CLI-controlled connected-components:* artifacts

Details:
When the `connected-components:*` define specifies an invalid index and out of bound operation will result in an access violation.
GitHub Security Advisory: GHSA-pmpg-6pww-fg6q
Package: Magick.NET-Q16-x64 (NUGET)
Severity: LOW (CVSS 3.3)
CWE: CWE-125: Out-of-bounds Read, CWE-787: Out-of-bounds Write
Vulnerable versions: < 14.12.0
Patched in: 14.12.0

Summary: ImageMagick has out-of-bounds access in ConnectedComponentsImage() via CLI-controlled connected-components:* artifacts

Details:
When the `connected-components:*` define specifies an invalid index and out of bound operation will result in an access violation.
GitHub Security Advisory: GHSA-pmpg-6pww-fg6q
Package: Magick.NET-Q16-arm64 (NUGET)
Severity: LOW (CVSS 3.3)
CWE: CWE-125: Out-of-bounds Read, CWE-787: Out-of-bounds Write
Vulnerable versions: < 14.12.0
Patched in: 14.12.0

Summary: ImageMagick has out-of-bounds access in ConnectedComponentsImage() via CLI-controlled connected-components:* artifacts

Details:
When the `connected-components:*` define specifies an invalid index and out of bound operation will result in an access violation.