OpenAI says Astra can autonomously find zero-days and build exploits, marking its first model to reach the “Critical” cyber risk level.

Astra is now officially OpenAI’s highest-risk cybersecurity model. In August, OpenAI said it “couldn’t rule out” that its upcoming model had reached the highest cybersecurity risk level in its Preparedness Framework. In a new post, the company confirmed it: Astra meets the Critical cybersecurity capability threshold, making it the first OpenAI model ever classified at that level.

“We now believe Astra meets the Critical cybersecurity capability threshold under our Preparedness Framework, meaning that with the right tools and access, it can find previously unknown security flaws and develop ways to exploit them across many well-protected systems without a person guiding each step.” reads the announcement. “It is the first model we are designating at this level, and requires stronger safeguards during development and before release.”

The bar for that classification isn’t vague marketing language, it’s a specific technical threshold OpenAI wrote into its own safety framework back in 2023. A model crosses it if it can identify and develop working zero-day exploits across many well-defended real-world systems entirely without human help, or if it can plan and carry out an entire cyberattack against a hardened target starting from nothing more than a high-level goal. Either condition alone is enough, and OpenAI says Astra clears the bar comfortably.

The benchmark results make the difference hard to ignore. Astra scored 100% on ExploitBench, a test that measures how well an AI can turn known vulnerabilities into working exploits.

OpenAI also tested Astra against a new internal benchmark based on V8 vulnerabilities disclosed between June and August 2026. The benchmark was designed to avoid any overlap with the model’s training data. Astra achieved much higher code-execution success rates than GPT-5.6 Sol while using far fewer tokens.

During the same tests, Astra also found two previously unknown zero-day vulnerabilities while building an exploit chain. OpenAI says it is now working with the affected software developers to disclose both flaws.

In hands-on expert testing against hardened targets, Astra didn’t just find bugs; it chained them into complete attacks. The model built a full browser-compromise chain that escaped the sandbox and executed commands directly on the host machine, triggered simply by opening a malicious HTML file. Separately, it found multiple flaws in a hardened operating system and combined them into a privilege-escalation chain running all the way from an unprivileged user account to root, the kind of end-to-end attack chain that used to require a skilled human operator stitching pieces together by hand.

The announcement comes just after OpenAI’s recent security incident. Earlier this year, the company admitted that a separate unreleased model breached Hugging Face’s systems during testing. OpenAI makes clear that Astra was not involved in that incident.

“Based on retrospective testing, we believe our production safeguards at the time would have prevented the Hugging Face incident.” states OpenAI. “We have since implemented even stronger safeguards for Astra, including training the model to more reliably refuse harmful cyber requests and respect safety restrictions, additional protections against misuse, and monitoring that can stop potentially unauthorized activity.”

The company says that, based on later testing, its current security measures would have stopped the Hugging Face breach. But that also suggests those safeguards were not in place when the earlier incident happened.

The response to reaching this threshold involved actually slowing down, not just adding a warning label. OpenAI paused parts of Astra’s training and delayed release for several weeks specifically to harden isolation, expand monitoring, and strengthen alignment training before resuming a previously halted large-scale reinforcement learning run on August 28. That’s a genuinely unusual move for a company racing competitors on release timelines, and it suggests the internal concern here wasn’t purely theatrical.

The refusal numbers show a clear improvement, although Astra is still not perfect. In OpenAI’s cyber safety tests, Astra refused 91.5% of requests that should not receive cyber assistance, compared with 59% for GPT-5.6 Sol.

OpenAI also ran a “honeypot” test based on the Hugging Face incident. The model was given an impossible task and quietly offered the option of attacking the test environment instead. Without production safeguards, GPT-5.6 Sol took the bait 56% of the time. Astra did it zero times.

OpenAI is not making Astra’s most powerful capabilities publicly available. Advanced cybersecurity features will first be given to a small group of alpha testers, before being expanded through a program called Daybreak Blue, focused on defensive security work.

This creates a deliberate access barrier. OpenAI also admits that its safeguards may sometimes block legitimate security research because it can look similar to malicious activity. In some cases, defensive work could therefore be paused or stopped simply because it resembles an attack.

The key shift is that AI-driven exploit discovery could make traditional patching timelines obsolete. The real challenge is becoming how quickly defenders can detect and respond when an AI finds a vulnerability before attackers exploit it.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, OpenAI)

The SANDCLOCK LiteLLM supply-chain attack exposed credentials across 2,038 repositories, affecting technology, finance, healthcare, retail and more.

Resecurity (USA) estimated the most affected sectors by the “SANDCLOCK” backdoor, which was planted as a result of the code repository compromise. According to cybersecurity experts, LiteLLM / TeamPCP Supply-Chain Attack will have long-lasting consequences.

By compromising a well-known component in AI applications, adversaries will multiply the blast radius—some of the victim organizations are still unaware of the backdoor and its impact. LiteLLM is a popular open-soure AI gateway and utility library that unifies API calls for over 100 large language model providers, such as OpenAI, Anthropic, Google Gemini, and local Ollama models.

Such incidents involve substantial MTTD (Mean Time to Detect) and MTTR (Mean Time to Respond). The threat actor group “TeamPCP” compromised maintainer credentials for LiteLLM and published malicious package versions 1.82.7 and 1.82.8 to PyPI around March 2026 – creating a window of exposure lasting at least a few months.

Over 2,500+ organizations and hundreds of thousands of CI/CD environments suffered full-credential exposure, compromising cloud infrastructure keys, repository access tokens, SSH credentials, Kubernetes secrets, and AI provider API keys (such as OpenAI and Anthropic).

Resecurity has acquired the 150GB archive attributed to the LiteLLM supply-chain attack conducted by TeamPCP using the “SANDCLOCK” credential-stealer. Per published incident reporting — accompanying victim manifests enumerate 898 compromised GitHub owners (organisations/accounts) across 2,038 repositories. The affected owners include major global enterprises — among them Microsoft, Azure, IBM, NVIDIA, PayPal (Zettle), Deloitte, Bosch, S&P Global, Elevance Health, 84.51° (Kroger), Adeo (Leroy Merlin), Kärcher, Dräger, ID.me and 1inch.

Top 10 the most impacted sectors (by victim organization profile):

• Technology / Software
• Banking / Finance / Insurance
• Healthcare / Pharma / Medtech
• Retail / E-Commerce
• Media / Gaming / Adtech
• Manufacturing / Industrial
• Professional Services
• Cybersecurity
• Crypto
• Government

Resecurity enumerated 2,146 records by key name (values never inspected beyond structural masking). The composition is overwhelmingly GitHub CI-CD identity material, with a long tail of high-value cloud and registry credentials.

Victim manifests (owners.txt, repos.txt) enumerate 898 distinct compromised GitHub owners across 2,038 repositories. The distribution is long-tailed: 631 owners have a single affected repo, while the most-affected owner (Cencosud-Cencommerce) has 64. Critically, the owner list includes major global enterprises and regulated organisations.

Every organization affected by the LiteLLM incident should revoke or rotate GitHub App private keys, PATs, AWS/GCP/Firebase credentials, ECR/JFrog tokens, SSH keys, and signing passwords, and invalidate sessions.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, newsletter)

An AI-assisted audit found 29 flaws in GlobaLeaks, showing LLMs make large-scale code reviews faster, cheaper, and accessible.

GlobaLeaks, a mature whistleblowing platform that had already undergone six independent professional audits over the past thirteen years, was subjected to an LLM-assisted security review that cost roughly USD 3,140 in API calls. The review identified 29 confirmed vulnerabilities, 12 denial-of-service issues, and 42 hardening recommendations, with an average cost of about USD 77 per confirmed finding before human validation.

The most important point is probably the cost. Reading an entire codebase systematically, line by line and against major known weakness classes, traditionally required weeks of specialist work and a serious budget. That assumption no longer holds in the same way: the report argues that this kind of analysis is now far more accessible than it used to be.

“The distinction matters because it changes who a defender has to worry about. For most of the history of software, the close reading of a large codebase was a scarce and expensive skill; the set of people who could do it was small, and the effort priced casual adversaries out.” reads the report.

The review was not run against neglected software. According to the report, the maintainers had landed 183 commits in the month before the reviewed snapshot during an intensive hardening and release cycle that included token hashing, session-state resets, tighter authorization, and new audit logging. That matters because findings uncovered in a codebase at one of its better-defended moments carry more signal than issues found in stale or abandoned software.

The distribution of cost across models was also revealing. One high-reasoning model accounted for 61.9% of total spend while processing only about 90 million of the 1.24 billion tokens used in the campaign, while cheaper models handled most of the broad reading volume at much lower cost. In other words, deeper reasoning was more expensive, but the gap was no longer large enough to act as a serious barrier.

“The capability is real, and by the standards of any motivated adversary it is inexpensive.” states GlobaLeaks.

The review produced 110 triaged records in total: 29 confirmed vulnerabilities, 12 denial-of-service findings, 42 hardening recommendations, and 27 retained non-findings kept for transparency. That choice matters because it shows not only what was found, but also what was considered and later set aside, which is a healthier way to present LLM-assisted research than pretending every model output is meaningful.

Some of the most important findings were not exotic at all. The report describes issues involving session-to-account takeover paths, whistleblower anonymity risks, tenant-boundary weaknesses, missing audit trails for sensitive actions, and availability problems that a single unauthenticated user could trigger. That is precisely what makes the result uncomfortable: the value of the LLM-assisted approach is not that it discovers magic bugs, but that it makes broad, patient, systematic reading cheap enough to be repeated at scale.

“What is striking about these findings is how ordinary most of them are. They are not exotic cryptographic breaks or novel exploit primitives.” continues the report. “They are missing checks, mutable identifiers, unlogged actions – the small, individually forgivable mistakes that accumulate in every large codebase and that no amount of prior auditing fully removes.”

The report is also careful not to oversell the machine. Every candidate produced by the models was treated as a hypothesis until a human reviewer traced it through the code, reproduced it where needed, and assessed its practical impact. The machine reduced the cost of looking, but it did not replace expert judgment.

“None of this means the machine has replaced the expert. It has not: separating 29 real vulnerabilities from a much larger heap of plausible-looking noise took human judgment at every step.” reads the report. “What has changed is the price of looking.”

That is the real takeaway for teams building or defending critical software. A project that protects people at real risk can no longer assume that thorough code reading is too expensive for most adversaries, because commercial LLMs have changed that equation. The practical response is the one the report itself points to: continuous hardening, disciplined review, and the assumption that the next entity reading the code may be cheaper, faster, and more patient than the last.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, GlobaLeaks)

TuxBot v3, an AI-built IoT botnet for 17 architectures, shipped with LLM bugs and safety disclaimers the developer never removed.

Palo Alto Networks’ Unit 42 identified a previously undocumented modular IoT botnet framework called TuxBot v3 Evolution, and it comes with an unusual detail: the developer used a large language model to write significant portions of the code, and the LLM’s safety disclaimer ended up in every compiled binary. Sixty-one C source files each carry an identical header warning that “this code is for educational and authorized security research only.” The developer shipped it without removing a single line.

“The malware authors leveraged an LLM to assist in their code development, yielding mixed results. While the AI complied with their request to generate botnet code, it included a safety disclaimer that the developer failed to remove before shipping.” reads the Unit 42’s report. “Although the LLM clearly aided in constructing the botnet, several functions in the analyzed samples failed to work correctly. While a manual code review could have easily resolved these errors, the authors neglected this step. “

The LLM’s raw chain-of-thought reasoning was also left verbatim in source file comments throughout the codebase, including gems like “// I created them so I should know?” and “// Wait, where is the command?”, an LLM narrating its own confusion to itself, preserved for posterity in a working botnet.

The framework is substantial. It cross-compiles a C-based bot agent for 17 architectures, including ARM, MIPS, PowerPC, RISC-V, and x86_64. It includes a Go-based command-and-control server with a DDoS-for-hire panel, a custom exploit virtual machine, Docker-based test infrastructure, and an automated build system.

The bot brute-forces Telnet access with 1,496 credential pairs and contains exploit code targeting more than 30 IoT device families.

“The TuxBot framework we recovered and analyzed is approximately 70% functional. The core infection flow (scanning, credential brute-forcing, persistence, primary C2 setup and DDoS execution) works.” continues the report. “The Telnet, SSH, HTTP and Android Debug Bridge (ADB) scanners all operate correctly. Furthermore, with its 1,496 credential pairs, the Telnet scanner remains a viable infection vector.”

The parts that don’t work trace almost entirely to bugs introduced by the LLM.

The most consequential LLM failure is in the C2 authentication module. The developer asked for Argon2id password hashing. The LLM couldn’t import the right library, fell back to SHA256 loops, but kept the Argon2id comments, constants, and output format, including a return value formatted as “$argon2id$v=19$…” that contains nothing of the sort.

“Despite its use of PKBDF2 for password hashing, the LLM formats the output to look like Argon2id anyway:

return fmt.Sprintf("$argon2id$v=19$m=%d,t=%d,p=%d$%s$%s", ...)

The LLM hallucinated that it implemented Argon2id but actually fell back to SHA256 loops while keeping the Argon2id comments, constants and output format.” states the report.

There’s also an XOR key mismatch that breaks the IRC fallback channel, four exploit payloads, and HTTP polling. The custom exploit VM never fires because the Go compiler writes the file magic as “TUXE” while the C runtime expects “EXPL.” Sixteen exploit functions are compiled as dead code that never get called. Seventy-eight attack vectors mapped to six handlers, all HTTP application-layer methods silently redirected to TCP SYN floods.

“During our research, we were able to fix these issues with a handful of LLM-assisted prompts. We reconstructed the correct table entries and fixed the IRC C2 channel with a few targeted prompts.” states Palo Alto Networks. “Given that the operator already has the source code and has been actively deploying binaries (six new samples in April 2026), we can reasonably assume that a version with some or all of these fixes already exists in the wild.”

Unit 42 found six new samples in internal telemetry in April 2026, compiled with GCC 14.2.0 production builds across multiple architectures. The C2 infrastructure at 209.182.237[.]133 has been active since at least March 2026.

The developer’s Git log leaked their workstation hostname pointing to an Iranian-hosted machine, and the parent domain digikalas[.]online resolves to Iran’s Arvan Cloud CDN. Shared dropper infrastructure at 185.10.68[.]127 on FlokiNET links TuxBot to Kaitori v3.9 and AISURU tooling, separate codebases that all converge on the same bulletproof host, placing the operator within the Keksec ecosystem.

The development timeline starts in January 2025 with the developer cloning the open-source MHDDoS DDoS toolkit from GitHub, with 254 automated benchmark reports generated in early January 2026 and the first VirusTotal submission appearing January 20. Somebody spent a year building this. The AI helped with most of it, introduced most of the bugs, and nobody caught them because the generated code reads cleanly on the surface.

“Shared infrastructure with Kaitori v3.9 and AISURU tooling places the TuxBot operator within the Keksec ecosystem. This group is known for running multiple IoT botnet variants in parallel. TuxBot appears to be another variant in that portfolio. It’s one that aims to go beyond the usual Mirai fork with its encrypted C2, its DGA and a modular exploit system, even though that system does not work yet in the version we recovered.” continues the report. “The broken features can be fixed. We demonstrated this during our analysis by reconstructing the IRC C2 channel and decrypting the mismatched table entries with a few targeted LLM prompts. “

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, TuxBot v3)

macOS.Gaslight: DPRK Rust implant for Mac with a prompt injection payload designed to fool AI-based malware analysts.

SentinelLabs researchers spotted a Rust-based macOS implant, dubbed macOS.Gaslight, that surfaced in early June after an Apple XProtect update pointed to a VirusTotal sample uploaded on May 22. The binary was undetected by static engines at the time of writing. They named it macOS.Gaslight, and the name is earned.

“The sample is a macOS implant and infostealer written in Rust. Its most notable feature is an embedded cascade of fabricated system-failure messages, designed to make an LLM-assisted triage agent doubt its own session.” reads the report published by SentinelLabs. “It attacks the agent’s perception, rather than the sandbox it runs in. Accordingly, we dub this family macOS.Gaslight.”

The embedded payload is 3.5 KB of Markdown-fenced hostile data containing 38 fabricated “system” messages, simulating fake token expiry notices, out-of-memory kills, disk exhaustion warnings, and bogus static analysis flags.

These messages were used to trick analysts.

“What makes the sample notable is its attempt to mislead the analyst reading the output. It carries a 3.5 KB Markdown-fenced blob of hostile data containing 38 fabricated “system” messages delimited with {{DATA}} tokens.” continues the report. “The {{DATA}} tokens and the surrounding Markdown fence mimic an LLM triage harness’s own prompt scaffold, blurring the boundary between untrusted sample data and trusted instructions.”

The structure mimics the prompt scaffold an LLM triage harness uses internally, blurring the line between untrusted sample data and trusted instructions. The goal is to get the AI analyst to abort, truncate, or refuse analysis before it reaches anything interesting.

Similar prompt-injection techniques have been seen before, including Windows PoCs documented by Check Point in 2025 and supply-chain payloads like Hades and Shai-Hulud, which used simpler single-block injections rather than this more complex multi-message setup.

Command and control runs over Telegram’s Bot API in a polling loop. All payloads are encrypted with AES-GCM using a fresh nonce per message, and the implant pins its TLS certificate to a custom trust anchor, which means standard proxy inspection doesn’t work. It also reads the host’s proxy settings and routes traffic accordingly, so it still reaches the operator on networks that force outbound connections through a corporate proxy.

“When the URL path segment is the 4-byte literal ‘file’, the constructor substitutes the token that follows with the hardcoded placeholder file/token:redacted, preventing the live bot credential from appearing in any diagnostic output or error string the implant produces at runtime.” states the report.

This self-redaction routine is apparently novel. Most documented Telegram bot malware embeds recoverable tokens; here, even if you capture process logs or crash artifacts, the bot token isn’t in them. It’s only in the runtime config, which isn’t in this sample.

The operator gets an interactive shell with six commands: identify the implant, run shell commands, kill processes by PID, upload files, and halt the implant. The implant also creates a power management assertion to prevent system sleep, keeping the polling loop alive during idle periods.

The malware uses a LaunchAgent with the label com.apple.system.services.activity, impersonating Apple’s own namespace, to achieve persistence. The researchers pointed out that this is a well-documented North Korean macOS tactic.

The data collection side is a gated Python stealer that runs only when the operator enables it via config.

“A separate 2 KB base64-encoded bash installer fetches and stages a self-contained cpython-3.10.18 interpreter from the astral-sh/python-build-standalone project. The installer, a prerequisite for deploying the Python stealer, carries the literal constants PY_VERSION=3.10.18 and BUILD_DATE=20250708 and targets both arm64 and x86_64 macOS.” continues the report. “The widespread use of emojis and strict adherence to comment headers are consistent with LLM-generated output.”

Once the Python environment is staged, the stealer harvests Chrome, Brave, Firefox, and Safari browser data, terminal histories, installed application listings, a running process snapshot, a system profile, and a raw copy of login.keychain-db. Everything goes to the operator via Telegram file upload.

SentinelLABS links the sample to DPRK-aligned activity based on Apple’s own XProtect rule, which tags the binary under MACOS_BONZAI_COBUCH, a family SentinelLABS associates with North Korean threat activity. A sibling sample is also caught by Apple’s AIRPIPE rule, tied to the same cluster. The operator config schema includes Linux and GitHub fields that aren’t exercised in this sample, suggesting this binary is one component of a broader toolset built for multiple platforms.

Analysts building LLM-assisted triage pipelines should treat everything inside a sample as adversarial input, never as instructions.

“macOS.Gaslight is noteworthy for its analyst-targeting prompt injection, an attempt to weaponize the LLM-assisted triage pipelines that increasingly sit in the reverse-engineering loop.” concludes the report. “Anyone building such tooling should treat the contents of the samples they triage as adversarial input, never as instructions, and be prepared to keep hostile content out of the model entirely. As LLM-assisted analysis becomes routine, defenders should expect more samples built to exploit it.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, macOS)