A few days ago I wrote about how the Trivy ecosystem got turned into a credential stealer. One of my takeaways was “pin by SHA.” Every supply chain security guide says it, I’ve said it, every subreddit says it, and the GitHub Actions hardening docs say it.

The Trivy attack proved it wrong, and I think we need to talk about why.

Here is a draft for a Reddit post tailored for the r/homelab community.

Title: [Project] Turning a Raspberry Pi into a "Poor Man's" Enterprise IDS/NSM using Zeek and Suricata

Hey everyone,

I’ve been looking for ways to get better visibility into my network traffic without dropping $500+ on dedicated hardware or running a power-hungry 1U server 24/7. I came across this guide from HookProbe that breaks down how to deploy Zeek and Suricata on a Raspberry Pi (specifically optimized for the Pi 4/5), and I thought it would be right up this sub's alley.

Link: Deploying Zeek and Suricata on Raspberry Pi for Edge Security

Why this is cool for a Homelab:

• The "Double Whammy": It uses Suricata for signature-based detection (finding the "known bad") and Zeek for high-level metadata/network analysis (the "context"). Usually, running both on a Pi would kill the CPU, but the post goes into some decent optimization tricks.
• Resource Management: It covers pinning network interface interrupts to specific cores and increasing ring buffer sizes so you don't drop packets when your 1Gbps fiber actually hits its peak.
• Edge Defense: Instead of just monitoring your "main" server, the idea is to place these at the "edge" (connected to a mirror/SPAN port on your switch) to see everything—IoT devices, guest Wi-Fi, etc.—before it even hits your core network.

The Setup: The guide walks through the /etc configurations for both tools. If you’re like me and love structured logs (DNS queries, SSL handshakes, HTTP headers) for your ELK stack or Grafana dashboards, Zeek is a goldmine.

Some questions for the community:

1. Is anyone else running Zeek/Suricata on ARM hardware? How are you handling the heat/throttling during heavy traffic?
2. Are you using a managed switch with a SPAN port, or are you using a hardware tap to feed the Pi?
3. For those using the Pi 5, have you noticed a significant jump in PPS (packets per second) handling compared to the Pi 4?

I’m planning to set this up this weekend to feed into my local SOC dashboard. If you're looking for a low-cost way to move past "just a basic firewall," this seems like a solid weekend project.

Curious to hear if anyone has tried a similar "Edge Security" approach!

Built a free red team arena for testing real attack paths against a live defense system for ShieldNet DLX7.

This is NOT a CTF or a static lab. It actually responds to what you do.

Current scenarios:

• prompt injection bypass
• DOM tamper (including honeytrap detection)
• JWT forging (alg confusion, role escalation)
• API exfil (debug routes, traversal)
• indirect injection (markdown, SVG, base64 payloads)

Everything runs in a sandbox. No production targets. Novel attacks generate detection rules that get reviewed and pushed into the system

If you want to test how your payloads actually hold up against modern defenses, this is useful.

https://www.shieldnet.app/red-team-arena.html

Mongoose network library <= 7.20

CVE-2026-5244 - mg_tls_recv_cert pubkey heap-based overflow (exploitable)
CVE-2026-5245 - mDNS Record stack-based overflow (exploitable)
CVE-2026-5246 - authorization bypass via P-384 Public Key (trivially exploitable)

Fun ride.

Researcher Yarden Porat (Cyata) disclosed a vulnerability chain in CrewAI, the widely-used Python multi-agent framework. CERT/CC advisory VU#221883. No full patch released yet.

The chain:

CVE-2026-2275 — Code Interpreter silently falls back to SandboxPython when Docker is unavailable. SandboxPython allows arbitrary C function calls → RCE.

CVE-2026-2287 — CrewAI does not continuously verify Docker availability during runtime. An attacker who triggers the fallback mid-execution lands in the vulnerable sandbox.

CVE-2026-2285 — JSON loader tool reads files without path validation. Arbitrary local file read.

CVE-2026-2286 — RAG search tools don't validate runtime URLs → SSRF to internal services and cloud metadata endpoints.

Attack entry point: prompt injection against any agent with Code Interpreter Tool enabled. The attacker doesn't need code execution access to the host — they just need to reach the agent with crafted input.

Scope: Any CrewAI deployment running Code Interpreter Tool where Docker is not guaranteed to be available (or can be disrupted). Default "unsafe mode" config is fully exposed.

Current status: CrewAI maintainers are working on mitigations (fail closed instead of fallback, block C modules, clearer warnings). Not released. No CVSSv3 scores published yet.

Has anyone tested whether the Docker availability check can be disrupted mid-execution in a containerized deployment, or does that attack path require an already-degraded environment?

Cisco reportedly suffered a breach of its internal development environment after attackers leveraged credentials stolen during the recent Trivy supply-chain compromise. More details linked with sample data

Questions regarding netsec and discussion related directly to netsec are welcome here, as is sharing tool links.

Rules & Guidelines

• Always maintain civil discourse. Be awesome to one another - moderator intervention will occur if necessary.
• Avoid NSFW content unless absolutely necessary. If used, mark it as being NSFW. If left unmarked, the comment will be removed entirely.
• If linking to classified content, mark it as such. If left unmarked, the comment will be removed entirely.
• Avoid use of memes. If you have something to say, say it with real words.
• All discussions and questions should directly relate to netsec.
• No tech support is to be requested or provided on r/netsec.

As always, the content & discussion guidelines should also be observed on r/netsec.

Feedback

Feedback and suggestions are welcome, but don't post it here. Please send it to the moderator inbox.

Writeup : https://github.com/califio/publications/blob/main/MADBugs/CVE-2026-4747/write-up.md

If you set LmCompatibilityLevel to 5 a couple years back and called it done, there's a good chance NTLMv1 is still running in your environment. Not because the setting doesn't work. Because it doesn't work the way you think it does.

This isn't just aimed at people who never fully switched to Kerberos. It's also for the ones who are pretty sure they did.

For people not deep into auth protocols: NTLMv1 and NTLMv2 are both considered unsafe today. NTLMv1 especially. It uses DES encryption, which with a weak password can be cracked in seconds. And because NTLM never sends your actual password (challenge-response, the hash gets passed not the plaintext), it's also wide open to pass-the-hash. An attacker intercepts the hash and reuses it to authenticate as you. Responder is the tool that makes this trivial and it's been around forever.Silverfort's research puts 64% of authentications in AD environments still on NTLM.

Here's the actual problem with the registry fix. LMCompatibilityLevel is supposed to tell your DCs to reject NTLMv1 traffic and require NTLMv2 or Kerberos instead. Sounds reasonable. But enforcement runs through the Netlogon Remote Protocol (MS-NRPC), the mechanism application servers use to forward auth requests to your domain controllers. There's a structure in that protocol called NETLOGON_LOGON_IDENTITY_INFO with a field called ParameterControl. That field contains a flag that can explicitly request NTLMv1, and your DC will honor it regardless of what Group Policy says.

The policy controls what Windows clients send. It has no authority over what applications request on the server side. Any third party or homegrown app that hasn't been audited can still be sending NTLMv1 traffic and you'd have no idea.

Silverfort built a POC to confirm this. They set the ParameterControl flag in a simulated misconfigured service and forced NTLMv1 authentications through a DC that was configured to block them. Worked. They reported it to Microsoft, Microsoft confirmed it but didn't classify it as a vulnerability. Their response was to announce full removal of NTLMv1 starting with Windows Server 2025 and Windows 11 24H2. So that's something, atleast.

If you're not on those versions, you're still exposed and there's no patch coming.

What you can do right now: turn on NTLM audit logging across your domain. Registry keys exist to capture all NTLM traffic so you can actually see what's authenticating how. From there, map every app using NTLM, whether primary or as a fallback, and look specifically for anything requesting NTLMv1 messages. That's your exposure.

The University of North Georgia is one of the lesser known of the nation's senior military colleges (SMCs). But last week it beat out all the other five SMCs—and two of the elite service academies—in a capture-the-flag hacker contest staged at the Pentagon's Cyber Workforce Summit.

The contest was designed by specialists from the Air Force Research Laboratory to be operationally realistic. In the first round, teams had to geo-locate a targeted individual through his devices and apps, prevent him from getting warning messages, and then call in an air strike to kill him.

More details and quotes from UNG students—plus the team from The Citadel they bested in the final—in my latest story.

Axios is one of the most used npm packages which just got hit by a supply chain attack. Malicious versions of Axios (1.14.1 and 0.30.4) hit the npm registry yesterday. They carry a malware dropper called plain-crypto-js@4.2.1. If you ran npm install in the last 24 hours, check your lockfile. Roll back to 1.14.0 and rotate every credential that was in your environment. Currently, as of now, npmjs has removed the compromised versions of axios package along with the malicious plain crypto js package. Live updates + info linked.