Updates are now available for all active Node.js release lines.

The following releases all contain fixes for CVE-2016-5180 "ares_create_query single byte out of buffer write":

• Node.js v0.10.48 (Maintenance)
• Node.js v0.12.17 (Maintenance)
• Node.js v4.6.1 (LTS "Argon")

While this is not a critical update, all users of these release lines should upgrade at their earliest convenience.

In addition, our new Node.js v6 LTS "Boron" release line is available beginning with Node.js v6.9.0 (LTS "Boron"). Along with the transition to Long Term Support, this release also contains the following security fixes, specific to v6.x:

• Disable auto-loading of openssl.cnf: Don't automatically attempt to load an OpenSSL configuration file, from the OPENSSL_CONF environment variable or from the default location for the current platform. Always triggering a configuration file load attempt may allow an attacker to load compromised OpenSSL configuration into a Node.js process if they are able to place a file in a default location.
• Patched V8 arbitrary memory read (CVE-2016-5172): The V8 parser mishandled scopes, potentially allowing an attacker to obtain sensitive information from arbitrary memory locations via crafted JavaScript code. This vulnerability would require an attacker to be able to execute arbitrary JavaScript code in a Node.js process.
• Create a unique v8_inspector WebSocket address: Generate a UUID for each execution of the inspector. This provides additional security to prevent unauthorized clients from connecting to the Node.js process via the v8_inspector port when running with --inspect. Since the debugging protocol allows extensive access to the internals of a running process, and the execution of arbitrary code, it is important to limit connections to authorized tools only. Note that the v8_inspector protocol in Node.js is still considered an experimental feature. Vulnerability originally reported by Jann Horn.

All of these vulnerabilities are considered low-severity for Node.js users, however, users of Node.js v6.x should upgrade at their earliest convenience.

Original post is included below

Node.js v6 LTS security inclusions

Next week, on Tuesday the 18th (late evening UTC), the Node.js Foundation will be launching its second new LTS release line, a continuation of the v6.x series of releases. This line will be codenamed "Boron" and the first version will be v6.9.0.

In addition to a change to introduce the process.release.lts property, set to 'Boron', we will also be including 3 low-severity security patches that only apply to the v6.x release series.

The security vulnerabilities being addressed are all low-severity and arise from Node.js dependencies:

• V8
• OpenSSL when Node.js is built in FIPS-compliant mode (not official builds)
• v8_inspector, a new experimental debugging protocol

These patches will also be included in the new v7.x Current (non-LTS) release series which is due to be launched later this month.

• Node.js v6 is affected
• Node.js v4 (LTS "Argon") is not affected
• Node.js v0.12 (Maintenance) is not affected
• Node.js v0.10 (Maintenance) is not affected

CVE-2016-5180 "ares_create_query single byte out of buffer write"

A security vulnerability has been discovered in the c-ares library that is bundled with all versions of Node.js. Due to the difficulty of triggering and making use of this vulnerability we currently consider this a low-severity security flaw for Node.js users.

The patch has already been included in Node.js v6 and we will ensure that patched versions of the remaining affected versions are made available by Tuesday the 18th.

• Node.js v6 is not affected
• Node.js v4 (LTS "Argon") is affected
• Node.js v0.12 (Maintenance) is affected
• Node.js v0.10 (Maintenance) is affected

We apologise for the short notice of these releases.

Updates are now available for all active Node.js release lines. These include the recently published versions of OpenSSL 1.0.1 and 1.0.2 as well as fixes for some Node.js-specific security-related defects.

The OpenSSL security fixes included in these updates that impact Node.js are:

• CVE-2016-6304: "OCSP Status Request extension unbounded memory growth"
• CVE-2016-2183: "SWEET32 Mitigation"
• CVE-2016-6303: "OOB write in MDC2_Update()"
• CVE-2016-2178: "Constant time flag not preserved in DSA signing"
• CVE-2016-6306: "Certificate message OOB reads"

Details on each of these can be found in the original post below.

Additionally, OpenSSL 1.0.2j was released yesterday and included a fix for CVE-2016-7052. This flaw was introduced in last week's 1.0.2i release, and therefore does not directly impact Node.js.

Node.js-specific security flaws

Also included, are a number of fixes unrelated to the recent OpenSSL releases.

CVE-2016-7099: Wildcard certificates not properly validated

This is a high severity defect that would allow a malicious TLS server to serve an invalid wildcard certificate for its hostname and be improperly validated by a Node.js client. This is due to a flaw in the validation of *. in the wildcard name string.

Originally reported by Alexander Minozhenko and James Bunton (Atlassian).

All versions of Node.js are affected.

CVE-2016-5325: reason argument in ServerResponse#writeHead() not properly validated

This is a low severity security defect that that may make HTTP response splitting possible under certain circumstances. If user-input is passed to the reason argument to writeHead() on an HTTP response, a new-line character may be used to inject additional responses.

The fix for this defect introduces a new case where throw may occur when configuring HTTP responses. Users should already be adopting try/catch here.

This was originally reported independently by Evan Lucas and Romain Gaucher.

All versions of Node.js are affected.

Remove support for loading dynamic third-party engine modules

This is a low severity security defect. By default, OpenSSL will load a list of third-party engine modules when the ENGINE_load_builtin_engines() function is used. These are normally not present on a user's system. An attacker may be able to make Node.js load malicious code by masquerading it as one of the dynamic engine modules.

This defect primarily impacts Windows due to the standard DLL search paths. However, UNIX users may also be at risk with a poorly configured LD_LIBRARY_PATH environment variable or /etc/ld.so.conf path list.

Originally reported by Ahmed Zaki (Skype).

• Node.js v6 (Current) is affected
• Node.js v4 (LTS "Argon") is affected
• Node.js v0.12 (Maintenance) is affected
• Node.js v0.10 (Maintenance) is not affected

Downloads

• Node.js v6.7.0
• Node.js v4.6.0 (LTS "Argon")
• Node.js v0.12.16 (Maintenance)
• Node.js v0.10.47 (Maintenance)

Please note that this may be the final release of the v0.10 line as support ends in October. Please upgrade to v4 or above if you have not already done so.

Original post is included below

The Node.js project has scheduled updates for all of its active release lines to patch a number of security flaws. These flaws include some of those announced by the OpenSSL project as well as a number of Node.js-specific issues. We do not consider any of these updates to be critical. However, it is strongly recommended that all production instances of Node.js be upgraded when the releases are made available.

We intend to make releases available on or soon after the evening of Tuesday, the 27th of September, 2016, UTC (midday US time).

We consider some of the patches in these releases to be API breaking changes which would normally warrant an increase in the major-version number of Node.js. However, in accordance with our security procedures, we will be delivering these changes in minor-version increases (the y in x.y.z) where appropriate, and patch-version increases in v0.10 an v0.12 releases.

These are the expected version numbers for the releases:

• Node.js v6.7.0 (Current)
• Node.js v4.6.0 (LTS "Argon")
• Node.js v0.12.16 (Maintenance)
• Node.js v0.10.47 (Maintenance)

Additional notes:

• As per our LTS schedule, support for Node.js v0.10 will cease in October. Therefore, this may be the final release of Node.js v0.10. If you are still using v0.10 in production, it is essential that you plan for a migration to v4 (LTS "Argon") or v6 (LTS to be announced in October) as soon as possible.
• In accordance with our security release procedures, we will be limiting changes included in the LTS and Maintenance lines (v4, v0.12, and v0.10) for these updates to only security-related and other critical fixes that provide for maximum stability for users.

Node.js-specific security flaws

Included in these releases will be a number of fixes unrelated to the recent OpenSSL releases. These include:

• A high-severity flaw relating to the processing of TLS certificates, impacting all versions of Node.js
• A low-severity native code injection vulnerability on Windows, impacting all versions of Node.js
• A low-severity HTTP validation error, impacting all versions of Node.js

Full disclosure of fixed vulnerabilities will be provided after all releases are made available for download.

September OpenSSL Releases

The OpenSSL project has announced the general availability of versions 1.0.2i (to be included in Node.js v4 and above) and 1.0.1u (to be included in Node.js v0.10 and v0.12). Our crypto team (Shigeki Ohtsu, Fedor Indutny, and Ben Noordhuis) have performed an analysis of the defects addressed in the OpenSSL releases to determine their impact on Node.js. The results of this analysis are included below.

CVE-2016-6304: OCSP Status Request extension unbounded memory growth

A malicious client can exhaust a server's memory, resulting in a denial of service (DoS) by sending very large OCSP Status Request extensions in a single session.

This flaw is labelled high severity due to the ease of use for a DoS attack and Node.js servers using TLS are vulnerable.

Assessment: All versions of Node.js are affected by this vulnerability.

CVE-2016-6305: SSL_peek() hang on empty record

OpenSSL 1.1.0 SSL/TLS will hang during a call to SSL_peek() if the peer sends an empty record.

Node.js is not yet dependent on OpenSSL 1.1.0 so it is not impacted by this flaw.

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability.

CVE-2016-2183: SWEET32 Mitigation

SWEET32 is a new attack on older block cipher algorithms that use a block size of 64 bits.

As mitigation, OpenSSL has moved DES-based ciphers from the HIGH to MEDIUM group. As Node.js includes HIGH, but not MEDIUM, in its default suite, affected ciphers are no longer included unless the default suite is not used. Node's default TLS cipher suite can be found in the API documentation.

Assessment: All versions of Node.js are affected by this vulnerability.

CVE-2016-6303: OOB write in MDC2_Update()

An overflow can occur in MDC2_Update() under certain circumstances resulting in an out of bounds (OOB) error. This attack is impractical on most platforms due to the size of data required to trigger the OOB error.

Node.js is impacted by this flaw but due to the impracticalities of exploiting it and the very low usage of of MDC-2, it is very low severity for Node.js users.

Assessment: All versions of Node.js are affected by this vulnerability.

CVE-2016-6302: Malformed SHA512 ticket DoS

If a server uses SHA512 for TLS session ticket HMAC, it is vulnerable to a denial of service (DoS) attack via crash upon receiving a malformed ticket.

Node.js does not use SHA512 for session tickets and is therefore not impacted by this flaw.

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability.

CVE-2016-2182: OOB write in BN_bn2dec()

An out of bounds (OOB) write can occur in BN_bn2dec() if an application uses this function with an overly large BIGNUM. TLS is not affected because record limits will reject an oversized certificate before it is parsed.

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability.

CVE-2016-2180: OOB read in TS_OBJ_print_bio()

An out of bounds (OOB) read can occur when large OIDs are presented via TS_OBJ_print_bio().

Node.js does not make use of the Time Stamp Authority functionality in OpenSSL and is therefore believed to be unaffected by this flaw.

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability.

CVE-2016-2177: Pointer arithmetic undefined behaviour

This programming flaw is described in the post at https://www.openssl.org/blog/blog/2016/06/27/undefined-pointer-arithmetic/.

It is unlikely that Node.js users are directly impacted by this.

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability.

CVE-2016-2178: Constant time flag not preserved in DSA signing

A flaw in the OpenSSL DSA implementation means that a non-constant time codepath is followed for certain operations. This has been demonstrated through a cache-timing attack to be sufficient for an attacker to recover the private DSA key.

This is very low severity for Node.js users due to the difficulty in taking advantage of this attack and because DSA is very rarely used.

Assessment: All versions of Node.js are affected by this vulnerability.

CVE-2016-2179: DTLS buffered message DoS

In a DTLS connection where handshake messages are delivered out-of-order, those messages that OpenSSL is not yet ready to process will be buffered for later use. This can be exploited to cause a denial of service (DoS) via memory exhaustion.

As Node.js does not support DTLS, users are not impacted by this flaw.

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability.

CVE-2016-2179: DTLS replay protection DoS

A flaw in the DTLS replay attack protection mechanism that would allow an attacker to force a server to drop legitimate packets for a DTLS connection, resulting in a denial of service (DoS) for that connection.

As Node.js does not support DTLS, users are not impacted by this flaw.

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability.

CVE-2016-6306: Certificate message OOB reads

Some missing message length checks can result in out of bounds (OOB) reads of up to 2 bytes beyond an allocated buffer. There is a theoretical denial of service (DoS) risk. This only impacts a client or a server which enables client authentication.

Node.js is impacted by this low severity flaw.

Assessment: All versions of Node.js are affected by this vulnerability.

CVE-2016-6307: Excessive allocation of memory in tls_get_message_header()

Excessive allocation of memory in OpenSSL 1.1.0 can be achieved by manipulating the length component of a TLS header.

Node.js is not yet dependent on OpenSSL 1.1.0 so it is not impacted by this flaw.

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability.

CVE-2016-6308: Excessive allocation of memory in dtls1_preprocess_fragment()

A flaw that is similar to CVE-2016-6307 but impacting DTLS.

Node.js is not yet dependent on OpenSSL 1.1.0, nor does it implement DTLS, so it is not impacted by this flaw.

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability.

Contact and future updates

Please monitor the nodejs-sec Google Group for updates: https://groups.google.com/forum/#!forum/nodejs-sec or the Node.js website for release announcements: https://nodejs.org/en/blog/

The current Node.js security policy can be found at https://nodejs.org/en/security/.

Please contact security@nodejs.org if you wish to report a vulnerability in Node.js.

Subscribe to the low-volume announcement-only nodejs-sec mailing list at https://groups.google.com/forum/#!forum/nodejs-sec to stay up to date on security vulnerabilities and security-related releases of Node.js and the projects maintained in the nodejs GitHub organisation.

After a thorough assessment of the fixes we were planning on including, we have decided to scale back this security update to only include a subset. We are deferring some fixes while we improve the required API changes in order to decrease the disruption that it may cause to users. The vulnerabilities that the deferred fixes address are low severity.

Note that there is no Node.js v6 release in this set of updates as it is not impacted by the vulnerabilities being patched.

The fixes we are including in this update are:

CVE-2016-1669 Buffer overflow in V8

Under certain conditions, V8 may improperly expand memory allocations in the Zone::New function. This could potentially be used to cause a Denial of Service via buffer overflow or as a trigger for a remote code execution.

Although this bug is marked as high severity in the corresponding Chromium release (50.0.2661.102), our assessment is that this is low severity for Node.js users due to the level of difficulty in making use of this vulnerability. However, users are encouraged to upgrade their Node.js installation to ensure they are properly protected.

• Node.js v6 (Current) is not affected as of v6.2.0 due to an update to V8 5.0.71.47, versions prior to v6.2.0 are affected
• Node.js v5 is affected
• Node.js v4 (LTS "Argon") is affected
• Node.js v0.12 (Maintenance) is affected
• Node.js v0.10 (Maintenance) is affected

CVE-2014-9748 Unsafe use of read/write locks on Windows 2003 and XP in libuv

Prior to libuv version 1.7.4, a flaw in the read/write locks implementation for Windows XP and Windows 2003 could lead to unlocking a CRITICAL_SECTION on the wrong thread, resulting in undefined and potentially unsafe behavior. This problem was identified by Zhou Ran. Node.js v4 and later are not affected as the usage of read/write was replaced with simple mutexes. Further details can be found on the libuv repository.

• Node.js v6 (Current) is not affected
• Node.js v5 is not affected
• Node.js v4 (LTS "Argon") is not affected
• Node.js v0.12 (Maintenance) is affected
• Node.js v0.10 (Maintenance) is affected

Downloads

• Node.js v5.12.0
• Node.js v4.4.6 (LTS "Argon")
• Node.js v0.12.15 (Maintenance)
• Node.js v0.10.46 (Maintenance)

Please note that this may be the final release of the v5.x line as support ends on the 30th of June.

(Update 16-June-2016) Adjusted release schedule

Unfortunately we have to announce that we are delaying our security releases by a week. We have concluded that pushing forward with the releases this week would unnecessarily compromise the quality of the fixes we intended to include. Instead, we will be taking the extra time to be sure that we are delivering the stability and quality that Node.js users expect.

We now intend to make releases available on or soon after Thursday, the 23rd of June, 2016, UTC.

Original post is included below

The Node.js project has scheduled updates for all of its active release lines to patch two security flaws and one security-related usability flaw. We do not consider any of our updates to be critical, however, it is recommended that all production instances of Node.js be upgraded when the releases are made available.

We intend to make releases available on or soon after Thursday, the 16th of June, 2016, UTC.

We consider some of the patches in these releases to be API breaking changes which would normally warrant an increase in the major-version number of Node.js. However, in accordance with our security procedures we will be delivering these changes in minor-version increases (the y in x.y.z) where appropriate, and patch-version increases in v0.10 an v0.12 releases.

Therefore, we expect to be releasing:

• Node.js v6.3.0 (Current)
• Node.js v5.12.0
• Node.js v4.5.0 (LTS "Argon")
• Node.js v0.12.15 (Maintenance)
• Node.js v0.10.46 (Maintenance)

While we anticipate minimal impact from the breaking changes, please be sure to review the details once they are released and make an assessment regarding the impact on your applications.

Additional notes:

• It is our intention to stop releasing critical updates for the v5 release line at the end of this month, you should migrate to to v6 or v4 LTS if you have not already done so.
• In accordance with our security release procedures, we will be limiting changes included in the LTS and Maintenance lines (v4, v0.12 and v0.10) for these updates to only security-related and critical fixes to provide maximum stability for users.

V8 security defect

The V8 team has identified and patched a potential security vulnerability. We will be backporting the fix to all active release lines of Node.js. Our current assessment is that this vulnerability should be considered low-severity for Node.js users with an exploit being very difficult to develop and execute.

All versions of Node.js are affected.

HTTP processing security defect (CVE-2016-5325)

We will be including fixes relating to Node.js HTTP processing. We categorise these as low-severity and are not aware of any existing exploits leveraging the defects. Full details are embargoed until new releases are available.

Common Vulnerability Scoring System (CVSS) v3 Base Score:

Refer to the CVSS v3 Specification for details on the meanings and application of the vector components.

All versions of Node.js are affected.

This defect will identified as CVE-2016-5325

Security-related HTTP client usability flaw

We intend to also include a patch for HTTP client in Node.js. While we do not consider this to be strictly a security concern for Node.js core, it poses a usability concern that may easily enable users to write code that exposes vulnerabilities in their applications.

All versions of Node.js are affected.

Contact and future updates

Please monitor the nodejs-sec Google Group for updates: https://groups.google.com/forum/#!forum/nodejs-sec or the Node.js website for release announcements: https://nodejs.org/en/blog/

The current Node.js security policy can be found at https://nodejs.org/en/security/.

Please contact security@nodejs.org if you wish to report a vulnerability in Node.js.

Subscribe to the low-volume announcement-only nodejs-sec mailing list at https://groups.google.com/forum/#!forum/nodejs-sec to stay up to date on security vulnerabilities and security-related releases of Node.js and the projects maintained in the nodejs GitHub organisation.

The following releases have been made available to include the security updates to OpenSSL discussed in the post below. Please upgrade your Node.js installation as soon as possible in order to be protected against the disclosed vulnerabilities.

• Node v6.1.0 (Current): http://nodejs.org/en/blog/release/v6.1.0/
• Node v5.11.1: http://nodejs.org/en/blog/release/v5.11.1/
• Node v4.4.4 (LTS): http://nodejs.org/en/blog/release/v4.4.4/
• Node v0.12.14 (Maintenance): http://nodejs.org/en/blog/release/v0.12.14/
• Node v0.10.45 (Maintenance): http://nodejs.org/en/blog/release/v0.10.45/

Original post is included below, along with an update containing a risk assessment

The OpenSSL project has announced that that they will be releasing versions 1.0.1t and 1.0.2h this week, on Tuesday the 3rd of May, UTC. The releases will fix "several security defects" that are labelled as "high" severity under their security policy, meaning they are:

... issues that are of a lower risk than critical, perhaps due to affecting less common configurations, or which are less likely to be exploitable.

Node.js v0.10 and v0.12 both use OpenSSL v1.0.1 and Node.js v4, v5 and v6 use OpenSSL v1.0.2 and releases from nodejs.org and some other popular distribution sources are statically compiled. Therefore, all active release lines are impacted by this update.

At this stage, due to embargo, it is uncertain the exact nature of these defects, nor what impact they will have on Node.js users, if any. We will proceed as follows:

Within approximately 24 hours of the OpenSSL releases, our crypto team will make an impact assessment for Node.js users of the OpenSSL releases. This information may vary depending for the different active release lines and will be posted here.

As part of that impact assessment we will announce our release plans for each of the active release lines to take into account any impact. Please be prepared for the possibility of important updates to Node.js v0.10, v0.12, v4, v5 and v6 soon after Tuesday, the 3rd of May. It is likely that if upgrades are required that they will be ready on or after Thursday, the 5th of May.

Note that Node.js v5 will be supported until June and will therefore be included in this set of releases.

Please monitor the nodejs-sec Google Group for updates, including an impact assessment and updated details on release timing within approximately 24 hours after the OpenSSL release: https://groups.google.com/forum/#!forum/nodejs-sec

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/.

Please contact security@nodejs.org if you wish to report a vulnerability in Node.js.

Subscribe to the low-volume announcement-only nodejs-sec mailing list at https://groups.google.com/forum/#!forum/nodejs-sec to stay up to date on security vulnerabilities and security-related releases of Node.js and the projects maintained in the nodejs GitHub organisation.

(Update 4-May-2016) OpenSSL Impact Assessment

Our crypto team (Ben Noordhuis, Shigeki Ohtsu and Fedor Indutny) have performed an analysis of the defects addressed in this week's OpenSSL releases, 1.0.2h and 1.0.1t. The results of this analysis are included below.

We will be producing new versions this week for all of our active release lines containing the new versions of OpenSSL in order to provide security assurance. We will provide an update here once all releases are available. We anticipate that they will be available on, or soon after, Thursday the 5th of May, UTC.

CVE-2016-2107: Padding oracle in AES-NI CBC MAC check

A man-in-the-middle (MITM) attacker may be able to execute a padding oracle attack to decrypt traffic when a connection uses an AES-CBC cipher and the server runs on an Intel CPU supporting AES-NI. This is a common configuration for TLS servers.

The OpenSSL project has labelled this vulnerability high severity.

Assessment: All versions of Node.js are affected by this vulnerability.

CVE-2016-2105: EVP_EncodeUpdate overflow

An overflow can occur in the OpenSSL EVP_EncodeUpdate() function which is used for Base64 encoding of binary data. An attacker must be able to supply large amounts of input data in order to cause an overflow.

Node.js uses the EVP_EncodeUpdate() internally during calls to crypto.Certificate#exportPublicKey() for SPKAC Certificate Signing Requests. User-supplied data must be passed to this method for applications to be vulnerable. This method has been available since Node.js v0.12.

The OpenSSL project has labelled this vulnerability low severity.

• Node.js v0.10 is unaffected
• Node.js v0.12, v4, v5 and v6 are affected

CVE-2016-2108: Memory corruption in the ASN.1 encoder

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability.

CVE-2016-2106: EVP_EncryptUpdate overflow

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability

CVE-2016-2109: ASN.1 BIO excessive memory allocation (CVE-2016-2109)

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability

CVE-2016-2176: EBCDIC overread

Assessment: All versions of Node.js are believed to be unaffected by this vulnerability

The primary npm registry has, since late 2014, used HTTP bearer tokens to authenticate requests from the npm command-line interface. Due to a design flaw in the CLI, these bearer tokens were sent with every request made by the CLI for logged-in users, regardless of the destination of the request. They should instead only be included for requests made against the registry or registries used for the current install.

This flaw allows an attacker to set up an HTTP server that could collect authentication information they could use to impersonate the users whose tokens they collected. This impersonation would allow them to do anything the compromised users could do, including publishing new versions of packages.

This flaw has been fixed in npm@2.15.1 (npm LTS) and npm@3.8.3. The npm CLI team believes that the fix won't break any existing registry setups, but due to the large number of registry software suites in the wild, it's possible that this change will be breaking in some cases. If so, please file an issue describing the software you're using and how it broke, and the team will work with you to mitigate the breakage.

If you believe that your bearer token may have been leaked, it should be sufficient to invalidate your current npm bearer tokens and to rerun npm login to generate new tokens. Keep in mind that this may cause continuous integration builds in services like Travis to break, in which case you'll need to update the tokens in your CI server's configuration.

Thanks to Mitar, Will White & the team at Mapbox, Max Motovilov, and James Taylor for reporting this vulnerability to npm.

As Node.js ships with npm, releases for the active lines will be made available shortly for your convenience. Please watch the Node.js news feed for the following releases:

• v0.10 (Maintenance): Node.js v0.10.44 includes npm LTS v2.15.1. This is a major upgrade of npm from v1 which has previously been deprecated. No fix is being made available for npm v1, please upgrade to npm v2 as soon as possible.
• v0.12 (LTS): Node.js v0.12.13 includes npm LTS v2.15.1.
• v4 (LTS "Argon"): Node.js v4.4.2 includes npm LTS v2.15.1.
• v5 (Stable): Node.js v5.10.0 includes npm v3.8.3.

Update: Unfortunately the version of npm that was bundled with Node.js version v0.10.44, v0.12.13 and v4.4.2 did not include the correct version string, npm -v reports 2.15.0, however the code is v2.15.1.

Note that you can upgrade your installed version of npm manually without requiring a Node.js update by using the command npm install npm@2 -g for npm LTS v2.15.2 or npm install npm@3 -g for npm v3.8.5.

The OpenSSL project has announced that that they will be releasing versions 1.0.2g and 1.0.1s this week, on Tuesday the 1st of March, UTC. The releases will fix "several defects" that are labelled as "high" severity under their security policy, meaning they are:

... issues that are of a lower risk than critical, perhaps due to affecting less common configurations, or which are less likely to be exploitable.

Node.js v0.10 and v0.12 both use OpenSSL v1.0.1 and Node.js v4 and v5 both use OpenSSL v1.0.2 and releases from nodejs.org and some other popular distribution sources are statically compiled. Therefore, all active release lines are impacted by this update.

At this stage, due to embargo, it is uncertain the exact nature of these defects, nor what impact they will have on Node.js users, if any.

As we already had minor, non-security releases scheduled for each of our active release lines during this week and next, we will be adjusting our schedule to adapt to the OpenSSL releases depending on their impact on Node.js users.

We will therefore proceed as follows:

Within approximately 24 hours of the OpenSSL releases, our crypto team will make an impact assessment for Node.js users of the OpenSSL releases. This information may vary depending for the different active release lines and will be posted here.

As part of that impact assessment we will announce our release plans for each of the active release lines to take into account any impact. Please be prepared for the possibility of important updates to Node.js v0.10, v0.12, v4 and v5 soon after Tuesday, the 1st of March.

Node.js v0.10 (Maintenance)

A release of Node.js v0.10.43 has been proposed for this week, it currently contains fixes for domains and an important fix for a regression in http_parser that was introduced in v0.10.42. Details of the changes included in this release along with instructions on how to download and use a release candidate (v0.10.43-rc.1) can be found in https://github.com/nodejs/node/pull/5404. Node.js v0.10 users are encouraged to test the release candidate build to ensure compatibility with existing deployments.

If the OpenSSL 1.0.1s release contains important fixes that impact Node.js v0.10 we will endeavour to ensure that our v0.10.43 release contains the update.

Node.js v0.12 (LTS)

A release of Node.js v0.12.11 has been proposed for this week, it currently contains fixes for domains, an important fix for a regression in http_parser that was introduced in v0.12.10, and some other minor fixes. Details of the changes included in this release along with instructions on how to download and use a release candidate (v0.12.11-rc.1) can be found in https://github.com/nodejs/node/pull/5403. Node.js v0.12 users are encouraged to test the release candidate build to ensure compatibility with existing deployments.

If the OpenSSL 1.0.1s release contains important fixes for Node.js v0.12 we will endevour to ensure that our v0.12.11 release contains the update.

Node.js v4 (LTS "Argon")

A significant update to Node.js v4 has been proposed for next week, the 8th of March. You can read about what will be included in Node.js v4.4.0 and find release candidates to test against your deployments at https://github.com/nodejs/node/pull/5301.

If the OpenSSL 1.0.2g update includes important fixes that impact Node.js v4, we may release a v4.3.2 this week with only the security updates in order to provide a low-risk path for Node.js v4 users.

If the OpenSSL 1.0.2g update does not include important fixes that impact Node.js v4, we will continue with our planned v4.4.0 release and also attempt to include the OpenSSL 1.0.2g upgrade. Users of Node.js v4 can then upgrade to v4.4.0 in their own time and allow for proper testing of the changes included.

Node.js v5 (Stable)

A regular update to Node.js v5 has been proposed for this week. You can read about what will be included in the proposed Node.js v5.7.1 at https://github.com/nodejs/node/pull/5464. We are excluding any semver-minor changes from this release although it has fixes for some regressions

If the OpenSSL 1.0.2g release contains important fixes for Node.js v5, we will endevour to ensure that our v5.7.1 release contains the update.

Summary

• Expect an impact assessment of the OpenSSL updates within 24 hours of their release
• Expect releases of Node.js v0.10, v0.12 and v5 this week, possibly containing important security releases
• Expect a Node.js v4.4.0 release next with the possibility of a v4.3.2 security update this week

Please monitor the nodejs-sec Google Group for updates, including an impact assessment and updated details on release timing within approximately 24 hours after the OpenSSL release: https://groups.google.com/forum/#!forum/nodejs-sec

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/.

Please contact security@nodejs.org if you wish to report a vulnerability in Node.js.

Subscribe to the low-volume announcement-only nodejs-sec mailing list at https://groups.google.com/forum/#!forum/nodejs-sec to stay up to date on security vulnerabilities and security-related releases of Node.js and the projects maintained in the nodejs GitHub organisation.

(Update 2-Mar-2016) OpenSSL Impact Assessment

Our crypto team (Ben Noordhuis, Shigeki Ohtsu and Fedor Indutny) have performed an analysis of the defects addressed in this week's OpenSSL releases, 1.0.2g and 1.0.1s. The results of this analysis are included below.

The overall impact to Node.js users is low, however we will be producing new versions this week for all of our release lines containing the new versions of OpenSSL in order to provide security assurance.

• v0.10.43 (Maintenance) will proceed as planned for this week, it includes fixes for domains and an important fix for a regression in http_parser that was introduced in v0.10.42. It will also now include an upgrade of OpenSSL to 1.0.1s. An important change will be the complete removal of SSLv2 support, see CVE-2016-0800 below.
• v0.12.11 (LTS) will proceed as planned for this week, it includes fixes for domains, an important fix for a regression in http_parser that was introduced in v0.12.10, and some other minor fixes. It will also now include an upgrade of OpenSSL to 1.0.1s. An important change will be the complete removal of SSLv2 support, see CVE-2016-0800 below.
• v4.4.0 (LTS Argon) will proceed as planned for next week and will include an upgrade of OpenSSL to 1.0.2g. We will also produce a v4.3.2 this week with only the OpenSSL upgrade in order to provide a more conservative upgrade path for users wishing to use the new OpenSSL without having to also include all of the additional non-security fixes in v4.4.0.
• v5.7.1 (Stable) will proceed as planned for this week and will include fixes for a number of regressions introduced in v5.7.0 as well as an upgrade of OpenSSL to 1.0.2g.

Release announcements for each of these will be made on the Node.js blog.

CVE-2016-0800: Disable SSLv2 default build, default negotiation and weak ciphers

Assessment:

• Node.js v0.10 an v0.12 are unaffected, unless manually enabling SSLv2 with --enable-ssl2
• Node.js v4 and v5 are unaffected

This vulnerability has been labelled the DROWN Attack and only impacts servers supporting SSLv2:

Modern servers and clients use the TLS encryption protocol. However, due to misconfigurations, many servers also still support SSLv2, a 1990s-era predecessor to TLS. This support did not matter in practice, since no up-to-date clients actually use SSLv2. Therefore, even though SSLv2 is known to be badly insecure, until now, merely supporting SSLv2 was not considered a security problem, because clients never used it.

DROWN shows that merely supporting SSLv2 is a threat to modern servers and clients. It allows an attacker to decrypt modern TLS connections between up-to-date clients and servers by sending probes to a server that supports SSLv2 and uses the same private key.

It is important to note that simply supporting SSLv2 on an HTTPS socket enables this vulnerability, regardless of whether clients are actively using SSLv2.

Since Node.js v0.10.29, SSLv2 and SSLv3 have been disabled by default. It has remained possible to enable them with the --enable-ssl2 and --enable-ssl3 command-line arguments to node. As these protocols have consistently been demonstrated to be insecure, keeping SSLv2 and SSLv3 disabled has been strongly encouraged.

If you are using the --enable-ssl2 command-line argument with node then HTTPS servers are vulnerable to this attack. You should stop using this argument to avoid potential decryption of your secure data.

SSLv2 support is being removed

Given the additional barriers introduced in OpenSSL 1.0.1s to retaining SSLv2 support and the long list of known SSLv2 vulnerabilities, Node.js v0.10.43 and v0.12.11 will be completely remove SSLv2 support and the --enable-ssl2 command-line argument.

CVE-2016-0705: Fix a double-free in DSA code

Assessment: All versions of Node.js are affected, with low severity

This defect allows the use of malformed DSA to be used as a potential Denial of Service (DoS) vector or for causing memory corruption. However it is likely to be very difficult to use in practice and is therefore considered low severity for Node.js users.

CVE-2016-0798: Disable SRP fake user seed to address a server memory leak

Assessment: All versions of Node.js are unaffected

The Secure Remote Password (SRP) feature of OpenSSL is not exposed via Node.js, therefore all versions are unaffected by this defect.

CVE-2016-0797: Fix BN_hex2bn/BN_dec2bn NULL pointer deref/heap corruption

Assessment: All versions of Node.js may be affected, with low severity

This defect can cause memory corruption in certain very rare cases. Additionally, the BN_hex2bn() and BN_dec2bn() functions are not explicitly used in Node.js, however they are used internally by OpenSSL for some APIs. While we are unable to confirm with certainty at this stage, we believe that Node.js is not invoking the code paths that use these functions.

Combined with the difficulty of exploiting this defect and the likelihood that Node.js is not using APIs that require the internal use of these functions, this defect is considered to have a very low severity for Node.js users.

CVE-2016-0799: Fix memory issues in BIO_*printf functions

Assessment: All versions of Node.js are unaffected

This defect can serve as a potential Denial of Service (DoS) vector or be used for causing memory corruption. The BIO_*printf() functions are used internally by OpenSSL, however the only path by which an API call by Node.js invokes these functions has a default certificate size limit, which is not changed by Node.js, that removes the possibility of exploiting this defect. Therefore we believe that Node.js is unaffected by this defect.

CVE-2016-0702: Fix side channel attack on modular exponentiation

Assessment: All versions of Node.js are affected, with low severity

This defect has been labelled the CacheBleed Attack.

This defect enables attackers to execute side-channel attacks leading to the potential recovery of entire RSA private keys. It only affects the Intel Sandy Bridge (and possibly older) microarchitecture when using hyper-threading. Newer microarchitectures, including Haswell, are unaffected. Disabling hyper-threading is an option for mitigating against this attack.

Upon release of the OpenSSL updates we posted an impact assessment for Node.js users. We noted that the updates contained only one minor change that impacted Node.js users.

Today we have released Node.js v0.10.42 (Maintenance), v0.12.10 (LTS), v4.3.0 "Argon" (LTS) and v5.6.0 (Stable) with fixes for the announced vulnerabilities and updates to OpenSSL.

Please note that our LTS "Argon" release line has moved from v4.2.x to v4.3.x due to the security fixes enclosed. There will be no further updates to v4.2.x. Users are advised to upgrade to v4.3.0 as soon as possible.

For the purpose of understanding the impact that the fixed vulnerabilities have on your Node.js deployment and the urgency of the upgrades for your circumstances we are providing details below.

CVE-2016-2086 Request Smuggling Vulnerability

Régis Leroy reported defects in Node.js that can make request smuggling attacks possible under certain circumstances. To fix these defects, HTTP header parsing in Node.js, for both requests and responses, is moving closer to the formal HTTP specification in its handling of Content-Length.

While the impact of this vulnerability is application and network dependent, it is likely to be difficult to assess whether a Node.js deployment is vulnerable to attack. We therefore recommend that all users upgrade.

• Versions 0.10.x of Node.js are vulnerable, please upgrade to v0.10.42 (Maintenance).
• Versions 0.12.x of Node.js are vulnerable, please upgrade to v0.12.10 (LTS).
• Versions 4.x, including LTS Argon, of Node.js are vulnerable, please upgrade to v4.3.0 "Argon" (LTS).
• Versions 5.x of Node.js are vulnerable, please upgrade to v5.6.0 (Stable).

CVE-2016-2216 Response Splitting Vulnerability

Сковорода Никита Андреевич (Nikita Skovoroda / @ChALkeR) and Amit Klein (of Safebreach) separately reported ways in which HTTP header parsing in Node.js can be used to perform response splitting attacks (new-line / CRLF injection). While Node.js has been protecting against response splitting attacks by checking for CRLF characters, it is possible to compose response headers using Unicode characters that decompose to these characters, bypassing the checks previously in place.

To fix this defect, HTTP header parsing in Node.js, for both requests and responses, is moving closer to the formal HTTP specification. HTTP headers containing characters outside of the valid set for tokens will be rejected. This check is performed for both requests and responses, for Node.js HTTP servers and clients.

It is possible that there exist Node.js applications that rely on the lax behaviour of HTTP header parsing for Node.js clients and/or servers. This change is therefore a breaking change that would normally be reserved for a semver-major version increment. However, as per our LTS policy, we are introducing this change as a semver-minor in Node.js v4 (hence the move from v4.2.x to v4.3.x) and v5 and semver-patch in v0.10 and v0.12.

Node.js LTS releases, v0.10.42, v0.12.10 and v4.3.0 (but not v5.6.0) also include a new command-line argument that can be used to turn off this new strict header parsing. By supplying --security-revert=CVE-2016-2216 when starting Node.js, the previous lenient HTTP header character checks will be used instead. Use of this option is not recommended and should only be used as a temporary migration tool where the implications of reverting the new behavior are fully understood.

We recommend that all users upgrade to receive this fix.

• Versions 0.10.x of Node.js are vulnerable, please upgrade to v0.10.42 (Maintenance).
• Versions 0.12.x of Node.js are vulnerable, please upgrade to v0.12.10 (LTS).
• Versions 4.x, including LTS Argon, of Node.js are vulnerable, please upgrade to v4.3.0 "Argon" (LTS).
• Versions 5.x of Node.js are vulnerable, please upgrade to v5.6.0 (Stable).

OpenSSL upgrade summary

Node.js v0.10.42 and v0.12.10 upgrades the bundled version of OpenSSL from 1.0.1q to 1.0.1r. Full details can be found in the OpenSSL 1.0.1 changelog.

Node.js v4.3.0 and v5.6.0 upgrades the bundled version of OpenSSL from 1.0.2e to 1.0.2f. Full details can be found in the OpenSSL 1.0.2 changelog.

As per our impact assessment, the following applies to these releases:

DH small subgroups (CVE-2016-0701)

Node.js v0.10 and v0.12 are not affected by this defect.

Node.js v4 and v5 use the SSL_OP_SINGLE_DH_USE option already and are therefore not affected by this defect.

SSLv2 doesn't block disabled ciphers (CVE-2015-3197)

Node.js v0.10 and v0.12 disable SSLv2 by default and are not affected unless the --enable-ssl2 command line argument is being used (not recommended).

Node.js v4 and v5 do not support SSLv2.

An update on DHE man-in-the-middle protection (Logjam)

Previous releases of OpenSSL (since Node.js v0.10.39, v0.12.5, v4.0.0 and v5.0.0) mitigated against Logjam for TLS clients by rejecting connections from servers where Diffie-Hellman parameters were shorter than 768-bits.

The new OpenSSL release, for all Node.js lines, increases this to 1024-bits. The change only impacts TLS clients connecting to servers with weak DH parameter lengths.

Please tune in to nodejs-sec (https://groups.google.com/forum/#!forum/nodejs-sec) to receive security announcements. An Atom feed is also available for security-only posts to the nodejs.org blog.

Summary

The Node.js project will be releasing new versions across all of its active release lines early next week (possibly sooner, pending full impact assessment) to incorporate upstream patches from OpenSSL and some additional low-severity fixes relating to HTTP handling. Please read on for full details.

OpenSSL

The OpenSSL project announced this week that they will be releasing versions 1.0.2f and 1.0.1r on the 28th of January, UTC. The releases will fix two security defects that are labelled as "high" severity under their security policy, meaning they are:

... issues that are of a lower risk than critical, perhaps due to affecting less common configurations, or which are less likely to be exploitable.

Node.js v0.10 and v0.12 both use OpenSSL v1.0.1 and Node.js v4 and v5 both use OpenSSL v1.0.2 and are normally statically compiled. Therefore, all active release lines are impacted by this update.

At this stage, due to embargo, the exact nature of these defects is uncertain as well as the impact they will have on Node.js users.

Low-severity Node.js security fixes

In addition, we have some fixes to release relating to Node.js HTTP processing. We categorise these as low-severity and are not aware of any existing exploits leveraging the defects. Full details are embargoed until new releases are available.

Common Vulnerability Scoring System (CVSS) v3 Base Score:

Refer to the CVSS v3 Specification for details on the meanings and application of the vector components.

Impact

Both the OpenSSL updates and the Node.js fixes affect all actively maintained release lines of Node.js.

• Versions 0.10.x of Node.js are affected.
• Versions 0.12.x of Node.js are affected.
• Versions 4.x, including LTS Argon, of Node.js are affected.
• Versions 5.x of Node.js are affected.

Release timing

As the OpenSSL release is planned for late in the week, we are currently planning on deferring Node.js releases until early next week due to the complexity of the upgrade process and a preference for not releasing security fixes at the end of the work-week or on the weekend.

Releases will be available at, or shortly after, Monday the 1st of February, 11pm UTC (Monday the 1st of February, 3pm Pacific Time) along with disclosure of the details defects to allow for complete impact assessment by users.

However, when details of the OpenSSL defects are released on the 28th, our crypto team will be making a more detailed assessment on the likely severity for Node.js users. In the event that the team determines that the fixes are critical in nature for Node.js users we may choose to expedite releases for Friday or Saturday in order to ensure that users have the ability to protect their deployments against a disclosed vulnerability.

Please monitor the nodejs-sec Google Group for updates, including a decision within 24 hours after the OpenSSL release regarding release timing, and full details of the defects upon eventual release: https://groups.google.com/forum/#!forum/nodejs-sec

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/.

Please contact security@nodejs.org if you wish to report a vulnerability in Node.js.

Subscribe to the low-volume announcement-only nodejs-sec mailing list at https://groups.google.com/forum/#!forum/nodejs-sec to stay up to date on security vulnerabilities and security-related releases of Node.js and the projects maintained in the nodejs GitHub organisation.

(Update 29-Jan-2016) OpenSSL Impact Assessment

OpenSSL versions 1.0.1r and 1.0.21 have been released, the announcement can be found here: https://mta.openssl.org/pipermail/openssl-announce/2016-January/000061.html

Our team has made an assessment of the impact of the disclosed defects and concluded that there is no urgency in releasing patched versions of Node.js in response to this release. Therefore, we will be proceeding as planned and attempt to release new versions of each of our active release lines on or after Monday the 1st of February, 11pm UTC (Monday the 1st of February, 3pm Pacific Time). Please note that this is simply an approximation of release timing. Please tune in to nodejs-sec (https://groups.google.com/forum/#!forum/nodejs-sec) where we will announce the availability of releases.

Details

DH small subgroups (CVE-2016-0701)

Node.js v0.10 and v0.12 are not affected by this defect.

Node.js v4 and v5 use the SSL_OP_SINGLE_DH_USE option already and are therefore not affected by this defect.

SSLv2 doesn't block disabled ciphers (CVE-2015-3197)

Node.js v0.10 and v0.12 disable SSLv2 by default and are not affected unless the --enable-ssl2 command line argument is being used (not recommended).

Node.js v4 and v5 do not support SSLv2.

An update on DHE man-in-the-middle protection (Logjam)

Previous releases of OpenSSL (since Node.js v0.10.39, v0.12.5, v4.0.0 and v5.0.0) mitigated against Logjam for TLS clients by rejecting connections from servers where Diffie-Hellman parameters were shorter than 768-bits.

The new OpenSSL release, for all Node.js lines, increases this to 1024-bits. The change only impacts TLS clients connecting to servers with weak DH parameter lengths.

(Update 30-Jan-2016) Release postponement

The announced security releases will not go ahead for the 1st of February as previously announced. Instead, our new target for release will be on or shortly after Tuesday, the 9th of February, 11pm UTC (Tuesday, the 9th of February, 3pm Pacific Time).

The planned fixes include a backward-incompatible change that, under normal circumstances, would be deferred until the next major-version of Node.js, v6. However, because the fix addresses a security concern that exists across all release lines (including our LTS lines: v4, v0.12 and v0.10) we require the additional time to further review the changes and consider how best to achieve minimal impact to users.

We apologise for any inconvenience this schedule change may cause.

Please tune in to nodejs-sec (https://groups.google.com/forum/#!forum/nodejs-sec) to be notified of any further updates.

Today we have released Node.js v0.10.41 (Maintenance), v0.12.9 (LTS), v4.2.3 "Argon" (LTS) and v5.1.1 (Stable) with fixes for the announced vulnerabilities and updates to OpenSSL.

For the purpose of understanding the impact that the fixed vulnerabilities have on your Node.js deployment and the urgency of the upgrades for your circumstances we are providing details below.

CVE-2015-8027 Denial of Service Vulnerability

This critical denial of service (DoS) vulnerability impacts all versions of v0.12.x through to v5.x, inclusive. The vulnerability was discovered by Node.js core team member Fedor Indutny and relates to HTTP pipelining. Under certain conditions an HTTP socket may no longer have a parser associated with it but a pipelined request can trigger a pause or resume on the non-existent parser thereby causing an uncaughtException to be thrown. As these conditions can be created by an external attacker and cause a Node.js service to be shut down we consider this a critical vulnerability. It is recommended that users of impacted versions of Node.js exposing HTTP services upgrade to the appropriate patched versions as soon as practical.

• Versions 0.10.x of Node.js are not affected.
• Versions 0.12.x of Node.js are vulnerable, please upgrade to v0.12.9 (LTS).
• Versions 4.x, including LTS Argon, of Node.js are vulnerable, please upgrade to v4.2.3 "Argon" (LTS).
• Versions 5.x of Node.js are vulnerable, please upgrade to v5.1.1 (Stable).

CVE-2015-6764 V8 Out-of-bounds Access Vulnerability

A bug was discovered in V8's implementation of JSON.stringify() that can result in out-of-bounds reads on arrays. The patch was included in this week's update of Chrome Stable. While this bug is high severity for browsers, it is considered lower risk for Node.js users as it requires the execution of third-party JavaScript within an application in order to be exploitable.

Node.js users who expose services that process untrusted user-supplied JavaScript are at obvious risk. However, we recommend that all users of impacted versions of Node.js upgrade to the appropriate patched version in order to protect against malicious third-party JavaScript that may be executed within a Node.js process by other means.

• Versions 0.10.x of Node.js are not affected.
• Versions 0.12.x of Node.js are not affected.
• Versions 4.x, including LTS Argon, of Node.js are vulnerable, please upgrade to v4.2.3 "Argon" (LTS).
• Versions 5.x of Node.js are vulnerable, please upgrade to v5.1.1 (Stable).

CVE-2015-3193 OpenSSL BN_mod_exp may produce incorrect results on x86_64

A bug exists in OpenSSL v1.0.2 in the Montgomery squaring procedure on the x64 architecture that expose potential attack vectors. Attacks against RSA and DSA are considered possible but with a very high degree of difficulty. Attacks against DHE key exchange is considered feasible but difficult. EC algorithms are not vulnerable. Node.js TLS servers using DHE key exchange are considered at highest risk although it is believed that Node.js' existing use of SSL_OP_SINGLE_DH_USE may make DHE attacks impractical. Details are available at http://openssl.org/news/secadv/20151203.txt.

OpenSSL v1.0.2 is used in Node.js v4.x LTS and v5.x. It is strongly recommended that Node.js users exposing TLS servers upgrade to patched versions as soon as practical.

• Versions 0.10.x of Node.js are not affected.
• Versions 0.12.x of Node.js are not affected.
• Versions 4.x, including LTS Argon, of Node.js are vulnerable, please upgrade to v4.2.3 "Argon" (LTS).
• Versions 5.x of Node.js are vulnerable, please upgrade to v5.1.1 (Stable).

CVE-2015-3194 OpenSSL Certificate verify crash with missing PSS parameter

A bug exists in OpenSSL v1.0.1 and v1.0.2 that may cause a crash during certificate verification procedures when supplied with a malformed ASN.1 signature using the RSA PSS algorithm. This may be used as a the basis of a denial of service (DoS) attack against Node.js TLS servers using client authentication. Node.js TLS clients are also impacted if supplied with malformed certificates for verification. Details are available at http://openssl.org/news/secadv/20151203.txt.

OpenSSL v1.0.0 is used in Node.js v0.10.x and v0.12.x. OpenSSL v1.0.2 is used in Node.js v4.x LTS and v5.x. It is strongly recommended that Node.js users employing either TLS client or server code upgrade as soon as practical.

• Versions 0.10.x of Node.js are vulnerable, please upgrade to v0.10.41 (Maintenance).
• Versions 0.12.x of Node.js are vulnerable, please upgrade to v0.12.9 (LTS).
• Versions 4.x, including LTS Argon, of Node.js are vulnerable, please upgrade to v4.2.3 "Argon" (LTS).
• Versions 5.x of Node.js are vulnerable, please upgrade to v5.1.1 (Stable).

Note: Node.js users are not considered vulnerable to the two additional announced OpenSSL vulnerabilities: CVE-2015-3195 "X509_ATTRIBUTE memory leak" and CVE-2015-3196 "Race condition handling PSK identify hint". However, fixes for these bugs are included with the new versions of OpenSSL bundled with the newly patched versions of Node.js.

MODERATE Severity. This includes issues like crashes in client applications, flaws in protocols that are less commonly used (such as DTLS), and local flaws. These will in general be kept private until the next release, and that release will be scheduled so that it can roll up several such flaws at one time.

Node.js versions v0.10.x and v0.12.x depend on OpenSSL v1.0.1 and versions v4.x (LTS Argon) and v5.x depend on OpenSSL v1.0.2. As the Node.js build process statically links OpenSSL into binaries, we will be required to release patch-level updates to all of our actively supported versions to include the upstream fixes. While we are unaware of the exact nature of the OpenSSL vulnerabilities being fixed, we must consider it likely that Node.js releases will be required in order to protect users.

Since the OpenSSL release schedule is two days after our announced updates for v0.12.x, v4.x and v5.x, we have decided to postpone our security releases to coincide with OpenSSL release availability. We will also be including v0.10 in our set of releases.

Therefore, we are moving our planned security releases for Node.js from Wednesday the 2nd of December 2015, UTC to the Friday, the 4th of December 2015, UTC (Thursday the 3rd of December US time). We understand that the timing of this during the work-week is unfortunate but we must take into account the possibility of introducing a vulnerability gap between disclosure of OpenSSL vulnerabilities and patched releases by Node.js and therefore must respond as quickly as practical. Please be aware that patching and testing of OpenSSL updates is a non-trivial exercise and there will be significant delay after the OpenSSL releases before we can be confident that Node.js builds are stable and suitable for release.

An updated summary of the release inclusions is available below:

CVE-2015-8027 Denial of Service Vulnerability

A bug exists in Node.js, all versions of v0.12.x through to v5.x inclusive, whereby an external attacker can cause a denial of service. The severity of this issue is high and users of the affected versions should plan to upgrade when a fix is made available.

• Versions 0.10.x of Node.js are not affected.
• Versions 0.12.x of Node.js are vulnerable.
• Versions 4.x, including LTS Argon, of Node.js are vulnerable.
• Versions 5.x of Node.js are vulnerable.

CVE-2015-6764 V8 Out-of-bounds Access Vulnerability

An additional bug exists in Node.js, all versions of v4.x and v5.x, whereby an attacker may be able to trigger an out-of-bounds access and/or denial of service if user-supplied JavaScript can be executed by an application. The severity of this issue is considered medium for Node.js users, but only under circumstances where an attacker may cause user-supplied JavaScript to be executed within a Node.js application. Fixes will be shipped for the v4.x and v5.x release lines along with fixes for CVE-2015-8027.

• Versions 0.10.x of Node.js are not affected.
• Versions 0.12.x of Node.js are not affected.
• Versions 4.x, including LTS Argon, of Node.js are vulnerable.
• Versions 5.x of Node.js are vulnerable.

OpenSSL Moderate Severity Update

The OpenSSL project has announced a set of releases which contain fixes for multiple vulnerabilities, the highest severity being labelled "moderate". Consult the OpenSSL security policy for details on this definition. New releases of all actively maintained Node.js release lines are required in order to protect users against potential vulnerabilities in their applications. We do not have details on the nature of any of the included vulnerabilities or their fixes, users should plan for upgrades as soon as practical.

• Versions 0.10.x of Node.js may be vulnerable.
• Versions 0.12.x of Node.js may be vulnerable.
• Versions 4.x, including LTS Argon, of Node.js may be vulnerable.
• Versions 5.x of Node.js may be vulnerable.

• CVE-2015-8027: a high-impact denial of service vulnerability
• CVE-2015-6764: a low-impact V8 out-of-bounds access vulnerability

CVE-2015-8027 Denial of Service Vulnerability

Description and CVSS Score

A bug exists in Node.js, all versions of v0.12.x through to v5.x inclusive, whereby an external attacker can cause a denial of service. The severity of this issue is high (see CVSS scoring below) and users of the affected versions should plan to upgrade when a fix is made available.

• Versions 0.10.x of Node.js are not affected.
• Versions 0.12.x of Node.js are vulnerable.
• Versions 4.x, including LTS Argon, of Node.js are vulnerable.
• Versions 5.x of Node.js are vulnerable.

Full details of this vulnerability are embargoed until new releases are available on Wednesday the 2nd of December 2015, UTC (Tuesday the 1st of December US time).

Common Vulnerability Scoring System (CVSS) v3 Base Score:

Complete CVSS v3 Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:F/RL:O/RC:R/CR:L/IR:L/AR:H/MAV:N/MAC:L/MPR:N/MUI:N/MS:U/MC:N/MI:N/MA:H. Refer to the CVSS v3 Specification for details on the meanings and application of the vector components.

CVE-2015-8027 is listed on the MITRE CVE dictionary and NIST NVD.

CVE-2015-6764 V8 Out-of-bounds Access Vulnerability

Description and CVSS Score

An additional bug exists in Node.js, all versions of v4.x and v5.x, whereby an attacker may be able to trigger an out-of-bounds access and/or denial of service if user-supplied JavaScript can be executed by an application. The severity of this issue is considered medium for Node.js users (see CVSS scoring below), but only under circumstances where an attacker may cause user-supplied JavaScript to be executed within a Node.js application. Fixes will be shipped for the v4.x and v5.x release lines along with fixes for CVE-2015-8027.

• Versions 0.10.x of Node.js are not affected.
• Versions 0.12.x of Node.js are not affected.
• Versions 4.x, including LTS Argon, of Node.js are vulnerable.
• Versions 5.x of Node.js are vulnerable.

Full details of this vulnerability are embargoed until new releases are available on Wednesday the 2nd of December 2015, UTC (Tuesday the 1st of December US time).

Common Vulnerability Scoring System (CVSS) v3 Base Score:

Complete CVSS v3 Vector: CVSS:3.0/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H/E:U/RL:O/RC:R/CR:L/IR:L/AR:M/MAV:N/MAC:H/MPR:N/MUI:N/MS:U/MC:N/MI:N/MA:H. Refer to the CVSS v3 Specification for details on the meanings and application of the vector components.

CVE-2015-6764 is listed on the MITRE CVE dictionary and NIST NVD.

Action and updates

New releases of v0.12.x, v4.x and v5.x on Wednesday the 2nd of December 2015, UTC will be made available with appropriate fixes for CVE-2015-8027 and CVE-2015-6764 (for v4.x and v5.x only) along with disclosure of the details of the bug to allow for complete impact assessment by users.

Contact and future updates

Please contact security@nodejs.org if you wish to report a vulnerability in Node.js.

Please subscribe to the low-volume announcement-only nodejs-sec mailing list at https://groups.google.com/forum/#!forum/nodejs-sec to stay up to date with security vulnerabilities in Node.js and the projects maintained in the nodejs GitHub organisation.

This issue was identified by Tom Steele of ^Lift Security and Fedor Indunty, Node.js Core Team member worked closely with the V8 team to find our resolution.

The V8 issue is described here https://codereview.chromium.org/339883002

It has landed in the Node repository here: https://github.com/joyent/node/commit/530af9cb8e700e7596b3ec812bad123c9fa06356

And has been released in the following versions:

• v0.10.30
• v0.8.28

The Fix

The backport of the fix for Node.js is

diff --git a/deps/v8/src/isolate.h b/deps/v8/src/isolate.h
index b90191d..2769ca7 100644
--- a/deps/v8/src/isolate.h
+++ b/deps/v8/src/isolate.h
@@ -1392,14 +1392,9 @@ class StackLimitCheck BASE_EMBEDDED {
  public:
   explicit StackLimitCheck(Isolate* isolate) : isolate_(isolate) { }

-  bool HasOverflowed() const {
+  inline bool HasOverflowed() const {
     StackGuard* stack_guard = isolate_->stack_guard();
-    // Stack has overflowed in C++ code only if stack pointer exceeds the C++
-    // stack guard and the limits are not set to interrupt values.
-    // TODO(214): Stack overflows are ignored if a interrupt is pending. This
-    // code should probably always use the initial C++ limit.
-    return (reinterpret_cast<uintptr_t>(this) < stack_guard->climit()) &&
-           stack_guard->IsStackOverflow();
+    return reinterpret_cast<uintptr_t>(this) < stack_guard->real_climit();
   }
  private:
   Isolate* isolate_;

Remediation

The best course of action is to patch or upgrade Node.js.

Mitigation

To mitigate against deep JSON parsing you can limit the size of the string you parse against, or ban clients who trigger a RangeError for parsing JSON.

There is no specific maximum size of a JSON string, though keeping the max to the size of your known message bodies is suggested. If your message bodies cannot be over 20K, there's no reason to accept 1MB bodies.

For web frameworks that do automatic JSON parsing, you may need to configure the routes that accept JSON payloads to have a maximum body size.

• expressjs and krakenjs used with the body-parser plugin accepts a limit parameter in your JSON config
• Hapi.js has payload.maxBytes https://github.com/spumko/hapi/blob/master/docs/Reference.md
• restify bundled bodyParser accepts a maxBodySize

• node-v0.8.27
• node-v0.10.29

First and foremost these releases address the current OpenSSL vulnerability CVE-2014-0224, for both 0.8 and 0.10 we've upgraded the version of the bundled OpenSSL to their fixed versions v1.0.0m and v1.0.1h respectively.

Additionally these releases address the fact that V8 UTF-8 encoding would allow unmatched surrogate pairs. That is to say, previously you could construct a valid JavaScript string (which are stored internally as UCS-2), pass it to a Buffer as UTF-8, send and consume that string in another process and it would fail to interpret because the UTF-8 string was invalid.

Note, the results encoded by V8 in this case are exactly what was passed into the encoding routine. There is no overflow, underflow, or the inclusion of other arbitrary memory, merely an unmatched UTF-8 surrogate resulting in invalid UTF-8.

As of these releases, if you try and pass a string with an unmatched surrogate pair, Node will replace that character with the unknown unicode character (U+FFFD). To preserve the old behavior set the environment variable NODE_INVALID_UTF8 to anything (even nothing). If the environment variable is present at all it will revert to the old behavior.

This breaks backward compatibility for the specific reason that unsanitized strings sent as a text payload for an RFC compliant WebSocket implementation should result in the disconnection of the client. If the client attempts to reconnect and receives another invalid payload it must disconnect again. If there is no logic to handle the reconnection attempts, this may lead to a denial of service attack. For instance socket.io attempts to reconnect by default.

// Prior to these releases:
new Buffer('ab\ud800cd', 'utf8');
// <Buffer 61 62 ed a0 80 63 64>

// After this release:
new Buffer('ab\ud800cd', 'utf8');
// <Buffer 61 62 ef bf bd 63 64>

// This is an explicit conversion to a Buffer, but the implicit
// .write('ab\ud800cd') also results in the same pattern
websocket.write(new Buffer('ab\ud800cd', 'utf8'));
// This would result in the client disconnecting.

Node's default encoding for strings is UTF-8, so even if you're not explicitly creating Buffers out of strings, Node may be doing so under the hood. If what you're passing is not actually UTF-8 then when you call .write(str) you could be specific and say .write(str, 'binary') which signals Node to pass the string through without interpreting it.

You can also mitigate this in pure JavaScript by sanitizing your strings, as an example see node-unicode-sanitize which will similarly replace unmatched surrogate pairs with the unknown unicode character.

Thanks to Node.js alum Felix Geisendörfer for finding, getting the fixes upstreamed, and helping with the testing and mitigation. Also for helping to inform and improve the process for Node.js security issues.

To float these fixes in your own builds you can apply the following patch with git am

• For v0.10 branch https://gist.github.com/tjfontaine/f869f373a8e9416809ba/raw/e3eb85201413a79d12ce24a7cb4b02edf0abc1a5/v0.10-invalid-utf8.patch
• For v0.8 branch https://gist.github.com/tjfontaine/f869f373a8e9416809ba/raw/8633aba88fa867a88b1b3ab88d13671a78dab187/v0.8-invalid-utf8.patch

We recommend that anyone using Node.js v0.8 or v0.10 to run HTTP servers in production please update as soon as possible.

• v0.10.21 http://blog.nodejs.org/2013/10/18/node-v0-10-21-stable/
• v0.8.26 http://blog.nodejs.org/2013/10/18/node-v0-8-26-maintenance/

This is fixed in Node.js by pausing both the socket and the HTTP parser whenever the downstream writable side of the socket is awaiting a drain event. In the attack scenario, the socket will eventually time out, and be destroyed by the server. If the "attacker" is not malicious, but merely sends a lot of requests and reacts to them slowly, then the throughput on that connection will be reduced to what the client can handle.

There is no change to program semantics, and except in the pathological cases described, no changes to behavior.

If upgrading is not possible, then putting an HTTP proxy in front of the Node.js server can mitigate the vulnerability, but only if the proxy parses HTTP and is not itself vulnerable to a pipeline flood DoS.

For example, nginx will prevent the attack (since it closes connections after 100 pipelined requests by default), but HAProxy in raw TCP mode will not (since it proxies the TCP connection without regard for HTTP semantics).

This addresses CVE-2013-4450.

• A carefully crafted attack request can cause the contents of the HTTP parser's buffer to be appended to the attacking request's header, making it appear to come from the attacker. Since it is generally safe to echo back contents of a request, this can allow an attacker to get an otherwise correctly designed server to divulge information about other requests. It is theoretically possible that it could enable header-spoofing attacks, though such an attack has not been demonstrated.

• Versions affected: All versions of the 0.5/0.6 branch prior to 0.6.17, and all versions of the 0.7 branch prior to 0.7.8. Versions in the 0.4 branch are not affected.
• Fix: Upgrade to v0.6.17, or apply the fix in c9a231d to your system.

Details

A few weeks ago, Matthew Daley found a security vulnerability in Node's HTTP implementation, and thankfully did the responsible thing and reported it to us via email. He explained it quite well, so I'll quote him here:

There is a vulnerability in node's http_parser binding which allows information disclosure to a remote attacker:

In node::StringPtr::Update, an attempt is made at an optimization on certain inputs (node_http_parser.cc, line 151). The intent is that if the current string pointer plus the current string size is equal to the incoming string pointer, the current string size is just increased to match, as the incoming string lies just beyond the current string pointer. However, the check to see whether or not this can be done is incorrect; "size" is used whereas "size_" should be used. Therefore, an attacker can call Update with a string of certain length and cause the current string to have other data appended to it. In the case of HTTP being parsed out of incoming socket data, this can be incoming data from other sockets.

Normally node::StringPtr::Save, which is called after each execution of http_parser, would stop this from being exploitable as it converts strings to non-optimizable heap-based strings. However, this is not done to 0-length strings. An attacker can therefore exploit the mistake by making Update set a 0-length string, and then Update past its boundary, so long as it is done in one http_parser execution. This can be done with an HTTP header with empty value, followed by a continuation with a value of certain length.

The attached files demonstrate the issue:

$ ./node ~/stringptr-update-poc-server.js &
[1] 11801
$ ~/stringptr-update-poc-client.py
HTTP/1.1 200 OK
Content-Type: text/plain
Date: Wed, 18 Apr 2012 00:05:11 GMT
Connection: close
Transfer-Encoding: chunked

64
X header:
 This is private data, perhaps an HTTP request with a Cookie in it.
0

The fix landed on 7b3fb22 and c9a231d, for master and v0.6, respectively. The innocuous commit message does not give away the security implications, precisely because we wanted to get a fix out before making a big deal about it.

The first releases with the fix are v0.7.8 and 0.6.17. So now is a good time to make a big deal about it.

If you are using node version 0.6 in production, please upgrade to at least v0.6.17, or at least apply the fix in c9a231d to your system. (Version 0.6.17 also fixes some other important bugs, and is without doubt the most stable release of Node 0.6 to date, so it's a good idea to upgrade anyway.)

I'm extremely grateful that Matthew took the time to report the problem to us with such an elegant explanation, and in such a way that we had a reasonable amount of time to fix the issue before making it public.