Sprecher Automation: SPRECON-E series has a critical vulnerability due to the use of static cryptographic keys in system components

Sprecher Automations SPRECON-E-C,  SPRECON-E-P, SPRECON-E-T3 is vulnerable to attack by an unauthorized remote attacker via default cryptographic keys. The use of these keys allows the attacker to read, modify, and write projects and data, or to access any device via remote maintenance.

Sprecher Automation: SPRECON-E series has static default key material for TLS connections

Sprecher Automations SPRECON-E series uses default cryptographic keys that allow an unprivileged remote attacker to access all encrypted communications, thereby compromising confidentiality and integrity.

Default secret use for initial deployment

datahub-helm provides the Kubernetes Helm charts for deploying Datahub and its dependencies on a Kubernetes cluster. Starting in version 0.1.143 and prior to version 0.2.182, due to configuration issues in the helm chart, if there was a successful initial deployment during a limited window of time, personal access tokens were possibly created with a default secret key. Since the secret key is a static, publicly available value, someone could inspect the algorithm used to generate personal access tokens and generate their own for an instance. Deploying with Metadata Service Authentication enabled would have been difficult during window of releases. If someone circumvented the helm settings and manually set Metadata Service Authentication to be enabled using environment variables directly, this would skip over the autogeneration logic for the Kubernetes Secrets and DataHub GMS would default to the signing key specified statically in the application.yml. Most deployments probably did not attempt to circumvent the helm settings to enable Metadata Service Authentication during this time, so impact is most likely limited. Any deployments with Metadata Service Authentication enabled should ensure that their secret values are properly randomized. Version 0.2.182 contains a patch for this issue. As a workaround, one may reset the token signing key to be a random value, which will invalidate active personal access tokens.

macrozheng mall JWT Token default key

A vulnerability, which was classified as problematic, has been found in macrozheng mall up to 1.0.3. Affected by this issue is some unknown functionality of the component JWT Token Handler. The manipulation leads to use of default cryptographic key. The complexity of an attack is rather high. The exploitation is known to be difficult. The vendor was contacted early about this disclosure but did not respond in any way. Instead the issue posted on GitHub got deleted without any explanation.

RUCKUS SmartZone (SZ) before 6.1.2p3 Refresh Build has a hardcoded SSH private key for a root-equivalent user account.

There is a Hard-coded Cryptographic Key in Docusnap 13.0.1440.24261, and earlier and later versions. This key can be used to decrypt inventory files that contain sensitive information such as firewall rules.

Publicly Known Cryptographic Machine Key In Procura Portal Application

Publicly known cryptographic machine key in AlayaCare's Procura Portal before 9.0.1.2 allows attackers to forge their own authentication cookies and bypass the application's authentication mechanisms.

Cosmote Greece What's Up App Realm Database RealmDB.java default key

A vulnerability, which was classified as problematic, has been found in Cosmote Greece What's Up App 4.47.3 on Android. This issue affects some unknown processing of the file gr/desquared/kmmsharedmodule/db/RealmDB.java of the component Realm Database Handler. The manipulation of the argument defaultRealmKey leads to use of default cryptographic key. Local access is required to approach this attack. The complexity of an attack is rather high. The exploitation is known to be difficult. The vendor was contacted early about this disclosure but did not respond in any way.