Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Attackers Exploit Critical UnrealIRCd Flaw Enabling Server Command Injection

 

A high-severity vulnerability in UnrealIRCd, an open-source IRC server, is being actively exploited by attackers. Tracked as CVE-2026-114713, the flaw has a CVSS score of 8.6 and allows malicious users to inject server-to-server commands that execute with elevated authority. CISA has added it to its Known Exploited Vulnerabilities catalog, making urgent patching essential for affected organizations. 

The vulnerability arises from improper neutralization of delimiters in UnrealIRCd’s labeled-response module. In versions 6.0.0 through 6.2.7.0, the software fails to properly escape the IRCv3 “label” message tag when echoing it in replies. On networks with two or more linked servers, this lets any connected user inject commands into server-to-server communication and potentially perform actions reserved for server or IRC operators. 

The flaw is especially serious because it can undermine the trust between linked IRC servers and enable arbitrary command execution. UnrealIRCd maintainer Bram Matthys described it as the most critical UnrealIRCd vulnerability discovered in the past 15 years. Exploitation reportedly began just one day after the security hotfix was released on November 7, 2026, showing that attackers are moving quickly to target unpatched systems. 

CISA added the vulnerability to its Known Exploited Vulnerabilities catalog after reports of real-world attacks. Under Binding Operational Directive 26-04, federal civilian executive branch agencies must apply the required fixes by November 16, 2026. The short deadline reflects the urgency of the threat, particularly for internet-facing systems or organizations operating multi-server IRC networks. 

Administrators should immediately upgrade UnrealIRCd to version 6.2.7.1 or later, which fixes CVE-2026-114713 and several other vulnerabilities. Those unable to update right away should apply the available spamfilter workaround, review logs for suspicious activity, and ensure every linked server is patched. The incident is a reminder that prompt patching and strong access controls are essential to prevent newly disclosed flaws from becoming active attack vectors.

Trezor Confirms Hardware Implants in Three Safe 5 Wallets Sold Through Malaysian Reseller

 


Trezor has confirmed that three of its Safe 5 hardware wallets contained malicious circuit board implants capable of stealing cryptocurrency recovery phrases and transmitting them over a mobile network to an attacker-controlled server. The company published its investigation findings on November 13 and released a firmware patch two days earlier that neutralizes the implants found so far.

All three affected devices were purchased from CryptoBilis, a Malaysia-based hardware wallet retailer operating across Southeast Asia, between August 20 and September 23, 2026. No customers who bought from other regional resellers have been flagged, and no affected CryptoBilis customer has reported stolen funds so far.


How the Implant Works

The malicious component is a secondary circuit board installed between the Safe 5's main board and its display. It does not touch the legitimate firmware or the wallet's Secure Element, which is precisely what makes it difficult to catch through standard software checks. Instead, it sits passively and watches the screen.

When a user sets up a new wallet or restores an existing one, the implant reads the recovery words as they appear on the display. It can also capture passphrases. Once it has what it needs, it encrypts the data and sends it over a mobile network to a remote server. If the device has no mobile connection at that moment, the implant holds the data and keeps attempting transmission until it goes through.

The design mirrors what security researchers at Tibane Labs found inside tampered Ledger wallets traced to the same reseller weeks earlier. In those devices, the implants used an eSIM and a shielded LTE module alongside a microcontroller, with chip markings scraped off in at least one variant to slow identification.


How Trezor Found Them

The investigation began in October 2026 after a customer reported finding an unfamiliar circuit board inside a Safe 5 purchased from CryptoBilis. At the time, Trezor had not yet received the physical device and could not confirm what the implant was actually doing. It issued a warning and asked CryptoBilis customers to get in touch.

Forty-eight customers responded. Trezor examined some devices directly in its lab and checked others by reviewing photographs of internal components submitted by owners. That process turned up two more compromised wallets beyond the original one.


The Fix and What It Cannot Do

Firmware version 2.13.1, released on November 11, is designed to block the specific implants Trezor has examined from reading information off updated devices. The company described the patch as making "the current batch of implants useless."

There is an important limit to what the update can accomplish. If a device was implanted and a user set it up or restored a wallet before installing the firmware, the recovery phrase was already captured and sent. The patch stops future captures but cannot retrieve data that has already left the device.

Trezor is advising everyone who purchased a Safe 5 from CryptoBilis to move their funds to a new wallet generated with a freshly created recovery phrase. The company is offering replacement devices to any customer who bought from CryptoBilis since March 2026, including those whose devices have not been confirmed compromised.

CryptoBilis sits at the center of a supply chain problem that has now touched two of the most recognized hardware wallet brands. Ledger confirmed implants in its own devices sold through the same reseller in early October, shortly after users began reporting fund losses. Ledger's investigation showed that all reported drains traced back to CryptoBilis, and the company asked the retailer to stop selling and shipping its products.

Tampered Ledger devices were reportedly sold at roughly half the standard retail price, which in hindsight was a signal that something was wrong with how those units were sourced.

Trezor had already announced plans in October to tighten its reseller network following the Ledger reports, before its own implants were confirmed. It has since cut approximately 80 percent of its global reseller partners. The company said the removed resellers were not themselves untrustworthy, but that they did not meet the stricter supply-chain security requirements Trezor put in place after the CryptoBilis situation came to light. Remaining partners now face tighter controls over how devices are sourced, stored, and physically handled before they reach customers.


What Buyers Should Do

Anyone who purchased a Trezor wallet from CryptoBilis is being directed to contact Trezor directly. Those who set up or restored a wallet on the device before the November 11 firmware update should treat their current recovery phrase as exposed and generate a new one on a trusted device. Trezor's recommendation is to move funds before doing anything else.



UK Data Protection Regulator Sees Unprecedented Rise in Cyber Incident Reports


There was a record number of cyber incidents reported by British organizations to the country's data protection regulator during the third quarter of 2026, demonstrating the increasing strain on the UK's cybersecurity landscape. The latest data from the Information Commissioner's Office (ICO), which has been analyzed by Recorded Future News, indicates that 1,371 cyber incidents were reported from July to September, surpassing the previous quarterly record set in 2023. It is also estimated that the UK will surpass its previous record for cyber incident reports, which was also set in 2023. 

In addition to cyber-related incidents, the regulator received 4,604 reports regarding data security incidents during the third quarter, marking the highest quarterly total ever recorded. These included non-cybersecurity incidents, for example, sending sensitive emails to the wrong recipients accidentally. 

There are growing concerns among cybersecurity firms about the increasing number of British organizations appearing on data leak sites operated by cybercriminal groups. These groups increasingly use stolen information to pressure their victims into paying extortion demands. In addition, incident response providers have reported a sharp increase in demand, with employees at some firms stating that they have had to turn away prospective clients as a result of capacity limitations. 

ICO figures, however, provide a mixed picture of the ransomware threat. While reports of extortion-related activity continue to increase across the industry, the number of ransomware incidents formally reported to the regulator has continued to decrease. In 2023, the ICO recorded 1,253 ransomware incidents, followed by 752 in 2024 and 620 in 2025. It is estimated that 321, including 102 cases in the third quarter, have been reported in the third quarter of 2026, compared to 111 cases reported in the second quarter of 2026. 

ICO reports of cyber incidents are generally classified as 'other cyber incidents' rather than specifically classified as ransomware, phishing, or malware, which are most frequently reported. It is difficult to compare ransomware figures directly since the regulator's classification does not clearly indicate whether data theft and extortion without file encryption are included. While these limitations have been acknowledged, cybersecurity researchers have identified a significant increase in organizations being publicly identified by ransomware groups.

Rafe Pilling, director of threat intelligence at Sophos, stated leak-site numbers are imperfect but indicate a rise in ransomware attacks and data theft extortion activity, especially in the UK. As reported incidents increased, they were not limited to a particular industry. Retail and manufacturing organizations recorded the highest number of incidents, with reports increasing from 205 in the second quarter to 296 in the third quarter. 

A substantial increase has also been observed among charitable and voluntary organizations, with incidents rising from 79 to 145 during the same period. A significant increase has been observed at online technology and telecommunications companies, where incidents have increased from 76 to 120. There was a decline in reports in education and childcare among the six most affected industries, which fell from 135 to 115 reports.

Although there have been an increasing number of complaints, only a small percentage have resulted in formal regulatory investigations. ICO officials confirmed that only 18 of 1,371 cyber incidents reported during the third quarter were investigated, while the majority were handled by informal regulation or were closed without a formal investigation being initiated. 

Moreover, artificial intelligence is gaining traction in the evolving cyber threat landscape Rafe Pilling of Sophos cites the growing use of artificial intelligence by established cybercriminals and attacks involving AI agent frameworks as contributing factors to the wider threat. It is possible for threat actors to increase the speed and scale of their operations through the use of these technologies, facilitating the identification of vulnerabilities and the implementation of attacks. 

In the healthcare sector, the wider impact of unauthorized data access has also been of concern. ICO received and assessed more than 300 reports of unauthorized access to patient records between January and October 2026. Healthcare employees are reported to have accessed medical records without a legitimate reason, viewed information belonging to individuals they are acquainted with, and shared confidential patient information. 

Health care leaders have been instructed by the regulator to improve access controls, monitor suspicious activity, and take appropriate action against employees who have accessed records without authorization. Although established defensive measures remain essential for reducing cyberattack exposure, security experts continue to emphasize how effective these measures remain. 

To prevent unauthorized access to internet-facing systems, Pilling recommended that vulnerabilities in these systems be addressed and multifactor authentication, as well as passkeys, be implemented. Several organizations across all sectors are vulnerable to cyberattacks. The Information Commissioner has stressed how important it is to protect personal information from cyberattacks.

A strong cyber resilience program is essential, according to Jonathan Ellison, director of national resilience at the National Cyber Security Centre, who pointed out that many successful attacks continue to exploit known security vulnerabilities. In addition, artificial intelligence is facilitating the identification of vulnerabilities and potential exploitation of those vulnerabilities at a faster rate. 

Despite the growing trend of cybercriminal activity, British organizations have been under increasing pressure to improve their security controls, detect incidents and protect sensitive information as a result of increasing cybercriminal activity. These record figures underscore the increasing pressure that UK organizations face when it comes to strengthening their cybersecurity practices and protecting sensitive data. 

s criminal groups increasingly rely on data theft and extortion, effective access controls, timely security updates and phishing-resistant authentication remain essential. Organizations must also improve incident monitoring and response capabilities to limit exposure and maintain public trust.

Ransomware Attack Disrupts Belarusian Cloud Provider ActiveCloud, Affecting Business Services

 

A ransomware attack on Belarus-based cloud services provider ActiveCloud has caused issues with websites, business email and virtual servers. The company has confirmed that their systems have been breached and some areas have been locked by ransomware. 

The company said on Tuesday that they had been hit by the ransomware attack which has affected their cloud hosting, email and customer support. Whilst some critical elements of their infrastructure have been restored by Wednesday, it will take longer to get customer systems back up and running. ActiveCloud said on Friday that they have now restored their core services, however some customers are still having issues. 

They added that their technical teams have been working around the clock to get everything back up and running and the most difficult part of the recovery process is now complete. The ransomware attack has impacted a number of services including their core cloud hosting product E-Cloud, secure hosting E-Cloud Protected and their business email SmartMail. Some customers also had issues getting their virtual machines running. 

ActiveCloud said that during their investigation they have found no evidence that customer data has been compromised. They have not said how the attackers gained access to their systems. The ransomware attack has impacted organisations using ActiveCloud. Belarus news organisation Smartpress have confirmed that they use ActiveCloud to host their website, however they are still publishing. Domino’s Pizza website and mobile app in Belarus have also had some downtime due to the issues. 

ActiveCloud provide cloud hosting, virtual servers, business email and other IT services to businesses and organisations in Belarus and Russia. This means that when issues occur with these services, a number of customers can be impacted. The attack comes after a number of incidents targeting hosting companies in Belarus and neighbouring Russia. On November 8, Russian hosting provider ESTT were hit by a ransomware attack which impacted their cloud services. This caused issues with websites, virtual servers and other customer services. 

They said that whilst their cloud management systems had been targeted, there was no evidence that customer data had been compromised. Just days earlier another Russian provider Beget fell victim to a destructive cyber attack. Attackers reportedly gained access to their infrastructure management systems and ran scripts to wipe data from some areas of their cloud. 

This caused issues with websites and online services for businesses, media and government. They also said that some of their virtual servers had been lost meaning it was harder to get everything back up and running. There is no confirmed evidence linking the attacks on ActiveCloud, ESTT and Beget. None of the companies have identified who is responsible.

Cyberattack on Quantum Systems Disrupts German Military Drone Operations


German defence technology company Quantum Systems has confirmed that it was targeted in a cyberattack in late October.

The incident involved a compromised software update server used to distribute updates for the company's QBase ground-control and mission-planning software.

The company said it detected suspicious activity linked to an active cyberattack carried out by unidentified hostile actors. It responded by working with government authorities to contain the threat and ensure its unmanned systems could safely resume operations.

Quantum Systems manufactures reconnaissance and interceptor drones, along with software used to control and manage their missions. Its drone systems are deployed by the German military and are also used in support of Ukraine.

Malicious software update compromises drone systems

According to reports by German newspaper Der Spiegel and the Financial Times, attackers compromised a server responsible for distributing software updates for Quantum Systems' QBase platform.

The attackers placed a malicious update file on the compromised server, disguising it as a legitimate software update. Since QBase is used for ground control and mission planning, the incident raised concerns that malicious software could reach systems used by military drone operators.

Der Spiegel reported that the Vector reconnaissance drone, known as Falke in German military service, is among the systems whose missions are planned using QBase software.

The unauthorised update triggered alarms within Quantum Systems after it was distributed to customers. However, it remains unclear how many customers downloaded or installed the malicious file.

German military grounds drones as precaution

The cyberattack disrupted German military drone operations, prompting the armed forces to ground Quantum Systems' drones as a precautionary measure.

According to media reports, the decision also resulted in the company's drone systems being excluded from a recent military exercise.

Quantum Systems said it believes the company was targeted because of its support for Ukraine. The company has also highlighted the growing number of cyberattacks against European defence organisations.

German authorities investigate the incident

Germany's military counterintelligence service (MAD), domestic intelligence agency (BfV), and Federal Office for Information Security (BSI) are involved in the investigation.

Quantum Systems said it is cooperating with government authorities to investigate the incident and address the security concerns. However, the company has not publicly identified the attackers or provided details about their methods and objectives.

In July, Australian drone manufacturer CubePilot also experienced a DNS hijacking attack that caused operational disruption.

Hackers Exploit New N-able N-central Zero-Day Hours After PoC Release

 

Hackers began exploiting a new zero-day vulnerability in N-able N-central within hours of a proof-of-concept exploit becoming public. The flaw, called 4EverAble2Shell, can let unauthenticated attackers execute code with root privileges on vulnerable N-central servers, including systems running the latest available patches. 

The vulnerability was published on GitHub by security researcher Sean Bales, two days after N-able released fixes for several other flaws he had disclosed. 4EverAble2Shell chains an exploit for a recent Apache Axis vulnerability, CVE-2026-90436, with an unspecified flaw affecting N-central deployments that have the Legacy API enabled. The Apache Axis issue has a CVSS score of 9.8, reflecting its critical severity. 

Modus operandi 

The attack chain first exploits the Apache Axis bug to achieve remote code execution. It then attempts to elevate its privileges to root and run a shell script. Researchers said the chain works against N-central servers updated to 2026.4 HF2, build 2026.4.1.26, which had already received fixes for earlier Able2Shell zero-days. This means applying the latest hotfix alone does not fully eliminate the risk. 

N-able responded by restricting several N-central features and integrations, including the Legacy API and Intune integration. The company said it had identified additional indicators of compromise and was working with affected customers to assess and mitigate potential risks. On November 12, Bales also published proof-of-concept code for Agent2Shell, a set of roughly a dozen zero-day flaws that could allow attackers to execute commands on managed Windows agents with System privileges. 

Threat intelligence firm Previdian reported that attackers began using the 4EverAble2Shell proof of concept within hours of publication. WatchTowr also observed probes targeting N-central systems with the Legacy API enabled. Lupovis and Huntback found evidence of successful compromises about five hours after the exploit was released, with attackers deploying an XMRig cryptocurrency miner and using systemd or cron for persistence. 

The attackers named each miner after the victim’s IP address. Lupovis said the attacker’s wallet showed 21 rigs connected to compromised N-central servers in the United States, South Africa, Canada, the United Kingdom, Germany, France, and Sweden. The researchers said their decoy systems did not execute the exploit, confirming that the listed systems were real victims. 

Huntback found that 19 victims had already applied N-able’s latest patches. The firm warned that the miner may be the only observed payload, but the privilege escalation gives attackers root access to a server that manages customer endpoints. Security teams should therefore treat any successful exploitation as a full compromise rather than a minor cleanup task. 

Organisations using N-central should immediately disable the Legacy API where possible, apply vendor guidance, review logs for exploitation indicators, and rotate credentials connected to affected systems. They should also inspect AWS, Azure, and other connected environments for suspicious access, because root-level compromise of an RMM server can expose downstream customer networks.

PostgreSQL’s Largest Ever Security Release Patches 52 Flaws, Including a 22-Year-Old Bug Any Logged-In User Could Weaponize

 


The PostgreSQL Global Development Group shipped security updates on November 12 for all five supported major versions, issuing fixes for 52 vulnerabilities at once: the largest security release the project has published. Thirty-two of the 52 flaws carry a CVSS 3.1 score of 8.8, with no user interaction required, full confidentiality and availability impact, and network reachability through a low-privilege login. The fixed releases are 18.7, 17.12, 16.16, 15.20, and 14.25.

At the center of the batch is CVE-2026-6460, a type confusion flaw in how PostgreSQL handles composite types — data structures built from named fields. When a field's type is changed after values of the original type are already stored, PostgreSQL's binary representation keeps those old bytes intact while the catalog metadata shifts around them. The server then reads a stale value through the new type's output function. That mismatch is enough for a database user who can create objects to run arbitrary code as the OS account running PostgreSQL, no superuser status, no extensions, no file access.

The trigger takes exactly four SQL statements. A user creates a composite type, prepares a query using it, alters the attribute to a different type, then executes the prepared query. The backend selects the wrong output handler, dereferences a null pointer, and crashes. That crash is the entry point.

Security researcher Mehmet Ince found the flaw and published a writeup alongside a demonstration on PostgreSQL 18.6. He traces the root cause to a commit made May 5, 2004, the one that added ALTER TABLE ... ALTER COLUMN ... TYPE. That logic never accounted for prepared statements holding values built against the old type. The code sat there for 22 years. His exploit chain defeats ASLR through a related confusion involving PostgreSQL's unnest() function, then calls system() through a forged object whose methods table points at the system call. He stopped short of publishing that final step. He found 21 variants of the problem in total, and six of the 52 CVEs in this release trace to his work. The release credits 18 researchers for CVE-2026-6460 alone, including PostgreSQL core developers Heikki Linnakangas and Andres Freund, along with the OpenAI Security Research Team and the Anthropic OSS program.

Before going public, Ince spent August coordinating with every major managed provider. He shared working proofs of concept with AWS covering both Aurora and RDS, Microsoft for Azure Database for PostgreSQL, Google for AlloyDB, Supabase, Databricks, and Ubicloud. Google AlloyDB escalated the report to its highest internal priority. Databricks validated the exploits the same day they arrived. Several vendors deployed their own mitigations before the upstream release shipped. Their current patch status is not public, so administrators on managed services should verify the minor version their provider is running.

The release also contains a flaw that skips authentication entirely. CVE-2026-116322, rated 5.3, lets any client restart a PostgreSQL 18 server without logging in. It involves a cancel request and a spinlock held during the authentication timeout window. Two further vulnerabilities sit in the client tools: a crafted archive fed to pg_restore can execute code as whoever invoked it, and a compromised source server can inject commands through the restore script inside pg_dump's tar output to any psql client connecting to it.

The November release permanently closes the PostgreSQL 14 branch. Version 14.25 is its last update. Administrators still on that version are running unsupported software from today. PostgreSQL 15 reaches the same status in November 2027.

Upgrading involves more than swapping binaries. The fix for CVE-2026-6460 changes the server's internal ABI for C-language extensions, which must be rebuilt against the patched version. Extensions compiled for the new release will not load on an unpatched server, so the upgrade and the rebuild must happen together. A new server setting, composite_type_mismatch, enables the type-version checks behind the fix; the project says disabling it carries security risk. Client tools must be updated on every machine running them, not just servers. Clusters managed by Patroni or any custom service unit need a manual restart. Users of incremental backups should take a new full backup before anchoring further incrementals. No workaround exists for the principal vulnerability on servers that cannot be patched, and PostgreSQL has reported no attacks in the wild.

The same acknowledgment list that names Ince, Linnakangas, and Freund also includes AI-assisted tooling. That dynamic cuts both ways. PostgreSQL 19, normally shipped in September or October, was pushed to November 19 partly because AI and LLM tools generated enough new reports to overwhelm the maintainers' review capacity before the feature freeze. Developer Robert Haas noted that LLM-drafted patches still need human review to meet project standards, and consultant Christophe Pettus pointed to the volume of low-quality machine-generated reports as a growing burden. The same tools that surfaced a 22-year-old bug made it harder to ship the next version.


SilentAir Hacks Asian Telecom Networks to Intercept Calls and SMS Verification Codes

 

A cyber espionage group known as SilentAir has been attacking telecoms infrastructure throughout Asia to listen in on selected individuals’ calls and text messages. This was uncovered by Enea, a telecom security firm based in Stockholm. They believe with high confidence that the campaign is state-sponsored, however it is uncertain how connected it is to China. Enea were able to trace the attacks to compromised devices within mobile operators in at least 6 countries throughout Asia. 

They have informed the operators but cannot confirm that all devices are now clean. SilentAir attacked the trust between mobile networks using the SS7 and Diameter protocols to communicate. This communication occurs on the IPX network which links all operators together. They sent false UpdateLocation messages to the compromised devices claiming they were the serving network for targeted users. When this was accepted calls and texts were redirected towards the attacker. Whilst they were intercepting some calls, Enea were able to see SMS 2FA codes being captured straight after the redirection. This suggests they were trying to breach other accounts for their victims. 

However during their investigation there was no confirmation that they were able to take over any accounts, nor was there any evidence of voice calls being intercepted. Intercepting calls made up 18.3% of the attacks they observed compared to only 2.1% from their previous research into common signalling attacks. There were many high value targets such as political and government individuals. 

In some cases multiple compromised devices were used across different countries to target the same individuals suggesting there was some central control. The attacks occurred in short bursts. At times thousands of subscribers were targeted but then nothing happened for months. Whilst the main focus was Taiwan, networks across Southeast Asia, East Asia, East Africa, Central Asia, Middle East and Europe were also targeted. 

There was a large amount of silent SMS being used. Many targeted Taiwanese subscribers during the evening, potentially to check if the redirection was working. Many were sent during the day to subscribers on other networks. The messages had generic English text relating to promotions and motivation, so could have been seen as spam if the silent settings were turned off by the operators. Enea started to see strange signalling activity in early 2025. 

Eventually they were able to see compromised devices sending and receiving attack commands confirming that the operators internal infrastructure had been compromised. They looked into potential links with another telecom focussed threat group called Liminal Panda but there wasn’t enough evidence to connect them. SilentAir also had similarities to SCTPE, a Linux based tool used to manage SS7 and Diameter traffic. This has been referred to as SIGweaver within a government advisory from Singapore. 

However the capabilities differ and there was not enough operational security to link them. Liminal Panda activity was also detected by Enea across multiple customer networks in early 2026. They blocked GTPDoor backdoor traffic across at least 5-10 operators. The new version of this is harder to detect as it hides the commands within GTP-U traffic.

Enea recommend using GTP-C and GTP-U firewalls, treating all IPX connections as untrusted and ensuring telecom monitoring is brought into the wider IT security.

Operation Endgame Takes Down Three Malware Networks, Recovers 6.4 Million Stolen Logins


An international law enforcement operation has shut down the infrastructure behind three major malware operations: Gootloader, CastleRAT and StealC, seizing 235 servers and 257 domains used by cybercriminals to distribute malicious software, steal sensitive information and support ransomware attacks.

Operation endgame disrupts three major malware networks

The coordinated action, conducted as part of Operation Endgame, also resulted in the identification and seizure of approximately 6.4 million stolen login credentials belonging to victims worldwide. According to Germany's Federal Criminal Police Office (BKA), the credentials were associated with more than 40,000 victims.

Gootloader spread malware through compromised websites

Gootloader is a malware loader that enables attackers to gain initial access to compromised computers and subsequently install additional malicious programs, including ransomware. Its operators distributed malware through fake legal documents hosted on compromised websites, frequently exploiting hacked WordPress sites.

The attackers also used search engine optimisation (SEO) poisoning to manipulate search results and direct unsuspecting users towards malicious downloads. 

Since 2018, Gootloader has infected at least 25,000 computers worldwide, according to the U.S. Department of Justice. In the United States alone, the malware has been linked to ransomware attacks against at least 44 victims, resulting in estimated losses of approximately $28.8 million.

As part of the operation, authorities dismantled 14 servers and 218 domains associated with Gootloader and cleaned 681 compromised websites.

Castlerat and stealc enabled remote access and credential theft

The investigation also targeted CastleRAT, a remote access trojan that allows attackers to remotely control infected systems and use them for malicious activities. Authorities seized 120 servers and 39 domains linked to the operation.

Meanwhile, StealC, an information-stealing malware, was another major target. The malware is designed to extract sensitive information, including passwords, stored credentials and digital identities, from compromised computers. 

This latest disruption follows an earlier law enforcement action against StealC in June 2026. Following that operation, its operators reportedly rebuilt their infrastructure and resumed activities to evade investigators.

Europol's European Cybercrime Centre (EC3) supported the investigation through cyber intelligence, financial tracking and victim identification. Authorities also plan to make information about affected users available through several cybersecurity platforms, including Have I Been Pwned, and the Shadowserver Foundation.

Although no arrests were announced during this latest action, Dutch authorities have continued investigations targeting Gootloader's suspected main operator.

Hackers Steal Personal Information in Cyberattack on University of Texas at Arlington


UTA has confirmed that hackers have stolen personal information as a result of a cyberattack last month that affected its IT environment. A university investigation into unauthorized activity has led to this disclosure, although the university has not yet determined the full extent of the data exposure or identified all individuals whose information may have been compromised as a consequence of the data exposure. 

During a response to Recorded Future News, a university spokesperson confirmed the investigation identified data theft, but did not provide specific details regarding which types of information were accessed by the attackers. As part of the university's ongoing efforts to determine the scope and nature of the compromised data and identify potentially affected students and employees, we are currently conducting research. 

According to UTA, individuals who are identified as affected will receive notifications describing the incident, the information involved, and the methods available for protecting their personal information. In addition, the university plans to provide support and guidance to individuals whose information has been exposed. 

In the initial phase, the incident was noticed following disruptions involving MachForms, an online platform used for registrations, service requests, surveys, and other administrative functions. UTA immediately took the platform offline as a precautionary measure following the discovery of the security incident. 

While the investigation continues, MachForms will remain unavailable. The university has also monitored its IT environment to detect any further impacts on its systems or daily operations. There has been no specific timeline provided for the restoration of the affected service. With approximately 41,000 undergraduate and graduate students, The University of Texas at Arlington is one of the most prestigious higher education institutions in Texas. 

It is alarming to learn that personal information belonging to academic and administrative members of the university was stolen, raising concerns about the possibility of sensitive data being exposed. A ransomware attack was claimed earlier this week by the Qilin ransomware group. Qilin has established itself as one of the most active ransomware groups targeting a variety of industries. 

Halcyon Ransomware Research Center figures indicate that between July and September 2026, the group is believed to be linked to 344 alleged ransomware incidents, placing it among the top ransomware operators at that time. In addition to the recent arrest of one of the ransomware operation's prominent affiliates in Japan and extradition to Germany, Qilin has also been attracting attention as a result of a series of developments involving its affiliates and leadership. 

The Russian national Aleksey Mikhailovich Yakovtsev has been identified as a leader of the ransomware network by cybersecurity companies and independent researchers, adding to ongoing investigations into the individuals behind the ransomware network. In addition to claiming responsibility for attacks on the US Bureau of Alcohol, Tobacco, Firearms and Explosives (ATF), the group has also claimed responsibility for attacks on government and institutional targets in the past few months. 

Using its double-extortion strategy, the organization threatens to publish the stolen files if victims refuse to pay ransom. These tactics increase the workload on organizations, particularly those that handle large volumes of personal and administrative information. This incident occurs during a period when higher education institutions are experiencing a series of ransomware attacks. 

According to York University's recent announcement, attackers have accessed and taken substantial amounts of student information, including more than a decade of student records. Besides raising concerns about the long-term exposure of personal information maintained by academic institutions, Vanderbilt University has also suffered from a separate ransomware attack which has adversely affected its operations. 

University officials have advised that it may take several weeks to restore normal operation across the university's systems. The university's efforts to recover are concentrating on essential services such as payroll, payment processing, admissions, course registration, and public safety. Vanderbilt remains under investigation for possible data theft. 

A group responsible for BYOD ransomware has claimed responsibility for the incident at Vanderbilt, as well as recent attacks that affected Michigan State University and New Mexico University. Newly emerging groups and their operations are relatively unknown to researchers. There has been an increasing number of attacks against universities, which have highlighted the risk faced by educational institutions that maintain extensive student, employee, and administrative databases. 

Having disruptions to academic services, combined with unauthorized access to personal data, can adversely affect institutions and their communities for a long period of time. Immediately, the top priority at UTA is determining the scope of the breach, identifying those affected, and restoring the impacted services in a secure manner. 

As higher education institutions manage large quantities of sensitive student and employee data, cybersecurity risks are becoming increasingly important. As UTA continues to assess the extent of the breach and identify affected individuals, this case illustrates the importance of strengthened data protection measures, timely incident response, and continuous monitoring of university information technology systems. 

As well as reflecting the persistent threat that ransomware groups pose to educational institutions, Qilin's involvement also demonstrates the possibility of long-term consequences when disrupting operations and revealing data.

Baker Tilly Discloses Third-Party Data Breach Affecting Nearly 196,000 Individuals

 



Baker Tilly Advisory Group has begun notifying clients about a data breach involving an external service provider, after an unauthorized actor obtained personal information belonging to certain clients and their dependents.

The compromised information was stored on a platform operated by a third-party provider that Baker Tilly uses to deliver its client services. According to the company's notification letter, Baker Tilly discovered the incident on September 6, 2026, and completed its review of the affected records on October 28, identifying the individuals whose information had been exposed.

In its notification, Baker Tilly stated that it became aware of a potential cybersecurity incident involving information maintained on the third-party platform. The company subsequently confirmed that an unauthorized party had obtained data associated with some of its clients.


Nearly 196,000 Individuals Reportedly Affected

Although Baker Tilly's notification does not disclose an overall number of affected individuals or identify the third-party service provider, regulatory disclosures provide further details about the incident's scale.

A filing submitted to the Texas Attorney General's Office lists 10,456 affected Texas residents. The disclosure identifies individuals' full names, addresses, Social Security numbers (SSNs), and other information among the compromised data categories.

The same filing reportedly records a nationwide impact of 195,512 individuals. Additional state disclosures include 1,359 affected residents in South Carolina and 2,689 in Massachusetts. However, the company has not independently provided a consolidated figure in its customer notification.

The sample notification letter published through state regulatory disclosures also contains an unfilled placeholder where the specific categories of compromised personal information should appear. Consequently, the Texas filing currently provides the clearest publicly available breakdown of the exposed information.


Baker Tilly Investigates Third-Party Security Incident

Following the discovery, Baker Tilly says it initiated containment measures and engaged external cybersecurity specialists to investigate the incident, establish its scope, and determine which information had been accessed. The company also notified law enforcement authorities and stated that it is cooperating with their investigation.

Baker Tilly maintains that its investigation has found no evidence of continued unauthorized access to its own network or systems. It has also reported no known instances of identity theft or fraud connected to the compromised information.

However, the absence of reported fraudulent activity does not establish that the exposed information cannot be misused in the future, particularly where government identification numbers and residential information are involved.


Affected Individuals Offered 24 Months of Experian Protection

To address potential consequences of the exposure, Baker Tilly is providing affected individuals with complimentary access to Experian IdentityWorks for 24 months.

According to the notification letter, the package includes credit monitoring, identity restoration assistance, and access to specialists who can help investigate and resolve identity theft incidents. The membership also includes up to $1 million in identity theft insurance, subject to the applicable policy conditions and exclusions.

The company has advised recipients to monitor their financial statements and credit reports for unfamiliar transactions or other suspicious activity.


Baker Tilly's Global Operations

Baker Tilly provides accounting, auditing, tax, consulting, and business advisory services. Its international network reported annual revenue of $6.8 billion for the financial year ending December 31, 2025, representing a 21.3% increase over the previous year.

According to its January 2026 financial announcement, the network comprises more than 50,400 professionals operating across 147 territories and 754 offices.

The company has not publicly identified the compromised service provider or explained how the unauthorized actor gained access to its platform. BleepingComputer also reported that it had contacted Baker Tilly seeking clarification about the incident, affected customer numbers, and compromised information but had not received a response at publication time.

No ransomware group had publicly claimed responsibility for the incident at the time of reporting.

Massive GitHub Supply-Chain Attack Exposes Secrets in 1,800+ Repositories

 

A large-scale software supply-chain attack has compromised thousands of GitHub accounts and exposed secrets across more than 1,800 repositories. According to Aikido Security, an attacker used stolen credentials to gain write access to GitHub accounts and planted a malicious continuous-integration (CI) workflow designed to steal cloud credentials, tokens, and other sensitive information. The malicious code was inserted into repositories and often removed within minutes, making the incident difficult to detect. The campaign demonstrates how compromised developer accounts can be weaponized to attack the software supply chain, potentially affecting organizations far beyond the initially targeted repositories. 

The attackers reportedly gained control of 4,837 hijacked GitHub accounts and used their write permissions to insert a secret-stealing payload into repositories. The malicious workflow ran in at least 1,806 repositories, meaning credentials and cloud roles accessible to those repositories’ CI pipelines should be treated as compromised. The campaign began with seemingly harmless pull requests titled “docs: dependency audit notes,” submitted from branches named wfx-docs. These requests were opened in 61,764 repositories, apparently to test whether the compromised accounts could write to them, before malicious commits were added to a smaller group of targets. 

A separate analysis by SafeDep identified 8,093 public repositories that received malicious commits between 12:46 UTC on Tuesday and 04:36 UTC the following day. Because the researchers examined only default branches of public repositories, the actual number of affected repositories is likely higher. In 7,309 repositories, the attacker added the stealer to an existing GitHub Actions workflow. In another 771 repositories, it was inserted as an npm postinstall hook, which could execute on a developer’s machine when they ran npm install. After deploying the payload, the attacker frequently reverted the changes within minutes and deleted workflow logs, sometimes removing the workflow run entirely. 

The malware collected a broad range of sensitive material from CI runners, including GitHub Actions secrets and variables, the workflow’s GITHUB_TOKEN, OIDC and runtime tokens, AI-service keys, and credentials stored in process memory. It also searched for credential files associated with AWS, Azure, Google Cloud, Kubernetes, npm, PyPI, and SSH. The attack was not limited to stealing short-lived tokens: researchers found that the malware could exchange GitHub OIDC tokens for AWS, Google Cloud, and Azure sessions, potentially allowing the attacker to move deeper into cloud environments.

On AWS, the stealer could create long-lived access keys for IAM users and rewrite a role’s trust policy to make it accessible from other AWS accounts. In Azure, it could add federated identity credentials prefixed with wfx-ci- to Entra ID applications, allowing workflows to authenticate even after original tokens were rotated. Repository owners should search for suspicious branches such as wfx-docs, ci-check-[0-9]{4}, and short-lived chore/ branches. They should also look for pull requests titled “docs: dependency audit notes” and commits labeled ci: refresh build cache, chore: add ci helper, ci: restore, or ci: cleanup. 

Other indicators include unexpected workflow files, a .ci-xxxxxx.sh script, an npm postinstall hook, and the SHA-256 hash 89695abb392d5cfd4972672961e644bb46baa98aa1ed7173c2a2816c762735cf. Affected repository owners should immediately revoke the compromised account’s tokens, OAuth grants, SSH keys, and active sessions, then enable two-factor authentication. They must also rotate every secret, variable, cloud credential, and API key that the affected repository or CI workflow could access. Developers who ran npm install on an affected commit should treat their machines as compromised and rotate local keys and credentials. 

Organizations should also review GitHub Actions permissions, restrict workflow access to secrets, require approval for changes from outside collaborators, and monitor cloud logs for suspicious identity activity. This incident highlights that developer accounts, CI systems, and cloud identities are now primary targets in software supply-chain attacks, making strong authentication, least-privilege access, secret rotation, and continuous monitoring essential defenses.

Apache HTTP/2 Security Flaw Exposes Servers to Critical Remote Code Execution Attacks

 

A new vulnerability in Apache HTTP Server could allow an attacker to run malicious code remotely on vulnerable systems. The vulnerability, tracked as CVE-2026-119618, affects the HTTP/2 module (mod_http2) and has a CVSS score of 9.8 which means it is critical. This has been fixed in Apache version 2.4.71 which was released on the 11th November 2026. 

The Apache versions affected are between 2.4.55 and 2.4.70. However, only systems where HTTP/2 has been enabled are vulnerable. Red Hat state "An attacker with network access to a vulnerable system could exploit this vulnerability to take control of the server process." As no authentication is required systems that are network accessible could be at high risk. Red Hat’s analysis of the vulnerability states that there is public research showing a reliable exploit for a server running the default configuration and mod_http2 enabled. The research was not detailed or sourced. 

However, cybersecurity firm Wiz state that there is no exploit available and no attacks have been observed in the wild. HTTP/2 is not enabled by default. It can be enabled globally for all virtual hosts or just on specific virtual hosts. This is done by adding ‘h2’ to the Protocols directive for secure HTTP/2 (TLS) or ‘h2c’ for insecure HTTP/2 (TCP). All configuration files should be reviewed by the security team. Apache recommend upgrading to version 2.4.71. This also includes a fix for a crash issue in mod_md (Important) and a memory overwrite vulnerability in mod_vhost_alias (Low severity). If you are using official builds of Apache then administrators should upgrade to the latest version. This also affects standalone versions of the HTTP/2 module (mod_h2). 

These versions affected are between 2.0.8 to 2.0.42. There is no fixed version available. The GitHub repository has been archived and the latest version published is 2.0.42. The patch is available for some OSs. Red Hat have patched Enterprise Linux versions 9 and 10. However, this vulnerability is rated as Important. This is because the HTTP/2 streams use separate memory allocators making it harder to exploit. Enterprise Linux 8 and below are unaffected. Debian have patched this in their unstable version. Bookworm, trixie and forky are still affected. 
Amazon Linux 2, 2023 and 2027 Preview are waiting on patches. Ubuntu do not have a specific vulnerability page.  
If you cannot patch your systems then Wiz recommend disabling HTTP/2 by removing ‘h2’ and ‘h2c’ from the Protocols directive. This will leave you with HTTP/1.1. This vulnerability was first reported by Anthropic’s OSS Scanner on the 26th October. The scanner uses Anthropic’s AI models to scan open source software. It was also reported by Anthony Weems and Simon Scannell from Google Cloud Vulnerability Research last week. This comes after another vulnerability in Apache’s HTTP/2 module (CVE-2026-23918) was patched in version 2.4.67 in May. Upgrading to this version or any version after up to 2.4.70 won’t protect your systems from this new vulnerability.

Critical Red Hat Quay Flaw Could Allow Attackers to Steal Private Container Images


A critical security vulnerability in Red Hat Quay, an enterprise container registry platform, could allow attackers to access private container images, modify repository contents and maintain persistent access to affected systems. 

Tracked as CVE-2026-123710, the flaw carries a CVSS severity score of 9.8 out of 10, placing it in the critical category. According to Red Hat, the vulnerability affects deployments in which the service responsible for managing signing keys is accessible to untrusted clients.

The vulnerability exists in Quay's service key server, which manages the cryptographic keys used to sign registry access tokens. These tokens determine whether users and applications can download or upload container images.

According to Red Hat's security advisory, an unauthenticated attacker can exploit weaknesses in the key rotation mechanism to install an unauthorized signing key that the registry automatically trusts. When anonymous access is enabled, an attacker can obtain a registry token and use it to manipulate the key rotation process.

Once the malicious key has been installed, attackers can generate their own registry tokens with read and write permissions across repositories. This allows them to access private container images belonging to other users or organizations without following the platform's normal access restrictions.

According to Red Hat's Bugzilla report, "rotation also deletes the legitimate instance key as a side effect, and the attacker key can delete replacement instance keys."

Beyond stealing images, attackers could also replace or overwrite repository contents. Such modifications could affect software development and deployment processes, particularly when automated systems download compromised images from the registry. Sensitive credentials and other secrets stored within container images could also be exposed.

Another scaring aspect of the vulnerability is the persistence of unauthorized access. The malicious signing key can be configured without an expiration date and remains active even after the registry is restarted. Red Hat also warned that attackers could use the compromised key to delete legitimate signing keys, potentially disrupting normal image uploads and downloads.

Disabling anonymous access does not completely eliminate the risk, as users with valid Quay accounts can also exploit the vulnerability. Similarly, changing account passwords or regenerating robot account tokens will not invalidate an unauthorized signing key.

Red Hat recommends administrators immediately restrict access to the key-management service.

Red Hat cautioned that removing malicious keys alone may not provide lasting protection until a fixed version is installed, as attackers could potentially reinstall them.

The vulnerability was discovered by Red Hat researcher Dave O'Connor. Fixes for the issue were merged into the project's GitHub repository on November 11.

GSocket Backdoor Allows Hackers to Retain Remote Control Over Linux Servers


GSocket is a legitimate open-source remote access tool that is being exploited by multiple threat actors to remain undetected even after the vulnerabilities used to gain entry have been patched. As a result of this activity, attackers are developing independent access channels that remain active after the initial security breach, highlighting the growing post-compromise threat. 

Microsoft released a report on November 11, 2026 detailing malicious use of GSocket across Linux environments in significant numbers. Microsoft Defender for Endpoint telemetry reports a 356.2% increase in detections of GSocket-related attacks between March and August 2026. The attacks primarily affected internet-facing web applications as well as hosting infrastructure. 

As a networking utility, GSO sockets were originally developed to allow remote communication between systems behind firewalls and Network Address Translation (NAT) devices. As a result of these networking capabilities, attackers are establishing encrypted command-and-control connections via GSRNV through the Global Socket Relay Network in an attempt to exploit its capabilities. 

In contrast to conventional remote access methods, GSocket does not require attackers to directly access compromised servers. By establishing outbound connections to the shared relay network, both the infected host and the operator are able to communicate. In addition to eliminating the need for an exposed inbound port, a public IP address, or a dedicated C2 server controlled by an attacker, this communication model also diminishes conventional network defense capabilities. 

A firewall rule that identifies inbound connections cannot easily identify these connections, and blocking individual IP addresses or domains may not interfere with access as traffic passes through a shared relay system. However, egress filtering and outbound traffic monitoring can be useful for identifying or preventing suspicious communications. 

Most detected activities occur in web hosting environments

An analysis conducted by Microsoft determined that web applications and hosting environments contributed 87.1% to the number of incidents attributed to GSocket. PHP web applications and cPanel hosting accounted for 63.9% of incidents, while Apache environments contributed 24.3%. In conclusion, these findings indicate that internet-facing Linux infrastructure is a significant target of this activity. 

GSocket is typically downloaded and launched through shell commands by attackers using vulnerabilities in exposed web applications. Once deployed, the tool operates independently of the vulnerable application. As a result, patching the original security flaw or restarting the affected service does not terminate or remove the malicious client or terminate its access channel automatically. According to Microsoft, education and research organizations accounted for 30.7% of affected organizations, followed by technology and telecommunications with 22.9%. 

Attackers Establish Multiple Persistence Mechanisms

Following the initial compromise, Microsoft found that attackers used a number of methods to maintain GSocket running. These malicious processes were renamed in order to appear to be legitimate Linux kernel threads or system services, which made them less noticeable during routine system checks. In some cases, hidden files were also installed in temporary or memory-backed directories to facilitate the deployment process. 

There were some intrusions involving watchdog processes and duplicate copies of the tool, which enabled access to be restored if one instance was removed. Persistence was established by cron jobs, systemd services, and shell startup files. As part of their efforts to complicate investigations, attackers also deleted installation files and other traces of deployment. 

Moreover, the research identified attempts to exploit the Linux kernel vulnerability CVE-2026-43284, commonly referred to as Dirty Frag, which can allow attackers to elevate their privileges from a web-service account to root. This was observed in a limited number of incidents, but success in escalation of privilege was not always observed. 

Shared relay network complicates blocking

GSocket identifies and authenticates its endpoints utilizing a shared secret rather than a fixed IP address. During installation, a secret is generated and made available to the operator in a variety of ways. By using that information, the attacker can connect to the compromised server using a client that is compatible with the Global Socket Relay Network, regardless of the network address of the compromised server changing. 

Consequently, conventional IP-based blocking is less reliable due to the shared relay infrastructure, rather than controlled by a single attacker. Therefore, blocking an attacker's address may not interrupt the connection, which makes conventional IP-based blocking less reliable. Nevertheless, Microsoft stated that monitoring outbound traffic and imposing egress restrictions remain useful methods of identifying or limiting such activity. 

A host-level investigation and remediation is recommended by Microsoft

GSocket activity should be treated as a host compromise, rather than assuming that patching the vulnerable application will resolve the issue. Security teams should locate and eliminate unauthorized GSocket clients, staged files, and persistence mechanisms, as well as check whether suspicious outbound connections have been terminated. It is also recommended that cron entries, systemd units, and shell startup files be reviewed for unauthorized changes. 

Updated applications, plugins, and server components, as well as unused services and unnecessary administrative paths or file upload paths, should be restricted. Furthermore, organizations should limit outbound connections to destinations necessary for normal operations and monitor any unexpected communications that may occur from web server processes. 

The configuration of temporary and memory-backed directories should be modified so that they cannot be executed, thereby reducing the opportunity for attackers to launch hidden payloads. Moreover, Microsoft advised prioritizing Linux kernel security updates, focusing primarily on the CVE-2026-43284, as well as monitoring suspicious web application processes. 

A compromised Linux server cannot be considered secure unless the GSocket client, persistence mechanisms, and all remaining outbound communication are addressed as part of incident response. According to its research, removing the entry point is only one component of incident response. As the GSocket client is increasingly abused, organizations face difficulties identifying legitimate tools repurposed for malicious purposes. 

Linux environments must be secured against internet-facing applications, monitored outbound network traffic, and audited for persistence mechanisms in order to detect hidden access and be protected from long-term compromises.

AntiFox AI Pentest Tool Linked to AWS Production Secret Theft

 

Cybersecurity researchers have linked the open-source, AI-driven penetration-testing platform AntiFox to real-world intrusions involving AWS credential theft and access to production secrets. According to Arctic Wolf Labs, Alibaba Cloud systems hosting AntiFox interfaces were associated with malicious activity against internet-facing web services and connected AWS environments, showing how autonomous AI security tools can be abused for offensive operations. 

AntiFox is built on ARTEX and uses a planner, worker, and main-agent architecture to carry out penetration-testing engagements. Given an authorized target, it can conduct reconnaissance, discover attack surfaces, exploit weaknesses, capture findings, and generate a report with limited human involvement. The project is publicly available on GitHub and has been forked 251 times and starred 474 times, reflecting growing interest in agentic AI security tooling. 

In one observed attack chain, threat actors compromised an internet-facing Microsoft IIS application. Although the exact initial-access vulnerability remains unknown, they used the IIS worker process, w3wp.exe, to create an ASPX web shell and execute operating-system commands. From there, they searched for web.config files and configuration backups, read application settings and database connection strings, enumerated debug and error-log directories, and copied sensitive configuration and log files into a web-accessible upload directory. 

The attackers also attempted to connect to an internal production database using credentials extracted from application configuration. In separate incidents, they began with valid AWS credentials obtained through means that have not yet been determined. Using legitimate IAM identities and, in some cases, assumed EC2 roles, they authenticated to AWS APIs and enumerated services including IAM, EC2, S3, Lambda, Secrets Manager, KMS, RDS, ECS, EKS, Redshift, Athena, Glue, Systems Manager, API Gateway, CloudWatch, CloudFormation, DynamoDB, and Amazon Bedrock. 

Most authenticated cross-service requests returned “AccessDenied” errors, but some discovery and secret-access operations succeeded. Researchers observed successful GetSecretValue requests against production secrets, as well as S3 discovery and object operations using a valid AWS identity. The activity demonstrates how a small initial foothold can escalate into broad cloud exposure when credentials, configurations, and permissions are not properly secured.

The incident highlights the growing risk posed by agentic AI frameworks, which can automate reconnaissance, exploitation, credential validation, and post-exploitation at machine speed. AntiFox and ARTEX are among roughly 45 open-source agentic attack frameworks that connect large language models to tools capable of acting autonomously. These systems can assemble attack pipelines at runtime—for example, searching GitHub for exposed secrets, downloading scanners, and passing discovered credentials into subsequent stages of an operation.

Organizations should treat exposed configuration files, hardcoded credentials, and overly broad IAM permissions as urgent risks. Security teams should rotate exposed credentials, restrict public access to sensitive files, enforce least-privilege access, and monitor for unusual AWS API activity—particularly bursts of denied requests followed by successful secret retrieval or S3 operations. As AI-driven tools become more accessible, defenders must assume that attackers can automate not only discovery, but also exploitation, credential theft, and lateral movement across cloud environments.

Fortinet Releases Fixes for Nearly 100 Vulnerabilities Across Its Product Lineup

 


Fortinet issued 89 security advisories on November 11, covering close to 100 vulnerabilities across its product lineup, with roughly 17 rated critical and nearly 80 classified as high severity. The release stands as one of the company's largest single-day patch drops, touching nearly every major product in its portfolio.

FortiMail received the heaviest concentration of critical fixes. FortiAuthenticator, FortiOS, FortiManager and FortiAnalyzer followed close behind. FortiSASE and FortiClient also received updates resolving critical issues.

The critical vulnerabilities span a wide range of attack classes. Among those fixed are arbitrary code execution flaws, authentication bypass conditions, account takeover paths, unauthorized access to Virtual Domains (VDOMs), server-side request execution, and a command execution bug that could allow an attacker to run commands with super-admin privileges. FortiMail-specific issues include paths that expose secure email accounts and allow IBE webmail session compromise, along with flaws enabling unauthorized webmail password resets.

High-severity fixes address cross-site scripting, code injection, arbitrary file uploads, denial-of-service conditions, man-in-the-middle attack vectors, privilege escalation, and information disclosure. Fortinet has not attributed any of these vulnerabilities to active exploitation in the wild.


A Notable Standalone Finding

One vulnerability drew particular attention from the security research community. Kevin Joensen, a principal security consultant at Baldur Security, identified and named a FortiClient flaw he called "Fortinet2Shell." The root cause is a CORS misconfiguration that allows attacker-controlled web pages to communicate with a local service running on the target machine.

If a victim visits a malicious website while FortiPAM is enabled, an attacker could achieve arbitrary code execution on that system. The flaw is conditional but the bar for triggering it is low: simply visiting a crafted page is enough. Joensen's research illustrates how client-side software that communicates with local services over HTTP remains a consistent attack surface, one that often gets less scrutiny than server-facing products.


AI in the Testing Pipeline

The scale of this release tracks directly to a shift in how Fortinet approaches internal security testing. Carl Windsor, the company's CISO, confirmed that Fortinet has been running frontier AI models alongside its own on-premises models in vulnerability testing for several months.

The program operates in two phases. In the first, models analyzed firmware without access to source code, mapping how products function and identifying potential attack vectors. Those leads were then validated through penetration testing and red teaming. The black-box phase returned few directly exploitable flaws, but the models showed strong capability in comparing firmware versions across releases and building proof-of-concept exploits for bugs that had already been patched.

The second phase involved source code analysis. Across more than 100 tests spanning 30 product families, roughly 40 percent of findings were genuine vulnerabilities, 30 percent were false positives, and the remaining 30 percent were security improvements that did not rise to the level of exploitability.

Windsor did not frame AI-assisted testing as a silver bullet. He acknowledged that the same tools available to Fortinet's internal teams are available to attackers, and he warned that the gap between public disclosure and active exploitation is getting shorter. "The window between disclosure and exploitation continues to shrink, and we expect it to keep shrinking," he said.


The Urgency Behind Early Disclosure

Fortinet's decision to hold technical details until a fixed release is available reflects a deliberate strategy. Once a patch ships, researchers and threat actors alike can reverse-engineer the changes to identify what was fixed and where. For organizations running unpatched versions, that creates a narrow and shrinking window of practical anonymity.

Windsor noted that internet-facing systems should be prioritized for immediate patching. For organizations that cannot apply fixes right away, interim steps include restricting administrative access to trusted IP ranges, keeping FortiManager off public networks, enforcing strong and unique credentials, and requiring multi-factor authentication for all admin accounts. He was direct that none of these measures replace upgrading the software.

Fortinet's PSIRT page at fortiguard.com/psirt carries the full list of advisories and affected version ranges.

The November batch comes weeks after the company released urgent fixes for FortiOS and FortiManager, some of which were also flagged as AI-assisted discoveries. The cadence suggests Fortinet is now committing to more frequent and larger release cycles as a direct consequence of expanding its AI testing program, a move that will likely increase pressure on enterprise security teams to maintain tighter patch windows across Fortinet deployments.