blueredix logo
SCAN On-demand vulnerability scans from €149
info service-web-server-cve

Vulnerabilities in web servers (Apache, nginx, IIS, Caddy)

A vulnerability in your web server is more serious than the same kind of bug elsewhere — it sits at the front door, sees every request, and a successful attack usually means the attacker can run code. Why patches matter, and what to do if they have to wait.

Why this category needs more attention than most

A vulnerability in your web server is more dangerous than the same class of bug somewhere else, because of where the web server sits:

  • Every visitor’s request goes through it. Every header, every cookie, every form submission — all of it is input the web server has to parse.
  • It usually runs with significant privileges. Apache and nginx typically start as the all-powerful “root” user before dropping to a less-privileged service user; IIS runs in a service account with broad filesystem access. Remote code execution in any of these is a small step away from total host compromise on a poorly hardened server.
  • It has direct read access to your TLS private keys. The cryptographic material that proves your HTTPS certificates are yours. A remote-read bug (the Heartbleed family) can lift those keys.
  • It sees the request bodies of every other tenant on the same instance. Multi-tenant hosting becomes very fragile when the shared web server has a memory bug.

The blueredix scanner reads the running version from the response headers and from network-level service detection, then asks public databases which CVEs apply (with a filter to drop the well-known false positives — see How to read a CVE).

What kinds of bugs the major web servers ship

  • Apache HTTP Server. Most Apache CVEs are in three areas: request smuggling (HTTP/1.1 and HTTP/2 frame parsing), proxy module misuse, and module-specific RCEs (mod_dav, mod_lua, mod_session). Modules you don’t use are usually still loaded if Apache was packaged with them — disabling them shrinks the attack surface immediately.
  • nginx. Smaller core, fewer CVEs, but the ones that land are often impactful — DNS-resolver buffer overflows, HTTP/3 (QUIC) parsing bugs, mp4-module overflows. Avoid the experimental modules in production.
  • Microsoft IIS. The historical surface includes ASP.NET authentication bypasses and HTTP.sys remote crashes. Modern Windows Server pushes these out via Patch Tuesday — keep automatic updates on for the OS.
  • Caddy. Small surface, modern Go codebase, fewer CVEs simply by virtue of fewer features. Most security work has been around certificate issuance rather than request handling.

Triage when a web-server CVE shows up

Order:

  1. Is it KEV-flagged or EPSS > 0.5? Treat as same-day, out-of-band patching. Web-server CVEs become actively exploited fast — every internet-exposed server running the affected version is a target.
  2. Is it remote code execution? Patch this week regardless of the EPSS score. The headline RCEs of recent years (Apache Path Traversal CVE-2021-41773, log4j CVE-2021-44228 in Java application servers) all crossed from “interesting” to “actively exploited” within 24 hours.
  3. Is it information disclosure or denial-of-service only? Patch in the next regular maintenance window unless EPSS suggests imminent exploitation.

The blueredix report shows you all three signals (severity, exploitation probability, KEV flag) for each finding.

When patching has to wait

Sometimes you can’t patch immediately — frozen change window, vendor appliance, regulated environment. Real mitigations that buy time:

  • Block the malicious request before it reaches the bug. Most web-server CVEs trigger on a specific URL pattern, header, or method. A web application firewall (Cloudflare, AWS WAF, ModSecurity) can drop matching requests at the edge. Vendor advisories typically publish such patterns; look for “mitigation” or “workaround” in the references.
  • Disable the vulnerable module. A surprising number of web-server CVEs are scoped to a single module (mod_lua, mod_session, nchan). Disabling the module makes the bug unreachable without changing the rest of the server.
  • Restrict who can reach the server. Internal admin paths can usually be limited to office IPs; even the public surface can be narrowed if you know your customer base.
  • Run the server behind a reverse proxy. A Caddy or nginx in front of an Apache backend can normalise the request and strip the attack pattern before it reaches the vulnerable server. Not a permanent fix, but useful for short windows.

A note on operating-system packages

If your web server comes from your operating system’s package manager (apt, yum, dnf on Linux), the upstream version number doesn’t tell the full story. Distributions back-port security fixes onto stable upstream versions — “Apache 2.4.52” on Ubuntu 22.04 may have ten patches the upstream 2.4.52 doesn’t know about. The blueredix scanner detects the distribution tag and short-circuits the public-database lookup for those builds, emitting an info-level “distribution-managed” notice instead. Your authoritative source is your distribution’s security tracker:

Further reading