2026-05-13 AI创业新闻

New Exim BDAT Vulnerability Exposes GnuTLS Builds to Potential Code Execution

Exim has released security updates to address a severe security issue affecting certain configurations that could enable memory corruption and potential code execution. Exim is an open-source Mail Transfer Agent (MTA) designed for Unix-like systems to receive, route, and deliver email. The vulnerability, tracked as CVE-2026-45185, aka Dead.Letter, has been described as a use-after-free vulnerability in Exim’s binary data transmission (BDAT) message body parsing when a TLS connection is handled by GnuTLS. “The vulnerability is triggered during BDAT message body handling when a client sends a TLS close_notify alert before the body transfer is complete, and then follows up with a final byte in cleartext on the same TCP connection,” Exim said in an advisory released today.

“This sequence of events can cause Exim to write into a memory buffer that has already been freed during the TLS session teardown, leading to heap corruption. An attacker only needs to be able to establish a TLS connection and use the CHUNKING (BDAT) SMTP extension.” The issue impacts all Exim versions from 4.97 up to and including 4.99.2. That said, it only affects builds that use USE_GNUTLS=yes, meaning builds that rely on other TLS libraries like OpenSSL are not impacted. Federico Kirschbaum, head of Security Lab at XBOW, an autonomous cybersecurity testing platform, has been credited with discovering and reporting the flaw on May 1, 2026.

“During TLS shutdown, Exim frees its TLS transfer buffer – but a nested BDAT receive wrapper can still process incoming bytes and end up calling ungetc(), which writes a single character (\n) into the freed region,” Kirschbaum said . “That one-byte write lands on Exim’s allocator metadata, corrupting the allocator’s internal shape; the exploit then leverages that corruption to gain further primitives.” XBOW described the vulnerability as “one of the highest-caliber bugs” discovered in Exim to date, adding that triggering it requires almost no special configuration on the server. The shortcoming has been addressed in version 4.99.3. All users are advised to upgrade as soon as possible.

There are no mitigations that resolve the vulnerability. “The fix ensures that the input processing stack is cleanly reset when a TLS close notification is received during an active BDAT transfer, preventing the stale pointers from being used,” Exim noted. This is not the first time critical use-after-free bugs in Exim have been disclosed. In late 2017, Exim patched a use-after-free vulnerability in the SMTP daemon ( CVE-2017-16943 , CVSS score: 9.8) that unauthenticated attackers could have exploited to achieve remote code execution via specially crafted BDAT commands and seize control of the email server.

Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

RubyGems Suspends New Signups After Hundreds of Malicious Packages Are Uploaded

RubyGems , the standard package manager for the Ruby programming language, has temporarily paused account sign ups following what has been described as a “major malicious attack.” “We’re dealing with a major malicious attack on Ruby Gems right now,” Maciej Mensfeld, senior product manager for software supply chain security at Mend.io, said in a post on X. “Signups are paused for the time being. Hundreds of packages involved – mostly targeting us, but some carrying exploits.” Visitors to RubyGems’ sign up page are now greeted with the message: “New account registration has been temporarily disabled.” Mend.io, which secures RubyGems, said it intends to release more details once the incident is contained. It’s currently not known who is behind the attack.

The development comes as software supply chain attacks targeting open-source ecosystems have been on the rise, with threat actors like TeamPCP compromising widely used packages to distribute credential-stealing malware capable of harvesting sensitive data and allowing the attackers to expand their reach. In a report published Monday, Google said the credentials stolen from affected environments have been monetized through partnerships with ransomware and data theft extortion groups. (This is a developing story. Please check back for more details.) Found this article interesting?

New TrickMo Variant Uses TON C2 and SOCKS5 to Create Android Network Pivots

Cybersecurity researchers have flagged a new version of the TrickMo Android banking trojan that uses The Open Network (TON) for command-and-control (C2). The new variant, observed by ThreatFabric between January and February 2026, has been observed actively targeting banking and cryptocurrency wallet users in France, Italy, and Austria. “TrickMo relies on a runtime-loaded APK (dex.module), used also by the previous variant, but updated with new features adding new network-oriented functionality, including reconnaissance, SSH tunnelling, and SOCKS5 proxying capabilities that allow infected devices to function as programmable network pivots and traffic-exit nodes,” the Dutch mobile security company said in a report shared with The Hacker News. TrickMo is the name assigned to a device takeover (DTO) malware that’s been active in the wild since late 2019.

It was first flagged by CERT-Bund and IBM X-Force , describing its ability to abuse Android’s accessibility services to hijack one-time passwords (OTPs). It’s also equipped with a wide range of features to phish for credentials, log keystrokes, record screen, facilitate live screen streaming, intercept SMS messages, essentially granting the operator complete remote control of the device. The latest versions, labeled TrickMo C, are distributed via phasing websites and dropper apps, the latter of which serve as a conduit for a dynamically loaded APK (“dex.module”) that’s retrieved at runtime from attacker-controlled infrastructure. A notable shift in the architecture entails the use of the TON decentralized blockchain for stealthy C2 communications.

“TrickMo carries an embedded native TON proxy that the host APK starts on a loopback port at process start,” ThreatFabric said. “The bot’s HTTP client is wired through that proxy, so every outbound command-and-control request is addressed to an .adnl hostname and resolved through the TON overlay.” Dropper apps containing the malware masquerade as adult-friendly versions of TikTok through Facebook, whereas the actual malware impersonates Google Play Services - com.app16330.core20461 or com.app15318.core1173 (Dropper) uncle.collop416.wifekin78 or nibong.lida531.butler836 (TrickMo) While previous iterations of “dex.module” implemented the accessibility-driven remote control functionality through a socket.io-based channel, the new version utilizes a network-operative subsystem that turns the malware into a tool for managed foothold than a traditional banking trojan. The subsystem supports commands like curl, dnslookup, ping, telnet, and traceroute, giving the attacker a “remote shell-equivalent for network reconnaissance from the victim’s network position, including any internal corporate or home network the device is currently associated with,” per ThreatFabric. Another important feature is a SOCKS5 proxy that turns the compromised device into a network exit node that routes malicious traffic, while defeating IP-based fraud-detection signatures on banking, e-commerce and cryptocurrency exchange services.

Furthermore, TrickMo includes two dormant features that bundle the Pine hooking framework and declare extensive NFC-related permissions. But neither of them are actually implemented. This likely indicates the core developers are looking to expand on the trojan’s capabilities in the future. “Instead of relying on conventional DNS and public internet infrastructure, the malware communicates through .adnl endpoints routed via an embedded local TON proxy, reducing the effectiveness of traditional takedown and network-blocking efforts while making the traffic blend with legitimate TON activity,” ThreatFabric said.

“This latest variant also expands the operational role of infected devices through SSH tunnelling and authenticated SOCKS5 proxying, effectively turning compromised phones into programmable network pivots and traffic-exit nodes whose connections originate from the victim’s own network environment.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Webinar: What the Riskiest SOC Alerts Go Unanswered - and How Radiant Security Can Help

Why do the Riskiest SOC Alerts Go Unanswered? Security operations teams are drowning in alerts. But the real problem isn’t always alert volume; it’s the blind spots. The most dangerous alerts are the ones no one is investigating.

A recent report from The Hacker News examined why certain high-risk alert categories - WAF, DLP, OT/IoT, dark web intelligence, and supply chain signals- consistently go uninvestigated across enterprise SOCs. The findings point to a structural gap in how security coverage is delivered today: not a lack of tooling, but a ceiling built into every existing model. Your SOC Model Has a Coverage Ceiling In-house SOC teams are the first to feel the gap. Overloaded with high-volume, routine alerts, analysts rarely have the capacity, or the specialized expertise, to investigate WAF events, DLP anomalies, or signals from operational technology environments.

These alert types require deep, domain-specific knowledge that most SOC teams simply don’t have on staff. MSSPs and MDRs face a different version of the same problem. Complex, specialized alerts are time-consuming to investigate and require business context that managed providers don’t have. The economics don’t work in their favor, so they escalate these alerts back to the client, the same in-house team that lacked the capacity to investigate them in the first place.

AI SOC automation platforms have made significant progress on common alert types, but most cap out at four to six pre-defined categories. They rely on static, pre-built triage logic. When an alert falls outside that logic, whether it’s a novel threat, an unfamiliar alert source, or an emerging attack vector, the platform deprioritizes it or passes it on. The result is a blind spot at the intersection of all existing SOC models: the alerts most likely to result in a breach are precisely the ones for which no one has a workflow to handle.

Who Offers True Coverage
On May 21, 2026,
Radiant Security
and German cybersecurity firm Cirosec are hosting a technical webinar to address this gap directly:
“Alert Coverage No One Else Can Triage.”
The session will examine the structural reasons behind the coverage ceiling, walk through the specific alert types most commonly left uninvestigated, and demo live how Radiant’s AI SOC platform triages them. Radiant is built on a fundamentally different architecture than other AI SOC platforms. Rather than relying on pre-built playbooks, its AI generates custom triage logic on the fly, for any alert type, including ones the platform has never seen before. Webinar Details
Date:
May 21, 2026
Time:
15:00 CEST (6:00 AM PDT)
Format:
Microsoft Teams — technical, interactive session
Host:
Cirosec & Radiant Security
Language: English Register here to register (click translate page to English on your browser translator) Important note: the webinar will be in English.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Mini Shai-Hulud Worm Compromises TanStack, Mistral AI, Guardrails AI & More Packages

TeamPCP , the threat actor behind the recentsupply chain attack spree, has been linked to the compromise of the npm and PyPI packages from TanStack, UiPath, Mistral AI, OpenSearch, and Guardrails AI as part of a fresh Mini Shai-Hulud campaign. The affected npm packages have been modified to include an obfuscated JavaScript file (“router_init.js”) that’s designed to profile the execution environment and launch a comprehensive credential stealer capable of targeting cloud providers, cryptocurrency wallets, AI tools, messaging apps, and CI systems, including Github Actions, multiple reports from Aikido Security , Endor Labs , SafeDep , Socket , StepSecurity , and Snyk show. The data is exfiltrated to the “filev2.getsession[.]org” domain. Using Session Protocol infrastructure is a deliberate attempt on the part of the attackers to evade detection, as the domain is unlikely to be blocked within enterprise environments, given that it belongs to a decentralized, privacy-focused messaging service.

As a fallback option, the encrypted data is committed to attacker-controlled repositories under the author name “claude@users.noreply.github.com” via the GitHub GraphQL API using the stolen GitHub tokens. The malware is also capable of establishing persistence hooks in Claude Code and Microsoft Visual Studio Code (VS Code) to survive reboots and re-execute the stealer on every launch of the IDEs. Furthermore, it installs a gh-token-monitor service to monitor and re-exfiltrate GitHub tokens, and injects two malicious GitHub Actions workflows to serialize repository secrets into a JSON object and upload the data to an external server (“api.masscan[.]cloud”). Unlike the previous SAP wave , where the compromised packages added a preinstall hook to trigger the infection sequence, the latest TanStack cluster adopts a different strategy by including a JavaScript file within the package tarball and adding an optional dependency that points to a GitHub-hosted package.

The GitHub dependency contains a prepare lifecycle hook that executes the JavaScript payload via the Bun runtime. The updates to the Mistral AI packages, on the other hand, follow the earlier approach, replacing the contents of the “package.json” file with a preinstall hook to invoke “node setup.mjs,” which downloads Bun and runs the same JavaScript malware. The TanStack supply chain compromise has been assigned the CVE identifier CVE-2026-45321 . It carries a CVSS score of 9.6 out of a maximum of 10.0, indicating critical severity.

The incident has impacted 42 packages and 84 versions across the TanStack ecosystem. TanStack has since traced the compromise to a chained GitHub Actions attack involving the “pull_request_target” trigger, GitHub Actions cache poisoning , and runtime memory extraction of an OIDC token from the GitHub Actions runner process. “No npm tokens were stolen, and the npm publish workflow itself was not compromised,” TanStack said. Specifically, the attackers are assessed to have staged the malicious payload in a GitHub fork via an orphaned commit, injected it into published npm tarballs, then hijacked the project’s legitimate “TanStack/router” workflow to publish the compromised versions with valid SLSA provenance.

“The attack published malicious versions through the project’s own GitHub Actions release pipeline using hijacked OIDC tokens,” StepSecurity researcher Ashish Kurmi said. “In an extremely rare escalation, the compromised packages carry valid SLSA Build Level 3 provenance attestations, making this the first documented npm worm that produces validly attested malicious packages. The worm has since spread beyond TanStack to packages from UiPath, DraftLab, and other maintainers.” The attack is noteworthy for the fact that it abuses trusted publishing, allowing attacker-controlled code running within a workflow to leverage its OIDC permissions to “mint” a short-lived publish token during the build and use it to publish the packages without having to steal an npm token. What makes the worm stand out is its ability to spread itself to other packages by locating a publishable npm token with bypass_2fa set to true, enumerating every package published by the same maintainer, and exchanging a GitHub OIDC token for a per-package publish token to sidestep traditional authentication entirely.

“The orphaned commit additionally triggered a GitHub Actions workflow run against the legitimate TanStack/router workflow surface,” Endor Labs researcher Peyton Kennedy said. “Because the repository’s OIDC trusted publisher configuration granted trust at the repository level rather than scoped to a specific protected branch and workflow file, the workflow run triggered by that commit was able to request a valid short-lived npm publish token.” Another new behavior introduced in the obfuscated JavaScript malware is the installation of a dead-man’s switch that uses a shell script to periodically check if an npm token created by the malware is not revoked by polling the “api.github.com/user” endpoint every 60 seconds. The token has the description “IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner.” Should the developer revoke the token from their npm dashboard, the script triggers a destructive routine that executes “rm -rf ~/” on the infected machine, essentially turning it into a wiper malware. These changes indicate that TeamPCP is growing aggressive and evolving its tradecraft with every campaign.

It’s therefore essential that developers do not revoke the npm tokens before isolating and imaging the system. “This campaign reflects a broader shift in supply chain attacks from isolated package compromise to identity-driven propagation through trusted CI/CD infrastructure,” Avital Harel, security research lead at Upwind, said in a statement shared with The Hacker News. “Once attackers gain access to publishing workflows and pipeline identities, the software delivery process itself becomes the distribution mechanism. The challenge for defenders is that much of this activity can appear legitimate on the surface, which makes behavioral visibility during installs and builds increasingly important.” Besides TanStack, the Mini Shai-Hulud campaign has also spread to several other packages, including some in PyPI - guardrails-ai@0.10.1 (PyPI) mistralai@2.4.6 (PyPI) @opensearch-project/opensearch@3.5.3, 3.6.2, 3.7.0, and 3.8.0 @squawk/mcp@0.9.5 @squawk/weather@0.5.10 @squawk/flightplan@0.5.6 @tallyui/connector-medusa@1.0.1, 1.0.2, and 1.0.3 @tallyui/connector-vendure@1.0.1, 1.0.2, and 1.0.3 According to data from OX Security , the incident has affected over 170 packages spanning both the npm and PyPI registries.

The packages have more than 518 million downloads cumulatively. No less than 400 repositories with stolen credentials have been created as part of the attack wave. All the repositories contain the string “Shai-Hulud: Here We Go Again.” Google-owned Wiz said the payload also exfiltrates stolen credentials via a third redundant channel, a typosquat domain named “git-tanstack[.]com,” along with the Session messenger network and GitHub API dead drops using the stolen token, adding the trojanized PyPI packages associated with both Mistral AI and Guardrails AI contain the same malware, which “operates notably differently” from the JavaScript versions distributed via npm. Microsoft, in its analysis of the malicious mistralai PyPI package, said it’s designed to download a credential stealer from a remote server (“83.142.209[.]194”) that includes country-aware logic to avoid Russian-language environments and a “geofenced destructive branch that has a 1-in-6 chance of executing rm -rf / when the system appears to be in Israel or Iran.” “The guardrails-ai@0.10.1 compromise is especially notable because the malicious code executes on import,” Socket said.

“The package checks for Linux systems, downloads a remote Python artifact from https://git-tanstack.com/transformers.pyz, writes it to /tmp/transformers.pyz, and executes it with python3 without integrity verification.” “This latest activity shows the campaign continuing to propagate across both npm and PyPI, with affected packages spanning search infrastructure, AI tooling, aviation-related developer packages, enterprise automation, frontend tooling, and CI/CD-adjacent ecosystems.” (The story was updated after publication to include additional insights.) Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Agentic AI is already running in production environments across many organizations today. It is executing tasks, consuming data, and taking actions — most likely without meaningful involvement from the security team. The industry conversation has largely framed this as a question of policy: allow it, restrict it, or monitor it? However, that framing misses the point.

The more urgent question is whether security professionals actually understand what they are dealing with. In most organizations, they don’t right now. And that gap is compounding by the week. You cannot secure what you do not understand The foundational principle of information security has not changed: genuine fluency in a technology must come before you can meaningfully defend it.

Think about firewalls. You cannot configure one well without understanding networking. When cloud computing arrived, organizations that skipped the foundational work ended up with environments they could not reason about — tools purchased, policies written, and still no real control. We have cloud security as its own discipline today precisely because the technology demanded that practitioners develop deep familiarity with it before security could follow.

The same dynamic is playing out with AI, at a faster pace and with higher stakes. The practical consequence of being behind on agentic AI goes beyond technical exposure. Security teams that cannot speak the language of AI engineering — that cannot challenge design decisions, propose workable controls, or ask informed questions — get bypassed. Business units move forward without them, not out of bad faith, but because a security team that cannot engage substantively with the technology is not a useful partner for decisions about it.

This has played out with every major technology shift over the past two to three decades. AI will be no different. The starting point is engagement. Try building an agent.

Experiment with the tools your developers are already using. This hands-on familiarity is where real understanding begins, and real understanding is what makes everything else possible. Three categories of agents, three categories of risk The agentic AI landscape is broad, and the risk profile varies significantly across it. Three categories are worth understanding distinctly.

The first is general-purpose coding and productivity agents — tools like Claude Code and GitHub Copilot. These are already embedded in developer and engineering workflows across your organization. Whether they have been formally approved or not, they are being used. What data they can access, how they interact with codebases, and what actions they can take is baseline security knowledge at this point.

The second is vendor-built agents powered by the Model Context Protocol , or MCP. MCP is the integration layer that allows agents to connect to external services and act on their behalf. Nearly every major vendor either has an MCP server in production or is actively building one. In practice, this means an agent managing a user’s calendar, email, or internal ticketing system can receive input from those channels and act on it.

A malicious calendar invite carrying hidden instructions in the event description is a real attack vector — the agent reads it, interprets the embedded prompt, and executes. This is a live attack surface that requires deliberate configuration and security review. The third category is custom agents built by individual users , and this is where the dynamic gets particularly interesting. For years, a real barrier existed between security practitioners who understood risk and the code that ran in their environments.

Most security professionals are not programmers. Building custom tooling required development skills that were not widely distributed across security teams. That barrier is gone. With agentic AI, anyone in the organization can build functional tools — automations, workflows, agents with real system access — without writing traditional code.

For security teams, this is genuinely valuable. Incident investigation, forensic triage, threat hunting workflows — these can be accelerated when practitioners can build the tools they actually need. But that same capability extends to every other team. Marketing, finance, operations — everyone can build agents now.

Many will. Most of those agents will not go through a security review before they go live. This is a supply chain problem in a different form. The cost of arriving late When security teams lag behind on a major technology shift, the pattern is consistent.

First, the rest of the organization moves forward without security input. Developers deploy, business units adopt, and security is consulted as a formality — or not at all. Second, the exposure compounds. The more powerful the agents an organization deploys, the more access those agents require.

Broad permissions are what make agents useful: access to calendars, communication platforms, file systems, code repositories, internal APIs. That access is also what makes the blast radius significant when something goes wrong. An agent with access to both a terminal and an email inbox can be manipulated through either channel to act in the other. That is a lateral movement path an attacker will look for.

Reasoning about it requires understanding how the agent was built — the kind of understanding that only comes from genuine engagement with the technology. The skills that matter right now Building competency in agentic AI security requires two distinct layers of knowledge. The first is understanding how AI applications are architected — from a practitioner’s perspective, not a data scientist’s. What are the components of an AI application?

How do agents consume inputs, chain tools together, and produce outputs? What does a session with an MCP-connected agent actually look like from an access control standpoint? This is the foundation that makes everything else actionable. The second layer is currency .

The tooling and threat landscape around AI is moving fast. Vendors are building security controls for AI systems, though most are still maturing. Open-source frameworks are emerging. OWASP and others are publishing threat taxonomies that evolve week to week.

Once the foundational layer is in place, staying current becomes the ongoing discipline — knowing which tools are worth evaluating, which frameworks are gaining traction, and what questions to ask when vendors come in with solutions. That second point matters more than it might seem. Security teams are already being approached by vendors selling AI security products. Without foundational knowledge of how these applications are built, those conversations are almost impossible to navigate well.

You cannot distinguish a well-designed control from a marketing wrapper if you don’t understand what you’re trying to control. Configuration as a security control Many agentic AI deployments carry risk because they were stood up without security-conscious configuration — not because the underlying tools are fundamentally broken. Take a self-hosted AI assistant connected to a communication channel like Telegram, which can be common. without proper controls, the agent could respond to anyone who messages it.

That is a wide-open entry point. A simple configuration change — pairing the agent with a single trusted account — closes most of that exposure. One decision, made early, with a meaningful security outcome. The broader principle is scope.

An agent built to manage your calendar should not have access to your terminal. An agent processing incoming requests should not have write access to your code repository. Scoping agents to their intended function limits the blast radius and reduces the attack surface available for exploitation. The tension is real: powerful agents need broad access to be useful.

That is the trade-off organizations will push back on. Finding the right balance requires security involvement early in the design process — before the architecture is set and before the permissions are already in place. Getting ahead of it at SANSFIRE 2026 The organizations building genuine AI security fluency now will be positioned to shape how these systems are deployed. Those who arrive late will find themselves, once again, applying controls to an architecture that was already decided without them.

This July, I will be teaching SEC545: GenAI and LLM Application Security at SANSFIRE 2026. The course covers how AI applications are actually built, how agentic systems work in practice, the real attack surfaces security teams need to understand, and the tools and controls available to address them — including hands-on work with techniques like model scanning to detect compromised models before they run in your environment. For practitioners who want to engage with AI systems from a foundation of real understanding, this is where to start. Register for SANSFIRE 2026 here.

Note: This article has been expertly written and contributed by Ahmed Abugharbia, SANS Certified Instructor. Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Instructure Reaches Ransom Agreement with ShinyHunters to Stop 3.65TB Canvas Leak

American educational technology company Instructure, the parent company of Canvas, said it reached an “agreement” with a decentralized cybercrime extortion group after it breached its network and threatened to leak stolen information from thousands of schools and universities. In an update shared on Monday, the Utah-based firm said it “reached an agreement with the unauthorized actor involved in this incident,” citing “concerns about the potential publication of data.” In taking the controversial decision to pay a ransom to avoid a leak, the company said the agreement covers all its impacted customers and that the pilfered data was returned to it, along with digital confirmation of data destruction. It also said it has been informed that none of the company’s customers will be separately extorted as a result of the hack. “While there is never complete certainty when dealing with cyber criminals, we believe it was important to take every step within our control to give customers additional peace of mind, to the extent possible,” Instructure said .

It also said it’s working with expert vendors to support its forensic analysis, improve its cybersecurity posture, and conduct a comprehensive review of the data involved. The disclosure comes as the ShinyHunters extortion crew waged a digital attack against Canvas, a popular web-based learning management system, late last month, resulting in the theft of 3.65TB of data. The incident impacted nearly 9,000 organizations. Although the breach was assumed to be initially contained, a second wave of unauthorized activity tied to the same incident was detected on May 7, 2026, defacing the Canvas login portals with extortion messages at roughly 330 institutions and giving Instructure a deadline of May 12, 2026, to negotiate a ransom or risk a data leak.

The attackers are said to have weaponized an unspecified vulnerability “regarding support tickets” in its Free-for-Teacher environment to obtain initial access and siphon about 275 million records containing usernames, email addresses, course names, enrollment information, and messages. Instructure has emphasized that course content, submissions, and credentials were not compromised. In the wake of the breach, Instructure has temporarily shut down Free-For-Teacher accounts. The company did not disclose the nature of the vulnerability, but said it revoked privileged credentials and access tokens for affected systems, rotated internal keys, restricted token creation pathways, and deployed additional security controls.

“The exfiltrated data provides threat actors enough personal context to conduct targeted phishing campaigns against staff, students, and parents alike,” Halcyon said. “Leaked records can be used to impersonate school administrators, IT support, or financial aid offices in follow-on attacks. Students, parents, and personnel at affected institutions should be considered, and institutions should issue phishing advisories and direct communications immediately.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

OpenAI Launches Daybreak for AI-Powered Vulnerability Detection and Patch Validation

OpenAI has launched Daybreak , a new cybersecurity initiative that brings together frontier artificial intelligence (AI) model capabilities and Codex Security to help organizations identify and patch vulnerabilities before attackers find a way in using the same issues. “Daybreak combines the intelligence of OpenAI models, the extensibility of Codex as an agentic harness, and our partners across the security flywheel to help make the world safer for everyone,” the AI upstart said . “Defenders can bring secure code review, threat modeling, patch validation, dependency risk analysis, detection, and remediation guidance into the everyday development loop so software becomes more resilient from the start.” Like Anthropic’s Mythos , the idea is to leverage AI to tilt the balance in favor of defenders and help detect and address security issues before they are found by bad actors. Access to the tooling remains tightly controlled for now, with OpenAI urging interested organizations to request for a vulnerability scan or contact its sales team.

Daybreak leverages Codex Security to build an editable threat model for a given repository that focuses on realistic attack paths and high-impact code, identify and test vulnerabilities in an isolated environment, and propose fixes. The effort is built on the foundations of three models: GPT-5.5 (which has standard safeguards for general purpose use), GPT-5.5 with Trusted Access for Cyber (for verified defensive work in authorized environments), and GPT-5.5-Cyber (a permissive model for red teaming, penetration testing, and controlled validation). Several major companies like Akamai, Cisco, Cloudflare, CrowdStrike, Fortinet, Oracle, Palo Alto Networks, and Zscaler are already integrating these capabilities under the Trusted Access for Cyber initiative, OpenAI said, adding it’s working with industry and government partners to deploy “more cyber-capable models” in the future. The rollout comes as AI tools have shortened the time it takes to discover latent security issues that may have otherwise escaped notice, turning what would once have taken a significant amount of time and effort into a much shorter period of work.

As a result, the patching process can struggle to keep up even under ideal conditions. Earlier this March, HackerOne paused its bug bounty program citing a shift in balance between vulnerability discoveries and the ability for open-source maintainers to address them, attributing it to how AI-assisted research has led to an uptick in the volume of new flaws and the speed at which they are identified. This also has had the side effect of what’s called triage fatigue, where project maintainers are required to sift through a flood of vulnerability reports, some of which could be plausible-sounding but entirely hallucinated by the AI models. As AI lowers the barrier to finding security flaws, companies like Anthropic, Google, and OpenAI have increasingly positioned AI security agents as a new operational layer to address the remediation bottleneck and safeguard digital infrastructure from potential exploitation.

In a post published last week, security researcher Himanshu Anand said “the 90 day disclosure policy is dead,” as large language models (LLMs) compress disclosure and exploit timelines to near-zero. “When 10 unrelated researchers find the same bug in six weeks, and AI can turn a patch diff into a working exploit in 30 minutes, what exactly is the 90-day window protecting? Nobody,” Anand said. Found this article interesting?

iOS 26.5 Brings Default End-to-End Encrypted RCS Messaging Between iPhone and Android

Apple on Monday officially released iOS 26.5 with support for end-to-end encryption (E2EE) to Rich Communication Services (RCS) in beta as part of a “cross-industry effort” to replace traditional SMS with a more secure alternative. To that end, E2EE RCS messaging is rolling out to iPhone users running iOS 26.5 with supported carriers and Android users on the latest version of Google Messages. The feature is enabled by default for both new and existing conversations in both platforms. RCS is a modern, internet-based messaging protocol that allows Android and iPhone users to send high-resolution photos and videos, see typing indicators, and receive read receipts, features all typically present in instant messaging apps.

It is built on an industry specification called the RCS Universal Profile . “When RCS messages are end-to-end encrypted, they can’t be read while they’re sent between devices,” Apple said in a statement. “Users will know that a conversation is end-to-end encrypted when they see a new lock icon in their RCS chats.” Apple began testing with E2EE in RCS messages in iOS and iPadOS 26.4 Beta, initially limiting it to only conversations between Apple devices. In early 2025, the GSM Association (GSMA) announced support for E2EE for safeguarding messages sent via the RCS protocol.

In a similar statement, Google said Google Messages for Android users will see a padlock icon to indicate that the cross-platform conversation is end-to-end encrypted. “This welcome progress is the result of close, cross‑industry collaboration between the GSMA RCS Working Group, including Apple, Google, and the wider mobile ecosystem,” Alex Sinclair, chief technology officer at GSMA, said . “Crucially, the new secure services are being delivered on an open, globally recognised foundation.” The latest updates also come with fixes for over 50 vulnerabilities in iOS and iPadOS, including various flaws in AppleJPEG, ImageIO, Kernel, mDNSResponder, and WebKit that could be exploited to leak sensitive information, a denial-of-service (DoS), or result in unexpected system termination. Found this article interesting?

TeamPCP Compromises Checkmarx Jenkins AST Plugin Weeks After KICS Supply Chain Attack

Checkmarx has confirmed that a modified version of the Jenkins AST plugin was published to the Jenkins Marketplace. “If you are using Checkmarx Jenkins AST plugin, you need to ensure that you are using the version 2.0.13-829.vc72453fa_1c16 that was published on December 17, 2025 or previously,” the cybersecurity company said in a statement over the weekend. As of writing, Checkmarx has released 2.0.13-848.v76e89de8a_053 on both GitHub and the Jenkins Marketplace. A spokesperson for the company said the new version addresses the concerns associated with the incident.

It’s assessed that the malicious code was published after obtaining credentials from a previous supply chain attack that took place in March 2026. The development is the latest attack orchestrated by TeamPCP targeting Checkmarx. It arrives a couple of weeks after the notorious cybercrime group was attributed to the compromise of its KICS Docker image, two VS Code extensions, and a GitHub Actions workflow to push credential-stealing malware. The breach, in turn, resulted in the brief compromise of the Bitwarden CLI npm package to serve a similar stealer that can harvest a wide range of developer secrets.

TeamPCP has been linked to a series of breaches since March 2026 as part of a sprawling campaign that exploits the inherent trust in the software supply chain to propagate its malware and expand its reach. According to details shared by security researcher Adnan Khan and SOCRadar , TeamPCP is said to have gained unauthorized access to the plugin’s GitHub repository and renamed it to “Checkmarx-Fully-Hacked-by-TeamPCP-and-Their-Customers-Should-Cancel-Now.” The defaced repository was also updated to include the description: “Checkmarx fails to rotate secrets again. with love – TeamPCP.” “The fact that TeamPCP is back inside Checkmarx systems just weeks later points to one of two possibilities: either the initial remediation was incomplete and credentials were not fully rotated, or the group retained a foothold that wasn’t identified during the March response,” SOCRadar said. “A second Checkmarx incident happening this soon suggests the group is actively watching for re-entry points, testing the depth of past remediations, and capitalizing on any gaps.” (The story was updated after publication to include a response from Checkmarx.) Found this article interesting?

cPanel CVE-2026-41940 Under Active Exploitation to Deploy Filemanager Backdoor

A threat actor named Mr_Rot13 has been attributed to the exploitation of a recently disclosed critical cPanel flaw to deploy a backdoor codenamed Filemanager on compromised environments. The attack exploits CVE-2026-41940 , a vulnerability impacting cPanel and WebHost Manager (WHM) that could result in an authentication bypass and allow remote attackers to gain elevated control of the control panel. According to a new report from QiAnXin XLab, the security defect has been exploited by a number of threat actors shortly after its public disclosure late last month, resulting in malicious behaviors like cryptocurrency mining, ransomware, botnet propagation, and backdoor implantation. “Monitoring data shows that more than 2,000 attacker source IPs worldwide are currently involved in automated attacks and cybercrime activities targeting this vulnerability,” XLab researchers said.

“These IPs are distributed across multiple regions globally, primarily originating from Germany, the United States, Brazil, the Netherlands, and other regions.” Further analysis of the ongoing exploitation activity has uncovered a shell script that uses wget or curl to download a Go-based infector from a remote server (“cp.dene.[de[.]com”) that first modifies the compromised cPanel system’s root password to “123Qwe123C,” plants an SSH public key for persistent access, and then drops a PHP web shell that facilitates file upload/download and remote command execution. The web shell is then used to inject JavaScript code to serve a customized login page to steal login credentials and siphon them to an attacker-controlled system that’s encoded using the ROT13 cipher (“ wrned[.]com “). Once the details are transmitted, the attack chain culminates with the deployment of a cross-platform backdoor that’s capable of infecting Windows, macOS, and Linux systems. The infector is also equipped to collect sensitive information from the compromised host, including bash history, SSH data, device information, database passwords, and cPanel virtual aliases (aka valiases), to a 3-member Telegram group created by a user named “0xWR.” In the infection sequence analyzed by XLab, Filemanager is delivered via a shell script downloaded from the “wpsock[.]com” domain.

The backdoor supports file management, remote command execution, and shell functionality. There are signs that the threat actor behind the operation has been operating silently in the shadows for years. This assessment is based on the fact that the command-and-control (C2) domain embedded in the JavaScript code has been put to use in a PHP-based backdoor (“ helper.php “) that was uploaded to the VirusTotal platform in April 2022. The domain was first registered in October 2020.

“Over the six years from 2020 to the present, the detection rate of Mr_Rot13’s related samples and infrastructure across security products has remained extremely low,” XLab said. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Hackers Used AI to Develop First Known Zero-Day 2FA Bypass for Mass Exploitation

Google on Monday disclosed that it identified an unknown threat actor using a zero-day exploit that it said was likely developed with an artificial intelligence (AI) system, marking the first time the technology has been put to use in the wild in a malicious context for vulnerability discovery and exploit generation. The activity is said to be the work of cybercrime threat actors who appear to have collaborated together to plan what the tech giant described as a “mass vulnerability exploitation operation.” “Our analysis of exploits associated with this campaign identified a zero-day vulnerability implemented in a Python script that enables the user to bypass two-factor authentication (2FA) on a popular open-source, web-based system administration tool,” Google Threat Intelligence Group (GTIG) said in a report shared with The Hacker News. The tech giant said it worked with the impacted vendor to responsibly disclose the flaw and get it fixed in order to proactively disrupt the activity. It did not disclose the name of the tool.

Although there is no evidence to suggest that Google’s Gemini AI tool was used to aid the threat actors, GTIG assessed with high confidence that an AI model was weaponized to facilitate the discovery and weaponization of the flaw via a Python script that featured all hallmarks typically associated with large language model (LLM)-generated code. “For example, the script contains an abundance of educational docstrings, including a hallucinated CVSS score, and uses a structured, textbook Pythonic format highly characteristic of LLMs training data (e.g., detailed help menus and the clean _C ANSI color class),” GTIG added. The vulnerability, described as a 2FA bypass, requires valid user credentials for exploitation. It stems from a high-level semantic logic flaw arising as a result of a hard-coded trust assumption, something LLMs excel at spotting.

“AI is already accelerating vulnerability discovery, reducing the effort needed to identify, validate, and weaponize flaws,” Ryan Dewhurst, watchTowr’s Head of Threat Intelligence, told The Hacker News in a statement. “This is today’s reality: discovery, weaponization, and exploitation are faster. We’re not heading toward compressed timelines; we’ve been watching the timelines compress for years. There is no mercy from attackers, and defenders don’t get to opt out.” The development comes as AI is not only acting as a force multiplier for vulnerability disclosure and abuse, but is also enabling attackers to develop polymorphic malware and conduct autonomous malware operations, as observed in the case of PromptSpy , an Android malware that abuses Gemini to analyze the current screen and provide it with instructions to pin the malicious app in the recent apps list.

Further investigation of the backdoor has uncovered a broader set of capabilities to allow the malware to navigate the Android user interface and autonomously monitor and interpret real-time user activity to determine the next course of action using an autonomous agent module. PromptSpy is also equipped to capture victim biometric data to replay authentication gestures, such as a lock screen PIN or a pattern, to regain access to a compromised device. On top of that, it’s capable of preventing uninstallation by making use of an “AppProtectionDetector” module that identifies the on-screen coordinates of the “Uninstall” button and serves an invisible overlay just over the button to block a victim’s touch events and give the impression that the button is unresponsive. “While PromptSpy initializes using hardcoded default infrastructure and credentials, the malware is designed with high operational resilience, allowing adversaries to rotate critical components at runtime without redeploying the PromptSpy payload,” Google said.

“Specifically, the malware’s command-and-control (C2) infrastructure, including the Gemini API keys and the VNC relay server, can be updated dynamically via the C2 channel. This configuration model demonstrates the developers anticipated defensive countermeasures and engineered the backdoor to maintain presence even if specific infrastructure endpoints are identified and blocked by defenders.” Google said it took steps against PromptSpy by disabling all assets related to the malicious activity. No apps containing the malware have been discovered on the Play Store. Some other cases of Gemini-specific abuse spotted by Google are listed below - A suspected China-nexus cyber espionage group dubbed UNC2814 prompted Gemini by asking it to assume the role of a network security expert to trigger persona-driven jailbreaking and support vulnerability research into embedded device targets, including TP-Link firmware and Odette File Transfer Protocol (OFTP) implementations.

The North Korean threat actor known as APT45 (aka Andariel and Onyx Sleet) sent “thousands of repetitive prompts” that recursively analyze different CVEs and validate proof-of-concept (PoC) exploits. A Chinese hacking group known as APT27 leveraged Gemini to speed up the development of a fleet management application with an aim to likely manage an operational relay box (ORB) network. A cluster of Russia-nexus intrusion activity targeted Ukrainian organizations to deliver AI-enabled malware dubbed CANFAIL and LONGSTREAM, both of which use LLM-generated decoy code to conceal their malicious functionality. Threat actors have also been found experimenting with a specialized GitHub repository named “ wooyun-legacy “ that’s designed as a Claude code skill plugin featuring over 5,000 real-world vulnerability cases collected by the Chinese vulnerability disclosure platform WooYun between 2010 and 2016.

“By priming the model with vulnerability data, it facilitates in-context learning to steer the model to approach code analysis like a seasoned expert and identify logic flaws that the base model might otherwise fail to prioritize,” Google explained. Elsewhere, a suspected China-aligned threat actor is said to have deployed agentic tools like Hexstrike AI and Strix in an attack targeting a Japanese technology firm and a major East Asian cybersecurity platform to conduct automated discovery with minimal human oversight. Google also said it continues to see information operations (IO) actors from Russia, Iran, China, and Saudi Arabia using AI for common productivity tasks like research, content creation, and localization, even as it called out China-affiliated threat activity from UNC6201 that involved the use of a publicly available Python script to automatically register and immediately cancel premium LLM accounts. “This process highlights the methods adversaries leverage to procure high-tier AI capabilities at scale while insulating their malicious activity from account bans,” GTIG pointed out.

“Threat actors now pursue anonymized, premium-tier access to models through professionalized middleware and automated registration pipelines to illicitly bypass usage limits. This infrastructure enables large-scale misuse of services while subsidizing operations through trial abuse and programmatic account cycling.” Another China-linked activity flagged by Google originates from UNC5673 (aka TEMP.Hex), which has employed various publicly available commercial tools and GitHub projects to likely facilitate scalable LLM abuse. The findings overlap with recent reports about a thriving grey market of API relay platforms that allow local developers in China to illicitly access Anthropic Claude and Gemini. These relay or transfer stations route access to the AI models through proxy servers that are hosted outside mainland China.

The services are advertised on Chinese online marketplaces Taobao and Xianyu. In a study published in March 2026, academics from the CISPA Helmholtz Center for Information Security found 17 shadow APIs that claim to provide access to official model services without regional limitations via indirect access. A performance evaluation of these services uncovered evidence of model substitution, exposing AI applications to unintended safety risks. “On high-risk medical benchmarks like MedQA, the accuracy of the Gemini-2.5-flash model drops precipitously, from 83.82% with the official API to approximately 37.00% across all examined shadow APIs,” the researchers said in the paper.

What’s more, the proxy services can capture every prompt and response that passes through their servers, providing the operators with unlawful access to a goldmine of data that could then be used for fine-tuning models and conducting illicit knowledge distillation . In recent months, AI environments have also become the target of adversaries like TeamPCP (aka UNC6780), exposing developers to supply chain attacks and enabling attackers to burrow deeper into compromised networks for follow-on exploitation. “For example, threat actors with access to an organization’s AI systems could leverage internal models and tools to identify, collect, and exfiltrate sensitive information at scale or perform reconnaissance tasks to move deeper within a network,” Google said. “While the level of access and particular use depends heavily on the organization and the specific compromised dependency, this case study demonstrates the broadened landscape of software supply chain threats to AI systems.” Found this article interesting?