Don’t just learn tools and payloads. Learn why vulnerabilities exist. Hands-on web hacking, security code review, and real-world CVE labs.
Melbourne, Victoria
Joined December 2011
- Tweets11K
- Following0
- Followers21K
- Likes11.7K
Pinned Tweet
💥🐹 4 new Go Code Review Labs just dropped! 🐹💥
Read the code, peek at the diff, find the bug.
Sharpen your skills: pentesterlab.com/badges/gola…
After the recent PHP, Brotli and Linux kernel bugs, I think we have a lot of patching ahead. If every update is still a small project, now is a good time to make the next one easier.
A few practical ideas:
pentesterlab.com/blog/brace-…
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.
What does this Java print?
String password = null;
String s = "user:realm:" + password;
A) NullPointerException
B) user:realm:null
C) user:realm:
Tomcat had a CVE because of the answer (CVE-2026-43512).
pentesterlab.com/training/on…
How does a serialised Java object become code execution?
Our Java Deserialization badge helps you understand the mechanics: build payloads, explore deserialisation entry points, and construct gadget chains.
pentesterlab.com/badges/java…
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..
Finding bugs is only part of a pentest.
Our Pentest Process badge is now fully available: 20 exercises following an engagement from scoping to reporting and retesting.
Learn the process behind the pentest:
pentesterlab.com/badges/pent…
New: Web Security Code Review, on-demand. 107 short lessons on finding vulnerabilities in source code.
Four lessons are free with a PentesterLab account. Launch price $699 until Thu 5 Nov.
pentesterlab.com/training/on…
Two new on-demand courses, fully recorded and ready:
🔎 Web Security Code Review
🐹 Secure Coding for Go Developers, beyond the OWASP Top 10
Learn at your own pace. Launch discounts available now:
pentesterlab.com/training/
PentesterLab retweeted
"She's a 4, but she's the private key of an intermediate certificate authority..."
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.
