Jun 18, 2018

Nessus Security Scans can cause ColdFusion CPU spike

If your organization uses Nessus for security scans you might see an issue around the the jetty service ColdFusion uses for the PDFG Service.

Some ColdFusion accounts are reporting the same behavior after one of the scans is run against a CF server.  By looking at the IIS or Apache logs you can see clear indications that hundreds of erroneous requests made to the web server using to try and gain any penetration to the server.

Part of the scan must likely includes a port scan prior to the penetration test, which means it finds the jetty connector port.

Here is a forum thread which provides one of the initial reports of the issue.

I have since provided the this workaround to several customers and they have all seen the CPU spikes disappear.

Here is the edit you need to make:

  1. Go to \ColdFusion2016\cfusion\lib\ 
  2. Open "jetty.xml" and search for port "5500" on Connector line
  3. The Host attribute shows "", please replace it with 
  4. Save the changes and restart the respective ColdFusion Application service.

The 5500 port relates to a ColdFusion feature which allows you  to have the Server Monitor client communicate on its own ip\port.  It is unlikely you are using this feature so I would recommend to also uncheck this feature if you are not using it.

So if you are seeing CPU spikes, and you see them across multiple servers and across Dev and Test this could be your issue.  

1 comment:

  1. Hey, Mike. Thanks for providing another avenue for this news to get out. I have some good news to share: the problem was finally resolved with CF2018 update 2 or CF2016 update 8, both released in Feb 2019. After that update, CF no longer listens on that port by default.

    One quibble about the post: at the bottom you rightly identify this jetty as being the one that provided for the CF Enterprise Server Monitor's "alternative web server" feature.

    But at the opening you mention the PDFG feature (used by CF11's new CFHTMLTOPDF tag). While that TOO uses jetty, that is a DIFFERENT Jetty. It's the one enabled by CF's "add on service", which can be enabled as an option on CF installation (or can be installed separately).

    For readers, I'll add that THAT jetty has its own folder, cfusion/jetty (as opposed to the jetty.xml in the cfusion/lib that you rightly refer to), and that has its own jetty.xml (in cfusion/jetty/etc). And fortunately THAT jetty.xml DOES already have the host set to

    So it really was only the jetty used for the Svr Mon (and this cfusion/lib/jetty.xml) that had the problem. Folks who get beyond CF2016 update 7 or CF2018 update 1 will no longer see the issue.