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.
minreq(13 total, 5 outdated, 3 possibly insecure)
| Crate | Required | Latest | Status |
|---|---|---|---|
| base64 | ^0.22 | 0.22.1 | up to date |
| log | ^0.4.0 | 0.4.29 | up to date |
| native-tls | ^0.2 | 0.2.18 | up to date |
| openssl ⚠️ | ^0.10.29 | 0.10.79 | maybe insecure |
| openssl-probe | ^0.1 | 0.2.1 | out of date |
| punycode | ^0.4.1 | 0.4.1 | up to date |
| rustls ⚠️ | ^0.21.1 | 0.23.40 | out of date |
| rustls-native-certs | ^0.6.1 | 0.8.3 | out of date |
| rustls-webpki ⚠️ | ^0.101.0 | 0.103.13 | out of date |
| serde | ^1.0.101 | 1.0.228 | up to date |
| serde_json | ^1.0.0 | 1.0.149 | up to date |
| urlencoding | ^2.1.0 | 2.1.3 | up to date |
| webpki-roots | ^0.25.2 | 1.0.7 | out of date |
(2 total, 1 possibly insecure)
| Crate | Required | Latest | Status |
|---|---|---|---|
| chrono ⚠️ | ^0.4.0 | 0.4.44 | maybe insecure |
| tiny_http | ^0.12 | 0.12.0 | up to date |
chrono: Potential segfault in `localtime_r` invocationsUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.
No workarounds are known.
rustls: `rustls::ConnectionCommon::complete_io` could fall into an infinite loop based on network inputIf a close_notify alert is received during a handshake, complete_io
does not terminate.
Callers which do not call complete_io are not affected.
rustls-tokio and rustls-ffi do not call complete_io
and are not affected.
rustls::Stream and rustls::StreamOwned types use
complete_io and are affected.
openssl: Use-After-Free in `Md::fetch` and `Cipher::fetch`When a Some(...) value was passed to the properties argument of either of these functions, a use-after-free would result.
In practice this would nearly always result in OpenSSL treating the properties as an empty string (due to CString::drop's behavior).
The maintainers thank quitbug for reporting this vulnerability to us.
rustls-webpki: Name constraints for URI names were incorrectly acceptedName constraints for URI names were ignored and therefore accepted.
Note this library does not provide an API for asserting URI names, and URI name constraints are otherwise not implemented. URI name constraints are now rejected unconditionally.
Since name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.
This vulnerability is identified as GHSA-965h-392x-2mh5. Thank you to @1seal for the report.
rustls-webpki: Name constraints were accepted for certificates asserting a wildcard namePermitted subtree name constraints for DNS names were accepted for certificates asserting a wildcard name.
This was incorrect because, given a name constraint of accept.example.com, *.example.com could feasibly allow a name of reject.example.com which is outside the constraint.
This is very similar to CVE-2025-61727.
Since name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.
This vulnerability is identified as GHSA-xgp8-3hg3-c2mh. Thank you to @1seal for the report.
rustls-webpki: Reachable panic in certificate revocation list parsingA panic was reachable when parsing certificate revocation lists via [BorrowedCertRevocationList::from_der]
or [OwnedCertRevocationList::from_der]. This was the result of mishandling a syntactically valid empty
BIT STRING appearing in the onlySomeReasons element of a IssuingDistributionPoint CRL extension.
This panic is reachable prior to a CRL's signature being verified.
Applications that do not use CRLs are not affected.
Thank you to @tynus3 for the report.