SURIQ
A newly published flaw in Roundcube Webmail, one of the most widely deployed open-source webmail clients on shared hosting and self-run mail servers, gives an ordinary logged-in user a path to run operating-system commands on the server behind it. CVE-2026-74997 carries a CVSS score of 8.8 and was assigned its number on August 17, more than a week after Roundcube shipped the fix. The catch, and the part most of the early coverage skipped, is that it only bites a specific configuration. Whether you need to move fast depends entirely on how your spam handling is set up.
Which Roundcube installs are actually exposed
The vulnerability lives in the markasjunk plugin, the component that lets a user flag a message as spam and, optionally, feed that decision to an external spam filter for training. That training step is where the problem sits, and it is off by default. An install is exposed only when all three of these are true:
- The markasjunk plugin is enabled in your plugin list.
- Its learning driver is set to
cmd_learn(the driver that shells out to an external command), rather than the default. - The configured learn command contains the
%iplaceholder, which the plugin fills in with the user's identity email address.
Most Roundcube deployments never turn on that command-based training path, so they are not affected by this specific bug. Administrators who wired markasjunk to a local sa-learn or an equivalent tool through cmd_learn are the ones who need to act, and they need to act today. If you are not sure which describes you, the config check in the last section settles it in under a minute.
How a spam button becomes a command prompt
The mechanism is a textbook CWE-78 operating-system command injection, and it is worth understanding because the same shape recurs across many products. When a user marks mail as junk, the plugin builds the training command by substituting the %i placeholder with that user's identity email. Per the advisory published by SSD Secure Disclosure, the substitution is a plain string replacement with no shell-escaping around the email value. Because a user can set their own identity email in Roundcube's settings, they control that value, and anything they slip into it that a shell treats as syntax is executed rather than passed as text.
That is why the privilege bar is so low. The severity vector reads network-reachable, low attack complexity, no user interaction, and only low privileges needed. In practice the attacker is any account that can log in, edit an identity, and click the junk button. No administrator role is involved. On a shared mail host that serves many mailboxes, that is a wide door: one compromised or hostile low-value account reaches code execution on the box that holds everyone else's mail.
| Roundcube branch | Affected versions | Fixed in |
|---|---|---|
| 1.6 LTS | 1.6.0 through 1.6.17 | 1.6.18 |
| 1.7 stable | 1.7.0 through 1.7.2 | 1.7.3 |
A researcher credited as nept1337 reported the flaw, and Roundcube's own release notes list it as a fix for command execution via the markasjunk cmd_learn driver. SSD's writeup includes technical detail and a conceptual example; there is no report of exploitation in the wild at the time of writing, and the CVE is not on CISA's Known Exploited Vulnerabilities list. That is the good news. The bad news is that the fix has been public since August 9, which means the diff that shows exactly what changed has been public for just as long.
Update to 1.6.18 or 1.7.3, then check two things
Patching is the whole fix. Move any 1.6.x install to 1.6.18 and any 1.7.x install to 1.7.3. This is worth doing even if you never touched markasjunk, because CVE-2026-74997 was one of eleven flaws closed in the same August 9 release. The batch also fixed an IMAP command injection, several server-side request forgery bypasses, an LDAP filter injection, a Sieve filter-rule script injection, and a stored cross-site scripting bug in the address book. Any self-hosted Roundcube older than these releases is behind on more than this one issue, so treat the upgrade as non-optional regardless of your spam configuration. If you run Roundcube through a control panel, the same reasoning applies to the panel's own mail stack; we made the point recently about the cPanel and WHM security release for Exim.
Once you have patched, do two quick checks. First, confirm your real exposure: look at your Roundcube config for a line setting markasjunk_learning_driver to cmd_learn and a markasjunk_spam_cmd or markasjunk_ham_cmd value containing %i. If those are absent, this specific flaw never applied to you. Second, if they were present while you ran an affected version, hunt for abuse: review your web server and PHP error logs for the window before you patched, look for identity email addresses on accounts that contain shell metacharacters rather than a normal address, and look on the mail host for unexpected child processes spawned by the webmail worker around the times users marked mail as junk. Those are the traces the trigger would leave. If you find them, treat the host as potentially compromised, rotate credentials and secrets reachable from it, and review what that mailbox could touch.
The pattern worth remembering
The interesting thing here is not that a webmail client had a bug. It is where the bug was: in the seam between a user-controlled value and a shell command, joined by a placeholder and no escaping. Roundcube's fix wraps that value so the shell can no longer read it as syntax. The same seam exists in any feature that folds user input into a command line through templating, from spam training to editor and tooling integrations that shell out to hosting panels that run helper binaries, as we saw with the Control Web Panel command-execution flaw. When you audit your own stack, the question to carry away from this one is simple: where does a value a user can set end up on a command line, and is it escaped before it gets there?