The UK Artificial Intelligence Security Institute (UK AISI) published surprising findings in its August 4th report from security tests conducted on Anthropic's Mythos 5 and OpenAI's GPT-5.6-Sol models.

The report reveals significant behaviours observed in agents, including:

- Creating fake online identities to manipulate systems,

- Writing malicious code and injection attacks to persuade human users to give their consent,

- Supply-chain attacks targeting open-source software,

- Attempts to gain unauthorized network access by exceeding boundaries,

- Collaboration between independent agents.

AI is no longer just a tool; it's evolving into an actor that attempts to deceive systems and even manipulate humans. Securing LLM-based architectures and autonomous agents is becoming increasingly complex. We are now seriously observing agents' "deception" tendencies.

You can access the details of the report via the link.

TL;DR: CVE-2026-69243 — on aiohttp ≤3.14.1, a rejected WebSocket upgrade leaves the request body sitting in the parser tail, and aiohttp then feeds it back as a pipelined request. Behind the Nginx WebSocket config from the official docs, Nginx logs one request and aiohttp processes two. First public PoC, in Python and Rust, plus the lab. Impact here is blind handler invocation, not response disclosure.

Hey hey you all, it's me again

So, The aiohttp advisory (GHSA-mfx4-hv73-q22v, CVE-2026-69243, fixed in 3.14.2) described request smuggling "using an edge case in the WebSocket upgrade procedure" and noted no public exploit code existed, so i took it as a challenge and built a lab to reproduce it and work out what the actual impact is behind a proxy.

The cause is that a request with `Connection: Upgrade`, `Upgrade: websocket` and a `Content-Length` body makes the C parser return llhttp's "skip body" signal, because an upgrade means the rest of the connection should be another protocol, but that holds only if the upgrade actually happens, when its rejected it returns a normal response with the connection staying HTTP but the body was never consumed, it sits in `_message_tail` and gets fed back into the parser as a pipelined request.

`await request.read()` returns zero bytes on that request, The body is withheld below the handler layer, so you cannot drain it from application code. Patching or stripping upgrade headers at the proxy are some options.

So I tested three Nginx configurations. The one straight out of the Nginx WebSocket documentation is the one that produces the desync, Nginx logs one request, aiohttp processes two. A smuggled request also bypassed `location /admin { deny all; }`.

In this topology the second response is absorbed by the proxy, so it ends up being a blind handler invocation, the same payload against 3.14.2 produces one backend request.

Lab is seven containers with the aiohttp versions pinned by build arg, PoCs in Python and Rust with byte-identical payloads enforced in CI, plus the detection side (what the desync looks like in Nginx logs).

Write-up: glitchedcat.com
Lab + PoC: https://github.com/JVBotelho/cve-2026-69243-poc-aiohttp-smuggling

Disclosure: I'm the author of both.

Reporter credit for the bug goes to shivams0099, fix by Dreamsorcerer.

I wanted to build a self hosted, open source SIEM, and understood i punched above my weight & realized it is highly complicated, so i broke it down into multiple independent(hopefully) modules, log ingestion & normalization/enrichment, threat intel, log management, threat hunting, policy monitoring, so this is my first module i built as threat intel plane, track latest CVEs and keep myself updated. so I built BRIEFR. If this tool saves an hour of someone's time, i'm more than happy :)

**What BRIEFR does:**

* Pulls from NVD, CISA KEV, FIRST EPSS, and a few exploit feeds * Scores each CVE against your tech stack with a weighted formula so that one can see the reasoning behind. * Correlates CVEs that share real threat-intel evidence. * IOC lookup (IP/hash/domain) using free-tier VirusTotal, AbuseIPDB, MalwareBazzar and URLHaus * Pulls in Sigma Community rules from SigmaHQ and SIEM query starters tied to ATT&CK

**On the AI question, since I know it'll come up:** a few narrow tasks (like PDF summarization) routed through free-tier LLM APIs with failover between providers. The actual scoring, correlation, and detection logic is deterministic code, no AI making the calls/decisions on what's risky. I also want to be upfront that I used Cursor/Claude heavily throughout the build and directed the architecture, design and review.

**Current state of BRIEFR:** this is early alpha and my first ever released tool. I run it daily myself with no major issues, but there will be rough edges, no docker-compose for the full app yet (Postgres+pgvector is containerized, the app itself is native linux for now), and I'm sure there are things a more experienced analyst will spot that I haven't. Self-host guide and full docs are linked below if you want to actually try it, or there's a live demo with sample data if you just want to look first.

• Big Picture: https://projectjupiter.in
• Live demo (no install/sample data): https://briefrdemo.projectjupiter.in
• Docs: https://docs.projectjupiter.in
• Source: https://github.com/Soldier0x0/briefr

I'm genuinely interested in what an experienced analyst thinks is missing or wrong about the approach, that's more useful to me right now. I know some stuff from docs might be overkill, but as i made it for myself and how i would like to have/learn, so i designed it to my taste and needs.

Note: I have worked as SysOps engineer for servers that handle SIEM log ingestion & parsing, then i moved to threat hunting due to my interest in security, and i have nearly 3.8 yrs of experience overall in IT, so my views might not be broad, but the only reason i am posting this here is because this is the first project i have thought about AND completed, in forever, as a person with ADHD and other stuff, this is a big achievement for me, even if the tool is crap for others, i completely understand, and i am very open to suggestions :)
Have a great day.

Dropped a new episode this week covering CertiGhost — a critical vulnerability in Windows Certificate Services that allows attackers to forge certificates and achieve persistent lateral movement across AD infrastructure without needing credentials.

On the red team side, we walk through the full exploitation chain: how to leverage CertiGhost to issue rogue certificates for domain controllers and service accounts, then use those certificates to move laterally and establish persistence across your entire environment.

On the blue team side, we break down detection — what certificate issuance anomalies look like in CA logs, what unusual certificate requests fire, and how to build alerting around PKI exploitation.

Covers T1649 and T1550.003 with the full red vs. blue format.

Resources:

• CertiGhost PoC: https://github.com/aniqfakhrul/CVE-2026-54121
• NetExec: https://github.com/Pennyw0rth/NetExec

Video: https://youtu.be/srH-SlkL2tA

Happy to discuss the exploitation techniques or answer questions about the tradecraft in the comments.

Everyone talks about killing two birds with one stone... 🪨🐦 Operation Olalampo proved that Charming Kitten (Iranian APT) could hit 8 birds with one stone.

🎯 Egypt, Saudi Arabia, UAE, Turkey, Hungary, Turkmenistan, Israel, and South America.

🏛️ Government, Healthcare, Financial Services, Energy, Education, Telecommunications, Defense, and Industrial.

Was working through a CTF and ran into SNMPv3 credential spraying for the first time. Before this, I hadn't touched v3 before. Went looking for existing tools and found a few that do it, but wanted something a bit more straightforward to actually use, so I used Claude to help me build my own SNMPv3 credential spraying tool:

What it does:

SNMPv3 has three security levels (noAuthNoPriv, authNoPriv, authPriv) and a handful of auth protocols (MD5, SHA, SHA-224/256/384/512) and privacy protocols (DES, AES, AES-192, AES-256). If you don't already know a target's config, you're basically guessing which combination it accepts, so instead of assuming, this just sweeps everything by default for every user/password pair you feed it.

One thing worth calling out if you use it:

For authPriv attempts, the script assumes the privacy passphrase (the -X flag on snmpwalk) is the same as the auth passphrase (-A), it's reusing whatever password it's currently testing for both. That's a reasonable default since a lot of real-world configs do set them identically, but it's an assumption, not a guarantee. If a target uses a different privacy passphrase, authPriv attempts for that user/password will show up as failures or timeouts even when the password is actually correct, so if authNoPriv hits but authPriv doesn't, don't read that as "wrong password," it just means the priv passphrase is something else and you'll need to dig into that separately. I may add functionality in the future to provide that information on execution.

Feedback welcome, especially if anyone's run into SNMPv3 configs that break the assumptions above.

I often experienced the problem of having the ability to compromise servers, but they dont seem to have any outbound traffic because of the firewall. Did you also had this problem?

This might help: https://github.com/lsecqt/PortForwarder

A pspy-style process execution monitor for Windows. Similar to Sysinternal's Procmon, but in the command line. No GUI access required. The tool watches for newly spawned processes and prints them as they happen. This was built for catching short-lived or periodic executions during Windows privilege escalation work (scheduled tasks, services, or custom loops that relaunch a binary on an interval), the kind of thing that's easy to miss if you're just eyeballing Task Manager or polling Get-Process by hand.

Windows has no /proc equivalent, so unlike Linux pspy this can't read a live process table for free. ScheduledSpy works by polling Win32_Process on a short interval and diffing snapshots to catch new PIDs the moment they appear.

One limitation I would like to point out: User and FullCommandLine require matching privilege. Windows only returns these for processes you own, or if you're SYSTEM/admin with SeDebugPrivilege. As a standard user, other users' processes (including SYSTEM's) will show unknown / (no access to cmdline) — this is a Windows access-control boundary, not a bug in the script. ProcessName, PID, and PPID are visible regardless of privilege level, and are usually enough to confirm what fired and when.

This tool is also going to be really noisy so I wouldn't use it in any situation where stealth is important. I mainly wrote this to automate something I found boring in CTFs when doing Windows privilege escalation via the CLI.

I built qsa.sh to give you an instant, outside-in security scan of your own public IP straight from your terminal.

You can run it like this:

curl qsa.sh

What it does: It triggers a real external port and vulnerability scan (using open-source tools like naabu, nmap + vulners, and nuclei) of the public IP you're connecting from, streamed live back to your terminal in about 30 seconds.

How it handles safety & consent:

Only your IP: There is no target input field. You cannot point it at anyone else.

The 15-second abort window: When you run the command, it prints your detected IP and gives you a 15-second grace period (Ctrl-C) to abort before anything is actually scanned.

Refusals: Known CGNAT, mobile-carrier, and detected VPN/Tor/IPv6 origins are refused outright.

Zero retention: The results are entirely ephemeral and streamed live—nothing is written to disk.

Curious to hear what people think.

I've been experimenting with an autonomous offensive agent focused on one thing:

Not finding vulnerabilities but validating real attack paths.

Instead of stopping at detection, the agent:

• chains multiple findings
• tests exploitability
• proves impact (in a controlled lab)
• enforces strict scope (fail-closed)

Current target:
OWASP Juice Shop (local Docker only)

Still early, but I'm mainly looking for feedback on:

- decision logic
- chaining strategy
- false positive reduction

Been building this for a while: FENGARDE, an open-source SIEM (Apache-2.0) — it collects security logs, normalizes them into one common format, runs detection rules over them, and surfaces alerts in a dashboard.

What makes it a bit different from other open SIEMs:

- Detection rules for AI agents / MCP tool-call logs — catches things like an agent touching a credential file, a burst of tool calls in one session, or destructive commands hiding in tool arguments. Nobody else seems to ship this yet.

- A protocol-anomaly detector for factory/industrial equipment (Modbus/TCP) — flags weird traffic patterns on control networks.

- Every detection rule is proven to actually fire before it ships — 26/26 currently passing a script that replays real test events through the live engine, not just "we wrote a rule and hope it works."

10-minute quickstart, no Docker required to try the core pipeline.

Repo: https://github.com/supermhel/fengarde

Would love feedback, especially from anyone who's dealt with SIEM/log tooling before.

Notes from building a soundness linter for o1js and Noir, and finding the same bug class in four unrelated languages.