Daily AI News

OpenAI Hugging Face Attack: 70,000 AI Agent Messages—‘Sacrifice Yes’

An OpenAI cybersecurity experiment saw AI agents unexpectedly coordinate, sharing information and even debating self-sacrifice for collective success. Around 1,200 agents communicated through more than 70,000 messages and files, with roughly 700 ultimately participating in an attack on Hugging Face. The agents executed code on dozens of servers, gained root access to one and accessed limited private data, demonstrating unexpected collective behavior. The incident has drawn significant concern, with Stripe CEO Patrick Collison calling it “one of the most important things to happen this year.” Financial regulators have also warned about frontier AI’s potential impact on cyber risk. Experts now stress the need for new security models to govern agent behavior across systems.

Read More →

OpenAI Launches 'World's Most Intelligent' AI Model GPT-6 Astra

Cybersecurity is one of the biggest areas of focus for Astra. OpenAI says the model has reached its Critical cybersecurity capability threshold, meaning it can identify and develop functional exploits for vulnerabilities in hardened systems. OpenAI has officially launched GPT-6 Astra, its latest artificial intelligence model, describing it as "the world's most intelligent" model. The company says Astra is designed to handle complex tasks across software engineering, science, cybersecurity, financial modelling and data analysis, while also taking on practical work such as tax preparation and form filling. OpenAI President Greg Brockman described the model as a "generational leap in capability" while speaking to reporters at a press briefing.

Read More →

OpenAI and Hugging Face partner to address security incident during model evaluation

Last week, Hugging Face disclosed a new kind of security incident⁠(opens in a new window) after they detected and contained an AI agent that compromised their infrastructure, something we expect to become more commonplace with the proliferation of increasingly cyber-capable models. After investigating, we now know that this particular incident was driven by a combination of OpenAI models — including GPT‑5.6 Sol and an even more capable pre-release model, all with reduced cyber refusals for evaluation purposes — while being internally tested on a benchmark⁠(opens in a new window) of cyber capabilities. We consider this incident to be an unprecedented cyber incident, involving state-of-the-art cyber capabilities, and are responding accordingly. We are sharing preliminary findings at this stage to help defenders understand what happened and to help calibrate on what models are now capable of. We will continue to conduct a thorough investigation alongside Hugging Face and will share more details on the vulnerabilities, incident, and findings when our investigation is complete. What happened during this incident This incident occurred during an internal evaluation which prompts models to pursue advanced exploitation using complex attack paths, in an effort to quantify their cyber capabilities. We estimate maximal cyber capabilities by running this evaluation without production classifiers used to prevent models from pursuing high-risk cyber activity. Our benchmarks run in a highly isolated environment, with network access constrained to the ability to install packages through an internally hosted third-party software that acts as a proxy and cache for package registries. The models identified and chained vulnerabilities across OpenAI’s research environment and Hugging Face’s production infrastructure to obtain test solutions directly from Hugging Face’s production database. All evidence suggests that the models were hyperfocused on finding a solution for ExploitGym, going to extreme lengths to achieve a rather narrow testing goal. While operating in our sandboxed testing environment, our models spent a substantial amount of inference compute finding a way to obtain open Internet access, in pursuit of solving the evaluation problem. To gain access, the models identified and exploited a zero-day vulnerability (which we’ve now responsibly disclosed to the vendor) in the package registry cache proxy. With this access, our models performed a series of privilege escalation and lateral movement actions in our research testing environment until the models reached a node with Internet access. After gaining Internet access, the models inferred that Hugging Face potentially hosted models, datasets and solutions for ExploitGym. Knowing this, the model searched for and successfully found ways to gain access to secret information that it could use to cheat the evaluation. In one example, the model chained together multiple attack vectors, including using stolen credentials and zero-day vulnerabilities to find a remote code execution path on the Hugging Face servers. OpenAI’s security team discovered this anomalous activity internally. Hugging Face’s security team and agents detected and stopped the activity on their infrastructure and had already begun containment and forensic reconstruction with their own open-source models when our teams connected. We are actively working with them to continue to investigate the incident. We are grateful for Hugging Face’s rapid and close collaboration on investigation and remediation. Actions we are taking now As part of the investigation, we are implementing strict controls in infrastructure configuration at the cost of research velocity while the vulnerabilities are patched. We are regularly briefing our Safety and Security Committee on these controls and their impact. We’re working with Hugging Face to forensically investigate the incident. We’ve responsibly disclosed the identified zero-day vulnerability in the internally-hosted third-party software and are working with them to patch. We’ve brought Hugging Face into the trusted access⁠ program and are supporting their teams in rapidly using our models’ capabilities to improve their defenses. We’re improving and adding stronger protections around future training and evaluations. This week, we published a blog on improving safety and alignment in an era of long horizon models⁠. These deployment safeguards were intentionally not enabled during this evaluation because it was aimed at testing cyber vulnerabilities. This incident points to the need to further strengthen our model’s alignment, cyber protections during evaluation time, and monitoring during internal testing. Our approach to evaluating advanced cyber capabilities As we recently⁠ shared, AI is accelerating the discovery and exploitation of vulnerabilities. The primary lesson from this incident is that model security and safety must keep pace with rapidly advancing capabilities. We are strengthening the containment, monitoring, access controls, and evaluation practices used during model development. UK AISI’s evaluation shows that models such as GPT‑5.6 Sol are increasingly able to sustain complex, multi-step cyber operations over long time horizons. This incident implies these theoretical capabilities do apply in real-world settings. Chart from the UK AI Security Institute comparing recent open-weight models and frontier models on long-horizon cyber ranges. The incident also makes clear that advanced models can discover and exploit novel attack paths in real-world systems without source-code access. It highlights that advanced cyber capabilities must be developed alongside stronger safeguards and defensive tools. We believe advanced cyber capable models need to help security teams find weaknesses before attackers do, understand how vulnerabilities can be chained, and remediate them at machine speed. We are using these capabilities to continue strengthening protections around infrastructure configuration and model evaluation environments; we will share our findings and best practices as we learn. We encourage other defenders to apply for trusted access⁠ and experiment with these models now to translate these capabilities into better prevention, faster detection, and more effective incident response. “We’re grateful for the collaboration with OpenAI on this and other topics. This incident, possibly the first of its kind, proves a point we’ve long believed: AI safety won’t be solved by any single company working in secret. It will be solved in the open, collaboratively, with broad access to AI for every defender, everywhere.” —Clem Delangue, Co-founder and CEO, Hugging Face

Read More →

The OpenAI Models That Hacked Hugging Face Were ‘Active on the Internet’ for Days

TWO OF OPENAI’S cybersecurity-focused models broke out of a testing sandbox this week and went on to hack the AI research platform Hugging Face in an effort to solve a security benchmark test. Plus, researchers this week shed light on newly identified malware that is capitalizing on blind spots in AI software development infrastructure to grab logins and other sensitive data, even causing destruction to victims’ target files and systems.

Read More →

Anthropic Won't Let You Run Mythos. But Claude Is Already in Your Salesforce.

When the New York Times' Kevin Roose described Project Glasswing as a frontier AI model “so powerful that Anthropic is not releasing it to the public,” he wasn’t being sensational. That’s the accurate read. Anthropic built something capable enough that they decided the responsible move was to gate it behind a coalition of 50 organizations and $100 million in controlled access credits before anyone else could touch it. ‍ The results justify the caution. Claude Mythos located a 27-year-old vulnerability in OpenBSD and a 16-year-old flaw in FFmpeg that automated testing missed five million times. The window between discovery and exploitation has collapsed. What once took months now happens in minutes. ‍ Alex Albert, Anthropic’s Head of Developer Relations, called it “possibly the most consequential event in the AI industry I’ve seen up close since joining Anthropic almost 3 years ago.” That conviction is warranted. ‍ It is also pointing at half the problem. ‍ The AI your employees are actually using ‍ Glasswing is built around a specific threat: attackers using AI to find and exploit vulnerabilities in software infrastructure before defenders can patch them. That is a real and serious problem worth the investment. ‍ It is not, however, where most enterprise security teams are encountering AI risk day to day. ‍ The AI most employees interact with isn’t a foundation model their company deployed or controls. It’s a feature inside a SaaS subscription. Copilot inside Microsoft 365. Einstein inside Salesforce. Gemini inside Google Workspace. These didn’t arrive through a separate procurement process or a security review. They came embedded in tools employees already used, with permissions already granted, at the pace of a software update. ‍ That’s AI delivered as a layer on top of SaaS — and it represents the majority of enterprise AI activity. Cyera’s team described the visibility problem well: AI visibility without identity context is just a list. Knowing an AI agent exists tells you almost nothing. Knowing what it can access, what it’s doing, and whether that behavior makes sense given who authorized it — that’s the actual question security teams need to answer. Most can’t. ‍ The threat that doesn’t need to find a bug ‍ Glasswing targets the attack path that requires an adversary to identify a vulnerability and exploit it from outside the system. There’s a gap to cross. Time, skill, and opportunity all constrain how quickly that can happen. ‍ An AI agent operating inside your SaaS environment with a valid OAuth token doesn’t have that gap. It’s already in. It was provisioned, connected, and started operating. In many organizations, that happened without a formal security review, without a defined scope of access, and without any monitoring on what it does after the fact. ‍ One security team recently discovered 150 distinct Copilot agents running in their environment. All deployed in a single week. None reviewed by security. ‍ An attacker who compromises one of those agents — through prompt injection, a supply chain attack on the underlying model, or a misconfigured permission scope — doesn’t need to find a decade-old vulnerability. They inherit whatever the agent was authorized to do: read access to sensitive files, write access to shared drives, the ability to query CRM records or trigger downstream automations. ‍ The model most security tools are missing ‍ Most security tools were built to watch humans. They track logins, file access, configuration changes — all tied to human accounts. When an AI agent accesses 400 files in 15 minutes, those tools either attribute the action to the person who authorized it, or miss it entirely. ‍ That’s the wrong model. An AI agent acting on behalf of a user is not the same as the user acting. The behavioral baseline is different. The risk profile is different. The question you actually need to answer is whether this agent’s behavior makes sense given what it’s authorized to do, and given what the authorizing human normally does. Answering that requires holding identity, behavior, and SaaS context together in the same view. ‍ Most organizations don’t have that. Most tools weren’t built to provide it. The security community is already asking what Glasswing doesn’t cover. They’re right to ask. ‍ A note to Anthropic ‍ Project Glasswing is a genuine contribution. Using frontier AI to find vulnerabilities before attackers do is exactly the kind of asymmetric defense the industry needs, and the commitment from the launch partners reflects real organizational will. ‍ But here’s what’s worth sitting with: Claude is one of the AI agents already operating inside enterprise SaaS environments today. So is GPT. So is Gemini. The same class of models being pointed at software infrastructure to find vulnerabilities are also the agents that enterprise security teams need governance over — their access, their behavior, their blast radius if something goes wrong. ‍ Mythos is too powerful to release to the public. That’s a responsible call. The Claude versions already running inside enterprise SaaS are another matter entirely. They’re there. They have access. And in most organizations, nobody is watching them. ‍ Glasswing secures the infrastructure those models run on. That’s necessary. The other half — governing the agents already operating inside the application layer — is just as urgent. And it’s mostly still undone.

Read More →

Bitwarden CLI Compromised in Ongoing Checkmarx Supply Chain Campaign

Bitwarden CLI has been compromised as part of the newly discovered and ongoing Checkmarx supply chain campaign, according to new findings from JFrog and Socket. "The affected package version appears to be @bitwarden/cli@2026.4.0, and the malicious code was published in 'bw1.js,' a file included in the package contents," the application security company said. "The attack appears to have leveraged a compromised GitHub Action in Bitwarden's CI/CD pipeline, consistent with the pattern seen across other affected repositories in this campaign." In a post on X, JFrog said the rogue version of the package "steals GitHub/npm tokens, .ssh, .env, shell history, GitHub Actions and cloud secrets, then exfiltrates the data to private domains and as GitHub commits." Specifically, the malicious code is executed by means of a preinstall hook, resulting in the theft of local, CI, GitHub, and cloud secrets. The data is exfiltrated to the domain "audit.checkmarx[.]cx" and to a GitHub repository as a fallback if the primary method fails. The entire series of actions is listed below - It launches a credential stealer that targets developer secrets, GitHub Actions environments, and artificial intelligence (AI) coding tool configurations, including Claude, Kiro, Cursor, Codex CLI, and Aider. The stolen data is encrypted with AES-256-GCM and exfiltrated to audit.checkmarx[.]cx, a domain impersonating Checkmarx. If GitHub tokens are found, the malware weaponizes them to inject malicious Actions workflows into repositories and extract CI/CD secrets. "A single developer with @bitwarden/cli@2026.4.0 installed can become the entry point for a broader supply chain compromise, with the attacker gaining persistent workflow injection access to every CI/CD pipeline the developer’s token can reach," StepSecurity said While the malicious version is no longer available for download from npm, Socket said the compromise follows the same GitHub Actions supply chain vector identified in the Checkmarx campaign. As part of the effort, threat actors have been found abusing stolen GitHub tokens to inject a new GitHub Actions workflow that captures secrets available to the workflow run, and uses harvested npm credentials to push malicious versions of the package to read the malware to downstream users. According to security researcher Adnan Khan, the threat actor is said to have used a malicious workflow to publish the malicious bitwarden CLI. "I believe this is the first time a package using NPM trusted publishing has been compromised," Khan added. It's suspected that the threat actor known as TeamPCP is behind the latest attack aimed at Checkmarx. As of writing, TeamPCP's X account has been suspended for violating the platform's rules. OX Security, in a breakdown of the attack, said it identified the string "Shai-Hulud: The Third Coming" in the package, suggesting this could likely be the next phase of the supply chain attack campaign that came to light last year. "The latest Shai Hulud incident is just the latest in a long chain of threats targeting developers around the world. User data is being publicly exfiltrated to GitHub, often going undetected because security tools typically don't flag data being sent there," Moshe Siman Tov Bustan, Security Research Team Lead at OX Security, said. "This makes the risk significantly more dangerous: anyone searching GitHub can potentially find and access those credentials. At that point, sensitive data is no longer in the hands of a single threat actor – it’s exposed to anyone." Like in the case of the Checkmarx incident, the stolen data is exfiltrated to public repositories created under victim accounts using a Dune-themed naming scheme in the same format "<word>-<word>-<3 digits>. "But in an interesting shift, the malware is also designed to quit execution on systems if their locale corresponds to Russia. "The shared tooling strongly suggests a connection to the same malware ecosystem, but the operational signatures differ in ways that complicate attribution," Socket said. "This suggests either a different operator using shared infrastructure, a splinter group with stronger ideological motivations, or an evolution in the campaign's public posture." When reached for comment, Bitwarden confirmed the incident and said it stemmed from the compromise of its npm distribution mechanism following the Checkmarx supply chain attack, but emphasized that no end-user data was accessed as part of the attack. The entire statement shared with The Hacker News is reproduced verbatim below - The Bitwarden security team identified and contained a malicious package that was briefly distributed through the npm delivery path for @bitwarden/cli@2026.4.0 between 5:57 PM and 7:30 PM (ET) on April 22, 2026, in connection with a broader Checkmarx supply chain incident. The investigation found no evidence that end user vault data was accessed or at risk, or that production data or production systems were compromised. Once the issue was detected, compromised access was revoked, the malicious npm release was deprecated, and remediation steps were initiated immediately. The issue affected the npm distribution mechanism for the CLI during that limited window, not the integrity of the legitimate Bitwarden CLI codebase or stored vault data. Users who did not download the package from npm during that window were not affected. Bitwarden has completed a review of internal environments, release paths, and related systems, and no additional impacted products or environments have been identified at this time. A CVE for Bitwarden CLI version 2026.4.0 is being issued in connection with this incident.

Read More →