Security advisories

For tenant admins, partner admins and security reviewers.

Logic Unknown ApS publishes an advisory here for every vulnerability fixed in AdminExplorer, once a fixed version is available. Each advisory says which versions are affected, which version fixes it, how severe it is and what you can do until you have installed the fix. To report a vulnerability, follow the vulnerability disclosure policy. The support period and how security updates are delivered are described in Product security information.

Format

Every advisory has these fields:

Field	Content
Id	AEX-SA-YYYY-NNN: the year of publication and a running number within that year
Published	Date of publication (and of each later revision)
Affected versions	The client versions (or the portal) that have the vulnerability
Fixed version	The first version with the fix
Severity	Low, Medium, High or Critical, from the CVSS base score, with the full CVSS vector
CVE	The CVE id, when one is assigned; otherwise “None assigned”
Description	What the flaw is, without exploit steps
Impact	What could happen on an affected device
Workaround	What you can do until the fix is installed
Credits	Who reported it, with their consent

Fixes in the portal take effect for everyone at once and need no action on your devices; fixes in the client take effect when you install the fixed version (how to install updates).

Advisories

AEX-SA-2026-001: Programs relaunched in the console session on multi-session machines

Field	Value
Id	AEX-SA-2026-001
Published	2026-10-30
Affected versions	Client 2.0.64, 2.0.65 and 2.0.66
Fixed version	Client 2.0.68
Severity	Medium, CVSS 3.1 base score 5.3 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:N)
CVE	None assigned
Credits	Found by Logic Unknown ApS in an internal code review

Description. When a pre-approved program is started, AdminExplorer stops the start and starts the program again with administrator rights. Child programs that an elevated program is not allowed to start elevated are likewise started again, without administrator rights. In the affected versions, both were always started again in the session of the user signed in at the console of the machine, with that user’s identity, instead of in the session and as the user that started them. On a device with one signed-in user these are the same session and the same user, so nothing changes there. They differ only when another user is signed in at the same time in a separate session, for example over Remote Desktop.

Impact. On a machine with several signed-in users at the same time:

• A pre-approved program started by a user in a second session could start elevated on the console user’s desktop, under the console user’s identity, and its audit record named the console user. Only programs on the approved list, with the arguments set in the policy, could start this way.
• A child program started by an elevated program in a second session could start, without administrator rights, on the console user’s desktop as the console user, with the program and command line of the original user. Code chosen in one session could so run under another user’s identity; this is the reason for the Medium rating.

The elevated path is limited by your policy: only approved programs can start elevated, with their configured arguments. The more narrowly the approved list is kept (no shells, script hosts or installers that start other programs), the smaller the exposure.

Devices used by one person at a time are not affected.

Fix. Client 2.0.68, with the kernel driver it installs, starts every program again only in the session it was started in, as the user of that session. If that session cannot be determined or has no signed-in user, the program is not started again. Install client 2.0.68 (how to install updates).

Workaround. Do not install AdminExplorer on multi-session hosts (Remote Desktop Session Host, Windows multi-session) or on devices where several users are signed in at the same time. AdminExplorer does not support multi-session hosts.