When you see nginx/1.18.0 (ubuntu) in a Server response header, you are looking at the nginx 1.18.0 stable release as packaged by Ubuntu, and the security question is not the version string itself but whether Ubuntu's backported patches have been applied on the running host. The banner alone does not tell you that a server is vulnerable, because distribution packages routinely fix security bugs while keeping the upstream 1.18.0 version number intact. That single fact is the most important thing to understand before you file a finding based on this header.
nginx 1.18.0 shipped in April 2020 as the stable branch of its era. Ubuntu picked it up into the archive for the releases of that period, and the (ubuntu) suffix in the banner is nginx telling you it was built from the distribution's packaging rather than from source or the official nginx.org repository. You will most commonly encounter this string in a scanner report, a curl -I against a service, or a fingerprint from a tool like nmap or Shodan.
What does the (ubuntu) suffix actually mean?
Upstream nginx built from nginx.org reports a bare nginx/1.18.0. The (ubuntu) in nginx/1.18.0 (ubuntu) is added by Canonical's build, and it is a meaningful signal: it means the binary came from the Ubuntu archive, which means it is subject to Ubuntu's security maintenance rather than upstream's. This is the crux of the whole risk assessment.
Upstream stopped fixing the 1.18 line when 1.20 became stable in 2021. If you were running a source build of 1.18.0, any nginx vulnerability disclosed since then would never have an official 1.18 patch. But Ubuntu does not work that way. Canonical backports security fixes into the packaged version and bumps the Ubuntu-specific portion of the version, so a fully patched host might report a package version like 1.18.0-6ubuntu14.x while the banner still says nginx/1.18.0 (ubuntu). The banner is frozen at the upstream version; the real patch state lives in the package revision.
Which CVEs matter for this version?
Two disclosure sets are worth checking specifically, and both are configuration-dependent rather than universally exploitable.
CVE-2021-23017 is a one-byte memory overwrite in the nginx DNS resolver, affecting versions from 0.6.18 through 1.20.0, which includes 1.18.0. It carries real weight because there is published exploitation research, but it only applies if the resolver directive is configured. Many nginx deployments never use resolver at all. Check with:
grep -r "resolver" /etc/nginx/
If that returns nothing, the DNS resolver flaw does not apply to your configuration regardless of version.
CVE-2022-41741 and CVE-2022-41742 are memory corruption and information disclosure bugs in the ngx_http_mp4_module, fixed upstream in 1.22.1 and 1.23.2. They only matter if the mp4 module is compiled in and an mp4 directive is active, which concentrates the practical risk on servers that stream user-uploaded or untrusted video. If you do not serve mp4 through nginx, these do not apply either.
Never invent a severity or an exploit path for a banner you have not correlated with the running package version. Confirm the CVEs against the NVD and Ubuntu's security tracker before acting.
How do I confirm the real patch state?
The banner is not enough. On the host itself, check the actual package version:
dpkg -l nginx-core nginx-common | grep nginx
# or
apt-cache policy nginx
Then compare that package revision against Ubuntu's security notices for the affected CVEs. If Canonical has released a fix and your package revision is at or above the fixed revision, the host is patched even though the banner still reads 1.18.0. If you cannot reach the host, for example when assessing a third party, the banner tells you the version family but not the patch state, so the honest finding is "running an nginx line whose patch state cannot be confirmed from headers," not "vulnerable to CVE-X."
Run your updates the normal way and the fixes flow in:
sudo apt update && sudo apt upgrade nginx-core
Should I stop advertising the version at all?
Yes, as defense in depth. There is no reason to hand every scanner and opportunistic bot your exact version and packaging. Suppress the version detail with:
http {
server_tokens off;
}
With server_tokens off, the banner collapses to a bare nginx with no version or (ubuntu) suffix. This does not fix any vulnerability, and you should never treat banner suppression as a substitute for patching, but it removes an easy targeting signal and cuts down the noise of automated version-based probes. For a full removal of the header you would need a module like headers-more, but for most deployments server_tokens off is the pragmatic control.
What is the right long-term posture?
Sitting on an Ubuntu-packaged 1.18.0 that Canonical still maintains is not an emergency, but it is a clock. Ubuntu security maintenance for any given release has an end date, and once the release leaves standard support (or ESM), the backports stop and the version becomes genuinely stale. The durable answer is to track your Ubuntu release's support window and plan the nginx upgrade path as part of the OS lifecycle, rather than treating the web server in isolation. Continuously inventorying which services run which packaged versions, so a support-window expiry does not surprise you, is exactly the kind of drift an SBOM-driven tool such as Safeguard is built to track across an estate.
FAQ
Is nginx/1.18.0 (ubuntu) automatically vulnerable?
No. The banner reports the upstream version, not the patch state. Ubuntu backports security fixes while keeping the 1.18.0 version string, so a fully patched host still reports nginx/1.18.0 (ubuntu). You must check the actual package revision on the host to know whether it is patched.
How do I tell if the DNS resolver CVE applies to me?
CVE-2021-23017 only affects configurations that use the resolver directive. Run grep -r "resolver" /etc/nginx/. If it returns no matches, that vulnerability does not apply to your deployment even though your version is in the affected range.
Should I upgrade off 1.18.0?
Eventually, yes, aligned with your Ubuntu release lifecycle. While the release is in standard support or ESM, Canonical backports fixes, so 1.18.0 is maintained. Plan the move to a newer nginx line before your OS release leaves support and the backports stop.
Does turning off server_tokens improve security?
It reduces information disclosure by hiding the version and packaging from the Server header, which cuts automated version-based targeting. It does not patch anything, so treat it as defense in depth alongside keeping the package current, never as a replacement for patching.