PENTESTY · EDITORIAL ANALYSIS · · 4 min read
SolarWinds ARM: who authorizes what the integration changes in the directory?
A tool reviewing permissions also uses permissions to operate. Check who may request changes and what authority the integration receives to perform them.
By Pentesty
The alert has its own product, version and scope
On September 17, 2026, SolarWinds published CVE-2026-28326: unauthenticated remote execution in Access Rights Manager associated with a static product key. The advisory lists ARM 2026.2 and earlier versions, with a fix in ARM 2026.2.1. The published vector is AV:A, involving adjacent-network access. These sources establish neither compromise of a specific environment nor automatic compromise of an entire directory. The analysis below proposes an authorized integration review.
Map the operation beyond the permissions screen
Imagine an analyst authorized to review a team’s access. The application may serve the request using a technical identity with different reach. Inventory needs to show that relationship, including queries and changes. Identify the responding process’s authority.
Choose an operation and follow its requester, accounts used and destination resource. Record who maintains configuration and who approves, reviews and removes access when the service changes.
Connect each permission with the function needing it
ARM requirements documentation distinguishes permissions by function, including Active Directory reading, modification and delegation to organizational units. Consult guidance matching the deployment and compare it with configured accounts. Plan changes around support requirements, operational impact and the necessary recovery procedure.
Pentesty proposes mapping permitted operations, reachable resources and approval owners. A technical account may need to write in one area; that does not establish whether every requester may initiate the write. The JadePuffer deletion-authority analysis helps frame questions about effective reach. Its product and mechanism differ.
Test approval using fictional objects
Prepare an authorized environment with test resources representing the selected boundary. Agree accounts, reversible changes, the window and stopping criteria with directory operators. Check the permitted path and expected denial using fictional objects without exploiting the CVE.
Define how to recognize the destination effect. A success message may only acknowledge receipt. Retain identifiers to compare the request, decision and observed state, limiting records to what is necessary.
- Requester: a query identity receives the authorized result and cannot initiate a change outside its role.
- Destination: an approved operation reaches only the fictional objects included in scope, respecting the agreed boundary.
- Execution: the observed change can be connected to the technical account, approved request and exercise timing.
- Closure: objects return to their expected state and temporary access is removed with owner confirmation.
Keep the decision traceable to the resource
The report should identify the operation, identities, object set and configuration assessed. Record questions depending on third parties and areas excluded from the exercise. Another owner should be able to understand why the operation was accepted and which evidence supports its reach.
Repeat relevant cases when service accounts, delegation, integrations or user roles change. Begin with a critical operation and expand as dependencies become clear. The deliverable shows who could request action, what received approval and which directory effect was confirmed.
Frequently asked questions
Does the flaw establish compromise of an entire Active Directory?
The advisory describes an ARM vulnerability. Reach within an environment depends on deployment and permissions; a conclusion about compromise requires its own evidence.
Is a dedicated service account already sufficiently restricted?
Dedication helps identify its purpose, but operations, resources and delegation still need review. Connect each permission to its function and applicable support guidance.
How can we test without changing real accounts?
Use fictional identities and objects in an authorized environment, with reversible changes and an agreed return. Compare the permitted operation with an attempt that should be denied.
Does an approval test remove the need to update ARM?
They are different deliverables. Maintenance should follow vendor guidance, while authority assessment needs to show which requests and effects were permitted within tested scope.
Sources and references
- SolarWinds: CVE-2026-28326 advisory
- SolarWinds: ARM 2026.2.1 release notes
- SolarWinds: ARM account requirements and permissions
Original Pentesty analysis, published October 16, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.