Phil Pennock

**Name of the Vulnerable Software and Affected Versions** NATS Server versions 2 prior to 2.1.9 JWT library versions prior to 1.1.0 **Description** A malicious account can create and sign a User JWT with a state not created by the normal tooling, such that decoding by the NATS JWT library would attempt a nil dereference, aborting execution. This can cause a Denial of Service due to process termination in the NATS Server. The issue is related to the NATS account system, where an Operator trusted by the servers signs Accounts, and each Account can then create and sign Users within their account. **Recommendations** Upgrade the NATS server to version 2.1.9 or later if using NATS Accounts. Upgrade the JWT dependency in any application using it to version 1.1.0 or later. If your NATS servers do not trust any accounts which are managed by untrusted entities, then malformed User credentials are unlikely to be encountered, and you may not need to take immediate action. However, upgrading is still recommended to prevent potential issues.

**Name of the Vulnerable Software and Affected Versions** NATS nats-server versions 2.0.0 through 2.1.8 JWT library versions prior to 1.1.0 **Description** The issue is related to Incorrect Access Control in the JWT library used by NATS nats-server, specifically in how expired credentials are handled. The `IsRevoked` and `Export.IsRevoked` functions improperly validate expired credentials using the current system time rather than the issue time of the JWT. This results in time-based credential expiry not working. A new `IsClaimRevoked` method has been introduced with correct handling, and the nats-server has been updated to use this method. The old `IsRevoked` method now always returns true, and other client code will have to be updated to avoid calling it. **Recommendations** For NATS nats-server versions 2.0.0 through 2.1.8, upgrade to version 2.1.9 or later. For JWT library versions prior to 1.1.0, upgrade the JWT dependency to version 1.1.0 or later. As a temporary workaround, consider having credentials that only expire after fixes can be deployed. Avoid using the `IsRevoked` method in the affected JWT library until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** nats.js versions 2.0.0-201 through 2.0.0-208 nats.ws versions 1.0.0-85 through 1.0.0-110 nats.deno versions prior to 1.0.0-9 **Description** The issue concerns an information disclosure flaw in the NATS project's preview versions of two NPM packages and one Deno package. This flaw causes the leakage of options, including TLS private credentials, from a client to a server. The nats.js client supports Mutual TLS, and the credentials for the TLS client key are included in the connection configuration options, leading to the disclosure of the client's TLS private key to the server. Most authentication mechanisms are handled after connection and are unaffected. The estimated number of potentially affected devices worldwide is not provided. There is no information about real-world incidents where this issue was exploited. **Recommendations** For nats.js versions 2.0.0-201 through 2.0.0-208, upgrade to version 2.0.0-209 or later and reissue any TLS client credentials with new keys. For nats.ws versions 1.0.0-85 through 1.0.0-110, upgrade to version 1.0.0-111 or later. For nats.deno versions prior to 1.0.0-9, upgrade to version 1.0.0-9 or later. As a temporary workaround, consider disabling Mutual TLS until a patch is available. Restrict access to untrusted servers to minimize the risk of exploitation. Avoid disabling TLS verification to prevent authentication credentials from being leaked.

**Name of the Vulnerable Software and Affected Versions** golang.org/x/crypto/ssh versions prior to the version that includes commit e4e2799 **Description** The issue is related to the default behavior of the Go SSH library, which does not verify host keys. This facilitates man-in-the-middle attacks if the ClientConfig.HostKeyCallback is not set. The lack of host key verification allows a remote attacker to execute a man-in-the-middle attack. **Recommendations** For versions prior to the one including commit e4e2799, consider explicitly registering a hostkey verification mechanism by setting ClientConfig.HostKeyCallback to prevent man-in-the-middle attacks. As a temporary workaround, ensure that ClientConfig.HostKeyCallback is set for all SSH client configurations to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Exim versions 4.70 through 4.80 **Description** The issue is a heap-based buffer overflow in the `dkim exim query dns txt` function, which can be exploited by remote attackers to execute arbitrary code. This can occur when DKIM support is enabled and specific settings, `acl smtp connect` and `acl smtp rcpt`, are not configured to disable DKIM verification. The attack vector involves an email from a malicious DNS server. **Recommendations** For Exim versions 4.70 through 4.80, consider disabling DKIM support or setting `acl smtp connect` and `acl smtp rcpt` to "warn control = dkim disable verify" to mitigate the risk of exploitation.