A reminder to parents this Halloween 🎃
Please inspect your children’s candy carefully.
Some people are hiding NVIDIA DGX Sparks in trick-or-treat bags.
If you find one, don’t panic. Send it to us for safe disposal.
This XSS filter removes every script tag. Well, every other one. A live NodeList, a loop that removes items from it, and CVE-2020-15885.
Free lesson: pentesterlab.com/training/on…
We love grep, but there's more to security code review than searching for dangerous functions and patterns.
Those searches can give you useful starting points, but the real work is understanding what the application does, how its security controls work, and where its assumptions break down.
A missing authorisation check won't necessarily contain a suspicious keyword, and a business logic flaw might use perfectly safe functions in the wrong order.
Use grep to find places to look, but always take the time to understand what you're reviewing..
In 2008, Debian disclosed that a change intended to silence Valgrind warnings had broken OpenSSL's random number generator.
The change removed code that mixed entropy into its internal state, leaving the process ID as the only meaningful source of variability. Attackers could precompute the possible keys instead of breaking the cryptography.
In 2026, eight of eMudhra's intermediate CA private keys turned out to be:
4, 56, 66, 115, 155, 156, 230, 237.
Assumptions are at the root of so many security issues. When testing an application or reviewing code, always ask yourself: "What assumptions did the developer make? What assumptions am I making when I say this is secure?"
Maybe you're assuming that an input has already been validated, that a route requires authentication, or that a framework handles a security check for you.
Each of those assumptions deserves to be verified.
Questioning the developer's assumptions is part of the job, but questioning your own is just as important.









