Dispatch 001: The first dispatch: A Fortinet EMS advisory, an Acrobat zero-day, and a Looming Secure Boot deadline

Steven Lorenz — Tue, 14 Apr 2026 00:00:00 GMT

Patch today

CVE-2026-35616 + CVE-2026-21643 in Fortinet FortiClient EMS, both actively exploited
Patch FortiClient EMS today. If it's reachable from the internet, that's the actual problem.
Why it matters: If your MSP runs your Fortinet and hasn't called you about this one yet, that's its own finding. EMS is the management server that pushes policy to every endpoint agent you own, and it has an unauthenticated RCE being actively exploited right now. The federal patch deadline was last Thursday. Meanwhile, roughly two thousand of these are sitting on the open internet because somewhere along the way, someone decided the management plane didn't need to be behind anything. It does.
What to do: Push the 7.4.5/7.4.6 hotfix through to the EMS host before lunch, or jump to 7.4.7 when it lands. If the EMS web interface answers to anything outside your office or VPN subnets, ACL it down to those today and while that should have been the case in 2023, fix it now. Then pull the EMS auth log and look for admin accounts or API tokens created since March 31. On 7.4.4? You have the sibling bug (CVE-2026-21643), same urgency, same window.
Fortinet PSIRT advisory
CVE-2026-34621 in Adobe Acrobat Reader, exploited in the wild since December
Patch Acrobat on every endpoint. This has been a live zero-day since December and you just didn't know.
Why it matters: A crafted PDF runs code on the endpoint. Adobe patched it yesterday. The exploit's been in the wild since December. Four months where Acrobat was quietly shipping a zero-day and nobody knew except the people using it. Every SMB has Acrobat. Every SMB's users open PDFs from strangers with subject lines like 'Invoice_Q1_FINAL.pdf.' You know how this ends.
What to do: Push the update through your RMM today. If you're on Kaseya, NinjaOne, or Datto, the patch is already in the catalog so just approve it and send it. If you're still doing Acrobat updates by hand across fifteen endpoints on a Sunday, the patch is half the problem and we should talk about the other half separately. As a stopgap for anything still unpatched: set Protected View to 'All files' in Preferences > Security (Enhanced). And drop in a detection method if you have the capability, if acrobat.exe or acrord32.exe ever spawns cmd, powershell, or wscript, that is not a false positive. Alternatively, Microsoft provided ASR rules cover this pattern.
Adobe Acrobat security bulletin
Chrome CVE-2026-5281 and CVE-2026-5289, both actively exploited, CISA deadline April 15
Force-relaunch Chrome to 146.0.7680.178 fleet-wide. Federal deadline is tomorrow. Actively exploited. You're out of runway.
Why it matters: Two use-after-free bugs, both under active exploitation. 5289 is a full sandbox escape, which means a user visits a bad page and the attacker owns the endpoint — no click, no download, no warning. Here's the uncomfortable part: Chrome updates on relaunch, and half your users haven't relaunched Chrome since February. The fix has been sitting there for — what, almost two weeks now? — ready, ignored. If your security posture leans on 'Chrome auto-updates, we're fine,' this is your reminder that auto-update is a promise, not a control.
What to do: Push 146.0.7680.178 through whatever manages your browsers: Intune, GPO, Chrome Browser Cloud Management, or Workspace. Set RelaunchNotification to 'Required' with a 24-hour window so the user physically cannot keep dismissing the prompt. Same story for Edge, Brave, Opera, and Vivaldi since these are all Chromium, all shipped fixes, and all waiting on a relaunch. If any of your users run Chrome as a local admin, fix that today too.
Chrome Releases blog

This week

EvilTokens / Microsoft device-code phishing campaign bypassing MFA at scale
Block device code flow in Conditional Access this week. Your MFA will not save you from this one.
Why it matters: The attack doesn't steal a password. It doesn't fake a login page. It asks the user to type a code on the real microsoft.com/devicelogin, the actual Microsoft domain, and in doing so authorizes the attacker's session. MFA fires, the user approves it (it's Microsoft!), and the token lands in a criminal's hands. Once in, attackers register persistent devices inside ten minutes and set inbox rules to forward anything with 'payroll' or 'invoice' in the subject. The reason this works in SMB tenants specifically: device code flow is on by default, almost nobody uses it legitimately, and very few are actually turning it off.
What to do: Block device code flow tenant-wide in Conditional Access. Policy: Users = All, Cloud apps = All, Conditions > Authentication flows > Block device code flow. Pilot on a small group for 24 hours in case you have one weird IoT or kiosk scenario (you probably don't), then enforce everywhere. While you're in the tenant: filter Entra sign-in logs to authenticationProtocol = deviceCode for the last 30 days. If anything listed the results that isn't quickly explainable, or a legitimate flow, you have an incident. Then check Enterprise Applications for OAuth apps consented since March 1 that you don't recognize. Revoke, block, write down what you found, and sleep slightly better.
Microsoft Learn: block device code flow
Microsoft Patch Tuesday drops Tuesday April 14, so prep your rings now
Pilot ring this week, production by SLA. Do not skip the pilot.
Why it matters: Q1 averaged 85 CVEs a month with nine actively-exploited zero-days across the quarter, and the April forecast is 80-100+ including a Windows 11 24H2/25H2 critical. The cycle also keeps rolling the Secure Boot replacement certs (see the monthly item). The actual risk here isn't the patches themselves but the pattern since February: patch ships, patch breaks Outlook or Teams, SMBs hold off, SMBs forget. By the time April gets deployed in mid-May, May's cycle lands on top of it. This is how fleets end up three cycles behind and nobody is quite sure when it started.
What to do: Today: confirm the pilot ring actually exists and is healthy (yes, that is the hard part), and that the April maintenance window is on the calendar. Wednesday April 15: deploy to pilot, watch for Outlook-Classic and Teams add-in regressions. Microsoft flagged both in the pre-release notes, so at least you know where to look. Then on schedule: production, if pilot is clean. Do not skip the pilot. February broke things. March broke things. Nothing about April suggests it's the cycle that finally doesn't.
Microsoft Security Update Guide

Monthly or quarterly review

Secure Boot 2011 certificates expire June 26, 2026. Don't procrastinate, as that is only 75 days out
Inventory your fleet by OEM this month. Plan firmware deployment for May. Use June as your cleanup buffer, not the initial deployment runway.
Why it matters: Nobody's telling you about this yet because it doesn't cause pain until June, and security news doesn't do June in April. The short version: the Secure Boot root certs Microsoft issued in 2011 expire June 26. Windows Update is shipping the replacements, which handles the easy half. The other half is OEM firmware updates across all of your hardware providers. Each of those vendors has their own portal, their own update tool, and their own opinions about what still qualifies for support. The portal logins alone will eat a day. This is the exact kind of thing that's easy in April and a disaster in late June.
What to do: At your next tenant/fleet review (you know, on the quarterly calendar) and if you don't have one scheduled, schedule one and pull the Secure Boot readiness report (Microsoft's playbook is linked below). Inventory devices by OEM and model. For each OEM, find the current firmware advisory and flag any device that hasn't taken February through April's Windows cumulative updates plus the matching firmware update. Plan the firmware push for May. If any device on the list is out of OEM support, that's a replacement conversation, not a patch conversation. Better to have that conversation now than on June 25.
Microsoft Secure Boot certificate playbook

The Postinstall Dispatch

Dispatch 001: The first dispatch: A Fortinet EMS advisory, an Acrobat zero-day, and a Looming Secure Boot deadline

Patch today

CVE-2026-35616 + CVE-2026-21643 in Fortinet FortiClient EMS, both actively exploited

CVE-2026-34621 in Adobe Acrobat Reader, exploited in the wild since December

Chrome CVE-2026-5281 and CVE-2026-5289, both actively exploited, CISA deadline April 15

This week

EvilTokens / Microsoft device-code phishing campaign bypassing MFA at scale

Microsoft Patch Tuesday drops Tuesday April 14, so prep your rings now

Monthly or quarterly review

Secure Boot 2011 certificates expire June 26, 2026. Don't procrastinate, as that is only 75 days out