Look around you. The world is an amazing place full of awesome people. – at Redmond, WA

Adjusting the Wordfence org to create a 24/7 Threat Response Team for an even higher operational tempo. Our incident response is 24/7. Our Threat Intel team is legendary. With AI producing exploits and vulnerability reports 24/7 we needed a highly capable research team available 24/7 to manage and direct agents, processes, comms and advise customers. Thus, the Threat Response Team with Alex Thomas at the helm and a small, fast-moving team of world-class operators. wordfence.com/blog/2026/10/i…

😱 Anthropic grew quarterly revenue 30.7X in just 15 months. Reading and analyzing the S1 filed a few hours ago. I’m weirdly unsurprised. sec.gov/Archives/edgar/data/…

Buried the lead 3 posts deep. How infrequently do you see hacked PHP sites that you’d make a mistake like this?

Called it. As I said, that report reeks. This is an unauthenticated RCE if exploited, so it absolutely is an urgent patch and should be described as such. But the truth matters. And we have a lot more, and probably worse, coming down the road and lying about compromises will cost credibility and create alert fatigue. And cyber drama fatigue, for that matter.

Reposting this as a top level post. The rationale for being honest with end users and customers, and not exaggerating threats in the hopes that they’re more likely to patch. And what exaggeration will cost you. We’re playing a long game.

Solved X algo

StealMyBitcoin is solved! This is the absolute best explanation you’ll see on how hard #php2shell is to exploit. The author had to trigger a precise memory corruption condition, leak internal memory addresses, bypass aslr, reverse engineer php’s internal memory structures, forge structures to hijack execution, and account for php build differences, worker behavior and timing to get RCE. 20 http requests with a 7 out of 10 success rate. What an amazingly successful CTF. Impressive the creator was able to keep the server up during all the attempts. With all the BS around it’s nice to see something concrete that moves the art forward. github.com/KillaBoi/StealMyB…

“Patch the planet” is a comfortable reality to live in because it assumes a finite pool of vulnerabilities and thinks of vulnerabilities as bugs. Defects some developer wrote. Ooopsies that AI models are helpful enough to fix. Many of them are. But we’re moving beyond that. Software of any complexity has an infinite number of possible interaction sequences. Somewhere in that infinity are exploits that have not been discovered. These are emergent capabilities of the software, not necessarily a developer-written defect. We need to start thinking about the new flow of exploits from AI as the new normal, and accept that as model capabilities go exponential, the flow will increase. We need to move from “patch the planet” to systems thinking, and create organizations and processes that can handle this flow as it goes exponential. And the only way to do this is to harness the models. So what does this look like? Every team member is a highly capable AI builder and operator. They’re building harnesses using Pi with a mix of models from OpenRouter, foundational providers, and their own small local models. They’re triaging, developing POCs, researching - all AI accelerated. And they’re having a blast with passion projects eg games, music, images and video etc. We’ve done this in our org and I’ll unpack some of that soon. For the past 3 years I’ve been saying to our team: If it feels like cheating, you’re doing it right. Well, in a world where the flow of exploits from AI is going exponential, it better feel like cheating and you better know ALL the cheat codes. Codemode in the latest Pi 1.0. Yes please. DeepSeek 4.1 Flash cyber capable at $0.5/Mtok? Thanks very much. RSI on my harness? LFG!! JIT tool discovery. And my personal favorite: lying to models to make them work way harder. If it feels like cheating, you’re doing it right!

☀️You’re going to be hearing a lot of breathless reports on a Tailscale security issue. Here’s an update from their VP of Eng: reddit.com/r/Tailscale/s/NL2… Hi folks, Mike Shaver here, VP of Engineering at Tailscale. We've seen the concerns about Tailscale SSH and wanted to share what we know so far. If you want to jump to the most important part, based on our current assessment, we're not recommending that everyone disable Tailscale SSH. We've now received the researcher's report and are reviewing it. Our engineering and security teams had already been investigating independently, with help from external security specialists. That work has identified issues we're working to fix. We're still validating the full scope, including which configurations are affected. A bit of technical context: Tailscale SSH uses your tailnet's access policies to control who can connect to which machines. Most of the issues we've identified so far concern what happens after someone has been authorized to connect, particularly how Unix privileges and SSH forwarding are handled. In some cases, a session may be able to do more than the configured local user should be allowed to do. While it’s a serious concern, it isn't the same as an unauthenticated attacker being able to connect to arbitrary machines, but the potential impact depends on how SSH access is configured. We're still investigating, so we don't want to make blanket claims about what's affected or not. Again, based on our current assessment, we're not recommending that everyone disable Tailscale SSH. In the meantime, there are a few precautions you can take: •⁠Review your SSH access policies. Make sure only the people and devices that need access have it. •⁠Review SSH forwarding permissions and remove access you don't need. •⁠Consider enabling SSH check mode for an additional authentication step. This won't fix privilege escalation issues, but it does add another barrier to gaining access. •⁠Enable automatic updates where supported so you can pick up fixes when they're released. For particularly sensitive systems, consider temporarily tightening your Tailscale SSH access policies while we investigate, so that only the specific users and devices that need access can connect. We're working on fixes and testing them carefully. We'll publish a security advisory explaining the confirmed findings, affected configurations, recommended actions and available patches. We'll also follow up with a more detailed technical write-up. If we find anything that changes our assessment or requires immediate customer action, we'll communicate that. We know it's been a rough week for security teams, and we understand why people are concerned. We'd rather give you the technical context we have than speculate about things we haven't confirmed yet. We'll share more as we verify the details. If you have any questions about how this relates to your particular environment, please get in touch with our team tailscale.com/contact/suppor…

Requires exact default wordpress:7.1.2 docker with PHP 8.3.35 mod_php, fresh child for leak before opcache, worker pin, clean processes for session files, and no 0x7c in ASLR pointer. And a partridge in a pear tree.

Dark fiber all over again.

A vulnerability is no longer necessarily a bug. It may be an emergent capability of the software. The original developer wrote the software. The attacker writes the exploit using the software as their programming language. Any sufficiently complex software system may contain exploitable combinations of legitimate functionality. Which means that AI models are not finding bugs, in some cases, that need fixing. They’re writing exploits that need to be mitigated. And this may change the ethical lens you use to examine the capability and the organizations. #cybersecurity #vulnerability #ethics

You’re going to see a lot more AI lab and Cybersecurity CEO joint appearances.

php2shell: a running list of exploitation claims that were later corrected, walked back, or not supported by their own sources. Sophos, Oct 22 16:18 UTC: "one successful exploitation." Sophos, Oct 22 21:21 UTC: "telemetry shows scanning and a small number of failed exploitation attempts… no evidence of a successful compromise." sophos.com/en-us/blog/proof-… Sansec, Oct 21: "Sansec expects mass attacks within 15 minutes of the release." Sansec, Oct 22: "The public exploits do not work against a default PHP installation. You do not need to take your store offline." sansec.io/research/php2shell Patchstack, Oct 21 07:34 UTC: "Multiple active exploitation incidents reported to Patchstack by hosting partners." Patchstack, 13:57 UTC: "our telemetry shows only probing attacks, with no hard evidence of breaches yet." patchstack.com/articles/php-… MyCERT headline: "in-the-wild exploitation is confirmed." Its sources are honeypot reports, and its own table lists a confirmed Malaysian compromise as "not established." mycert.org.my/portal/details… TechCrunch: "confirmed compromises… according to Palo Alto Networks and Trail of Bits." The Trail of Bits link goes to a post about their own exploit being "production-grade," with no compromise mentioned. techcrunch.com/2026/10/24/ph… That leaves one victim claim: Unit 42's single unnamed government entity. It comes with no IOCs, no request logs, and no statement that php2shell was the entry point. unit42.paloaltonetworks.com/…

Techcrunch confuses AWS reporting exploit attempts with actual exploits. Then says “But as of late Friday, there are now confirmed compromises and post-exploit activity related to the PHP bug, according to security giants Palo Alto Networks and Trail of Bits.” but links to a POC being developed by Trail of Bits (not exploit incidents) and a unit 42 report with no IOCs or logs or any proof it was php2shell. techcrunch.com/2026/10/24/ph…

🙄 Sophos retraction: “The previous update (October 22 16:18 UTC) reported that Sophos observed successful exploitation of PHP2Shell in customer environments. Upon further analysis, we are correcting that assessment as Sophos customer telemetry shows scanning and a small number of failed exploitation attempts. As of this update, there is no evidence of a successful compromise due to these vulnerabilities.” sophos.com/en-us/blog/proof-…

More bullshit around php2shell. Doesn’t even state the CVEs were the entry point and provides no evidence of compromise via php2shell - but a ton of “look at us” and “buy my product”.