CVE-2026-55040 lets an unauthenticated attacker skip the SharePoint login process entirely and act as any user on your site — including a site administrator. In plain terms, someone on the internet can access your SharePoint data without ever supplying a valid password. (Source: Rapid7)

The one condition is that the attacker needs to know which user they want to impersonate ahead of time. That's a low bar. They can enumerate valid accounts using a user's Active Directory Security ID (SID) or their User Principal Name (UPN) — the email-style logon name such as This email address is being protected from spambots. You need JavaScript enabled to view it.. Rapid7's proof-of-concept walks through exactly this: discover accounts, then bypass authentication to assume that identity and surface the administrator account.

SharePoint is where a lot of firms keep their most sensitive material — corporate intranets, internal file shares, contracts, and workflow data tied into the Microsoft 365 ecosystem. Because SharePoint bridges internal users, Active Directory, and cloud infrastructure, an attacker impersonating a site user can read and act on documents as though they belonged there, which makes data exfiltration a realistic outcome and complicates any after-the-fact investigation.

Microsoft scored the bug CVSSv3.1 5.3 (Medium), classified as CWE-1390: Weak Authentication. Do not let the medium rating set your priority.

Patching CVE-2026-55040 breaks the exploit chain, even though the RCE component itself isn't scheduled for a fix until the August 2026 patch cycle.

That's the operational takeaway: the authentication bypass is the link that makes the RCE reachable without credentials. The fix for CVE-2026-55040 is available now, and applying it removes the entry point attackers would need to reach the still-unpatched RCE stage.

How the JWT Authentication Bypass Works

The flaw lives in SharePoint's JSON Web Token (JWT) validation pipeline — the code path that inspects and trusts the signed tokens SharePoint uses to establish who a request belongs to. According to Rapid7 Labs, CVE-2026-55040 stems from several distinct issues in how that pipeline validates tokens, rather than a single misconfiguration. The result is that the server accepts a token as authentic when it should reject it.

JWTs are the currency of identity in modern web applications. A properly functioning server checks the token's signature to confirm it was issued by a trusted authority, then reads the claims inside — including which user the token represents. When that verification chain breaks down, an attacker can present a token the server never legitimately issued and still be treated as the named user.

That is precisely what happens here. A remote attacker who knows the target account — identified through an Active Directory Security ID or User Principal Name — can produce a token the validation pipeline accepts, then act as that user against the SharePoint site. No password, no valid session, no interactive login is required.

Rapid7 assigns the standalone bug a CVSSv3.1 score of 5.3 (Medium), mapped to CWE-1390: Weak Authentication. The medium rating reflects the vulnerability in isolation: on its own, an attacker gains the permissions of the identity they assume, no more. For a low-privilege user account, that is a bounded impact. For the site administrator account, it is considerably broader.

The impact of successfully chaining a medium severity authentication bypass to an RCE component is significant.

The severity number understates the operational risk because of what the bypass enables downstream. Once authenticated as a site user, an attacker reaches the authenticated attack surface — the functionality SharePoint exposes only to logged-in users. Rapid7 chained CVE-2026-55040 to a separate remote code execution vulnerability reachable only from that authenticated surface, producing full unauthenticated RCE against the server. The RCE component is scheduled for a Microsoft patch in the August 2026 cycle.

The attack sequence, based on Rapid7's description, runs in a clear order:

• Reconnaissance: The attacker enumerates valid accounts, using SID enumeration to discover users and surface privileged accounts such as the site administrator.
• Authentication bypass: Using the target's identifier, the attacker forges or manipulates a JWT the validation pipeline wrongly accepts, assuming that user's identity.
• Authenticated access: The attacker performs operations as the impersonated user and reaches functionality restricted to authenticated sessions.
• Code execution (when chained): From the authenticated surface, the chained RCE bug executes attacker-controlled code on the server.

The prerequisite is network reachability to the SharePoint site and advance knowledge of a target account — both practical for internet-facing deployments where SID and UPN enumeration is achievable. For your organization, that means an on-premises SharePoint server exposed to untrusted networks is reachable by anyone who can enumerate an account name, and SharePoint's role as the store for corporate documents and intranet content makes the assumed-administrator path a direct route to sensitive data.

Rapid7 states it will publish full technical details within 30 days of this July 14, 2026 disclosure, and notes that patching CVE-2026-55040 breaks the exploit chain even before the RCE component is addressed in August. Applying the current update removes the authentication bypass that the entire chain depends on.

Operational and Compliance Risk in Enterprise Environments

SharePoint typically holds the material an enterprise keeps closest: contract drafts, financial records, HR files, internal wikis, workflow approvals, and the metadata that maps who touches what. When an attacker acts as a legitimate site user or administrator through CVE-2026-55040, every document and list that identity can reach becomes readable. If the impersonated account is a site administrator, that reach can extend across the entire site collection.

The data at risk isn't limited to files. SharePoint stores user membership lists, permission structures, version history, and audit trails. An attacker operating as a valid user can pull all of it without tripping a failed-login alarm, because from the server's perspective the requests belong to a real account.

That's the part that makes this expensive to investigate. Access under a stolen identity looks like normal activity in your logs. Your incident response team can't simply filter on "unauthorized" sessions — every action carries a legitimate-looking token, so scoping a breach means reconstructing what a real user account actually did versus what the impersonated session did.

An authentication bypass that assumes a valid identity means the attacker's activity blends into ordinary user behavior — the hardest kind of intrusion to scope after the fact.

This vulnerability also amplifies insider-threat exposure. The same technique that lets an external attacker impersonate an administrator works for anyone who can enumerate a target account. You inherit the burden of proving, after an incident, that a given action came from the named user and not from someone wearing that user's identity.

The compliance consequences follow directly from the data involved:

• GDPR: If your SharePoint sites contain EU personal data, unauthorized access to that data can trigger the 72-hour breach notification requirement to your supervisory authority. You have to notify even when you cannot fully confirm what was accessed — and impersonated sessions make that confirmation difficult.
• HIPAA: Healthcare organizations that store protected health information in SharePoint face breach-reporting obligations to affected individuals and regulators once unauthorized access is established.
• SOX: If SharePoint hosts financial reporting documents or supports controls that feed your financial statements, an authentication bypass touches the integrity of those controls and becomes an audit finding you must explain.

The prerequisite that an attacker knows the target user in advance does not lower your exposure much. User Principal Names follow the email format your organization already publishes, and Active Directory Security IDs can be enumerated. For most enterprises, the identities an attacker would want to impersonate are neither secret nor hard to guess.

Consider the chaining risk when you weigh severity. Microsoft assigned CVE-2026-55040 a CVSSv3.1 score of 5.3 (Medium), which can read as low priority on a patch backlog. Rapid7 Labs chained it with a separate remote code execution flaw — expected to be patched in the August 2026 cycle — to achieve unauthenticated RCE. A medium-severity bypass that unlocks code execution on a server storing your business records carries impact well beyond its base score.

The operational cost lands whether or not an attacker reaches the RCE stage. Confirming the scope of identity-based access, notifying regulators within statutory windows, and demonstrating to auditors that your controls held all consume staff time and legal review — costs you absorb even in an incident that never reaches the headlines.

Immediate Detection and Patching Actions

The single most important action is to apply Microsoft's July 14, 2026 security update for SharePoint, which patches CVE-2026-55040. This break the authentication bypass and, by extension, the full unauthenticated RCE chain Rapid7 Labs demonstrated — even before the RCE component itself is patched in August 2026. If you run on-premises SharePoint Server, install the update through your normal patch process and confirm the fixed build listed in Microsoft's advisory for your SharePoint version. Do not wait for the August cycle; patching this one component alone closes the door on the chain.

Once the patch is staged, work through the remaining priorities in the order below.

Identify

Inventory every SharePoint Server instance reachable from the internet or from untrusted network segments. Internet-facing servers carry the most immediate exposure because the attack requires no valid credentials — only prior knowledge of a target user's SID or UPN. Confirm which instances have received the July content update and flag any that lag behind.

Exposure Command, InsightVM, and Nexpose customers can confirm patch status using the authenticated vulnerability checks for CVE-2026-55040 released in the July 14 content update.

Detect

Because the flaw sits in the JWT token validation pipeline, your detection focus is authentication events that don't fit normal token issuance. Pull the following log sources and hunt for anomalies:

• SharePoint ULS logs — the Unified Logging Service records token validation and request handling. Look for authentication events tied to accounts that show no corresponding interactive or federated sign-in.
• IIS logs on the SharePoint web front ends — review requests carrying bearer tokens that resolve to privileged accounts, especially requests originating from external IP ranges.
• Azure AD / Microsoft Entra ID sign-in logs (hybrid deployments) — cross-reference SharePoint activity attributed to a user against that user's Entra sign-in record. Activity in SharePoint with no matching Entra authentication is a strong signal of a forged token.

The specific indicator to chase is a mismatch: a request accepted as an authenticated user where no legitimate token issuance exists. In environments Capstone manages, Adlumin correlates SharePoint authentication activity against identity provider sign-in records across managed environments, surfacing sessions that assert an identity the directory never actually authenticated.

Respond

If your log review turns up activity that predates your patch and can't be tied to a legitimate sign-in, treat those accounts as potentially impersonated. Review what the impersonated identity could reach and check for access to document libraries and lists that account does not normally touch.

• Reset credentials and revoke active sessions for any account showing suspicious token-backed activity, prioritizing site administrator accounts.
• Preserve ULS, IIS, and Entra sign-in logs before they roll over — the article notes Rapid7 is publishing full technical details within 30 days, and those details will sharpen retrospective hunts.
• Check for follow-on actions an attacker could take as an authenticated user, since the bypass was designed to chain into the authenticated attack surface.

Recover and harden

After confirming the environment is patched and clean, tighten how SharePoint trusts tokens going forward. Enforce token signature validation, and where your configuration allows, shorten JWT token lifetime so that any single accepted token has a narrower window of use.

Limit direct internet exposure of SharePoint front ends where the business case allows, placing them behind authenticated reverse proxies or VPN access. This reduces the pool of unauthenticated attackers who can reach the token pipeline at all.

Keep the August 2026 patch cycle on your calendar to close the RCE component as well, but do not let that timeline delay the July update.

Assessing Your SharePoint Environment

Start by building a complete inventory of every SharePoint instance you run. You cannot patch or protect what you haven't accounted for, and organizations frequently discover forgotten farms, test environments, or departmental sites that never made it onto the asset register. Note that CVE-2026-55040 affects on-premises SharePoint Server; internet-facing on-prem deployments carry the highest exposure because a remote unauthenticated attacker can reach them directly.

Identify

Catalog each server and record its exact SharePoint version and current patch build. Confirm which farms are reachable from the internet versus those restricted to internal networks — that single distinction drives your prioritization order.

• List all SharePoint Server farms, including staging, disaster-recovery, and one-off project instances.
• Map internet exposure for each farm — is the site published through a reverse proxy, gateway, or directly?
• Record the SharePoint version and installed build so you can match it against the fixed build in Microsoft's advisory for your version.
• Flag sites holding sensitive data — contract repositories, HR and finance libraries, and any site backing a business workflow.

Then look at your user populations. Because exploitation depends on impersonating a known account, sites where administrator and privileged accounts are easily enumerated deserve attention first. Identify which sites have the largest number of elevated-permission users, since those identities are the most valuable to impersonate.

Protect

Apply the July 14, 2026 update as your primary control. If your change-management process forces a delay, put compensating controls in place on the farms you can reach from outside the network.

• Restrict access by IP at the gateway or reverse proxy so only known ranges — VPN egress, office networks, trusted partners — can reach the SharePoint site while you stage the patch.
• Enforce MFA at the identity provider for accounts that touch SharePoint. MFA does not stop the token-validation bypass itself, but it hardens the surrounding account-access paths an attacker would otherwise use.
• Shorten token lifetime policies where your configuration allows, reducing the window in which any accepted token remains usable.
• Publish sites behind an authenticating proxy where feasible, so unauthenticated requests never reach the vulnerable validation pipeline directly.

Treat these as temporary measures. They narrow the reachable attack surface but do not fix the underlying flaw — only the update does that.

Adlumin ITDR monitors authentication behavior across managed environments, surfacing token and logon anomalies tied to privileged SharePoint accounts so impersonation attempts stand out against normal activity while you complete remediation.

Track remediation status

Give your IT team a single view of where each farm stands. A simple checklist keeps the effort honest and shows management exactly what remains:

• ☐ Farm inventoried, version and build recorded
• ☐ Internet exposure confirmed (yes/no)
• ☐ Sensitive-data classification assigned
• ☐ Compensating controls applied (IP restriction / proxy / MFA)
• ☐ July 2026 update staged
• ☐ July 2026 update installed and fixed build verified against Microsoft's advisory
• ☐ August 2026 RCE-component patch scheduled and tracked

Rapid7 customers using Exposure Command, InsightVM, and Nexpose can assess exposure to CVE-2026-55040 with authenticated vulnerability checks in the July 14 content release, which gives you a way to validate the inventory above against what scanners actually find. Keep the August cycle on your calendar; patching the authentication bypass breaks the demonstrated exploit chain, and the RCE component still needs its own update.

Key Takeaway and Next Steps

CVE-2026-55040 is a medium-severity authentication bypass in the way Microsoft SharePoint validates JWT tokens, and on its own it lets an unauthenticated attacker act as any SharePoint site user or administrator. Rapid7 Labs chained it with a separate remote code execution flaw to reach full unauthenticated RCE, which is why the CVSS score of 5.3 understates the real risk when the two flaws are combined.

The single most important action is to apply Microsoft's July 14, 2026 SharePoint update across every affected on-premises instance you run. That patch closes this component and breaks the full exploit chain before the RCE half is even addressed in the scheduled August 2026 cycle.

Your secondary step depends on your risk profile. If a full patch rollout across all farms will take you longer than a couple of days, prioritize internet-facing SharePoint Server instances first, since those are directly reachable by a remote unauthenticated attacker, and complete internal-only farms once external exposure is closed.

Two dates anchor your planning: Rapid7 intends to publish full technical details within 30 days of this disclosure, and Microsoft is scheduled to patch the RCE component in August 2026.

This case is a reminder that a medium-scored authentication bypass can carry outsized weight when it unlocks the authenticated attack surface behind it. Treat this update with the same priority you would give a higher-scored flaw, and confirm the fixed build listed in Microsoft's advisory for each SharePoint version you operate.