There are reports of OVHcloud-related data being posted on a forum for sale. No official confirmation so far from OVHCloud. Given OVH’s scale, potential impact could be significant depending on scope, especially in Europe
UPDATE: OVHcloud CEO, Octave Klaba has commented that the sample dataset was not found in their system.
Watching OpenClaw do its thing must be like watching the first plane take flight. It's a bit rickety and stuck together with a lot of sticky tape, but squint and you can see the potential for agentic AI to change the world as we know it. And I don't think that's hyperbolic. A lot of what people claim to have done with it is hyperbolic, and as with all new tech, the challenge is to cut through the noise and find the value. Stay tuned for more on that, as I've already found some really useful applications for it to help me do my job better, which I think I should devote my next weekly vid to just that.
Most AI security testing focuses on the model: prompt injection, jailbreaking, and output filtering.
We've been working on something different: testing the agent *system*. The protocols, integrations, and decision paths that determine what agents do in production. The result is a framework with 209 tests covering 4 wire protocols:
**MCP (Model Context Protocol)** Tool invocation security: auth, injection, data leakage, tool abuse, scope creep
**A2A (Agent-to-Agent)** Inter-agent communication: message integrity, impersonation, privilege escalation
**L402 (Lightning)** Bitcoin-based agent payments: payment flow integrity, double-spend, authorization bypass
**x402 (USDC/Stablecoin)** Fiat-equivalent agent payments: transaction limits, approval flows, compliance
Every test maps to a specific OWASP ASI (Agentic Security Initiatives) Top 10 category. Cross-referenced with NIST AI 800-2 categories for compliance reporting.
```
pip install agent-security-harness
```
20+ enterprise platform adapters included (Salesforce, ServiceNow, Workday, etc.).
MIT license. Feedback welcome. Especially from anyone running multi-agent systems in production. What attack vectors are we missing?
SnappyClient is a malware found by Zscaler that uses a custom binary protocol (encrypted and compressed) to communicate with its C&C server, with little to work with when it comes to network detection.
At Netomize, we set out to write a detection rule targeting the encrypted message packet by leveraging the unique features of PacketSmith + Yara-X detection module, and the result is documented in this blog post.
Schneider Electric has addressed two vulnerabilities disclosed by Team82 in its Modicon Controllers M241 / M251, and M262 PLC line. The vulnerabilities can allow an attacker to cause a denial-of-service condition that affects the availability of the controller.
Read more on our Disclosure Dashboard: http://claroty.com/team82/disclosure-dashboard
Or download SE's advisory: https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2026-069-01&p_enDocType=Security+and+Safety+Notice&p_File_Name=SEVD-2026-069-01.pdf
Login**Submission URL** : https://arxiv.org/abs/2603.16572 **Repository hijacking** — Skills.sh and SkillsDirectory index agent skills by pointing to GitHub repository URLs rather than hosting files directly. When an original repository owner renames their GitHub account, the previous username becomes available. An adversary who claims that username and recreates the repository intercepts all future skill downloads. The authors found 121 skills forwarding to 7 vulnerable repositories. The most-downloaded hijackable skill had 2,032 downloads. **Scanner disagreement** — The paper tested 5 scanners against 238,180 unique skills from 4 marketplaces. Fail rates ranged from 3.79% (Snyk on Skills.sh) to 41.93% (OpenClaw scanner on ClawHub). Cross-scanner consensus was negligible: only 33 of 27,111 skills (0.12%) flagged by all five. When repository-context re-scoring was applied to the 2,887 scanner-flagged skills, only 0.52% remained in malicious-flagged repositories. **Live credentials** — A TruffleHog scan found 12 functioning API credentials (NVIDIA, ElevenLabs, Gemini, MongoDB, and others) embedded across the corpus. **What to do:** - Pin skills to specific commit hashes, not mutable branch heads - Monitor for repository ownership changes on skills already deployed - Require at minimum two independent scanners to flag a skill before treating as confirmed - Prefer direct-hosting marketplaces (ClawHub's model) over link-out distribution The repository hijacking vector is real and responsibly disclosed. The link-out distribution model is an architectural weakness — no patch resolves it. We wrote a practitioner-focused analysis covering this and 6 other papers from this week at 
CVE-2026-33068 is a configuration loading order defect in Anthropic's Claude Code CLI tool (versions prior to 2.1.53). A malicious `.claude/settings.json` file in a repository can bypass the workspace trust confirmation dialog by exploiting the order in which settings are resolved. The mechanism: Claude Code supports a `bypassPermissions` field in settings files. This is a legitimate, documented feature intended for trusted workspaces. The vulnerability is that repository-level settings ( `.claude/settings.json` ) are loaded and resolved before the workspace trust dialog is presented to the user. A malicious repository can include a settings file with `bypassPermissions` entries, and those permissions are applied before the user has an opportunity to review and approve the workspace. This is CWE-807: Reliance on Untrusted Inputs in a Security Decision. The trust decision (whether to grant elevated permissions) depends on inputs from the entity being evaluated (the repository). The security boundary between "untrusted repository" and "trusted workspace" is bridged by the settings loading order. The fix in Claude Code 2.1.53 changes the loading order so that the trust dialog is presented before repository-level settings are resolved. Worth noting: `bypassPermissions` is not a hidden feature or a misconfiguration. It is documented and useful for legitimate workflows. The bug is purely in the loading order. found this during a routine supply chain audit of our own codebase. the part that concerns us most is the false patch problem - anyone who responded to CVE-2025-58367 last year updated the restricted unpickler and considered that attack surface closed. it wasn't. if you're running the likes of SageMaker, DataHub, or acryl-datahub and haven't pinned to 8.6.2 yet, worth checking now.
In the beginning, it was simple. A website, a database and 150M+ email addresses to search. Time has added serverless functions (which run on servers 🤷♂️), code on the edge, new data storage constructs and a completely different mechanism for even just querying a simple email address. HIBP is a continually evolving beast, and barely a week goes by that we don't implement code of significance. You don't always see it out there in the public realm, but the tweaks - in including the major one I talk about in this week's video - all add up to make the platform faster, more sustainable and if we do it right, even a bit more cost-effective to run 😊
Since starting HIBP a dozen and a bit years ago, I've loaded an average of one breach every 4.7 days. That's 959 of them to date, but last week it was five in only two days. That's a few weeks' worth of breaches in only 48 and a half hours. And that's the way it tends to be in this industry: flurries of activity followed by periods of silence. I obviously don't have any control over the cadence of breaches (nor when they begin circulating), which does make for some interesting scheduling challenges. Somewhere amongst responding to those incidents, we manage to do all the other mechanical things required to keep this service running the way it does. Anyway, this week it's "breachapalooza", with some behind-the-scenes info on the Odido, KomikoAI, Quitbro, Lovora and Provecho.
The Odido breach leaks were towards the beginning during this week's update. I recorded it the day after the second dump of data had hit, with a third dump coming a few hours later, and a final dump of everything the day after that. From what I hear, it dominated the news in the Netherlands, and we sure saw that through the traffic stats. Clearly, the leak cadence was designed for maximum news impact, and it seems to have achieved that. It may not have put any cash in the extortionist's pockets, but it's set a very visible precedent and, I suspect, put a massive law enforcement target on them. It's hard to image leaks of this impact continuing for much longer...
