Two Critical Bugs in Dev Infrastructure Control Planes: LXD/MicroCloud CVE-2026-112816 and pgAdmin CVE-2026-116241

Two tools that developers and platform teams treat as trusted plumbing shipped critical fixes on the same day, October 29. LXD/MicroCloud run containers and VMs. pgAdmin is the default web console for PostgreSQL. Neither is in CISA’s KEV catalog yet, but both bugs give an attacker a path from “allowed to talk to the control plane” to command execution on the machine behind it.

LXD and MicroCloud: CVE-2026-112816 (CVSS 4.0: 10.0)

What went wrong

LXD authenticates remote clients with mutual TLS. A client presents a certificate chain, and LXD checks it against a trust store of client certificates. According to Canonical’s advisory, LXD compared every certificate in the peer’s chain against that trust store. Only the leaf certificate proves the client holds the private key, though. The other certificates in the chain are just public data.

So an attacker who knows a trusted client’s public certificate can put it in the chain as an intermediate, present their own leaf, and be authenticated as that trusted client. Public certificates often aren’t treated as secrets, which makes this a very practical attack. Admin-level access to LXD is generally equivalent to root on the host.

MicroCloud has its own variant. An attacker who intercepts a joining member’s certificate during cluster formation can impersonate that member.

Who is exposed

• Standalone LXD is only exposed over the network if core.https_address is set. Local Unix-socket use isn’t affected.
• MicroCloud and clustered LXD listen over HTTPS by design, so assume they’re exposed.
• The issue affects the snap channels. Canonical says LXD packages in the Ubuntu archive aren’t affected.

The bug was reported by the Incus project (the community LXD fork led by Stéphane Graber), which fixed the same class of issue in Incus 7.6.0. Canonical says there’s no workaround other than restricting network access to the LXD API.

Snap updates roll out gradually, so refresh explicitly and then confirm the version:

sudo snap refresh lxd
sudo snap refresh microcloud
snap list lxd microcloud   # confirm you're on the fixed revision
lxc config get core.https_address   # empty = API not exposed over the network

pgAdmin 4: CVE-2026-116241 (CVSS 3.1: 9.9)

What went wrong

pgAdmin’s Import/Export Data tool builds a psql \copy (...) command, and for query-based exports a parenthesis-balance guard is supposed to keep the user’s query inside it. An earlier fix (CVE-2026-17566) tried to stop users from sneaking a TO PROGRAM clause, which runs a shell command, into that statement. The new bug gets around it with a backslash inside a double-quoted identifier. When standard_conforming_strings is off, the escaping is parsed differently and the injected TO PROGRAM escapes the guard.

Two defaults make it worse:

• An ordinary database role can turn standard_conforming_strings off for its own session.
• The Import/Export Data permission is granted to non-admin pgAdmin users by default.

So in server mode (a shared, multi-user pgAdmin), any logged-in low-privilege user can run OS commands as the pgAdmin service account. That account usually holds the saved connection credentials for every database the team manages.

The fix

pgAdmin 4 9.19 fixes CVE-2026-116241 together with a batch of related issues (CVE-2026-116238 through CVE-2026-116252). According to the release notes, most of them affect server mode. They include the service account’s own ~/.pgpass, client certificates, SSH keys and Kerberos credentials being usable by any user (CVE-2026-116247, 116242, 116244), saved passwords leaking through the process environment (116246), symlink and path-traversal escapes from the storage directory (116240, 116249, 116250), and LDAP/Kerberos logins landing in a different account with the same username (116239). Several fixes change behaviour, such as the new SERVER_PASSEXEC_COMMANDS and SERVER_MODE_ALLOWED_SERVICES settings, so read the release notes before upgrading a shared instance. If you can’t upgrade straight away, revoke the tools_import_export_data permission from every role you don’t fully trust.

What to do

1. Run snap list lxd microcloud on every host and refresh to the fixed revisions. Prioritize MicroCloud clusters and any LXD host with core.https_address set.
2. Firewall the LXD API (port 8443 by default) so only management networks can reach it, and review the trust store with lxc config trust list for clients you don’t recognize.
3. Upgrade pgAdmin 4 to 9.19, especially shared server-mode deployments and Docker images (dpage/pgadmin4).
4. Until then, remove the import/export permission from non-admin pgAdmin roles.
5. If a pgAdmin server was reachable by untrusted users, rotate the database credentials saved in it.

For more patch-priority advisories, see our security tracker.