Documentary photographer, old creaky hacker. Co-author of @OWASP ASVS standard. Blackhat/Brucon Review Board & Co_chair UK Gov Cyber Security Advisory Board
Airport lounges.
Joined April 2008
- Tweets17.7K
- Following2K
- Followers33.8K
- Likes45.8K
These fixes came out of the hardening behind the study, before publication.
Worth reading if you build scanners or rely on their reports.
There’s a fair bit hiding behind the word “clean”.
One particularly dodgy failure: a verification rule breaks, produces no findings, and the harness calls the original issue “refuted”.
We fixed that distinction. Tool failure now means error. We also tightened verdict reuse so an old assessment can’t skip review without the ev
Framework handlers often have no obvious caller in the repository. The framework calls them.
Treating that as dead code is how you lose reachable bugs. We expanded Raptor’s framework recognition and tightened the conditions for suppression when the call graph is uncertain.
Someone writing # nosemgrep beside a vulnerability doesn’t make it go away.
We now retain the finding and attach the suppression as metadata. Their justification reaches validation as a claim to investigate.
“Trust me, mate” needs slightly more supporting evidence.
Naming a directory tests/ could keep its contents out of Semgrep’s scan. Bit of a gift if you’re trying to hide
something.
Raptor now includes those directories and stops the target’s ignore files from quietly deciding scan scope.
Exclusions get reported. yay. rightly so
Extensionless scripts could disappear from Raptor’s inventory. We added shebang detection and made sure the detected language reaches the scan itself.
Otherwise you’ve only fixed half the problem.
glad everyone is now using some form of robot to scan their code, but before it says “clean”, check whether it actually scanned the code.
While hardening Raptor, we found harness decisions that could quietly lose real attack surface.
Gadi’s new post explains the research.
Daniel Cuthbert retweeted
this is baller... nice one @censysio php2shell.censys.com/
emudhra.com/en/press-release…
yup, probably for the best
Justin proving that the hyperbole of "AI makes it trivial to sling exploit code" isn't exactly true
LLMs...Letting me do fun things I never would have wasted time on.
"I reviewed all 30 public GitHub repos for PHP2Shell (CVE-2026-109618 / CVE-2026-109619) by reading code only. The slide has the full
grouped table; the headline findings:
Nothing works against a real target. Every genuine memory-corruption chain is lab-bound: it needs exact per-build offsets, display_errors=On, a single prefork mod_php worker, and a specific image.
Independent reviewers (allureluoli, dinosn, Gi1gamesh123) and the leaked primary source itself all converge on "no public artifact achieves code execution" on the patched core bug. Every real shell
in these repos comes from an app-side LFI or deserialization sink, not the CVE.
Three are original and real, all lab-only. 9bie (the source of the Set-Cookie leak chain), Marven11 (the most sophisticated, a true in-band leak), and Karasawa2025 (whose "Fermat" troll description
hides a working ROP + display_errors=off exploit). These are the only ones with a genuine ASLR-defeating leak primitive that is their own.
Most are copies. One original (9bie) spawned five derivatives:
- twili8 is an outright uncredited rip-off: its own README still says git clone 9bie/... and the Docker files are byte-identical.
- godylockz and xuehuolll are byte-identical to each other.
- dinosn and 3em0 are credited ports that add value.
Three are mislabeled. iQingshan, KarimUD7 (≈98% the same code), and Gi1gamesh123 exploit a different bug entirely (the Calif unserialize var_hash UAF) against their own planted endpoints, filed
under the php2shell CVE numbers.
The rest is noise. The most-starred repo (ikow, 905★) delivers the least: broken or stubbed chains with the two "real" ones paywalled behind Substack. eness (558★) is a leakless forge that can't
defeat ASLR. syrex1013 ships AI-generated fake CVEs in a side directory. Whackermelon hallucinates a non-existent openai/php2shell-checker. lcfr-eth is a parody with a memecoin address, and Icex0
is an empty repo. The genuinely honest work is the crash labs (allureluoli, slabbdev, 0x4148), which prove the bug without claiming RCE.
The ASLR column, star counts, copy lineage, and the specific "tell" for each repo are all in the table. The page is private to your account; use the Share menu if you want to send it to the team"
Daniel Cuthbert retweeted
LLMs...Letting me do fun things I never would have wasted time on.
"I reviewed all 30 public GitHub repos for PHP2Shell (CVE-2026-109618 / CVE-2026-109619) by reading code only. The slide has the full
grouped table; the headline findings:
Nothing works against a real target. Every genuine memory-corruption chain is lab-bound: it needs exact per-build offsets, display_errors=On, a single prefork mod_php worker, and a specific image.
Independent reviewers (allureluoli, dinosn, Gi1gamesh123) and the leaked primary source itself all converge on "no public artifact achieves code execution" on the patched core bug. Every real shell
in these repos comes from an app-side LFI or deserialization sink, not the CVE.
Three are original and real, all lab-only. 9bie (the source of the Set-Cookie leak chain), Marven11 (the most sophisticated, a true in-band leak), and Karasawa2025 (whose "Fermat" troll description
hides a working ROP + display_errors=off exploit). These are the only ones with a genuine ASLR-defeating leak primitive that is their own.
Most are copies. One original (9bie) spawned five derivatives:
- twili8 is an outright uncredited rip-off: its own README still says git clone 9bie/... and the Docker files are byte-identical.
- godylockz and xuehuolll are byte-identical to each other.
- dinosn and 3em0 are credited ports that add value.
Three are mislabeled. iQingshan, KarimUD7 (≈98% the same code), and Gi1gamesh123 exploit a different bug entirely (the Calif unserialize var_hash UAF) against their own planted endpoints, filed
under the php2shell CVE numbers.
The rest is noise. The most-starred repo (ikow, 905★) delivers the least: broken or stubbed chains with the two "real" ones paywalled behind Substack. eness (558★) is a leakless forge that can't
defeat ASLR. syrex1013 ships AI-generated fake CVEs in a side directory. Whackermelon hallucinates a non-existent openai/php2shell-checker. lcfr-eth is a parody with a memecoin address, and Icex0
is an empty repo. The genuinely honest work is the crash labs (allureluoli, slabbdev, 0x4148), which prove the bug without claiming RCE.
The ASLR column, star counts, copy lineage, and the specific "tell" for each repo are all in the table. The page is private to your account; use the Share menu if you want to send it to the team"
after all the vulns yesterday and the pwnage, the arguments of "joo released p0c code bro, so bad" etc, we are so back in the 90s
next up @dugsong is gonna release a new version of dsniff
you are a CA and have caused major havoc, mostly because you messed up, write a good PR piece to save face. don't make mistakes
Daniel Cuthbert retweeted
Calif was founded with a mission to make the Internet a more secure place for everyone. In the last few months, we have been seeing significant advances in AI model capabilities, especially in the domain of offensive security research. In addition to publishing our research and learnings, we wondered what else we could do to help defenders.
While large corporations and government agencies have the dedicated budget and human resources for incident response and forensics, there are non-profit organizations –- collectively known as civil society organizations –- investigating digital threats affecting vulnerable groups and they are funded entirely by volunteers. In order to perform their job, the civil society researchers may need to extract data from mobile devices for forensic purposes, reverse engineer malware, and conduct similar security tasks. This work can be challenging given the restricted environments on some mobile devices.
We understand these technical challenges and will offer our research services and capabilities to these organizations, free of charge. We support them and their mission.
If you represent such an organization and need assistance, contact us at [email protected].
Daniel Cuthbert retweeted
arstechnica.com/security/202…
The private keys for these certs are literally the numbers 4, 56, 66, 115, 155, 156, 230, and 237 (life imitates XKCD, again).
