Search This Blog
Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Load More
Trendy Right Now

Popular Posts

Showing posts with label Zero-Day Exploit. Show all posts
Zimbra Zero-Day
CVE-2025-66376 cyber espionage email security Laundry Bear Russian Espionage Group Two-Factor Authentication Vulnerabilities and Exploits Zero-Day Exploit Zimbra Security Zimbra Zero-Day

Russian Cyber Spies Exploited Critical Zimbra Flaw to Access Emails and 2FA Codes


 

Cyber espionage groups backed by the Russian government exploited a previously unknown vulnerability in the Zimbra Collaboration Suite (ZCS) in order to steal emails, browser credentials, and two-factor authentication (2FA) recovery codes from government and commercial organizations throughout the world, according to a joint cybersecurity advisory issued by the U.S. National Security Agency (NSA), the Cybersecurity and Infrastructure Security Agency (CISA), and international partners. 

In the campaign, CVE-2025-66376 was used to exploit a stored cross-site scripting (XSS) vulnerability affecting Zimbra's Classic Web Client. According to Proofpoint, the flaw was exploited as a zero-day attack for at least five months before a security patch was available in November 2025, identified by Palo Alto Networks Unit 42 as CL-STA-1114. It is reported by the Dutch General Intelligence and Security Service (AIVD) that the activity is referred to as Laundry Bear, while cybersecurity vendors continue to use different tracking names for the same or similar threats. 

The vulnerability allowed attackers to compromise users by merely opening or previewing a specially crafted HTML email in a Zimbra session that was vulnerable. Upon activating the malicious JavaScript within the authenticated webmail session, attackers gained access to the victim's mailbox without requiring additional interaction from them. 

The campaign has been described as a "half-click" phishing attack by security researchers, as the victim only needed to browse or open the malicious email in Zimbra's Classic Web Client to gain access. As opposed to conventional phishing campaigns that require the user to click links or download attachments, the exploit executed automatically when the email was rendered, which permitted the execution of arbitrary JavaScript within the authenticated webmail session. 

According to researchers, the ZimReaper malware harvested emails from the last 90 days, the organization's Global Address List, browser-stored passwords, details on Zimbra versions and recovery codes for two-factor authentication. Besides exfiltrating data through DNS queries, attackers also created app-specific passwords for retaining persistent access to compromised accounts even after password changes. 

In accordance with the advisory, the campaign targeted government, military, transportation, financial, and scientific organizations throughout NATO member countries, Ukraine, the Commonwealth of Independent States, Africa, and the United States. Researchers did not disclose the number or identities of affected organizations. The operation is believed to have been conducted in support of Russian intelligence objectives to gather sensitive information.

One of the longest-running known exploit campaigns against Zimbra was launched in July 2025, according to intelligence officials. It was publicly disclosed and patched in August 2025, making it one of the longest-running known exploit campaigns. Versions 10.0.18 and 10.1.13 of Zimbra addressed the vulnerability, while CISA added it to its Known Exploited Vulnerabilities (KEV) catalog in March of 2026. 

According to security experts, applying a patch alone will not be sufficient if a system has been compromised since the update occurred. Although Zimbra released a fix in November 2025, the vulnerability was not assigned a CVE identifier until several weeks later and was publicly documented. It has been argued that the delayed disclosure may have contributed to organizations remaining unaware of the active threat while attackers continued to exploit vulnerable servers. 

In addition to upgrading to supported Zimbra releases, organizations are advised to reset passwords for accounts that may be affected, invalidate active sessions, generate 2FA recovery codes, remove unauthorized passwords for applications, and review logs for suspicious activities. Admins should also monitor for unusual DNS requests and inspect email correspondence for indicators associated with the exploit. 

Furthermore, Proofpoint researchers warned that other threat actors have continued exploiting unpatched Zimbra servers, indicating that the vulnerability is still appealing beyond the Russian espionage campaign that originally exploited it. Additionally, the researchers noted that although no evidence has been provided to suggest that the exploit itself was created using artificial intelligence, large language models may assist attackers in identifying future methods for bypassing security patches. 

Despite the absence of activity from the threat group since February 2026, Unit 42 and government agencies remain concerned that attackers continue to target Zimbra environments that are not patched. The advisory warns that Russian espionage actors are likely to continue pursuing email platforms to support intelligence-gathering operations. 

Several zero-day vulnerabilities have been exploited rapidly in this campaign, compromising trusted communication platforms. Organizations using Zimbra are encouraged to ensure that systems are fully patched, review accounts for signs of compromise, revoke unauthorized access, and continuously monitor their environments as a preventative measure against persistent espionage.
Read more »
Zero-Day Exploit
Council of Europe CVE-2026-35273 Cyber Extortion Data Breach Data Leak Employee Data Exposure Identity Theft Oracle PeopleSoft Vulnerability ShinyHunters Zero-Day Exploit

Council of Europe Data Breach Exposes Records of 10000 Employees After ShinyHunters Leak


 

Council of Europe is investigating a major data breach following the public release of approximately 297 GB of sensitive employee data by cybercriminal group ShinyHunters following the expiration of a ransom deadline. 

An archive has been leaked that contains information regarding more than 10,000 current and former employees, contractors, and job applicants dating from 15 years ago. As one of Europe's leading human rights organizations since 1949, the Council of Europe has been an official observer at the United Nations since 1949. It represents 46 member states and is a central force in promoting democracy, human rights, and the rule of law throughout Europe. 

Since the information it holds is sensitive, the breach of confidentiality is particularly significant. As reported by ShinyHunters, more than 429,000 files, including personnel data, were obtained from multiple Council departments, including human resources and administrative units. This was one of the largest breaches of personal data involving an intergovernmental organization in Europe. 

Information available indicates that payroll records, bank account information, medical information, tax information, social security information, salary histories, personnel files, and thousands of CVs were exposed. Due to the large size of the dataset, identity theft, financial fraud, and highly targeted phishing are significantly more likely to occur. It has been reported that the breach is related to CVE-2026-35273, a critical 9.8-severity zero-day vulnerability affecting Oracle PeopleSoft's Environment Management Hub (PSEMHUB). 

According to security researchers, the vulnerability allowed attackers to execute arbitrary code remotely without authentication. According to Google's Mandiant team, more than 100 organizations had actively exploited the vulnerability prior to Oracle's release of security guidance. Using the zero-day vulnerability in combination with older vulnerabilities, ShinyHunters obtained persistent access, migrated laterally through compromised environments, and exfiltrated data while posing as legitimate users. 

The exploit was conducted between May 27 and June 9, before mitigations were available. ShinyHunters has also altered its extortion strategy significantly following the Council of Europe declining to meet the ransom demand. In response to the Council's refusal to pay the ransom, ShinyHunters announced it would permanently distribute stolen datasets through multiple mirror sites and torrent networks, thereby reducing the likelihood of future takedown efforts.

In addition, the incident adds to the growing number of campaigns involving ShinyHunterS Researchers have recently linked the group to attacks targeting multiple organizations, while Google's threat intelligence team has linked the group's latest activity to widespread exploitation of the Oracle PeopleSoft zero-day vulnerability before mitigations were available. 

According to a brief statement issued by the Council of Europe, the organization was "investigating the matter and assessing the situation." Further comment was not provided. The organization has not yet announced a formal notification process or measures to protect individuals' identities. Zero-day exploitation and data extortion campaigns are becoming increasingly prevalent, with public disclosure increasingly taking precedence over traditional ransomware encryption. 

The threat of persistent leak strategies is increasing, which is why organizations are being urged to strengthen vulnerability management, accelerate patch deployment, and improve incident response to minimize both institutions and individuals' long-term risks.
Read more »
Zero-Day Exploit
Argument Injection Credential Theft Cyber Threats Git Repository Security Gogs Vulnerability Open Source Security Remote Code Execution Supply Chain Attack Zero-Day Exploit

Gogs Zero-Day Vulnerability Raises Alarm Over Server Security


 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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