CVE-2026-28808 is a critical (CVSS 9.8) incorrect authorization flaw in the Erlang/OTP inets HTTP server. When script_alias points outside DocumentRoot, directory auth rules do not protect the CGI scripts. Fixed releases are OTP 26.2.5.19, 27.3.4.10 and 28.4.2.
What's affected
The GitHub advisory and the Erlang CNA entry say OTP from 17.0 is affected until the fixed releases: OTP 26.2.5.19, 27.3.4.10 and 28.4.2. In inets terms, that is versions from 5.10 before 9.1.0.6, 9.3.2.4 and 9.6.2. Whether older releases are affected is unknown.
You are affected only if all three apply. You use the inets httpd server, you map a URL prefix with script_alias to a directory outside DocumentRoot, and you protect that directory with mod_auth directory rules.
The advisory says you are not affected if you use erl_script_alias (mod_esi), keep script_alias targets inside DocumentRoot, or enforce authentication in an external reverse proxy.
How to check if you're exposed
Find your OTP release from a shell on the host:
erl -noshell -eval 'io:format("~s~n",[erlang:system_info(otp_release)]), halt().'
This prints the major release. Check the full patch version with your package manager or release notes. Then search your httpd configuration for script_alias entries and directory auth rules, and see whether they match the affected pattern.
What to do now
- Upgrade to OTP 26.2.5.19, 27.3.4.10 or 28.4.2 (or later) for your release line, and rebuild images that bundle Erlang.
- If you cannot upgrade yet, move CGI scripts inside DocumentRoot and use
aliasinstead ofscript_alias, as the advisory suggests. - Apply URL-based access control for the CGI prefix at a reverse proxy.
- Review access logs for requests to the CGI path from unauthenticated clients.
Why it matters
The record lists CWE-863 (incorrect authorization) and CWE-551 (incorrect behavior order: authorization before parsing and canonicalization). Two modules disagreed about which path a request meant. The alias module did not include script_alias entries when resolving the path, so the auth module checked rules against the wrong, DocumentRoot-relative path, while the CGI module ran the script at the real target.
The pattern is familiar: a check and an action that see different versions of the same request. The record does not mark the CVE as exploited in the wild.
Quick check
Does erl_script_alias have the same issue?
The advisory says no. That setting maps to Erlang modules, not file system paths, so it falls outside the affected configuration.
Sources
Last reviewed: 19 October 2026.
