If you run PaperCut NG or MF, restrict its web interface to trusted addresses today, then install Emergency Patch Release 3. PaperCut's security bulletin says its response team "is investigating active exploitation of a vulnerability affecting PaperCut NG and PaperCut MF," and that "we are aware of confirmed customer incidents." The vendor's own first instruction is a network control, not a patch: "If your PaperCut NG/MF Application Server is accessible from the public internet, immediately restrict web access to trusted IP addresses only." It adds, "Take this action now, even if you have not observed suspicious activity."

Two CVEs chain into unauthenticated code execution. CVE-2026-81578 is the way in: "unauthenticated remote requests targeting administrative functions can trigger backend actions prior to the completion of access validation checks," letting an attacker "modify certain system configurations." NVD scores it 9.8 on CVSS v3.1. CVE-2026-82078 is what that configuration access buys: PaperCut "instantiates database driver classes based on configurable driver names without validating against an allowlist," which "enables the execution of arbitrary Java bytecode residing on the application classpath under the security context of the PaperCut server process." NVD scores that one 9.1. Change the database driver setting, then make the server load it. CISA added both to KEV on August 31 with a federal deadline of September 14.

Which patch you installed decides whether you are done. PaperCut shipped three emergency patches in five days — the first on August 28, Release 2 later the same day, and Release 3 on September 1. Rapid7's exploit module for this chain, submitted to Metasploit on August 28, states plainly that it "bypasses the vendors emergency patch v1," and that "the vendors emergency patch v2 has been verified to successfully remediate this exploit." Rapid7's write-up explains that "the first emergency patch could be bypassed by using the Home page for display, however the newest version of the vendor patch correctly remediates this bypass." If you patched on August 28 and closed the ticket, you may be running the version a public module defeats.

Do not verify this by version number. NVD's affected ranges mark 26.0.4 as fixed, but the Metasploit module's own example output reports PaperCut MF 26.0.4.76494 as vulnerable and returns a SYSTEM shell. Check the build. Release 3 is Build 76531 (MF v26), 76532 (MF v25), 76534 (MF v24), 76530 (NG v26), 76533 (NG v25), and 76535 (NG v24). These are not normal releases. Asked "Is this an official release?", the bulletin answers, "No. We have not gone through our usual release process."

Scope it correctly. "Site Servers and secondary/print servers should be updated to a patched version, not just the primary Application Server." Mobility Print, Print Deploy, the client software, Hive, and Pocket are not affected. Versions 23 and earlier get no patch — the guidance is to upgrade.

Action, in order. First, firewall the Application Server's web interface off the public internet, including your smallest print-only sites. Second, install Release 3 on every application, site, and secondary server, confirming the build number, not the version. Third, hunt before you close. PaperCut's indicators include the server.log string ERROR No suitable driver found for jdbc:no:x, files matching <install>\server\lib\<5-char-name>.class, and a post-compromise sequence that starts with whoami & ver and ends with a Windows service named "Remote Access Service" running a SimpleHelp agent as LocalSystem, followed by an AnyDesk download. Search your RMM for both. The bulletin warns that "these files may be cleaned up by the attacker as activity progresses, so their absence does not rule out compromise." If you find evidence, PaperCut's advice is to rebuild the Application Server and restore a backup from before the activity. As of September 2 the vendor reports "a second wave of attack on servers that are not fully patched and are publicly available."

Advisories

An authentication config took out Exchange Online, OneDrive, Teams, and Defender XDR

Microsoft acknowledged an Exchange Online incident at 5:30 PM UTC on August 31 under EX1464935, then retracked it as MO1465074 when it spread to "OneDrive for Business and SharePoint Online, Microsoft Teams, Microsoft Purview, and Microsoft Defender XDR," per BleepingComputer. Downdetector reported "tens of thousands" of affected users. Microsoft first said it had "isolated a common failure pattern across affected Exchange Online requests that is associated with authentication and protocol connectivity," then attributed it to "core authentication configuration issues" that are "used by multiple internal services within the Exchange Online infrastructure." 22 hours after acknowledgement Microsoft reported "positive recovery trends," and said mail flow and search were restored later on September 1.

Action: it is not fully closed. On September 2 Microsoft said "a small subset of users may still see impact," with "service availability remains stable above 99 percent." Confirm mail flow for clients who never called. Then fix your status template: one authentication component took mail, files, Teams, and two security products with it, so "Exchange is down" will understate the next one.

Defender is telling users it is turned off when it is not

Microsoft confirmed a known issue on August 28 in Windows release health: "After installing the latest updates for Microsoft Defender Antivirus, notifications might appear stating that 'Microsoft Defender Antivirus is turned off,' even though the antivirus is functioning correctly and all settings show it as active." The alerts "can appear when Windows starts and intermittently afterward" and "persist even if notification settings are turned off." The affected list runs to 14 platforms, from Windows 11 26H1 back through Windows 10 Enterprise LTSC 2016 and Windows Server 2012. There is no fix yet: "We are working to release a resolution in a future Microsoft Defender Antivirus update."

Action: send a short client-facing note before the tickets arrive. Users who learn to dismiss security popups keep the habit, so tell them this specific alert is a known false alarm rather than letting them decide on their own. Confirm real-time protection from your RMM or the Defender portal rather than the endpoint's own toast, and treat a device as unprotected only when your management plane agrees.

Teams and new Outlook fail to launch on ARM devices after the August update

Microsoft opened this known issue on September 1: after installing the security updates "released on or after August 11, 2026, (KB5121003), Microsoft Teams and the new Outlook for Windows might fail to launch or might close unexpectedly on ARM-based devices, such as Surface Pro 11 and Surface Laptop 7." Classic Outlook, Word, and Excel are not affected. It hits "new or freshly imaged PCs that have not yet installed any Microsoft Store updates." Microsoft marks it Mitigated — a workaround, not a patch.

Action: the fix is a Store update, not a Windows one — open Microsoft Store, go to Downloads, check for updates, and install the Auto Super Resolution Package version 1.0.19.0 or later. Fold this into your ARM imaging checklist now. Autopilot devices that ship straight to a user will hit it before anyone from your team touches them, and a new Surface that cannot open Teams reads as a broken deployment on day one.

Product changes

Intune can now run Remote Help sessions with nobody at the keyboard

The Intune 2608 service release, shipped the week of August 25, adds unattended Remote Help on physical Windows devices: "Authorized helpdesk agents can sign in to a remote device with their own credentials without requiring the user to be present or take action. Helpers can view and control the device to troubleshoot issues and complete support tasks remotely." It ships under Advanced capabilities, the add-on formerly sold as the Intune Suite, so check entitlement before you promise it to a client.

Action: decide who gets this role before you enable it. Unattended access to a user's session is a different consent posture than the click-to-approve model your clients agreed to, so write it into your MSA, scope the helper role narrowly, and confirm session logging lands somewhere you can produce on request. The same release turns the new single device page on by default, so expect "the Intune console moved" tickets from your own team.

SharePoint will now report exactly what Everyone except external users can reach

SharePoint's admin center gained an item-level oversharing report, marked Launched in the M365 release communications API with an August availability date: "The new report provides SharePoint Advanced Management admins complete item level details of permissions granted to Everyone except external user and Everyone special SharePoint groups." Note the qualifier — this is a SharePoint Advanced Management feature, not a base SharePoint Online one.

Action: if a client licenses SharePoint Advanced Management, run this report before their next Copilot rollout, not after. The Everyone except external users group reads as safe to whoever clicked it years ago, and item-level detail is what turns a vague oversharing worry into a fixable list. Clients without the add-on have the same exposure and no report — plan that permission review as manual work.

Teams adds automatic bot blocking and mandatory meeting consent

Two Teams controls are rolling out for September, both in the release communications API. The first extends existing external-AI-bot controls: "we are adding the option to automatically block all identified bots" from joining meetings, reaching Worldwide and GCC. The second is broader — "a new configuration experience in Teams Admin Center where tenant admins can enable and customize an explicit consent message before joining any meeting hosted in their organization," covering Worldwide, GCC, GCC High, and DoD.

Action: raise the bot-blocking toggle with clients who have never inventoried which notetakers join their calls. Blocking every identified bot will break notetakers people rely on, so ask before you flip it, not after the first complaint. Flag the consent message to any client under recording-consent obligations — it puts the notice in the join path instead of a policy document nobody opens.

Licensing

CSP direct bill eligibility is now checked per tenant, with 90 days before enforcement

Microsoft announced the Eligibility Dashboard on August 27 for CSP direct bill partners, and the change underneath it matters more than the dashboard. "Microsoft AI Cloud Partner Program (MAICPP) enrollment and the associated security requirement are enforced at the tenant level rather than the partner global account (PGA) level," so "if one or more tenants under your partner global account don't meet a tenant-level requirement, only the affected tenant is at risk." Revenue, support plan, and solutions partner designations still validate at the PGA level. The dashboard arrives "gradually through mid-September," and "enforcement for these tenant-level requirements begins 90 days after release."

Action: Microsoft gives 90 days from release before enforcement — use them to find tenants passing on the partner global account's coattails. Sign in as a global administrator or admin agent and check MAICPP enrollment plus the security requirement for every CSP tenant, not just the one you are signed into; Partner Center shows that status only for the current tenant. A stale partner location account association is a common cause of a tenant reading as inactive while your organization is enrolled.

Compliance

Purview DLP gets specific about what to do when classification fails

Microsoft has default protection controls for Exchange Online in public preview, per the release communications API: the release "gives administrators fine-grained control to create DLP policies based on specific classification or text extraction failure types — such as timeout, throttling and other scan errors — rather than one blanket policy for all failure conditions." Read the cloud scope before you plan around it: this record lists GCC, GCC High, and DoD only, not Worldwide.

Action: for government-cloud clients this closes a real gap — a scan timeout and an unreadable attachment are different risks, and one blanket rule forced a choice between blocking too much and letting failures through. Check how your Exchange DLP policies behave on failure before the preview lands; most tenants inherited a default nobody chose. Commercial-cloud clients should watch rather than plan.