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?

Breach occurred at Navia Benefit Solutions, a 3rd party, not HackerOne infra.

Around 287 HackerOne employees PII leaked.

Navia delayed breach notifications by weeks. Filed at Maine AG.

Navia was independently breached. Over 10K US employee's PII exposed.

Reports point to an auth flaw (BOLA-type) enabling access to employee PII (SSNs, DoB, addresses, benefits data).

Exposure window: Dec 2025 to Jan 2026.

Root cause: EspoCRM's formula engine operates outside the field-level restriction layer — fields marked readOnly (like Attachment.sourceId) are writable through it. sourceId is concatenated directly into a file path in getFilePath() with no sanitization. Chain: modify sourceId via formula → upload webshell via chunked upload → poison .htaccess → RCE as www-data. Six requests, admin credentials required. Coordinated disclosure — patched in 9.3.4.

I’ve written a long-form analysis on how age-verification laws are pushing identity into internet infrastructure (OS layers, app stores, identity credentials), rather than staying at the application/content layer.

It looks at how enforcement is moving “down the stack”, with governments increasingly targeting platform chokepoints like Apple/Google and device-level controls.

The piece draws on UK identity history, US telecoms, and current global regulation.

Curious how people here think this holds up technically, especially around enforcement, bypass (VPNs, forks, sideloading), and where this creates new attack surfaces.

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?