Researchers disclosed on June 3 that several Microsoft 365 Android applications shipped with a development debug flag enabled in their production builds. The flag in question disabled the Android inter-app token sharing restriction that is intended to limit which apps can receive authentication tokens from other apps on the same device. Under normal operation, this restriction ensures that only other Microsoft apps can request and receive M365 account tokens shared between Microsoft applications on a device.
With the flag enabled, any app installed on the same Android device, including third-party apps with no relationship to Microsoft, could send a standard Android inter-app token request to the affected M365 apps and receive the signed-in user’s account token in response. The token grants full access to the user’s M365 environment including Exchange Online email, SharePoint files, Teams messages, OneDrive documents, and calendar data. The user receives no visible notification that the token has been shared. Microsoft has confirmed the issue and released a fix through updated app versions on Google Play.
The affected applications include multiple apps in the Microsoft 365 suite on Android. The specific app versions and the window during which the flag was present have not been fully detailed in public reporting as of today. Microsoft recommends updating all M365 Android apps to the latest versions available.
- Update all Microsoft 365 Android apps to the latest versions via Google Play immediately. Push the update through MDM for managed Android devices in your fleet today.
- Review M365 sign-in logs for accounts accessed via mobile clients for unexpected access patterns since the affected app versions were in use. Unexpected token usage from Android clients may indicate prior exploitation.
- Evaluate Microsoft Entra Conditional Access policies for token binding and Continuous Access Evaluation, which reduces the useful lifetime of stolen tokens by requiring periodic re-authentication for sensitive actions.
Huntress disclosed on June 3 that the Windows Search URI handler, the system component that processes search: protocol links and opens Windows Search, can be exploited to trigger automatic NTLM authentication to an attacker-controlled server when a user clicks a specially crafted link. The mechanism is the same class of vulnerability as CVE-2026-33829, which affected the ms-screensketch: URI handler and was patched by Microsoft in April 2026.
When a user clicks a crafted search: link, Windows processes it through the Search URI handler, which initiates a search operation. As part of that process, Windows may attempt to authenticate to a UNC path or network resource embedded in the crafted URI using NTLM. This sends the user’s NTLMv2 credential hash to the attacker-controlled server specified in the link. The attacker does not need any prior access to the victim’s environment. The link can be embedded in a web page, phishing email, or document.
No patch has been released by Microsoft for this specific URI handler vulnerability as of today’s reporting. Huntress has reported the vulnerability to Microsoft through responsible disclosure. Given the April precedent with CVE-2026-33829 affecting a similar URI handler mechanism, a patch is anticipated in an upcoming Patch Tuesday or out-of-band release.
- Block outbound SMB connections on port 445 at the network perimeter firewall. This prevents NTLM authentication attempts triggered by crafted links from reaching attacker-controlled external servers.
- Where Kerberos authentication is available and NTLM is not required, consider disabling NTLMv2 via Group Policy to eliminate the credential exposure class entirely rather than relying solely on network blocking.
- Monitor MSRC for a patch addressing the Windows Search URI handler NTLM coercion vulnerability and apply it as a priority when released.
SecurityWeek confirmed on June 3 that threat actors are exploiting vulnerable Kirki and Burst Statistics WordPress plugin deployments to elevate privileges and take over websites. Burst Statistics is a popular WordPress analytics plugin used to track visitor traffic and site performance. The specific vulnerability in Burst Statistics being exploited allows privilege escalation on affected sites, consistent with the account takeover capability confirmed in the Kirki campaign.
The campaign targeting both plugins simultaneously suggests a coordinated actor or toolkit that is scanning for both vulnerabilities and exploiting whichever is present on a given target site. WordPress sites that have both plugins installed are being hit by a single attack pass that chains the two vulnerabilities for maximum access. Sites with only one of the two present are being targeted through whichever plugin is available.
The WordPress plugin active exploitation wave this week began with WP Maps Pro from Issue 50 on June 1 and expanded to Kirki in Issue 52 on June 2. The addition of Burst Statistics today represents continued escalation of the campaign rather than a separate unrelated attack. Patch both plugins and follow the post-compromise audit procedure even if patching appears timely.
- Update or disable the Burst Statistics WordPress plugin immediately across all managed WordPress sites. Check the WordPress plugin repository for the patched version.
- Confirm Kirki is patched following Issue 52 guidance. Also check for theme-bundled Kirki copies that may not appear in the standard Plugins menu.
- Audit the WordPress Users table for unexpected administrator or elevated-privilege accounts and review recently modified plugin and theme files for backdoors on any site that had either plugin installed while unpatched.