CVE-2026-105766 in Academy
Summary
by MITRE • 10/05/2026
Use of the backend-facing $scheme variable in the trailing-slash directory redirect in nginx.conf of Chainguard Academy (edu) from commit 0b75ff98057f69b044a3e7194e428066ac5ad0d4 before commit 93dc0e50739c225f5aee2e803800a47fc0feb906 allows an on-path network attacker to read or modify documentation content served to a victim via an HTTPS request for a slashless directory path, because TLS terminates at the load balancer in front of Nginx and the resulting 301 response redirects the client to a plaintext http:// URL. Browsers that ship the HSTS preload list are not affected, because the .dev top-level domain is preloaded; clients that do not enforce HSTS, such as command-line HTTP clients and scripts that follow redirects, are affected.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability identified in Chainguard Academy involves a misconfiguration within the Nginx web server setup used to serve educational documentation content. Specifically, the issue stems from the use of the backend-facing $scheme variable when handling trailing-slash directory redirects. In this architecture, TLS termination occurs at an upstream load balancer rather than directly on the Nginx instance serving the static content. Consequently, the connection between the client and the load balancer is encrypted via HTTPS, but the internal communication from the load balancer to Nginx may be unencrypted or utilize a different scheme context that does not accurately reflect the original request's protocol when processed by certain variables like $scheme in specific redirect configurations.
When a user requests a directory path without a trailing slash over HTTPS, such as https://edu.chainguard.dev/some/path/, the Nginx configuration triggers a 301 permanent redirect to append the missing slash. Due to the reliance on the backend-facing scheme variable which may default to or incorrectly resolve to http in this specific proxying context, the generated Location header points to an unencrypted HTTP URL instead of preserving the HTTPS protocol used by the client. This results in the browser receiving a redirect instruction that forces a downgrade from secure transport to plaintext HTTP for subsequent requests to the same resource.
This behavior creates a significant security risk known as SSL stripping or protocol downgrading, particularly affecting clients that do not enforce strict transport security policies. While modern browsers with HSTS preload lists enabled are protected because they automatically upgrade any attempt to access .dev domains over HTTPS and reject insecure redirects, other user agents remain vulnerable. Command-line HTTP clients like curl or wget, automated scripts, and older browser implementations without preloaded HSTS rules will follow the redirect into plaintext mode. Once in this state, an on-path network attacker can intercept, read, or modify the documentation content being served to the victim. This exposure compromises both confidentiality and integrity of the data transmitted during these redirected sessions.
From a classification perspective, this flaw aligns with CWE-319 Cleartext Transmission of Authentication Information over a Closed Channel if authentication tokens are involved in subsequent requests, but more broadly it represents a failure to maintain transport layer security consistency across redirects, often categorized under CWE-649 Reliance on Obfuscation or Security through Misconfiguration. In the context of the MITRE ATT&CK framework, this vulnerability facilitates Network Sniffing (T1040) and potentially Man-in-the-Middle attacks (T1557), allowing adversaries to intercept sensitive information such as session cookies if they are transmitted in subsequent requests over the downgraded HTTP connection.
To mitigate this issue, it is essential to ensure that Nginx correctly identifies the original scheme of the incoming request even when running behind a reverse proxy or load balancer with TLS termination. This typically involves configuring Nginx to trust and utilize headers such as X-Forwarded-Proto provided by the upstream server rather than relying solely on internal variables like $scheme which may not reflect the client-facing protocol accurately in all redirect scenarios. Additionally, implementing Strict-Transport-Security (HSTS) headers with a long max-age value ensures that clients will refuse to connect via HTTP for future requests, although this does not protect against the initial downgrade during the first request if HSTS is not yet established or enforced by the client's preload list. Updating the Nginx configuration as addressed in later commits resolves this logic error by ensuring redirects preserve the HTTPS scheme regardless of internal proxying details.