Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Due to this library's use of an inefficient algorithm, it is vulnerable to a denial of service attack when a maliciously crafted input is passed to DecodeFromBytes or other CBOR decoding mechanisms in this library. Affected versions include versions 4.0.0 through 4.5.0. This vulnerability was privately reported to me. Patches This issue has been fixed in version 4.5.1. Users should use the latest version of this library. (The latest version is not necessarily 4.5.1. Check the NuGet page to see the latest version's version number.) Workarounds Again, users should use the latest version of this library. In the meantime, note that the inputs affected by this issue are all CBOR maps or contain CBOR maps. An input that decodes to a single CBOR object is not capable of containing a CBOR map if— - it begins with a byte other than 0x80 through 0xDF, or - it does not contain a byte in the range 0xa0 through 0xBF. Such an input is not affected by this vulnerability and an…
Recommended action: Upgrade to 4.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The CBOR library supports optional tags that enable CBOR objects to contain references to objects within them. Versions earlier than 4.0 resolved those references automatically. While this by itself doesn't cause much of a security problem, a denial of service can happen if those references are deeply nested and used multiple times (so that the same reference to the same object occurs multiple times), and if the decoded CBOR object is sent to a serialization method such as EncodeToBytes, ToString, or ToJSONString, since the objects referred to are expanded in the process and take up orders of magnitude more memory than if the references weren't resolved. The impact of this problem on any particular system varies. In general, the risk is higher if the system allows users to send arbitrary CBOR objects without authentication, or exposes a remote endpoint in which arbitrary CBOR objects can be sent without authentication. Patches This problem is addressed in version 4.0 by…
Recommended action: Upgrade to 4.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.