This project might be open to known security vulnerabilities, which can be prevented by tightening the version range of affected dependencies. Find detailed information at the bottom.

Crate jsonwebtoken-aws-lc

Dependencies

(6 total, 2 outdated, 1 possibly insecure)

CrateRequiredLatestStatus
 aws-lc-rs^1.8.11.18.0up to date
 base64^0.220.23.1out of date
 pem^34.0.0out of date
 serde^1.01.0.229up to date
 serde_json^1.01.0.151up to date
 simple_asn1 ⚠️^0.60.6.4maybe insecure

Dev dependencies

(2 total, 1 outdated, 1 possibly insecure)

CrateRequiredLatestStatus
 criterion^0.5.10.8.2out of date
 time ⚠️^0.30.3.55maybe insecure

Security Vulnerabilities

simple_asn1: Panic on incorrect date input to `simple_asn1`

RUSTSEC-2021-0125

Version 0.6.0 of the simple_asn1 crate panics on certain malformed inputs to its parsing functions, including from_der and der_decode. Because this crate is frequently used with inputs from the network, this should be considered a security vulnerability.

The issue occurs when parsing the old ASN.1 "UTCTime" time format. If an attacker provides a UTCTime where the first character is ASCII but the second character is above 0x7f, a string slice operation in the from_der_ function will try to slice into the middle of a UTF-8 character, and cause a panic.

This error was introduced in commit d7d39d709577710e9dc8, which updated simple_asn1 to use time instead of chrono because of RUSTSEC-2020-159. Versions of simple_asn1 before 0.6.0 are not affected by this issue.

The patch was applied in simple_asn1 version 0.6.1.

time: Denial of Service via Stack Exhaustion

RUSTSEC-2026-0009

Impact

When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of service attack via stack exhaustion is possible. The attack relies on formally deprecated and rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary, non-malicious input will never encounter this scenario.

Patches

A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned rather than exhausting the stack.

Workarounds

Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of the stack consumed would be at most a factor of the length of the input.