Critical RCE in GUARDIANWALL MailSuite Confirmed Under Active Attack — 4,000 Japanese Firms Affected

A critical-severity vulnerability (CVSS score 9.8) has been disclosed in the Japanese enterprise email security product GUARDIANWALL MailSuite. According to a JPCERT/CC advisory, sending a single crafted request from the outside is enough to execute arbitrary code on the server without any login.

The product is deployed to prevent email misdirection and data leakage. According to the vendor, over 4,000 organizations and 5.8 million users in Japan rely on it. National research institutes, telecommunications carriers, and foundations are among them — organizations where email sits at the center of daily operations. And the developer, Canon IT Solutions, has confirmed that attacks exploiting this vulnerability are already being observed in the wild.

The official disclosure was published on May 13, 2026. As of this writing, eight days have passed. We are publishing this piece now because cases keep surfacing where internal IT administrators still cannot answer the question, "Are we affected, yes or no?" This article reorganizes the available information and lays out, in order, what your environment can act on today.

What is happening

The flaw lives inside an internal command of GUARDIANWALL MailSuite called pop3wallpasswd. It is a program tied to mail-receiving logic and is invoked through the product's web service. Sending data longer than the program expects causes processing to overflow — what is technically known as a stack-based buffer overflow.

An attacker sends one crafted HTTP request to the server. That alone is enough to run a program of the attacker's choice on the server, in place of any command an administrator would normally type. No login screen, no password, no user interaction.

The identifier is CVE-2026-32661. The CVSS score is 9.8 on v3 and 9.3 on v4. Anything above 9 out of 10 is classified as "Critical" — the level at which public agencies tell organizations to prioritize remediation. Japan's IPA (Information-technology Promotion Agency) issued its own alert on May 13.

The on-premises edition is the one at risk

GUARDIANWALL is offered in two forms: an on-premises edition deployed on a company's own servers, and a cloud-hosted edition called Mail Security Cloud. The blast radius differs between the two.

Every release of the on-premises edition from Ver 1.4.00 through Ver 2.4.26 is affected. Because that range spans many years of releases, it is more realistic to assume any on-premises deployment running inside your network needs some form of action. The cloud edition (GUARDIANWALL Mail Security Cloud) was patched during scheduled maintenance on April 30, 2026, according to the operator. Cloud customers do not need to take additional steps.

Identifying your edition and what to do next

Start by figuring out which edition you are running. The lookup table below covers the cases.

If you are not sure which edition you have, the fastest path is to check the version number from the GUARDIANWALL admin console. When ownership is split across several people inside your company, asking the contract owner (not just the operator) whether you signed up for the cloud or the on-premises edition will often save time. Version 1.x and Version 2.x cover several years of releases, so environments that have not been touched in a long time are more likely to fall into the affected range.

If you are on the on-premises edition, the top-priority step is to apply the patch distributed by Canon IT Solutions. The vendor sent individual notifications to affected customers on May 1 and May 4. Searching your inbox for "Canon IT Solutions" often surfaces an earlier support email. If nothing has arrived, contacting your existing support window directly is the first move.

When patching cannot happen immediately — for example because a maintenance window is hours away, or because no staging environment is in place — the vendor offers a temporary workaround that stops the admin process. On the server, run /etc/init.d/grdn-wgw-work stop to halt it and /etc/init.d/grdn-wgw-work start to bring it back up. The vendor itself notes that this stop has a heavy operational impact, since it disables the admin interface. Treat it strictly as a bridge until the patch is applied.

The attacks are already underway

When critical flaws of this class are disclosed, vendors usually note that "no exploitation has been observed yet." This time is the opposite. As Security NEXT's reporting repeatedly emphasizes, Canon IT Solutions states plainly that "attacks exploiting this vulnerability have already been confirmed."

Neither the attacker's identity nor the names of victim organizations have been published. That said, when a mail product becomes the entry point, the damage rarely stops at intercepted messages — there is a long track record of mail servers being used as a foothold for lateral movement into other servers on the internal network. Because GUARDIANWALL inspects message contents to make routing decisions, business email bodies, attachments, and recipient lists pass through it, even if only briefly. When a piece of infrastructure that sits at this "checkpoint" position is breached, the impact does not stay scoped to the device itself.

The technical classification is CWE-121, a stack-based buffer overflow. The trigger lives in the pop3wallpasswd command running under the grdnwww user. The class of bug itself is well-trodden ground. What turns this old pattern into a usable attack today is that the entry point is reachable from outside without authentication.

What to do while waiting for the patch window

Patching remains the top priority. In environments where the patch cannot be applied immediately, it is worth running preparation work in parallel so signs of compromise are not missed.

First, preserve access logs for the GUARDIANWALL server's web service. The attack path is a web service request, so the breadcrumbs you will want during an incident review are there. Second, extend the retention window for mail send/receive logs. If attacks are being observed in the wild, traces may already exist on your network, and you will need them later to trace back the time of first impact. Inbound network traffic to the server — particularly access outside business hours, or reachability from overseas IPs — is also worth a look while you are at it.

If there is any suspicion that you have already been hit, it is worth involving JPCERT/CC or an external security firm under contract early, rather than trying to fully scope it in-house. When active exploitation is in progress, time spent trying to clarify the situation internally is time during which the blast radius keeps growing.

Reading the official advisory and the vendor's response

Canon IT Solutions's support information page shows the public notice was posted at 14:05 JST on May 13, 2026. Before that, on May 1 and May 4, individual notifications were sent to contracted customers. Sending notice to affected customers ahead of the public disclosure is a pattern seen with high-impact flaws.

The advisory itself does not publish specific fixed-version numbers on the page. Contracted customers receive patches through their dedicated support channel. This is a common distribution model for enterprise products — it avoids handing the public a fix that attackers can reverse-engineer. The flip side is that systems with no active connection to the support window can stay un-patched indefinitely, because the patch never makes it inside.

If your support contract has lapsed, or if no one in your company has corresponded with the vendor in a long time, restoring that connection turns out to be the shortest path to remediation in practice.

For mid-sized firms and one-person IT shops

GUARDIANWALL is an enterprise product, but pricing and feature set put it inside organizations that do not necessarily have full-time IT administrators. Mid-sized companies where the IT role is shared with other duties, local governments, and research institutes are among the customers. In environments like that — "no dedicated IT person," or "only one" — incident response of this size lands outside whatever capacity was planned for.

A practical first step is to put on a single sheet "who is the contracting party for GUARDIANWALL, and who can physically touch the server." That alone makes the next round of decisions go faster. If no such person exists internally, the maintenance contractor often also serves as the contact for security operations, and asking them "what is your status on CVE-2026-32661?" is the fastest opener. Quoting the CVE number speeds the contractor's lookup noticeably.

The patch application itself, depending on the product, takes anywhere from tens of minutes to a few hours. The time-consuming parts are confirmation, talking to the support window, and post-patch verification. Planning the work for outside business hours — evening or weekend windows — generally produces a shorter total outage than trying to squeeze it into the workday.

Summary, and what to watch from here

The GUARDIANWALL MailSuite vulnerability combines three conditions: maximum severity classification, unauthenticated remote exploitation, and active observed attacks. As ScanNetSecurity also notes, the affected range covers on-premises Ver 1.4.00 through 2.4.26, and the SaaS edition was already fixed on April 30. The order of operations is to identify your edition, contact the support window to receive the patch, and apply the patch with operational impact in mind.

When email stops, business stops. That is exactly why mail security products end up being hard to patch and easy to leave alone. This vulnerability is designed, structurally, to target that neglect. Asking inside your company "when did anyone last touch the mail infrastructure?" is, even at this point, not too late as a starting point.

Finally, the vendor and related public agencies may publish additional information going forward. Bookmarking the JVN entry and the Canon IT Solutions support page makes follow-up easier.

References

• ▸ JVN#35567473 - GUARDIANWALL MailSuite vulnerable to stack-based buffer overflow (May 13, 2026)
• ▸ JPCERT/CC - Advisory on stack-based buffer overflow in GUARDIANWALL MailSuite (May 13, 2026)
• ▸ IPA - Alert on the stack-based buffer overflow in GUARDIANWALL MailSuite (May 13, 2026)
• ▸ Canon IT Solutions - Customer notice on GUARDIANWALL MailSuite vulnerability (May 13, 2026)
• ▸ Security NEXT - Critical flaw in GUARDIANWALL MailSuite — exploitation already observed (May 13, 2026)
• ▸ INTERNET Watch - Critical vulnerability in GUARDIANWALL MailSuite, apply the patch; cloud version already fixed (May 13, 2026)
• ▸ ScanNetSecurity - Stack-based buffer overflow vulnerability in GUARDIANWALL MailSuite (May 18, 2026)
• ▸ Innovatopia - GUARDIANWALL MailSuite hit by critical vulnerability, exploitation confirmed (May 2026)
• ▸ Canon MJ Group - GUARDIANWALL product line