This project contains known security vulnerabilities. Find detailed information at the bottom.

Crate sqlx-core

Dependencies

(63 total, 26 outdated, 1 insecure, 5 possibly insecure)

CrateRequiredLatestStatus
 ahash^0.7.60.8.11out of date
 atoi^0.4.02.0.0out of date
 base64^0.13.00.22.1out of date
 bigdecimal^0.2.20.4.3out of date
 bit-vec^0.6.30.6.3up to date
 bitflags^1.3.22.5.0out of date
 bstr^0.2.171.9.1out of date
 byteorder^1.4.31.5.0up to date
 bytes^1.1.01.6.0up to date
 chrono ⚠️^0.4.190.4.38maybe insecure
 crc^2.1.03.2.1out of date
 crossbeam-queue^0.3.20.3.11up to date
 digest^0.10.00.10.7up to date
 dirs^4.0.05.0.1out of date
 either^1.6.11.11.0up to date
 encoding_rs^0.8.300.8.34up to date
 event-listener^2.5.25.3.0out of date
 flume^0.10.90.11.0out of date
 futures-channel^0.3.190.3.30up to date
 futures-core^0.3.190.3.30up to date
 futures-executor^0.3.190.3.30up to date
 futures-intrusive^0.4.00.5.0out of date
 futures-util^0.3.190.3.30up to date
 generic-array^0.14.41.0.0out of date
 git2^0.13.250.18.3out of date
 hashlink^0.7.00.9.0out of date
 hex^0.4.30.4.3up to date
 hkdf^0.12.00.12.4up to date
 hmac^0.12.00.12.1up to date
 indexmap^1.6.02.2.6out of date
 ipnetwork^0.17.00.20.0out of date
 itoa^1.0.11.0.11up to date
 libc^0.2.1120.2.154up to date
 libsqlite3-sys ⚠️^0.24.10.28.0out of date
 log^0.4.140.4.21up to date
 mac_address^1.1.21.1.6up to date
 md-5^0.10.00.10.6up to date
 memchr^2.4.12.7.2up to date
 num-bigint^0.3.30.4.4out of date
 once_cell^1.9.01.19.0up to date
 paste^1.0.61.0.14up to date
 percent-encoding^2.1.02.3.1up to date
 rand^0.8.40.8.5up to date
 regex^1.5.51.10.4up to date
 rsa ⚠️^0.6.00.9.6insecure
 rust_decimal^1.19.01.35.0up to date
 rustls ⚠️^0.19.10.23.5out of date
 serde^1.0.1321.0.200up to date
 serde_json^1.0.731.0.116up to date
 sha-1^0.10.00.10.1up to date
 sha2^0.10.00.10.8up to date
 smallvec^1.7.01.13.2up to date
 sqlformat^0.1.80.2.3out of date
 sqlx-rt^0.5.130.6.3out of date
 stringprep^0.1.20.1.4up to date
 thiserror^1.0.301.0.59up to date
 time^0.2.270.3.36out of date
 tokio-stream^0.1.80.1.15up to date
 url^2.2.22.5.0up to date
 uuid^0.8.21.8.0out of date
 webpki ⚠️^0.21.40.22.4out of date
 webpki-roots^0.21.10.26.1out of date
 whoami ⚠️^1.2.11.5.1maybe insecure

Dev dependencies

(2 total, 1 outdated, 1 possibly insecure)

CrateRequiredLatestStatus
 sqlx^0.5.130.7.4out of date
 tokio ⚠️^11.37.0maybe insecure

Security Vulnerabilities

chrono: Potential segfault in `localtime_r` invocations

RUSTSEC-2020-0159

Impact

Unix-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.

Workarounds

No workarounds are known.

References

libsqlite3-sys: `libsqlite3-sys` via C SQLite CVE-2022-35737

RUSTSEC-2022-0090

It was sometimes possible for SQLite versions >= 1.0.12, < 3.39.2 to allow an array-bounds overflow when large string were input into SQLite's printf function.

As libsqlite3-sys bundles SQLite, it is susceptible to the vulnerability. libsqlite3-sys was updated to bundle the patched version of SQLite here.

tokio: reject_remote_clients Configuration corruption

RUSTSEC-2023-0001

On Windows, configuring a named pipe server with pipe_mode will force ServerOptions::reject_remote_clients as false.

This drops any intended explicit configuration for the reject_remote_clients that may have been set as true previously.

The default setting of reject_remote_clients is normally true meaning the default is also overridden as false.

Workarounds

Ensure that pipe_mode is set first after initializing a ServerOptions. For example:

let mut opts = ServerOptions::new();
opts.pipe_mode(PipeMode::Message);
opts.reject_remote_clients(true);

webpki: webpki: CPU denial of service in certificate path building

RUSTSEC-2023-0052

When this crate is given a pathological certificate chain to validate, it will spend CPU time exponential with the number of candidate certificates at each step of path building.

Both TLS clients and TLS servers that accept client certificate are affected.

This was previously reported in https://github.com/briansmith/webpki/issues/69 and re-reported recently by Luke Malinowski.

webpki 0.22.1 included a partial fix and webpki 0.22.2 added further fixes.

rsa: Marvin Attack: potential key recovery through timing sidechannels

RUSTSEC-2023-0071

Impact

Due to a non-constant-time implementation, information about the private key is leaked through timing information which is observable over the network. An attacker may be able to use that information to recover the key.

Patches

No patch is yet available, however work is underway to migrate to a fully constant-time implementation.

Workarounds

The only currently available workaround is to avoid using the rsa crate in settings where attackers are able to observe timing information, e.g. local use on a non-compromised computer is fine.

References

This vulnerability was discovered as part of the "Marvin Attack", which revealed several implementations of RSA including OpenSSL had not properly mitigated timing sidechannel attacks.

whoami: Stack buffer overflow with whoami on several Unix platforms

RUSTSEC-2024-0020

With versions of the whoami crate >= 0.5.3 and < 1.5.0, calling any of these functions leads to an immediate stack buffer overflow on illumos and Solaris:

  • whoami::username
  • whoami::realname
  • whoami::username_os
  • whoami::realname_os

With versions of the whoami crate >= 0.5.3 and < 1.0.1, calling any of the above functions also leads to a stack buffer overflow on these platforms:

  • Bitrig
  • DragonFlyBSD
  • FreeBSD
  • NetBSD
  • OpenBSD

This occurs because of an incorrect definition of the passwd struct on those platforms.

As a result of this issue, denial of service and data corruption have both been observed in the wild. The issue is possibly exploitable as well.

This vulnerability also affects other Unix platforms that aren't Linux or macOS.

This issue has been addressed in whoami 1.5.0.

For more information, see this GitHub issue.

rustls: `rustls::ConnectionCommon::complete_io` could fall into an infinite loop based on network input

RUSTSEC-2024-0336

If 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.