Security this week was a reminder that the weakest link is often not your own code: a third-party provider, a data-sharing deal, or a firmware flaw under everything else.
1. Polymarket halted trading after hackers drained accounts
WIRED reports Polymarket halted international trading after hackers drained accounts. The company says an unnamed third-party provider was compromised, trading has resumed, and affected traders will be made whole.
Why it matters: A compromise at a provider can stop your service even if your own systems were not breached. Customers experience it as your outage and your loss of trust.
What to do next: List the third parties that can halt or expose your service, and check what their incident notice and recovery promises actually are — before an incident, not during one.
Based on reporting by WIRED: https://www.wired.com/story/polymarket-flagship-platform-hack-traders-lose-money/
2. GM pays $220 million over selling drivers’ data
General Motors has agreed to pay $220 million to settle claims it sold driving and location information to data brokers. TechCrunch reports that, as part of the settlement, GM must get drivers’ express consent before it collects or shares their driving and location data. The Verge reports the agreement resolves a complaint from a coalition of 36 US attorneys general.
Why it matters: Data collected for one purpose — running a vehicle, for example — can become a liability when it is shared onward. Consent and limits on sharing are now a settlement term, not just a privacy policy line.
What to do next: Audit what location and behaviour data your products collect, who receives it, and whether you have clear consent for that sharing. Remove sharing you cannot explain.
Based on reporting by TechCrunch: https://techcrunch.com/2026/10/29/gm-reaches-220m-settlement-over-selling-drivers-private-data/ and The Verge: https://www.theverge.com/transportation/1022555/gm-data-privacy-attorneys-general-lawsuit
3. Most servers are vulnerable to a UEFI firmware flaw, WIRED reports
WIRED reports a critical code-execution flaw in UEFI firmware, tracked as CVE-2026-97631, with a severity rating of 9.5 out of 10. The flaw is a memory-corruption bug in the ICMP parser of the EDK2 network stack — a 16-year-old buffer overflow in the PXE-Base Code driver (NetworkPkg/UefiPxeBcDxe) of TianoCore EDK II, the open-source codebase virtually all server vendors and cloud providers use to build UEFI firmware.
Discovered by Alex Matrosov of Anthropic and Dan Holmes of Google, the flaw lets an attacker with low-level network access send a malicious ICMP error message during the PXE network-boot sequence — deliverable by unicast from any network distance — and run code before the Secure Boot chain of trust is established. That early execution can even break disk encryption. While the initial payload does not persist across reboots, it opens the door to installing payloads that run early in every boot.
A fix exists — WIRED notes this flaw can be corrected with a basic code fix, and patch code is already public after AMI posted a pull request detailing the vulnerability — but rolling firmware updates out across thousands of hardware makers and cloud providers is slow. Intel says none of its commercial products currently under security support are affected; Arm says the CVE is not directly applicable to its firmware, though its firmware borrows heavily from EDK2.
Why it matters: Firmware sits below the operating system, so one flaw can affect a huge range of servers at once — and firmware is easy to overlook in a normal patch cycle. It applies only to organisations with machines that boot from the local network, not to devices that boot solely from disk.
What to do next: Check with your firmware maker about CVE-2026-97631, consider temporarily turning off network boot where possible, and make sure firmware versions are in your regular patch and inventory process.
Based on reporting by WIRED: https://www.wired.com/story/most-servers-on-the-planet-are-vulnerable-to-a-code-execution-flaw-in-uefi-firmware/
4. A personal AI agent ran on a secure Pentagon network for two months
WIRED reports sources say an Accenture employee’s personal Claude agent ran on a Department of Defense network for two months before it was identified and the vulnerability could be patched. A defence contractor, in WIRED’s headline, had given their personal AI agent access to a secure Pentagon system.
Why it matters: This is the agent-identity problem from the AI post, with security consequences. A personal tool connected to a secure network can bypass the controls built for approved software.
What to do next: Block or explicitly approve personal AI agents on secure and work networks, and make sure network monitoring can spot an unfamiliar agent connection — not just an unfamiliar login.
Based on reporting by WIRED: https://www.wired.com/story/a-defense-contractor-gave-their-personal-ai-agent-access-to-a-secure-pentagon-system/
Bottom line
This week, check three things: your third-party exposure, your data-sharing consent, and whether personal AI tools can reach secure systems. Those are governance jobs, and they are cheaper than a settlement or a halted service.
