On January 14, 2025, Rapid7 Labs disclosed a critical exploit chain targeting Microsoft SharePoint Server. The chain combines CVE-2026-55040 (CVSS 9.1, JWT authentication bypass) and CVE-2026-63520 (remote code execution) to achieve unauthenticated RCE on SharePoint Server Subscription Edition, 2019, and 2016. Microsoft patched both vulnerabilities in January 2025. SharePoint Online is not affected.
What makes this incident notable isn't just the severity, it's that Rapid7 used AI to discover and weaponize the chain, then published a proof-of-concept. This timeline matters: AI-assisted discovery compressed months of manual research into days, and the public PoC means your patch window just got a lot shorter.
Timeline
- Pre-January 2025: Rapid7 Labs uses AI-assisted analysis to identify the authentication bypass and RCE chain.
- January 14, 2025: Rapid7 publicly discloses both CVEs with proof-of-concept code.
- January 2025: Microsoft releases patches for affected SharePoint versions.
- Post-disclosure: Public PoC availability accelerates attacker weaponization timeline from weeks to hours.
Which Controls Failed or Were Missing
This wasn't a zero-day caught in the wild. The vulnerabilities existed in the authentication and input validation layers of SharePoint Server. Here's what should have prevented exploitation:
Authentication boundary enforcement failed. CVE-2026-55040 bypasses JWT validation, letting an attacker impersonate authenticated users without valid credentials. Your authentication layer should treat JWT claims as untrusted input and validate every component, issuer, audience, signature, expiration, before granting access.
Input validation at the execution boundary was insufficient. CVE-2026-63520 allows RCE through improper handling of user-controlled data. This is a textbook failure of server-side input validation before processing commands.
Vulnerability scanning didn't catch it first. If your quarterly scans or pentests didn't identify these issues before Rapid7's AI did, you're relying on external researchers to tell you what's broken. That's not a control, that's luck.
Patch deployment velocity wasn't ready. Between disclosure and exploitation, you have hours, not weeks. If your patch testing and deployment process takes 30 days for critical vulnerabilities, you're operating outside acceptable risk parameters.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.3.1 mandates that security vulnerabilities are identified using industry-recognized sources and new threats are assigned a risk ranking. A CVSS 9.1 with public PoC is maximum risk. Your ranking process should flag this for emergency patching within 24-48 hours, not your normal cycle.
Requirement 6.4.3 requires critical security patches to be installed within one month of release. "Critical" means high-risk vulnerabilities that could lead to compromise of the CDE. An authentication bypass leading to RCE on a system that might touch cardholder data meets that bar. One month is your outer limit, not your target.
ISO/IEC 27001:2022 Control 8.8 (management of technical vulnerabilities) requires you to obtain timely information about technical vulnerabilities, evaluate exposure, and take appropriate measures. "Timely" for a public PoC means same-day awareness and risk assessment.
NIST 800-53 Rev 5 SI-2 (flaw remediation) requires you to install security-relevant software updates within organization-defined time periods. Your time period for critical vulnerabilities with active exploitation or public exploits should be measured in days, not weeks.
Lessons and Action Items for Your Team
Stop treating AI-discovered vulnerabilities as theoretical. Rapid7 used AI to compress the discovery timeline. Attackers will do the same. Your assumption that you have weeks between disclosure and weaponization is outdated. Update your patch SLAs to reflect this new reality: critical vulnerabilities with public PoCs get emergency deployment within 72 hours.
Audit your JWT implementation today. Pull your authentication logs and verify that every JWT validation checks signature, issuer, audience, and expiration. If you're using a library, confirm it's current and configured to reject malformed tokens. CVE-2026-55040 exploited weak JWT validation, that's a pattern, not a one-off.
Build a PoC response playbook. When a public proof-of-concept drops, you need a process:
- Identify affected systems (asset inventory).
- Assess exploitability in your environment (network segmentation, authentication requirements).
- Deploy compensating controls if patches aren't ready (WAF rules, network isolation).
- Fast-track patching through change control.
Test your emergency patch process quarterly. If you can't deploy a critical patch outside your normal cycle, you don't have an emergency process, you have a hope. Run a tabletop: "Public RCE PoC for SharePoint drops Friday at 5pm. How fast can you patch production?" If the answer is "next month's patch window," you're not ready.
Implement virtual patching for critical systems. AppTrana and similar WAF solutions can block this specific exploit chain while you test patches. That's not a long-term fix, but it buys you time to patch safely instead of rushing untested updates into production. Build relationships with WAF vendors who can push rules for disclosed vulnerabilities within hours.
Inventory your SharePoint exposure. If you don't know which SharePoint versions you're running and whether they're internet-facing, you can't assess risk. Build a configuration management database that tracks version, patch level, and network exposure for every SharePoint instance. Update it automatically, not manually.
Validate your vulnerability intelligence sources. Rapid7 disclosed this on January 14. When did your team know about it? If you're waiting for your quarterly scan vendor to tell you about critical CVEs, you're weeks behind. Subscribe to vendor security advisories, CISA alerts, and researcher disclosures directly.
The AI angle here isn't science fiction, it's operational reality. Researchers are using AI to find vulnerabilities faster, and they're publishing PoCs that attackers can weaponize immediately. Your patch cycle, testing process, and risk assessment timelines need to account for this compression. If your critical patch SLA is still 30 days, you're measuring in the wrong units.
