CVE-2026-33006

What it actually does

Apache HTTP Server 2.4.66 contains a timing side-channel weakness in mod_auth_digest that can allow a remote, unauthenticated attacker to bypass Digest authentication under favorable conditions. The issue affects authentication decision logic rather than memory safety: by measuring response timing differences during Digest authentication checks, an attacker may infer enough information to craft requests that are accepted for protected resources. The vulnerability has network attack vector, requires no prior credentials or user interaction, but has high attack complexity and is limited to confidentiality and integrity impact for resources protected by mod_auth_digest.

Why it matters to the business

Organizations using Apache HTTP Server with Digest authentication may have protected web content or administrative endpoints exposed to unauthorized access. Although public exploitation is not currently known, the issue has been public for roughly 100 days, and authentication bypass flaws can become more serious if the protected resource controls business workflows, configuration panels, internal documentation, or sensitive files. The current EPSS is low and stable, and it is not listed in CISA KEV or associated with ransomware campaigns, so remediation should be prioritized based on exposure of Digest-protected internet-facing services and the sensitivity of the protected content.

How an attack unfolds

An attacker first identifies an Apache HTTP Server instance that challenges access with HTTP Digest authentication, typically by requesting a protected path and observing a 401 response with a WWW-Authenticate: Digest header. If the server is running the vulnerable mod_auth_digest implementation, the attacker repeatedly sends crafted Digest authentication attempts and measures subtle differences in response timing. Over many attempts, those timing differences may reveal whether parts of the supplied authentication material are closer to a valid value. The attacker then refines the request until the server accepts it as authenticated, allowing access to resources that should require valid credentials. Successful exploitation is likely to appear as repeated failed Digest authentication attempts followed by successful access to the same protected paths, but there may be no distinctive exploit payload in default logs.

How to fix it

Upgrade Apache HTTP Server to version 2.4.67 or later. Because the flaw is in mod_auth_digest, the most direct mitigation is to remove reliance on Digest authentication where possible, disable mod_auth_digest if it is not required, or replace it with a stronger authentication control such as SSO, reverse-proxy authentication, mutual TLS, or application-layer authentication. For internet-facing servers that must continue using Digest authentication before an upgrade, restrict access by source IP, VPN, WAF/reverse proxy policy, or network segmentation; increase monitoring of Digest-protected paths; and ensure sensitive administrative functions are not protected solely by Digest authentication. Restart or reload Apache after patching and verify that all active instances, containers, appliances, and downstream packages have picked up the corrected httpd build.

How to confirm the fix worked

Confirm the running Apache HTTP Server version is 2.4.67 or later using the package manager, vendor inventory, container image metadata, and where appropriate `httpd -v` or `apachectl -v`. Confirm that vulnerable 2.4.66 binaries are no longer running after restart by checking active processes and loaded service units. Review configuration for `AuthType Digest`, `mod_auth_digest`, and `LoadModule auth_digest_module` to determine whether the vulnerable code path was exposed. Validate that protected URLs still require authentication after the upgrade and that invalid Digest credentials consistently receive 401 responses. External validation can include scanning only for exposed Digest challenges and server version evidence; avoid attempting timing exploitation in production unless using an approved test plan because reliable testing may require many requests and precise measurement.

Typical attack path

1. Discover an Apache HTTP Server endpoint that returns a Digest authentication challenge for a protected resource.
2. Confirm that the server appears to be running an affected version and that mod_auth_digest is in use.
3. Send repeated crafted requests with HTTP Authorization: Digest headers while measuring response timing precisely.
4. Use timing differences to infer valid authentication material or bypass conditions.
5. Submit a final Digest-authenticated request that is accepted by the server.
6. Access or modify protected resources according to the privileges normally granted by the bypassed Digest authentication realm.

How to detect it

To assess possible prior exploitation, review Apache access logs, error logs, reverse proxy logs, WAF logs, and authentication telemetry for Digest-protected locations. Focus on patterns rather than a single payload: high volumes of 401 responses against the same protected URI, many requests containing Digest authentication attempts, unusually consistent request pacing consistent with timing measurement, and eventual 200/2xx access from the same source after repeated failures. Compare successful accesses to Digest-protected resources against expected users, source networks, geographies, and user agents. If logs include authentication scheme or headers, search for repeated `Authorization: Digest` attempts with varying nonce, response, cnonce, nc, username, realm, or URI fields. On hosts, check Apache configuration and module inventory to determine exposure: `AuthType Digest`, `LoadModule auth_digest_module`, and active `mod_auth_digest` usage. Because successful exploitation may look like a normal authenticated request and default Apache logs often omit Authorization headers, absence of clear indicators does not prove non-exploitation; correlate web access with downstream application actions on protected resources.

• Authorization: Digest
• WWW-Authenticate: Digest
• AuthType Digest
• LoadModule auth_digest_module
• mod_auth_digest
• 401
• " 401
• " 200
• " 204
• " 302

What your security team should do

• Inventory Apache HTTP Server deployments and prioritize any internet-facing systems using `AuthType Digest` or loading `mod_auth_digest`.
• Upgrade affected Apache HTTP Server 2.4.66 deployments to 2.4.67 or later, including container images, embedded distributions, and vendor-packaged builds.
• If immediate patching is not possible, disable Digest authentication where feasible or place Digest-protected resources behind compensating controls such as VPN, IP allowlisting, reverse-proxy authentication, or mTLS.
• Review access logs for repeated 401 responses followed by 200/2xx responses to the same Digest-protected paths, especially from the same source IP or user agent.
• Increase logging temporarily for protected paths, including request method, URI, status code, source IP, user agent, authenticated username, and, where policy permits, authentication scheme metadata.
• Do not rely on the low EPSS alone for deferral if Digest authentication protects sensitive administrative or business-critical resources.
• Track vendor advisories and downstream package updates to ensure all distributions ship the fixed Apache HTTP Server version.