aws-crt@1.8.1 vulnerabilities

NodeJS/browser bindings to the aws-c-* libraries

Direct Vulnerabilities

Known vulnerabilities in the aws-crt package. This does not include vulnerabilities belonging to this package’s dependencies.

Automatically find and fix vulnerabilities affecting your projects. Snyk scans for vulnerabilities and provides fixes for free.
Fix for free
Vulnerability Vulnerable Version
  • M
Improper Certificate Validation

aws-crt is a NodeJS/browser bindings to the aws-c-* libraries

Affected versions of this package are vulnerable to Improper Certificate Validation. The connections which were initialized by the package did not verify server certificate hostname during TLS handshake when overriding Certificate Authorities (CA) in their trust stores on MacOS.

How to fix Improper Certificate Validation?

Upgrade aws-crt to version 1.8.2 or higher.

<1.8.2
  • M
Improper Certificate Validation

aws-crt is a NodeJS/browser bindings to the aws-c-* libraries

Affected versions of this package are vulnerable to Improper Certificate Validation. It appends a user supplied Certificate Authority (CA) to the root CAs instead of overriding it on macOS systems. Additionally, SNI validation is also not enabled when the CA has been “overridden”. TLS handshakes will thus succeed if the peer can be verified either from the user-supplied CA or the system’s default trust-store. Attackers with access to a host’s trust stores or with ability to compromise a CA already in the host's trust store (note: the attacker must also be able to spoof DNS in this case) may be able to use this issue to bypass CA pinning.

How to fix Improper Certificate Validation?

Upgrade aws-crt to version 1.9.0 or higher.

<1.9.0
  • M
Improper Certificate Validation

aws-crt is a NodeJS/browser bindings to the aws-c-* libraries

Affected versions of this package are vulnerable to Improper Certificate Validation. TLS handshakes are succeeding if the peer can be verified either from the user-supplied CA or the system’s default trust-store. Attackers with access to a host’s trust stores or are able to compromise a certificate authority already in the host's trust store (note: the attacker must also be able to spoof DNS in this case) may be able to use this issue to bypass CA pinning. An attacker could then spoof the MQTT broker, and either drop traffic and/or respond with the attacker's data, but they would not be able to forward this data on to the MQTT broker because the attacker would still need the user's private keys to authenticate against the MQTT broker.

How to fix Improper Certificate Validation?

Upgrade aws-crt to version 1.8.2 or higher.

<1.8.2