Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Latest News

Linux Systems Exposed as Public Exploits Target One-Character Kernel Flaw

  Several researchers have recently published fully functional exploit code demonstrating reliable privilege escalation from an unprivileged...

All the recent news you need to know

University of Toronto Researchers Demonstrate Autonomous AI Worm That Adapts, Exploits, and Self-Replicates Without Human Control

 

kResearchers from the University of Toronto have developed and tested a proof-of-concept artificial intelligence-powered computer worm capable of independently navigating networks, identifying vulnerabilities, creating customized attack plans, and replicating itself without human assistance. Notably, the system operates using a locally hosted open-weight large language model (LLM), eliminating reliance on commercial AI platforms.

The research paper, published on arXiv on June 2 and currently undergoing peer review, highlights a growing cybersecurity concern: traditional patching strategies focused on individual vulnerabilities may become ineffective against malware that can dynamically analyze systems, consume newly published security advisories, and generate attack methods in real time.

During testing, the AI worm was deployed in 15 isolated experiments across a purposely vulnerable network consisting of 33 hosts. On average, it discovered 31.3 vulnerabilities and obtained elevated privileges on 23.1 systems. The worm successfully replicated itself to 20.4 hosts, covering approximately 62% of the network over a seven-day period without prior knowledge of the network structure or any human guidance.

How This AI Worm Differs From Traditional Malware

Conventional worms are typically designed with predefined exploits. Once those vulnerabilities are patched, the malware's ability to spread is significantly reduced.

The Toronto researchers took a different approach. Their worm leverages an open-weight large language model running on a single GPU to create attack strategies on demand. Instead of depending on a fixed exploit chain, it generates tailored attack logic based on the characteristics of each target system. It also functions independently of commercial AI services, meaning it is not subject to API restrictions, rate limits, or account suspensions.

Inside the Experiment

The project was led by Associate Professor Nicolas Papernot and involved researchers from the University of Toronto, the Vector Institute, the University of Cambridge, and ServiceNow.

Testing took place on an isolated environment known as "FakeCorp," which consisted of 33 hosts running a variety of operating systems, including Ubuntu, Debian, Rocky Linux, Alpine Linux, Windows Server 2008 R2, Windows Server 2019, Windows Server 2022, and several IoT devices.

Every host contained at least one genuine vulnerability. Five machines were equipped with GPUs. During primary experiments, the worm used a shared GPU inference pool to emulate computational resources obtained from compromised systems. Researchers also tested full GPU-based replication, where the worm deployed its own LLM on an infected GPU machine. This approach achieved a success rate of 68.8%.

Under this architecture, compromised GPU systems acted as reasoning hubs, supplying AI inference capabilities to less powerful devices that could not run the model independently.

Across all 15 tests, the worm achieved elevated access on an average of 23.1 hosts and successfully replicated to 88% of those systems. The malware propagated through as many as seven generations, averaging 5.1 generations overall.

Researchers emphasized that the network was intentionally vulnerable and designed to evaluate autonomous reasoning and exploitation rather than represent a heavily secured enterprise environment.

Dynamic Exploitation of Multiple Vulnerabilities

The worm successfully leveraged a broad range of vulnerabilities, including SambaCry, Dirty Pipe, PrintNightmare, Drupalgeddon 2, Exim Remote Code Execution, blind SQL injection flaws, JWT authentication bypasses, Redis escapes, and others.

What makes these results notable is that the exploits were not hardcoded into the malware. Instead, the AI agent analyzed available information and independently determined suitable attack paths for each host.

According to the study, individual exploit attempts succeeded approximately 44% of the time. Most failures resulted from payload syntax issues rather than incorrect reasoning. Researchers observed stronger performance against Linux privilege-escalation and service vulnerabilities, while Windows privilege escalation and web application attacks proved more challenging.

Exploiting Newly Disclosed Vulnerabilities

A significant finding was the worm's ability to overcome its training-data limitations by consuming public vulnerability advisories in real time.

The system successfully exploited three vulnerabilities that were disclosed after the model's training period:

  • CVE-2026-39987, a pre-authentication remote code execution flaw affecting Marimo Python notebooks.
  • CVE-2026-31431 (CopyFail), a Linux kernel privilege-escalation vulnerability.
  • CVE-2026-43284 and CVE-2026-43500 (DirtyFrag), Linux kernel privilege-escalation flaws.

Across these targets, the worm achieved root-level access in 41 out of 67 attempts.

Researchers pointed to the increasingly narrow window between disclosure and exploitation. CVE-2026-39987, for example, was publicly disclosed on April 8, 2026. Security firm Sysdig reportedly observed exploitation activity less than ten hours later and documented an intrusion involving an LLM-based agent used during post-compromise operations.

Why Containment Becomes More Difficult

The researchers identified two key factors that could make AI-driven worms harder to contain than traditional malware.

First, operating costs shift from paid API access to the computational resources available on compromised machines. Once attackers gain access to GPU-capable systems, the malware can continue operating without incurring external service costs.

Second, the use of open-weight models removes dependency on AI vendors. As a result, provider-side safety controls such as service refusals, account suspensions, and rate limiting become ineffective.

The team also observed instances where the worm modified its own code to bypass local security measures, despite not being explicitly programmed to do so.

Importantly, the prototype lacked several advanced malware capabilities. It did not include encryption, persistence mechanisms, polymorphic code, process masquerading, or log-cleaning functions. Researchers noted that a malicious version incorporating these features would be significantly harder to detect.

Placing the Research in Context

While AI-powered worm research is not entirely new, the Toronto project represents a distinct advancement.

Earlier projects such as Morris II focused on spreading through AI applications and email assistants. In 2026, ClawWorm demonstrated self-replication across LLM agent ecosystems by compromising persistent configurations and spreading between agents.

The Toronto worm differs because it targets traditional network infrastructure rather than AI systems themselves. In this case, the large language model serves as the attack engine rather than the attack target.

The findings also align with broader industry observations. Security researchers have increasingly documented AI-assisted cyber operations involving reconnaissance, exploit development, credential theft, lateral movement, and data exfiltration.

Recommended Defensive Measures

Although the prototype lacked stealth capabilities, researchers identified several practical steps organizations can take to reduce risk:

Isolate GPU-enabled systems through strict segmentation and zero-trust controls to prevent them from becoming centralized AI reasoning hubs.
Treat newly disclosed vulnerabilities as high-priority risks and accelerate patching for internet-facing systems.
Immediately rotate credentials on compromised or potentially compromised devices to limit lateral movement.
Monitor for behavioral indicators such as unusual port activity, automated SSH key deployment, and unexpected AI inference workloads on endpoints.

The experiments demonstrated that the worm could gain root access on newly disclosed vulnerabilities in 41 out of 67 attempts and spread across 62% of a network within seven days without additional human involvement. Researchers warn that once an attacker establishes a GPU foothold in a poorly segmented environment, the cost of identifying and exploiting new targets decreases substantially.

The implementation has not been publicly released. The University of Toronto is currently establishing a vetting process through which qualified defensive researchers may request access to the system for further study.

Citizens Bank, Stanford Warn Against Sharing Financial Data With AI

 

Artificial intelligence is quickly becoming part of everyday financial decision-making, but experts are warning Americans to be careful about what they share with it. Citizens Bank has stressed that AI can be helpful, yet it also brings serious privacy and fraud risks when people enter personal financial information into chatbots and similar tools. 

The biggest concern is oversharing. Many users ask AI for budgeting help, debt advice, or retirement guidance and then unknowingly provide account numbers, balances, income figures, tax details, or other sensitive data. According to reporting on Stanford-related research, sensitive information shared with AI systems may be stored, collected, or exposed through vulnerabilities, creating opportunities for identity theft or financial fraud. 

Citizens Bank says AI should not be treated like a secure financial adviser. Its online safety guidance warns that AI can be used by cybercriminals to steal money or identities, especially when users reveal critical information. The bank advises people to avoid sharing key financial details, use caution with suspicious messages, and verify anything that seems unusual through trusted sources rather than replying directly. 

Experts say there are safer ways to use AI for money questions. Instead of typing exact figures, users can describe their situation in broad terms or use ranges, such as “low savings” or “moderate debt,” to get useful guidance without exposing private data. This approach allows AI to give practical responses while reducing the chance that confidential information will be stored, reused, or leaked later.

According to security experts, AI can be a useful assistant, but it should never become a place to dump your personal finances. Americans who want to protect themselves should avoid entering banking credentials, account balances, Social Security numbers, or tax documents into any AI tool. In an era of growing AI-driven scams, caution is no longer optional — it is part of basic financial security.

Experts Reveal the DDoS Under Ground Market


Attack tactic

What happens in a typical Distributed Denial-of-Service (DDoS) attack. A website that suddenly stops? Time out of a login page? Not being able to reach an online service when you need it the most? These causes are not internal, and are attributed to DDoS attacks. 

Cloudflare reported stopping a 7.3 Tb/s attack last year and said it addressed a 31.4 Tb/s attack in its Q4 2025  DDoS report. According to Microsoft, Azure also blocked a 15.72 Tb/s attack last year in October. The activity was linked to the Aisuru botnet.

Darkweb market selling and buying the service

For all these instances, dark web actors are fighting over the same buyers with pitches. Flare experts analyzed dark web operations and detailed API access, reseller options, botnet-based capacity, monthly plans, Cloudflare bypass claims, and game-server tactics.

A comparative analysis of the DDoS-related dark web operations from the first five months of 2023 and the first five months of 2026 demonstrate how rapidly that offer has evolved. Scripts, tutorials, leaked tools, and sporadic forum posts used to be more common, but these days they are more typically provided as recurring products that are simpler to purchase and use.

What is a DDoS attack?

A DDoS attack tries to crowd an application, network, server, or website with traffic from various servers at one time. Few attacks are aimed at network capacity, while the remaining emphasize on application layer resources like APIs and login pages. The aim is to dismantle any service or activity and make it unavailable, expensive to use, or unstable. 

What is DDoS-as-a-service?

DDoS-as-a-service removes the barrier even further, a hacker can choose a victim, pay for accessing a web panel, select timeline, and depend on another person’s botnet, third-party attack infrastructure, or proxy network.

About the attack

A hosting company that employs Magic Transit to protect their IP network and is a Cloudflare user was the target of the attack. According to Cloudflare’s recent DDoS threat assessment, DDoS attacks are increasingly targeting hosting providers and vital Internet infrastructure. 

An assault campaign from January and February of 2025 that launched over 13.5 million DDoS attacks on Cloudflare's hosting providers and infrastructure was detailed by the experts on their blog.

CBSE Revaluation Portal Hit by Cyberattack, Payment Gateway Glitch Affects Students

 

A breach has surfaced within CBSE's digital infrastructure, casting doubt on transaction reliability during revaluation requests. Officials confirm unusual activity emerged just hours after launch of the updated platform. Instead of standard fees, some users saw inflated amounts appear without explanation. The disruption stemmed from external interference, not internal error, per preliminary assessments. While access resumed quickly, trust in online payments wavered temporarily among applicants. Investigators are now tracing entry points used in the intrusion. Security teams emphasize that only a small fraction faced actual financial impact. Monitoring continues as safeguards undergo review. 

Some fifty learners faced disruptions due to the event, officials noted. Payment amounts shifted without warning in these instances - now low at just one rupee, now near sixty-seven or sixty-eight thousand. Unauthorized entry might have paved the way for intentional system interference, according to insiders. Such altered fees possibly stemmed from targeted digital tampering following a breach. Trouble began when the portal’s payment gateway - handled by HDFC Bank - faced glitches after launch. Right away, access problems appeared, blocking user entry without warning. 

A few people took advantage while systems faltered, altering charges shown on student records. Officials confirmed irregular fees stemmed from these brief security lapses. Following the event, CBSE along with state bodies began closely examining the system's framework. To support this effort, specialists from IIT Madras, joined by counterparts at IIT Kanpur and the Digital Infrastructure Corporation of India, were invited into the process. With access granted, these teams started analyzing the underlying software structure and identifying weak points. 

One main goal drives their work: keeping the service stable under pressure. By reinforcing key defenses now, they aim to block repeat disruptions later. Now live within the platform, four state-run lenders join the network to spread risk beyond one vendor. Among them: State Bank of India, followed by Canara Bank, then Indian Bank, and later Bank of Maharashtra. With more institutions linked, handling payments should run smoother under strain. Built-in backup paths emerge naturally when multiple entry points exist. Stability gains come not from promises but structure - extra layers help maintain flow during outages. 

Later came reports of trouble faced by students after results and rechecking, sparking talks between Dharmendra Pradhan and Nirmala Sitharaman. Because of these concerns, officials decided improvements were needed in how payments work across CBSE platforms. So far, reports indicate the updated setup is running smoothly after shifting the platform to Amazon Web Services (AWS). This move comes in response to past issues with traffic handling and long-term flexibility. Teams remain alert, observing both function and protection measures closely during ongoing evaluations. 

What happened shows why protecting school systems matters more now, given how much personal information and money flows through them. Even so, officials keep digging into the case even as new security steps go live to reduce risks ahead.

WhatsApp to Roll Out Username Feature, No Mobile Number Required


WhatsApp will launch a new feature where users can opt for usernames and connect with others without putting mobile numbers. The feature is similar to the famous messaging app Telegram and also Instagram. The new update will allow users to share a unique username instead of their contact number for chats.

About feature development

“WhatsApp has worked to ensure that the username experience is stable and secure. For this reason, the rollout of usernames is taking a significant amount of time. Over the years, the code of the app has been extensively updated to make sure all existing features are fully compatible with usernames. So WhatsApp focused on testing and refining the feature carefully before making it widely available. It seems that WhatsApp is set to roll out the username feature to users as part of a phased rollout strategy over the coming months,” Whatsapp said in its blog. 

Users will still have the option to continue using WhatsApp as usual if they so choose. Phone numbers will still be linked to accounts for login and recovery purposes, but each account will support a single username that can be changed at a later time without impacting chats or account activity.

How to setup

Soon, both Android and iPhone users of WhatsApp will be able to create usernames straight from the app's Settings menu. Users must visit their profile settings, select the Username option when it appears, and pick a distinctive handle for their account in order to set one up. Before the chosen username can be kept, WhatsApp will automatically check if it is legitimate and accessible.

Safety first

In order to avoid confusion and abuse, the site is also implementing strict guidelines for usernames. Usernames can only contain letters, digits, periods, underscores, and at least one letter; they must be between three and thirty-five characters long. Some formats will not be accepted, such as usernames that start with "www," finish in domain-style extensions, or have repeated periods.

What about user privacy?

By enabling users to communicate without disclosing their phone numbers, the function aims to increase privacy. Once enabled, users can speak with buyers, sellers, community organizations, or new connections using their usernames rather than their personal mobile numbers. Only the selected handle—rather than the associated phone number—will be visible to those who contact you using the username.

With a wider deployment anticipated later in 2026, WhatsApp has already begun testing usernames with a small number of iOS and Android users. According to the firm, usernames will continue to be optional, so users can continue to use WhatsApp with just their phone numbers if they so choose. Even once usernames are implemented, phone numbers will still be used for account sign-ins, verification, and recovery.

Gogs Zero-Day Vulnerability Raises Alarm Over Server Security


 

Researchers have discovered a zero-day vulnerability in Gogs, the widely used self-hosted Git repository management platform, that may allow authenticated users to escalate their privileges on vulnerable servers by leveraging this vulnerability to execute remote code. 

In addition to affecting current Gogs releases, this vulnerability is classified as a critical argument injection weakness that poses a particular risk to distributed software development and collaboration deployments that are Internet-accessible. As a result of security analysis, the attack can be carried out without administrative privileges and, under default configurations, the attacker may only need a standard user account to compromise the underlying host. 

The finding highlights the fact that seemingly routine source code management operations can become high-impact attack vectors when exploitable flaws intersect with permissive default settings and exposed development infrastructure, which has not been officially patched at the time of disclosure. Due to the close alignment between the attack path and Gogs' default deployment behaviour, the exposure becomes especially significant. 

A Rapid7 researcher stated that open registration of users and the creation of unrestricted repositories enable an external actor to establish the necessary conditions for exploitation without requiring privileged access or assistance from other users. An application-wide flaw exists in the application's handling of repository merge operations. If the branch name is specially crafted, malicious arguments can be injected into the git rebase process during the "Rebase before merging" workflow by using a specially crafted branch name. 

By abusing Git's --exec parameter, an attacker can force arbitrary shell commands to run on the host system under the security context of the Gogs service account. As researchers noted, the consequences of the compromise extend far beyond a single repository compromise, allowing threat actors to access private repositories belonging to other users, extract sensitive credentials such as password hashes, API tokens, SSH keys, multi-factor authentication secrets, and move laterally across connected systems, as well as alter source code stored on the system. 

While Burgess indicates that Gogs has addressed several argument injection vulnerabilities in recent years, this newly discovered vulnerability stems from a different code path within the Merge() function, which was not addressed. Moreover, users with write permissions in repositories with rebase merging are also at risk of exploiting this vulnerability, while environments which restrict repository creation remain vulnerable if attackers can obtain write access to qualifying projects. 

While the flaw was reported to the maintainer in March 2026, it remains unpatched as of the date of publication, making deployments across Windows, Linux, and macOS vulnerable to exploitation. Approximately 1,100 Gogs instances are currently exposed to the internet, according to Rapid7, but the true number is likely to be substantially greater due to the prevalence of deployments that operate behind VPNs and internal enterprise networks.

Additionally, the disclosure has brought to the vendor's attention concerns relating to its response timeframe. In March 2026, Burgess reported the vulnerability to the Gogs maintainers and received an acknowledgement on March 28, but no security update has been released since then. Given the platform's existing exposure footprint, this delay is particularly noteworthy. 

Data from Shadowserver indicates that more than 2,400 publicly accessible Gogs instances are currently located in Asia and Europe, with the highest concentrations occurring in the region, while Shodan indexes over 1,000 internet-facing systems that exhibit identifiable Gogs signatures. An incident of this type is reminiscent of one that occurred with CVE-2025-8110, another remote code execution vulnerability that was exploited by hackers before patches were available. 

A vulnerability discovered by Wiz Research during an investigation into a compromised Gogs deployment ultimately led to the U.S. Government's Cybersecurity and Infrastructure Security Agency (CISA), which classified it as actively exploited and directed federal agencies to secure affected systems, resulting in a significant threat model. 

In addition, this new flaw undermines the trust boundaries underlying shared Git hosting environments, making it a similar serious threat model. It is common for businesses, universities, and development teams to deploy multi-user software environments, where a single, authenticated account can control the underlying server infrastructure without having to gain access to another user's repository. 

If code execution is achieved, an attacker will be able to access all repository files hosted on the instance, extract authentication credentials stored within the backend databases, enter adjacent network resources, and manipulate source code on the file system. 

Gogs service accounts usually maintain unrestricted read and write rights across repositories that are stored under the same repository root; therefore, malicious modifications can bypass platform-level audit mechanisms and are difficult to identify in environments where commit-signing enforcement does not exist. It was also noted that exploitation can be highly practical and automated using publicly available tools, enabling attacks to be carried out within seconds with minimal forensic evidence remaining. 

Gogs' implementation of the "Rebase before merging" feature has resulted in the issue, as it internally invokes the git rebase command to create a linear project history by replaying commits. With the --exec parameter, Git executes shell commands after each replayed commit, creating the exploitation primitive when malicious input is incorrectly handled. 

While the rebase merge functionality is disabled by default, the repository can enable the feature through the project owner's settings, and new repositories are automatically assigned ownership to their creators, ensuring that abuse does not occur. Despite deployments that restrict repository creation, vulnerable code paths can still be exploited to execute remote commands by users who have access to repositories that support rebase merging.

Newly disclosed vulnerabilities in development platforms such as Gogs serve as a timely reminder that these platforms can magnify the impact of a single security weakness across entire software ecosystems. Considering the lack of a patch and the requirement for limited user privileges to exploit Gogs in common deployment configurations, organisations relying on Gogs should carefully evaluate repository permissions, disable unnecessary registration and repository creation features, and closely monitor merging activity. 

In light of the continued reliance on software supply chains as a critical component of business operations, the security of source code infrastructure has become more than an issue of development it has become a fundamental security priority that requires continuous monitoring, prompt remediation, and proactive defence.

Featured