TL;DR: Microsoft’s September release set a new record at 964 CVEs, with 104 critical issues, 860 important issues, and two zero-days already exploited in the wild, while Adobe Commerce’s unauthenticated RCE was attacked before patching, according to Expel. The lesson is straightforward: exploitability and blast radius still matter more than patch volume, especially when credentials and privileged paths are exposed.
At a glance
What this is: This is an independent analysis of a record Microsoft Patch Tuesday and a separately exploited Adobe Commerce RCE, with the key finding that actively abused flaws and unauthenticated attack paths should dominate remediation order.
Why it matters: It matters because identity and access controls often determine whether a vulnerability becomes full compromise, especially when attackers can move from low privilege to SYSTEM, steal tokens, or reuse exposed credentials.
By the numbers:
- Microsoft’s September release included 964 CVEs, 104 rated critical and 860 rated important.
- Elevation of privilege made up 44.7% of this month’s CVEs.
- Remote code execution accounted for 26.8% of this month’s CVEs.
- Adobe Commerce StyleSmuggler carried a CVSS score of 10.0 and needed no authentication.
👉 Read Expel's analysis of the September Patch Tuesday zero-days and Adobe Commerce RCE
Context
Microsoft’s September patch cycle shows how vulnerability volume can obscure the risks that matter most. When a release includes exploited zero-days, elevation-of-privilege flaws, and remote code execution in the same month, prioritisation has to shift from counting advisories to identifying which weaknesses can hand attackers privileged control fastest. That is especially true where identity boundaries collapse after initial code execution.
The Adobe Commerce issue reinforces the same governance problem from a different angle. An unauthenticated RCE does not just create application risk, it can become an access-control problem once attackers use the platform to execute code, persist, and steal the secrets that protect admin, API, and payment workflows. In identity terms, the breach path is typical of modern compromise patterns, not an outlier.
Key questions
Q: What breaks when an unauthenticated RCE lands in a system that stores credentials?
A: The boundary between application compromise and identity compromise breaks immediately. Attackers can use code execution to reach tokens, keys, passwords, and deploy credentials that were meant to remain outside the app trust zone. That turns one vulnerability into a wider access problem that patching alone cannot solve.
Q: Why do exploited privilege-escalation flaws outrank larger patch backlogs?
A: Because exploit status changes the threat from possible to active, and privilege escalation changes the consequence from local compromise to full system control. A backlog of low-risk issues can wait. A flaw already delivering SYSTEM or equivalent access can become the bridge to credential theft and persistence.
Q: What are the signs that post-exploit persistence is already in place?
A: Look for restart jobs, disguised system processes, unusual kernel-thread impersonation, new binaries surviving reboots, and access patterns that continue after the original exploit vector should have been closed. Those signals show the attacker is relying on durable control, not a one-time exploit.
Q: How should teams respond when a public-facing commerce platform may have leaked secrets?
A: Assume the platform’s trust boundary has expanded beyond the web tier and verify every credential it could reach. That means rotating admin, API, database, payment, and deployment secrets, checking for secondary access, and confirming that the attacker did not move from application execution into broader identity reuse.
Technical breakdown
Why exploited zero-days outrank large patch counts
A patch cycle with hundreds of CVEs is not unusual in large ecosystems, but exploited zero-days change the response model. Once a flaw is already in active use, the question is no longer whether it is theoretically dangerous. It is whether attackers can reach privileged execution before defenders can compress exposure. In this article, the two Windows issues matter because both lead to SYSTEM compromise through different paths, one through link-following abuse in the update stack and one through sandbox escape in ALPC. Those are privilege boundary failures, not just software defects.
Practical implication: prioritise exploited privilege-escalation flaws before routine backlog work and align patching with privilege exposure, not only severity scores.
How unauthenticated RCE turns application compromise into identity compromise
Unauthenticated remote code execution is especially dangerous in platforms that store or process credentials, tokens, and signing material. Once the attacker can execute code inside the application context, the platform itself can become the pivot into higher-value access. That is what makes the Adobe Commerce issue more than an application bug: the code path can reach stored secrets, admin workflows, and downstream services that trust the platform. From an IAM and NHI perspective, the real problem is not just code execution. It is the opportunity to harvest standing credentials and abuse them before detection catches up.
Practical implication: treat internet-reachable RCE in commerce platforms as a secrets exposure event until token and key integrity is verified.
Why persistence and secret rotation decide the post-exploit outcome
The presence of a persistent implant changes the remediation question. If attackers can survive restarts, masquerade as legitimate system activity, and continue accessing protected workflows, patching alone only closes the original door. The article’s description of Adobe recommending rotation of admin passwords, REST and GraphQL tokens, OAuth client secrets, payment gateway credentials, database credentials, SSH and deploy keys, and extension API keys shows that the compromise boundary extends well beyond the application binary. This is a classic example of credential propagation after initial access.
Practical implication: verify persistence first, then rotate every credential and key path that the compromised application could reach.
Threat narrative
Attacker objective: The attacker seeks durable privileged control over Windows or commerce environments so they can persist, steal credentials, and expand access into adjacent systems.
- Entry occurs through either an exploited Windows privilege-escalation flaw or an unauthenticated Adobe Commerce RCE that gives the attacker initial execution inside the target environment.
- Escalation follows as the attacker moves from local or application-level execution to SYSTEM privileges or to the secrets and workflows protected by the commerce platform.
- Impact is achieved through persistent control, credential theft, and reuse of trusted access paths that can extend the breach beyond the original vulnerable component.
Breaches seen in the wild
- ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
- MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Exploitability beats volume in vulnerability governance: A month with 964 CVEs can still have only a handful of issues that define operational risk. The real control failure is assuming all critical and important flaws deserve equal urgency when exploited zero-days and privilege escalation are present. Practitioners should rank by reachable privilege gain, not by advisory volume.
StyleSmuggler is really a secrets governance problem disguised as application compromise: The Adobe Commerce issue matters because unauthenticated code execution can expose admin tokens, API keys, and deploy credentials in one chain. Once that happens, the breach is no longer contained to the web layer. Teams should treat application RCE as a trust-boundary breach across IAM, PAM, and NHI controls.
Standing privilege remains the accelerator for post-exploit movement: When attackers can pivot from low privilege to SYSTEM or from application context to stored secrets, the organisation has already lost the ability to contain the event at the original exploit point. That is why blast-radius reduction, credential scoping, and key rotation discipline matter more than patch completion metrics alone. Practitioners should measure how much authority remains reachable after initial compromise.
Security teams need a named concept for this pattern: privileged exposure compression: this is the shrinking window between exploit and full credential-based compromise when attackers can move from initial access to durable trust abuse. The shorter that window becomes, the more likely routine patching will fail to contain the event. Teams should build response playbooks around compressing that exposure window.
For identity programmes, exploited software flaws are now identity events: Once an attacker can extract tokens, secrets, or session material, the incident becomes an IAM and NHI governance issue as much as a vulnerability issue. The operational conclusion is that privileged access scope, secret hygiene, and offboarding discipline must be part of vulnerability triage, not separate from it.
From our research:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- From our research: 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
- For a deeper operational view, see the 52 NHI breaches Report for breach patterns that show how secrets exposure turns into persistent access.
What this signals
Privileged exposure compression is the pattern security teams should watch for when active exploitation collapses the time between initial access and durable credential abuse. In practice, the issue is no longer whether a vulnerability exists but how quickly it can become a trust failure across IAM, PAM, and NHI controls.
For identity programmes, this means patch management and secret governance cannot remain separate workstreams. When internet-facing applications can expose admin tokens or deployment keys, the remediation clock includes credential rotation, offboarding checks, and service-account visibility, not just binary fixes.
For practitioners
- Prioritise exploited privilege-escalation flaws first Rank patches by whether the flaw is already exploited, reaches SYSTEM or equivalent privilege, and sits on an externally reachable path. Use that triage to override backlog order when the difference is between theoretical exposure and active abuse.
- Treat unauthenticated RCE as a credential-exposure event When code execution lands in a platform that stores admin passwords, OAuth client secrets, API keys, or deploy credentials, assume the secret boundary is compromised until each store is verified and rotated.
- Rotate every credential reachable from the compromised trust boundary Follow the compromise path outward from the application to admin accounts, REST and GraphQL tokens, payment gateway credentials, database credentials, SSH and deploy keys, and extension API keys. Rotation should match reachable trust, not just the original CVE.
- Check for persistence before declaring remediation complete Look for implants, scheduled tasks, disguised processes, and restart mechanisms that can survive patching. If the platform stayed reachable during the exploitation window, treat the event as an incident and validate that no surviving access paths remain.
Key takeaways
- This month’s patch cycle shows that exploited zero-days and privilege escalation matter more than total CVE volume.
- Unauthenticated RCE becomes an identity problem as soon as the compromised platform can reach tokens, keys, or privileged workflows.
- Containment depends on shrinking privileged exposure, validating persistence, and rotating every credential reachable from the affected trust boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0004; TA0006; TA0003 — Privilege Escalation; Credential Access; Persistence | The article centres on exploited escalation, secret theft, and durable post-exploit control. |
| Recommendation — Map exploited flaws to TA0004, TA0006, and TA0003, then hunt for privilege gain, secret access, and persistence artefacts. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorisations | The article links patching to access scope and secret reuse across trusted workflows. |
| Recommendation — Review PR.AC-4 exposure for affected platforms and reduce reachable permissions before attackers can reuse them. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | SYSTEM escalation and credential reuse show why least privilege limits breach impact. |
| Recommendation — Apply AC-6 to remove unnecessary privilege from application, admin, and service accounts. | ||
| CIS Controls v8 | CIS-5 — Account Management | The incident response requires account and secret rotation across many trusted credentials. |
| Recommendation — Use CIS-5 to inventory, disable, and rotate accounts and secrets exposed by the compromise. | ||
| ISO/IEC 27001:2022 | A.8.2 — Privileged Access Rights | Privilege escalation and exposed secrets both fall under privileged access governance. |
| Recommendation — Tighten A.8.2 controls over privileged access rights and verify that emergency access remains bounded. | ||
Key terms
- Privilege Escalation: An attack technique where a compromised identity — often an NHI with initially limited permissions — exploits vulnerabilities or misconfigurations to gain elevated access rights, typically leading to broader compromise.
- Unauthenticated Remote Code Execution: A flaw that lets an attacker run code on a target system without first proving who they are. In enterprise applications, this is especially dangerous because the code executes inside a trusted workload context, which can expose data, internal services, and downstream privileges.
- Post Compromise Persistence: Post compromise persistence is the ability of an attacker to remain active after the initial vulnerability has been patched or the original access path is closed. It often relies on stolen credentials, tokens, accounts, or integrations that still appear legitimate to normal security controls.
- Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.
What's in the full analysis
Expel's full analysis covers the operational detail this post intentionally leaves for the source:
- Microsoft CVE-by-CVE prioritisation context that helps teams compare this month against previous Patch Tuesday releases
- Adobe Commerce exploitation timing, hotfix sequencing, and the specific compromise window between 9/4 and 9/7
- Credential rotation scope for admin passwords, REST, SOAP, GraphQL, OAuth, payment, database, SSH, and extension keys
- Post-compromise indicators such as persistence artefacts, implant behaviour, and restart mechanisms
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps practitioners connect vulnerability response to the credential and privilege decisions that determine blast radius.
Published by the NHIMG editorial team on September 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org