The 1st case of open weight model to weak cyber capabilities: Moonshot AI cuts cyber training data from open-weight Kimi K3.1 Pro, dropping its internal exploit success from 90.5% to 81%.
For the open-weight release, Moonshot removed cyber-related data from both mid-training and RL stages (while keeping general coding data) to reduce misuse risk. This followed analysis showing that such content was naturally present in broad training and that unrestricted scaling would substantially boost cyber capabilities.
Results on their internal xdev-bench-hard(real-source-code vulnerability discovery/exploitation tasks from software like the Linux kernel, Node.js, etc., with mitigations enabled):
• Unfiltered checkpoint: 90.5% (pass@3)
• Final released K3.1 Pro: 81.0%
The filtering meaningfully lowers cyber performance versus the unrestricted version, yet the model still improves substantially over prior Kimi K3 due to stronger general coding and long-horizon skills. Its offensive cyber capability remains behind frontier proprietary models that have been public for months.
Moonshot’s stated approach is to avoid pushing the absolute cyber frontier in open weights while gradually making dual-use defensive capabilities more widely available.
#Kimi #k3 #Cyber
I can't agree on this.
Even the non-abliterated version are good at finding vulnerabilities, trivial to bypass if needed at all. so it's basically saying "part of it are because of open source models ".
Not to mention that many people have access to cyber programs of OAI and Anthropic.
I strongly believe a part of why so many critical vulnerabilities are happening all over the proliferation of "abliterated" models, or models with safeguards removed.
You can access an abliterated GLM 5.3, a near frontier AI model, on @abliteration_ai today. And it's a world class penetration tester for like $10.
Seems folks are getting stable universal RCE for mod_php, but not PHP-FPM yet?
#php2shell
Is it mapping for PHP applications? Or real exploit shoot?
PHP2Shell (CVE-2026-109618/109619) hit our MadPot honeypots on Oct 17, four days before disclosure.
Investigating? Start your timeline there, not at the advisory date. Patch to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 now.
aws.amazon.com/blogs/securit…
A 60+ year old sales guy just called me. He used REA and AI to reverse a financial system, found a serious “architecture flaw,” and asked:
“How do you guys make money off things like this?”
Artex is back—with a commercial edition.
Many of you first heard about Artex after it was misused in attacks against several South Korean banks. What you may not know is that it started as a personal project built by a talented threat detection engineer at ThreatBook.
Following those incidents, he took the project’s GitHub repository offline to prevent further misuse. Today, he leads the development of RedAgents.ai, our new cloud-based, AI-powered penetration testing platform, with support for zero data retention (ZDR).
RedAgents.ai brings together a growing lineup of AI pentesting agents, including:
1. Artex Pro, the commercial edition of Artex.
2. YanXun, an agent developed by companies affiliated with Peking University.
3. YanJi, which ranked first in the individual category of Tencent’s AI penetration testing competition.
4. The commercial edition of CyberStrikeAI, which we recently acquired.
And more are on the way.
Why bring multiple powerful agents together on one platform?
Because no single agent finds everything.
The same is true of human-led penetration testing: different testers and teams bring different strengths, take different approaches, and uncover different vulnerabilities. AI agents are no different. Using complementary agents can provide broader coverage than relying on any one agent alone.
With RedAgents.ai, you’re not locked into a single AI pentesting vendor. We’re bringing leading agents together on one platform, giving you the flexibility to choose one, combine several, or use them all for continuous security assessment.
Our goal is simple: help you find and address vulnerabilities before adversaries exploit them—and stay ahead of AI-powered attacks.
A preview of RedAgents.ai is coming soon. Interested in early access? Join the waitlist. My DMs are open, too—feel free to reach out with questions or to learn more.
threatbook.io/blog/redagents…
Announcement:
ThreatBook has acquired CyberStrikeAI (github.com/aipentest/cyberst…), one of the most widely used AI pentesting agents out there.
Honestly, when I read back in February that attackers were actually using CyberStrikeAI in real attacks, my first reaction was: that's a technical endorsement! After all, there are countless AI pentesting agents out there — the fact that attackers picked this one speaks for itself.
Open source technologies and tools are neutral — what matters is who wields them. We believe they should be in the hands of defenders, who need to think and act like attackers to stay ahead. That said, we've added guardrails to limit potential misuse, but at the end of the day it's open source, and there's only so much we can do. New capability enhancements will go into the commercial edition.
One more thing worth mentioning: the attribution issue.
The initial threat intelligence report suggested the developer was likely affiliated with certain national agencies, citing the mention of his contributions to China's national vulnerability database on his GitHub profile. This is a false positive. The developer was a security engineer at Alipay who built this tool in his spare time and open-sourced it. In China, submitting vulnerabilities you discover to the national database is a regulatory requirement — it says nothing about any ties to government agencies.
As a CTI vendor ourselves, all I can say is: attribution is hard. You need to understand the culture, the ecosystem, the motivations, and many other factors before making a claim. We all need to be more careful. But it happens.
asiatechdaily.com/threatbook…
3 CVEs found by XGPT were patched in macOS 27 release.
CVE-2026-84536 — SMBClient: remote kernel memory corruption via integer underflow in symlink resolution
Apple: "An integer underflow was addressed with improved input validation. Connecting to a malicious SMB server may lead to unexpected system termination." In smbfs_smb_unix_read_symlink(), nmlen -= 2 runs on a server-controlled size_t with no minimum check; a TRANS2 QUERY_PATH_INFO (SMB_QFILEINFO_UNIX_LINK) reply carrying fewer than 2 bytes wraps nmlen to SIZE_MAX, so targetlen = nmlen * 9 + 1 becomes 0xFFFFFFFFFFFFFFF8, the oversized kalloc_data returns NULL, and that unchecked buffer is immediately written through. What broadens the reachability is that the readlink is issued automatically from smbfs_vnop_getattr(), so ordinary directory enumeration — Finder, Spotlight, an indexer — exercises the path with no user action past connecting.
CVE-2026-84537 — SMBClient: kernel heap corruption via allocation/free size mismatch
Apple: "The issue was addressed with improved memory handling. An app may be able to cause unexpected system termination or corrupt kernel memory." nsmb_dev_ioctl reuses rwrq->ioc_cnt for both the kalloc_data size and the post-transfer byte count: a server answering SMBIOC_READ/SMBIOC_WRITE with a short transfer leaves the field reduced, and kfree_data releases the original allocation under the smaller size — a textbook zone-confusion primitive that current XNU hardening converts into termination. Apple treats the issue as an app-triggered local one even though the triggering bytes arrive over the network.
CVE-2026-84581 — HFS: local kernel heap overflow in the extent B-tree byte-swap
Apple: "A buffer overflow was addressed with improved bounds checking. Mounting a maliciously crafted disk image may cause unexpected system termination or corrupt kernel memory." In hfs_swap_HFSPlusBTInternalNode, recordSize is sizeof(HFSPlusExtentDescriptor) (8 bytes) while the swap loop writes a full HFSPlusExtentRecord (64), so a 20-byte bounds check admits a 76-byte access — 52 bytes past the node buffer. The corruption is a SWAP_BE32 byte reversal of adjacent heap rather than attacker-chosen data, triggered by an unprivileged user mounting a crafted disk image and reading a file.
Great writing!
How easily a security perona can be compromised, and how complicated IR can be now with credential theft focus, and also excellent attribution work done.
Hi guys, just wanted to share my latest writeup about a recent (and slightly embarrassing) experience: I got pwned 😅
The incident eventually led me to uncover what appears to be a new and emerging infostealer operation I’m tracking as RedHive. Enjoy!
winslow1984.com/books/threat…

















