Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Latest News

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,...

All the recent news you need to know

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.


Poland Takes Government Services Platform Offline After Detecting Cyberattack


Poland has temporarily shut down its national electronic government services platform, ePUAP, after authorities detected and stopped a cyberattack targeting the system. The precautionary shutdown has disrupted access to several online public services used by citizens, businesses and government institutions.

The incident was confirmed by Polish Digital Affairs Minister Krzysztof Gawkowski, who said security teams had responded immediately after identifying the attack. In a social media statement, Gawkowski said the cyberattack against the state-run ePUAP system had been detected and halted, while technical teams were working to restore its full functionality.

The ePUAP platform is a central part of Poland's digital government infrastructure. It allows individuals and businesses to submit official documents, communicate with government departments and complete various administrative procedures online. Its temporary closure has therefore affected an important channel through which people interact with public authorities.

Gawkowski also confirmed that the infrastructure of the Central Information Technology Center, the government agency responsible for maintaining ePUAP and other essential digital services, remained secure. Officials stressed that the platform was taken offline as a precautionary measure rather than because the cyberattack had caused damage or disrupted its operations.

Marek Gieorgica, spokesperson for Poland's Digital Affairs Ministry, told the Polish news agency PAP that the system had not been compromised by the incident. He explained that authorities had deliberately disabled the platform to reduce potential risks while security teams assessed the situation.

However, the government has not disclosed technical details about the attack, including the methods used by the attackers or the identity of those responsible. There is also no public confirmation that hackers gained unauthorized access to government systems or managed to steal sensitive information.

According to a notice published on the government's website, ePUAP electronic mailboxes are currently unavailable to both citizens and public institutions. The disruption could also temporarily affect Poland's Trusted Profile digital identity service, which enables users to access online government services and electronically sign official documents.

Authorities have not announced a specific timeline for restoring the platform. Services are expected to resume after cybersecurity specialists complete their investigations and necessary technical checks.

The incident comes amid a series of cyberattacks targeting Polish government institutions, critical infrastructure and private organizations in recent months. In October, online invoicing provider Fakturownia reported a data breach that potentially exposed information belonging to its users, customers and business partners.

Earlier, in September, hackers stole data from Qbusoft, a Polish healthcare software provider, following a separate security incident involving medical technology company MyDr. Polish authorities said the MyDr breach could have affected information associated with approximately 19 million individuals and around 12,000 healthcare organizations.

Volta-Autodoxer Malware Uses Artificial Intelligence to Rank Victims and Build Detailed Personal Dossiers

 

Cybersecurity researchers at Cisco Talos have uncovered a new piece of malware known as Volta-Autodoxer (VOLTA) which uses commercial AI models to analyse the data it steals from Windows systems, identifying the most valuable targets. This shows that AI technology is now increasingly being used inside malware to automate processes. 

While traditional infostealers will steal sensitive data from infected systems such as saved passwords, browser cookies, payment card details, crypto wallet recovery phrases, authentication tokens and cloud credentials, the attacker often has to manually search through large amounts of data to identify valuable targets. Volta aims to cut this out using automated analysis of the victims data on the infected system. 

During the data collection phase, the malware will collect credentials, session data, Wi-Fi profiles, SSH keys, Microsoft OAuth tokens and screenshots of the desktop. It will also target Discord, Telegram, Steam and Roblox accounts to collect active session and account data. It will then use the stolen session tokens to access the victims main email accounts. This includes Gmail and Outlook. It will look at purchase confirmations and order history on services like Amazon, UberEats, DoorDash and Grubhub. This can give an insight into the victims home address, shopping habits, daily routines, work details and other personal information. It can also look up third-party services such as Rolimons to determine the resale value of their Roblox items. 

The malware will then organise the data it has collected and send it to OpenRouter, an API gateway that allows access to multiple AI models. The prompt inside the malware will tell the language model to act as a forensic intelligence analyst. It will create a detailed report on the victims and will identify if they could be valuable financially and how good their operational security is. The malware will use Anthropic’s Claude Opus 4.6 model by default. However, the developers have considered that there may be AI safety measures in place preventing the creation of malicious reports. 

The malware will look for rejection phrases such as 'I can’t’ in the models responses and switch to another provider if the request is denied. It will switch to Moonshot AI’s Kimi K2 and Google’s Gemini 2.5 Flash. Once the report has been created, the malware will package the stolen data and AI report into ZIP files. These will be sent directly to the attackers via a Telegram channel. Files will be named things like volta_dox.zip. The malware was discovered by Cisco Talos during their research using the CAIRN research framework. 

The builder also has configurable fields suggesting that this malware may have been designed to be distributed or sold to other cybercriminals. While it has not been seen widely in the wild, it shows how AI can be used to help attackers target victims more effectively by automatically creating profiles. This makes the personal information stolen more useful for targeted cybercrime.

Featured