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.

This new report is kind of a wake-up call. KnowBe4 says 86 percent of phishing attacks are now AI-driven, and it shows. It is not just email anymore either. Attackers are hitting Teams, calendar invites, and basically any tool people trust at work. The scary part is how convincing this stuff is getting, especially with internal impersonation and multi-channel setups. At some point, it feels like companies may need AI defending them just to keep up, because humans alone are going to have a harder time spotting this.

This new Linux kernel bug called Copy Fail (CVE-2026-31431) is kinda terrifying because it’s not complicated at all. A normal user can run a tiny 732-byte script and get root, no race conditions or luck required, and it works across major distros like Ubuntu, RHEL, and SUSE. The exploit quietly modifies the page cache instead of the file on disk, so integrity checks don’t catch it, but the kernel still executes the tampered version in memory.

Even worse, since the page cache is shared, it can potentially cross container boundaries too. Patch ASAP if your distro hasn’t already, because this one feels way too reliable…

As we commonly know in appsec, not every vulnerability, even if critical 10 is relevant. This is a take from my buddy Brian Vermeer at Snyk, he's a Java Champion and offers his opinion as a developer to the Thymeleaf vulnerability CVE-2026-40478

With everything that's happened recently, the Axios npm account hijack, LiteLLM getting poisoned on PyPI, and that coordinated npm/PyPI/Docker Hub campaign in April, I finally stopped manually running npm audit and set up something proper.

Been running Dependency-Track for a few weeks now. It's an OWASP open source project that works differently from the usual scanners, you upload an SBOM for each project and it continuously monitors against NVD, OSS Index, GitHub Advisories, and more. New CVE drops affecting your stack? You get notified without doing anything.

Wrote up how I set it up on Hetzner with Docker, Traefik for HTTPS, and GitHub Actions to auto-generate and upload SBOMs on every push

Summary: I’m disclosing a full-chain CVSS 10.0 RCE affecting Microsoft Semantic Kernel (.NET v1.74) and the new Agent Framework 1.0.

The Timeline & Conflict: > * March 24: Initial disclosure sent to MSRC with PoC.

• April 8: MSRC closed the case as "Developer Error / Configuration Issue."
• The Reality: Despite the rejection, Microsoft silently merged mitigations in PRs #13683 and #13702 without assigning a CVE. This results in a "False Green" for enterprise SCA tools (Snyk/Checkmarx/Dependabot) while the bypasses remain functional.

Technical Scope:

• Architectural Trust Gap (CWE-1039): Auto-invocation logic treats non-deterministic LLM output as a high-privilege system coordinator without a sandbox boundary.
• 6 Day-Zero Bypasses: Discovery of Type Confusion and Unicode homoglyphs that defeat the "hardened" baseline in the April 2026 releases.
• Versioning: Persistence confirmed from .NET v1.7x through the Agent Framework 1.0 re-baseline.

Full paper, .cast exploit recordings, and a production-ready C# remediation filter are available at the link.

The core issue: Windows RPC runtime doesn't verify whether the server a high-privileged client connects to is legitimate. If a target RPC server is unavailable, an attacker with SeImpersonatePrivilege can spin up a fake RPC server mimicking the same endpoint, wait for a SYSTEM-level client to connect, then call RpcImpersonateClient to escalate privileges.

Five confirmed escalation paths:

- gpupdate /force → SYSTEM (coerces Group Policy service)

- Microsoft Edge launch → Administrator (no coercion needed)

- WDI background service → SYSTEM (fires every 5–15 min automatically)

- ipconfig + disabled DHCP → Administrator

- w32tm.exe → Administrator via non-existent named pipe

Microsoft assessed this as moderate severity, issued no CVE, and has no patch planned — justification being that SeImpersonatePrivilege is a prerequisite.

Questions for the community:

1. Are you monitoring for RPC_S_SERVER_UNAVAILABLE (Event ID 1 via ETW) in your environment?

2. Any Sigma/Defender rules already written for this?

3. Do you agree with Microsoft's severity assessment given how common SeImpersonatePrivilege is on IIS/SQL servers?

Kaspersky's full write-up + PoC: https://securelist.com/phantomrpc-rpc-vulnerability/119428/

[ Removed by Reddit on account of violating the content policy. ]

Fuzzing is a common technique to detect faults.

In the case of REST APIs, common types of faults are HTTP 500 server error responses, and mismatches with what declared in the OpenAPI specifications.

However, there are several types of security properties that can be automatically checked as well, even when there is no formal specification of the access policy of the API. For example, what if a PUT/PATCH is denied (403), but then a DELETE is accepted (2xx)?

The linked article on arXiv shows a series of experiments on more than 50 APIs using 9 different kinds of security "oracle" checks. Those are implemented in the open-source fuzzer EvoMaster.

We have been toying with evading EDRs at Vulnetic with moderate success, so this time we wanted to put it against an in-house AI SOC. The idea is that the defense gets streamed logs on the network and can make decisions like quarantining or blocking potential attackers while also sifting through logs being streamed. This was with the last gen Anthropic models, so we will be redoing these tests with the newest gen from OpenAI and Anthropic shortly as in initial testing they seem to be 15-20% better already.

I think defense is lagging behind offense and there will be a come to Jesus moment where open weight models in a decent harness can evade modern SIEMs / detection mechanisms and when that happens there will be a problem. With regards to AI, it comes down to proper access control and so the fundamentals of networking and defense in depth will be vital in the future to fight against these AI threats. Happy to answer any questions and always looking for cool experiments to try!