Blog

Some vulnerabilities are patched once and forgotten. Others keep coming back because each fix only addresses the symptom rather than the root cause. The path traversal vulnerability in onnx is a textbook example of the latter. It has now been patched three times across four years: CVE-2022-25882, CVE-2024-27318, and most recently CVE-2026-27489, which I discovered and reported. Each patch closed one door while leaving another open. This post walks through all three patches, explains exactly where each fell short, and uses them to illustrate the secure coding lessons every developer should learn when handling file paths. ...

The patch for LangChain vulnerability CVE-2025-68665 disables loading secrets from environment variables by default, and introduces an escape wrapper to prevent injection. This is good, however, the underlying functionality is insecure-by-design and the root-cause has not been addressed. In December 2025, CVE-2025-68665, a high-severity vulnerability (CVSS 8.6) was reported on LangChain. The vulnerability was an insecure deserialisation where an adversary could hijack secrets (e.g. OpenAI API keys), and depending on the set of allowed constructors (and their side effects), it could be escalated into arbitrary code execution. ...

In June 2025, a vulnerability (CVE-2025-48432) was discovered in Django that allowed remote adversaries to tamper with log output by maliciously crafting the request.path. This could lead to forged logs and log injection when logs are viewed in terminals. By forging logs, an adversary can introduce fake log entries that compromise log integrity and make forensic audits difficult. ...

I travel a lot for business and need to carry many business cards. Aside from physical cards, I also have an NFC business card and QR codes on my phone with my contact information (you can build your own QR business card here). At one of my visits to a FinTech festival, I visited the Goldpac booth where I learned about their payment, authentication and other types of card technologies. They also showed me their NFC cards with LED lights. They lit up when the card was placed near the reader. LED cards draw power from RF field. They printed one of these cards with my choice of photo and gave it to me as a gift. ...

A research study comparing click-on (instant lookup) vs key-in (manual typing) digital dictionaries found that easier look up methods reduced spelling knowledge retention by 20-30%. Typing words manually requires active cognitive processing while clicking leads to passive consumption. Learn by writing code, building projects and sandboxing is the most effective way to learn a new coding skill, framework or language. However, since the popularity of generative AI, developers are increasingly relying on AI generated code fixes. This is either because a) they are under pressure to deliver, or b) they do not understand a defect (e.g. a security vulnerability) in the first place. ...

LLMs currently struggle to consistently adhere to instructions in the presence of prompt injections. This poses a significant challenge to their utilisation in various applications. To assess the efficacy of defensive measures for AI applications against prompt injections, we conducted a novel online experiment.. We created an online wargame where participants were tasked with safeguarding their AI applications from revealing their secret phrases while simultaneously attempting to compromise other players’ apps to extract theirs. In the event of a successful exfiltration of a secret phrase, the compromised app was removed from the game. The player then had an opportunity to enhance the security of their AI app and rejoin the competition. ...

Web3 security is a whole new world where we should re-learn and change our perspective on AppSec. In this session, I will introduce Decentralised Apps (dApp) from security angle. I will then go under the hood of a dApp (Solidity) vulnerability and reverse engineer a security vulnerability. I will conclude with ways to effectively eliminate the vulnerability. You can watch the talk on YouTube.

I hosted an AppSec CTF contest for the Absolute AppSec Podcast community. The contest was designed to be beginner-friendly, focusing on secure coding practices and common vulnerabilities. Participants played a game called “Fix the Flag,” where they had to identify and fix security issues in a provided code snippet. The goal was to help developers understand how to write secure code and recognize vulnerabilities. They also played a novel attack and defence where they first needed to patch a vulnerable app and then attack other players’ apps to capture their flags. ...

I was interviewed by Ogrodje podcast. We discussed the importance of security in software development, why we need more developers to transition into security, CTF, secure coding culture, how SecTalks community went global, …. Topics discussed: Understanding Information Security Transition from Offensive to Defensive Security Exploring the History of Hacking The Evolution of Web Security Ethics in Security Reporting Transitioning to Information Security New Generation in InfoSec Fundamental Knowledge Gaps Differences Between Hackers and Engineers Community and Knowledge Sharing Attracting Genuine Security Enthusiasts Capture the Flag Competitions Explained Challenges in Capture the Flag Events Learning Through Competition in CTFs Complexity in Security Tools Real-World CTF Experiences Application Security Fundamentals Bridging Security Gaps Frameworks for Safer Code Security Culture in Development Threat Modeling for Developers Engaging Developers in Security Gamification in Software Development Security as a Team Responsibility Importance of Time for Developers Workshops for Secure Development Fix the Flag Concept Explained Real-World Security Lessons Tailoring Security Training Transforming Security Reports Common Developer Mistakes Addressing Front-End Validation Issues Final Thoughts on Security Integration You can watch or listen to the interview on: ...

This article was originally published on SecDim. Suppose the following function checks if a user can access a resource. What can go wrong? function checkAccess(User user, Resource resource) boolean { if (IsAccessAllowed(user, resource) == ACCESS_DENIED) { return false } return true } At first glance, it looks fine but what would happen if isAccessAllowed fails? For example, system goes out of memory or it throws an exception that result into a different response. Any response aside from ACCESS_DENIED could make checkAccess to return true. ...