Muppy 18.89.0¶
Released 2026-09-09.
Open the LXD web UI from a Host¶
LXD 6 ships a web UI served by the daemon itself. Muppy now opens it for you: on the form of an LXD host, one button binds the LXD listener to the host's Control IP, asks LXD for an initial-access link and opens that link in your browser. You land in the UI as its initial administrator, with nothing to type.
What you gain. A browser view of a host's containers, images and storage without an SSH session, and without configuring LXD's HTTPS listener or its identities by hand.
What to expect from the link. It is the only login the UI accepts: there is no password to set, it expires after 24 hours, and asking for a new one invalidates the previous one. Muppy neither stores nor logs it — close the tab and you ask again.
What the Control IP decides. The button reads the host's Control IP to decide what it may expose:
- a Tailscale address opens nothing on the host firewall — the tailnet is the perimeter;
- a LAN address opens port 8443 to your own address only, and only when the host firewall (UFW) is active;
- a public address is refused unless the host firewall is active.
Requirements
The host runs LXD 6.7 or later — the version that introduced the initial-access identity the link relies on — and you belong to the new LXD Administrators group. Muppy Administrators are members of it already; grant it to anyone else who needs the UI. Members of a Manganese tenant reading a shared host do not have it, and cannot reach the button.
What you have to do. Nothing on existing hosts. Grant LXD Administrators to the people who should open the UI, and upgrade LXD on hosts older than 6.7 if you want it there. The full walkthrough is in LXD Web UI.
18.89.1¶
Released 2026-09-10.
A Code Server window used to end its title with the product name, which reads the same on every instance: with several open side by side, no window said which App Server it belonged to. The title now ends with the App Server's own URL. Nothing to do — the change applies the next time the editor is deployed on a server. The name the editor carries when it is installed as an application is unchanged: it comes from the editor itself, not from Muppy.
18.89.2¶
Released 2026-10-01.
Security fix: importing systemd units could run a command on an App Server's host without approval¶
| Severity | Affected versions | Fixed in |
|---|---|---|
| Low | 18.64.0 to 18.89.1, and the candidates of 18.97.0 cut before this patch | 18.89.2, and the next candidate of 18.97.0 |
The import of existing systemd units — Import custom Services on an App Server, and Import Systemd Units in the Muppy menu — handed a value supplied by the user to a command run with administrator rights on the host. A logged-in user who owns an App Server, or an AI agent acting for them through the MCP, could have that host run a command of their choosing without the human approval that an AI agent's commands require on that App Server. The owner of such an App Server already administers its host through the IDE: what the flaw bypassed is that approval, not a boundary between tenants. The import no longer hands any user value to a command, and Import Systemd Units in the Muppy menu is now reserved to Muppy infrastructure users.
What to do. Upgrade to 18.89.2 or any later version. The unit filter of both import
wizards, and of the MCP method behind Import custom Services, is now a list of words
separated by | — a unit is listed when its name contains one of them — rather than a regular
expression: a filter written as an expression (^mpy, mpy_.*) finds nothing, write it as
words instead (mpy_, mongo|redis).
18.89.3¶
Released 2026-10-01.
Security fix: an App Server owner's git credentials could be obtained from the task logs¶
| Severity | Affected versions | Fixed in |
|---|---|---|
| High | 18.74.0 to 18.89.2, and the candidates of 18.97.0 cut before this patch | 18.89.3, and the next candidate of 18.97.0 |
When Muppy installed its git credential helper on an App Server — at provisioning, when an App Server is switched to the helper, and when its owner renews the helper's secret — the log of that task recorded the secret the helper uses to ask Muppy for git credentials. The secret belongs to the App Server's owner and, on its own, obtains the git access token that owner has connected in Muppy. Anyone allowed to read that task's log could therefore act on the owner's git repositories with the owner's rights: Muppy infrastructure users, the user who started the task, and the Manganese administrators of that user's company. Only instances with App Servers using the Muppy git credential helper are affected. On the candidates of 18.97.0, the secret recorded identifies the App Server rather than its owner, and does not by itself obtain a git token.
What to do. Upgrade to 18.89.3 or any later version. The upgrade removes the secret from the existing task logs, and names in its log, as warnings, the users — and on a candidate of 18.97.0, the App Servers — whose current secret was recorded. Renew each of them. For a user: on the user form, tab Muppy, button Rotate Bootstrap Secret. For an App Server: on its form, button Renew git secret, which comes with the next candidate of 18.97.0. If you cannot rule out that someone read those task logs, also revoke the git tokens of the users named, at their git provider, and connect new ones in Muppy.
18.89.4¶
Released 2026-10-01.
Security fix: git tokens and database password verifiers could be read in the task logs¶
| Severity | Affected versions | Fixed in |
|---|---|---|
| High | 18.64.0 to 18.89.3, and the candidates of 18.97.0 cut before this patch | 18.89.4, and the next candidate of 18.97.0 |
Muppy copies the commands a task runs into that task's log, and it copied every one of them, including the ones written to be kept out of it. Two kinds of credential reached the logs that way: the git token of an App Server's repository, in the commands that clone the repository or set its remote, and the definition of a database owner's role — its password verifier included — read by every database backup and replayed by its restore. Anyone allowed to read such a task's log could reuse the git token: Muppy infrastructure users, the user who started the task, and the Manganese administrators of that user's company. A password verifier does not log in on its own; it only lets a weak password be guessed offline.
What to do. Upgrade to 18.89.4 or any later version. The upgrade masks these credentials
in the existing task logs and results, and names in its log, as warnings, each account whose
credential appeared, as user@host. Revoke each git token named at its provider and replace
it in its Vault; change a database password named on its cluster.
Security fix: the values of Kubernetes releases could be read in the task logs¶
| Severity | Affected versions | Fixed in |
|---|---|---|
| High | 18.64.0 to 18.89.3, and the candidates of 18.97.0 cut before this patch | 18.89.4, and the next candidate of 18.97.0 |
A Helm install or upgrade of a Kubernetes release copied Helm's output into the task's log and into its result. That output carries the release's values and its rendered manifests, Secrets included: registry credentials, git tokens, database passwords — whatever the chart is given. The same people as above could read it. Only instances that deploy Kubernetes releases are affected. Helm's output now stays in the release's Config Journal, and the task log receives one line saying how the command ended.
What to do. Upgrade to 18.89.4 or any later version. The upgrade removes Helm's output from the existing task logs and results. If you cannot rule out that someone read those logs, change the secrets your releases' values carry.