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 rocket

Dependencies

(42 total, 2 outdated, 2 possibly insecure)

CrateRequiredLatestStatus
 serde_json^1.0.261.0.140up to date
 rmp-serde^11.3.0up to date
 uuid^11.17.0up to date
 x509-parser^0.160.17.0out of date
 http^11.3.1up to date
 bytes^1.41.10.1up to date
 hyper^1.11.6.0up to date
 hyper-util^0.1.30.1.14up to date
 yansi^1.0.11.0.1up to date
 num_cpus^1.01.17.0up to date
 time^0.30.3.41up to date
 memchr^22.7.5up to date
 binascii^0.10.1.4up to date
 ref-cast^1.01.0.24up to date
 ref-swap^0.1.20.1.2up to date
 parking_lot^0.120.12.4up to date
 ubyte^0.10.20.10.4up to date
 serde^1.01.0.219up to date
 figment^0.10.170.10.19up to date
 rand^0.80.9.1out of date
 either^11.15.0up to date
 pin-project-lite^0.20.2.16up to date
 indexmap^22.10.0up to date
 tempfile^33.20.0up to date
 async-trait^0.1.430.1.88up to date
 async-stream^0.3.20.3.6up to date
 multer^3.1.03.1.0up to date
 tokio-stream^0.1.60.1.17up to date
 cookie^0.180.18.1up to date
 futures^0.3.300.3.31up to date
 state^0.60.6.0up to date
 tracing^0.1.400.1.41up to date
 tinyvec^1.61.9.0up to date
 thread_local ⚠️^1.11.1.9maybe insecure
 tracing-subscriber^0.3.180.3.19up to date
 tokio^1.35.11.45.1up to date
 tokio-util^0.70.7.15up to date
 rustls ⚠️^0.230.23.28maybe insecure
 tokio-rustls^0.260.26.2up to date
 rustls-pemfile^2.1.02.2.0up to date
 s2n-quic^1.511.61.0up to date
 libc^0.2.1490.2.174up to date

Dev dependencies

(3 total, 1 possibly insecure)

CrateRequiredLatestStatus
 tokio ⚠️^11.45.1maybe insecure
 figment^0.10.170.10.19up to date
 pretty_assertions^11.4.1up to date

Build dependencies

(1 total, all up-to-date)

CrateRequiredLatestStatus
 version_check^0.9.10.9.5up to date

Crate rocket_codegen

Dependencies

(8 total, all up-to-date)

CrateRequiredLatestStatus
 indexmap^22.10.0up to date
 quote^1.01.0.40up to date
 syn^2.02.0.104up to date
 proc-macro2^1.0.601.0.95up to date
 devise^0.40.4.2up to date
 unicode-xid^0.20.2.6up to date
 version_check^0.90.9.5up to date
 glob^0.30.3.2up to date

Dev dependencies

(4 total, all up-to-date)

CrateRequiredLatestStatus
 time^0.30.3.41up to date
 pretty_assertions^11.4.1up to date
 version_check^0.90.9.5up to date
 trybuild^1.01.0.105up to date

Crate rocket_http

Dependencies

(14 total, all up-to-date)

CrateRequiredLatestStatus
 tinyvec^1.61.9.0up to date
 percent-encoding^22.3.1up to date
 time^0.30.3.41up to date
 indexmap^22.10.0up to date
 ref-cast^1.01.0.24up to date
 uncased^0.9.100.9.10up to date
 either^11.15.0up to date
 pear^0.2.90.2.9up to date
 memchr^22.7.5up to date
 stable-pattern^0.10.1.0up to date
 cookie^0.180.18.1up to date
 state^0.60.6.0up to date
 serde^1.01.0.219up to date
 uuid^11.17.0up to date

Crate rocket_db_pools_codegen

Dependencies

(2 total, all up-to-date)

CrateRequiredLatestStatus
 devise^0.40.4.2up to date
 quote^11.0.40up to date

Dev dependencies

(2 total, all up-to-date)

CrateRequiredLatestStatus
 trybuild^1.01.0.105up to date
 version_check^0.90.9.5up to date

Crate rocket_db_pools

Dependencies

(8 total, 1 outdated, 2 possibly insecure)

CrateRequiredLatestStatus
 deadpool^0.12.10.12.2up to date
 deadpool-postgres^0.140.14.1up to date
 deadpool-redis^0.160.21.1out of date
 mongodb^33.2.4up to date
 diesel-async^0.5.00.5.2up to date
 diesel ⚠️^2.12.2.11maybe insecure
 sqlx ⚠️^0.80.8.6maybe insecure
 log^0.40.4.27up to date

Build dependencies

(1 total, all up-to-date)

CrateRequiredLatestStatus
 version_check^0.90.9.5up to date

Crate rocket_sync_db_pools_codegen

Dependencies

(2 total, all up-to-date)

CrateRequiredLatestStatus
 quote^1.01.0.40up to date
 devise^0.40.4.2up to date

Dev dependencies

(2 total, all up-to-date)

CrateRequiredLatestStatus
 version_check^0.90.9.5up to date
 trybuild^1.01.0.105up to date

Crate rocket_sync_db_pools

Dependencies

(9 total, 3 outdated, 2 possibly insecure)

CrateRequiredLatestStatus
 r2d2^0.80.8.10up to date
 tokio ⚠️^1.6.11.45.1maybe insecure
 serde^1.01.0.219up to date
 diesel ⚠️^2.0.02.2.11maybe insecure
 postgres^0.190.19.10up to date
 r2d2_postgres^0.180.18.2up to date
 rusqlite^0.31.00.36.0out of date
 r2d2_sqlite^0.24.00.30.0out of date
 memcache^0.17.20.18.0out of date

Build dependencies

(1 total, all up-to-date)

CrateRequiredLatestStatus
 version_check^0.9.10.9.5up to date

Crate rocket_dyn_templates

Dependencies

(6 total, 1 outdated)

CrateRequiredLatestStatus
 walkdir^2.42.5.0up to date
 notify^78.0.0out of date
 normpath^11.3.0up to date
 tera^1.19.01.20.0up to date
 handlebars^6.06.3.2up to date
 minijinja^2.0.12.11.0up to date

Dev dependencies

(1 total, all up-to-date)

CrateRequiredLatestStatus
 pretty_assertions^1.41.4.1up to date

Crate rocket_ws

Dependencies

(1 total, 1 outdated)

CrateRequiredLatestStatus
 tokio-tungstenite^0.240.27.0out of date

Crate rocket_docs_tests

Dev dependencies

(3 total, 1 outdated, 1 possibly insecure)

CrateRequiredLatestStatus
 figment^0.10.170.10.19up to date
 tokio ⚠️^11.45.1maybe insecure
 rand^0.80.9.1out of date

Security Vulnerabilities

thread_local: Data race in `Iter` and `IterMut`

RUSTSEC-2022-0006

In the affected version of this crate, {Iter, IterMut}::next used a weaker memory ordering when loading values than what was required, exposing a potential data race when iterating over a ThreadLocal's values.

Crates using Iter::next, or IterMut::next are affected by this issue.

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);

sqlx: Binary Protocol Misinterpretation caused by Truncating or Overflowing Casts

RUSTSEC-2024-0363

The following presentation at this year's DEF CON was brought to our attention on the SQLx Discord:

SQL Injection isn't Dead: Smuggling Queries at the Protocol Level
http://web.archive.org/web/20240812130923/https://media.defcon.org/DEF%20CON%2032/DEF%20CON%2032%20presentations/DEF%20CON%2032%20-%20Paul%20Gerste%20-%20SQL%20Injection%20Isn't%20Dead%20Smuggling%20Queries%20at%20the%20Protocol%20Level.pdf
(Archive link for posterity.)

Essentially, encoding a value larger than 4GiB can cause the length prefix in the protocol to overflow, causing the server to interpret the rest of the string as binary protocol commands or other data.

It appears SQLx does perform truncating casts in a way that could be problematic, for example: https://github.com/launchbadge/sqlx/blob/6f2905695b9606b5f51b40ce10af63ac9e696bb8/sqlx-postgres/src/arguments.rs#L163

This code has existed essentially since the beginning, so it is reasonable to assume that all published versions <= 0.8.0 are affected.

Mitigation

As always, you should make sure your application is validating untrustworthy user input. Reject any input over 4 GiB, or any input that could encode to a string longer than 4 GiB. Dynamically built queries are also potentially problematic if it pushes the message size over this 4 GiB bound.

Encode::size_hint() can be used for sanity checks, but do not assume that the size returned is accurate. For example, the Json<T> and Text<T> adapters have no reasonable way to predict or estimate the final encoded size, so they just return size_of::<T>() instead.

For web application backends, consider adding some middleware that limits the size of request bodies by default.

Resolution

sqlx 0.8.1 has been released with the fix: https://github.com/launchbadge/sqlx/blob/main/CHANGELOG.md#081---2024-08-23

Postgres users are advised to upgrade ASAP as a possible exploit has been demonstrated: https://github.com/launchbadge/sqlx/issues/3440#issuecomment-2307956901

MySQL and SQLite do not appear to be exploitable, but upgrading is recommended nonetheless.

diesel: Binary Protocol Misinterpretation caused by Truncating or Overflowing Casts

RUSTSEC-2024-0365

The following presentation at this year's DEF CON was brought to our attention on the Diesel Gitter Channel:

SQL Injection isn't Dead: Smuggling Queries at the Protocol Level
http://web.archive.org/web/20240812130923/https://media.defcon.org/DEF%20CON%2032/DEF%20CON%2032%20presentations/DEF%20CON%2032%20-%20Paul%20Gerste%20-%20SQL%20Injection%20Isn't%20Dead%20Smuggling%20Queries%20at%20the%20Protocol%20Level.pdf
(Archive link for posterity.) Essentially, encoding a value larger than 4GiB can cause the length prefix in the protocol to overflow, causing the server to interpret the rest of the string as binary protocol commands or other data.

It appears Diesel does perform truncating casts in a way that could be problematic, for example: https://github.com/diesel-rs/diesel/blob/ae82c4a5a133db65612b7436356f549bfecda1c7/diesel/src/pg/connection/stmt/mod.rs#L36

This code has existed essentially since the beginning, so it is reasonable to assume that all published versions <= 2.2.2 are affected.

Mitigation

The prefered migration to the outlined problem is to update to a Diesel version newer than 2.2.2, which includes fixes for the problem.

As always, you should make sure your application is validating untrustworthy user input. Reject any input over 4 GiB, or any input that could encode to a string longer than 4 GiB. Dynamically built queries are also potentially problematic if it pushes the message size over this 4 GiB bound.

For web application backends, consider adding some middleware that limits the size of request bodies by default.

Resolution

Diesel now uses #[deny] directives for the following Clippy lints:

to prevent casts that will lead to precision loss or other trunctations. Additionally we performed an audit of the relevant code.

A fix is included in the 2.2.3 release.

rustls: rustls network-reachable panic in `Acceptor::accept`

RUSTSEC-2024-0399

A bug introduced in rustls 0.23.13 leads to a panic if the received TLS ClientHello is fragmented. Only servers that use rustls::server::Acceptor::accept() are affected.

Servers that use tokio-rustls's LazyConfigAcceptor API are affected.

Servers that use tokio-rustls's TlsAcceptor API are not affected.

Servers that use rustls-ffi's rustls_acceptor_accept API are affected.