In a discussion titled ‘Management of NVTs and CVEs’ under the Installation category with the tag ‘unsupported-install’, klp reports that their Discourse server (v2.9.0.beta7), installed via DigitalOcean’s 1-click marketplace, is flagged by a third-party scanner for several nginx-related CVEs and three NVTs: missing secure and httpOnly cookie attributes, and TCP timestamps. jomaxro reassures that Discourse’s nginx version (1.21.0+) is not vulnerable to the listed CVEs and suggests running git pull && sudo ./launcher rebuild app to ensure the latest base image is in use — noting that DigitalOcean’s 1-click install is not officially supported by Discourse. klp confirms no proxies are in use and the server runs Ubuntu 20.04.2 LTS. Regarding the NVTs, jomaxro admits unfamiliarity with NVTs and asks for more scanner details. klp clarifies NVTs are Network Vulnerability Tests and provides screenshots. supermathie explains the cookie issues likely stem from Discourse not recognizing HTTPS, suggesting setting SiteSetting.force_https = true, and notes TCP timestamps are a host-level issue needing OS-level fixes. The thread highlights gaps in third-party scanning accuracy and the limitations of unsupported install methods.
G’day,
We have a third party cybersecurity platform that constantly scans all our domains for vulnerabilities, my Discourse server (running 2.9.0.beta7) hosted on DigitalOcean is flagging the following NVTs and CVE’s. All of the CVE’s are related to nginx. Have I missed a process somewhere to update nginx? Appreciate any assistance.
G’day!
Unless your base image is somehow out of date (shouldn’t be possible, you’d be prevented from updating via the UI if it was), Discourse isn’t vulnerable to those nginx CVEs. You can see the version of Nginx used at discourse_docker/image/base/install-nginx at main · discourse/discourse_docker · GitHub, and looking at nginx security advisories 1.21.0+ isn’t vulnerable to CVEs listed.
How did you install Discourse? Did you follow the official install instructions? Any proxies in front of your instance?
Thanks for your quick reply Joshua,
No proxies in front of the instance.
I installed it via the 1-click Marketplace on DigitalOcean: Discourse | DigitalOcean Marketplace 1-Click App
The instance is Ubuntu 20.04.2 LTS
So we have limited support for the 1-click install. That comes from DigitalOcean, we have no control over it. Despite DigitalOcean saying “Supported By: DigitalOcean”, the Support URL sends folks here, where DO staff are not. 
Anyway, first thing I would try, to rule out a weird base image scenario, is to SSH into your droplet, and run the following:
cd /var/discourse
git pull
sudo ./launcher rebuild app
That last command will ensure you have the latest base image, as well as latest Discourse code. Warning, it will take your site down while running.
Then re-run your scanner and see what it reports.
Thanks Joshua,
I will do as you suggest and let you know.
Any feedback on the three NVTs listed?
secure Cookie AttributehttpOnly Cookie AttributeI am not personally familiar with NVTs. And Google isn’t exactly giving promising results, see Google Search for example. Best I’m getting is results on securityspace.com, a site that, strangely enough, doesn’t use SSL/TLS itself and looks like it was built in the 90s.
Does your third-party cybersecurity platform provide more details on the 3 NVTs besides titles?
Re: the first two:
It appears the instance is improperly configured and doesn’t realise it’s serving over https.
SiteSetting.force_https = true may resolve this.
Re: the third:
This is a property of the host on which Discourse is running and needs to be fixed there.
