We benchmarked Opus 4.6's ability to find simple C vulns and found that the model flags about 1 in 4 flaws -- with a very high false positive rate and lots of inconsistency from run to run. Techniques like judge agents and requiring the model to justify its results improve the results to some extent, but they're still not great.

I’ve been experimenting with Chrome DevTools Protocol primitives to build tools for reversing and debugging JavaScript at runtime.

The idea is to interact with execution by hooking functions without monkeypatching or modifying application code.

Conceptually, this is closer to a Frida-style instrumentation model (onEnter/onLeave handlers), but applied to the browser via CDP.

Early experiments include:

• attaching hooks to functions at runtime
• inspecting and modifying arguments and local variables
• overriding return values (unfortunately limited to sync functions due to CDP constraints)
• following return values to their consumer (best-effort / heuristic)
• conditional stepping (stepIn / stepOut / stepOver)

All implemented via CDP (debugger breakpoints + runtime evaluation), so this also works inside closures and non-exported code.

I’d really appreciate feedback — especially from people doing reverse engineering, bug bounty, or complex frontend debugging.

Nicholas Carlini (Anthropic research scientist) used Claude Code and a 12-line bash script to find hundreds of remotely exploitable Linux kernel vulnerabilities — including one introduced in 2003 and undiscovered for 23 years.
He's holding most of them unreported. His words: "I'm not going to send the Linux kernel maintainers potential slop."
The bottleneck isn't finding bugs anymore. It's validating them fast enough.
Here's the part that matters for defenders:
That validation constraint only binds researchers following responsible disclosure. An attacker running the identical script has zero validation requirement — they probe directly from unverified findings. The asymmetry is structural, not technical. It's baked into how responsible disclosure works.

And the framework was already failing before AI arrived:

• 32% of vulnerabilities exploited on or before CVE issuance
• Median exploitation window: 5.0 days (down from 8.5)
• AI can generate working CVE exploits in ~10 minutes at ~$1 per exploit
• 130+ new CVEs weaponised daily at scale

We ran this problem through four structured Crucible analysis passes and produced a white paper. The conclusion: responsible disclosure needs a named replacement framework — Post-Exploitation Response Coordination — which accepts that exploitation will happen before validation and rebuilds around detection, response, and recovery speed instead.

The full white paper is live at https://www.thecrucible.systems/whitepapers/f27bb2aa-8a5b-47d3-b3bf-b33effa7e20e

Curious what this community thinks — specifically on the asymmetry point. Is there a path to closing that gap or is it genuinely irreducible?

With Cloudflare now supporting PQC encryption, I thought it'd be a fun experiment to see if I could encapsulate Plex traffic in a tunnel since it's not supported natively. 🤓

A new investigation, dubbed BrowserGate, claims that LinkedIn (Microsoft) is quietly running hidden JavaScript on linkedin.com that probes users’ browsers for installed extensions - over 6,000 of them, all without consent and transmits that data back to LinkedIn & third parties. Researchers argue this isn’t just passive fingerprinting because users are logged in with real names, employers & roles, the data can be tied directly to identifiable people and used to infer sensitive info like job‑search status, political/religious interests, health‑related tools, or corporate tooling usage.

The report also highlights potential GDPR and privacy‑law issues, and the detections reportedly include both competitor tools and personal‑interest extensions. LinkedIn has not publicly refuted the core claim. More details with technical details, sources etc in the linked article.

Sharing the ShieldNet Trust Posture. Very good analytical data of the current CVE landscape across OWASP,NIST, NVD, Phishing, AI, Microsoft etc.

https://www.shieldnet.app/trust-dashboard.html

Built an automated npm package scanner that uses heuristic scoring + LLM analysis to flag malicious packages in real time. Ran it for 24 hours against ~2000 recent npm registry changes and found 21 malicious packages across 11 campaigns.

Four novel attack vectors documented:

1. LLM API MITM (T1557): makecoder@2.0.72 overwrites ~/.claude/ via postinstall, reconfigures Claude Code client to proxy all API calls through attacker server. Application-layer MITM on AI assistant conversations.

2. Encrypted skill distribution (T1027, T1105): skillvault@0.1.14 fetches encrypted payloads from private API, decrypts locally, installs as persistent Claude Code skills. Server-side swappable without npm update.

3. AI agent as RAT (T1219, T1036.005): keystonewm/tsunami-code ship functional coding assistant CLIs routing all interactions through attacker's ngrok tunnel. Exploits AI tool trust model where users grant full filesystem access voluntarily.

4. Redis CONFIG SET + raw disk read via postinstall (T1190, T1006): 6 fake Strapi plugins use Redis to write shell payloads to 7 directories, dd if=/dev/sda1 to extract credentials bypassing file permissions, Docker overlay traversal for container escape.

All IOCs, decoded payloads, and MITRE mappings on the site. None of the 21 packages were flagged by any public scanner at time of discovery.

My write up around a research project I've been doing in my spare time around investigating the security of AWS CodeConnections. This post covers the techniques I used to hook a CodeBuild job to monitor the requests the CodeBuild bootstrapping makes before user code is run. Using this information I then also show the endpoints I found that can be used to retrieve the raw GitHub App token or BitBucket JWT App token CodeConnections uses which tends to be very privileged in a lot of environments, granting far more access than to just the single repository where the CodeBuild job is being run.

CVE-2026-33579 is actively exploitable and hits hard.

What happened: The /pair approve command doesn't check who is approving. So someone with basic pairing access (the lowest permission tier) can approve themselves for admin. That's it. Full instance takeover, no secondary exploit needed. CVSS 8.6 HIGH.

Why this matters right now:

• Patch dropped March 29, NVD listing March 31. Two-day window for the vulns to spread before anyone saw it on NVD
• 135k+ OpenClaw instances are publicly exposed
• 63% of those run zero authentication. Meaning the "low privilege required" in the CVE = literally anyone on the internet can request pairing access and start the exploit chain

The attack is trivial:

1. Connect to an unauthenticated OpenClaw instance → get pairing access (no credentials needed)
2. Register a fake device asking for operator.admin scope
3. Approve your own request with /pair approve [request-id]
4. System grants admin because it never checks if you are authorized to grant admin
5. You now control the entire instance — all data, all connected services, all credentials

Takes maybe 30 seconds once you know the gap exists.

What you need to do:

1. Check your version: openclaw --version. If it's anything before 2026.3.28, stop what you're doing
2. Upgrade (one command: npm install openclaw@2026.3.28)
3. Run forensics if you've been running vulnerable versions:
   • List admin devices: openclaw devices list --format json and look for admins approved by pairing-only users
   • Check audit logs for /pair approve events in the last week
   • If registration and approval timestamps are seconds apart and approver isn't a known admin = you got hit

Let me know if you're interested, happy to share the link.