Is CVE-2024-49035 (Microsoft Partner Center Improper Access Control) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2024-49035 to its Known Exploited Vulnerabilities catalogue on 25 February 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft Partner Center contains an improper access control vulnerability that allows an attacker to escalate privileges. Any organisation running the affected product should treat remediation as urgent.

What “being exploited in the wild” means for this CVE

The practical meaning here is straightforward: this is no longer a theoretical issue to track for a future maintenance window. A KEV listing means defenders should assume real-world abuse is already happening somewhere and validate exposure, patch status, compensating controls, and any signs that Partner Center access has been misused.

For a cloud administration portal, the main question is not only whether the vulnerability exists in the product, but whether any tenant, role, workflow, or delegated access path could let an attacker move from ordinary portal use into higher privilege. That is why teams should treat this as a privileged access problem as much as a vulnerability item.

In practice, prioritisation should follow the exploitation signal, not just the product name. Guidance such as the CISA Known Exploited Vulnerabilities Catalog and the NIST National Vulnerability Database helps teams confirm the record, track its remediation status, and align it with internal asset inventory and patch ownership.

How to confirm exposure and reduce blast radius

Start by confirming whether your organisation actually uses Microsoft Partner Center and which administrators, delegated partners, or automation accounts can reach it. Exposure checks should include tenant inventory, federated access paths, and any service integrations that rely on the portal for partner management or customer administration.

Because the issue is an improper access control weakness, the exposure review should focus on who can reach privileged functions, not only whether the endpoint is internet-facing. If access has been broadly delegated, assume the blast radius is larger until the permission model is reviewed.

A useful reference point is the CVE Program for the canonical record, then your vendor advisory for the exact remediation path. For operational prioritisation, the FIRST EPSS can be used alongside KEV to support urgency decisions, but it should not override confirmed exploitation evidence.

What to do if patching must wait

If remediation is delayed, reduce exposure by limiting administrative entry points, tightening partner and delegated access, and reviewing every account that can perform privileged Partner Center actions. Compensating controls should focus on access restriction, session monitoring, and rapid revocation of stale or unnecessary permissions.

In a portal-access scenario, waiting on a fix is only defensible if you can prove the vulnerable path is materially constrained. That means reducing who can use the affected functions, not merely documenting the exception. If the product underpins partner operations or customer administration, treat any delay as time-bounded and exception-managed.

Teams can also use this period to review neighbouring identity controls with the Authorisation Models Guide and the Broken Access Control Prevention Guide, because the same design flaws that create one portal privilege issue often show up in other admin paths too.

Risk and Threat Considerations

Improper access control in an administration portal creates a direct privilege-escalation path, which means the attacker objective is not just data viewing but control over privileged actions, tenant administration, or account manipulation. Once that path exists, the vulnerability can become a stepping stone to persistence, fraud, or lateral movement through trusted business workflows.

Failure mechanism: The access decision is weaker than the action being performed, so an attacker can reach functions that should have been restricted to a smaller administrative set or to a different trust boundary.

Impact: A successful abuse case can expose partner data, alter account state, or give the attacker a durable privileged foothold inside a high-trust administrative surface.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack surface, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-5 — Account Management	Partner Center exploitation depends on excessive or stale access paths.
Recommendation — Review and remove unnecessary accounts and delegated access to the affected portal.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	The issue is an improper access control weakness enabling privilege escalation.
	AU-6 — Audit Record Review, Analysis, and Reporting	Confirmed exploitation warrants review of portal activity for abuse indicators.
Recommendation — Restrict Partner Center actions to the minimum privileges required. Review privileged portal logs for suspicious access and escalation attempts.
ISO/IEC 27001:2022	A.5.15 — Access control	The vulnerability is fundamentally about controlling who can perform privileged actions.
Recommendation — Enforce and periodically review access restrictions for the portal.
MITRE ATT&CK	T1068 — Exploitation for Privilege Escalation	The CVE allows an attacker to escalate privileges through weak access control.
Recommendation — Map observed abuse to privilege-escalation detection and response coverage.

Practitioner Guidance

What to prioritise: Treat the portal itself as the asset to triage, then map every privileged workflow that can be reached through it. If Partner Center is used for customer, partner, or delegated administration, the highest-value check is whether any broad role can invoke actions that should be separately approved or constrained.

What to verify: Verify current access paths, recent privilege changes, and whether any automation or delegated admin account can exercise the affected functions. Keep evidence of who had access, when access was reviewed, and what was removed or restricted while remediation was pending.

Practitioner takeaway: For a KEV-listed access control flaw, the right decision is to assume exploitation pressure is real, then prove that no account, delegation, or workflow can still reach the privileged action path unnecessarily.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org