CAs found 17% of their own incidents in 2026 so far, down from 29% last year and 59% in 2022. Researchers, root programs, and other outsiders found the rest.

That's from a dataset we built of every TLS incident in Mozilla's CA program since 2017 (1,581 as of November 7). 2026 is already the busiest year, with 338. Only 11 incidents in the whole set are critical, and eMudhra's computable keys are the only one where a CA lost control of its own keys.

https://www.certkit.io/ca-report

I built a behavioral detection engine focused on Living-off-the-Land binaries on Windows and wanted to share it with the community for feedback.

Problem it tries to solve

Traditional signature/hash-based detection struggles with LOLBins because they are legitimate, signed Microsoft binaries. Attackers also rename them, obfuscate command lines, and chain multiple utilities across time. Single-event rules often miss the broader operational context.

What the tool does

• Collects process telemetry (prefers Sysmon Event ID 1, falls back to psutil)
• Single-event behavioral rules for common LOLBins (certutil, bitsadmin, mshta, regsvr32, rundll32, powershell, wmic, etc.)
• Sequential multi-stage correlation (download → execute, LOLBin → encoded PowerShell, process cascades)
• Binary masquerading detection via PE OriginalFileName
• PPID spoofing anomaly checks
• Command-line obfuscation heuristics (carets, backticks, Base64 blocks, environment variable slicing)
• False-positive suppression + de-duplication
• Timeline reconstruction (±5–10 min window) + process lineage
• Local web dashboard for triage
• Automated Markdown incident reports + webhook support (Slack/Discord/SIEM)

Architecture highlights

• Modular pipeline: collector → correlation state machine → detection engine → timeline reconstructor → dispatcher
• Rules can be written in YAML (declarative) or pure Python
• Built-in threat emulation test harness (11 scenarios currently)

Current limitations

• psutil mode has polling latency (can miss very short-lived processes)
• Still user-mode only (no kernel/ETW consumer yet)
• Needs more real-world tuning of suppression rules

GitHub: https://github.com/nimesh895/Behavioral-Living-off-the-Land-LOLBins-Detection-System

Would love feedback on:

• Rule coverage / false positive rates you’ve seen with similar approaches
• Missing high-value sequential chains
• Whether the dashboard and timeline reconstruction are useful in practice
• Any other LOLBins or techniques I should prioritize

Happy to answer technical questions or discuss design decisions.

Has anyone heard of this?

https://blog.gitguardian.com/the-agents-have-now-found-your-secrets-on-github-artex-is-abusing-public-secrets-right-now/

When the PHP vulnerabilities were first announced, I spent a HUGE amount of time trying to figure out the logic behind them.

As many others who tried investigating them probably noticed, there was barely any technical information available at the time. We had a few basic hints: something related to PHP_SESSION_UPLOAD_PROGRESS, some kind of Out of Memory condition, and, of course, that video Calif published showing a dancing girl with a shell running the exploit in the background. 😂

I found that pretty funny, especially considering the scale of the vulnerabilities and how many servers around the world could potentially be affected. Anyway, that was pretty much all we had to work with!

Even AI assistants weren't particularly helpful. At the time, they were heavily restricted when it came to this subject. A simple technical question about an internal PHP function could get flagged just because you mentioned PHP and something technical in the same sentence. For those of us without access to a more cybersecurity-focused model, even asking basic questions and using AI to help investigate things was practically impossible.

So I started digging into the PHP codebase myself (I was honestly getting a little mentally insane by that point).

I spent countless hours going through the source code, tracing functions, setting up experiments, debugging, and trying to understand exactly what was happening behind the scenes. There were long days and endless nights spent following one thing after another, trying to connect all the pieces until things finally started making sense.

The more I investigated, the more I realized that I wanted to put everything together somewhere. Not just the final explanation, but the entire process: the PHP internals behind the vulnerabilities, what's happening in memory, why certain things happen the way they do, and how all of this eventually leads to a working exploit.

That's how this research project started.

I structured the write-up to start from the basics and gradually build up to the actual exploitation. Each part builds on what came before, with the explanations becoming progressively more technical until we get to the real thing. I wanted someone with little or no experience in low-level memory exploitation to be able to follow along and understand how all the pieces fit together.

The write-up also goes through the actual exploit code used to solve the "Steal My Bitcoin" challenge, breaking it down step by step rather than simply showing the final result.

Everything is based on my own research, local experiments, and understanding of the PHP engine. I'm not claiming this is an official analysis or that everything is necessarily correct. I'm still learning, and there might be mistakes or things I've misunderstood.

And honestly, I was getting tired of explanations that only scratched the surface without actually showing what was happening internally. I wanted to do something different: a proper, in-depth technical walkthrough covering the entire process, examining the important details and explaining not just WHAT happens, but WHY and HOW it happens.

You can read the full write-up here:

PHP2Shell: From Memory to C Internals to Real Exploit Code

And here's the GitHub repository, which also includes the project files and the backstory behind the research:

GitHub Repository

Many common web frameworks like Spring and Ruby on Rails trust the RFC 7239 Forwarded header by default, even though most proxies don't actually have any support for it. This makes apps vulnerable to request hostname or client IP address spoofing in the default configurations.

I've been researching how the Forwarded header is supported across frameworks and proxies. Rails and Spring recently shipped fixes following my research. There are still other frameworks that need application configuration changes to be secure.

We just published our research on escaping Firecracker microVMs, coordinated with AWS.

The interesting part is how a guest can end up accessing memory belonging to the Firecracker process running outside the VM.

The vulnerability: When a microVM is restored from a snapshot using the File memory backend, a failed memory remapping operation can leave KVM referencing a stale host virtual address range. Firecracker may subsequently reuse that memory for its own data, while KVM still considers it guest memory.

This allows a malicious guest to read or overwrite Firecracker VMM process memory, crossing the VM isolation boundary.

Our research demonstrates an exploit chain from guest userspace to controlled code execution in the host.

Affected configurations: Firecracker 0.23.0 - 1.16.1, when restoring snapshots with the File memory backend and a balloon or virtio-mem device.

Fixed: Firecracker 1.16.2 and 1.17.0+.

AWS advisory: https://aws.amazon.com/security/security-bulletins/2026-169-aws/

The write-up covers the vulnerability, the memory-management behavior behind it, and the exploitation process.

We are from Coinspect, the team behind the research. Happy to answer technical questions here.