10 Nov 2026

SonicWall is warning customers about a new flaw in its SonicOS SSL-VPN devices. An attacker who holds credentials for an alternate authentication method can use it to get around SAML controls, potentially including MFA. CISA has added it to its Known Exploited Vulnerabilities list, and SonicWall has fixed six other flaws in the same release.

Plenty of firms have spent the last few years tightening identity on their applications while the edge appliance stays a box someone patches when they get round to it. That is the wrong way round. If the VPN accepts a weaker route in, every control behind it is working from a false assumption. MFA on the front door is only as strong as the side entrance.

The test is short. Can your team say, today, every remote access appliance you run, which firmware it is on and how many authentication methods it will accept? If the answer takes longer than an afternoon, you have an operational resilience gap as well as a patching backlog. Your important business services depend on that box, so treat a KEV listing as a change to make this week.

Between 14 and 26 October, an attacker used IAM credentials from Qubole's own AWS account to assume the cross-account roles customers had set up to trust the vendor. It harvested secrets, tested them against AWS, Entra ID and Okta, and downloaded entire S3 buckets. Most of the roles it used had seen no legitimate Qubole activity that month, and every request carried a valid External ID.

That last detail is the uncomfortable one. The customers did what the setup guide told them to do. The trust was configured correctly and simply outlived any need for it. Wiz's write-up says that pinning the trust policy to the vendor's own IP addresses would have blocked every attempt.

For a lender this is third-party risk in its most concrete form. Your supplier register probably lists data tools by contract, not by the access they still hold. Pull every cross-account role and service principal in your cloud estate, match each one to a live contract and a named owner, and remove anything idle for 90 days. If a supplier you stopped using two years ago can still read a customer data bucket, the due diligence file will not save you.

Microsoft's consumer email services have been rejecting legitimate messages after a change to how they enforce sender authentication. Users report SPF and DMARC failures, including from domains that appear to be compliant, and a Microsoft support moderator has acknowledged a service degradation. For senders that means intermittent delivery failures that are hard to diagnose.

Lenders now lean on email for the communications that matter most: arrears notices, statements, changes to terms and the notices the Consumer Credit Act requires. Hotmail and Outlook addresses are common in any consumer book. If those messages bounce for a week and nobody notices, the firm has a customer who was never told and a file that says they were.

Check two things this week. First, whether your email platform records hard bounces against the customer record and triggers a fallback, whether that is SMS, post or the app. Second, whether anyone watches bounce rates by recipient domain, because a spike at one provider disappears inside an overall delivery figure. When a complaint reaches the Financial Ombudsman, the question will be whether the customer received the notice, and a send log alone will not answer it.

Enterprises are getting ready for more traffic from personal AI agents such as Meta's Muse and Instinct, treating them as both a sales channel and a governance headache. Shopify, Hilton and Rocket are among the firms adapting their platforms and APIs to support AI-driven transactions. Volumes are still small, and executives are focused on authentication, compliance and keeping the direct relationship with the customer.

Rocket being on that list matters. A mortgage business is preparing for a customer's agent to turn up and start a credit journey on their behalf. UK point of sale finance will see the same thing: a customer asks their assistant for the cheapest way to pay for a heat pump, and the agent lands on a retailer's finance page.

The questions are practical. How do you know a person is behind the application, and that they understood what they agreed to? Who read the pre-contract information, and how would you evidence it? Most firms would block agent traffic as a bot today, which is fine while volumes are small. Decide now what an acceptable agent-assisted journey looks like, because retailers will ask before the regulator does.

PostHog uses small decision models to answer narrow questions with a typed output and a probability score before it calls a larger model. Its personal-data filter skips 98.7 per cent of LLM calls, and the thresholds are set according to what a false positive or a false negative actually costs.

This is the pattern regulated firms should copy. Many AI projects in financial services start with the biggest model and work backwards. For jobs like flagging possible vulnerability in a call note, spotting a complaint in an email or routing a document, a narrow classifier is cheaper, faster, easier to test and far easier to explain to a model risk committee.

The useful discipline is in the thresholds. Missing a vulnerable customer and wrongly flagging one carry very different costs, and that trade-off should be a written decision with a named owner rather than a default someone left in the code. Before your next AI build goes for approval, ask the team which questions could be answered by a model that returns yes, no and a confidence score. Keep the large model for the cases that are genuinely ambiguous.