Monday, October 26, 2026. Sales Engineer Briefing. Three customer conversations: Tailscale SSH, PHP patching, and stolen Microsoft 365 sessions. If a customer uses Tailscale’s built-in SSH, start there.
The weekend Tailscale report describes a path from one compromised device to administrator access under specific settings. PHP remains an urgent patch check, with attackers recorded gaining command access on decoy servers. And Huntress’s Microsoft 365 findings explain why a password reset may leave an attacker’s access routes behind.
Item one. Tailscale SSH: check which feature your customer uses. Tailscale connects devices into a private network. Its built-in SSH feature provides remote server access using Tailscale’s identity and access rules. That distinction matters before you start talking about the vulnerability.
The weekend Tailworm report describes lab tests in which an attacker already controlling an allowed device used SSH forwarding to reach privileged resources on another server. The reported consequence is full administrator access. How far that could go depends on which targets the access rules permit and what those servers can reach. The tested versions were Tailscale 1.104.2 and headscale 0.29.5; that is a test boundary, not a complete affected-version list.
Ask first: does the customer use built-in Tailscale SSH, and is forwarding enabled? Then ask which devices can reach sensitive servers. The report says headscale 0.29.5 lacks the hosted service’s per-rule forwarding controls, so those SSH grants deserve especially careful review. Narrow access grants and restricting forwarding where supported can reduce the reported path. They aren’t a confirmed software fix. Tailscale says it is investigating and hasn’t recommended everyone disable SSH. This is serious lab research, not evidence that customer networks have been attacked.
If this is your customer’s setup, read the report and vendor response before the call. A networking label alone doesn’t establish which sessions are allowed or what a product will block.
Item two. PHP: ask whether the fix is running. PHP is the engine processing web requests behind many sites and applications. Customers may have it in containers or bundled products, so asking only whether they develop in PHP can miss it.
Two critical memory-handling flaws can let someone who hasn’t signed in run code through a web request. PHP says web-serving installations are in scope, with Apache’s mod_php at highest risk. That could put the web service and information it can reach under attacker control, within the service’s permissions. Over the weekend, researcher-operated decoy servers recorded attackers successfully launching command shells on three honeypots. That is observed exploitation on those exposed systems; it doesn’t tell us how many customers are compromised.
Your useful question is: which service is serving requests, and what proves its running workers have the fix? An updated package or a successful deployment job isn’t that proof. Vendor backports can also make a version number misleading. The fixed upstream releases and original guidance are linked below. For bundled appliances, use the manufacturer’s exact product and software scope.
Keep this as a follow-up from last week, not a fresh announcement of the same flaws. Patching removes the vulnerable code. It doesn’t establish that an earlier intrusion never happened.
Item three. Microsoft 365: a password reset isn’t the whole conversation. A session token is the pass issued after a successful sign-in. Attackers can capture that pass through a phishing relay, even while the person completes the real multifactor prompt, then reuse it.
Huntress’s October 22 report describes incidents at 79 organizations it investigated, during July through September. Those are its observed cases, not a count of every affected Microsoft customer. It found attacker-added devices and authentication methods, plus mailbox rules hiding communications. Those changes can preserve access or conceal fraud after the original session is gone.
Ask your customer’s identity team what they checked beyond the password. Huntress calls for session revocation and a password reset, plus removal of unauthorized devices and authentication methods. Mailbox rules deserve review too. These are separate cleanup jobs because changing a password doesn’t remove everything an attacker added.
For identity or SIEM conversations, this is worth reading before the call: what logs cover those changes, and what shows the customer’s policies actually operate? Huntress reports Conditional Access helped in its observed cases. That doesn’t establish how a particular customer is configured. Sell the evidence you can show.
