Last updated at Fri, 10 May 2019 17:01:21 GMT

This post describes CVE-2017-8987, an unauthenticated remote Denial of Service vulnerability in HPE iLO3 firmware version 1.88. This vulnerability can be exploited by several HTTP methods; once triggered, it lasts for approximately 10 minutes until the watchdog service performs a restart of the iLO3 device. CVE-2017-8987 is categorized as CWE-400 (Resource Exhaustion) and has a CVSSv3 base score of 8.6.

CVE-2017-8987 is limited to iLO3 firmware v1.88. Versions 1.8, 1.82, 1.85, and 1.87 of iLO3 were also tested, but were not found to be vulnerable. In addition, an iLO4 device running firmware v2.55 was tested and was not found to be vulnerable. iLO5 devices were not tested for this vulnerability.

iLO3 v1.89 patches CVE-2017-8987; we encourage users to update their iLO3 instances to v1.89 to address this issue (see Remediation section below).

Product Description

Integrated Lights-Out (iLO) is a proprietary embedded server management technology by Hewlett-Packard which provides out-of-band management facilities (also referred to as "lights out management"). It provides more direct access (via a physical card with a separate network connection) to a range of HPE servers (such as the ProLiant line), enabling users to remotely perform actions such as resetting and powering up, as well as accessing the server's integrated management log. See this page for additional product information.


This issue was discovered by Rapid7 lead security researcher Ross Kirk and Adam McClenaghan. It is being disclosed in accordance Rapid7's vulnerability disclosure policy.

Exploitation details

Several HTTP request methods cause iLO3 devices running firmware v1.88 to stop responding in several ways for 10 minutes:

  • SSH: open sessions will become unresponsive; new SSH sessions will not be established
  • Web portal: users cannot log in to the web portal; the login page will not successfully load

Benign request methods

HTTP GET and POST requests, such as the following, have no detrimental effect:

curl -X GET
curl -X POST

The following is a packet capture from a successful curl -X GET request to an iLO3 device:

Problematic request methods

Requests calling the following four methods, however, will trigger the Denial of Service:

curl -X PUT
curl -X TRACE

For example, the following is a packet capture from a curl -X OPTIONS request to an iLO3 device:

After packet number 16 shown above is sent from the server, the curl command will hang, and no new SSH sessions can be opened to the server.

In addition, any method requested other than GET or POST will trigger the DoS, even invalid ones like the following:



Once the DoS is triggered, the device will continue to respond to ICMP/ping requests. This may prevent some external monitoring systems from detecting the problem initially. nmap scans will also show nothing abnormal:

Nmap scan report for 10.X.X.21
Host is up (0.090s latency).
Not shown: 996 closed ports
22/tcp open ssh
80/tcp open http
443/tcp open https
17988/tcp open unknown

These standard ports being in an open state means that SYN-ACK packets are returned by the device, and thus the underlying services have not completely crashed. This is consistent with a packet capture made while SSH login is attempted during the DoS:

SYN-ACK packets are still received from the server, but the SSH connection does not complete. Compare this with the following packet capture from an SSH login initiated when the iLO3 device is responding normally:

Ten minutes after the DoS is triggered, the watchdog (automatic system recovery) service restarts the device, which is shown in the iLO Event Log:

The device will stop responding to ICMP requests for a short period due to the restart. Shortly thereafter, the device becomes fully responsive (i.e. again allowing SSH and web portal login).

Note, this DoS condition does not affect the operations of the host server’s operating system or applications, just the remote management functionality provided by the iLO3 itself.


HPE addressed CVE-2017-8987 on Oct 19, 2017 in the v1.89 release of iLO3. Users running iLO3 v1.88 should update to iLO3 v1.89 as soon as possible. This will prevent a Denial of Service from being triggered by the HTTP methods specified above.

If upgrading is not feasible, users should configure their firewalls to block HTTP requests (for methods other than GET and POST) sent to affected iLO3 devices.

Vendor Statement

Hewlett Packard Enterprise would like to thank Ross Kirk and Adam McClenaghan of Rapid7 for identifying and reporting this vulnerability to

Disclosure Timeline

  • Sept 2017: Issue discovered
  • Thurs, Oct 19, 2017: Vendor released v1.89 update to iLO3, which addresses CVE-2017-8987
  • Mon, Nov 6, 2017: Vendor notified; vendor assigned PSRT110615 to this vulnerability
  • Wed, Nov 15, 2017: Additional details sent to vendor
  • Wed, Jan 10, 2018: Disclosed to CERT/CC
  • Wed, Jan 31, 2018: Vendor reported that v1.89 is not vulnerable to R7-2017-27; Rapid7 confirmed this finding.
  • Thurs, Feb 22, 2018: Public disclosure; vendor published security bulletin and assigned CVE-2017-8987
  • Thurs, Mar 1, 2018: Rapid7 published this post

Update, Mar 1, 2018: Added a note clarifying the scope of the DoS condition in the Impact section.