Proactive security doesn't have to wait for a vuln to be disclosed. Even if a patch isn't available, it's possible to deploy controls and design systems to be resilient against how vulns are exploited. Rashid Feroze talks about runtime security and the benefits of deploying eBPF filters to improve observability and block unauthorized behavior. He walks through scenarios related to supply chain attacks, prompt injections against agents, and responding to major events like PHP2Shell. We touch on threat models to help distinguish between what eBPF filters can protect against and what still requires secure coding discipline from developers.
Resources
Rashid Feroze is Head of Security Engineering at CRED, where he leads security across cloud infrastructure, applications, data, threat detection and response, and emerging AI systems. With more than a decade of experience in cybersecurity, he combines hands-on technical expertise with executive leadership in fast-growing, regulated environments. His work focuses on building security programs that scale while translating complex technical risks into clear business priorities.
Rashid is particularly interested in cloud security, AI supply-chain threats, agentic-system security, and the practical use of AI in security operations. He is an active contributor to the security community and has shared his work at industry forums including Black Hat USA, BSides, Nullcon, and ElasticON. He brings a pragmatic perspective on securing modern financial technology, balancing rapid innovation with resilience, trust, and responsible risk management.
Your application isn't running on a network anymore. It's running on dozens of networks you don't control.
Cloud, Kubernetes, APIs, service meshes... the old network perimeter is gone. The question isn't whether traffic is flowing. It's whether you actually know what's talking to what.
Join us for the Network Security Virtual Summit on October 28 and learn how modern teams are securing application connectivity, reducing blind spots, and building resilient architectures without slowing development.
Security Weekly listeners get a free pass! Register now at https://securityweekly.com/netsec using the discount code CSS26-SW
Mike Shema
- PHP2Shell
The underlying memory flaw was discovered two years, but its urgency was diminished by uncertain exploitability. Then a few months ago researchers rediscovered and reinvestigated the flaw. Where the original flaw was accepted as a known problem in how PHP managed memory when it encountered allocation failures (such as hitting out of memory limits), this new research hinted at how those situations could be exploited.
Fast forward to October when PHP made announcements to prepare for an impending critical security patch. However, the embargo was broken early, which led to even more scrambling from admins to react before patches were available.
Then the patch landed, coming in at 423 files changed with about 11,500 lines of code added and about 1,000 removed. On one hand, more than half of that code was occupied by new test files to exercise memory allocation code paths and memory management failure modes. But that still left about 5,400 lines of new code that mostly replaced memory allocation functions with equivalent ones that accounted for being fallible when memory couldn't be allocated and allocation flows had to be unwound.
And, yes, there's an LLM element to this story, where researchers relied on agents to assist with developing successful exploits. But post-patch release, there's also been a proliferation of agent-assisted POCs that are long on concept and short on proof.
Ultimately, this feels like a very human story of developers considering how to improve software quality (improve correctness of memory management and exceptions), how to prioritize work (does a memory safety flaw become a security flaw only once it's exploitable), and how to manage large open source projects (what versions get patched and what compatibility issues can a patch introduce).
The main site noted above has links to the PHP Foundation's announcement and several other technical blogs from the security researchers who discovered the flaw. There's a lot of good technical background to dig into there.
- Broccoli2Shell
Another exciting flaw this month! I particularly like this once because it's a parsing problem where carefully crafted compressed data can turn into an RCE due to out-of-bounds writes by the decoder.
One of the things noted in the OpenSourceMalware blog post is that the fix was committed back in February 2026 and didn't become a security event until this October.
- Compromised eMudhra Intermediate Certificates
When a certificate requires a private key to be derived from an elliptic curve with 384 bits, the assumption was that more than just the lowest eight bits should have some ones.
The CA's explanation shows how this kind of mistake arose from multiple errors. But those errors highlight process flaws that should have been caught by technical and procedural controls before they compounded into an 8-bit private key.
