CVE-2026-63286 is a vulnerability in AXIS Camera Station Pro where database backups use inadequate encryption strength, making them susceptible to offline attacks. Versions prior to 6.20 are affected. The product automatically creates an additional backup during updates, which is also vulnerable. Users should delete all vulnerable backups and change stored credentials after applying the patch.
Authlib versions prior to 1.9.1 contain an improper authentication vulnerability where zero-length key material is accepted in certain cryptographic operations. This allows a remote attacker to forge valid HS256, HS384, or HS512 signatures for arbitrary token claims if the application's secret lookup returns empty keys. The issue is fixed in version 1.9.1.
The Booking Package WordPress plugin before 1.7.31 does not generate booking cancellation tokens using a secure source of randomness, deriving them instead from values it exposes publicly, so an unauthenticated attacker can reconstruct an arbitrary booking's token, disclose that booking's personal data and, where visitor cancellation is enabled, cancel the booking.
Slican IPx telephone exchanges use symmetric encryption with a hardcoded secret key in multiple binary files, allowing attackers with access to these files to decrypt TCP/IP communications. This vulnerability is fixed in IPx series version 6.62.0100. End-of-life products CCT-1668 (CCT1CPU), MAC-6400, and CXS-0424 remain vulnerable and will not receive updates due to hardware upgrade requirements. Users of these discontinued devices should contact the vendor's service department for upgrade options.
CVE-2026-83885 is a medium severity vulnerability in Microsoft Windows 11 Version 24H2 involving inadequate encryption strength in the Windows Virtualization-Based Security (VBS) Enclave. This flaw allows an authorized local attacker to perform spoofing attacks. The vulnerability affects multiple builds of Windows 11 24H2 prior to specific fixed versions. An official fix is available from Microsoft.
The Booking Calendar WordPress plugin before 11.8 does not generate its per-booking access hashes with sufficient entropy, deriving each from a low-entropy time-seeded value, which can allow unauthenticated attackers who are able to determine a booking's creation time to predict the hash and then read that booking's personal data or modify the booking in place.
Imprivata Enterprise Access Management (EAM) versions up to 26.2.6 use an RSA key pair for generating X.509 certificates that cannot be rotated after deployment. This practice of indefinite use of the same RSA key pair is against cryptographic best practices and results in inadequate encryption strength.
The Newsletter WordPress plugin before 9.3.8 does not generate its email tracking signing key with sufficient entropy and signs its tracking links with an unkeyed hash, allowing an unauthenticated attacker who recovers that key offline to forge tracking links, obtain any subscriber's session token, and read and modify that subscriber's stored personal data.
RabbitMQ amqp091-go is a Go AMQP 0.9.1 client. Prior to 1.13.0, tlsConfigFromURI in uri.go creates tls.Config values without setting MinVersion to tls.VersionTLS12. Builds using a Go runtime whose default permits TLS 1.0 or TLS 1.1 can therefore negotiate an obsolete protocol version when connecting through an amqps URI. A network attacker able to influence TLS negotiation with such a legacy build may weaken transport protection for AMQP messages and credentials. This issue is fixed in version 1.13.0.
The Newsletters WordPress plugin before version 4.17 uses an insufficiently random source to generate its API key, deriving it from a publicly known value. This weakness allows unauthenticated attackers to compute the API key and perform privileged actions such as adding or deleting subscribers and sending emails when the optional API is enabled. The vulnerability is classified as CWE-326 (Inadequate Encryption Strength) and has a CVSS score of 4.8, indicating medium severity.
IBM Langflow OSS 1.0.0 through 1.10.3 could allow an authenticated attacker to execute arbitrary code due to a cryptographic weakness in the custom component validation mechanism. When the optional hardening mode that restricts execution to trusted component templates is enabled, the application validates component code using a truncated SHA‑256 hash. Because the hash comparison relies on only a portion of the digest, an attacker can craft malicious component code that collides with a trusted template hash and bypasses validation. Successful exploitation allows the attacker to introduce and execute unauthorized Python code within the Langflow process, defeating the intended security control and potentially leading to full compromise of the affected instance.
CVE-2026-59651 is a vulnerability in Bouncy Castle for Java (BC-JAVA) affecting versions before 1.85 and LTS versions from 2.73.0 up to but not including 2.73.12. The issue involves the BKS keystore accepting a legacy version that uses a 16-bit integrity MAC key, which is considered inadequate encryption strength. This weakness could potentially undermine the integrity protection of the keystore data.
Use of an insecure cryptographic algorithm in the cashless payment system using NFC wristbands from CasfID Servicios Tecnológicos S.L.U. (version used at Resurrection Fest 2025), which employs cards based on MIFARE Classic technology (FM11RF08S). The cryptographic weakness of the authentication algorithm allows an attacker to retrieve access keys using techniques known as Backdoored Nested Attack, read the wristband’s entire contents, and clone its credentials onto a compatible rewritable card. Exploitation of this vulnerability could enable the impersonation of other attendees, the fraudulent use of the balance associated with their wristbands, and financial losses for both the affected users and the event organizers.
Pronetiqs IntraVUE versions 3.2.1a14 and prior have an inadequate encryption strength vulnerability which could allow an attacker to steal admin credentials via weak hash or a pass-the-hash attack.
### Summary
`joserfc.jwt.decode` accepts attacker-forged HMAC-signed tokens when the
caller-supplied verification key is the empty string or `None`.
`HMACAlgorithm.sign` and `HMACAlgorithm.verify` in
[`src/joserfc/_rfc7518/jws_algs.py:62-70`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/src/joserfc/_rfc7518/jws_algs.py#L62-L70) feed whatever
`OctKey.get_op_key(...)` produced into `hmac.new(...)`, and `OctKey.import_key`
only emits a `SecurityWarning` when the raw key is shorter than 14 bytes
without rejecting zero-length input. Any application whose JWT secret is
sourced from an unset environment variable, an unset Redis / DB row, a key
finder fallback that returns `""`, or a `Hash.new("")`-style default verifies
attacker tokens forged with `HMAC(key=b"", signing_input)` because the
attacker trivially reproduces the same digest with no secret knowledge.
This is a cross-language sibling of jwt/ruby-jwt GHSA-c32j-vqhx-rx3x /
CVE-2026-45363 (HS256/HS384/HS512 verify accepted an empty/nil HMAC key,
filed 2026-05-13). ruby-jwt v3.2.0 added an `ensure_valid_key!` precondition
that rejects empty keys at both sign and verify entry; joserfc has no
equivalent. (The same primitive lives in the deprecated `authlib.jose`
module by the same maintainer; filing this advisory against joserfc
alongside a separate `authlib` advisory because the codebases are
independent shipping artifacts on PyPI.)
### Affected versions
`joserfc` (PyPI) `<= 1.6.7` (latest published release reproduces). No
patched release.
### Privilege required
Unauthenticated. Any HTTP / RPC endpoint that calls `joserfc.jwt.decode`
with a verification key sourced from configuration is reachable. The
condition that makes the bug observable is operator-side: the configured
secret resolves to `""` or `None`. Common patterns that produce this state
in production:
- `OctKey.import_key(os.environ.get("JWT_SECRET", ""))`
- A key finder callable that returns `""` / `None` for an unknown `kid`
- Default values like `os.getenv("SECRET") or ""`, `cfg.get("secret", "")`
- Database / Redis row lookup that returns `""` for a missing row
### Vulnerable code
[`src/joserfc/_rfc7518/jws_algs.py:43-70`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/src/joserfc/_rfc7518/jws_algs.py#L43-L70):
```python
class HMACAlgorithm(JWSAlgModel):
SHA256 = hashlib.sha256
SHA384 = hashlib.sha384
SHA512 = hashlib.sha512
def __init__(self, sha_type, recommended=False):
self.name = f"HS{sha_type}"
self.description = f"HMAC using SHA-{sha_type}"
self.recommended = recommended
self.hash_alg = getattr(self, f"SHA{sha_type}")
self.algorithm_security = sha_type
def sign(self, msg: bytes, key: OctKey) -> bytes:
op_key = key.get_op_key("sign")
return hmac.new(op_key, msg, self.hash_alg).digest()
def verify(self, msg: bytes, sig: bytes, key: OctKey) -> bool:
op_key = key.get_op_key("verify")
v_sig = hmac.new(op_key, msg, self.hash_alg).digest()
return hmac.compare_digest(sig, v_sig)
```
[`src/joserfc/_rfc7518/oct_key.py:52-63`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/src/joserfc/_rfc7518/oct_key.py#L52-L63):
```python
@classmethod
def import_key(cls, value, parameters=None, password=None) -> "OctKey":
key: OctKey = super(OctKey, cls).import_key(value, parameters, password)
if len(key.raw_value) < 14:
# https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final
warnings.warn("Key size should be >= 112 bits", SecurityWarning)
return key
```
The `< 14` check only warns; `len(key.raw_value) == 0` falls through and is
returned to the caller. `HMACAlgorithm.verify` then calls
`hmac.compare_digest(sig, hmac.new(b"", signing_input, sha256).digest())`,
and Python's `hmac.new(b"", ...)` accepts the empty key.
Cross-language sibling of ruby-jwt's fix in [`lib/jwt/jwa/hmac.rb`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/lib/jwt/jwa/hmac.rb):
```ruby
def ensure_valid_key!(key)
raise_verify_error!('HMAC key expected to be a String') unless key.is_a?(String)
raise_verify_error!('HMAC key cannot be empty') if key.empty?
end
```
invoked from both `sign(signing_key:)` and `verify(verification_key:)`.
PyJWT landed an equivalent guard in 2.13.0 (`HMACAlgorithm.prepare_key`
raises `InvalidKeyError("HMAC key must not be empty.")` for `len(key_bytes) == 0`).
firebase/php-jwt rejects empty material in `Key.__construct`. jjwt enforces a
256-bit minimum in `DefaultMacAlgorithm.validateKey`. joserfc has the
strongest existing length-warning logic but stops at `< 14 bytes` warn
rather than `== 0` reject.
### How an empty `JWT_SECRET` reaches `hmac.new`
1. The application calls `joserfc.jwt.decode(value, key, algorithms=["HS256"])`
where `key = OctKey.import_key("")` (or `OctKey.import_key(b"")`,
or any custom path t
HCL Aftermarket EPC is affected by Business Logic Vulnerability using which a non valid user of the application can obtain passwords from the server and redirect them to their own email address by manipulating the server's response. The application includes checks in the initial requests to verify the validity of the provided UserId, but similar validation is not applied to Email requests when sending passwords to user emails.
HCL DFXServer is affected by an Unencrypted Communication vulnerability. The application permits users to establish connections over unencrypted channels via the HTTP protocol, which could allow a remote attacker to intercept network traffic and expose sensitive data transmitted between the user and the application.