Christos Papakonstantinou

A failure in the `X509 verify cert()` function allows an unverified attacker CA to be permanently stored in the shared CertManager. This leads to a bypass of certificate validation across all type-blind sibling consumers, including native TLS, OCSP, CRL, and direct CertManager verification. This issue occurs when the software is built with the `--enable-opensslextra` flag or the macros `OPENSSL EXTRA`, `!NO CERTS`, and `!WOLFCRYPT ONLY` defined, and the application specifically calls the `X509 verify cert()` function.

When using Raw Public Key (RPK), a client side connection using TLS 1.2, 1.3, or DTLS 1.2 may accept an unsolicited `server cert type=RawPublicKey`. This behavior allows a malicious or misbehaving server to bypass authentication. This issue occurs in builds where RPK is enabled via `--enable-rpk`, `--enable-all`, or `--enable-distro` (HAVE RPK).

An improper access check allows privilege escalation through the 'com users group editing webservice' endpoint.

An improper access check allows privilege escalation through the `com users` batch task.

Insufficient state checks create a vector that allows the bypass of two-factor authentication (2FA) checks.

Cargo incorrectly normalized URLs of third-party registries using the sparse index protocol. In scenarios where a hosting provider allows multiple registries to be hosted with arbitrary names within the same domain, an attacker capable of publishing crates in a registry could obtain the credentials of other users of that same registry.

Cargo incorrectly handled symbolic links (symlinks)—which are files that point to another file or directory—inside crate tarballs downloaded from third-party registries. This allows a malicious crate to override the source code of another crate originating from the same registry.