Hi, we have investigated this further and identified the cause of the blank UI.
The issue is caused by the nginx configuration generated by MAAS for static Web UI resources.
MAAS currently generates the following location:
location ~ ^/MAAS/r/(.*)$ {
root /usr/share/maas/web/static;
try_files /$1 /index.html =404;
}
The MAAS UI references:
/MAAS/r/assets/index-CMtvu7Y_.js
The corresponding file exists and is readable on disk:
/usr/share/maas/web/static/assets/index-CMtvu7Y_.js
However, requesting the asset through the MAAS-managed nginx listener on port 5443 returns index.html instead of the JavaScript file.
With nginx debug logging enabled, the request shows:
trying to use file: "//MAAS/r/assets/index-CMt" "/usr/share/maas/web/static//MAAS/r/assets/index-CMt"
trying to use file: "/index.html" "/usr/share/maas/web/static/index.html"
try file uri: "/index.html"
http filename: "/usr/share/maas/web/static/index.html"
http2 output header: "content-type: text/html"
The first try_files candidate is incorrect. Instead of resolving to:
/usr/share/maas/web/static/assets/index-CMtvu7Y_.js
The positional capture $1 has been overwritten before try_files evaluates it.
As a result, nginx falls back to /index.html. The browser then receives HTML for a JavaScript module URL and rejects it with:
Expected a JavaScript-or-Wasm module script but the server responded with a MIME type of "text/html".
We changed the generated configuration to use a named regex capture:
location ~ ^/MAAS/r/(?<maas_resource>.*)$ {
root /usr/share/maas/web/static;
try_files /$maas_resource /index.html =404;
}
After validating and reloading nginx, the same JavaScript URL is served correctly and the MAAS Web UI immediately works again.
Suggested MAAS fix
I suggest changing the MAAS nginx template to use a named capture, for example:
location ~ ^/MAAS/r/(?<maas_resource>.*)$ {
root {{static_dir}}/web/static;
try_files /$maas_resource /index.html =404;
}
It would also be worth reviewing the other MAAS-generated regex locations that rely on $1/$2, including the machine resources, documentation and boot-resource locations, for the same issue.
Additional context
The issue was reproduced on both MAAS 3.6.4 and 3.6.5, so upgrading MAAS from 3.6.4 to 3.6.5 does not resolve it.
The problem appeared suddenly on an installation that had previously been working.
This also appears to correlate with a recent Ubuntu nginx security update released on 19 August 2026, nginx 1.24.0-2ubuntu7.16 for Ubuntu 24.04 as part of USN-8563-3. That security update specifically changed nginx’s handling of regex matching and capture variables. Later the same day, Ubuntu issued USN-8563-4 saying that USN-8563-3 had introduced a regression “in certain environments” and reverted that fix. The corrected/reverted Ubuntu 24.04 package is: nginx 1.24.0-2ubuntu7.17.
Related Ubuntu issue: Launchpad #2164558.
Even if the immediate trigger is an nginx regression, I believe the MAAS configuration should still be changed to use named captures. This removes MAAS’s dependency on mutable positional capture variables and makes the generated configuration robust against this class of nginx behaviour.
