Microsoft July 2026: exploited SharePoint and AD FS flaws

Microsoft’s July security release needs more than a routine maintenance window. CVE-2026-56164 in SharePoint Server and CVE-2026-56155 in Active Directory Federation Services are marked as exploited, and CISA added both to its Known Exploited Vulnerabilities catalogue on 14 July.

For security teams, the important question is not merely whether a patch exists. It is: was the vulnerable service reachable during the exposure window, and is there enough evidence to rule out compromise? A green patch-management status answers neither question.

Two vulnerabilities, two control planes

Vulnerability	Layer	Principal operational risk
CVE-2026-56164	SharePoint Server	unauthorised access to the server and application resources
CVE-2026-56155	AD FS	elevation of privilege in the identity federation layer

Both products commonly sit close to high-value assets. SharePoint holds documents, integrations and process data. AD FS participates in token issuance and trust between security domains. Even where a server is not directly Internet-facing, access through a VPN, reverse proxy, partner network or compromised workstation can materially change its exposure.

Establish the real environment first

Do not begin with every server name present in the CMDB. Begin with systems that are actually responding and processing traffic.

1. Discover every SharePoint Server farm, including standby nodes, test environments and recovery systems.
2. Identify AD FS instances and Web Application Proxy servers.
3. Record the product version and effective update level from each host.
4. Map access paths through the Internet, WAF, proxies, VPN, partner networks and administrative segments.
5. Name the business owner and the person responsible for each system’s logs.

This sequence exposes a familiar problem: a nominally internal service may be reachable through a published application, trusted integration or over-broad network segment. A product inventory without a traffic map creates false completeness.

Patching does not replace exposure-window analysis

Apply Microsoft’s updates as directed, but run two workstreams in parallel. One closes the vulnerability; the other determines whether it was abused before closure.

For SharePoint, preserve and review IIS, ULS, Windows event, WAF/reverse-proxy and application-directory change logs. Look for unusual POST requests, new or modified files, child-process execution, unexpected accounts and configuration changes. Do not restrict hunting to one signature: public indicators age quickly.

For AD FS, inspect administrative events, token issuance, configuration and certificate changes, privileged sign-ins and activity on proxy servers. Give special attention to events outside normal maintenance windows and actions by identities that do not ordinarily administer federation.

A mitigation buys time; it does not close risk

Microsoft and CISA describe additional SharePoint risk-reduction measures, including appropriate AMSI scanning configuration. This may disrupt some attack paths, but it is not equivalent to installing the security update. A control can be disabled, incomplete or bypassed by a variant it does not recognise.

If immediate patching is impossible:

• restrict network access to known trusted sources;
• remove unnecessary publication and retire obsolete nodes;
• extend retention and alerting for application and operating-system logs;
• monitor file creation and child processes launched by service identities;
• assign a named owner and firm deadline to the exception.

An exception without an expiry and closure condition is not a mitigation. It is an indefinite acceptance of poorly understood risk.

Proving that remediation works

Validate every node after deployment, not only the farm’s primary server:

1. Read the effective binary version and update level.
2. Confirm the node has rejoined the pool and is serving traffic.
3. Run a controlled negative test of the remediated path.
4. Test authentication, search, integrations and critical business workflows.
5. Review post-update telemetry for failed attack attempts or regressions.
6. Check recovery images and disaster-recovery systems so a vulnerable copy cannot return during the next incident.

The evidence pack should record the host, before-and-after versions, timestamp, test result, log coverage, anomalies and accepted residual risk. This is material for the risk owner and auditors, not a screenshot that says “completed”.

Priority for the CISO and leadership

Observed exploitation changes the order of work. Start with public-facing and identity systems, proceed to broadly reachable internal services, and then address isolated environments. At the same time, do not confuse absence of an alert with absence of an incident. If the required events were never logged or retention has expired, the accurate conclusion is “insufficient evidence”.

Where SharePoint or AD FS is part of a wider Microsoft estate, combine patching with an IT security audit and manual validation of trust boundaries. The most consequential attack paths usually cross application, identity, network configuration and excessive privilege.

Primary and government sources: Microsoft Security Update Guide — July 2026, MSRC — CVE-2026-56164, MSRC — CVE-2026-56155, CISA — SharePoint hardening after new exploitations.