OK @kth can I get you to raise a support ticket and submit your support bundle with it? We’ll check this out

Thats ahh… really odd! I will forward this through to the team

Ooo point one is a good bug spot, thanks! I’ll get that raised.

Point two is a great suggestion, I’ll add that in as well. Thanks!

Interesting suggestion, are you able to DM me the name of the ITSM solution?

Hey @gavin.beukes sadly no, we don’t have a definitive answer yet. I’ve been working on re-tooling our test suites and labs to include DRBD storage types as we dont have that currently (which explains why you’re hitting this bug).

Love this idea @r.balboni - I’ll get it added to the backlog! Thanks!

Hey Anders
We’re aware of this and it’s being addressed in preparation for a patch release soon :) Stay tuned

Hey @pxrzival we’re unable to replicate this behaviour - are you able to provide us (directly if you’d like, in a DM or something) more details about your deployment, public IP configurations, etc.

Thanks for posting @gavin.beukes - this might be a bug introduced with the storage policies (possibly). Did this work on 1.2.0?

Excellent suggestion @miked

I’ll get this added to our backlog for sure.

Hey there @ataricze

We’re anticipating Q4CY26 for this capability. Happy to arrange a roadmap discussion if you want to send me a DM here or an email?

Many thanks

MultiPortal has published security advisory MPSA-2026-001, a stored cross-site scripting issue in user and resource name fields.

• Severity: High (CVSS v3.1 base 8.7)
• Affected: MultiPortal Core 1.1.2, 1.1.3, and 1.2.0
• Fixed in: 1.2.1

If you run an affected version, upgrade to 1.2.1 at your next maintenance window. The fix needs no data cleanup: existing names are made safe when they are displayed.

Read the full advisory, including impact, remediation, and workaround:
MPSA-2026-001 on docs.multiportal.io

The fix ships in the 1.2.1 release. To report a vulnerability privately, see Reporting security issues.

We are aware of an upstream outage outside of our control. Currently installs/updates and upgrades are unavailable. No ETA :(
Update: It’s all working now :)

Hi everyone,

MultiPortal 1.2.1 is now available. It is a patch release that tidies up a batch of issues reported after 1.2.0, and it also closes a stored cross-site scripting vulnerability, so we would encourage everyone to upgrade at their next maintenance window. Nothing here changes how you work day to day: it is fixes, one security patch, and a couple of upgrade notes worth a read before you roll it out.

The full, formatted notes live here: MultiPortal 1.2.1 release notes.

Security and access

There is a real cluster of access and isolation work in this one.

• Stored cross-site scripting is fixed. Names entered by users, and names given to resources like VDCs, virtual machines, and networks, are now encoded everywhere they are shown, including user lists and global search, and are validated when you save them. This closes a path where a crafted name could run script in another operator’s browser, including across tenant boundaries. We have published a full advisory with affected versions and remediation: MPSA-2026-001. Existing names are made safe when they are displayed, so there is no data cleanup after upgrade.
• LDAP configuration screen hardened. The Active Directory and LDAP connection-test screen no longer lets a value in the username field inject markup into the result message, and Active Directory query handling is improved. If you run LDAP, this is also a good moment to revisit how role and permission changes take effect.
• Reseller global search scoped to owned tenants. A reseller’s global search now returns only the resources inside the tenants they own.
• Cross-tenant status leak closed in the VDC machine list. The VM list on the VDC page now filters by ownership, so you only see the status of machines that belong to you. Reseller access to managed VDCs is also corrected, so a managing reseller can again read a VDC’s storage policies and convert machines to templates.
• Usage API scoping tightened. The raw usage endpoint now always reports on the VDC in the request path; an identifier passed in the query string can no longer override it.
• Less internal detail in branding errors. Custom-domain and SSL errors shown to resellers and tenants no longer include internal server addresses or file paths. The full detail is still written to the server log for support.

Reliability and performance

• Faster VM and VDC pages. The virtual machine view and the VDC machine list now render from cached data first and refresh live details in place, so the first view usually appears in under two seconds instead of ten or more. A guest agent that is enabled but not running no longer holds the page up while it waits.
• Scheduled backup log sync restored. A regression in 1.2.0 stopped scheduled-backup task logs from syncing and had each data centre logging repeated fetch failures. Logs are fetched per node again and sync correctly.

Bug fixes

• Global search works again. Running a search no longer returns an error.
• “Ghost” virtual machines can be removed. A machine that still exists in MultiPortal but no longer in Proxmox can now be removed.
• Storage policy values display correctly in Resource Allocation, Reports Allocation, and Edit VM Hardware.
• Opening a virtual machine no longer errors, and snapshot fetch failures are reported clearly rather than as an unexpected error.
• Machines created in Proxmox appear reliably in MultiPortal.
• Snapshot times show in your timezone rather than always in UTC. There is a new display-timezone setting; see Time-zone handling in MultiPortal for how it fits together.
• Proxmox Backup Server timestamps display correctly.
• The “Backup Storage usage over time” chart renders across all VDCs.
• Cloud-init is applied to the correct node after cloning, rather than the node chosen when the clone started.
• Custom-domain SSL certificate upload is fixed on hardened installs that run PHP under systemd sandboxing, with a clearer message when the web server is not yet set up for custom domains.
• Custom-domain and cleanup cron errors resolved.
• Reseller external networks and QinQ handling restored, with imported QinQ zones re-validated against the live Proxmox configuration.

API and integrations

• Raw usage endpoint fixed. GET /virtual-data-center/{id}/usage-raw no longer returns an HTTP 500 and returns raw per-machine usage as expected.
• Renaming a machine over the API no longer raises a spurious “name differs from Proxmox” alert; the Proxmox name is kept in sync.
• Network creation over the API. The REST API now supports creating internal and external networks.

Upgrading

1.2.1 includes automatic database migrations that run as part of the standard upgrade, so please back up your database first.

Two things worth knowing before you roll it out:

• Permissions settle on upgrade. The updater applies some permission changes that were intended a while ago but had not run on existing databases. On older databases this removes a little previously granted reseller access to update and delete VDCs, and a leftover tenant-admin wildcard over VDC routes. New installs already behave this way. It is worth reviewing reseller and tenant-admin roles after upgrade; this KB article walks through what to check if menu items or permissions look different afterwards.
• Keep the vm/sync task scheduled. The faster VM and VDC pages read status from a cache that the vm/sync task keeps warm. If it is not scheduled, pages show “Pending” until the first background refresh.

There are no breaking API changes. The stored XSS fix needs no data cleanup: existing names are made safe when they are displayed.

Thanks

Thanks to everyone who reported the issues that went into 1.2.1, especially the desk tickets that pinned down the timestamp and backup-sync problems. If you have already upgraded, let us know how it went, and questions or anything odd are welcome in the usual categories.

Thanks for letting us know @guillaume , we’ll take a look at this for sure

I absolutely agree, and this is something we have already put on our roadmap, only it’ll be under a full catalogue re-imagining (for the better, I promise).

Thanks for the feedback!

Heck yes, love this @guillaume . We’re in the early planning stages for tags, providing every level (provider, reseller, tenant) to tag all objects in their respective tiers. I obviously can’t give any indicative times but just know we are totally on board with tags!

Yep! Go nuts :)

Yea love the customisation!

Totally agree - this is something I’ll be working on

Hey @jimf ! We can’t seem to replicate this. What do you see under backend/runtime/logs