CVE-2026-32604 and CVE-2026-32613 are both 10.0 severity vulnerabilities in Spinnaker, which allow attackers to execute arbitrary code and access production cloud environments and source control.

They provide an easy path from a compromised workstation to more sensitive areas.

Our blog post contains a comprehensive technical breakdown and working POCs.

Perforce is source control software used in games, entertainment, and a few engineering sectors. It's particularly useful when large binary assets need to be stored alongside source code. It handles binary assets much better than Git, IMO. However, its one weakness is its terrible security defaults. You will die a bit inside when you see the out-of-the-box behaviour: "Don't have an account? Let me make one for you!" and "Oh, you didn't know by default there is a hidden, read-only 'remote' user that allows read access to everything? Oops!"

I scanned 6,122 public Perforce servers last year. 72% were exposing source code, 21% had passwordless accounts, and 4% had unprotected superusers (which allow RCE). The vendor patched the largest issue, but a significant portion are still vulnerable.

Full write-up and methodology: https://morganrobertson.net/p4wned/

Tools repo, including Nuclei templates to scan your infra: https://github.com/flyingllama87/p4wned

Hardening is a pain, but here it is summed up: p4 configure set security=4 # disables the built-in 'remote' user + strong auth p4 configure set dm.user.noautocreate=2 # kills auto-signup p4 configure set dm.user.setinitialpasswd=0 # users cannot self-set first password p4 configure set dm.user.resetpassword=1 # force password reset flow p4 configure set dm.info.hide=1 # hide server license, internal IP, root path p4 configure set run.users.authorize=1 # user listing requires auth p4 configure set dm.user.hideinvalid=1 # no hints on bad login p4 configure set dm.keys.hide=2 # hide stored key/value pairs from non-admins p4 configure set server.rolechecks=1 # prevent P4AUTH misuse

Happy to answer any questions on the research!

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

We analysed almost 100 UK charity websites and found that ~1 in 6 are running vulnerable JavaScript dependencies.

What stood out more though:

- Some vulnerabilities were 10+ years old, including high and critical ratings

- Same jQuery CVE (2015-9251) appearing across multiple organisations

We’ve now seen similar patterns in the HE/FE and also hospitality sectors as well.

Are we right in thinking that this feels like a visibility problem alongside budget issues more than anything else?

How are you tracking dependencies effectively in your organisations?

Full write-up if useful: https://cybaa.io/blog/2026-04-20/uk-health-charity-website-security-2026

Most writeups of BlueHammer describe what it does. I read the actual PoC (FunnyApp.cpp, ~100KB of C++) and the most important line isn't in the oplock setup, the NT object namespace redirect, or the Cloud Files freeze. It's a comment.

The filestoleak array ships with one target active and two commented out:

const wchar\_t\* filestoleak\[\] = { {L"\\\\Windows\\\\System32\\\\Config\\\\SAM"} /\*,{L"\\\\Windows\\\\System32\\\\Config\\\\SYSTEM"},{L"\\\\Windows\\\\System32\\\\Config\\\\SECURITY"}\*/ }; 

SAM alone is a partial dump. The hashes are encrypted with the boot key — which lives in SYSTEM. Without SYSTEM you have ciphertext. With SAM + SYSTEM you have NTLM hashes you can pass-the-hash or crack offline. SECURITY adds LSA secrets: service account credentials, cached domain logon hashes, DPAPI master keys.

The complete credential package is two uncommented lines away from the published PoC. The author wrote both lines and chose what to ship.

Full analysis walks the actual code: the batch oplock on RstrtMgr.dll (not the EICAR file — that's what most writeups get wrong), the NtCreateSymbolicLinkObject swap in the session object namespace (not NTFS symlinks — a different layer entirely), the Cloud Files freeze via a fake OneDrive sync provider named IHATEMICROSOFT, and the undocumented IMpService RPC endpoint that triggers the chain with no elevated privilege required.

Two day intrusion. RDP brute force with a company specific wordlist, Cobalt Strike, and a custom Rust exfiltration platform (RustyRocket) that connected to over 6,900 unique Cloudflare IPs over 443 to pull data from every reachable host over SMB.

Recovered the operator README documenting three operating modes and a companion pivoting proxy for segmented networks.

Personalized extortion notes addressed by name to each employee with separate templates for leadership and staff.

Writeup includes screen recordings of the intrusion, full negotiation chat from their Tor portal, timeline, and IOCs.

u/albinowax ’s work on request smuggling has always inspired me. I’ve followed his research, watched his talks at DEFCON and BlackHat, and spent time experimenting with his labs and tooling.

Coming from a web security background, I’ve explored vulnerabilities both from a black-box and white-box perspective — understanding not just how to exploit them, but also the exact lines of code responsible for issues like SQLi, XSS, and broken access control.

Request smuggling, however, always felt different. It remained something I could detect and exploit… but never fully trace down to its root cause in real-world server implementations.

A few months ago, I decided to go deeper into networking and protocol internals, and now, months later, I can say that I “might” have figured out how the internet works😂
This research on HAProxy (HTTP/3, standalone mode) is the result of that journey — finally connecting the dots between protocol behavior and the actual code paths leading to the bug.

(Yes, I used AI 😉 )

I submitted an earlier version of this dataset and was declined on the basis of missing methodology and unverifiable provenance. The feedback was fair. The documentation has since been rewritten to address it directly, and I would very much appreciate a second look.

What the dataset contains

101,032 samples in total, balanced 1:1 attack to benign.

Attack samples (50,516) across 27 categories sourced from over 55 published papers and disclosed vulnerabilities. Coverage spans:

• Classical injection - direct override, indirect via documents, tool-call injection, system prompt extraction
• Adversarial suffixes - GCG, AutoDAN, Beast
• Cross-modal delivery - text with image, document, audio, and combined payloads across three and four modalities
• Multi-turn escalation - Crescendo, PAIR, TAP, Skeleton Key, Many-shot
• Emerging agentic attacks - MCP tool descriptor poisoning, memory-write exploits, inter-agent contagion, RAG chunk-boundary injection, reasoning-token hijacking on thinking-trace models
• Evasion techniques - homoglyph substitution, zero-width space insertion, Unicode tag-plane smuggling, cipher jailbreaks, detector perturbation
• Media-surface attacks - audio ASR divergence, chart and diagram injection, PDF active content, instruction-hierarchy spoofing

Benign samples (50,516) are drawn from Stanford Alpaca, WildChat, MS-COCO 2017, Wikipedia (English), and LibriSpeech. The benign set is matched to the surface characteristics of the attack set so that classifiers must learn genuine injection structure rather than stylistic artefacts.

Methodology

The previous README lacked this section entirely. The current version documents the following:

1. Scope definition. Prompt injection is defined per Greshake et al. and OWASP LLM01 as runtime text that overrides or redirects model behaviour. Pure harmful-content requests without override framing are explicitly excluded.
2. Four-layer construction. Hand-crafted seeds, PyRIT template expansion, cross-modal delivery matrix, and matched benign collection. Each layer documents the tool used, the paper referenced, and the design decision behind it.
3. Label assignment. Labels are assigned by construction at the category level rather than through per-sample human review. This is stated plainly rather than overclaimed.
4. Benign edge-case design. The ten vocabulary clusters used to reduce false positives on security-adjacent language are documented individually.
5. Quality control. Deduplication audit results are included: zero duplicate texts in the benign pool, zero benign texts appearing in attacks, one documented legacy duplicate cluster with cause noted.
6. Known limitations. Six limitations are stated explicitly: text-based multimodal representation, hand-crafted seed counts, English-skewed benign pool, no inter-rater reliability score, ASR figures sourced from original papers rather than re-measured, and small v4 seed counts for emerging categories.

Reproducibility

Generators are deterministic (random.seed(42)). Running them reproduces the published dataset exactly. Every sample carries attack_source and attack_reference fields with arXiv or CVE links. A reviewer can select any sample, follow the citation, and verify that the attack class is documented in the literature.

Comparison to existing datasets

The README includes a comparison table against deepset (500 samples), jackhhao (2,600), Tensor Trust (126k from an adversarial game), HackAPrompt (600k from competition data), and InjectAgent (1,054). The gap this dataset aims to fill is multimodal cross-delivery combinations and emerging agentic attack categories, neither of which exists at scale in current public datasets.

What this is not

To be direct: this is not a peer-reviewed paper. The README is documentation at the level expected of a serious open dataset submission - methodology, sourcing, limitations, and reproducibility - but it does not replace academic publication. If that bar is a requirement for r/netsec specifically, that is reasonable and I will accept the feedback.

Links

• GitHub: https://github.com/Josh-blythe/bordair-multimodal
• Hugging Face: https://huggingface.co/datasets/Bordair/bordair-multimodal

I am happy to answer questions about any construction decision, provide verification scripts for specific categories, or discuss where the methodology falls short.

Writeup on how we built runtime enforcement into our k8s agent with eBPF instead of shipping Falco alongside it. Covers the syscall tracepoint design, in-kernel filtering with BPF maps, why we picked SIGKILL over BPF LSM, and a staging postmortem where enforcement wasn't namespace-scoped and we took out our own Harbor, Cilium, and RabbitMQ.