I Scanned an Intentionally Vulnerable Linux Server with Nessus. Here’s What We Found.

A practical walkthrough of credentialed and web application scanning — uncovering 76 system vulnerabilities and a live exploit on Nginx 1.15.5.

Ajibola Khaleelullah· Busayo Asiwaju Tool: Nessus Essentials

Vulnerability assessments can feel abstract until you run one yourself. For this project, we set up a controlled Linux environment — deliberately installing a known-vulnerable version of Nginx — and used Tenable Nessus Essentials to conduct two types of scans: a credentialed system scan and an unauthenticated web application scan. The results were eye-opening.

“Many of the issues identified are already well known and have fixes available, yet they still present real risk if left unattended.”

Setting Up the Environment

The target was a Kali Linux machine running Nginx 1.15.5, installed from source specifically because it contains multiple documented CVEs. OpenSSH was configured to allow Nessus to authenticate via root credentials and perform deep system inspection. Nessus itself was installed locally and accessed through its web interface at https://localhost:8834.

Email reporting was also configured through Gmail’s SMTP server (port 587, TLS) so that scan results could be delivered automatically after each run — a realistic touch that mirrors how security teams operate in production environments.

SMTP configuration used:

Setting Value SMTP Host smtp.gmail.com Port 587 Encryption TLS Authentication Gmail App Password

Methodology

The assessment followed two tracks:

Credentialed SSH Scan — Root credentials were provided to Nessus to allow a deep, authenticated inspection of the Linux system. This simulates the perspective of an insider or a post-compromise attacker with elevated access.

Unauthenticated Web Application Scan — Using Nessus’s Web Application Tests template, we scanned the Nginx server with no credentials configured. This simulates an external attacker probing the system from the outside.

Credential Scan Results: 76 Vulnerabilities

The credentialed SSH scan gave Nessus full visibility into the Linux system. The findings spanned the full severity spectrum:

Severity Count 🔴 Critical 1 🟠 High 4 🟡 Medium 15 ⚪ Low 0 ℹ️ Informational 80

The critical finding was tied to an outdated version of Node.js — exposing the system to privilege escalation, denial-of-service, and cryptographic weaknesses. The bulk of informational findings related to CGI configurations, general system settings, and database services. While these don’t pose immediate risk, they indicate a system that hasn’t been adequately hardened.

The presence of critical and high severity vulnerabilities in core application components like Node.js signals that basic patch management isn’t being consistently applied — a very common and very dangerous gap.

Web Application Scan: Nginx Under the Microscope

The unauthenticated web application scan targeted http://localhost with no credentials — simulating what a real external attacker would see. It returned 22 findings: 4 high severity and 18 medium severity issues.

Severity Count 🟠 High 4 🟡 Medium 18

The most serious finding is a confirmed, publicly exploitable remote code execution vulnerability. Here’s a breakdown of the key vulnerabilities:

🔴 CVE-2021–23017 — Remote Code Execution (CVSS 7.7 · High)

Affected versions: nginx 0.6.x < 1.20.1 Plugin ID: 150154 | Exploit: Publicly available ⚠️

An off-by-one error in the nginx resolver allows an attacker to send a crafted DNS response, writing a single byte out of bounds in the heap buffer. This can crash the worker process or — in the worst case — lead to arbitrary code execution. No authentication is required. The attacker only needs the resolver directive to be configured on the server.

This is the most critical finding of the entire assessment. A working exploit exists in the wild, making immediate patching non-negotiable.

Fix: Upgrade to nginx 1.20.1 or later.

🟠 CVE-2019–9511, CVE-2019–9513, CVE-2019–9516 — HTTP/2 Denial of Service (CVSS 7.5 · High)

Affected versions: nginx 1.9.5 < 1.16.1 / 1.17.x < 1.17.3 Plugin ID: 127907 | Exploit: None known

Three distinct flaws in the HTTP/2 protocol stack, all exploitable without authentication:

• CVE-2019–9511 (Data Dribble): Attacker manipulates window sizes and stream priorities to force the server to queue large responses in 1-byte chunks — exhausting CPU and memory.
• CVE-2019–9513 (Resource Loop): Attacker continuously shuffles stream priorities, causing excessive CPU consumption through priority tree churn.
• CVE-2019–9516 (Zero-Length Headers): Attacker sends a stream of zero-length header names and values that the server allocates memory for and never releases — until the session dies.

All three can render the server completely unavailable to legitimate users.

Get Official khaleelajibola’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Fix: Upgrade to nginx 1.16.1 / 1.17.3 or later.

🟡 CVE-2018–16843, CVE-2018–16844, CVE-2018–16845 — Multiple Vulnerabilities (CVSS 6.1 · Medium)

Affected versions: nginx 1.x < 1.14.1 / 1.15.x < 1.15.6 Plugin ID: 118956

• CVE-2018–16843: Excessive memory consumption via the ngx_http_v2_module.
• CVE-2018–16844: Excessive CPU usage via the ngx_http_v2_module.
• CVE-2018–16845: A buffer over-read in the ngx_http_mp4_module that can crash a worker process or leak memory contents. Requires an attacker to trick a user into uploading a specially crafted MP4 file.

Fix: Upgrade to nginx 1.14.1 / 1.15.6 or later.

🟡 CVE-2019–20372 — HTTP Request Smuggling (CVSS 5.3 · Medium)

Affected versions: nginx < 1.17.7 Plugin ID: 134220 | Exploit: Available ⚠️

Certain error_page misconfigurations allow an attacker to smuggle a hidden HTTP request to the backend server. In environments where Nginx sits behind a load balancer, this can expose unauthorized web pages to the attacker.

Fix: Upgrade to nginx 1.17.7 or later.

🟡 CVE-2026–1642 — SSL Upstream Injection (CVSS 5.9 · Medium)

Affected versions: nginx 1.3.0 < 1.28.2 / 1.29.x < 1.29.5 Plugin ID: 304671

When Nginx proxies to upstream TLS servers, an attacker in a man-in-the-middle position on the upstream side may inject plain text data into TLS responses — which Nginx then silently forwards to clients without detecting tampering.

Fix: Upgrade to nginx 1.28.2 / 1.29.5 or later.

Recommendations

Immediate Actions

Priority Issue Action 🔴 Critical CVE-2021–23017 RCE Upgrade to nginx 1.20.1+ immediately 🟠 High CVE-2019–9511/9513/9516 DoS Upgrade to nginx 1.16.1 / 1.17.3+ 🟠 High Node.js critical vuln Patch Node.js to latest stable 🟡 Medium CVE-2018–16843/44/45 Upgrade to nginx 1.14.1 / 1.15.6+ 🟡 Medium CVE-2019–20372 Smuggling Upgrade to nginx 1.17.7+ 🟡 Medium CVE-2026–1642 SSL Injection Upgrade to nginx 1.28.2 / 1.29.5+

SSH Hardening

• Set PermitRootLogin no in /etc/ssh/sshd_config
• Enforce key-based authentication: PasswordAuthentication no
• Restrict SSH access to specific IP ranges via firewall rules (ufw or iptables)
• Enable fail2ban to block repeated failed login attempts
• Keep OpenSSH updated to the latest stable release

Ongoing Security Practices

• Schedule weekly credentialed Nessus scans + monthly web application scans with automated email delivery
• Maintain a vulnerability register tracking each finding from detection to remediation
• Subscribe to nginx and OpenSSH security advisories for proactive patch awareness
• Deploy a Web Application Firewall (WAF) such as ModSecurity in front of Nginx
• Conduct quarterly penetration testing to validate that remediations actually hold

Conclusion

This assessment successfully demonstrated how quickly an unpatched system accumulates serious exposure. Every vulnerability flagged here has a published fix — some dating back to 2018. The gap between “patch available” and “patch applied” is precisely where attackers operate.

The most concerning finding — CVE-2021–23017 — carries a public exploit and requires no authentication to trigger. Running Nginx 1.15.5 in any environment connected to a network is an active risk, not a theoretical one.

Keeping systems patched, tightening configurations, and running regular scans are straightforward steps. But they only work when done consistently. Vulnerability assessment isn’t a one-time exercise — it’s an ongoing discipline.

This assessment was conducted using Tenable Nessus Essentials on a controlled, intentionally vulnerable lab environment. All findings are from a closed internal network.