Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Showing posts with label API. Show all posts

Hugging Face Breach Raises Concerns Over AI-Driven Attacks

 



Hugging Face is investigating a security incident after its production infrastructure was compromised in an intrusion the company says involved an autonomous AI agent, raising fresh concerns about how artificial intelligence could reshape offensive cyber operations.

In a security disclosure published on July 16, the open-source AI platform said the attack leveraged an autonomous agent framework built on top of an agentic security research environment powered by a large language model (LLM). According to the company, the system executed thousands of actions across multiple sandboxed environments, allowing the attackers to move through internal infrastructure and obtain unauthorized access to datasets and service credentials.

The company said the intrusion began when a malicious dataset exploited two separate code execution paths on a processing worker. After establishing an initial foothold, the attacker reportedly escalated privileges to node-level access before collecting cloud and cluster credentials and moving laterally into several internal clusters.

Hugging Face has not yet confirmed whether customer or partner information was affected and said its investigation remains ongoing.

The incident has attracted attention across the cybersecurity community because it suggests that AI systems may now be capable of carrying out increasingly complex intrusion workflows with limited human intervention. Unlike traditional automated malware or scripts that perform predefined tasks, autonomous AI agents can adapt to changing environments, plan sequences of actions and make decisions throughout an attack.

Researchers have long warned that advances in generative AI could lower the barrier for sophisticated cyberattacks by accelerating vulnerability discovery, reconnaissance, privilege escalation and post-compromise activities. While many of these scenarios have remained largely theoretical, Hugging Face's disclosure indicates that elements of these capabilities may already be appearing in real-world operations.

According to the company's investigation, the attacking system generated thousands of individual actions during the compromise, demonstrating a level of operational scale that would normally require substantial manual effort.

Hugging Face co-founder and CEO Clément Delangue said the incident reinforces the view that threat actors are already adopting AI agents in offensive operations. He also argued that restricting advanced AI models behind commercial APIs alone is unlikely to prevent misuse because determined attackers can often circumvent safety controls, while defenders may lose valuable access to tools needed for security research and incident response.

The company encountered another challenge during its investigation when content moderation mechanisms on a frontier AI model reportedly prevented analysts from processing portions of the attack data. To continue the forensic investigation, the security team instead relied on GLM-5.2, an open-weight language model that was deployed within Hugging Face's own infrastructure.

Using the model, investigators reconstructed the attack timeline, identified indicators of compromise, mapped affected credentials and accelerated forensic analysis that would otherwise have required significantly more manual effort. The company also revoked compromised credentials, rotated authentication tokens and remediated the exploited vulnerability.

Security researchers say the incident highlights both the opportunities and limitations of AI-assisted security operations. While AI can substantially reduce investigation time by processing large volumes of telemetry, organizations may encounter operational constraints if externally hosted models refuse to analyze sensitive security artifacts because of built-in safety guardrails.

Industry experts increasingly argue that enterprises should maintain trusted self-hosted AI models that can support internal incident response without exposing sensitive forensic data to external services.

The disclosure comes amid bigger concerns about the growing availability of permissive AI models that operate with fewer content restrictions. Recent threat intelligence research has identified thousands of publicly accessible models advertised as uncensored or unrestricted, raising concerns that malicious actors have expanding access to AI systems capable of assisting offensive cyber activities.

Cybersecurity professionals caution that AI is changing the economics of cybercrime by enabling attackers to automate portions of reconnaissance, exploitation, credential harvesting and post-compromise operations. As these technologies continue to mature, sophisticated attack capabilities may become accessible to a broader range of threat actors.

For defenders, the incident reinforces the need to integrate AI into security operations rather than relying solely on conventional manual workflows. AI-assisted detection, forensic analysis and incident response are increasingly becoming essential capabilities as organizations attempt to match the speed and scale of modern attacks.

Although the investigation into the Hugging Face breach remains ongoing, the incident serves as another indication that autonomous AI systems are beginning to influence both offensive and defensive cybersecurity strategies. As organizations continue adopting AI throughout their technology environments, security teams will need to prepare for a future in which machine-speed attacks are met with equally intelligent defensive capabilities.

Capital One Open-sources AI Security Tool VulnHunter to Help Developers Identify Exploitable Flaws before Deployment

 




Capital One has released VulnHunter, an open-source AI-powered application security tool designed to identify exploitable software vulnerabilities before code reaches production. Published under the Apache 2.0 licence, the framework combines agentic reasoning with code analysis to trace how an attacker could move through an application, determine whether a vulnerability is genuinely exploitable, and generate remediation guidance for developers.

Unlike many traditional static analysis tools that begin with suspicious code patterns and work backwards to determine whether they are reachable, VulnHunter adopts what Capital One describes as an attacker-first approach. The framework starts from external entry points such as API endpoints, network message handlers and file upload interfaces before following the application's execution path to assess whether malicious input can successfully bypass existing security controls and reach vulnerable code.

A distinguishing component of the framework is its built-in falsification engine. Rather than presenting every suspected issue to developers, VulnHunter attempts to invalidate its own findings by testing assumptions, examining application logic and identifying conditions that would prevent an exploit from succeeding. Findings that fail these internal verification steps are discarded, while validated issues are accompanied by a detailed explanation of the attack path, supporting evidence gathered from the codebase and a proposed code change that developers can review before deployment.

Capital One said the current implementation operates within Anthropic's Claude Code environment using Claude Opus 4.8, although the framework has been designed with the flexibility to support additional foundation models and coding environments in the future.

The financial institution said it decided to release the project publicly because software supply chains have become increasingly interconnected, making application security a shared challenge rather than one that can be solved by individual organisations. Chris Nims, Capital One's Chief Information Security Officer, said the growing accessibility of AI-driven offensive capabilities has reduced the time defenders have to identify and remediate vulnerabilities before they can be exploited by attackers. By making VulnHunter openly available, the company hopes security researchers and developers will continue improving the framework while strengthening software security across the wider ecosystem.

The release builds on Capital One's wider investment in open-source software and secure software development. The company began publishing open-source projects more than a decade ago, later adopting an open-source-first strategy and expanding its participation in community-driven security initiatives. It has since contributed to dozens of public projects and joined the Open Source Security Foundation (OpenSSF) as a premier member to support collaborative efforts around software supply chain security and governance.

Capital One also said it evaluated VulnHunter internally across thousands of software repositories spanning multiple business units before its public release. According to the company, the framework helped identify and remediate vulnerabilities more efficiently than previous manual review processes by reducing unnecessary alerts and providing developers with evidence-backed remediation guidance.

The announcement comes as organisations increasingly explore AI-assisted approaches to application security in response to the growing use of AI by threat actors to discover software weaknesses, automate exploit development and accelerate attacks. Security teams have also faced persistent challenges with alert fatigue caused by conventional vulnerability scanners that frequently generate false positives requiring extensive manual verification.

Capital One believes embedding security analysis directly into the software development lifecycle can help organisations identify exploitable weaknesses earlier, allowing developers to address issues before applications are deployed. As AI continues to reshape both offensive and defensive cybersecurity capabilities, tools that combine contextual code analysis, automated reasoning and actionable remediation may become an increasingly important part of modern secure software development practices.



Telegram Introduces Serverless Runtime for Bots, Bringing Deployment, Application Logic, and Data Under One Platform

 



Telegram has rolled out Telegram Serverless, a managed serverless runtime that enables developers to deploy bot backends directly to Telegram's infrastructure with a single "npx tgcloud push" command, eliminating the need for external servers, cloud functions or container platforms. While the service streamlines bot deployment by combining application logic, database storage and Telegram's Bot API within one environment, it also changes where bot data is processed and stored, shifting workloads that developers previously hosted themselves onto Telegram's own infrastructure.

Before the launch, Telegram bots typically relied on a split architecture. Telegram was responsible for delivering messages through the Bot API, while developers operated separate backends on virtual private servers, managed cloud services or self-hosted infrastructure to execute application logic and store user data. That approach required additional operational overhead but allowed organisations to determine where conversation data was hosted, how long it was retained and which security or compliance policies governed it. Telegram Serverless removes that separation by allowing developers to build JavaScript-based bot backends that execute directly alongside Telegram's messaging platform.

Applications are organised around event handlers, shared libraries and a database schema definition, with Telegram routing incoming updates to the appropriate handler automatically. The runtime executes JavaScript inside V8 isolates, lightweight execution environments also used by platforms such as Cloudflare Workers and Deno Deploy. Unlike virtual machines or containers, V8 isolates share a single operating system process while maintaining isolated memory spaces, allowing workloads to start within milliseconds and support large numbers of concurrent applications with lower resource overhead. Telegram also provides a built-in SQLite-backed database that applications can access through the runtime alongside native Bot API integration and outbound HTTP requests.

The platform includes a staged migration workflow that separates application deployment from database changes. Developers can review pending schema modifications before applying them, with low-risk changes processed automatically, higher-risk operations requiring confirmation and complex schema alterations left to manual SQL execution. Telegram's documentation also notes that SQLite foreign key enforcement is disabled within the runtime, meaning relational constraints must be maintained in application code rather than the database itself. At present, Telegram has not documented a method for exporting bot databases from the Serverless environment.

The runtime also introduces several architectural limitations. Developers are restricted to Telegram's SDK, with support limited to runtime APIs rather than the broader JavaScript ecosystem. The platform currently does not provide access to npm packages, native extensions or filesystem operations, while file handling is limited to media already stored on Telegram using existing "file_id" references. These constraints, combined with the absence of a documented database export mechanism, could make migrating applications to another hosting environment more challenging.

The launch also carries privacy implications. Bot conversations are processed through Telegram's standard messaging infrastructure and, unlike Secret Chats, are not protected by end-to-end encryption. Although this has always applied to Telegram bots, Serverless now places application logic and bot databases inside Telegram's infrastructure as well, reducing the degree of control developers previously had over where user information was processed and retained. Telegram has also not disclosed additional operating system-level isolation measures beyond its use of V8 isolates, making the platform's broader security architecture difficult to evaluate.

Several operational details also remain undisclosed, including execution time limits, storage quotas, pricing and secure secret management for third-party API credentials. These specifications are commonly published by established serverless providers and are important for organisations assessing production deployments. For developers building chatbots, Mini Apps and automation services, Telegram Serverless substantially lowers deployment complexity, but wider adoption may depend on greater transparency around platform limits, security safeguards and long-term data governance.

Digital Banking’s Expanding Ecosystem Creates New Cybersecurity Challenges, Report Warns

 

Three Russian Nationals Indicted for Operating Bulletproof Hosting Network that Facilitated Ransomware, Phishing, and Malware Attacks that Generated Over $62 Million in Illicit Proceeds Three Russian nationals have been indicted by the United States for allegedly running a bulletproof hosting network that facilitated ransomware, phishing, malware, and other cybercrime activities that generated over $62 million in proceeds. 

The indictment was unsealed by the United States Attorney’s Office, Northern District of Ohio, after a seven-year-long investigation. Alexander Alexandrovich Volosovik, Kirill Andreevich Zatolokin, and Yulia Vladimirovna Pankova, and their companies Media Land LLC and ML.Cloud LLC, have been charged with conspiracy to commit computer fraud and wire fraud, money laundering, and enabling computer fraud. 

Media Land and ML.Cloud are alleged to have operated out of St. Petersburg, Russia, with servers located in China, Finland, the Netherlands, the United States, and other countries. The companies are accused of providing hosting services that enabled customers to carry out ransomware and malware attacks, phishing, domain name obfuscation, brute-force attacks, criminal marketplaces, and extortion using cryptocurrencies. Media Land and ML.Cloud are also accused of providing technical support that enabled threat actors to carry out attacks while evading detection. 

The companies are alleged to have targeted banks, hospitals, schools, government agencies, media organizations, and other entities in 21 states within the United States. Other victims are reported to be in Australia, Canada, the European Union, the United Arab Emirates, the United Kingdom, and other countries. In addition to the indictment, the United States Department of State has offered a reward of up to $10 million for information that could lead to the identification of foreign government officials involved in the companies’ activities. 

The reward is part of the Rewards for Justice program. The indictment followed the imposition of sanctions against Media Land, ML.Cloud, and the three Russians by the United States, the United Kingdom, and Australia, for their alleged role in facilitating ransomware, distributed denial-of-service (DDoS), and other cybercrime activities. The European Union also imposed sanctions against the firms and individuals in July 2026. 

The investigation into the companies was conducted by the FBI Cleveland Division with the support of the Cybersecurity and Infrastructure Security Agency, the Treasury Office of Foreign Assets Control, and law enforcement agencies in the Netherlands, the United Kingdom, and Australia. Authorities noted that bulletproof hosting companies provide essential infrastructure for ransomware, phishing, and malware-as-a-service criminal organizations and should be prioritized for investigation and disruption.

Digital Banking’s Expanding Ecosystem Creates New Cybersecurity Challenges, Report Warns

 

The rapid development of digital banking services and financial technologies is resulting in an unprecedented cybersecurity paradigm, which the current security posture is not equipped to handle,” says the report titled ‘Digital Threat Report 2025-26’, complied by the Ministry of Electronics and Information Technology (MeitY), CERT-In, CSIRT-Fin, and cybersecurity firm SISA. “The cyber security landscape for banking is shifting due to an increasing reliance on connected financial systems, embedded finance, artificial intelligence (AI), real-time payments, APIs, and third-party services,” says the report. 

“Unlike isolated legacy banking systems, where the attack surface was limited to the core banking application, contemporary interconnected systems allow attackers to target relationships rather than the bank itself”. It further says that modern cyber threats are now exploiting the trust surface between systems rather than infiltrating individual institutions and organizations. “Modern cyber threats are targeting the biometric onboarding, partner applications, AI-driven payments, processing and settlement flows, APIs, programmable finance, and connected payment ecosystems. 

The attack surface has broadened with the interconnectedness of finance and the involvement of numerous entities in delivering financial services,” the report says. According to the report, the cyber security challenges for the banking sector and the financial ecosystem at large are also exacerbated by a lack of harmonization in regulatory oversight; hence, a regulatory lag is allowing threat actors to expand their reach. 
“Banking identities in digital payment systems are the cornerstone of contemporary finance,” the report states. “An attacker compromising an individual’s digital identity would be able to threaten, disrupt, and impact multiple financial accounts, applications, and platforms rather than individual banking applications as traditionally known. 

Attackers could also compromise the integrity of compliance monitoring systems, masking their actions or suppressing critical security alerts by modifying logs or monitoring tools.” “The traditional network perimeter is no longer the exclusive domain of a bank or financial institution,” the report adds. 

“Banks should transition from a mindset of protecting the network to securing the extended, distributed ecosystem comprising interconnected platforms, partnerships, APIs, cloud infrastructures, AI, and identity management.” The report says that as digital finance grows more sophisticated, organizations need to rethink their security approaches and strategies to account for the dynamic and distributed nature of such a platform.

Why AI Agents Are Challenging Identity Security


The wide adoption of AI agents is forcing organizations to rethink identity security as enterprises contend with an expanding population of non-human identities that increasingly outnumber employee accounts. While identity and access management programs have traditionally focused on managing people throughout their employment lifecycle, autonomous software identities are exposing governance gaps that many organizations are still struggling to address.

Unlike human users, machine identities, including AI agents, service accounts, workload identities, OAuth applications, and API credentials, are created to authenticate systems, automate processes, and enable communication between applications. As organizations embrace cloud computing, automation, and generative AI, these identities are being created at a pace that often exceeds traditional governance processes.

Human identities typically follow a predictable lifecycle. Employees are onboarded, assigned appropriate access, promoted or transferred to new roles, and eventually offboarded when they leave an organization. These lifecycle events form the foundation of identity governance, allowing security teams to periodically review permissions and revoke unnecessary access.

Machine identities operate differently. They may be generated automatically when new cloud workloads are deployed, inherit permissions from existing applications, communicate across multiple enterprise platforms, or exist only briefly before being replaced. Others remain active long after the application, automation workflow, or development project that created them has been retired. Without continuous oversight, organizations can lose visibility into who owns these identities, why they still exist, and what sensitive resources they are capable of accessing.

The scale of this challenge continues to grow. According to the Non-Human Identity Management Group, machine identities can outnumber human users by as much as 50 to one across many enterprise environments. While these identities are essential for modern business operations, security teams frequently struggle to maintain accurate inventories or establish clear ownership for every credential operating within their environments.

The security implications became evident during the UNC6395 campaign in 2025, when attackers reportedly obtained an OAuth token associated with Salesloft's Drift chat integration and leveraged the trusted credential to move across Salesforce environments used by hundreds of organizations. Rather than exploiting a software vulnerability, the attackers abused an identity that had already been authorized within enterprise systems. Investigations found that the compromised access enabled attackers to obtain additional secrets, including AWS credentials and Snowflake tokens, demonstrating how a single trusted machine identity can provide a pathway to multiple connected environments.

AI agents are not creating an entirely new category of identity risk, but they are accelerating an existing challenge. Modern AI systems increasingly perform tasks autonomously, interact with multiple business applications, retrieve sensitive information, and execute workflows without continuous human involvement. As these agents operate across cloud services, they introduce additional trusted identities, inherit permissions from existing accounts, and expand the number of credentials that organizations must secure.

This rapid growth creates a governance challenge that extends beyond simple visibility. Security teams may know that identities exist, but effective identity security also requires understanding who owns each identity, what permissions it has been granted, what sensitive data it can reach, and when that identity should no longer exist. Without continuous lifecycle management, dormant or forgotten machine identities can quietly expand an organization's attack surface.

Findings published in the 2026 Data and Identity Security Report illustrate the scale of the problem. Organizations that reported AI exponentially increasing the number of identities within their environments experienced a 43% breach rate over the previous year, compared with 11% among organizations where AI had not substantially expanded their identity footprint. Notably, many organizations affected by breaches also reported implementing stronger governance practices, suggesting that visibility alone is insufficient if identity ownership, permissions, and access reviews are not continuously maintained.

As enterprises continue integrating AI into daily operations, identity security is becoming less about managing employee accounts and more about governing a rapidly expanding ecosystem of trusted non-human identities. Maintaining comprehensive identity inventories, enforcing least-privilege access, continuously reviewing permissions, and assigning clear ownership to every human and machine identity will be essential to reducing risk. As AI agents become more autonomous, the identities organizations overlook may prove just as valuable to attackers as those they actively monitor.

Researchers Warn of Unpatched Argo CD Flaw That Enables Cluster Takeover

 


Organizations using Argo CD to automate application deployments on Kubernetes are being urged to review their network configurations after security researchers disclosed an unpatched vulnerability that could allow attackers to execute arbitrary code on the platform's repo-server component and ultimately seize control of an entire Kubernetes cluster.

The vulnerability was identified by French cybersecurity firm Synacktiv, which says the issue affects the repo-server, a core Argo CD service responsible for retrieving application source code from Git repositories and converting it into Kubernetes manifests before workloads are deployed. Because the repo-server sits at the center of the GitOps deployment process, compromising it gives an attacker an opportunity to interfere with how applications are delivered throughout the cluster.

According to the researchers, exploitation does not require authentication. An attacker only needs network access to the repo-server's internal gRPC service, which accepts requests from other Argo CD components but does not verify the identity of the caller. Once that communication channel becomes reachable, a specially crafted request can be used to trigger remote code execution on the vulnerable service.

Synacktiv reported the vulnerability to the Argo CD maintainers in January 2025 through a responsible disclosure process. However, roughly eighteen months later, the issue remains unresolved, with no official security patch or CVE identifier assigned. The researchers chose to disclose their findings publicly to give administrators time to strengthen their deployments while awaiting a permanent fix.

At the center of the attack is Argo CD's repo-server, which continuously retrieves application definitions stored in Git repositories and prepares them for deployment by generating Kubernetes manifests. These manifests describe the desired state of applications, including containers, services, networking, storage, and other deployment configurations that Kubernetes uses to build and manage workloads. Since every deployment passes through this component, gaining control of the repo-server can provide attackers with extensive influence over the software being deployed inside a cluster.

The vulnerability stems from an unauthenticated internal gRPC interface exposed by the repo-server. gRPC is a high-performance communication framework commonly used for communication between services inside distributed applications. In Argo CD's design, the interface is intended for trusted internal communication. However, Synacktiv found that the service performs no authentication checks, allowing any system capable of reaching the port to submit requests that the repo-server will process.

The researchers demonstrated the attack against Argo CD version 2.13.3. They noted that no patched release currently exists and did not publish a complete list of affected versions, leaving administrators without a definitive inventory of vulnerable deployments.

To achieve code execution, the attack abuses Kustomize, a Kubernetes configuration management tool that Argo CD relies on to generate deployment manifests. Kustomize can also invoke Helm, another widely used package manager for Kubernetes, through the "--helm-command" option that specifies which executable should be launched.

Instead of directing Kustomize to the legitimate Helm binary, Synacktiv discovered that an attacker can send a malicious GenerateManifest request instructing it to execute a script stored inside an attacker-controlled Git repository. When Kustomize begins processing the deployment, it unknowingly launches the attacker's script in place of Helm, providing arbitrary code execution within the repo-server environment.

Although the vulnerable interface is intended to remain internal, the researchers warn that internal services should not automatically be considered secure. Kubernetes clusters frequently host dozens or even hundreds of interconnected workloads, and a compromise affecting a single pod can become the starting point for lateral movement if internal communication is not properly restricted.

Argo CD includes Kubernetes NetworkPolicy resources designed to limit access to sensitive services such as the repo-server and Redis. However, Synacktiv found that these protections are disabled by default when Argo CD is deployed using its Helm chart because the "networkPolicy.create" option is set to "false". As a result, installations that rely on the default configuration may unintentionally leave the repo-server reachable from other workloads running inside the cluster.

In such environments, compromising a single pod may be enough for an attacker to contact the repo-server and exploit the vulnerability.

The researchers also demonstrated that remote code execution represents only the beginning of the attack chain. After obtaining execution on the repo-server, they extracted the Redis password stored in an environment variable, authenticated to Argo CD's Redis instance, and modified cached deployment information. When Argo CD later performed its routine synchronization with the Git repository, the poisoned cache caused the platform to deploy an attacker-controlled workload instead of the intended application.

According to Synacktiv, this technique effectively revives a previously addressed weakness tracked as CVE-2024-31989. That earlier vulnerability, discovered by Cycode, exposed Argo CD deployments where Redis lacked password protection, allowing any pod inside the cluster to manipulate deployment cache data. Although Argo CD later introduced Redis password protection to address that issue, the cache contents themselves remain unsigned. By stealing the Redis credentials through the newly disclosed repo-server vulnerability, attackers can once again tamper with deployment data and recreate a similar compromise path.

With no software update currently available, researchers recommend treating network segmentation as the primary line of defense. Administrators should enable Kubernetes NetworkPolicy rules to ensure that only legitimate Argo CD components can communicate with the repo-server and Redis services. Organizations deploying Argo CD through Helm should verify that these policies have been explicitly enabled rather than relying on the chart's default configuration.

Administrators can inspect active network policies by running:

"kubectl get networkpolicy -A"

A properly secured deployment should display dedicated network policies protecting each Argo CD component, including both the repo-server and Redis. Missing policies may indicate that sensitive internal services remain accessible to other workloads inside the cluster.

To help organizations evaluate their exposure, Synacktiv developed a proof-of-concept tool named argo-cdown, capable of automating the complete attack chain. The researchers have postponed its public release to provide defenders with additional time to secure vulnerable environments. The tool is expected to be published on GitHub later, allowing administrators to validate the effectiveness of their own security controls.

The newly disclosed vulnerability is the latest in a series of security issues affecting Argo CD's privileged position within Kubernetes environments. In September 2025, the project patched CVE-2025-55190 after researchers found that an API token with only basic read permissions could retrieve Git repository credentials associated with a project. Several months later, in May 2026, another flaw tracked as CVE-2026-42880 enabled read-only users to access plaintext Kubernetes secrets.

Taken together, these incidents point to a recurring challenge rather than isolated implementation flaws. Argo CD occupies one of the most privileged positions within Kubernetes deployments, maintaining access to source repositories, deployment pipelines, cluster resources, and sensitive credentials. As a result, weaknesses affecting its internal services can quickly become pathways to broader infrastructure compromise.

Until an official patch becomes available, organizations should assume that internal cluster traffic cannot always be trusted. Restricting communication between workloads, enabling Kubernetes NetworkPolicy protections, and limiting access to critical Argo CD services remain the most effective measures for reducing exposure to this newly disclosed attack technique.

Agentic AI Has Become an Identity Crisis for Enterprise Security Teams



Every major technological change has followed a familiar pattern: organizations embrace innovation first, while security teams are left adapting controls after deployment. Cloud computing, Software-as-a-Service (SaaS), and DevOps all reshaped enterprise security in this way. Agentic AI is now driving the next transformation, but with a more complex challenge. Unlike conventional applications, AI agents actively authenticate, interact with APIs, query databases, generate code, and execute workflows across production environments, often using credentials and permissions that organizations have yet to fully catalogue.

This changes the conversation around AI security. Rather than focusing solely on what an AI model can generate, security leaders must determine who an AI agent represents, what systems it can access, who is accountable for its actions, and whether its privileges can be modified or revoked as business requirements evolve.

Traditional identity and access management programs were designed around employees whose access follows established roles and review processes. The rapid expansion of machine identities, including service accounts, API keys, certificates, and workload identities, already challenged that approach. Autonomous AI agents introduce another level of complexity because they can interpret objectives, make decisions, and perform actions independently while operating at machine speed. They can also be deployed by developers, embedded into SaaS platforms, delegated permissions by users, and continue running long after their original purpose has ended.

Static access controls are increasingly inadequate for these systems. An AI assistant summarizing customer support tickets requires far fewer privileges than one capable of issuing refunds, modifying customer records, or deploying production infrastructure. Instead of relying on permanent permissions, organizations should adopt contextual, task-specific, time-limited, and continuously evaluated access policies that adjust according to an agent's responsibilities.

The rapid growth of agentic AI also introduces three identity risks that security teams cannot ignore. Many enterprises already lack visibility into AI agents operating across cloud services, developer environments, and business applications, making ownership and accountability difficult to establish. At the same time, broad permissions granted during testing frequently evolve into long-term identity debt, leaving agents with unnecessary administrative access. Attackers are also exploiting prompt injection techniques, manipulating trusted agents through untrusted content to perform unintended actions when effective privilege boundaries are absent.

Addressing these risks requires identity-centric governance rather than a separate AI security strategy. Every AI agent should possess a unique identity, a clearly assigned owner, a defined business purpose, and a controlled lifecycle supported by strong credential management and continuous monitoring. Automated discovery, policy enforcement, and access reviews will become essential as organizations deploy growing numbers of autonomous systems.

As enterprises integrate agentic AI into everyday operations, the security question is no longer limited to what AI can produce. The greater concern is what autonomous agents are authorized to do, and whether those identities remain governed throughout their entire lifecycle. Organizations that strengthen identity governance today will be better positioned to embrace AI-driven innovation without expanding their attack surface.

Signed Lenovo Driver Could Be Misused to Shut Down Security Software, Researcher Warns

 


A security researcher has uncovered a weakness in a Lenovo-signed Windows driver that could allow attackers to disable antivirus and endpoint security tools, potentially weakening a system's defenses before carrying out additional malicious activity.

The finding involves BootRepair.sys, a driver linked to Lenovo PC Manager. According to research conducted by security researcher Jehad Abudagga, the driver contains functionality that can be exploited to terminate processes directly from the Windows kernel. Because the file is legitimately signed by Lenovo, it may appear trustworthy to operating systems and security products that rely on digital signatures when evaluating software.

At the time of the analysis, the driver, identified by the SHA-256 hash 5ab36c116767eaae53a466fbc2dae7cfd608ed77721f65e83312037fbd57c946, reportedly had no detections on VirusTotal. Security researchers note that attackers often favor signed and seemingly legitimate software components because they can help malicious activity blend into normal system operations.

The research surfaces the growing nature of this particular attack technique known as Bring Your Own Vulnerable Driver, or BYOVD. In these attacks, threat actors deliberately use trusted but flawed drivers to gain elevated capabilities inside a system. Rather than exploiting security software directly, attackers abuse weaknesses in legitimate drivers to bypass protections and interfere with defensive tools.

A detailed examination of BootRepair.sys revealed several security weaknesses. The driver creates a device object called "\Device\::BootRepair" without applying a secure discretionary access control list (DACL). In practical terms, this means users with limited privileges may still be able to communicate with the driver.

The driver also creates a symbolic link named "\DosDevices\BootRepair," making the functionality accessible from user-mode applications. Researchers further found that the driver does not perform access-control validation when processing IRP_MJ_CREATE requests. As a result, any user can potentially obtain a handle to the driver without undergoing meaningful permission checks.

Analysis of the driver's input and output control functionality identified a single exposed IOCTL code, 0x222014. This control code accepts a four-byte input buffer that contains a process identifier, commonly referred to as a PID. Once received, the PID is passed to an internal routine responsible for terminating the specified process.

The underlying mechanism relies on the Windows kernel function ZwTerminateProcess. Because the operation is performed in kernel mode, the driver can terminate processes that would ordinarily be protected from interference. This includes security-sensitive services and endpoint protection products that are designed to prevent unauthorized shutdown attempts.

According to the research, these weaknesses create two primary attack opportunities. If the driver is already installed on a target system, an attacker with limited privileges could interact with it directly and terminate antivirus or endpoint detection and response (EDR) processes. If the driver is not present, an attacker could deploy the signed driver as part of a BYOVD operation, load it into the kernel, disable security controls, and then proceed with post-compromise activities.

In a proof-of-concept demonstration, the researcher showed that even protected processes could be terminated once the driver had been loaded. The test used standard Windows APIs to communicate with the driver. The process involved opening a handle to "\\.\BootRepair," sending a target process identifier through IOCTL code 0x222014, and allowing the driver to terminate the selected process from kernel mode.

The simplicity of the proof-of-concept demonstrates how little effort may be required to exploit the functionality once access to the driver is available. Researchers warn that after security products are disabled, attackers may be able to run credential theft tools, information stealers, or other post-exploitation utilities with a lower likelihood of detection.

The findings also reinforce concerns surrounding BYOVD attacks, which have become increasingly common in ransomware operations and advanced intrusion campaigns. Because vulnerable drivers often carry legitimate digital signatures, they can sometimes evade security controls that place significant trust in signed software.

To reduce exposure, organizations are encouraged to implement Microsoft's vulnerable driver blocklist, monitor systems for unusual driver-loading activity, restrict the installation of unauthorized drivers, and watch for suspicious kernel-level behavior. Security teams should also ensure that endpoint protection platforms are configured to detect attempts to abuse legitimate drivers.

The research serves as another example of how trusted software components can become security liabilities when design weaknesses are present. As attackers continue searching for legitimate tools that can be repurposed for malicious activity, organizations will need stronger controls around driver management, behavioral monitoring, and endpoint visibility to prevent security products from being disabled before an attack fully unfolds.

Ubuntu DDoS Attack Disrupts Installs Updates and Canonical Infrastructure

 

A wave of traffic overwhelmed systems, briefly halting downloads, patches, and web resources managed by Canonical - the team responsible for Ubuntu Linux. Outages stretched nearly twenty-four hours, blocking access to essential tools during the incident. 

Midway through the disruption, Canonical confirmed issues affecting its online systems, calling them a prolonged international cyber incident. With efforts already underway to bring functions back online, progress reports were expected later via verified sources after conditions improved. 

Not just external sites felt the impact - insights from casual chats on unaffiliated Ubuntu message boards pointed to deeper issues. Failures popped up across several core functions: the security API stumbled, repository access broke, setup tools froze, package upgrades failed. When the outage struck, countless machines could neither pull patches nor start clean installs. The ripple spread wider than first assumed. 

A claim of responsibility emerged afterward, attributed to an entity calling itself The Islamic Cyber Resistance in Iraq 313 Team. Supposed messages circulated on Telegram suggest they relied on a service named Beemed - one that facilitates distributed denial-of-service attacks - to execute the incident. While details remain sparse, the method points toward accessible cyber tools being leveraged for disruptive purposes. Heavy network floods emerge when tools like Beamed hand out DDoS power to anyone willing to pay, masking harm behind so-called "testing" labels. 

Instead of building safeguards, some misuse these setups to drown web systems in endless data streams. With advertised force climbing toward 3.5 terabits each second, one sees how readily extreme digital pressure becomes a purchasable option. A single flood of fake signals can overwhelm digital infrastructure when launched from countless hijacked gadgets online. 

Such an event forces critical systems to choke on excessive demand, blocking normal access. Real people experience delays or complete service failures as their requests get lost in chaos. Machines turned into unwilling helpers generate relentless noise instead of useful responses. Performance drops sharply once capacity limits are breached without warning. Genuine interactions fade under pressure from artificial congestion. 

Most times, hacking groups start by slipping malicious software onto gadgets, sometimes using poor login codes instead of strong ones. From there, machines already taken over get bundled together - forming massive clusters run from far away via command centers online. These hijacked setups often change hands in hidden digital bazaars; launching short outages becomes possible for cheap, while heavier assaults require deeper spending. 

What follows? Buyers pick time-limited chaos or go all-in for longer surges. Surprisingly, more DDoS attacks happen now due to widespread access to self-running malware that exploits weak device protections across countries. While strong networks may resist some threats, major companies still face interruptions since hackers pair huge bot-driven data floods with focused attack plans.  

The Ubuntu event underscores how fragile key open-source tools have become - tools that developers, businesses, and public agencies depend on worldwide. When update servers or security interfaces go offline briefly, ripple effects follow. Patching halts. System rollouts stall. All of this unfolds while digital attacks are already underway.

India’s Cybersecurity Workforce Struggles to Keep Pace as AI and Cloud Systems Expand

 



India’s fast-growing digital economy is creating an urgent demand for cybersecurity professionals, but companies across the country are finding it increasingly difficult to hire people with the technical expertise required to secure modern systems.

A new study released by the Data Security Council of India and SANS Institute found that businesses are facing a serious shortage of skilled cybersecurity workers as technologies such as artificial intelligence, cloud computing, and API-driven infrastructure become more deeply integrated into daily operations.

According to the Indian Cyber Security Skilling Landscape Report 2025–26, nearly 73 per cent of enterprises and 68 per cent of service providers said there is a limited supply of qualified cybersecurity professionals in the country. The report suggests that organisations are struggling to build teams capable of handling increasingly advanced cyber risks at a time when companies are rapidly digitising services, storing more information online, and adopting AI-powered tools.

The hiring process itself is also becoming slower. Around 84 per cent of organisations surveyed said cybersecurity positions often remain vacant for one to six months before suitable candidates are found. This delay reflects a growing mismatch between industry expectations and the skills available in the job market.

Researchers noted that many applicants entering the cybersecurity workforce lack practical exposure to real-world security environments. Around 63 per cent of enterprises and 59 per cent of service providers said candidates often do not possess sufficient hands-on technical experience. Employers are no longer only looking for basic security knowledge. Companies increasingly require professionals who understand multiple areas at once, including cloud infrastructure, application security, digital identity systems, and access management technologies. Nearly 58 per cent of enterprises and 60 per cent of providers admitted they are struggling to find candidates with this type of cross-functional expertise.

The report connects this shortage to the changing structure of enterprise technology systems. Many organisations are moving away from traditional on-premise setups and shifting toward cloud-native environments, interconnected APIs, and AI-supported operations. As businesses automate more routine tasks, demand is gradually moving away from entry-level operational positions and toward specialised cybersecurity roles that require analytical thinking, threat detection capabilities, and advanced technical decision-making.

Artificial intelligence is now becoming one of the largest drivers of cybersecurity hiring demand. Around 83 per cent of organisations surveyed described AI and generative AI security skills as essential for future operations, while 78 per cent reported strong demand for AI security engineers. The findings also show that nearly 62 per cent of enterprises are already running active AI or generative AI projects, which experts say can create additional security risks if systems are not properly monitored and protected.

As companies deploy AI systems, the attack surface for cybercriminals also expands. Security teams are now expected to defend AI models, protect sensitive datasets, monitor automated systems for manipulation, and secure APIs connecting multiple digital services. Industry experts have repeatedly warned that many organisations are adopting AI tools faster than they are building security frameworks around them.

Some cybersecurity positions remain especially difficult to fill. The report found that almost half of service providers and nearly 40 per cent of enterprises are struggling to recruit security architects, professionals responsible for designing secure digital infrastructure and long-term defence strategies. Demand is also increasing for specialists in operational technology and industrial control system security, commonly known as OT/ICS security. These professionals help protect critical infrastructure such as manufacturing facilities, power systems, transportation networks, and industrial operations from cyberattacks.

At the same time, companies are facing growing retention problems. Around 70 per cent of service providers and 42 per cent of enterprises said employees are frequently leaving for competitors offering better salaries and career opportunities. Limited access to advanced training and upskilling programs is also contributing to workforce attrition across the sector.

The findings point to a larger issue facing the cybersecurity industry globally: technology is evolving faster than workforce development. Experts believe companies, educational institutions, and training organisations may need to work more closely together to create industry-focused learning pathways that prepare professionals for modern cyber threats instead of relying heavily on theoretical instruction alone.

With India continuing to expand digital public infrastructure, cloud adoption, fintech services, AI development, and connected industrial systems, cybersecurity professionals are expected to play a central role in protecting sensitive information, maintaining operational stability, and preserving trust in digital platforms.

ClickUp API Key Exposure Leaves Corporate and Government Email Data Public for Over a Year

 

A previously unnoticed weakness in ClickUp’s web infrastructure sat undetected - exposing private data due to an embedded API key left visible on its public site. For over twelve months, access to internal records remained possible because safeguards were missing at a basic level. Emails tied to businesses and official agencies could be pulled by outside parties; no login required. This gap emerged not from complex hacking but from routine coding oversights ignored during deployment. Hidden credentials like these often escape review until examined closely. Months passed before scrutiny revealed what should have been caught earlier. Security gaps of this kind stem less from advanced threats and more from everyday lapses repeated across teams. 

Open talk about the problem began when security analyst Impulsive shared findings showing the leaked credential sat inside a JavaScript file served by ClickUp's site, even before login steps occurred. Since code running in browsers can always be seen, grabbing the API key took little effort and allowed contact with internal servers. Without needing any special access, one basic query allegedly pulled close to a thousand emails plus vast numbers of hidden development settings from the system. The study showed that 959 employee email addresses were part of the leaked data, tied to staff in large companies and public institutions spanning various locations. 

About 3,165 feature flags also turned up in the exposure - visible without restriction. Hidden inside what looks like routine code, these flags might expose how teams test software, plan releases, roll out new tools, or shape future updates. Because of that, malicious actors might mine them to craft deceptive emails, manipulate individuals through tailored messages, or collect insights on rivals’ progress. Surprisingly useful intel often hides where it seems least likely. Early in 2025, news of the exposure surfaced - yet by April 2026, it still hadn’t been fixed, stretching out the time hackers could act. Because access stayed open so long, experts say attackers gained more chances to try breaking in using stolen login details, fake identities, or personalized emails targeting workers linked to the affected websites. 

What happened shows a wider issue for groups depending on cloud-based services. Though easy to avoid, fixed login details remain common in today’s coding practices. When secret access tokens appear in open-source repositories, bots usually find them fast - sometimes in under sixty seconds. Even low-level access codes can lead to large data leaks if internal systems lack strong verification rules. Rotating API keys often helps lower exposure over time. Client-side apps without embedded secrets tend to withstand attacks better. Strict limits on backend access form another layer of defense. 

Protection against phishing gains strength when using tools like DMARC, SPF, or DKIM. Unusual logins catch attention faster with constant tracking. Exposed domains become visible through active threat data streams. Security improves not by one fix alone, but steady adjustments across systems. A quiet mistake lingered unseen within ClickUp's system, revealing data widely before detection. When operations move into shared online environments, oversight gaps often emerge - making careful monitoring essential. Security lapses like this highlight growing pressure on organizations to act earlier, respond smarter, stay alert longer.

Researchers Reproduce Anthropic-Style AI Vulnerability Findings Using Public Models at Low Cost

 


New research suggests that the ability to discover software vulnerabilities using artificial intelligence is becoming both inexpensive and widely accessible, raising concerns that advanced cyber capabilities may be spreading faster than anticipated.

A study by Vidoc Security demonstrates that vulnerability discovery techniques similar to those highlighted in Anthropic’s recent “Mythos” work can be reproduced using publicly available AI models. By leveraging GPT-5.4 and Claude Opus 4.6 within an open-source framework called opencode, researchers were able to replicate key findings for under $30 per scan, without access to Anthropic’s internal systems or restricted programs.

Anthropic had earlier positioned its Mythos research as highly sensitive, limiting access to a small group of major organizations and prompting concern across policy and financial circles. Reports indicated that senior figures, including Scott Bessent and Jerome Powell, discussed the implications alongside leading financial executives. The term “vulnpocalypse” resurfaced in cybersecurity discussions, reflecting fears of large-scale AI-driven exploitation.

The Vidoc team sought to test whether such capabilities were truly restricted. Using patched vulnerability examples referenced in Anthropic’s public materials, they examined issues affecting a file-sharing protocol, a security-focused operating system’s networking components, widely used video-processing software, and cryptographic libraries used for identity verification online.

Across three independent runs, both models successfully reproduced two of the documented vulnerability cases each time. Claude Opus 4.6 also independently rediscovered a flaw in OpenBSD in all three attempts, while GPT-5.4 failed to identify that specific issue. In other instances, including vulnerabilities tied to FFmpeg and wolfSSL, the systems correctly identified relevant code regions but did not fully determine the root cause.

The methodology closely mirrored workflows described by Anthropic. Instead of relying on a single prompt, the system first analyzed entire codebases, divided them into smaller segments, and ran parallel detection processes. These processes filtered meaningful signals from noise and cross-checked findings across files. Importantly, the selection of code segments was automated through earlier planning steps, rather than manually guided.

Despite these results, the study underlines a clear distinction. Anthropic’s system reportedly went beyond identifying vulnerabilities by constructing detailed exploit pathways, such as chaining code fragments across multiple network packets to achieve full remote control of a system. The public models, while capable of locating weaknesses, did not reach that level of execution.

According to researcher Dawid Moczadło, this indicates a new turn of events in cybersecurity economics. The most resource-intensive part of the process, identifying credible vulnerability signals, is becoming accessible to anyone with standard API access. However, validating those findings and converting them into reliable security insights or exploit strategies remains significantly more complex.

Anthropic itself has acknowledged that traditional benchmarks like Cybench are no longer sufficient to measure modern AI cyber capabilities, noting that its Mythos system exceeded those standards. The company estimated that comparable capabilities could become widespread within six to eighteen months.

The Vidoc findings suggest that, at least for vulnerability discovery, this transition may already be underway. By publishing their methodology, prompts, and results, the researchers highlight how open tools and commercially available models can replicate parts of workflows once considered highly restricted.

For organizations, the implications are instrumental. As AI reduces the cost and effort required to uncover software flaws, defenders may need to adopt continuous monitoring, faster remediation cycles, and deeper behavioral analysis. The challenge is no longer just identifying vulnerabilities, but managing the scale and speed at which they can now be discovered.

Salesforce’s New “Headless 360” Lets AI Agents Run Its Platform

 


Salesforce has introduced what it describes as the most crucial architectural overhaul in its 27-year history, launching a new initiative called “Headless 360.” The update is designed to allow artificial intelligence agents to control and operate the company’s entire platform without requiring a traditional graphical interface such as a dashboard or browser.

The announcement was made during the company’s annual TDX developer conference in San Francisco, where Salesforce revealed that it is releasing more than 100 new developer tools and capabilities. These tools immediately enable AI systems to interact directly with Salesforce environments. The move reflects a deeper shift in enterprise software, where the rise of intelligent agents capable of reasoning and executing tasks is forcing companies to rethink whether conventional user interfaces are still necessary.

Salesforce’s answer to that question is direct: instead of designing software primarily for human interaction, the platform is now being rebuilt so that machines can access and operate it programmatically. According to the company, this transformation began over two years ago with a strategic decision to expose all internal capabilities rather than keeping them hidden behind user interfaces.

This shift is taking place during a period of uncertainty in the broader software industry. Concerns that advanced AI models developed by companies like OpenAI and Anthropic could disrupt traditional software business models have already impacted market performance. Industry indicators, including software-focused exchange-traded funds, have declined substantially, reflecting investor anxiety about the long-term relevance of existing SaaS platforms.

Senior leadership at Salesforce has indicated that the new architecture is based on practical challenges observed while deploying AI systems across enterprise clients. According to internal insights, building an AI agent is only the initial step. Organizations also face ongoing challenges related to development workflows, system reliability, updates, and long-term maintenance.

To address these challenges, Headless 360 is structured around three foundational pillars.

The first pillar focuses on development flexibility. Salesforce has introduced more than 60 tools based on Model Context Protocol, along with over 30 pre-configured coding capabilities. These allow external AI coding agents, including systems such as Claude Code, Cursor, Codex, and Windsurf, to gain direct, real-time access to a company’s Salesforce environment. This includes data, workflows, and underlying business logic. Developers are no longer required to use Salesforce’s own integrated development environment and can instead operate from any terminal or external setup.

In addition, Salesforce has upgraded its native development environment, Agentforce Vibes 2.0, by introducing an “open agent harness.” This system supports multiple agent frameworks, including those from OpenAI and Anthropic, and dynamically adjusts capabilities depending on which AI model is being used. The platform also supports multiple models simultaneously, including advanced systems like Claude Sonnet and GPT-5, while maintaining full awareness of the organization’s data from the start.

A notable technical enhancement is the introduction of native React support. During demonstrations, developers created a fully functional application using React instead of Salesforce’s traditional Lightning framework. The application connected to Salesforce data through GraphQL while still inheriting built-in security controls. This significantly expands front-end flexibility for developers.

The second pillar focuses on deployment. Salesforce has introduced an “experience layer” that separates how an AI agent functions from how it is presented to users. This allows developers to design an experience once and deploy it across multiple platforms, including Slack, mobile applications, Microsoft Teams, ChatGPT, Claude, Gemini, and other compatible environments. Importantly, this can be done without rewriting code for each platform. The approach represents a change from requiring users to enter Salesforce interfaces to delivering Salesforce-powered experiences directly within existing workflows.

The third pillar addresses trust, control, and scalability. Salesforce has introduced a comprehensive set of tools that manage the entire lifecycle of AI agents. These include systems for testing, evaluation, monitoring, and experimentation. A central component is “Agent Script,” a new programming language designed to combine structured, rule-based logic with the flexible reasoning capabilities of AI models. It allows organizations to define which parts of a process must follow strict rules and which parts can rely on AI-driven decision-making.

Additional tools include a Testing Center that identifies logical errors and policy violations before deployment, custom evaluation systems that define performance standards, and an A/B testing interface that allows multiple agent versions to run simultaneously under real-world conditions.

One of the key technical challenges addressed by Salesforce is the difference between probabilistic and deterministic systems. AI agents do not always produce identical results, which can create instability in enterprise environments where consistency is critical. Early adopters reported that once agents were deployed, even small modifications could lead to unpredictable outcomes, forcing teams to repeat extensive testing processes.

Agent Script was developed to solve this problem by introducing a structured framework. It defines agent behavior as a state machine, where certain steps are fixed and controlled while others allow flexible reasoning. This approach ensures both reliability and adaptability.

Salesforce also distinguishes between two types of AI system architectures. Customer-facing agents, such as those used in sales or support, require strict control to ensure they follow predefined rules and maintain brand consistency. These operate within structured workflows. In contrast, employee-facing agents are designed to operate more freely, exploring multiple paths and refining their outputs dynamically before presenting results. Both systems operate on a unified underlying architecture, allowing organizations to manage them without maintaining separate platforms.

The company is also expanding its ecosystem. It now supports integration with a wide range of AI models, including those from Google and other providers. A new marketplace brings together thousands of applications and tools, supported by a $50 million initiative aimed at encouraging further development.

At the same time, Salesforce is taking a flexible approach to emerging technical standards such as Model Context Protocol. Rather than relying on a single method, the company is offering APIs, command-line interfaces, and protocol-based integrations simultaneously to remain adaptable as the industry evolves.

A real-world example surfaced during the announcement demonstrated how one company built an AI-powered customer service agent in just 12 days. The system now handles approximately half of customer interactions, improving efficiency while reducing operational costs.

Finally, Salesforce is also changing its business model. The company is shifting away from traditional per-user pricing toward a consumption-based approach, reflecting a future where AI agents, rather than human users, perform the majority of work within enterprise systems.

This transformation suggests a new layer in strategic operations. Instead of resisting the rise of AI, Salesforce is restructuring its platform to align with it, betting that its existing data infrastructure, enterprise integrations, and accumulated operational logic will continue to provide value even as software becomes increasingly autonomous.

New Chaos Malware Variant Expands to Cloud Targets, Introduces Proxy Capability

 



A newly observed version of the Chaos malware is now targeting poorly secured cloud environments, indicating a defining shift in how this threat is being deployed and scaled.

According to analysis by Darktrace, the malware is increasingly exploiting misconfigured cloud systems, moving beyond its earlier focus on routers and edge devices. This change suggests that attackers are adapting to the growing reliance on cloud infrastructure, where configuration errors can expose critical services.

Chaos was first identified in September 2022 by Lumen Black Lotus Labs. At the time, it was described as a cross-platform threat capable of infecting both Windows and Linux machines. Its functionality included executing remote shell commands, deploying additional malicious modules, spreading across systems by brute-forcing SSH credentials, mining cryptocurrency, and launching distributed denial-of-service attacks using protocols such as HTTP, TLS, TCP, UDP, and WebSocket.

Researchers believe Chaos developed from an earlier DDoS-focused malware strain known as Kaiji, which specifically targeted exposed Docker instances. While the exact operators behind Chaos remain unidentified, the presence of Chinese-language elements in the code and the use of infrastructure linked to China suggest a possible connection to threat actors from that region.

Darktrace detected the latest variant within its honeypot network, specifically on a deliberately misconfigured Hadoop deployment that allowed remote code execution. The attack began with an HTTP request sent to the Hadoop service to initiate the creation of a new application.

That application contained a sequence of shell commands designed to download a Chaos binary from an attacker-controlled domain, identified as “pan.tenire[.]com.” The commands then modified the file’s permissions using “chmod 777,” allowing full access to all users, before executing the binary and deleting it from the system to reduce forensic evidence.

Notably, the same domain had previously been linked to a phishing operation conducted by the cybercrime group Silver Fox. That campaign, referred to as Operation Silk Lure by Seqrite Labs in October 2025, was used to distribute decoy documents and ValleyRAT malware, suggesting infrastructure reuse across campaigns.

The newly identified sample is a 64-bit ELF binary that has been reworked and updated. While it retains much of its original functionality, several features have been removed. In particular, capabilities for spreading via SSH and exploiting router vulnerabilities are no longer present.

In their place, the malware now incorporates a SOCKS proxy feature. This allows compromised systems to relay network traffic, effectively masking the origin of malicious activity and making detection and mitigation more difficult for defenders.

Darktrace also noted that components previously associated with Kaiji have been modified, indicating that the malware has likely been rewritten or significantly refactored rather than simply reused.

The addition of proxy functionality points to a broader monetization strategy. Beyond cryptocurrency mining and DDoS-for-hire operations, attackers may now leverage infected systems to provide anonymized traffic routing or other illicit services, reflecting increasing competition within cybercriminal ecosystems.

This shift aligns with a wider trend observed in other botnets, such as AISURU, where proxy services are becoming a central feature. As a result, the threat infrastructure is expanding beyond traditional service disruption to include more complex abuse scenarios.

Security experts emphasize that misconfigured cloud services, including platforms like Hadoop and Docker, remain a critical risk factor. Without proper access controls, attackers can exploit these systems to gain initial entry and deploy malware with minimal resistance.

The continued evolution of Chaos underlines how threat actors are persistently enhancing their tools to expand botnet capabilities. It also reinforces the need for continuous security monitoring, as changes in how APIs and services function may not always appear as direct vulnerabilities but can exponentially increase exposure.

Organizations are advised to regularly audit configurations, restrict unnecessary access, and monitor for unusual behavior to mitigate the risks posed by increasingly adaptive malware threats.

Hackers Use Fake Oura AI Server to Spread StealC Malware

 



Cybersecurity analysts have uncovered a fresh wave of malicious activity involving the SmartLoader malware framework. In this campaign, attackers circulated a compromised version of an Oura Model Context Protocol server in order to deploy a data-stealing program known as StealC.

Researchers from Straiker’s AI Research team, also referred to as STAR Labs, reported that the perpetrators replicated a legitimate Oura MCP server. This genuine tool is designed to connect artificial intelligence assistants with health metrics collected from the Oura Ring through Oura’s official API. To make their fraudulent version appear authentic, the attackers built a network of fabricated GitHub forks and staged contributor activity, creating the illusion of a credible open-source project.

The ultimate objective was to use the altered MCP server as a delivery vehicle for StealC. Once installed, StealC is capable of harvesting usernames, saved browser passwords, cryptocurrency wallet information, and other valuable credentials from infected systems.

SmartLoader itself was initially documented by OALABS Research in early 2024. It functions as a loader, meaning it prepares and installs additional malicious components after gaining a foothold. Previous investigations showed that SmartLoader was commonly distributed through deceptive GitHub repositories that relied on AI-generated descriptions and branding to appear legitimate.

In March 2025, Trend Micro published findings explaining that these repositories frequently masqueraded as gaming cheats, cracked software tools, or cryptocurrency utilities. Victims were enticed with promises of free premium functionality and encouraged to download compressed ZIP files, which ultimately executed SmartLoader on their devices.

Straiker’s latest analysis reveals an evolution of that tactic. Instead of merely posting suspicious repositories, the threat actors established multiple counterfeit GitHub profiles and interconnected projects that hosted weaponized MCP servers. They then submitted the malicious server to a recognized MCP registry called MCP Market. According to the researchers, the listing remains visible within the MCP directory, increasing the risk that developers searching for integration tools may encounter it.

By infiltrating trusted directories and leveraging reputable platforms such as GitHub, the attackers exploited the inherent trust developers place in established ecosystems. Unlike rapid, high-volume malware campaigns, this operation progressed slowly. Straiker noted that the group spent months cultivating legitimacy before activating the malicious payload, demonstrating a calculated effort to gain access to valuable developer environments.

The staged operation unfolded in four key phases. First, at least five fabricated GitHub accounts, identified as YuzeHao2023, punkpeye, dvlan26, halamji, and yzhao112, were created to generate convincing forks of the authentic Oura MCP project. Second, a separate repository containing the harmful payload was introduced under another account named SiddhiBagul. Third, these fabricated accounts were listed as contributors to reinforce the appearance of collaboration, while the original project author was intentionally omitted. Finally, the altered MCP server was submitted to MCP Market for broader visibility.

If downloaded and executed, the malicious package runs an obfuscated Lua script. This script installs SmartLoader, which then deploys StealC. The campaign signals a shift from targeting individuals seeking pirated content to focusing on developers, whose systems often store API keys, cloud credentials, cryptocurrency wallets, and access to production infrastructure. Stolen information could facilitate subsequent intrusions into larger networks.

To mitigate the threat, organizations are advised to catalogue all installed MCP servers, implement formal security reviews before adopting such tools, confirm the authenticity and source of repositories, and monitor network traffic for unusual outbound communications or persistence behavior.

Straiker concluded that the incident exposes weaknesses in how companies assess developing AI tools. The attackers capitalized on outdated trust assumptions applied to a rapidly expanding attack surface, underscoring the need for stricter validation practices in modern development environments.

Instagram Refutes Breach Allegations After Claims of 17 Million User Records Circulating Online

 



Instagram has firmly denied claims of a new data breach following reports that personal details linked to more than 17 million accounts are being shared across online forums. The company stated that its internal systems were not compromised and that user accounts remain secure.

The clarification comes after concerns emerged around a technical flaw that allowed unknown actors to repeatedly trigger password reset emails for Instagram users. Meta, Instagram’s parent company, confirmed that this issue has been fixed. According to the company, the flaw did not provide access to accounts or expose passwords. Users who received unexpected reset emails were advised to ignore them, as no action is required.

Public attention intensified after cybersecurity alerts suggested that a large dataset allegedly connected to Instagram accounts had been released online. The data, which was reportedly shared without charge on several hacking forums, was claimed to have been collected through an unverified Instagram API vulnerability dating back to 2024.

The dataset is said to include information from over 17 million profiles. The exposed details reportedly vary by record and include usernames, internal account IDs, names, email addresses, phone numbers, and, in some cases, physical addresses. Analysis of the data shows that not all records contain complete personal details, with some entries listing only basic identifiers such as a username and account ID.

Researchers discussing the incident on social media platforms have suggested that the data may not be recent. Some claim it could originate from an older scraping incident, possibly dating back to 2022. However, no technical evidence has been publicly provided to support these claims. Meta has also stated that it has no record of Instagram API breaches occurring in either 2022 or 2024.

Instagram has previously dealt with scraping-related incidents. In one earlier case, a vulnerability allowed attackers to collect and sell personal information associated with millions of accounts. Due to this history, cybersecurity experts believe the newly surfaced dataset could be a collection of older information gathered from multiple sources over several years, rather than the result of a newly discovered vulnerability.

Attempts to verify the origin of the data have so far been unsuccessful. The individual responsible for releasing the dataset did not respond to requests seeking clarification on when or how the information was obtained.

At present, there is no confirmation that this situation represents a new breach of Instagram’s systems. No evidence has been provided to demonstrate that the data was extracted through a recently exploited flaw, and Meta maintains that there has been no unauthorized access to its infrastructure.

While passwords are not included in the leaked information, users are still urged to remain cautious. Such datasets are often used in phishing emails, scam messages, and social engineering attacks designed to trick individuals into revealing additional information.

Users who receive password reset emails or login codes they did not request should delete them and take no further action. Enabling two-factor authentication is fiercely recommended, as it provides an added layer of security against unauthorized access attempts.