The Node.js inspector, in 6.x and later is vulnerable to a DNS rebinding attack which could be exploited to perform remote code execution. An attack is possible from malicious websites open in a web browser on the same computer, or another computer with network access to the computer running the Node.js process. A malicious website could use a DNS rebinding attack to trick the web browser to bypass same-origin-policy checks and to allow HTTP connections to localhost or to hosts on the local network. If a Node.js process with the debug port active is running on localhost or on a host on the local network, the malicious website could connect to it as a debugger, and get full code execution access.

Updates are now available for all active Node.js release lines. These include the fix for the vulnerabilities identified in the initial announcement (below).

In addition to the vulnerabilities in the initial announcement, we have also included a fix for a vulnerability in the Node.js inspector functionality. This is described in detail below.

We recommend that all users upgrade as soon as possible.

*   Node.js 9.10.0 (Current)
*   Node.js 8.11.0 (LTS "Carbon")
*   Node.js 6.14.0 (LTS "Boron")
*   Node.js 4.9.0 (LTS "Argon")

OpenSSL version 1.0.2o was released this week. It fixed a flaw that primarily relates to PKCS#7 that may be used to cause a denial of service (DoS) attack (CVE-2018-0739). As PKCS#7 is not currently supported by Node.js and this flaw does not impact SSL/TLS functionality, our crypto team do not believe this has any impact on Node.js users.

OpenSSL 1.0.2o also contains a small number of code changes that are part of the OpenSSL project's continued code cleanup efforts. It is included in the releases for all Node.js release lines regardless of security impact.

Node.js 6.x and later include a debugger protocol (also known as "inspector") that can be activated by the --inspect and related command line flags. This debugger service was vulnerable to a DNS rebinding attack which could be exploited to perform remote code execution.

The attack was possible from malicious websites open in a web browser on the same computer, or another computer with network access to the computer running the Node.js process. A malicious website could use a DNS rebinding attack to trick the web browser to bypass same-origin-policy checks and to allow HTTP connections to localhost or to hosts on the local network. If a Node.js process with the debug port active is running on localhost or on a host on the local network, the malicious website could connect to it as a debugger, and get full code execution access.

We updated the inspector implementation with an additional check for the browser provided Host header. If the connection is via a hostname, i.e. subject to DNS resolution, we ensure that the connection is to either localhost or localhost6 precisely.

Note that this mitigation may affect some remote debugging scenarios. For example it may no longer be possible to debug a remote computer by using a hostname. Either connect using the IP address or use an ssh-tunnel to work around this additional security check. This change is therefore a _"breaking change"_, however, as per the Node.js release plan, we are including this as a security fix on all impacted release lines as a **semver-minor** rather than semver-major increment.

Node.js versions 4.x were _not_ vulnerable as the inspector debug protocol is not available in that release line.

The severity of this vulnerability is HIGH due to remote code execution risk. However, the impact should be limited to environments (e.g. development) where debuggers are typically used.

This vulnerability was reported by Timo Schmid.

The 'path' module in the **Node.js 4.x** release line contains a potential regular expression denial of service (ReDoS) vector. The code in question was replaced in Node.js 6.x and later so this vulnerability only impacts all versions of Node.js 4.x.

The regular expression, splitPathRe, used within the 'path' module for the various path parsing functions, including path.dirname(), path.extname() and path.parse() was structured in such a way as to allow an attacker to craft a string, that when passed through one of these functions, could take a significant amount of time to evaluate, potentially leading to a full denial of service.

We have determined the security risk of this vulnerability to Node.js users to be HIGH and recommend upgrading your Node.js 4.x installations as soon as possible.

This vulnerability was reported by James Davis of Virginia Tech.

**Spaces in HTTP Content-Length header values are ignored (CVE-2018-7159)**

The HTTP parser in all current versions of Node.js ignores spaces in the Content-Length header, allowing input such as Content-Length: 1 2 to be interpreted as having a value of 12. The HTTP specification does not allow for spaces in the Content-Length value and the Node.js HTTP parser has been brought into line on this particular difference.

We have determined the security risk of this flaw to Node.js users to be VERY LOW as it is difficult, and may be impossible, to craft an attack that makes use of this flaw in a way that could not already be achieved by supplying an incorrect value for Content-Length. Vulnerabilities may exist in user-code that make incorrect assumptions about the potential accuracy of this value compared to the actual length of the data supplied. Node.js users crafting lower-level HTTP utilities are advised to re-check the length of any input supplied after parsing is complete.

This change is a _"breaking change"_ as Content-Length values containing internal spaces are now rejected in the same way that non-numeric values are rejected. However, as per the Node.js release plan, we are including this as a security fix on all release lines as a **semver-minor** rather than semver-major increment.

This flaw was reported by Сковорода Никита Андреевич (Nikita Skovoroda / @ChALkeR)

All releases also include an update to the root certificates that are bundled in the Node.js binary. This includes 8 new additional certificates and the removal of 30 certificates. Details are available in on the public Node.js repository at https://github.com/nodejs/node/pull/19322.

Node.js uses Mozilla's NSS root certificate database. Certificates are regularly added to and removed from this database. Occasionally, certificates are revoked due to compliance or trust concerns, as is the case for the WoSign / StartCom certificates that are being removed in this update.

Please note that the NODE_EXTRA_CA_CERTS environment variable may be used to add back in certificates that have been removed if required (although this is not advised). In addition the ca option may be used when creating TLS or HTTPS servers to provide a custom list of trusted certificates.

This update was submitted by Ben Noordhuis.

_**Original post is included below**_

The Node.js project will be releasing new versions for each of its supported release lines on, or shortly after, the 27th of March, 2018 (UTC). These releases will incorporate a number of security fixes and will also likely include an upgraded version of OpenSSL.

The OpenSSL team have announced that OpenSSL 1.0.2o will be made available on the 27th of March, 2018. The highest severity issue fixed in these releases is MODERATE. According to the OpenSSL Security Policy, this classification is defined as follows:

> 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.

This post will be updated with a Node.js impact assessment for the flaws addressed in this OpenSSL release. However, regardless of severity, all actively supported Node.js release lines will likely receive an upgrade from OpenSSL 1.0.2n to 1.0.2o.

**Impact:**

*   All versions of Node.js 4.x (LTS "Argon") **are** impacted
*   All versions of Node.js 6.x (LTS "Boron") **are** impacted
*   All versions of Node.js 8.x (LTS "Carbon") **are** impacted
*   All versions of Node.js 9.x (Current) **are** impacted

All versions of 4.x are vulnerable to a flaw that can be used by an external attacker to cause a denial of service (DoS). The severity of this vulnerability is HIGH, users of the impacted versions should plan to upgrade when a fix is made available.

**Impact:**

*   All versions of Node.js 4.x (LTS "Argon") **are** vulnerable
*   All versions of Node.js 6.x (LTS "Boron") **are NOT** vulnerable
*   All versions of Node.js 8.x (LTS "Carbon") **are NOT** vulnerable
*   All versions of Node.js 9.x (Current) **are NOT** vulnerable

All versions of Node.js contain a flaw in their HTTP parser whereby a malformed HTTP request may be misinterpreted. The security impact of this flaw is minimal and therefore the severity is VERY LOW. The impact relates to usability concerns but we are currently not aware of practical uses of this flaw to attack well-constructed HTTP servers.

**Impact:**

*   All versions of Node.js 4.x (LTS "Argon") **are** vulnerable
*   All versions of Node.js 6.x (LTS "Boron") **are** vulnerable
*   All versions of Node.js 8.x (LTS "Carbon") **are** vulnerable
*   All versions of Node.js 9.x (Current) **are** vulnerable

All releases will also include an update to the root certificates that are bundled in the Node.js binary. This includes 5 new additional certificates and the removal of 30 certificates. Details are available in on the public Node.js repository at https://github.com/nodejs/node/pull/19322.

Please note that the NODE_EXTRA_CA_CERTS environment variable may be used to add back in certificates that have been removed if required (although this is not advised). In addition, the ca option may be used when creating TLS or HTTPS servers to provide a custom list of trusted certificates.

Please be aware that according to the Node.js release schedule, support for Node.js 4.x (LTS "Argon") will cease on the 30th of April. As this release line is in "Maintenance" and therefore receives minimal updates, this upcoming release of Node.js 4.x may be the final version for that release line.

If you have not already migrated from Node.js 4.x to a later release line, please do so at your earliest convenience. The Node.js team recommends adopting either Node.js 6.x (LTS "Boron") or Node.js 8.x (LTS "Carbon").

Releases will be available at, or shortly after, the 27th of March, 2018 (UTC), along with disclosure of the details for the flaws addressed in each release in order to allow for complete impact assessment by users.

The current Node.js security policy can be found at https://github.com/nodejs/node/blob/HEAD/SECURITY.md#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 organization.

CVE-2018-7160: March 2018 Security Releases | Node.js

nghttp2 version >= 1.10.0 and nghttp2 <= v1.31.0 contains an Improper Input Validation CWE-20 vulnerability in ALTSVC frame handling that can result in segmentation fault leading to denial of service. This attack appears to be exploitable via network client. This vulnerability appears to have been fixed in >= 1.31.1.

We have released nghttp2 v1.31.1.

This release addresses following security issue.

**Security Advisory**

CVE-2018-1000168: Denial of service due to NULL pointer dereference.

**Vulnerability**

If ALTSVC frame is received by libnghttp2 and it is larger than it can accept, the pointer field which points to ALTSVC frame payload is left NULL. Later libnghttp2 attempts to access another field through the pointer, and gets segmentation fault.

ALTSVC frame is defined by RFC 7838.

The largest frame size libnghttp2 accept is by default 16384 bytes.

Receiving ALTSVC frame is disabled by default. Application has to enable it explicitly by calling nghttp2_option_set_builtin_recv_extension_type(opt, NGHTTP2_ALTSVC).

Transmission of ALTSVC is always enabled, and it does not cause this vulnerability.

ALTSVC frame is expected to be sent by server, and received by client as defined in RFC 7838.

Client and server are both affected by this vulnerability if the reception of ALTSVC frame is enabled. As written earlier, it is useless to enable reception of ALTSVC frame on server side. So, server is generally safe unless application accidentally enabled the reception of ALTSVC frame.

**Affected Versions**

*   Affected versions: nghttp2 >= 1.10.0 and nghttp2 <= v1.31.0
*   Not affected versions: nghttp2 >= 1.31.1

**The Solution**

Upgrade to nghttp2 v1.31.1.

If the upgrade cannot be possible:

For client, disable ALTSVC, removing the call to nghttp2_option_set_builtin_recv_extension_type(opt, NGHTTP2_ALTSVC)

For server, because it is never expected to receive ALTSVC, just remove nghttp2_option_set_builtin_recv_extension_type(opt,
NGHTTP2_ALTSVC).

**Time Line**

It was first reported to the nghttp2 team April 4 2018.

nghttp2 v1.31.1 was released on April 12 2018.

**Credits**

Reported by Jordan Zebor at F5 Networks, and James M Snell from Node.js project. Fixed by the nghttp2 team.

Thank you for all who involved.

This security advisory format is inspired from curl/libcurl project.

CVE-2018-1000168: Nghttp2 v1.31.1 - nghttp2.org

The moment module before 2.19.3 for Node.js is prone to a regular expression denial of service via a crafted date string, a different vulnerability than CVE-2016-4055.

This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.

CVE-2017-18214: nodesecurity.io - nodesecurity Resources and Information.

Node.js was affected by OpenSSL vulnerability CVE-2017-3737 in regards to the use of SSL_read() due to TLS handshake failure. The result was that an active network attacker could send application data to Node.js using the TLS or HTTP2 modules in a way that bypassed TLS authentication and encryption.

Updates are now available for all active Node.js release lines. These include the fix for the vulnerability identified in the initial announcement.

In addition the updates for 8.X and 9.X include a fix for a low severity buffer vulnerability as describe below.

We recommend that all users upgrade as soon as possible.

*   Node.js 9 (Current)
*   Node.js 8 (LTS "Carbon")
*   Node.js 6 (LTS "Boron")
*   Node.js 4 (LTS "Argon")

Node.js was affected by OpenSSL vulnerability CVE-2017-3737 in regards to the use of SSL\_read() due to TLS handshake failure. The result was that an active network attacker could send application data to Node.js using the TLS or HTTP2 modules in a way that bypassed TLS authentication and encryption.

*   The original HTTP module was not affected.
    
*   The vulnerability in the HTTP2 module (which only existing in the 8.X and 9.X lines) was fixed through nodejs/\[email protected\]. HTTP2 was previously exploitable through the submission of malicious data by an attacker.
    
*   The vulnerability in the TLS module was fixed by incorporating OpenSSL-1.0.2n into Node.js. We are not currently aware of any exploits but it was previously at a severe security risk of accepting unauthenticated data. See this advisory from OpenSSL for more details on the fixes in OpenSSL-1.0.2n secadv-20171207.txt.
    
*   The HTTPS module was not affected.
    

This vulnerability has been assigned CVE-2017-15896.

We would like to thank Matt Caswell (OpenSSL) and David Benjamin (Google) for reporting this.

Node.js had a bug in versions 8.X and 9.X which caused buffers to not be initialized when the encoding for the fill value did not match the encoding specified. For example, 'Buffer.alloc(0x100, "This is not correctly encoded", "hex");' The buffer implementation was updated such that the buffer will be initialized to all zeros in these cases.

Versions 4.X and 6.X were **not** vulnerable.

The severity of this information disclosure vulnerability was low (due to the combination of coding errors that need to have been made in order to make it exploitable) and it has been assigned CVE-2017-15897.

Note that CVE 2017-3738 of OpenSSL-1.0.2 affected Node but it was low severity as described in secadv-20171207.txt.

_**Original post is included below**_

The Node.js project will be releasing new versions of 4.x, 6.x, 8.x and 9.x as soon as possible after the OpenSSL release, on or soon after December 8th UTC, to incorporate a security fix.

All versions of 4.x, 6.x, 8.x and 9.x are vulnerable to an issue to be fixed in the forthcoming OpenSSL-1.0.2n released on Dec 7, see https://mta.openssl.org/pipermail/openssl-announce/2017-December/000108.html for more details. The severity of this vulnerability of Node.js is HIGH (due to the way Node.js uses the OpenSSL APIs) and users of the affected versions should plan to upgrade when a fix is made available.

*   Versions 4.0 and later of Node.js are vulnerable
*   Versions 6.0 and later of Node.js are vulnerable
*   Versions 8.0 and later of Node.js are vulnerable
*   Versions 9.0 and later of Node.js are vulnerable

Releases will be available as soon as possible after the OpenSSL release, along with disclosure of the details for the vulnerability in order to allow for complete impact assessment by users.

The current Node.js security policy can be found at https://github.com/nodejs/node/blob/HEAD/SECURITY.md#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 organization.

CVE-2017-15896: Data Confidentiality/Integrity Vulnerability, December 2017 | Node.js

ZEIT Next.js before 2.4.1 has directory traversal under the /_next and /static request namespace, allowing attackers to obtain sensitive information.

**This upgrade is _completely backwards compatible and recommended for all users_**  
**For future security related communications of our OSS projects, please join this mailing list**

We were notified of a directory traversal issue under the /_next and /static request namespace.  
An attacker can craft a request that accesses potentially sensitive information in your filesystem.

tl;DR: the fix is live as a patch release and we're working together with a security firm to audit our OSS codebases routinely and avoid issues in the future.

**How to upgrade**

*   We have released patch versions of the stable and beta releases.
*   The following versions fix this bug and include precautions to avoid  
    similar problems in the future
    *   next@2.4.1
    *   next@3.0.0-beta7
*   Run npm install next@2.4.1 --save

**Who is affected**

*   **Affected**: Users of Next.js prior to this release
*   **Not affected**: Deployments on https://now.sh (like https://zeit.co) are mitigated
*   **Not affected**: Static deployments via next export

We recommend _everyone to upgrade regardless of whether you can reproduce the issue or not_.

Container-based deployments, chroot environments and virtualization users are at significantly less risk of sensitive data exposure. In most scenarios, an attacker would only be able to access frontend JavaScript components exclusively.

**How to assess impact**

If you think sensitive code or data could have been exposed, please filter logs of affected sites by .. (excluding quotes in all cases) and check for 200 responses.

**What is being done**

As Next.js has grown in popularity, it has received the attention of security researchers and auditors. We are thankful to @ru\_raz0r for his investigation and discovery of the original bug and subsequent responsible disclosure.

*   We have notified large deployments of Next.js in advance of this publication.
*   If you want to stay on top of our security related news impacting Next.js or other projects, please join this mailing list.
*   We are also very happy to announce that we're working together with Lift Security / Node Security on an audit of all our OSS projects in a recurring basis to ensure a safe experience for everyone.
*   We encourage responsible disclosure of future issues. Please email us at **security@zeit.co**. We are actively monitoring this mailbox.

CVE-2017-16877: Release 2.4.1 · vercel/next.js

redhat-support-plugin-rhev in Red Hat Enterprise Virtualization Manager (aka RHEV Manager) before 3.6 allows remote authenticated users with the SuperUser role on any Entity to execute arbitrary commands on any host in the RHEV environment.

Skip to navigation Skip to main content

**Utilities**

*   Subscriptions
*   Downloads
*   Containers
*   Support Cases

**Infrastructure and Management**

*   Red Hat Enterprise Linux
*   Red Hat Virtualization
*   Red Hat Identity Management
*   Red Hat Directory Server
*   Red Hat Certificate System
*   Red Hat Satellite
*   Red Hat Subscription Management
*   Red Hat Update Infrastructure
*   Red Hat Insights
*   Red Hat Ansible Automation Platform

**Cloud Computing**

*   Red Hat OpenShift
*   Red Hat CloudForms
*   Red Hat OpenStack Platform
*   Red Hat OpenShift Container Platform
*   Red Hat OpenShift Data Science
*   Red Hat OpenShift Online
*   Red Hat OpenShift Dedicated
*   Red Hat Advanced Cluster Security for Kubernetes
*   Red Hat Advanced Cluster Management for Kubernetes
*   Red Hat Quay
*   OpenShift Dev Spaces
*   Red Hat OpenShift Service on AWS

**Storage**

*   Red Hat Gluster Storage
*   Red Hat Hyperconverged Infrastructure
*   Red Hat Ceph Storage
*   Red Hat OpenShift Data Foundation

**Runtimes**

*   Red Hat Runtimes
*   Red Hat JBoss Enterprise Application Platform
*   Red Hat Data Grid
*   Red Hat JBoss Web Server
*   Red Hat Single Sign On
*   Red Hat support for Spring Boot
*   Red Hat build of Node.js
*   Red Hat build of Thorntail
*   Red Hat build of Eclipse Vert.x
*   Red Hat build of OpenJDK
*   Red Hat build of Quarkus

**Integration and Automation**

*   Red Hat Process Automation
*   Red Hat Process Automation Manager
*   Red Hat Decision Manager

All Products

Issued:

2016-03-09

Updated:

2016-03-09

**RHSA-2016:0426 - Security Advisory**

*   Overview
*   Updated Packages

**Synopsis**

Important: redhat-support-plugin-rhev security, bug fix and enhancement update

**Type/Severity**

Security Advisory: Important

**Red Hat Insights patch analysis**

Identify and remediate systems affected by this advisory.

View affected systems

**Topic**

Updated redhat-support-plugin-rhev packages that fix a security flaw  
and a bug are now available.  

Red Hat Product Security has rated this update as having Important  
security impact. Common Vulnerability Scoring System (CVSS) base  
scores, which give detailed severity ratings, are available for each  
vulnerability from the CVE links in the References section.

**Description**

The Red Hat Support plug-in for Red Hat Enterprise Virtualization  
offers seamless integrated access to Red Hat subscription services  
from the Red Hat Enterprise Virtualization administration portal. The  
plug-in provides automated functionality that enables quicker help,  
answers, and proactive services. It offers easy and instant access to  
Red Hat exclusive knowledge, resources, engagement, and diagnostic  
features.  

It was found that redhat-support-plugin-rhev passed a user-specified  
path and file name directly to the command line in the log viewer  
component. This could allow users with the SuperUser role on any  
Entity to execute arbitrary commands on any host in the RHEV  
environment. (CVE-2015-7544)  

All Red Hat Enterprise Virtualization Manager users are advised to  
upgrade to these updated packages.

**Solution**

Before applying this update, make sure all previously released errata  
relevant to your system have been applied.  

For details on how to apply this update, refer to:  

https://access.redhat.com/articles/11258

**Affected Products**

*   Red Hat Virtualization 3.6 x86\_64

**Fixes**

*   BZ - 1138310 - \[Tracker\] - Building redhat-support-plugin-rhev for 3.6
*   BZ - 1173074 - Red Hat Access: Support stucked after upload failure
*   BZ - 1269588 - CVE-2015-7544 redhat-support-plugin-rhev: Remote code execution by SuperUser role on hosts in RHEV

**Red Hat Virtualization 3.6**

SRPM

redhat-support-plugin-rhev-3.6.0-12.el6.src.rpm

SHA-256: 11d5372e5c04a50bf51bed6b10f7885425bd117113a10dcf0abcc138814e4ff7

x86\_64

redhat-support-plugin-rhev-3.6.0-12.el6.noarch.rpm

SHA-256: 57e77f6340e7fccffc068bb28a280214c2ba99f9f1b4d1e40510522aee70d463

The Red Hat security contact is secalert@redhat.com. More contact details at https://access.redhat.com/security/team/contact/.

CVE-2015-7544: Red Hat Customer Portal - Access to 24x7 support and knowledge

Cross-site scripting (XSS) vulnerability in the serve-index package before 1.6.3 for Node.js allows remote attackers to inject arbitrary web script or HTML via a crafted file or directory name.

CVE-2015-8856: nodesecurity.io - nodesecurity Lähteet ja tiedot.

The send package before 0.11.1 for Node.js allows attackers to obtain the root path via unspecified vectors.

CVE-2015-8859

The ms package before 0.7.1 for Node.js allows attackers to cause a denial of service (CPU consumption) via a long version string, aka a "regular expression denial of service (ReDoS)."

CVE-2015-8315: nodesecurity.io - nodesecurity Lähteet ja tiedot.

The duration function in the moment package before 2.11.2 for Node.js allows remote attackers to cause a denial of service (CPU consumption) via a long string, aka a "regular expression Denial of Service (ReDoS)."

Tag

#nodejs