Wednesday, October 28, 2026. Your Sales Engineer Briefing: four customer updates. Brotli is listed as exploited, Synology expands PHP patches, Tailscale fixes are available, and Microsoft sign-ins can be abused.
Storage customers have a specific PHP update today. Network and application teams are tracing Brotli dependencies. Tailscale users can move to verifying the fix. And a Microsoft phishing report explains why a genuine login page can still lead to an account takeover.
Item one. Continuing PHP: storage customers have an update. For storage conversations, today's useful change is Synology's expanded patch coverage. Its network storage systems can run PHP-dependent applications. These PHP flaws can execute attacker code in affected packages; the update closes that path. The October 28 update adds fixes for older DSM 7.1 and 7.0 systems; DSM 6.2 is scheduled for tomorrow. A planned patch is still a planned patch.
The scope matters: certain installed packages are affected. Synology says Synology Drive is unaffected, and its advisory also lists Hyper Backup as unaffected. An installed PHP package and a vulnerable public service are different findings. Storage customers may be sorting out package inventory and update availability, rather than replacing the NAS.
For network security customers, Dream's October 26 report describes PHP code execution chained with a Linux privilege flaw against firewall management software. It reports 25 rooted servers and a persistent route into an internal identity environment, including stolen directory-service credentials. The vendor and affected versions are withheld. That's a reason to follow the customer's actual vendor advisory, not guess which firewall was attacked. Your customer may be handling both appliance remediation and an investigation into access beyond it.
Item two. Continuing Brotli: follow the dependency. This is the compressed-data flaw also called Node2Shell. Brotli expands compressed web data; malformed input can corrupt a vulnerable decoder and potentially execute code. CISA listed it as exploited yesterday. The name undersells the reach: it extends beyond Node.js applications to other products containing the library.
For application customers, identify which deployed runtimes and dependencies actually process untrusted Brotli data. For network customers, Palo Alto's advisory has specific PAN-OS branches and mitigations. Exposure requires both Brotli inspection and TLS decryption on the traffic-processing side. It lists 11.1 and 10.2 as unaffected and reports no known malicious exploitation of its products. That product assessment is separate from Dream's unnamed-firewall report.
A customer may need a software update or a change to inspection settings. Those have different operational consequences. A generic claim that your product blocks the CVE won't settle either one. The vendor's current product and configuration assessment is the useful starting point.
Item three. Continuing Tailscale: the fix has shipped. Tailscale's private-network tool includes its own SSH server. The update since yesterday: version 1.104.4 fixes the reported SSH and Serve issues. The SSH bug could use the server's privileges to cross a user's intended access boundary. The SSH forwarding flaw required that built-in server and forwarding permissions; ordinary OpenSSH carried over the network is a different setup.
Serve also has fixes for Unix-socket backends and TLS setups with multiple mounts using different capabilities.
Customers using those features may now be coordinating upgrades and reviewing temporary restrictions. Keep the conversation there. Whether the affected nodes are running the fix matters more today than another tour of the original exploit.
Item four. Microsoft sign-ins: the page can be real. Yesterday, ANY.RUN published analysis of SkyW4lker, an existing phishing kit aimed at Microsoft 365 users. An invoice or document lure leads someone to enter an attacker-supplied code on Microsoft's real sign-in page. They complete authentication for the attacker's device, which receives account access tokens. Those are the credentials it can use afterward.
For customers, this is an email-workflow and identity-policy problem. Password theft isn't required. Microsoft's established guidance includes restricting device-code sign-ins where they aren't needed and revoking sessions when abuse is suspected. Don't promise that a successful MFA check, by itself, proves the account is safe. The useful distinction is who initiated the sign-in and what access was actually approved.
