Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Showing posts with label Code Injection. Show all posts

Critical Roundcube Flaw Under Active Exploitation in Code Injection Attacks

 

A high-severity vulnerability in Roundcube Webmail, patched in May 2026, is now being actively exploited in code injection attacks, according to the Canadian Centre for Cyber Security. The flaw, tracked as CVE-2026-48842, allows unauthenticated attackers to bypass security controls and execute malicious database commands, putting millions of email users at risk. 

Roundcube is a browser-based IMAP email client used as the default mail interface by thousands of services and is pre-installed with the widely adopted cPanel web hosting control panel. The vulnerability resides in the virtuser_query plugin, which handles database-driven user lookups and maps users to email addresses. Successful exploitation enables threat actors with no privileges to inject and execute malicious SQL commands, steal data from Roundcube's database, and compromise email systems without requiring any user interaction. 

The Roundcube security team addressed this issue in May by releasing patches in versions 1.6.16 and 1.7.1, strongly recommending that administrators update their servers immediately. For those unable to upgrade right away, disabling or removing the virtuser_query plugin eliminates the attack vector and reduces exposure. Despite the availability of fixes, Shadowserver currently tracks over 523,000 Roundcube instances exposed on the Internet, though it remains unclear how many are honeypots or already patched against this flaw. 

This is not the first time Roundcube has been targeted by sophisticated threat actors. The Russian Winter Vivern (TA473) group exploited a cross-site scripting zero-day (CVE-2023-5631) against European government entities, while APT28 abused multiple Roundcube flaws to breach Ukrainian government email systems. More recently, in February 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) flagged two other Roundcube vulnerabilities as actively exploited, ordering federal agencies to secure their networks within three weeks. Since May 2022, CISA has tagged 11 Roundcube Webmail vulnerabilities as exploited in the wild, underscoring the platform's persistent appeal to cybercriminals and state-backed hackers. 

Organizations relying on Roundcube should prioritize patching to versions 1.6.16 or 1.7.1 without delay, as the window for safe operation has closed. Administrators who cannot upgrade immediately must disable the vulnerable virtuser_query plugin and monitor logs for suspicious database queries or unauthorized access attempts. Given the scale of exposed instances and the history of active exploitation, treating this flaw as a critical priority is essential to prevent data theft, credential harvesting, and broader compromise of email infrastructure.

GitLab Email Feature Exposes Critical Security Risk

 

GitLab’s “Email work item to this project” feature, intended to simplify issue creation, has been found to expose a serious security vulnerability that allows attackers to push code directly to the main branch and execute CI/CD pipelines. Security researchers at Aikido discovered that the private email addresses GitLab provides contain long-lived authentication tokens that grant far more access than users expect, effectively bypassing traditional security controls like IP restrictions. 

Modus operandi

When users click “Email work item to this project” in GitLab, they receive a unique email address containing a glimt- prefixed token that never expires. While GitLab’s interface suggests this address only creates issues within a specific project, the embedded token actually provides account-wide access across all projects the user can reach, both public and private. Attackers who obtain this email address can change the suffix from -issue@ to -merge-request@, attach a code patch, and submit it directly to any branch, including protected ones like main. If the patch modifies .gitlab-ci.yml, the attacker can execute arbitrary CI/CD jobs with the victim’s permissions, potentially exfiltrating secrets or deploying malicious code. 

One of the most concerning aspects of this vulnerability is its ability to circumvent IP allowlists and other network-based restrictions. Researchers tested this against private projects configured to accept connections from only a single IP address; while GitLab correctly blocked browser access and git clone commands from unauthorized IPs, it still accepted merge request emails and pushed commits to the main branch. This creates a dangerous blind spot for organizations that believe their IP restrictions provide comprehensive protection, when in reality the email pathway offers an unguarded backdoor into their repositories.

The vulnerability affects every GitLab.com account and all self-managed instances with incoming email enabled, with no option to disable the feature. GitLab has acknowledged the issue but classified it as intended behavior rather than a security bug, making only minor UI updates to clarify that the email addresses can create merge requests in addition to issues. However, these changes still don’t adequately communicate that the token reaches every project in the account, can push code to protected branches, and bypasses IP restrictions entirely. Researchers found over a dozen publicly exposed email addresses in open-source project documentation, many deliberately published by maintainers instructing users where to send bug reports. 

Mitigation strategies 

Organizations should immediately rotate their incoming email tokens via the personal access tokens page, though this invalidates all project addresses simultaneously. Teams should scan repositories and documentation for exposed glimt- tokens using secret detection tools, treating these addresses with the same caution as API keys or passwords. Additionally, security teams must recognize that IP allowlists alone don’t provide complete protection in GitLab, and should implement additional controls like requiring sender address verification and monitoring for unauthorized merge requests. Until GitLab implements more granular controls or allows feature disablement, proactive token rotation and vigilant secret scanning remain the primary defenses against this attack vector.