CVE-2026-58639

This vulnerability lets someone who already has an account in SharePoint use it like a “proxy” to reach places inside your private network that they normally shouldn’t be able to access. Even though it doesn’t fully take over SharePoint, it can let them impersonate other services or users by making the server fetch information from internal locations. Think of it like using the front desk phone to call departments you shouldn’t reach—while the call appears to come from inside the building.

This matters if your business runs Microsoft SharePoint Enterprise Server 2016, Microsoft SharePoint Server 2019, Microsoft SharePoint Server Subscription Edition (sharepoint server). The key risk is that an attacker would need low-level authenticated access first (someone with basic credentials/permissions). It becomes relevant specifically when an attacker can log into SharePoint with those low privileges and then trigger the spoofing behavior through crafted requests.

This is RED because it targets Microsoft SharePoint Server and a low-privileged authenticated attacker can use it to cause spoofing by making the server fetch from hidden internal locations. Even though we don’t have clear dated public exploitation reporting or a KEV entry, the presence of a known patch and active threat interest (including actor-related reporting) means you should treat it as urgent to close the gap quickly.

1. Confirm exposure (versions/builds)

• Identify every SharePoint farm/instance running:
  • Microsoft SharePoint Enterprise Server 2016
  • Microsoft SharePoint Server 2019
  • Microsoft SharePoint Server Subscription Edition (sharepoint server)
• Record the current build/version from the SharePoint “About” page or server build information.

2. Decide if you need the patch

• Apply the Microsoft update if your build is older than the fixed versions:
  • Enterprise Server 2016 → fixed in 16.0.5565.1001
  • Server 2019 → fixed in 16.0.10417.20198
  • Subscription Edition / sharepoint server → fixed in 16.0.19725.20522

3. Patch/upgrade plan

• Follow Microsoft’s update guidance for CVE-2026-58639 from the MSRC update guide.
• Coordinate downtime/restart windows per your change process (SharePoint patching often requires careful sequencing in multi-server farms).

4. Temporary risk reduction if patching is delayed

• Limit and audit low-privileged SharePoint accounts: remove unused accounts, tighten group membership, and review any accounts/service principals that can access SharePoint.
• Reduce overly-broad permissions for users and integrations so that “low privilege” access is harder to obtain.

5. Validate and monitor

• After patching, verify the build number matches the fixed version.
• Review logs for signs of unusual internal requests/fetch behavior triggered from SharePoint (spikes in internal connectivity attempts, repeated failures, odd request patterns). If you see suspicious activity, investigate the accounts used at the time of events.

CISA KEV

• No KEV listing was found for this CVE in the provided findings, so your main driver is patch availability and risk exposure management.

Severity is given as medium by CVSS (6.5) but the business risk is driven by an authenticated spoofing mechanism inside private networks.

Weakness type: CWE-918 (Server-Side Request Forgery / spoofing via server-side fetching).

Mechanism/trigger: An authenticated attacker with low privileges can craft requests that make SharePoint fetch data from hidden internal locations. This enables spoofing/impersonation within the private network boundaries rather than direct server takeover.

Attack vector: Network-based, with authentication required (low-privileged access). No user interaction is needed.

Exploitation status: KEV entry was not found, there is no clear dated press claim in the provided findings, and no public exploit code is on record. However, threat-actor related reporting indicates active interest (Lazarus group) and a patch is available.

EPSS: A predicted likelihood value was provided (without publicizing it in owner-facing blocks). Traffic trend is flat in the findings.

What KEV means here: Since it is not listed in the provided KEV findings, there is no confirmation through that channel that large-scale exploitation has been validated; this does not reduce your remediation urgency because patching is straightforward and the attack requires only low-privileged authenticated access.