The internet is broken right now.

When MCUboot is built with the TinyCrypt crypto backend (MCUBOOT_USE_TINYCRYPT), bootutil_aes_ctr_drop() in boot/bootutil/include/bootutil/crypto/aes_ctr_tinycrypt.h was an empty stub. The AES-CTR context for this backend is the fully expanded AES-128 key schedule (struct tc_aes_key_sched_struct). Generic code relies on this hook to release and clear key state, so with TinyCrypt nothing was cleared. The mbedTLS and PSA backends do free or destroy their key state here. As a result, boot_state_clear(), which boot_go() calls before handing off to the application, left the image's AES content-encryption key schedule in the static boot_data state. This is the case after an encrypted upgrade in single-image builds, where boot_enc_zeroize() is not called. boot_decrypt_key() likewise left the ECIES-derived key-encryption key schedule on the stack. The affected build uses MCUBOOT_ENC_IMAGES with TinyCrypt, which is the default ECDSA and Ed25519 backend in the Zephyr port. The first AES-128 round key equals the cipher key, so anyone who can read the leftover bootloader RAM after boot can recover the image content key and decrypt that encrypted image. That includes a physical attacker with debug or RAM access, or code later running on the device. This weakens image-encryption key confidentiality (and so the confidentiality of the encrypted image's plaintext). The device's long-term private decryption key is not exposed, and image authenticity is not affected. The fix wipes the context with bootutil_wipe_memory().

Crypto Device

XWEB EVO 4.3.0 through 5.8.8 contains a weak password generation vulnerability that allows remote attackers to derive the Administrator code-of-the-day password using only the device MAC address and date, with no server secret involved. Attackers can analyze the firmware binary xwpasswd, which itself functions as the password generator, to compute valid Administrator credentials offline and authenticate to the device without authorization. This product line reached it's end of service date in March 2026.

Crypto Device

Improper authentication in Bootgen could result in the use of a fixed salt value for RSA padding instead of a randomly generated salt, potentially impacting data integrity.

Crypto

SOGo before 5.12.13 contains an improper cryptographic signature verification vulnerability that allows remote attackers to replace a victim's contact S/MIME certificate by sending a spoofed multipart/signed message with a mismatched signature and an impersonated From address. Attackers can deliver a crafted CMS signedData object containing their own self-signed certificate, which SOGo's UIxMailView stores on the contact card without validating signature authenticity or certificate identity, enabling subsequent encrypted communications to be decrypted with the attacker's private key.

Crypto Web app

In affected versions of Octopus Server, insufficient validation of custom claims on OIDC accounts allowed a user with permission to edit accounts to cause Octopus Server to issue signed OIDC tokens that impersonate a different project. This could grant access to external systems, such as cloud providers or other Octopus instances, that trust that project's identity.

Crypto Server

A security flaw has been discovered in SiteServer SSCMS up to 7.2.2. Impacted is an unknown function of the file /api/v1/captcha. Performing a manipulation of the argument Value results in inadequate encryption strength. The attack is possible to be carried out remotely. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

Crypto Web app