BIT-node-2026-106069: High severity bitnami/node vulnerability

Q: Which systems are most likely to be exposed?

Applications using Node.js 22.x, 24.x, or 26.x are affected when they make TLS connections to non-canonical IPv4 literals containing leading-zero octets. The mismatch depends on platform resolver behavior; macOS is identified as a platform that can interpret such addresses differently from Node.js hostname verification.

Q: What must an attacker be able to do to exploit this?

The client must be induced to connect using a leading-zero IPv4 literal such as 0127.0.0.1. A server at the address selected by the operating system resolver can then present a certificate valid for the differently normalized IP address.

Q: How can I check whether an application is using a risky connection target?

Review TLS client connection targets and any user-controlled URL or hostname inputs for IPv4 literals with leading-zero octets. Addresses of this form are the relevant trigger, rather than ordinary canonical IPv4 literals.

Q: What can be done before an update is available?

Do not permit leading-zero IPv4 literals as TLS connection hosts. Reject or canonicalize these inputs before making the connection so that hostname verification and operating-system address resolution use the same address interpretation.

Published Oct 29, 2026

Updated

A flaw in Node.js TLS hostname verification can cause a server certificate to be validated against a different IP address than the one the client connected to, when the host is a non-canonical IPv4 literal with a leading zero, such as 0127.0.0.1.

tls.checkServerIdentity() normalizes the host following the WHATWG URL rules, which read a leading-zero octet as octal (0127.0.0.1 becomes 87.0.0.1), while the connection is made through the operating system resolver, which on some platforms such as macOS reads it as decimal (127.0.0.1). A server at the connected address can then be authenticated with a certificate issued for another IP address.

This vulnerability affects Node.js 26.x, 24.x, and 22.x.

Affected Software

6 affected componentsFixes available

bitnami/node<22.23.4

22.23.4

bitnami/node>=23.0.0<24.22.1

24.22.1

bitnami/node>=25.0.0<26.12.1

26.12.1

bitnami/node-min<22.23.4

22.23.4

bitnami/node-min>=23.0.0<24.22.1

24.22.1

bitnami/node-min>=25.0.0<26.12.1

26.12.1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade bitnami/node to a version that resolves this vulnerability.
Fixed in 22.23.4
Upgrade
Upgrade bitnami/node to a version that resolves this vulnerability.
Fixed in 24.22.1
Upgrade
Upgrade bitnami/node to a version that resolves this vulnerability.
Fixed in 26.12.1
Upgrade
Upgrade bitnami/node-min to a version that resolves this vulnerability.
Fixed in 22.23.4
Upgrade
Upgrade bitnami/node-min to a version that resolves this vulnerability.
Fixed in 24.22.1
Upgrade
Upgrade bitnami/node-min to a version that resolves this vulnerability.
Fixed in 26.12.1

Event History

Oct 29, 2026

Advisory Published

via OSV·08:55 AM

Data Sourced

via OSV·08:55 AM

DescriptionSeverityAffected Software

Frequently Asked Questions

Which systems are most likely to be exposed?

Applications using Node.js 22.x, 24.x, or 26.x are affected when they make TLS connections to non-canonical IPv4 literals containing leading-zero octets. The mismatch depends on platform resolver behavior; macOS is identified as a platform that can interpret such addresses differently from Node.js hostname verification.

What must an attacker be able to do to exploit this?

The client must be induced to connect using a leading-zero IPv4 literal such as 0127.0.0.1. A server at the address selected by the operating system resolver can then present a certificate valid for the differently normalized IP address.

How can I check whether an application is using a risky connection target?

Review TLS client connection targets and any user-controlled URL or hostname inputs for IPv4 literals with leading-zero octets. Addresses of this form are the relevant trigger, rather than ordinary canonical IPv4 literals.

What can be done before an update is available?

Do not permit leading-zero IPv4 literals as TLS connection hosts. Reject or canonicalize these inputs before making the connection so that hostname verification and operating-system address resolution use the same address interpretation.

BIT-node-2026-106069: High severity bitnami/node vulnerability

Affected Software

Remediation

Event History

Frequently Asked Questions

Which systems are most likely to be exposed?

What must an attacker be able to do to exploit this?

How can I check whether an application is using a risky connection target?

What can be done before an update is available?

Company

Resources

Contact

Frequently Asked Questions

Which systems are most likely to be exposed?

What must an attacker be able to do to exploit this?

How can I check whether an application is using a risky connection target?

What can be done before an update is available?