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.