Vulnerabilities
All
My stack
Known exploited
Public exploit
Critical (9+)
Likely exploited (EPSS ≥ 50%)
Changed, 24 h
New, 24 h
Sort:
risk
modified
published
CVSS
EPSS
| CVE | CVSS | EPSS | Vendor, product | Description | Modified |
|---|---|---|---|---|---|
| CVE-2026-7874 | 9.1 critical | 0.00% | langflow | IBM Langflow OSS 1.0.0 through 1.10.0 Langflow could allow disclosure of all stored credentials due to the use of a weak and reversible key derivation mechanism for encryption at rest. | Sun 25 Oct |
| CVE-2026-98549 | 9.1 critical | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: tcp: prevent collapsing skbs across boundary in rtx queue tcp_write_collapse_fence() sets TCP_SKB_CB(skb)->eor = 1 on tcp_write_queue_tail(sk) to prevent skbs queued after a switch to device encryption from being collapsed into earlier skbs. The fence is a no-op if all earlier data has already been transmitted when the switch happens: sk->sk_write_queue is empty. The not yet acknowledged earlier skbs wait in sk->tcp_rtx_queue with eor 0. On a subsequent retransmit or SACK shift, tcp_retrans_try_collapse() or tcp_shift_skb_data() can then merge an skb queued after the switch into one queued before it. Both users of the fence are affected: - psp: devices only encrypt skbs with skb->decrypted set. The merged skb keeps decrypted = 0 from the earlier skb, so merged data sent after psp_sock_assoc_set_tx() is retransmitted in cleartext. - tls device offload: the merged skb straddles the start marker set in tls_set_device_offload(). The software fallback (fill_sg_in() returns -EINVAL) and the mlx5, nfp and funeth drivers cannot handle such an skb and drop it. Every retransmit rebuilds the same skb, so the connection stalls. Fix this in two places, for defense in depth: 1. Fall back to tcp_rtx_queue_tail(sk) in tcp_write_collapse_fence() when tcp_write_queue_tail(sk) is NULL. 2. Check !skb_cmp_decrypted(to, from) in tcp_skb_can_collapse(), as tcp_skb_can_collapse_rx() does on receive. skb_shift(), which both collapse paths call, already has a DEBUG_NET_WARN_ON_ONCE() for this condition. | Sat 24 Oct |
| CVE-2026-8470 | 9.1 critical | 0.00% | langflow | IBM Langflow OSS 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, and 1.0.0 through 1.10.3 use Python's non-cryptographic random module for generating Fernet encryption keys from user secrets under 32 characters. The deterministic Mersenne Twister PRNG produces identical keys for identical seeds, allowing attackers to reproduce encryption keys and decrypt stored API keys and authentication tokens. | Sat 24 Oct |
| CVE-2026-48021 | 9.1 critical | 0.00% | no CPE yet | In epa4all, prior to version 2026-05-20, an attacker who can intercept the TLS connection between epa4all and the ePA backend can complete the VAU handshake with attacker-controlled keys and obtain the session encryption keys. All inner HTTP traffic (patient consent decisions, medication data, document operations, authorization tokens, and entitlement queries) becomes readable and modifiable. The attacker can also inject arbitrary requests through the hijacked channel. This issue has been patched in version 2026-05-20. | Sat 24 Oct |
| CVE-2025-64767 | 9.1 critical | 0.00% | no CPE yet | hpke-js is a Hybrid Public Key Encryption (HPKE) module built on top of Web Cryptography API. Prior to version 1.7.5, the public SenderContext Seal() API has a race condition which allows for the same AEAD nonce to be re-used for multiple Seal() calls. This can lead to complete loss of Confidentiality and Integrity of the produced messages. This issue has been patched in version 1.7.5. | 18 Oct |
| CVE-2026-102946 | 9.1 critical | 0.00% | no CPE yet | joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Prior to 1.7.4, joserfc.jws.deserialize_json() accepts a JWS General JSON Serialization with an empty signatures array as authenticated. The verify_general_json() loop performs no iterations for the empty array and returns success because no signature check failed, allowing an attacker without a signing key to supply an arbitrary payload that relying applications may treat as authentic. The issue affects the General JSON Serialization path; compact JWS and JWT decoding, Flattened JSON serialization, and JWE JSON processing do not follow this vulnerable path. This issue is fixed in version 1.7.4. | 15 Oct |
| CVE-2025-30156 | 8.9 high | 0.00% | no CPE yet | Ceph is an open-source distributed storage platform providing object, block, and file storage. In versions prior to 20.2.4 and 19.2.6, the CephX authentication protocol encrypts tickets with AES-128-CBC in an unauthenticated mode that uses a hard-coded initialization vector and no message authentication, allowing an attacker to forge credentials and gain cluster-wide access. Because the ciphertext is malleable and the monitor will encrypt attacker-chosen entity names, an attacker holding one low-privilege key and able to observe CephX traffic can use the monitor as an encryption oracle and splice ciphertext blocks into valid tickets for privileged entities such as Manager, MDS, and OSD. The same lack of authentication also lets an attacker with CephX permissions escalate privileges by flipping a single bit in a service ticket to set its allow_all field to true. This issue is fixed in versions 20.2.4 and 19.2.6. | 19 Oct |
| CVE-2026-5065 | 8.8 high | 0.00% | ibm, controller | IBM Controller 11.0.1, 11.1.0, 11.1.1, and 11.1.2 contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data. | Mon 26 Oct |
| CVE-2023-28829 | 8.8 high | 0.00% | siemens, simatic_net_pc_software, simatic_pcs_7, simatic_wincc | A vulnerability has been identified in SIMATIC NET PC Software V14 (All versions), SIMATIC NET PC Software V15 (All versions), SIMATIC PCS 7 V8.2 (All versions), SIMATIC PCS 7 V9.0 (All versions), SIMATIC PCS 7 V9.1 (All versions), SIMATIC WinCC (All versions < V8.0), SINAUT Software ST7sc (All versions). Before SIMATIC WinCC V8, legacy OPC services (OPC DA (Data Access), OPC HDA (Historical Data Access), and OPC AE (Alarms & Events)) were used per default. These services were designed on top of the Windows ActiveX and DCOM mechanisms and do not implement state-of-the-art security mechanisms for authentication and encryption of contents. | 23 Oct |
| CVE-2026-54367 | 8.8 high | 0.00% | no CPE yet | CentreStack before 17.2 contains an authentication bypass vulnerability that allows unauthenticated attackers to read, write, or delete arbitrary account settings by exploiting exposed API endpoints that lack authorization checks. Attackers can generate valid encrypted EntAcctId values using the static shared encryption key to forge identifiers for any user GUID, including the system-wide cluster settings account, enabling enumeration of hosted tenant domains and administrator identities. | 23 Oct |
| CVE-2026-19293 | 8.8 high | 0.00% | no CPE yet | SMP security request (from peripheral) does not include the maximum encryption key size supported. Using a key with less than the maximum keysize makes brute-forcing the key easier. See V6 in BLERP paper linked below. | 23 Oct |
| CVE-2025-63675 | 8.8 high | 0.00% | netinvent, cryptidy | cryptidy through 1.2.4 allows code execution via untrusted data because pickle.loads is used. This occurs in aes_decrypt_message in symmetric_encryption.py. | 19 Oct |
| CVE-2026-105208 | 8.7 high | 0.00% | zitadel | ZITADEL 4.x before 4.17.3 and 3.x through 3.4.15 protects IdP intent tokens with unauthenticated, malleable encryption, allowing authenticated users to tamper with their own token so it is accepted for another user's external login intent. An attacker who predicts a victim's in-flight intent identifier and wins a timing race can call /v2/idp_intents or /v2/sessions to steal the victim's IdP tokens or hijack their session. | Thu 29 Oct |
| CVE-2026-42518 | 8.7 high | 0.00% | no CPE yet | This vulnerability exists in e-Sushrut due to disclosure of sensitive information and hardcoded AES encryption keys in client-side JavaScript. An unauthenticated remote attacker could exploit this vulnerability by accessing the client-side code to extract sensitive information and cryptographic keys. Successful exploitation of this vulnerability could lead to exposure of sensitive data and compromise of cryptographic protections on the targeted system. | Mon 26 Oct |
| CVE-2026-7807 | 8.7 high | 0.00% | smartertools, smartermail | SmarterTools SmarterMail builds prior to 9560 contain a local file inclusion vulnerability in the /api/v1/report/summary/{type} API endpoint that allows authenticated users to read arbitrary .json files on the system. Attackers can exploit this vulnerability combined with weak encryption algorithms and hardcoded keys to decrypt and access stored passwords and 2FA secrets for all users. | Mon 26 Oct |
| CVE-2026-45227 | 8.7 high | 0.00% | no CPE yet | Heym before 0.0.21 contains a sandbox escape vulnerability in the custom Python tool executor that allows authenticated workflow authors to bypass sandbox restrictions by using object-graph introspection primitives. Attackers can use Python introspection techniques to recover the unrestricted __import__ function, import blocked modules such as os and subprocess, and access inherited backend environment variables containing database credentials and encryption keys to execute arbitrary host commands as the backend service user. | Mon 26 Oct |
| CVE-2026-55195 | 8.7 high | 0.00% | no CPE yet | py7zr is a Python-based library and utility to support 7zip archive compression, decompression, encryption and decryption. Prior to 1.1.3, py7zr's Worker.decompress() extracted archive entries without tracking total decompressed size, allowing a crafted .7z file such as a 15.6 KB archive that expands to 100 MB to exhaust disk or memory before extraction completes. This issue is fixed in version 1.1.3. | Sun 25 Oct |
| CVE-2026-55206 | 8.7 high | 0.00% | no CPE yet | py7zr is a Python-based library and utility to support 7zip archive compression, decompression, encryption and decryption. Prior to 1.1.3, PackInfo._read() in archiveinfo.py used an O(n^2) cumulative sum pattern for attacker-controlled numstreams values parsed from archive headers, allowing a crafted .7z archive to cause excessive CPU consumption during SevenZipFile.init() before extraction. This issue is fixed in version 1.1.3. | Sun 25 Oct |
| CVE-2026-49852 | 8.7 high | 0.00% | no CPE yet | joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Prior to 1.6.8, joserfc.jwt.decode accepts attacker-forged HMAC-signed tokens when the caller-supplied verification key is the empty string or None, because HMACAlgorithm.sign and HMACAlgorithm.verify in src/joserfc/_rfc7518/jws_algs.py pass the output of OctKey.get_op_key(...) to hmac.new(...) and OctKey.import_key in src/joserfc/_rfc7518/oct_key.py only emits a SecurityWarning for keys shorter than 14 bytes without rejecting zero-length input. This issue is fixed in version 1.6.8. | Sat 24 Oct |
| CVE-2026-105937 | 8.7 high | 0.00% | no CPE yet | Apache Pulsar shadow topics (PIP-180) are topics that read the stored messages of a source topic from that topic's managed ledger. The source topic is selected by setting the reserved topic property PULSAR.SHADOW_SOURCE. The admin REST API accepts this property when creating a non-partitioned or partitioned topic and when updating the properties of an existing topic. On these paths the broker authorizes the caller only against the topic being created or updated. It does not authorize the caller against the source topic named in the property. The existing authorization for shadow topic configuration (the SHADOW_TOPIC topic policy on the source topic) is applied only to the source-side shadow topics admin API, not to these paths. As a result, an authenticated user who is allowed to create topics or update topic properties in one tenant can bind a topic in that tenant to a persistent topic in any other tenant. With the default authorization provider, these operations require the tenant admin role for the user's own tenant. The user does not need any permission on the source topic, its namespace or its tenant. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different. The user can then consume from the shadow topic, using only permissions on their own topic, and receive retained messages that were published to the source topic in the other tenant. Exposure is limited to messages that are still retained and readable in the source topic's ledgers; messages protected with client-side end-to-end encryption cannot be decrypted without the encryption keys. A producer on the shadow topic can also register a new schema version under the source topic's schema, subject to the schema compatibility settings; existing schema versions are not replaced. In addition, the shadow topic's managed ledger applies its own retention, trimming, offloading and deletion to the source topic's ledgers. This can permanently delete the source topic's ledger data from BookKeeper and from tiered storage, regardless of the source topic's own subscriptions and retention policy, including messages that have not yet been acknowledged. Deleting the shadow topic can also delete the source topic's ledgers. This data loss can also affect shadow topics that were configured intentionally by administrators. This issue affects Apache Pulsar versions from 3.0.0 before 4.0.14 and from 4.1.0 before 4.2.5. Apache Pulsar 2.x releases do not contain the shadow topic implementation. - 4.0.x version users should upgrade to at least 4.0.14. - 4.1.x and 4.2.x version users should upgrade to at least 4.2.5. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions. The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/. In the fixed versions, shadow topics are disabled by default and are controlled by the new broker configuration setting enableShadowTopics (default false). While it is disabled, the broker rejects creating shadow topics, setting the PULSAR.SHADOW_SOURCE property, and loading or replicating to existing shadow topics. Deployments that use shadow topics must set enableShadowTopics=true in the broker configuration of all brokers after upgrading; otherwise existing shadow topics will not be loaded. When shadow topics are enabled, binding a shadow topic to a source topic in a different tenant requires the superuser role. The fixed versions also prevent a shadow topic from deleting or trimming the ledgers and offloaded data of its source topic. Affected versions provide no configuration option to disable shadow topics. Users who cannot upgrade immediately can reduce exposure by granting the tenant admin role only to trusted principals. | 23 Oct |
| CVE-2025-34337 | 8.7 high | 0.00% | no CPE yet | eGovFramework/egovframe-common-components versions up to and including 4.3.1 includes Web Editor image upload and related file delivery functionality that uses symmetric encryption to protect URL parameters, but exposes an encryption oracle that allows attackers to generate valid ciphertext for chosen values. The image upload endpoints /utl/wed/insertImage.do and /utl/wed/insertImageCk.do encrypt server-side paths, filenames, and MIME types and embed them directly into a download URL that is returned to the client. Because these same encrypted parameters are trusted by other endpoints, such as /utl/web/imageSrc.do and /cmm/fms/getImage.do, an unauthenticated attacker can abuse the upload functionality to obtain encrypted representations of attacker-chosen identifiers and then replay those ciphertext values to file-serving APIs. This design failure allows an attacker to bypass access controls that rely solely on the secrecy of encrypted parameters and retrieve arbitrary stored files that are otherwise expected to require an existing session or specific authorization context. KISA/KrCERT has identified this unpatched vulnerability as "KVE-2023-5281." | 19 Oct |
| CVE-2025-46409 | 8.7 high | 0.00% | no CPE yet | Inadequate encryption strength issue exists in SS1 Ver.16.0.0.10 and earlier (Media version:16.0.0a and earlier). If this vulnerability is exploited, a function that requires authentication may be accessed by a remote unauthenticated attacker. | 18 Oct |
| CVE-2025-59484 | 8.7 high | 0.00% | no CPE yet | The use of a broken or risky cryptographic algorithm was discovered in firmware version 3.60 of the Click Plus PLC. The vulnerability relies on the fact that the software uses an insecure implementation of the RSA encryption algorithm. | 18 Oct |
| CVE-2025-65951 | 8.7 high | 0.00% | no CPE yet | Inside Track / Entropy Derby is a research-grade horse-racing betting engine. Prior to commit 2d38d2f, the VDF-based timelock encryption system fails to enforce sequential delay against the betting operator. Bettors pre-compute the entire Wesolowski VDF and include vdfOutputHex in their encrypted bet ticket, allowing the house to decrypt immediately using fast proof verification instead of expensive VDF evaluation. This issue has been patched via commit 2d38d2f. | 18 Oct |
| CVE-2026-63725 | 8.6 high | 0.00% | no CPE yet | sysPass's FileBackupService::doBackupFiles() in lib/SP/Services/Backup/FileBackupService.php around line 388 builds a tar shell command by string-concatenating the backup directory path $this->path directly into the command line ('tar czf ' . $backupFileApp . ' ' . BASE_PATH . ' --exclude \"' . $this->path . '\" 2>&1') and passes the result to PHP's exec() with no application of escapeshellarg() and no validation of the path against a safe character set. The $this->path value is read from the sysPass configuration, which is persisted in the database and writable through the admin settings API and the admin UI. An administrator (or an attacker who has obtained an admin API token or admin session) can therefore store a backup path containing shell metacharacters and trigger a backup operation to execute arbitrary OS commands as the web server process user (typically www-data or apache). Because sysPass is a password manager whose sole purpose is to hold credentials for other systems, code execution as the web-server user permits reading sysPass's master password and encryption key from memory or configuration files, decrypting every stored credential in the database, exporting the entire password vault, pivoting to internal systems using the disclosed credentials, and installing persistent backdoors on the password-manager host. | Sat 24 Oct |
| CVE-2026-48007 | 8.6 high | 0.00% | no CPE yet | Element Call is a native Matrix video conferencing application. Versions 0.5.17 through 0.19.3 report analytics data to a PostHog server, when configured to by a `posthog` key in config.json or by the `posthogApiHost` and `posthogApiKey` URL parameters. Several fields of this data (`$initial_person_info`, `$session_entry_url`, and `$current_url`) were found to contain the full URL of the user's visited page, including the fragment. Users of a standalone Element Call ‘SPA’ instance such as https://call.element.io may therefore have reported the full URLs of certain calls, including encryption passwords, to the configured PostHog server, potentially compromising the confidentiality of the calls to actors who could access both the PostHog analytics data and the encrypted media streams. The same issue is present in Element Call's embedded package, but in practice it does not impact applications using this package (including Element Web, Element Desktop, Element X iOS, and Element X Android) because they distribute encryption keys over Matrix rather than encoding a password in the URL. The issue is patched in Element Call 0.19.4. Some workarounds are available. Users may opt out of analytics in the 'Feedback' tab of Element Call's settings and create new links for future calls. Admins who host Element Call as a standalone application may disable PostHog analytics entirely by removing the `posthog` key from their deployment's config.json file. | 23 Oct |
| CVE-2025-48981 | 8.6 high | 0.00% | no CPE yet | An insecure implementation of the proprietary protocol DNET in Product CGM MEDICO allows attackers within the intranet to eavesdrop and manipulate data on the protocol because encryption is optional for this connection. | 8 Oct |
| CVE-2026-75882 | 8.5 high | — | eset spol. s.r.o., eset endpoint encryption, eset full disk encryption | An improper access control vulnerability in ESET Endpoint Encryption and ESET Full Disk Encryption allow attacker with standard user permissions access a device interface belonging to a privileged kernel driver and send specially crafted requests. | 8 h ago |
| CVE-2025-59054 | 8.5 high | 0.00% | no CPE yet | dstack is a software development kit (SDK) to simplify the deployment of arbitrary containerized apps into trusted execution environments. In versions of dstack prior to 0.5.4, a malicious host may provide a crafted LUKS2 data volume to a dstack CVM for use as the `/data` mount. The guest will open the volume and write secret data using a volume key known to the attacker, causing disclosure of Wireguard keys and other secret information. The attacker can also pre-load data on the device, which could potentially compromise guest execution. LUKS2 volume metadata is not authenticated and supports null key-encryption algorithms, allowing an attacker to create a volume such that the volume opens (cryptsetup open) without error using any passphrase or token, records all writes in plaintext (or ciphertext with an attacker-known key), and/or contains arbitrary data chosen by the attacker. Version 0.5.4 of dstack contains a patch that addresses LUKS headers. | 19 Oct |
| CVE-2025-11690 | 8.5 high | 0.00% | no CPE yet | An Insecure Direct Object Reference (IDOR) vulnerability exists in the vehicleId parameter, allowing unauthorized access to sensitive information of other users’ vehicles. Exploiting this issue enables an attacker to retrieve data such as GPS coordinates, encryption keys, initialization vectors, model numbers, and fuel statistics belonging to other users, instead of being limited to their own vehicle data. The fix for this vulnerability is a server-side authorization fix. | 18 Oct |
| CVE-2026-14868 | 8.4 high | 0.00% | arcinfo, pcvue | The encryption algorithm used to protect the configuration of user accounts, stored in the built-in user directory of PcVue projects, all versions prior to 17.0.0, is not strong enough for the level of protection required. A local attacker could alter the existing configuration and ultimately gain privileged access to the PcVue application. | Sun 25 Oct |
| CVE-2026-56254 | 8.3 high | 0.00% | no CPE yet | In @capgo/capacitor-updater (Cap-go/capgo) before 12.128.2, the end-to-end encryption scheme distributes the private key to each device that downloads the app. Because the public key can be derived from the private key, an attacker performing a man-in-the-middle attack or compromising the Capgo server can create a validly signed update bundle and cause devices to install an update not produced by the original app maker. | Sun 25 Oct |
| CVE-2025-58356 | 8.3 high | 0.00% | no CPE yet | Constellation is the first Confidential Kubernetes. The Constellation CVM image uses LUKS2-encrypted volumes for persistent storage. When opening an encrypted storage device, the CVM uses the libcryptsetup function crypt_activate_by_passhrase. If the VM is successful in opening the partition with the disk encryption key, it treats the volume as confidential. However, due to the unsafe handling of null keyslot algorithms in the cryptsetup 2.8.1, it is possible that the opened volume is not encrypted at all. Cryptsetup prior to version 2.8.1 does not report an error when processing LUKS2-formatted disks that use the cipher_null-ecb algorithm in the keyslot encryption field. This vulnerability is fixed in 2.24.0. | 8 Oct |
| CVE-2026-63573 | 8.2 high | 0.00% | bouncycastle, bc-csharp | Observable discrepancy in the CMS RSA PKCS#1 v1.5 key-transport unwrap (KeyTransRecipientInformation.UnwrapKey) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote attacker who holds a captured CMS EnvelopedData message, and who can submit many modified messages to an application that decrypts them with the recipient's RSA private key and reveals how decryption failed, to recover the captured message's content-encryption key and so its content, via a Bleichenbacher-style adaptive chosen-ciphertext attack, because a key-transport ciphertext with invalid PKCS#1 v1.5 padding is rejected during unwrap with a distinct "bad padding in message." CmsException instead of being replaced by a random key, so it can be told apart from a correctly padded ciphertext, which fails only later at content decryption. | Wed 28 Oct |
| CVE-2026-16001 | 8.2 high | 0.00% | bouncycastle, bc-csharp | Exposure of the message authentication key through the encryption keystream in the stream mode of IesEngine (an IesEngine constructed without a block cipher) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote attacker who has observed one encrypted message with known plaintext to forge shorter messages of their choosing that the recipient accepts as authentic, via a crafted ciphertext and MAC tag, because the MAC key was taken from the key derivation output directly after a keystream as long as the message, while the derivation input depends only on the static key pair and fixed parameters. The keystream revealed by that one message therefore contains the MAC key for every sufficiently shorter message. | Tue 27 Oct |
| CVE-2026-40514 | 8.2 high | 0.00% | smartertools, smartermail | SmarterTools SmarterMail builds prior to 9610 contain a cryptographic weakness in the file and email sharing endpoints that use DES-CBC encryption with keys and initialization vectors derived from System.Random seeded with insufficient entropy, reducing the seed space to approximately 19,000 possible values. An unauthenticated attacker can use the attachment download endpoint as an oracle to determine the seed in use and derive encryption keys and initialization vectors to forge sharing tokens for arbitrary emails, attachments, or file storage contents without prior access to the targeted content. | Mon 26 Oct |
| CVE-2026-54736 | 8.2 high | 0.00% | no CPE yet | Phalcon is a high-performance, full-stack PHP framework. Prior to 5.14.1, Phalcon\Encryption\Crypt::decrypt compares the attacker-supplied HMAC tag against the freshly computed HMAC using PHP/Zephir identity comparison, which lowers to a byte-wise comparison that returns early on the first differing byte. This observable timing discrepancy can allow an attacker to recover a valid tag byte-by-byte and attach it to a chosen IV and ciphertext so that decrypt() accepts tampered encrypted content as authentic. This issue is fixed in version 5.14.1. | Sun 25 Oct |
| CVE-2026-69247 | 8.2 high | 0.00% | no CPE yet | cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. From 44.0.0 until 50.0.0, pkcs7_decrypt_der, pkcs7_decrypt_pem, and pkcs7_decrypt_smime reported the outcome of decrypting a RecipientInfo's encryptedKey in several distinguishable ways, one of which disclosed the exact length recovered from the RSA operation. The same distinction was also observable by timing. An application that decrypts attacker-supplied EnvelopedData and reflects the outcome gives the attacker a Bleichenbacher oracle against the content-encryption key. Decryption ran as RSA PKCS#1 v1.5 decrypt of encryptedKey, build an AES cipher from the result, then AES-CBC decrypt and PKCS#7 unpad. Invalid RSA padding, a valid padding with a bad key length, a correct length with a wrong key, and the real key each failed or succeeded differently. Case 1 is reachable only where the linked library lacks implicit rejection: OpenSSL 3.0 and 3.1, LibreSSL, and BoringSSL. Exploitation requires a service that auto-decrypts untrusted EnvelopedData matching the victim certificate and answers adaptively at high volume, such as an S/MIME gateway or mail filter. This issue is fixed in 50.0.0. | 23 Oct |
| CVE-2026-35088 | 8.2 high | 0.00% | no CPE yet | Slican telephone exchanges use symmetric encryption for TCP/IP communication. Secret key is hardcoded in multiple binary files. An attacker who has access to these files can decrypt the communication. This issue was fixed in IPx series version 6.62.0100. The issue STILL EXISTS in End-Of-Life telephone exchanges: - CCT-1668 (CCT1CPU) - MAC-6400 - CXS-0424 These products were discontinued in 2011 and 2012 and and will not receive updates. These products require a hardware update in order to receive a software update. The vendor recommends that users of these devices contact the their service department directly to determine the options for upgrading. | 16 Oct |
| CVE-2026-109424 | 8.2 high | 0.00% | no CPE yet | NetEase Cloud Music client for Windows (cloudmusic.exe) versions 3.1.38 and 3.1.39.205426 contains a weak encryption vulnerability where /eapi/ and /xeapi/ API response bodies are decrypted using a fixed, publicly documented AES-128-ECB key with no integrity credential. Attackers who can intercept or originate server responses can construct valid ciphertext under the known key with PKCS#7 padding, enabling the client to accept forged API responses that serve as a prerequisite for further exploitation such as reaching the os.navigateExternal bridge. | 16 Oct |
| CVE-2026-109426 | 8.2 high | 0.00% | no CPE yet | Telegram-Stremio through 5.1.0 contains an insecure storage vulnerability that allows attackers with access to the MongoDB database, backups, or logs to recover the operator's authenticated Telegram session string, which is protected only by a keyless, reversible encoding transform rather than actual encryption. Attackers can round-trip the stored value through the repository's own decode_string function with no secret key to obtain a fully authenticated Telegram session, granting complete control of the operator's Telegram account even when two-step verification is enabled. | 16 Oct |
| CVE-2026-67236 | 8.2 high | 0.00% | broadcom, rabbitmq_server | RabbitMQ is a messaging and streaming broker. From 4.2.0 until 4.2.8 and 4.3.2, a successful POST /login caused is_authorized/2 to set an auth cookie containing base64-encoded username:password credentials without HttpOnly, Secure, SameSite, or expiration protections. Because base64 is encoding rather than encryption, an attacker with same-origin cross-site scripting, an HTTP-readable network position, or local access to the browser cookie store could recover the actual login credentials; older browsers that treated an absent SameSite attribute as None also sent the cookie cross-site. This issue is fixed in versions 4.2.8 and 4.3.2. | 15 Oct |
| CVE-2026-48081 | 8.1 high | 0.00% | no CPE yet | OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.2, a TENANT_ADMIN can store `javascript:` URLs in the tenant `links` configuration (`website`, `imprint`, `privacyStatement`). These values are returned to the patient-facing landing page via `/api/public`, hydrated into the SvelteKit Button component, and rendered as `<a href="javascript:...">` elements without URL-scheme filtering. A patient who clicks any such link executes the attacker's JavaScript inside the patient browser origin, where patient form data is read before client-side encryption is applied. This breaks the project's central trust claim that the server is an untrusted relay and that administrators cannot read patient data. Patient-side encryption happens after form input, so JavaScript executing in the patient origin can read or alter the plaintext before encryption is performed. Version 1.0.2 fixes the issue. | 23 Oct |
| CVE-2026-105941 | 8.1 high | 0.00% | no CPE yet | The Azure Key Vault KMS provider in Kroxylicious accepts an untrusted vaultName from wire-deserialized EDEK bytes without format validation, enabling SSRF that exfiltrates the proxy's Azure bearer token to an attacker-controlled host. Token replay against the real Key Vault defeats the entire record-encryption trust model. | 20 Oct |
| CVE-2026-43362 | 8.1 high | 0.00% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: smb: client: fix in-place encryption corruption in SMB2_write() SMB2_write() places write payload in iov[1..n] as part of rq_iov. smb3_init_transform_rq() pointer-shares rq_iov, so crypt_message() encrypts iov[1] in-place, replacing the original plaintext with ciphertext. On a replayable error, the retry sends the same iov[1] which now contains ciphertext instead of the original data, resulting in corruption. The corruption is most likely to be observed when connections are unstable, as reconnects trigger write retries that re-send the already-encrypted data. This affects SFU mknod, MF symlinks, etc. On kernels before 6.10 (prior to the netfs conversion), sync writes also used this path and were similarly affected. The async write path wasn't unaffected as it uses rq_iter which gets deep-copied. Fix by moving the write payload into rq_iter via iov_iter_kvec(), so smb3_init_transform_rq() deep-copies it before encryption. | 19 Oct |
| CVE-2026-43134 | 8.1 high | 0.00% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ This adds a check for encryption key size upon receiving L2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which expects L2CAP_CR_LE_BAD_KEY_SIZE. | 19 Oct |
| CVE-2026-23879 | 8.0 high | 0.00% | no CPE yet | py7zr is a Python-based library and utility to support 7zip archive compression, decompression, encryption and decryption. Versions 1.1.2 and below contain an an arbitrary file write vulnerability, which allows symbolic links to be recreated outside the destination directory via crafted malicious symbolic link chains. When using extractall to extract an archive, the library restores these symbolic links, linking them to arbitrary directories on the host file system. During extraction, the program only checks the link arcname within the destination directory, but ignores the combined symlink path resolution. Attackers can exploit this vulnerability by constructing malicious archives, thereby bypassing the directory boundary restrictions implemented by the extractor. Subsequent extraction of regular files through these symbolic links can result in arbitrary file writes. This vulnerability may lead to remote code execution, privilege escalation, data corruption, or denial of service. This issue has been fixed in version 1.1.3. | Sun 25 Oct |
| CVE-2026-68148 | 7.8 high | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent ("per-mode keys"), since the data structures there are per super_block. | 19 Oct |
| CVE-2025-27070 | 7.8 high | 0.00% | qualcomm, qcs615_firmware, qcs6490_firmware, qcs8300_firmware | Memory corruption while performing encryption and decryption commands. | 18 Oct |
| CVE-2026-74595 | 7.8 high | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: fscrypt: use the mount idmap for the owner check in fscrypt_ioctl_set_policy() fscrypt_ioctl_set_policy() calls inode_owner_or_capable() with &nop_mnt_idmap before allowing an encryption policy to be set, instead of the idmap of the mount the ioctl was issued on. fscrypt is used by filesystems that support idmapped mounts (e.g. ext4, f2fs), so on such a mount this compares the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EACCES and an unrelated caller wrongly allowed. Use file_mnt_idmap(filp) instead. | 16 Oct |
Download these 236 as CSV · subscribe to this list.
EPSS scores: 2026-10-29. NVD cursor: 2026-10-29 00:22. The News page shows only notable CVEs (KEV, your stack, new criticals, EPSS over 50%, or active exploitation per SSVC); this table has all of them.