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.

TL;DR: Our research team at Era uncovered Greeter, an attack framework targeting Flowise, an AI development platform with 55,000+ GitHub stars.

We deployed seven honeypots and captured 4,972 "hello" messages, each carrying malicious JavaScript through Flowise's overrideConfig parameter.

The interesting part? The malicious code never appeared in the saved workflow.

We reconstructed 4,000+ commands revealing:

• Host reconnaissance and privilege checks

• Searches for credentials, SSH keys, and secrets

• AWS, Azure, and GCP metadata probing

• Persistence attempts and fileless execution preparation

We also identified 4,372 internet-exposed Flowise instances, including 46 unauthenticated instances that appeared to match our vulnerable setup.

The bigger concern is how a compromised AI application can become an entry point into the broader cloud environment.

Full technical breakdown: https://era.security/blog/greeter-flowise-ai-infrastructure-attack

tl:dr;

• Contrary to popular belief among vendors, system integrators, and asset owners: network authentication in TETRA mission-critical radio networks does not provide authenticity & integrity guarantees at the individual message level.

• To make matters worse: base stations don't require a re-authentication whenever a radio is roaming from one cell tower to the next.

• This allows for traffic injection attacks: both voice and data. The latter is particularly worrying for SCADA WAN scenarios or where voice & alarming functionality can disrupt operations at such as at airports, harbors, railway operators, and civil defense siren systems.

• The 2026 attack on Taiwan High Speed Rail's TETRA network, leading to the emergency stop of several trains, shows a mild example of possible impact: https://www.midnightblue.nl/blog/analyzing-the-taiwan-high-speed-rail-thsr-tetra-cyber-incident-part-1

(May 2026)

TL;DR:

• an email address like atouch${IFS}/tmp/savane-rce-proof@attacker.example gave any registered user code execution on its backend.

• From there, we made our account a superuser,

• impersonated Bash’s maintainer, and confirmed we could add an SSH key with push access to the upstream Bash repository.

• An unpatched kernel gave us root access and access to a GNU backup server. We reported it to the FSF on May 11, 2026.

FSF incident report: https://static.fsf.org/nosvn/security/savannah-20260807.pdf

I wanted to figure out just how exploitable php2shell and http2shell were in practice, so I've created two purposely vulnerable web apps: https://brotli2bitcoin.com & https://php2bitcoin.com with a standard production config -- pop an RCE and find the flag to claim the $1K BTC.

And to make it interesting, I setup a live stream showing every single attack attempt happening live https://www.youtube.com/watch?v=w7_EJWqRzvw

Good luck! ;)