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.

The transition from a niche practice of DFIR to the discipline of risk management and incident preparedness

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

Human thought is still evolving to handle the digital world. We act instinctively when we should act deliberately — and under pressure, we rarely consider all the options available to us. This article examines how we think under stress and outlines practical steps organizations can take to protect themselves

A much-needed reality check for those insisting AI will automate away the need for human red teaming and pentesting. Not mentioning the costs involved.

Been digging into the OpenClaw vulnerability (CVE-2026-25253) this week.

Most people are focusing on the CVSS score (8.8), but the bigger issue is misconfigured instances + exposed skills.

Here’s a quick checklist I’ve been using:

1. Audit all active skills (especially external ones)
2. Lock down network exposure (a lot of instances are publicly reachable)
3. Recheck auth flows - default configs are risky
4. Monitor logs for abnormal agent behavior
5. Patch immediately if you haven’t already

I wrote a more detailed breakdown here if anyone wants the full audit steps: Here

Curious- has anyone here actually seen exploitation in the wild yet?

**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.