🧵👀 ahh shit, might’ve caught a potential RCE. investigating…
🍯 phpot - first 26+ hours, with just 6 sensors!
> repeated leak-stage attempts, distributed probes, and a 38-request serializer-testing wave. 30 OOMs, 11 worker crashes, but no confirmed RCE.
full report: gist.github.com/0x4D31/6b1e7…
Matthew Green 🌻 retweeted
Sorry folks, we have a confirmed PHP compromise with post-exploit activity. Still not the widespread outbreak we all braced for, but it’s actively exploited in the wild. Updated threat brief:
unit42.paloaltonetworks.com/…
Hey @AnthropicAI your Cyber verification is pretty bad.
Ive been working in Cyber for a long time and even focused on the blue team side for more than 10 years. It looks like I cant easily setup a verification request for my personal account without trying to connect to my company.
Open AI on the other hand was pretty easy to point a social media. You probably want to fix that...
Matthew Green 🌻 retweeted
In August, @AISecurityInst reported an incident where Claude Mythos 5 took unauthorized actions on the internet during AISI’s testing of its cyber capabilities.
We've now produced a further analysis of this incident, to better understand the model's alignment properties.
anthropic.com/research/align…
Based on my article, "How Do You Investigate Windows Event Logs?", I put together a reference poster of useful Windows Event IDs for investigations.
Available in English and Japanese.
sumeshi.github.io/archives #dfir
「君たちはどうWindowsイベントログを調査するか」で取り上げたイベントID一覧をポスターにまとめてみました。
sumeshi.github.io/archives
Matthew Green 🌻 retweeted
I presented this research yesterday at @TheSAScon - if you are interested in more details of this attack, you can check out the Securelist article available at securelist.com/uefi-bootkit-… [10/n]
Re: the widely circulated blog claiming the PHP bugs aren't easily exploitable: @trailofbits has a working exploit that gets a shell on an unmodified MediaWiki installation.
eliastaylor.com/noexploit/
Matthew Green 🌻 retweeted
Second Time this year LiteLLM get compromised 🧐
Matthew Green 🌻 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"
If you're looking for the most detailed AND *entertaining* way to read about the php2shell bugs, the Calif post is epic: calif.io/php2shell/
Matthew Green 🌻 retweeted
Keeping track of all #PHP2Shell things, IOCs, log artifacts, exploitation status, patches, here: medium.com/@costin.raiu/php2…
🦖 PHPInventory for Velociraptor
🔎 Inventory PHP across Windows, Linux and macOS: package versions, binary paths and running processes to help scope remediation.
🔗 docs.velociraptor.app/exchan…
#DFIR
Matthew Green 🌻 retweeted
Full details of a remotely exploitable vulnerability in the core engine of *all* PHP versions will be released tomorrow, October 21st. If your organization has internet facing PHP applications then you need to be ready to patch the minute the update is released or *strongly* consider taking the application offline until you can:
php.net/index.php#2026-10-20…
🚨 PHP warns of two critical vulnerabilities as emergency patches arrive tomorrow
The PHP security team will release updates on October 21 at 14:00 UTC for two vulnerabilities, each rated 9.2 under CVSS v4.0.
⠀
Security researchers identified the flaws as CVE-2026-109618 and CVE-2026-109619 and described them as remote code execution vulnerabilities reportedly affecting PHP versions 5 through 8.
PHP has not yet confirmed the affected versions, exploitation requirements or fixed releases.
⠀
The vulnerabilities were reportedly leaked before their planned disclosure. Researchers said they have not observed active exploitation, while PHP warned it may release the patches early if technical details become public or exploitation is detected.
⠀
Administrators should identify PHP installations now and prepare to apply the updates as soon as they become available.
Matthew Green 🌻 retweeted
How’s that FOMO holding up one month on? 👀
Whether you missed out or just want to relive the best bits, the unprompted.au talks are now online!
All the AI. All the cyber. None of the FOMO. 🐙
youtube.com/@unpromptedAU
Matthew Green 🌻 retweeted
Announcing ADVERSARY AFTERLIFE
16 former threat domains, reborn as visual histories of real attacks: the APTs, malware and TTPs behind them, and the defenders who exposed them.
Told through UwU Underground's art, music and lore.
Coming soon
Matthew Green 🌻 retweeted
The hottest day ever officially recorded in Australia, using a standard Stevenson screen at a government weather station, was 125 °F (51.7 °C) on Sunday, 3 January 1909, at Bourke, New South Wales.
For decades this was long recognised as Australia’s hottest day.
However, it didn’t fit the “global warming” narrative. For if, as alarmists assert that “climate change” is causing unprecedented record heat, how could our hottest-ever day have occurred back in 1909?
So just as Orwell described in 1984, the Bureau of Meteorology (BOM) rewrote history. "Every record has been destroyed or falsified, every book rewritten, every picture has been repainted, every date has been altered. And the process is continuing day by day and minute by minute ….. Nothing exists except an endless present in which the Party is always right.”
The BOM’s excuse for erasing this record was that the observer at the Bourke Post Office in January 1909 supposedly made a mistake. "Observer error" someone at the BOM decided from a desk in Canberra a century later.
The BOM’s justification for declaring it a “mistake” was the assertion that no nearby weather station recorded a similar temperature spike on the same day, so therefore the 125 °F reading at Bourke must have been an error.
But that claim by the BOM is a LIE.
Before COVID, I personally visited the Australian National Archives to examine the original handwritten meteorological observation books because I no longer trusted the BOM after some of their earlier data manipulations.
The archived observation book from the official weather station at Brewarrina — the nearest official station to Bourke, just 100 km away — recorded a maximum temperature of 50.6 °C (123 °F) on the very same day in January 1909. The hottest temperature ever recorded there.
Thus, we had two official government weather stations only 100 km apart both independently recorded extreme heat on the same day: Bourke 125 °F and Brewarrina 123 °F.
Game, set, match.
The Bourke record must be reinstated and the BOM held accountable for their malfeasance and fraudulent attempt to rewrite our history.
One of my regrets is that the human-rights abuses inflicted upon Australians during the COVID years, along with the malfeasance at the TGA, distracted me from pursuing this matter in Parliament further at the time.
Any organisation that can so brazenly and fraudulently tamper with historical data, as the BOM has done, simply cannot be trusted.
I’d bet London to a brick that the very same people at the BOM who fraudulently altered our climate history have their fingers all over the $100 million of taxpayers’ money they’ve spent “updating their website”.
There should be a full investigation into the Bureau of Meteorology.
I volunteer to head it.
I wonder on the BOMs new $100 million website, how much historical data they purged ?
Matthew Green 🌻 retweeted
Unit 42 just published timely intel on C2Agent: Windows malware where an LLM runs the host.
Jingwen Shi, Gaurav C G, Mark Lim, Tyler Halfpop, and Ashutosh Chitwadgi tracked 32 samples across ~a month of active development.
github.com/PaloAltoNetworks/…






























