r/netsec monthly discussion & tool thread

[u/albinowax]

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.

[u/Panda5151]

Rolling out corelight and integrating it with our elastic stack - big fans.

[u/Prestigious-Farm2346]

anyone tried that new tool for scanning open S3 buckets? been playing with it since last week and its pretty decent, catches misconfigurations i missed with the usual scanners. the UI is kinda clunky but the results are solid

[u/Unique-Quiet-4412]

Nice setup. Having one place for netsec questions and tools is pretty useful.

[u/Yaz_3ah]

I've been working on Aether, an open-source project exploring authorization enforcement for autonomous software agents.

The security question I'm trying to make testable is:

When an authorization request is denied, did the protected backend actually receive it?

A HTTP 403 alone isn't enough to answer that. I want to verify the authorization result against the backend's observed request count.

Aether currently has a 50-scenario Attack Lab covering identity, action scope, replay-related behavior, and revocation. I recently ran the corpus locally, and all 50 scenario subtests passed. These are creator-controlled results, not independent validation.

Repository: https://github.com/YabulHaj/Aether-Protocol

Challenge guide: https://github.com/YabulHaj/Aether-Protocol/blob/main/docs/BREAK_AETHER.md

The first experiment is:

go test -count=1 -v ./cmd -run '^TestAttackLabExtended$'

I'd particularly appreciate critical feedback on one question: Does the current test design convincingly establish that a denied request never reaches the protected backend, and what adversarial case would you test next?

The goal isn't to claim Aether is unbreakable. It's to make the authorization boundary reproducible and open to challenge.

[u/NoMost8645]

I built ssrf-lab, a local testing harness for SSRF defenses in Node.js HTTP clients: https://github.com/roshan-amble/ssrf-lab

The main distinction it tests is whether a security control actually refused a request or the request simply failed for another reason. It uses a response canary and an independent counter on the internal service. If that service received the request, a later client error cannot turn the result into a successful block.

The README starts with a reproducible comparison of three pinned packages across seven local address forms. In the recorded runs, ssrf-agent 1.0.5 reached the internal service through two forms. This reproduces a known address-classification weakness. Raw results and an adapter example for testing your own client are included.

It’s a testing harness, not a production protection library. DNS rebinding is simulated, and the full suite requires network isolation.

For people maintaining server-side URL fetchers: which SSRF regression cases are hardest to test reliably in your current setup?

[u/pezhik]

Disclosure: I wrote the scanner used here, SkillTotal (open source, Apache-2.0).

I scanned the 2026-08-16 snapshot of the official MCP registry. That covered 15,341 of 17,535 distinct components (87.5%), using SkillTotal 0.49.0 with rulesets 56 to 59. The analysis is deterministic regex and AST matching. Nothing was executed and no LLM was used.

The headline figures are about capabilities: 64.8% of components can reach the network, 21.1% can run shell commands and 7.4% run code at install time. A capability on its own adds zero to the risk score, and 15,225 of the 15,341 score low.

Coverage was 97.4% for npm, 97.2% for PyPI and 73.7% for git repos. 1,637 components were no longer reachable. A static scan can't see code fetched at run time or attacks that no rule describes. The write-up doesn't name any component.

Write-up: https://www.skilltotal.ai/mcp-registry-security-report Data: https://github.com/pezhik/skilltotal/blob/main/docs/mcp-registry-survey.json

If you find a wrong number, please say so.