A newly published ShieldCrash proof of concept from researcher MSNightmare claims that Microsoft Defender remains vulnerable to an arbitrary file-read flaw, despite Microsoft’s earlier fix for ShieldBreak, tracked as CVE-2026-69414.

The researcher says the issue could let a local attacker make Defender read files with SYSTEM-level privileges on fully updated, supported Windows systems.

According to the MSNightmare, Microsoft addressed several parts of the original ShieldBreak issue but left a specific attack path available. Under certain conditions, that remaining path allegedly recreates the core security impact of the prior vulnerability.

The reported impact is significant because the SYSTEM account has broader permissions than normal users and most administrator accounts. Windows services, security software components, and protected operating system processes often run under SYSTEM.

If an attacker can force a Defender component to access a protected file and expose its contents, they may obtain sensitive data that their existing account should not access.

Windows Defender ShieldCrash 0-Day Flaw

Potentially exposed data could include application configuration files, credential-related material, security product settings, private keys, browser or service secrets, or files belonging to other Windows users.

The exact impact depends on which files the attacker can target, whether they can reliably recover their contents, and what permissions the attacker already has before launching the attack.

The available proof of concept is described as a structure implementation rather than a complete SYSTEM privilege-escalation exploit.

The researcher says it demonstrates arbitrary file reading as SYSTEM after the September 2026 Windows security updates, while noting that a more complete proof of concept could be released later. Reading a file does not mean you can run code or system commands, but it can still weaken Windows security.

The ShieldCrash repository includes C++ project files, a DLL named Warden.dll, resource files, and an EICAR test archive. The EICAR file suggests the research may involve Defender’s malware-detection or file-handling workflow.

However, organizations should avoid running untrusted public proof-of-concept code on production endpoints, especially code that interacts with antivirus services or privileged Windows components.

The GitHub ShieldCrash PoC claims Microsoft’s fix for ShieldBreak (CVE-2026-69414) failed to fully address the underlying issue, allowing arbitrary file reads as SYSTEM on patched Windows systems.

Microsoft has not publicly confirmed the newer bypass, which remains a researcher-reported claim pending independent reproduction or a Microsoft security advisory. The earlier issue is tracked as CVE-2026-69414, while the new bypass has not yet received a separate CVE assignment.

Defenders should monitor endpoints for suspicious local tools that interact with Microsoft Defender scanning paths, unexpected creation or loading of unsigned DLLs, abnormal access attempts involving protected files, and child processes or file operations associated with Defender services.

Security teams should also keep the Microsoft Defender platform and intelligence updates current, apply future Microsoft patches promptly, and restrict untrusted code execution through application control policies.

Learn 7 Metric-Gated AI SOC Deployment Phases – Download Free AI SOC Deployment Playbook 2026.

The post New Windows Defender ShieldCrash 0-Day Bypasses Microsoft Patch to Read Files as SYSTEM appeared first on Cyber Security News.

A public proof-of-concept exploit has been released for CVE-2026-62911, a Microsoft Exchange Server vulnerability linked to an authentication capture-and-replay weakness.

While Microsoft classifies the issue as an elevation-of-privilege flaw, the published research describes an attack chain that can lead to unauthenticated remote code execution and a SYSTEM-level compromise on vulnerable Exchange environments.

The PoC, published on GitHub by researcher Nguyen Van Hiep, targets the Exchange Mailbox Replication Proxy service, commonly known as MRSProxy.

The exploit documentation claims that a reachable HTTP. sys-hosted MRSProxy endpoint does not enforce Extended Protection for Authentication, enabling an attacker to relay NTLM authentication from an Exchange machine account to the service.

Microsoft disclosed CVE-2026-62911 in August 2026 as an authentication-bypass capture-replay issue affecting on-premises Microsoft Exchange Server.

Public PoC For Exchange Server Pre-Auth RCE

Microsoft’s public description states that an authorized attacker could elevate privileges over a network. In contrast, the available PoC increases practical risk by demonstrating an NTLM relay path that may eliminate the need for prior Exchange credentials in certain configurations.

According to the technical analysis, Exchange exposes MRSProxy through separate endpoints. Extended Protection protects the IIS-hosted /EWS/MRSProxy.svc path.

However, the HTTPsys-hosted MailboxReplicationService ProxyService endpoint may not validate channel bindings. This creates a relay opportunity where a captured machine-account authentication attempt can be forwarded to the vulnerable Exchange service.

The attack chain begins by coercing an Exchange server to authenticate to an attacker-controlled listener through a technique such as PetitPotam. The attacker can then relay the NTLM authentication to a second vulnerable Exchange server.

If the relay succeeds, the machine account is treated as authenticated by MRSProxy. It receives access to Exchange mailbox replication functionality.

The PoC reportedly abuses WCF methods within the replication service, including IMailbox_Config6 and IMailbox_Connect. The first method accepts a file path, while the second may cause Exchange to write content to that location.

An attacker could attempt to place an ASPX webshell into a web-accessible IIS or Exchange virtual directory, then access the file remotely to execute commands under the Exchange service context. Public reporting and technical analysis describe a potential SYSTEM-level outcome.

The vulnerability is associated with a three-bug chain demonstrated by Orange Tsai of DEVCORE at Pwn2Own Berlin 2026. The Exchange compromise earned a $200,000 reward during the competition, underscoring the security impact of chained authentication and service-level weaknesses.

Affected products include Exchange Server 2016 CU23, Exchange Server 2019 CU14 and CU15, and Exchange Server Subscription Edition RTM. Organizations should deploy Microsoft’s August 2026 Exchange security updates immediately.

Fixed builds include Exchange 2016 CU23 (version 15.1.2507.72), Exchange 2019 CU14 (version 15.2.1544.44), Exchange 2019 CU15 (version 15.2.1748.49), and Exchange Server Subscription Edition (version 15.2.2562.46).

Exchange 2016 reached end of support in October 2025, meaning organizations without Extended Security Updates may not have a supported remediation path.

Administrators should also verify Extended Protection settings, reduce unnecessary exposure of Exchange services, monitor for unusual NTLM relay activity, and investigate unexpected ASPX files in Exchange and IIS directories.

Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC

The post Public PoC Released for Microsoft Exchange Server Pre-auth RCE Vulnerability appeared first on Cyber Security News.

Microsoft has started expanding primary mailbox storage for Microsoft 365 Business Basic, Business Standard, and Business Premium users. Eligible users can now receive up to 100 GB of Exchange Online mailbox capacity, doubling the previous 50 GB entitlement.

The change is part of Microsoft’s 2026 packaging updates, which began rolling out in June and are expected to continue through September. Microsoft also issued advance tenant notifications through the Message Center before the service-plan changes became available.

The increased capacity applies only to the primary mailbox. It does not automatically provide archive mailbox features, compliance capabilities, or other benefits of Exchange Online Plan 2.

Microsoft Expands Mailbox Storage

Microsoft delivers the new 100 GB entitlement through two Exchange-related service plans. The existing BPOS_S_STANDARD service plan provides the original 50 GB quota. A new EXCHANGE_STORAGE_50GB service plan adds another 50 GB.

Both service plans must be enabled for an eligible user to receive the full 100 GB primary mailbox quota. The added capacity is not a separate mailbox or additional archive storage it is an increase to the user’s primary Exchange mailbox limit.

Administrators should verify the assigned plans in the Microsoft 365 admin center under Users > Active users> Licenses and apps. The storage service plan may also be reviewed using Microsoft Graph PowerShell:

$licenses = Get-MgUserLicenseDetail -UserId user@contoso.com
$licenses.ServicePlans | Where-Object ServicePlanName -eq "EXCHANGE_STORAGE_50GB" |
Select-Object ServicePlanName, ProvisioningStatus

The change is limited to Microsoft 365 Business Basic, Business Standard, and Business Premium. Standalone Exchange Online Plan 1 licenses can still retain a 50 GB primary mailbox limit.

Organizations assigning multiple Exchange licenses to one user should note that storage quotas are not cumulative. Exchange Online offers the highest mailbox entitlement available in a single applicable product.

For example, a user assigned Business Premium and an Exchange Online Plan 2 or Microsoft 365 E3 license remains capped at 100 GB, rather than receiving 200 GB.

This follows Microsoft’s concurrent licensing model, where multiple service plans can be assigned. However, mailbox capacity does not stack beyond the highest supported entitlement.

Microsoft confirmed that the automatic storage increase will not overwrite administrator-defined mailbox quotas. If an administrator previously reduced a mailbox quota from 50 GB to 20 GB, it will remain at 20 GB after the add-on service plan is provisioned.

Likewise, removing the new storage service plan does not replace a later custom quota. This behavior protects tenant-specific mailbox governance and retention practices.

Administrators can inspect the effective Exchange quota with Exchange Online PowerShell:

Get-Mailbox -Identity user@contoso.com |
Format-List IssueWarningQuota,ProhibitSendQuota,ProhibitSendReceiveQuota,UseDatabaseQuotaDefaults

For an eligible user with both service plans enabled and no manually configured quota, the effective maximum should show 100 GB.

Because the update depends on provisioning of licenses and service plans, users within the same tenant may not receive the new quota simultaneously.

Microsoft says the process should complete automatically for properly licensed users during the June-to-September rollout window. Administrators should avoid removing and reassigning Exchange licenses to force a quota refresh.

License removal can interrupt service access and trigger the associated data-retention lifecycle. Instead, organizations should continue with standard license-assignment processes and verify that the new storage plan is in place.

Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC

The post Microsoft Expands Mailbox Storage From 50 GB to 100 GB for Users appeared first on Cyber Security News.

Security researchers have disclosed a serious attack chain affecting Microsoft System Center Configuration Manager, commonly known as SCCM or Configuration Manager.

The flaws could allow an attacker to execute malicious code remotely on an SCCM primary site server, potentially taking control of an organization’s managed Windows environment.

The attack is especially concerning because a standard Active Directory domain user could start the original chain. The account does not need SCCM administrative permissions, elevated Windows privileges, or user interaction.

A successful attack targets the SCCM primary site server, a critical system responsible for software deployment, patching, operating system installation, compliance monitoring, and device management.

Microsoft SCCM Vulnerability

XM Cyber reported the vulnerabilities to Microsoft on May 23. Microsoft assigned CVE-2026-47301 to the broken authorization issue and released a fix on July 14, 2026.

However, researchers said the remaining weaknesses in the chain are still unpatched. Microsoft plans to address them in ConfigMgr 2609, expected in October 2026.

The first issue involved SCCM’s AdminService REST API. SCCM supports uploading console extension packages through CAB archives. One upload endpoint checked for the required role-based access control permission.

In contrast, a chunked upload endpoint did not perform the same authorization check. This allowed authenticated domain users to submit specially crafted CAB files to the server.

The second weakness affected signature validation. SCCM checked whether a CAB archive had a valid embedded signature, but reportedly did not enforce that the signing certificate belonged to Microsoft or the victim organization.

It also skipped certificate revocation checks. As a result, an attacker could use a certificate that SCCM accepted to sign a malicious extension package.

Researchers also identified a path traversal flaw called “CabSlip.” During CAB extraction, SCCM failed to block relative path sequences properly. A crafted archive could write files outside the intended temporary extraction folder.

This gave attackers arbitrary file write access on the site’s server. The final step abused DLL loading behavior in the SMS Executive service. SMS Executive runs with NT AUTHORITY\SYSTEM privileges.

Although it validates a primary DLL, the service can load a secondary DLL named adsource.dll without performing equivalent integrity checks.

An attacker could overwrite that DLL through the path traversal flaw. When SCCM later loads the library, the malicious code would run as SYSTEM. Microsoft’s July update blocks standard domain users from abusing the chunked upload endpoint.

Yet users assigned the built-in Operations Administrator role, or a custom role with Create permission on the SMS_ConsoleExtensionData object, may still access the downstream attack path.

Defenders should monitor AdminService.log for DirectoryNotFoundException errors followed by HTTP 500 responses, inspect unexpected CAB upload activity, and watch for changes to adsource.dll in the Configuration Manager installation directory.

Organizations should also restrict access to the AdminService network port and urgently review SCCM role assignments until Microsoft releases a complete fix.

 Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.

The post Microsoft SCCM Vulnerability Chained to Execute Malicious Code Remotely appeared first on Cyber Security News.

Microsoft will make passkeys the default authentication experience in Microsoft Entra ID as part of a broader move away from phishing-prone sign-in methods.

The company will also retire Microsoft-provided SMS and voice authentication for multifactor authentication, pushing organizations toward phishing-resistant credentials.

Beginning September 1, 2026, users currently enabled for SMS or voice authentication will be automatically enabled for passkeys. During a future MFA sign-in, these users will see prompts encouraging them to register a passkey.

Microsoft will manage the passkey registration campaign by default. However, users can repeatedly postpone the registration prompt during the transition period. The change is designed to reduce risks associated with SMS and voice-based authentication.

Attackers can target these methods through phishing kits, SIM swapping, social engineering, number porting, and interception. Passkeys instead use cryptographic credentials tied to a device or credential manager.

Because there is no reusable shared secret to enter on a fake website, passkeys are intended to resist phishing and replay attacks. Microsoft Entra ID supports synced and device-bound passkeys.

Microsoft Passkeys Default in Entra ID

Synced passkeys can be stored in credential managers such as iCloud Keychain or Google Password Manager and used across a user’s devices.

Device-bound passkeys remain on a specific device and can include Windows Hello for Business, Microsoft Authenticator passkeys, Entra Passkey on Windows, and FIDO2 hardware security keys.

The next major deadline is February 1, 2027. On that date, Microsoft will fully retire its native telecom delivery for SMS and voice in Entra ID.

Organizations that continue relying on these channels must use a customer-managed telecom provider available through the Microsoft Security Store.

Microsoft plans to publish provider information from September 18, 2026, while customers are expected to be able to select and configure providers from October 30, 2026.

After the retirement date, users whose only MFA option is SMS or voice will face a blocking passkey registration prompt during sign-in. They will have to register a passkey before accessing their account.

Microsoft says there will be no opt-out from this enforcement, making early migration essential to avoid account access disruptions.

Administrators should first identify users who are still enabled for SMS or voice in the Entra Authentication Methods Policy or in legacy MFA configurations. Microsoft provides a PowerShell-based analyzer to help organizations find affected users.

Security teams should then enable Passkey (FIDO2), create targeted user groups, and launch a staged registration campaign before the automatic migration.

Microsoft is also offering a temporary opt-out for the automatic passkey enablement phase between September 1, 2026, and February 1, 2027. Administrators can use Microsoft Graph to set the passkeyDynamicMigration property in the authentication methods policy.

However, this setting only delays the transition. It does not prevent the February 2027 retirement and mandatory passkey registration requirement.

For enterprises, the announcement means that SMS and voice MFA should now be treated as legacy fallback options rather than long-term authentication controls.

Organizations should prioritize passkeys, Windows Hello for Business, and FIDO2 security keys, while reserving customer-managed telecom services only for limited regulatory or operational requirements.

 Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.

The post Microsoft to Make Passkeys Default in Entra ID and Retires SMS and Voice Authentication appeared first on Cyber Security News.