Every CVESearch/Get API key

GHSA-92vj-hp7m-gwcj

Nerdbank.MessagePack has Inefficient CPU Computation

5.3 MediumFix available

GHSA-92vj-hp7m-gwcj is a medium vulnerability (CVSS 5.3) in Nerdbank.MessagePack, published May 29, 2026. No source lists public exploit code. Fixed in Nerdbank.MessagePack 1.2.4.

What does this mean?
Severity
5.3 MediumCVSS 3.1, GitHub Advisories
Exploit chance
UnscoredNo EPSS score yet
Exploitation
None knownNot on CISA’s or ENISA’s lists

Description

Impact

Applications that call OptionalConverters.WithExpandoObjectConverter and deserialize untrusted data are open to a vulnerability by which an attacker can exploit a O(n²) algorithm to burn an inordinate amount of CPU effort by adding a great many properties to an ExpandoObject, whose Add method is implemented as an O(n) algorithm.

Patches

Update to a patched version.

If a project's ExpandoObject data requires more than 128 properties, the default limit should be changed:

this.Serializer = this.Serializer with
{
	StartingContext = this.Serializer.StartingContext with
	{
		Security = this.Serializer.StartingContext.Security with
		{
			ExpandoObjectMaxPropertyCount = 256, // Set this to whatever limit is required by your application
		},
	},
};

Workarounds

Avoid the non-default WithExpandoObjectConverter extension method when deserializing untrusted data. If deserializing untrusted data into an ExpandoObject is required, developers should write a custom converter for their project that limits the number of properties allowed before initializing the object.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
None
User interaction
None

What an attacker can affect

Confidentiality
None
Integrity
None
Availability
Low

Affected packages

Affected packages
PackageAffectedFixed
Nerdbank.MessagePack
NuGet
before 1.2.4
1.2.4
Nerdbank.MessagePack
NuGet
before 1.2.4, plus listed versions
0.1.705-alpha-gad428877b70.1.734-alpha-g09268fd45c0.10.2-rc0.10.7-rc0.2.108-alpha
Show 44 moreShow less
0.2.2-alpha0.2.34-alpha0.2.52-alpha0.2.82-alpha0.3.120-beta0.3.151-beta0.3.161-beta0.3.2-alpha0.3.27-alpha0.3.38-beta0.4.5-beta0.5.1-beta0.5.37-beta0.5.57-beta0.5.72-beta0.5.80-beta0.6.1-beta0.6.27-beta0.6.7-beta0.7.1-beta0.8.1-rc0.8.102-rc0.8.111-rc0.8.128-rc0.8.131-rc0.8.30-rc0.8.46-rc0.8.54-rc0.8.67-rc0.8.82-rc0.8.90-rc0.8.92-rc0.9.12-rc0.9.14-rc0.9.23-rc0.9.26-rc0.9.35-rc1.0.111.0.21.0.401.0.431.1.251.1.621.1.78
1.2.4

What each source reports

GitHub Advisories Score used5.3

Nerdbank.MessagePack has Inefficient CPU Computation

Impact

Applications that call OptionalConverters.WithExpandoObjectConverter and deserialize untrusted data are open to a vulnerability by which an attacker can exploit a O(n²) algorithm to burn an inordinate amount of CPU effort by adding a great many properties to an ExpandoObject, whose Add method is implemented as an O(n) algorithm.

Patches

Update to a patched version.

If a project's ExpandoObject data requires more than 128 properties, the default limit should be changed:

this.Serializer = this.Serializer with
{
	StartingContext = this.Serializer.StartingContext with
	{
		Security = this.Serializer.StartingContext.Security with
		{
			ExpandoObjectMaxPropertyCount = 256, // Set this to whatever limit is required by your application
		},
	},
};

Workarounds

Avoid the non-default WithExpandoObjectConverter extension method when deserializing untrusted data. If deserializing untrusted data into an ExpandoObject is required, developers should write a custom converter for their project that limits the number of properties allowed before initializing the object.

Record
GHSA-92vj-hp7m-gwcj
CVSS 3.1
5.3 MediumCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Weakness
CWE-1176
Updated
2026-11-02
OSV5.3

Nerdbank.MessagePack has Inefficient CPU Computation

Impact

Applications that call OptionalConverters.WithExpandoObjectConverter and deserialize untrusted data are open to a vulnerability by which an attacker can exploit a O(n²) algorithm to burn an inordinate amount of CPU effort by adding a great many properties to an ExpandoObject, whose Add method is implemented as an O(n) algorithm.

Patches

Update to a patched version.

If a project's ExpandoObject data requires more than 128 properties, the default limit should be changed:

this.Serializer = this.Serializer with
{
	StartingContext = this.Serializer.StartingContext with
	{
		Security = this.Serializer.StartingContext.Security with
		{
			ExpandoObjectMaxPropertyCount = 256, // Set this to whatever limit is required by your application
		},
	},
};

Workarounds

Avoid the non-default WithExpandoObjectConverter extension method when deserializing untrusted data. If deserializing untrusted data into an ExpandoObject is required, developers should write a custom converter for their project that limits the number of properties allowed before initializing the object.

Record
GHSA-92vj-hp7m-gwcj
CVSS 3.1
5.3 MediumCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Weakness
CWE-1176
Updated
2026-11-02

History

History
RecordedChangedSources
first indexedGitHub Advisories, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

References

MoveEnter Open