What breaks and who should care
If your organisation runs Microsoft SharePoint Server and you see a scanner flagging CVE-2025-49706, you have a problem that could let an authorised attacker spoof network traffic, peek at sensitive data and even alter information that has been disclosed. The flaw is rated medium severity, but the fact that it is confirmed in the wild and has been used in ransomware campaigns means you cannot ignore it. Anyone responsible for the confidentiality or integrity of SharePoint content – security engineers, system administrators, compliance officers – should treat this as a priority.
Related remediation guides
Other vulnerabilities in the same family or affecting the same products:
- CVE-2025-53770 SharePoint Server – Immediate Action Guide
- CVE-2026-45659 – SharePoint Server deserialization flaw – what it means and how to fix it
- CVE-2025-49704 – Immediate actions for Microsoft SharePoint code‑injection risk
For the wider picture, our Known Exploited Vulnerabilities tracker lists every flaw CISA has confirmed under active attack.
How the vulnerability works
The NVD description classifies CVE-2025-49706 as an “improper authentication” issue. In plain English, the server fails to correctly verify the identity of a client that presents certain credentials. An attacker who already has a valid account – for example a low‑privilege user or a service account – can craft requests that appear to come from a different, higher‑privilege identity. This is what is meant by “spoofing over a network”.
Because the authentication check is bypassed, the attacker can request objects that should be hidden, read documents that contain confidential information, and, in some cases, submit changes that are recorded as if they were made by a legitimate user. The exact technical details of the bypass – the code path, the token manipulation, the cryptographic checks that are skipped – have not been published. Microsoft’s advisory simply states that the flaw resides in the authentication logic of SharePoint’s server component.
What makes the situation worse is that the vulnerability can be chained with another flaw that also affects SharePoint. When combined, the attack surface expands, allowing an adversary to move laterally within the SharePoint farm or to gain persistence. While the chain is not required for a successful exploit, it is something you should be aware of when assessing risk.
How to determine if you’re exposed
The first step is to verify which SharePoint build you are running. Microsoft provides a PowerShell cmdlet that reports the exact build number of the farm. Run the following on any SharePoint server in the farm:
Get-SPFarm | Select-Object -ExpandProperty BuildVersionThe output will be a string such as 16.0.xxxxx.xxxxx. Compare that string against the table below, which lists the latest patched releases for each supported branch. If your build appears in the “affected” column, you are vulnerable until you apply the appropriate update.
For environments that are not managed via PowerShell, you can also locate the version in the SharePoint Central Administration site under System Settings → Manage servers in this farm. The version column there shows the same build identifier.
Mitigation and remediation steps
Microsoft has already released a fix for CVE-2025-49706. The remediation path is straightforward: install the cumulative update that contains the patched code for your SharePoint branch. In practice this means downloading the latest update package from the official Microsoft Update Catalog and applying it to every server in the farm. The update process is the same as any other SharePoint cumulative update – run the installer, let it finish, then run the SharePoint Products Configuration Wizard to complete the upgrade.
Because the vulnerability is already being exploited, CISA recommends an additional defence‑in‑depth step for any public‑facing SharePoint deployment that is still running an unsupported release. Disconnect those instances from the internet until they are upgraded or decommissioned. If you cannot take the site offline, restrict inbound traffic to known corporate IP ranges using a firewall or web‑application firewall (WAF). Enforce multi‑factor authentication for all accounts that have access to SharePoint, especially those with elevated privileges.
Here is a concise checklist you can copy‑paste into a ticket:
- Run
Get-SPFarm | Select-Object -ExpandProperty BuildVersionon each server. - Cross‑reference the output with the table below.
- If the build is listed as vulnerable, download the latest cumulative update for your branch from Microsoft.
- Install the update on every node in the farm.
- Run the SharePoint Products Configuration Wizard on each server after the install.
- Verify the new build number with the same PowerShell command.
- For any public‑facing instance that is still on an unsupported release, block external traffic at the perimeter firewall.
- Enable MFA for all SharePoint users.
- Review audit logs for suspicious authentication events in the days following the patch.
If a patch is not immediately available
In the unlikely event that you cannot apply the cumulative update right away – perhaps because you are locked into a change‑management window – you should apply the mitigations that CISA lists for this class of vulnerability:
- Network segmentation: Place SharePoint servers on a dedicated subnet that is not directly reachable from the internet.
- Restrict authentication methods: Disable basic authentication and any legacy protocols that do not support modern token validation.
- Hardening of web‑front ends: Use a reverse proxy that validates client certificates before forwarding requests to SharePoint.
- Logging and alerting: Enable detailed authentication logging and set up alerts for any failed login attempts that originate from unexpected source IPs.
- Temporary account lockdown: Review privileged accounts and, where possible, temporarily reduce their permissions until the patch can be applied.
These steps do not replace the need for the official fix, but they raise the cost for an attacker and can buy you time while you schedule the update.
What to do after you patch
Once the update is installed, run the PowerShell command again to confirm the build number now appears in the “fixed” column of the table below. Then perform a quick sanity check:
- Log in with a low‑privilege account and attempt to access a document that should be off‑limits. The request should be denied.
- Review the SharePoint health analyzer for any lingering warnings.
- Run a vulnerability scan again to verify that CVE-2025-49706 no longer appears.
If the scanner still flags the issue, double‑check that every server in the farm – including any remote web front ends – received the update. SharePoint farms can have multiple front‑end servers, and a single unpatched node will keep the vulnerability alive.
References
The official Microsoft security advisory provides the download links and detailed installation notes. CISA’s guidance on handling known‑exploited vulnerabilities gives the broader mitigation strategy for public‑facing services. Both sources are linked from the table below.
Version table
The table below is generated automatically from the National Vulnerability Database and shows which SharePoint Server builds are affected and which contain the fix. Use it as the single source of truth for version comparison.
Affected versions
Straight from the NVD record for CVE-2025-49706. If your build is inside one of these ranges, treat it as vulnerable.
| Product | Affected range | Fixed in |
|---|---|---|
sharepoint_server |
* up to 16.0.18526.20424 | 16.0.18526.20424 |
