Bug Report

When testing a PowerShell Universal API endpoint using the built-in Test tab, it is not possible to send a request with the Content-Type: application/json header. The Test UI only allows adding a header named ContentType, but this does not result in an actual HTTP Content-Type header being sent. As a result, the request body is not treated as application/json, and parameter binding does not work. Steps to reproduce Create an API endpoint like: param( [string]$Subject, [string]$Description, [string]$Reference ) return New-PSUApiResponse -StatusCode 200 -Body $Subject Open the endpoint's Test tab. Configure: Method: POST Header: ContentType: application/json Body: { "Subject": "PSU Test", "Description": "Description Stuff", "Reference": "PSUTEST-2", } Click Invoke . Expected behavior The request should be sent with: Content-Type: application/json and the JSON body should be bound to the parameters: $Subject = "PSU Test" Actual behavior Parameter binding fails with an error similar to: A parameter cannot be found that matches parameter name '{ "Subject":"PSU Test", ... }' The same request works correctly when sent externally (e.g. via Invoke-RestMethod, Postman, or curl) with a proper Content-Type: application/json header.

Version: 2026.2.1 I went to rerun a job and the popup doesnt show any labels on my params, or any values as seen here: [image] Notice the 3 params in the background, all are switches. (There's an additional parameter defined in the script - a string, but it was not supplied in the schedule that ran this.)

I use Invoke-PSUScript to start jobs from endpoint calls, and frequently use the Log tab in the endpoint code editor for debugging or traceback etc. Sadly this log is hard to read for 2 reasons: 1) it does not support ANSI sequences, but still displays them as text. 2) return values from Invoke-PSUScript do get written in the log, even if they are captured. So a simple $DisplayName = Invoke-PSUScript -Script 'getUser.ps1' -Wait sould not write the return value itself to the log, since it is captured in a variable, but it still does and on top all outputs (return / write-Information, etc) of that script contain ANSI sequences: [Information] [Api-/data/getUser:GET] DisplayString : John Doe So I would love to either have the log support those ANSI sequences or have it stripe them off. Also, captured return values from scrips should not appear in the log, which would be consistend to the powershell behavior in general.

Hello, After upgrading from 2026.1.6 to 2026.2.0, a domain user can no longer start a script manually from the admin console. The job fails immediately with Failed to start script. Unknown identity: DOMAIN\Account I did some troubleshooting before posting here and I found out that the console identifies me as DOMAIN\Account (with domain name in uppercase), and automatically creates an identity for me that I can find under Security > Identities. This automatically generated identity is stored as domain\account (With domain in lowercase). I manually created a second identity for my account with domain name in uppercase, and I was able to start a job successfully. Here are some details about my environment : Version: 2026.2.0 Auth: Windows Authentication, AD domain account Database: PostgreSQL Licensed: Yes Install: As a Windows Service with SYSTEM account Thank you in advance for your help.

V2026.2.2 IIS Hosting w/ MS SQL Persistence Two rather large issues I've been seeing, the first one more recent, far more pressing. I updated our beta environment to 2026.2.2 in hopes this would be resolved, but still seeing this error whenever trying to create new endpoints, anybody else seeing this? I've noticed it in the last few versions, and hoped it would have cleared itself up by now. After this error, the page usually temporarily returns a 503 error from IIS, as the app pool tends to recycle itself after this error presents, so thinking something's crashing. [image] Another I've noticed is when it comes to variables, we've been seeing this for a while, just never really gotten around to bringing it up, since we have found a workaround... When we create a variable of type "secret" and store it in the Database vault, the resulting entries in the Database show a duplicated, blank entry in "Variable" table for the new variable that was just created. This results in the variables page just spinning, never loading. The only fix has been to manually remove the "blank" row in the DB, and then it starts working again, and the secret works. [image] [image]

fyi :) [image]

it used to tell you the current version and if there was an upgrade. by accident, we found it by scrolling all the way down on the home page and found it in the bottom right. not easy to find.

If you use credential on apps and upgrade from 2026.1.7 to 2026.2, 2026.2.1 or 2026.2.2 The app will be unable to start. If you remove the credential the app will be able to start. If you then set a credential and restart the app - the app will fail to start an report this: An error occured. Failed to login user (1326). System.ComponentModel.Win32Exception (1326): The user name or password is incorrect. at PowerShellUniversal.Automation.ProcessHelper.LogInOtherUser(ProcessStartInfo processStartInfo) in D:\a\powershell-universal\powershell-universal\src\PowerShellUniversal.Automation\ProcessHelper.cs:line 156 at PowerShellUniversal.Automation.ProcessHelper.StartProcess(ProcessStartInfo processStartInfo, ILogger logger) in D:\a\powershell-universal\powershell-universal\src\PowerShellUniversal.Automation\ProcessHelper.cs:line 41 at PowerShellUniversal.Automation.JobProcessManager.StartProcessAsNewUser(String powerShellPath, String commandLine, Variable credential, Dictionary`2 environmentVariables, String verb) in D:\a\powershell-universal\powershell-universal\src\PowerShellUniversal.Automation\JobProcessManager.cs:line 914 at PowerShellUniversal.Automation.JobProcessManager.StartProcess(ExecutionEnvironment environment, Variable credential, String powerShellPath, String commandLine, ProcessType type, Action`1 onAgentOutput, Dictionary`2 environmentVariables) in D:\a\powershell-universal\powershell-universal\src\PowerShellUniversal.Automation\JobProcessManager.cs:line 684 at PowerShellUniversal.Automation.JobProcessManager.StartDashboard(Int32 port, ExecutionEnvironment environment, Variable credential) in D:\a\powershell-universal\powershell-universal\src\PowerShellUniversal.Automation\JobProcessManager.cs:line 429 at Universal.Server.Services.DashboardProxy.StartOutOfProcessAsync(Dashboard dashboard, ExecutionEnvironment environment) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Services\Dashboard\DashboardProxy.cs:line 242 at Universal.Server.Services.DashboardProxy.Start(Dashboard dashboard) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Services\Dashboard\DashboardProxy.cs:line 98 at Universal.Server.Services.DashboardManager.StartOnNode(Dashboard dashboard) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Services\Dashboard\DashboardManager.cs:line 95 at Universal.Server.Services.DashboardManager.Start(Dashboard dashboard) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Services\Dashboard\DashboardManager.cs:line 46 at Universal.Server.Services.DashboardManager.Restart(Dashboard dashboard) in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Services\Dashboard\DashboardManager.cs:line 138 at PowerShellUniversal.AppPowerMenu.Restart() in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Shared\Apps\AppPowerMenu.razor:line 98 at Microsoft.AspNetCore.Components.ComponentBase.CallStateHasChangedOnAsyncCompletion(Task task) at AntDesign.MenuItem.HandleOnClick(MouseEventArgs args) at Microsoft.AspNetCore.Components.ComponentBase.CallStateHasChangedOnAsyncCompletion(Task task) at Microsoft.AspNetCore.Components.RenderTree.Renderer.GetErrorHandledTask(Task taskToHandle, ComponentState owningComponentState)

Product: PowerShell Universal 2026.2.1 (upgraded from 2026.1.1 — issue does not exist on 2026.1.1) Environment: Linux (Docker), multi-node, PostgreSQL, configuration as code (git-synced .universal repository) Summary Since upgrading to 2026.2.1, endpoint URL validation rejects a static endpoint URL whenever a parameterized endpoint exists whose path starts with the same segments. The two routes are distinct (different segment counts) and represent the standard REST collection/item pattern ( GET /resource + GET /resource/:id ). This configuration has been working unchanged since v4 and loads fine on 2026.1.1. Minimal reproduction endpoints.ps1: New-PSUEndpoint -Url "/test" -Method GET -Endpoint { "static" } New-PSUEndpoint -Url "/test/:param" -Method GET -Endpoint { $Param } On configuration sync, validation of the static URL fails with: Endpoint URL /test is not valid. It matches an existing internal URL: GET:/test/:param Important detail for reproducing this: the error does not necessarily appear on the very first registration into an empty database. It appears once the parameterized route is already registered — i.e. on the next configuration sync, after a restart, or when a second node in a multi-node setup loads the same repository. This may be why issue #5627 (same error class, App URLs) could never be reproduced in-house. Real-world error (verbatim) Invalid configuration: endpoints.ps1 (Endpoint URL /v1/runner/jobs is not valid. It matches an existing internal URL: POST:/v1/runner/jobs/:jobId/status at PowerShellUniversal.Configuration.UrlValidator.ValidateStaticUrls[T](T item, String url, String[] methods) in src\PowerShellUniversal.Configuration\UrlValidator.cs:line 185 at PowerShellUniversal.Configuration.UrlValidator.Validate(Endpoint endpoint) in src\PowerShellUniversal.Configuration\UrlValidator.cs:line 47 at PowerShellUniversal.Configuration.EndpointService.UpdateAsync(ModelOperationContext`1 context) in src\PowerShellUniversal.Configuration\Endpoints.cs:line 213 at UniversalAutomation.Services.ConfigurationScript`1.ReadAsync(...) in src\PowerShellUniversal\ConfigurationScript.cs:line 461 Our production configuration (unchanged for years): POST /v1/runner/jobs GET /v1/runner/jobs GET /v1/runner/jobs/:jobId POST /v1/runner/jobs/:jobId/status GET /v1/runner/jobs/:jobId/status ... Note that /v1/runner/jobs (3 segments) is reported as "matching" POST:/v1/runner/jobs/:jobId/status (5 segments). A correct route matcher can never match these two — it looks like `ValidateStaticUrls` truncates parameterized route templates at the first route parameter and then compares the remaining prefix against static URLs. Knock-on effects environments.ps1 is marked invalid with the same error, because the environments sync re-triggers endpoint validation: at PowerShellUniversal.Configuration.EnvironmentsConfigurationScript.OnReadAfterAllAsync(SyncContext syncContext) in src\PowerShellUniversal.Configuration\Environments.cs:line 43 So a single validation false positive invalidates both the endpoints and the environments configuration — the entire custom REST API is down. In our case several hundred deployed agents lost connectivity after the upgrade; this is a hard outage for us. What we tried Curly-brace syntax ( /test/{param} ) instead of :param — not supported, does not work. Reordering the endpoint definitions — no effect (validation compares against routes already registered from the previous sync / the other node). Looked for a setting to disable or relax endpoint URL validation — none exists as far as we can tell (neither in appsettings.json nor in the feature flags). Merging the two routes into a single endpoint is not possible: an endpoint has exactly one URL, and /test must remain directly callable. Renaming routes so that no static URL is a prefix of a parameterized one would break all deployed API clients — not feasible. Expected behavior A static URL should only be rejected when it actually conflicts with an existing route (same method and same path shape/segment count) — as was the case up to and including 2026.1.1. Related https://github.com/ironmansoftware/powershell-universal/issues/5627 — same error class for App URLs ("was working for years"), closed unresolved when the repo was archived. The reproduction above is deterministic and should finally make this debuggable. The validator appears to have been introduced with the CVE-2026-3563 fix (advisory DEVO-2026-0008) in 2026.1.4. We jumped from 2026.1.1 directly to 2026.2.1, so this validation ran against our repository for the first time. Questions Can the false positive in UrlValidator.ValidateStaticUrls be fixed so that the standard REST pattern ( GET /resource + GET /resource/:id ) validates correctly again? Until a fix ships: is there any supported way to bypass or relax endpoint URL validation? We are currently blocked from running 2026.2.x at all.

PSU 2026.1.6 [image] The UI says seconds, but based on the documentation and real world testing, this is actually minutes https://docs.devolutions.net/powershell-universal/powershell-commands/new-psuscript#timeout

PSU 2026.1.6 Priority: High The behaviour has been more stable in recent releases, but modules that are not in the main PSU repo are still vanishing after a git sync when the sync changes files in the main repo. This can be fixed by the known method of reloading modules. If the git sync is stale and has no changes to sync, things are stable and don't require manual intervention. So: automated git sync -> git detects changes and PSU reloads config(?) -> git sync delayed trigger -> PSU script getting submodules -> modules with PSU resources vanish in the script view This is the general sequence, but I can't tell when exactly in the process the external modules vanish. It might be as early as the second step and everything after it doesn't matter. The consequence of this is not only cosmetic, the vanishing resources also can't be triggered via Invoke-PSUScript anymore.

PSU Version: 2026.2.1 Custom script base path configured in settings I'm trying to move this: SubFolder1\ScriptName.ps1 into SubFolder1\SubFolder2\ScriptName.ps1 I click edit properties on my existing script, choose the new folder from the drop down, then hit OK. No errors, and I get a toast saying "Script Saved", but the script stays in the same location.

I m running into issues while accessing variables for a while now and I could finally pin down two reproducable issues. I created 3 Secret variables: SecTest = Secret without any role SecTestRole = Secret with added role after creation SecTestRoleRem = Secret with added role after creation, then removed the role again SecTest should now be equivalent to SecTestRoleRem, but turns out, they are not. Small script to inspect variables: $names = @("SecTest","SecTestRole","SecTestRoleRem") $names | ForEach-Object { Write-Information "Access via Secret:name Secret:$_ :" Write-Information (Get-ChildItem "Secret:$_") $PSUVariable = Get-PSUVariable -Name $_ Write-Information ($PSUVariable | ConvertTo-Json) } Result of the Script: Access via Secret:name Secret:SecTest : S123456 { "Id": 23, "Name": "SecTest", "Value": null, "UserName": null, "Password": null, "Secret": true, "Vault": "Database", "Type": "System.String", "Description": null, "MissingSecret": false, "DisableRunAsSupport": false, "DeleteSecret": false, "ReadOnly": false, "Database": false, "Role": null, "Scope": 0, "Tags": [], "Tag": [], "Roles": null, "Force": false, "Module": null, "Required": false, "PasswordNotRequired": false, "SourceModule": null, "SourceModuleBase": null, "DisplayValue": "" } Access via Secret:name Secret:SecTestRole : 78293479 { "Id": 26, "Name": "SecTestRole", "Value": null, "UserName": null, "Password": null, "Secret": true, "Vault": "Database", "Type": "System.String", "Description": null, "MissingSecret": false, "DisableRunAsSupport": false, "DeleteSecret": false, "ReadOnly": false, "Database": false, "Role": [ "Execute" ], "Scope": 0, "Tags": [], "Tag": [], "Roles": [ "Execute" ], "Force": false, "Module": null, "Required": false, "PasswordNotRequired": false, "SourceModule": null, "SourceModuleBase": null, "DisplayValue": "" } Access via Secret:name Secret:SecTestRoleRem : The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: Cannot find path 'SecTestRoleRem' because it does not exist. 2 Issues: None of the secret variables contain a "Value" or "DisplayValue", which I would expect them to. SecTestRoleRem is no longer accessable via (Get-ChildItem "Secret:SecTestRoleRem") after the role removal. To add further details, this script: Write-Information "SecTest" Write-Information ($Secret:SecTest) $PSUVariable = Get-PSUVariable -Name "SecTest" Write-Information ($PSUVariable | ConvertTo-Json) Write-Information (Get-ChildItem "Secret:SecTest") Write-Information "SecTestRoleRem" Write-Information ($Secret:SecTestRoleRem) $PSUVariable = Get-PSUVariable -Name "SecTestRoleRem" Write-Information ($PSUVariable | ConvertTo-Json) Write-Information (Get-ChildItem "Secret:SecTestRoleRem") Should basically handle both secret variables the same, since they are configured the same, but will result in: SecTest S123456 { "Id": 23, "Name": "SecTest", "Value": null, "UserName": null, "Password": null, "Secret": true, "Vault": "Database", "Type": "System.String", "Description": null, "MissingSecret": false, "DisableRunAsSupport": false, "DeleteSecret": false, "ReadOnly": false, "Database": false, "Role": null, "Scope": 0, "Tags": [], "Tag": [], "Roles": null, "Force": false, "Module": null, "Required": false, "PasswordNotRequired": false, "SourceModule": null, "SourceModuleBase": null, "DisplayValue": "" } S123456 SecTestRoleRem System.Management.Automation.InformationRecord { "Id": 28, "Name": "SecTestRoleRem", "Value": null, "UserName": null, "Password": null, "Secret": true, "Vault": "Database", "Type": "System.String", "Description": null, "MissingSecret": false, "DisableRunAsSupport": false, "DeleteSecret": false, "ReadOnly": false, "Database": false, "Role": null, "Scope": 0, "Tags": [], "Tag": [], "Roles": null, "Force": false, "Module": null, "Required": false, "PasswordNotRequired": false, "SourceModule": null, "SourceModuleBase": null, "DisplayValue": "" } The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: Cannot find path 'SecTestRoleRem' because it does not exist. So removing roles from secret variables does break them. Adding back a role, makes them usable again, until you remove the role again. And Get-PSUVariable on secrets does not retrieve the value. PSU Version2026.2.0

PSU 2026.1.6 In Automation -> Jobs when selecting columns, if you select 'Origin', the table updates one last time and after that it gets stuck. You can select and deselect what you want, it doesn't update the columns and it doesn't refresh the table anymore. Also after selecting it, Origin appears two times in the list of selectable columns. Right now, as I see it, the only way to reset the view would be to delete the user or execute SQL: UPDATE "main"."Identity" SET "JobColumns" = NULL WHERE "name" = "USERIDENTITY"

I've currently tested terminals on multiple versions of PSU on Windows Server 2022 and 2026 as well as Ubuntu 24.04.4. I start a fresh install, and without fail so far, every version beyond 2026.1.3 will fail to launch any terminal other than one tied to the Integrated environment. This includes the current latest, 2026.2.1 with the built-in PS7 environment as well as the Windows PowerShell environment on Windows. [image] The logs seem to show that it is launching successfully but it does not show this in the GUI: [11:47:56 INF] PowerShellUniversal.Automation.JobProcessManager Starting job using Process as interactive. [11:47:56 DBG] PowerShellUniversal.Automation.JobProcessManager Agent Output: Received: ParentProcessId: 18064 UniversalPort: 62209 InstanceId: 9 [11:47:56 DBG] PowerShellUniversal.Automation.JobProcessManager Agent Output: Connecting to universal. [11:47:56 DBG] PowerShellUniversal.Automation.JobProcessManager Agent Output: D0629 11:47:56.370232 Grpc.Core.Internal.UnmanagedLibrary Attempting to load native library "D:\psu\versions\Universal.win-x64.2026.2.1\Hosts\7.5\grpc_csharp_ext.x64.dll" [11:47:56 DBG] PowerShellUniversal.Automation.JobProcessManager Agent Output: D0629 11:47:56.429861 Grpc.Core.Internal.NativeExtension gRPC native library loaded successfully. [11:47:56 DBG] PowerShellUniversal.Automation.JobProcessManager Agent Output: Server port:61507 I've not been able to find anyone else reporting this happening, but it's been pretty consistent for me across multiple servers and OSes. Anyone else see this or know of a solution?

After upgrading to 2026.2.0 for IIS, I am unable to access the settings for my Git remote in order to update a GitLab PAT. Sync is non-functional at this time. All was fine before upgrade. This issue appears on multiple development installs. I've reverted production to a previous VM snapshot. An error occured. Value cannot be null. (Parameter 'source') at System.Linq.ThrowHelper.ThrowArgumentNullException(ExceptionArgument argument) at System.Linq.Enumerable.<ToArray>g__EnumerableToArray|324_0[TSource](IEnumerable`1 source) at PowerShellUniversal.GitSettingsForm.OnInitializedAsync() in D:\a\powershell-universal\powershell-universal\src\Universal.Server\Shared\Settings\GitSettingsForm.razor:line 144 at Microsoft.AspNetCore.Components.ComponentBase.RunInitAndSetParametersAsync() at Microsoft.AspNetCore.Components.RenderTree.Renderer.GetErrorHandledTask(Task taskToHandle, ComponentState owningComponentState)

I m on Version 2026.2.0: I use the API Base folder setting. Not sure if this is relevant for the issue: [image] Reproduce: 1. Create an endpoint to a file [image] 2. edit code in editor, save any change, then click "Edit Endpoint Properties" [image] 3. edit the Execution role and hit "OK" [image] 4. reload the page or enter the code editor again and the code is cleared. [image] Something apparently overwrites the codebase/file when editing properties in the editor after making changes to the code and saving them. This does only happen, when you made changes in the editor and saved them before editing the properties. Hence if you did not made any changes to the code, before changing properties, or if you change and save something after editing the properties the file will stay populated.

Not sure if this is expected behavior: [image] For jobs that execute child jobs, in this instance it's a AI agent job executing 'tool' scripts. The child jobs show and I can close/expand from the parent, but the child jobs are also showing as their own separate entries too. It feels like it would be much cleaner to have child jobs only show under the nested parent and hidden from the list in the job view, wasn't sure if this is expected or a bug?

When using this setting: [image] First of all, the folder explorer will not work any more: [image] As well as selecting a folder for new scripts does not work as well: [image]

When attempting to edit the properties of an AI tool I always get the following toast popup: Script file 'SubFolder1\SubFolder2\Get-MgUser.ps1' does not exist. I have to delete the tool and re-add it (with the exact same script path). I'm running 2026.2.0 on windows, as a service. I have a custom script path configured in my settings (my hunch is it's to do with this, but havent been able to test without).

PSU 2026.1.6 Priority: High When using multiple MCP tools in parallel (e.g. >10) the server CPU load caps at 100% for several seconds and PSU gets unresponsive. Each MCP job spawns a Universal.Host process that consumes approximately 7~10% CPU. These jobs do very light work, most just start an asynchronous REST API call and check for completion with most calls completing in seconds. I'd wager the time it takes for PSU to prepare these jobs is greater than the time it takes for the content of the jobs to finish. Our AV and EDR tools are surely involved in creating this load and we are testing what happens if they are off or the PSU processes are excluded. But I don't think this will fully fix the problem. I would like to have the load problem permanently fixed, but for a workaround i would be satisified with a rate limiting for MCP tools. Can you please - either fix the problem or create a workaround - in the 2026.1.x version family? This happens on both of these types of machines: RDP -> VM (dev machine) Windows Server 2019 local access HTTP Portable zip 6 cores @ 2.80GHz 24GB RAM LB -> VM (test machine) Windows Server 2022 remote access HTTPS with official cert MSI install 4 cores @ 2Ghz (restricted by hypervisor policy) 8GB RAM I haven't tested it yet on our prod cluster, but i would expect the same: LB -> 2 VMs Windows Server 2022 remote access HTTPS with official cert MSI install 4 cores @ 2Ghz (restricted by hypervisor policy) 8GB RAM

Hi All With newest Docker Image 2026.2.0-ubuntu-24.04 im unable to login. The File _framework/blazor.server.js is not available anymore which results in a JS Crash: [image] Result: Black Website after Login. Looks like the Image has never been tested for me 😕 Best Regards Andreas

Looks like Published Folders stopped working. I'm seeing this repeated in the system logs. 2026-06-01 09:38:01.561 -05:00 [INF][Microsoft.AspNetCore.Hosting.Diagnostics] Request starting HTTP/2 GET https://dev-universal.xxxxxx.com/login?returnUrl=/admin/platform/publishedFolders - null null 2026-06-01 09:38:01.566 -05:00 [INF][Microsoft.AspNetCore.Authentication.Cookies.CookieAuthenticationHandler] Cookies was not authenticated. Failure message: Identity missing in session store 2026-06-01 09:38:01.580 -05:00 [INF][Microsoft.AspNetCore.Routing.EndpointMiddleware] Executing endpoint '/Login' 2026-06-01 09:38:01.580 -05:00 [INF][Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker] Route matched with {page = "/Login", action = "", controller = ""}. Executing page /Login 2026-06-01 09:38:01.583 -05:00 [INF][Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker] Executing handler method PowerShellUniversal.Login.OnGet - ModelState is "Valid" 2026-06-01 09:38:01.690 -05:00 [INF][Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker] Executed handler method OnGet, returned result Microsoft.AspNetCore.Mvc.RazorPages.PageResult. 2026-06-01 09:38:01.692 -05:00 [INF][Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker] Executed page /Login in 109.4217ms 2026-06-01 09:38:01.693 -05:00 [INF][Microsoft.AspNetCore.Routing.EndpointMiddleware] Executed endpoint '/Login' 2026-06-01 09:38:01.693 -05:00 [INF][Microsoft.AspNetCore.Hosting.Diagnostics] Request finished HTTP/2 GET https://dev-universal.xxxxxx.com/login?returnUrl=/admin/platform/publishedFolders - 200 null text/html; charset=utf-8 129.376ms

We've updated our container from 2026.1.7-azure to 2026.2.0-azure The webapp restarted successfully, but we are not able to open de /admin pages. The page shows an empty page, no errors are shown. Direct links to pages in the admin portal, e.g. /admin/platform/logging, will also show no information and the page stays empty. We reverted the image back to 2026.1.7-azure, then the admin portal works again. The dashboard (apps) are working properly.

Summary When a PowerShell Universal app is mounted at /, the built-in reset-password route can be intercepted by the app route surface. This prevents the normal reset-password page from loading when a local user's password has expired or when navigating directly to the reset-password URL. The issue started in 5.5.0 and persists through the current version 2026.2.0. To Reproduce Create an app mounted at / with app-level PageNotFound and NotAuthorized handlers. New-PSUApp -Name 'ResetPasswordRootRouteRepro' -BaseUrl '/' -Authenticated -Content { New-UDApp ` -Title 'Reset Password Root Route Repro' ` -PageNotFound { New-UDTypography -Text 'Custom PageNotFound' } ` -NotAuthorized { New-UDTypography -Text 'Custom NotAuthorized' } ` -Content { New-UDTypography -Text 'Home Page' } } Then browse to the built-in reset-password route. /reset-password?username=admin Expected Behavior The built-in reset-password page should load normally, even when an app is mounted at /. The reset-password route is part of the integrated authentication flow, so it should not be handled by the app's PageNotFound or NotAuthorized handlers. Actual Behavior When the app is mounted at /, the built-in reset-password route is intercepted by the app route surface. Workaround Mount the app at a non-root base URL instead of / if the built-in reset-password flow needs to remain available. For example, use a base URL such as /app or another non-root path. Suggested Fix Direction The built-in /reset-password route should probably be reserved ahead of root-mounted app routing, similar to how other integrated platform routes are protected from app catch-all behavior. If root-mounted apps are expected to own this route, then the documentation should call out that apps mounted at / can interfere with built-in authentication routes such as /reset-password.