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

Hey @peconi ! Yes, branding supports custom login pages for each tier. login page is derived from the custom domain if one is set.

I’ve also just had confirmation from dev’s that we’ll be supporting PVE 9.2 on this release! So I’ll go through and update our release notes and announcements everywhere to reflect that.

Hi everyone,

MultiPortal 1.2.0 is now live, and it is one of the biggest releases we have shipped. It brings finer control over storage and virtual disk performance, support for importing QinQ networks straight from Proxmox, full white-label branding across your whole channel, and self-service file-level restore for tenants, on top of a wide band of security, reliability, and usability work.

Here is the short version. Three big features lead the release: per-disk storage tuning, QinQ network import, and white-label branding. Around them sit dozens of smaller improvements, a stack of bug fixes, and a change Community edition users have been asking for. If you are upgrading, take a database backup first; everything else runs as part of the standard upgrade.

What’s new

Storage policy and virtual disk properties

You can now tune the disk-level settings that matter most for performance and compatibility, directly from your storage policies and per virtual disk. That covers disk cache mode, IO threads, AIO mode, discard, SSD emulation, and the recommended SCSI controller. MultiPortal applies these settings consistently when virtual machines and disks are created, and keeps them in place when disks are migrated between different Proxmox storage types.

The platform now tracks the SCSI controller and disk bus for each VM and disk, and validates your choices in the interface before you submit them, so you stop running into avoidable errors after the fact. When a storage policy does not suit a particular disk or controller, you get a clear warning, and you can dismiss the ones you have consciously chosen to accept.

QinQ network import

MultiPortal can now import QinQ (802.1ad) zones and VNets that already exist in your Proxmox SDN, bringing double-tagged, carrier-grade networks under management. A guided wizard discovers your QinQ zones, validates them, and assigns them to a reseller or a tenant, who then just sees a standard external network with none of the QinQ machinery underneath.

We wrote this one up in full, including the three-step import wizard and what it means for each tier. For the complete walkthrough, see QinQ zone import.

White-label branding

Make the portal your own, at every level of your channel. Service providers, resellers, and tenants can each set their own colours, font, logo, favicon, and login page, with every parent deciding how much freedom the level below it gets. Resellers and tenants can also serve the portal from their own custom domain, secured with an SSL certificate they upload or one issued automatically.

Branding cascades down the channel, too: a tenant inherits from its reseller and a reseller from you, and each parent decides whether the level below can override.

File-level restore

Tenants can now restore individual files from their backups themselves, using Proxmox’s file-level restore. There is no longer any need to restore a whole machine just to recover a single file.

Proxmox VE 9.2 support

MultiPortal 1.2.0 is tested against Proxmox VE 9.2. We have not built on any of the new 9.2 capabilities yet, but we have run our integration against the 9.2 APIs and confirmed that nothing you rely on today is lost, so you can move your hosts to 9.2 and keep managing them through MultiPortal exactly as before.

Security and access

This release tightens isolation and login handling across the board:

• Stronger tenant data isolation. Resources now stay correctly scoped to the tenant they belong to, closing paths where information could be seen outside its intended scope.
• Template sharing scoped correctly. Sharing a converted VM template now applies only to the intended scope, rather than being exposed more widely within a datacentre.
• More reliable single sign-on. SP-initiated SAML login has been hardened, including correct role assignment for newly provisioned users.
• Service Provider login isolation. Service Provider administration can now be restricted to its own dedicated login URL.
• Single session per user. You can now enforce a single active session per user.

Reliability and performance

• Faster usage synchronisation. Usage sync is now quicker and more reliable on larger environments, so usage data keeps pace with your reporting intervals.
• Leaner reporting. Reports take fewer resources to generate, and pay-as-you-go usage history is now kept after a virtual machine is deleted, so past usage stays available for billing and review.
• Accurate storage usage. Storage now totals correctly on VDC summaries, multiple storage policies are no longer added together by mistake, and total ISO usage is reported accurately. A VDC storage policy can be removed after a disk migration between Proxmox storages, and VDC deletion no longer stalls part-way through.

Also in 1.2.0

• Community edition limits removed. The caps on the number of resellers, tenants, and VDCs are gone from the Community edition. The 4-socket and feature restrictions stay.
• Japanese language support. Japanese joins the list of supported portal languages.
• Interface refinements. A range of interface and dark-mode improvements across the portal.

Upgrading

1.2.0 includes automatic database migrations that run as part of the standard upgrade. Please back up your database before you upgrade. We also recommend reading the documentation for anything new to your environment, particularly the storage disk properties and QinQ import, before you roll them out in production. Step-by-step instructions are in the upgrade guide, and the full notes will be in the 1.2.0 release notes: [TODO: release notes link once published].

Thanks, and what’s next

Thank you to everyone who told us what they needed in this release. A lot of 1.2.0, QinQ import and white-label branding especially, came straight from operators telling us how they run and sell. If you want to see where things are heading next, take a look at our roadmap for 1.2, 1.3 and 1.4.

If you have already upgraded, let us know how it went. Questions, bug reports, and feature requests are all welcome in the usual categories!

@gregoryl Thanks for the background!

I’ve actually got a Terraform provider planned but as you’ve discovered, we’re waiting for the per-tier API to be fully functional before we release :)

Hey @r.balboni

We’re aware of this requirement. There’s a lot of planning, assumption testing, security and isolation modelling I want to do before we jump the gun and ship something like this, especially if we consider giving resellers the ability to manage this.

Rest assured though, we have it on our backlog :)

Hey @danielbfusionred we’re actually adding something like this for storage changes in the next release. Feedback noted: we’ll look at adding pending reboots for other changes.

Hey MikeD, thanks for the post! We’re aware of this bug and we’re already investigating it.

Hey @r.balboni

I’ve got this on the roadmap for 1.3.0. I’m literally reviewing roadmap items and timings (along with specifications) now, and it’ll definitely be in :)

Thanks

Absolutely, 100% agree with you! Which is why we’re performing a ground-up rewrite of our authentication and authorisation system which will deliver excellent granularity and control over per-tier API endpoints. The current target is this year :)

@AlessandroRamon

Love the idea for an Italian translation! I’ll add it to the backlog.

Here’s a tiny spoiler: tier-specific documentation (Provider, Reseller, Tenant).