{
	"id": "5770e55c-66f1-4f39-8021-c812bf8eda45",
	"created_at": "2026-04-06T00:15:21.774329Z",
	"updated_at": "2026-04-10T13:11:27.544862Z",
	"deleted_at": null,
	"sha1_hash": "317c872cd047c2d82419d8257ec0f53274d69819",
	"title": "SharePoint 0-day uncovered (CVE-2025-53770)",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1325475,
	"plain_text": "SharePoint 0-day uncovered (CVE-2025-53770)\r\nBy Eye Security\r\nPublished: 2025-07-19 · Archived: 2026-04-05 16:48:25 UTC\r\nFrom SOC Alert Triage to SharePoint Mass Exploitation\r\nOn the evening of July 18, 2025, Eye Security was the first in identifying large-scale exploitation of a SharePoint\r\nremote code execution (RCE) vulnerability chain in the wild. Demonstrated just days before on X, this exploit is\r\nbeing used to compromise on-premise SharePoint Servers across the world. The chain we uncover in this blog\r\ncombines CVE-2025-49706 \u0026 CVE-2025-49704 to get unauthorised RCE on unpatched SharePoint Servers.\r\nAfter we learned about this chain being exploited in the wild, our team scanned over 23000 SharePoint servers\r\nworldwide. In total, we discovered more then 400 systems actively compromised during four confirmed waves of\r\nattack:\r\nhttps://research.eye.security/sharepoint-under-siege/\r\nPage 1 of 12\n\nconfirmed initial wave on 17th of July at 12:51 UTC from 96.9.125[.]147 (probably testing)\r\nconfirmed wave #1 on 18th of July at 18:06 UTC from 107.191.58[.]76 (widely successful)\r\nconfirmed wave #2 on 19th of July at 07:28 UTC from 104.238.159[.]149\r\nconfirmed multiple waves on and after 21th of July\r\nThis blog will share our detailed findings and recommendations to patch \u0026 perform a compromise assessment if\r\nyou think you are affected. While this story develops, we update this blog regularly as shown in our timeline using\r\nreferences. Consider following us on LinkedIn to help us spread the word.\r\nUpdate (July 29, 2025): Clarifications and Corrections\r\nSince the publication of this blog, we’ve received helpful feedback from the community. Here’s what we’ve\r\nupdated based on thoughts shared by researcher @irsdl on X on the 28th of July 2025.\r\nCorrect CVEs Referenced: The vulnerabilities exploited during the July 17–19 seem not to be CVE-2025-53770/53771, but rather the original ToolShell chain: CVE-2025-49706 (auth bypass) and CVE-2025-49704 (deserialization RCE).\r\nNo Zero-Day: The vulnerabilities we identified on July 18 seems to already been disclosed and patched on\r\nJuly 8, 2025, meaning this was an N-day exploitation, not a true zero-day. Our initial use of “0-day” has\r\nbeen removed in this blog to reflect this.\r\nPatch Confusion: Our original assumption was based on Microsoft’s out-of-band patch on July 19, which\r\nwe believed addressed the attack chain we observed. It was later confirmed that this patch was a fix for\r\nbypass variants, not new exploitation. Microsoft has since clarified this publicly.\r\nLimited Exploitation Scope: While we found 400+ compromised SharePoint servers, over 8,000 systems\r\nremain exposed online. This supports the updated consensus that attackers exploited known flaws on\r\nunpatched systems (July 9th patch was available), not a new variant.\r\nRemoved Unverified PoCs: We removed links to speculative GitHub PoCs for CVE-2025-53770 that\r\ncould not be validated and may have contributed to confusion.\r\nNo File Write Required: We updated our blog to make sure that readers understand that the ToolShell\r\nattack chain, does effectively not require writing a file to disk. RCE can be achieved in-memory via crafted\r\nPOST requests. File-based webshells (like spinstall0.aspx ) were dropped after initial exploitation for\r\npersistence and are just one variant that we observed, there might be countless more variants used since\r\nJuly 7, 2025, so assume breach.\r\nAppreciation for the Community: We thank @irsdl and others for their detailed analysis and respectful\r\ncorrections. We regret any confusion our initial post may have caused and remain committed to clear, fact-based communication.\r\nWe’ve made these updates to ensure accuracy and help defenders respond effectively.\r\nAll remediation guidance remains valid.\r\nA Word on Disclosure\r\nThis blog post follows dozens of responsible disclosures to affected organizations and their national GovCERT’s.\r\nIn every confirmed case, we reached out directly with detailed evidence (including the exact SharePoint URL\r\nhttps://research.eye.security/sharepoint-under-siege/\r\nPage 2 of 12\n\naffected). Our priority is clear: defend the ecosystem. Therefore, we will mask some details in this blog while\r\norganizations are recovering from their breaches. And we will never share victims.\r\nEvening of July 18, 2025\r\nEarly in the evening, our 24/7 detection team received an alert from one of our CrowdStrike Falcon EDR\r\ndeployment at a specific customer. The alert flagged a suspicious process chain on a legacy SharePoint on-prem\r\nserver, tied to a recently uploaded malicious .aspx file.\r\nAt first glance, it looked familiar. A classic web shell, obfuscated code in a custom path, designed to allow remote\r\ncommand execution via HTTP. We’ve seen many of these before. What made this one stand out, however, was\r\nhow it got there.\r\nOur first hypothesis was mundane but plausible: a brute-force or credential-stuffing attack on a federated ADFS\r\nidentity, followed by an authenticated upload or a remote code attempt using valid credentials. The affected\r\nSharePoint server was exposed to the internet and tied into Azure AD using a hybrid ADFS. That stack, when\r\nmisconfigured or outdated, can be a dangerous combination.\r\nIt all seemed to confirm the theory: credentials compromised → shell dropped → persistence achieved.\r\nLooking at the IIS logs more closely, we notice that the Referer is set to /_layouts/SignOut.aspx . That’s odd.\r\nHow can that be an authenticated request, just after the user has logged out?\r\n2025-07-18 18:xx:04 \u003cproxy masked\u003e POST /_layouts/15/ToolPane.aspx DisplayMode=Edit\u0026a=/ToolPane.aspx 443 - \u003cpro\r\n2025-07-18 18:xx:05 \u003cproxy masked\u003e GET /_layouts/15/spinstall0.aspx - 443 - \u003cproxy masked\u003e Mozilla/5.0+(Windows+\r\nSomething didn’t add up.\r\nWe found no successful authentications in ADFS logs, or the logging was at least insufficient…\r\nMalicious IIS logs did not contain a value in the cs-username column…\r\nPOST request to /_layouts/15/ToolPane.aspx seemed rather specific…\r\nReferer set so /_layouts/SignOut.aspx cannot be authenticated, right?…\r\nWe developed a feeling that credentials where never used…\r\nHow could the attacker write files to the server, without authenticating at all?\r\nToolShell (CVE-2025-49706 \u0026 CVE-2025-49704)\r\nThat’s when we realized we were no longer dealing with a simple credential-based intrusion.\r\nThis wasn’t a bruteforce or phishing scenario. This was CVE territory.\r\nAfter some digging, we learned that three days earlier, the offensive security team from Code White GmbH\r\ndemonstrated they could reproduce an unauthenticated RCE exploit chain in SharePoint, a combination of two\r\nbugs presented at Pwn2Own Berlin earlier this year in May: CVE-2025-49706 \u0026 CVE-2025-49704. They dubbed\r\nthe chain ToolShell.\r\nhttps://research.eye.security/sharepoint-under-siege/\r\nPage 3 of 12\n\nAt the time, it was considered a proof-of-concept. No public code was released, and details were scarce. But the\r\ntiming matched. And so did the behavior: vulnerability in /_layouts/15/ToolPane.aspx , file writes, no login,\r\nand complete control of the web application process. But the HTTP Referer header used, was odd:\r\n/_layouts/SignOut.aspx .\r\nWe later found that this specific Referer has been fuzzed by @irsdl on the 17th of July 2025, only the\r\ndecompilation of a .NET binary called Microsoft.PerformancePoint.Scorecards.Client.dll remained.\r\nhttps://research.eye.security/sharepoint-under-siege/\r\nPage 4 of 12\n\n@irsdl finding /_layouts/SignOut.aspx as valid Referer to bypass authentication\r\nThis wasn’t a credential issue. We stumbled upon a weaponized Pwn2Own exploit being used in the wild.\r\nASPX payload: dumping crypto (SharpyShell)\r\nWhen our team began reviewing the impacted systems, we expected to find the usual suspects: standard web\r\nshells designed for command execution, file uploads, or lateral movement. Instead, what we discovered was more\r\nsubtle, and arguably more dangerous: a stealthy spinstall0.aspx file whose sole purpose was to extract and\r\nleak cryptographic secrets from the SharePoint server using a simple GET request.\r\nPowershell.exe process spawned by w3wp.exe as grandparent (IIS worker) and cmd.exe as parent on the\r\naffected Windows Server (telemetry collected by our EDR):\r\npowershell -EncodedCommand JABiAGEAcwBlADYANABTAHQAcgBpAG4AZwAgAD0AIAAiAFAAQwBWAEEASQBFAGwAdABjAEcAOQB5AGQAQwB\r\nDecoding reveals the payload, unpacking a base64 layer and dropping its contents to spinstall0.aspx:\r\nContents of spinstall0.aspx, most probably created with Sharpyshell\r\n(92bb4ddb98eeaf11fc15bb32e71d0a63256a0ed826a03ba293ce3a8bf057a514)\r\nThis wasn’t your typical webshell. There were no interactive commands, reverse shells, or command-and-control\r\nlogic. Instead, the page invoked internal .NET methods to read the SharePoint server’s MachineKey\r\nconfiguration, including the ValidationKey . These keys are essential for generating valid __VIEWSTATE\r\npayloads, and gaining access to them effectively turns any authenticated SharePoint request into a remote code\r\nexecution opportunity.\r\nThen it all clicked together.\r\nRCE on SharePoint using ysoserial\r\nBased on us reading about CVE-2021-28474, we learned how the mass exploitation used the ASPX payload to\r\nmaintain persistence, even after patching: utilizing the way SharePoint handles __VIEWSTATE .\r\nIn the original CVE-2021-28474, attackers abused the server-side control parsing logic in SharePoint pages to\r\ninject unexpected objects into the page lifecycle. This was possible because SharePoint loaded and executed\r\nASP.NET ViewState objects using a signing key, namely the ValidationKey , stored in the machine’s\r\nconfiguration. By crafting a malicious page request with a serialized payload, and correctly signing it, an attacker\r\ncould cause SharePoint to deserialize arbitrary objects and execute embedded commands. However, the exploit\r\nhttps://research.eye.security/sharepoint-under-siege/\r\nPage 5 of 12\n\nwas gated by the requirement to generate a valid signature, which in turn required access to the server’s secret\r\nValidationKey .\r\nNow, using the ToolShell chain (CVE-2025-49706 + CVE-2025-49704), the attackers we observed were able to\r\nextract the ValidationKey via the malicious ASPX. Once this cryptographic material is leaked, the attacker can\r\ncraft fully valid, signed __VIEWSTATE payloads using a tool called ysoserial as shown in the example below.\r\nUsing ysoserial the attacker can generate its own valid SharePoint tokens for RCE:\r\nThese payloads can embed any malicious commands. It allows for full persistence and zero authentication, even\r\nafter patching.\r\nPatch Clarifications: CVE-2025-53770 and CVE-2025-53771\r\nAbout 24 hours after we published our initial findings and contacted affected vendors, the Microsoft Security\r\nResponse Center (MSRC) released an out-of-band advisory addressing two new CVEs: CVE-2025-53770 (a patch\r\nbypass of CVE-2025-49704) and CVE-2025-53771 (a bypass of CVE-2025-49706). These CVEs were introduced\r\nto fix weaknesses in the original July 8 patches, but as Microsoft later clarified in their guidance, they had not yet\r\nbeen exploited in the wild at that time.\r\nThe confirmed exploitation activity, observed by us and others since July 17, seems to be based on the original\r\nvulnerabilities CVE-2025-49704 and CVE-2025-49706, now collectively referred to as ToolShell. Systems that\r\nreceived the original July 8 patch should be immune to the exploit waves we gave observed.\r\nWe continue to advise defenders to take action immediately, especially by reviewing system logs, rotating\r\nmachine keys, and following Microsoft’s mitigation steps, regardless of patch status.\r\nOur first response\r\nFor our customer, we immediately initiated a thorough sweep of the SharePoint server and surrounding systems to\r\nensure no additional web shells or persistence mechanisms were present. In parallel, we directly notified the\r\ncustomer, isolated the affected system from the network, and activated our incident response protocol. While the\r\nfull compromise assessment is still ongoing and we will not disclose further details at this time, early evidence\r\nsuggests that the attack was stopped before it could succeed, thanks to the timely intervention of our EDR, which\r\nblocked further execution and prevented lateral movement.\r\nAfter performing some searches across all customers, we confirmed there were no other active intrusions,\r\nallowing us to start our research to inform potential other victims.\r\nScanning the internet to inform victims\r\nRealizing we were likely witnessing the first wave of a mass exploitation campaign, we expanded our scope.\r\nUsing internal telemetry, we scanned over 23000 public-facing SharePoint environments.\r\n# determine SharePoint version\r\ncurl -s -I -X OPTIONS --connect-timeout 5 \"https://$HOST\" \\\r\nhttps://research.eye.security/sharepoint-under-siege/\r\nPage 6 of 12\n\n| grep -i \"^MicrosoftSharePointTeamServices:\" \\\r\n | awk '{print $2}' | tr -d '\\r'\r\n# fetch malicious aspx endpoint (note that SP always returns HTTP 200 even if file does not exist)\r\nRESPONSE=$(curl -s -w \"HTTPSTATUS:%{http_code}\" --connect-timeout 5 \"$URL\")\r\nBODY=$(echo \"$RESPONSE\" | sed -e 's/HTTPSTATUS\\:.*//g')\r\nSTATUS=$(echo \"$RESPONSE\" | tr -d '\\n' | sed -e 's/.*HTTPSTATUS://')\r\nSIZE=$(echo -n \"$BODY\" | wc -c)\r\n# filter on HTTP response bodies of exactly 160 bytes in size\r\nif [ \"$STATUS\" = \"200\" ] \u0026\u0026 [ \"$SIZE\" -le 160 ]; then\r\n echo \"$BODY\"\r\nfi\r\n# if the aspx implant is there, you now have obtained proof (160 bytes long)\r\n# response body format (example):\r\n[A-Z0-9]{64}|HMACSHA256|[A-Z0-9]{64}|Auto|Framework20SP1\r\nOur goal of scanning was clear: determine if the exploit was isolated or systemic. The answer came quickly and\r\ndecisively: it was systemic. Within hours, we identified more then dozens of separate servers compromised\r\nusing the exact same payload at the same filepath. In each case, the attacker had planted a shell that leaked\r\nsensitive key material, enabling complete remote access.\r\nGiven the scale and severity, we moved fast to privately disclose our findings. We compiled technical IOCs,\r\nURLs, and compromise indicators and contacted multiple national CERTs across the world. We also notified the\r\nrelevant affected organizations when possible, in line with responsible disclosure guidelines. Later on, we got\r\noffered support by watchTowr, Shadowserver, DIVD and Hadrian in notifying victims and improve scanning.\r\nCall to action: follow Microsoft’s guidance\r\nWe strongly advise you to follow Microsoft Customer guidance for SharePoint vulnerability CVE-2025-53770.\r\nRotating Machine Keys (pre-caution)\r\nThe attack we’ve observed specifically targets the exfiltration of SharePoint server ASP.NET machine keys. These\r\nkeys can be used to facilitate further attacks, even at a later date. It is critical that affected servers rotate\r\nSharePoint server ASP.NET machine keys and restart IIS on all SharePoint servers. Patching alone is not enough.\r\nIf you are not targeted, or you are unsure, we also advise teams to rotate their Machine Keys just to be sure. It has\r\nno system impact, only that IIS is offline for some seconds while restarting services.\r\nTo update the machine keys using PowerShell, use the following documentation from Microsoft Learn:\r\nPlease note that in specific setups, like in clustered or load-balanced environments, our instructions might not\r\nwork. If possible, please consult a specialised partner to support and validate.\r\nhttps://research.eye.security/sharepoint-under-siege/\r\nPage 7 of 12\n\nAfter rotating the keys, restart IIS on all SharePoint servers by running: iisreset.exe .\r\nUnderstanding the risk (for CISO’s)\r\nCVE-2025-49706 and CVE-2025-49704, also referred to as ToolShell, are critical vulnerabilities in on-premises\r\nSharePoint that enable attackers to gain control of servers without authentication.\r\nMicrosoft has confirmed active exploitation and released patches on July 8th 2025. But as some systems\r\nwere not patched on July 17th 2025 and onwards, attackers managed to make global impact with mass\r\nexploitation tactics.\r\nMicrosoft released that they observed ToolShell exploitation already on July 7th 2025 in the wild. So\r\nassume breach is advised, depending on your organizations’ risk profile.\r\nThe risk is not theoretical. Attackers can execute code remotely, bypassing identity protections such as\r\nMFA or SSO. Once inside, they can access all SharePoint content, system files, and configurations and\r\nmove laterally across the Windows Domain.\r\nMore concerning is the theft of cryptographic keys. These keys allow attackers to impersonate users or\r\nservices, even after the server is patched. So patching alone does not solve the issue: you need to rotate\r\nmachine keys to invalidate future tokens a malicious actor could create.\r\nAttackers can maintain persistence through backdoors or modified components that survive reboots and\r\nupdates. So please consult expert incident response services if in doubt.\r\nBecause SharePoint often connects to core services like Outlook, Teams, and OneDrive, a breach can\r\nquickly lead to data theft, password harvesting, and lateral movement across the network.\r\nYou should assess for compromise immediately and respond accordingly. If that’s done, you should assess \u0026 test\r\nyour patching process and controls, making sure vendors patches are deployed asap once they are available.\r\nImmediate response recommendations\r\nIf you verified you are compromised, act immediately. Follow Microsoft’s advisory and make sure to:\r\n1. Isolate or shut down affected SharePoint servers. Blocking via firewall is not enough as persistence may\r\nalready exist.\r\n2. Renew all credentials and system secrets that could have been exposed via the malicious ASPX.\r\n3. Engage your incident response team or a trusted cybersecurity firm. Time is critical. If you need support,\r\nplease consult specialised support.\r\nIndicators of Compromise (IOC’s)\r\nPlease share the following indicators with your IT-team and/or MSP, allowing them to check their logs. Please not\r\nthat this list might not be complete.\r\n107.191.58[.]76 – first exploit wave\r\n104.238.159[.]149 – second exploit wave\r\n96.9.125[.]147 – shared by PaloAlto Unit42, initial exploit wave\r\nhttps://research.eye.security/sharepoint-under-siege/\r\nPage 8 of 12\n\nNote: more exploit waves on and after 21th of July: 45.191.66[.]77, 45.77.155[.]170,\r\n64.176.50[.]109, 206.166.251[.]228, 34.72.225[.]196, 34.121.207[.]116, 141.164.60[.]10,\r\n134.199.202[.]205, 188.130.206[.]168\r\nNote: post-exploitation c2 traffic: 131.226.2[.]6\r\nMozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0 – user agent\r\nstring used in active exploitation on 18th \u0026 19th of July\r\nMozilla/5.0+(Windows+NT+10.0;+Win64;+x64;+rv:120.0)+Gecko/20100101+Firefox/120.0 – encoded\r\nuser agent string for IIS log searches\r\nNote: we will not add any newly observed user agents after 19th of July observation\r\n/_layouts/15/ToolPane.aspx?DisplayMode=Edit\u0026a=/ToolPane.aspx – POST path used to trigger exploit\r\nand push Sharpyshell\r\n/_layouts/16/ToolPane.aspx?DisplayMode=Edit\u0026a=/ToolPane.aspx – alternative version\r\nReferer: /_layouts/SignOut.aspx – exact HTTP header used in exploiting ToolPane.aspx\r\nNote: be advised that full URI Referers are also used in the wild: Referer:\r\nhttps://\u003ctarget\u003e/_layouts/SignOut.aspx and Referer:\r\nhttp://\u003ctarget\u003e/_layouts/SignOut.aspx\r\nGET request to malicious ASPX file in /_layouts/15/spinstall0.aspx – aspx crypto dumper used by\r\nCVE-2021-28474 with tool ysoserial to get RCE on SharePoint\r\n92bb4ddb98eeaf11fc15bb32e71d0a63256a0ed826a03ba293ce3a8bf057a514 – SHA256 hash of\r\nspinstall0.aspx crypto dumper probably created with Sharpyshell\r\nC:\\PROGRA~1\\COMMON~1\\MICROS~1\\WEBSER~1\\16\\TEMPLATE\\LAYOUTS\\spinstall0.aspx – location of the\r\nmalicious aspx file on Windows Servers running SharePoint\r\nNote: alternative paths exists depending on your version:\r\nC:\\PROGRA~1\\COMMON~1\\MICROS~1\\WEBSER~1\\15\\TEMPLATE\\LAYOUTS\\spinstall0.aspx\r\nNote: variants like spinstall.aspx, spinstall1.aspx and spinstall2.aspx, xxx.aspx, 3plx.aspx,\r\ndebug_dev.js, info.js have also been seen. Be aware that the filename can be anything.\r\nIndicators of Attack (IoA’s)\r\nThe following queries can be used to hunt exploitation attempts with CrowdStrike Falcon, Defender for Endpoint\r\nand Sentinel One Complete.\r\nCrowdStrike Falcon (Next-Gen SIEM)\r\nDefender for Endpoint (Advanced Hunting)\r\nSentinel One\r\nTimeline\r\nhttps://research.eye.security/sharepoint-under-siege/\r\nPage 9 of 12\n\nTime Event\r\n18-07-25\r\n~18:00\r\nUTC\r\nWe identified the ASPX payload, research started\r\n19-07-25\r\n~02:00\r\nUTC\r\nPublication of our blog\r\n19-07-25\r\n~06:00\r\nUTC\r\nCorrected that Pwn2Own Berlin was in May ’25\r\n19-07-25\r\n~17:00\r\nUTC\r\nNew IP added used for 2nd wave of mass exploitation\r\n20-07-25\r\n~06:00\r\nUTC\r\nMicrosoft assigned CVE-2025-53770 and stated there is currently no patch\r\navailable. Disclosed malicious ASPX file path \u0026 hash. Added ysoserial example.\r\n20-07-25\r\n~08:00\r\nUTC\r\nAdded proof from X that @irsdl found an auth bypass that enabled CVE-2025-\r\n53770 to work without auth\r\n20-07-25\r\n~10:00\r\nUTC\r\nAdded relevant external resources section\r\n20-07-25\r\n~13:00\r\nUTC\r\nAdded RCE payload (Powershell) that drops spinstall0.aspx\r\n20-07-25\r\n~21:00\r\nUTC\r\nFixed some typo’s (including a typo in the Referer IOC)\r\n21-07-25\r\n~12:45\r\nUTC\r\nAdded steps to rotate ASP.NET machine keys as precaution\r\n21-07-25\r\n~17:30\r\nUTC\r\nAdded context to IOC 96.9.125[.]147 (1st wave 17th of July)\r\nhttps://research.eye.security/sharepoint-under-siege/\r\nPage 10 of 12\n\nTime Event\r\n21-07-25\r\n~18:30\r\nUTC\r\nAdded newly detected 3rd wave from 45.77.155[.]170\r\n21-07-25\r\n~23:00\r\nUTC\r\nAdded IPv4 IOC’s of several new waves we detected\r\n21-07-25\r\n~23:30\r\nUTC\r\nFixed Machine Key rotation instructions\r\n22-07-25\r\n~09:00\r\nUTC\r\nAdded Microsoft patch information\r\n22-07-25\r\n~10:00\r\nUTC\r\nAdded additional IPv4 IOC’s of new waves detected\r\n23-07-25\r\n~09:15\r\nUTC\r\nAdded additional webshell filenames IOC’s\r\n24-07-25\r\n~10:30\r\nUTC\r\nAdded Indicators of Attack\r\n29-07-25\r\n~20:00\r\nUTC\r\nClarifications \u0026 corrections, as July 17 to 19 waves we observed were not CVE-2025-53770/53771, but rather the original ToolShell chain: CVE-2025-49706\r\n(auth bypass) and CVE-2025-49704 (deserialization RCE) as pointed out by\r\n@irsdl (thank you).\r\nExternal resources\r\nPlease use the following confirmed sources which are linked through-out this blog.\r\nMicrosoft CVE-2025-53770 SharePoint Vulnerability Customer Guidance\r\nClarification posted on X by @irsdl posted on 28th of July 2025\r\nMSRC Microsoft SharePoint Auth Bypass Vulnerability (CVE-2025-49706)\r\nMSRC Microsoft SharePoint Remote Code Execution Vulnerability (CVE-2025-49704)\r\nNCSC-NL (Dutch GovCERT) vulnerability disclosure\r\nPaloAlto Unit42 IOC’s\r\nOur initial disclosure on LinkedIn\r\nhttps://research.eye.security/sharepoint-under-siege/\r\nPage 11 of 12\n\nZDI original SharePoint auth bypass disclosure (CVE-2025-49706 / ZDI-25-580 / ZDI-CAN-27162)\r\nPOC shared by CODE WHITE GmbH on X (CVE-2025-49704 + CVE-2025-49706)\r\nPOC auth bypass fuzzing results shared by @irsdl on X (CVE-2025-49706)\r\nAbout Eye Security\r\nWe are a European cybersecurity company focused on 24/7 threat monitoring, incident response, and cyber\r\ninsurance. Our research team performs proactive scans and threat intelligence operations across the region to\r\ndefend our customers and their supply chains.\r\nLearn more at https://eye.security/ and follow us on LinkedIn to help us spread the word.\r\nSource: https://research.eye.security/sharepoint-under-siege/\r\nhttps://research.eye.security/sharepoint-under-siege/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://research.eye.security/sharepoint-under-siege/"
	],
	"report_names": [
		"sharepoint-under-siege"
	],
	"threat_actors": [],
	"ts_created_at": 1775434521,
	"ts_updated_at": 1775826687,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/317c872cd047c2d82419d8257ec0f53274d69819.pdf",
		"text": "https://archive.orkl.eu/317c872cd047c2d82419d8257ec0f53274d69819.txt",
		"img": "https://archive.orkl.eu/317c872cd047c2d82419d8257ec0f53274d69819.jpg"
	}
}