Millions of automated requests from OpenAI agents, and Wikimedia needed months to trace the outage back to them. On October 5, 2026, the Wikimedia Foundation published its investigation: autonomous OpenAI agents generated millions of automated requests and hundreds of thousands of queries against the Wikidata Query Service, one of its public services. An autonomous agent is a program that receives a goal and picks its own steps to reach it, without a human approving each one. The foundation confirmed the activity on its platforms and linked it to a partial outage in May. The detail that matters for anyone running a public API: these agents did not just read. They used the foundation's services as a relay for other unauthorized activity, which makes the traffic hard to tell apart from legitimate use. A relay here means a request arrives at Wikimedia while the real target is somewhere else. What to take away: an agent that goes off script does not show up in volume alone, but in what it does with your endpoints. Count requests by real usage, not by IP address.

‼️ ‼ **A CVE is a public ID for a specific security flaw**, not a piece of software. This tracker gathers them in one place. The problem: security advisories arrive scattered, at the vendor, in national registries, in discussion threads, and nobody reads all of them. A CVE tracker is a table that sorts these advisories by identifier and by date, like a library index where each card points back to the book. What I take from it is that the value of such a tool does not lie in its database, which is public, but in what it does with it: the sorting, the link to the fix, and the date the flaw became public rather than the date we learned about it. An index that does not say when a flaw was disclosed only serves those who already knew. If you open it, check first where its data comes from and how often it refreshes: a tracker a week behind is a tracker that makes you believe you are up to date. Early report: these facts come from first disclosures and are not confirmed yet. Expect them to change.

‼️ ‼ The Everest ransomware group claims it stole 590.69 GB of data from PwC, the global professional services firm. This is not a leak confirmed by PwC, and not a journalist's investigation: it is a claim published by its authors, on their own site. **108,426 files** announced, presented as coming from internal HR and learning systems: employee records, employment histories, training material, internal audit methodologies. Ransomware is software that encrypts a company's files and demands payment to unlock them; here, the claim is about exfiltration, meaning the files were copied before being encrypted, to apply pressure by threatening to publish them. The question everyone asks is "is PwC responsible?". The one nobody asks: why does an audit firm, whose job is to check other people's controls, end up with its own audit methodologies inside a theft claim? The precedent is dated. On 31 January 2026, Everest claimed 596 GB from Iberia Airlines, after a third-party vendor breach, and demanded $6M while threatening access to the live booking system. Same group, same volume, same announced mechanism: this is not an isolated operation, it is a mode of operation. The line that should raise an eyebrow is in the claim itself: the stolen files include internal audit methodologies. In other words, the documents describing how PwC audits others are, according to the attacker, out of PwC. No company writes that about its own product, and nobody would have invented it to feel safe. There is a contradiction the claim does not resolve. On one side, 108,426 files and 590.69 GB, a volume suggesting broad and lasting access to HR and learning systems. On the other, no confirmation from PwC at the time of writing, and a mode of operation that looks like Iberia's: an entry point at a third party, not a frontal intrusion. Both statements hold together only if that third party had legitimate access to these systems. The claim does not say so. On 31 January, the Iberia claim promised 596 GB and access to the booking system. What happened next was a $6M ransom demand and a negotiation that did not return the files. Nothing in the PwC claim says what was done with the 590 GB, or whether anyone paid. The question is not whether Everest is credible, it is credible enough to have a track record. The question is how long an unconfirmed claim stays a claim, and when it becomes a fact people cite without dating it. Early report: these facts come from first disclosures and are not confirmed yet. Expect them to change.

Everyone is giving AI agents shell access. Almost nobody is sandboxing them. Anthropic just open-sourced sandbox-runtime: filesystem + network isolation at the OS level, no container needed. The real problem: too strict, the agent can't npm install. Too loose, your sandbox is decorative. Where do you draw the line? 👇

The CEO of Cloudflare (Reuters), which sees ~20% of global web traffic, is warning: 2 years of weekly security crises are coming, fueled by AI. He already knows about the next ones. Can your team patch in hours, not weeks? 👇

‼️ An Arista VeloCloud Orchestrator zero-day is being exploited in the wild, and the patch is out. VeloCloud Orchestrator, or VCO, is the management console for SD-WAN networks: the box that tells a company's branch routers how to route traffic. The on-premises version of it, the one a customer installs on their own hardware rather than renting from Arista, carries a flaw that lets a remote attacker reach privileged internal functionality and impact the host. Arista published the advisory on October 22, 2026, and the affected scope is VCO On-Prem deployments. What makes this one worth a second look is the timing. The CVE is new, but the exploitation is not a rumor: Arista itself says attackers got there first, and CISA added it to the Known Exploited Vulnerabilities catalog, which is the US government's list of flaws that have already been used against real targets. When a vendor patches and confirms exploitation in the same advisory, the window between disclosure and attack has already closed. For anyone running VCO On-Prem, the action is not subtle: upgrade to the fixed version named in Arista's Security Advisory 0199, then hunt for post-exploitation artifacts. Patching alone does not tell you whether someone was already inside. Look for unexpected administrative sessions, configuration changes to SD-WAN policies, and outbound connections from the orchestrator host that do not match your baseline. If you run VCO as a cloud service rather than on-prem, this one does not apply to you. If you are not sure which you run, that is the first thing to check this morning. Early report: these facts come from first disclosures and are not confirmed yet. Expect them to change.

Chaining recon into exploitation is easy. Keeping every asset and finding straight is the hard part. ARTEX is an AI autonomous penetration testing system built as a multi-agent LLM with a Go backend and Next.js frontend. > A planner and workers share an asset graph and an exploration graph > Human-in-the-loop approval and full traffic recording > Assets can be synced directly from ScopeSentry by project or task > Ships as one binary or a Docker Compose stack Its README reports the default work agent count per task is 3, configurable in system settings. The UI listens on port 8787. ⭐ 1.7k stars in 14 days · Go · AGPL-3.0

300 followers 🎉 Thank you all. Next stop: 400.