Missing authorization in Client-Server API in Conduit <=0.7.0, allowing for any alias to be removed and added to another room, which can be used for privilege escalation by moving the #admins alias to a room which they control, allowing them to run commands resetting passwords, siging json with the server's key, deactivating users, and more

Lack of privilege checking when processing a redaction in Conduit versions v0.6.0 and lower, allowing a local user to redact any message from users on the same server, given that they are able to send redaction events.

Lack of validation of origin in federation API in Conduit, allowing any remote server to impersonate any user from any server in most EDUs

Incomplete cleanup when performing redactions in Conduit, allowing an attacker to check whether certain strings were present in the PDU before redaction

Lack of consideration of key expiry when validating signatures in Conduit, allowing an attacker which has compromised an expired key to forge requests as the remote server, as well as PDUs with timestamps past the expiry date

conduit-hyper integrates a conduit application with the hyper server. Prior to version 0.4.2, `conduit-hyper` did not check any limit on a request's length before calling [`hyper::body::to_bytes`](https://docs.rs/hyper/latest/hyper/body/fn.to_bytes.html). An attacker could send a malicious request with an abnormally large `Content-Length`, which could lead to a panic if memory allocation failed for that request. In version 0.4.2, `conduit-hyper` sets an internal limit of 128 MiB per request, otherwise returning status 400 ("Bad Request"). This crate is part of the implementation of Rust's [crates.io](https://crates.io/), but that service is not affected due to its existing cloud infrastructure, which already drops such malicious requests. Even with the new limit in place, `conduit-hyper` is not recommended for production use, nor to directly serve the public Internet.