Author here. DVRTC is our attempt to fill a gap that's been there for a while: web app security has DVWA and friends, but there's been nothing equivalent for VoIP and WebRTC attack techniques.

The first scenario (pbx1) deploys a full stack — Kamailio as the SIP proxy, Asterisk as the back-end PBX, rtpengine for media, coturn for TURN/STUN — with each component configured to exhibit specific vulnerable behaviors:

• Kamailio returns distinguishable responses for valid vs. invalid extensions (enumeration), logs User-Agent headers to MySQL without sanitisation (SQLi), and has a special handler that triggers digest auth leaks for extension 2000
• rtpengine is using default configuration, that enables RTP bleed (leaking media from other sessions) and RTP injection
• coturn uses hardcoded credentials and a permissive relay policy for the TURN abuse exercise
• Asterisk has extension 1000 with a weak password (1500) for online cracking

7 exercises with step-by-step instructions. There's also a live instance at pbx1.dvrtc.net if you want to try it without standing up your own.

Happy to answer questions.

In enterprise environments, identity effectively became the control plane once network perimeters broke down (e.g. zero trust, et cetera).

I’m seeing a similar pattern emerging on the public internet via age verification and safety regulation, but with identity moving closer to the access layer itself.

Not just: “Are you over 18?”

But: identity assertions are becoming part of how access is granted at the OS/device/app store level.

From a security perspective, this seems to introduce some new attack surfaces:

• high-value identity tokens at the OS/device level
• new trust boundaries between apps, OS, and third-party verifiers
• incentives to target device compromise or token reuse rather than account-level bypass
• potential centralisation of identity providers as enforcement points

Questions I’m trying to think through:

• Does this effectively make identity providers the new perimeter/control plane?
• How would you model this system (closer to DRM, identity federation, or something else?)
• What are the likely failure modes if this layer becomes centralised?
• Are decentralised / on-device credentials actually viable from a security standpoint, or do they just shift the attack surface?

Curious how people here would threat model this or where the obvious breakpoints are.

NTLM-Relaying has been proclaimed dead a number of times, signing requirements for SMB and LDAP make it nearly impossible to use captured NTLM authentications anymore. However, it is still possible to relay to many webservers that do not enforce Extended Protection for Authentication (not just ADCS / ESC8).

We pentested a web app built 100% with AI — no human-written code. Functional, clean, well-structured. But security-wise, we found critical issues on day one: LFI, IDOR, vulnerable dependencies, and more.

AI-generated code is not secure by default. And vibe coding moves fast enough that security gets skipped entirely.

Full writeup with technical details and recommendations: https://www.hackmosphere.fr/en/?p=3803

Anyone else seeing this pattern in AI-generated apps?

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.

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

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