AcyMailing 11.1.2 Fixes Seven Front-End Security Flaws We Reported

Acyba released AcyMailing 11.1.2 today, 12 November 2026. It fixes seven flaws we found in the front end of the AcyMailing component for Joomla (com_acym) and reported privately in October. The worst is CVE-2026-120466, rated 8.8 High: an anonymous visitor who knew a subscriber’s email address could unsubscribe them from one list or from every list, without proving the address was theirs. Six of the seven are authorization bugs, where the component decides who may read or change something from a value the visitor controls, or skips the check altogether. The seventh is an open redirect. There is no remote code execution or SQL injection among them.

The Joomla CNA has published seven CVE records for the release. Six of them cover our findings and credit “Phil Taylor / mySites.guru”, and two of those six were also reported independently through the Ghent University VDP. One of our findings, the test-send branch of the online-view check, has no record of its own. 11.1.2 also fixes CVE-2026-118495, reported by other researchers and also rated 8.8 High, which let an anonymous visitor read a subscriber’s record and the secret key that goes with it.

Acyba publishes a security advisories page, with an RSS feed, covering advisories from January 2026 onward. It does not yet list the 11.1.2 advisories. Acyba is emailing its customers asking them to update, and credits “Phil Taylor / mySites.guru” for the reports. Jérémy at Acyba told us today that 11.1.2 “includes all the security fixes Gaëtan and you prepared”. The release has ordinary bug fixes in it too.

11.1.2 is the first AcyMailing version to use the security tag in its Joomla update XML, so Joomla 5.4.9 and later, and 6.1.4 and later, badge it as a security update. It does not yet include a changelogurl.

A site that lost its AcyMailing update site before 11.1.1 will not be offered 11.1.2 until the package is reinstalled, so check the installed version by hand as well as looking at the updates screen. That vanishing update site, fixed in 11.1.1, is why many AcyMailing sites reported themselves up to date when they were not.

TL;DR

Update every AcyMailing install to 11.1.2, then check the component reports that version. It fixes seven front-end flaws we reported, the worst being an anonymous forced unsubscribe (CVE-2026-120466, 8.8 High). It also fixes CVE-2026-118495 (8.8 High), reported by other researchers, which exposed each subscriber’s secret key. Every version up to and including 11.1.1 is affected. mySites.guru flags the affected range on connected Joomla sites through its vulnerability rules, so a site shows as needing this update even when its own Joomla updater has nothing to offer.

What AcyMailing 11.1.2 fixes

1. Anyone could unsubscribe any address they knew

The subscriber self-service model gives each subscriber a secret key, sent inside their own email links, so an unsubscribe link proves who is asking. One path did not apply it. The direct and ajax unsubscribe branch looked the subscriber up from the email address in the request and acted on it. The redirect branch of the same function does check ownership; the ajax branch skipped it.

The setting involved is “Allow subscriber data modifications without authentication”, on the Subscription tab of AcyMailing’s Configuration. It has three options: “No”, “Only their subscription” and “Yes”. A fresh install sets “Only their subscription”, which reads as the safe choice. In 11.1.1 the ownership check in unsubscribeDirectly() only runs when the option is “No”, so on the out-of-the-box setting anyone who knows an address can unsubscribe it.

Acyba’s first answer was that this is a configuration setting, not a vulnerability, and pointed to the option’s tooltip. That tooltip warns about “Yes”. It says nothing about “Only their subscription”, the default we tested. Acyba proposed making “No” the default, but defaults are written at install time with INSERT IGNORE, so a new default would not have reached sites that already have AcyMailing installed. They would have kept “Only their subscription” until someone changed it by hand.

We replied with the code, and the next day Acyba withdrew the configuration answer: “You’re right, and I was wrong to close this as a configuration issue.” It also went further than our report. Looking at the “No” branch, Acyba found that it only checked that someone had identified themselves and then acted on the address in the request, so any subscriber holding their own key, which is in every email AcyMailing sends, could still unsubscribe anyone else. A new default would not have fixed the flaw on any site, old or new.

One forged request is a nuisance, but the request is easy to repeat. There is no rate limit, the front-end captcha is off unless the site owner configures one, and the only bot filter rejects user agents containing “python”, “libwww-perl” or “googlebot”. A list of addresses and a curl loop can empty a site’s mailing list, and each successful request fires AcyMailing’s unsubscribe and notification emails from the site.

The damage is also hard to undo. The request deletes no rows: it sets the subscription row to unsubscribed and stamps a fresh unsubscribe date. The site owner then cannot tell a forged unsubscribe from a real one, so they cannot put people back without asking for consent again.

The right way to unsubscribe someone without an account is to email them a link that proves they control the address, the way AcyMailing’s own keyed links already do. That is the fix in 11.1.2. Ownership is now checked before anything is changed, on every branch and whatever the setting says: either a valid subscriber id and key, or a logged-in user acting on their own address. A request that cannot prove the address changes nothing, and the subscriber is emailed their own management link instead. The response is the same whether or not the address is on a list, which also stops the form being used to test whether an address is subscribed. Because the setting no longer controls this path, existing sites are protected by installing the update, with no configuration change. The one-click unsubscribe links in AcyMailing’s own emails include the key, so they keep working.

While fixing it, Acyba found a second route to the same flaw: the savechanges task reached the same unsubscribe code with the same missing check, and our reproduction would have worked against it unchanged. The same ownership check closes both.

Until 11.1.2 is installed, set “Allow subscriber data modifications without authentication” to “No” on every site. On 11.1.1 that is the only value that turns any ownership check on, and it blocks the anonymous request, though not a subscriber using their own key against someone else.

The CVE record lists every version from 1.0.0 to 11.1.1 as affected, on Joomla and on WordPress. It credits Phil Taylor / mySites.guru and K1nako / Ghent University VDP, so the same flaw was also reported independently through the Ghent University VDP.

2. Anyone could read a subscriber’s record and secret key

We did not find this one. The CVE record credits h0rus3c and K1nako / Ghent University VDP, and 11.1.2 fixes it in the same release as our seven.

According to the record, an unauthenticated attacker who knows a subscriber’s email address could read that subscriber’s record, including the per-subscriber secret key that authorises the subscription management links. Holding that key, the attacker could act as the subscriber on those endpoints, which includes triggering the GDPR data export and the GDPR account deletion on sites where those options are enabled. The record classes it as CWE-200 and lists AcyMailing 6.0.0 to 11.1.1 as affected, on Joomla and WordPress. The CISA assessment attached to the record puts exploitation at “none”.

This flaw and the forced unsubscribe above depend on each other. The forced-unsubscribe fix makes the subscriber key the proof of ownership, so a request has to present the right id and key before anything changes. A key that anyone could fetch with an email address proves nothing about who is asking. Both flaws had to be closed for the ownership check to mean anything, and 11.1.2 closes both.

3. A logged-in user could change anyone’s subscriptions

Two front-end tasks checked that the caller was a known subscriber, then acted on a separate subscriber id taken straight from the request. The identity check passed on the attacker’s own record while the action hit whoever they named. Any registered user who is or was a subscriber, which is common on a site with self-registration, could change other people’s list memberships.

The fix ties the identified subscriber to the id being acted on, and requires a CSRF token whenever the request does not include a subscriber id and key. A logged-in user with no id and key now resolves only to their own record.

4. Anyone could read campaigns a site had sent

AcyMailing has a web-archive view for campaigns, so a subscriber can open a newsletter in the browser. ArchiveController::view() loaded the archived copy by mail id and rendered it. The check that a campaign is published and public, canViewMailOnline(), only ran when there was no stored archive row.

An archive row is written for every standard campaign at send time, whatever its visibility. So a campaign that was sent and then unpublished, or sent only to a segment of the list, stayed readable at a guessable URL by someone with no account. Mail ids are sequential, which made the whole archive walkable. For a site that mails members-only offers, internal notices or anything segmented by customer type, that is the content of those mailings in the hands of anyone who counts upwards.

In 11.1.2 the visibility check runs on the archived path too, so an archived campaign is only shown to a visitor who would be allowed to see it.

5. Every list was listable, including hidden ones

A front-end entity-select endpoint, used to populate list pickers, applied its access filter only when a creator id was set. For an anonymous caller that id is zero, so the filter was skipped and every active standard list came back regardless of visibility or view level, with its name, description, owning account id and subscriber counts. No subscriber addresses are returned. The sibling endpoint for users has a guard that prevents the same bypass; the list endpoint did not. The WordPress build does not include the controller, and the CVE record says the WordPress plugin is not affected.

The endpoint now requires a session, and the list access filter is applied unconditionally outside the administrator, with an anonymous caller matching no lists.

6. A published key unlocked access-restricted modules

AcyMailing can render a Joomla module over ajax for its subscription widgets. ModuleloaderController::loadAjax() fetched any published site module by id and rendered it with no view-level check, so a module set to Registered or to a custom access level came back to a guest. The only condition was the security_key, and AcyMailing publishes that key in the site’s own page output, so anyone who can view the page has it.

11.1.2 checks the module’s access level against the visitor before rendering it.

7. The test-send view check trusted a user id

canViewMailOnline() is the visibility check behind CVE-2026-120470. It has a test_sent branch for mails that were sent as a test, and that branch granted access on the user id in the request alone. It did not validate the user_key, the secret that is supposed to prove the request comes from that user. In 11.1.2 the id is no longer enough and the key has to match.

No separate CVE record names this branch, so the score on the card is our own assessment. We confirmed it on Joomla.

8. The subscribe flow could send a visitor anywhere

The redirect after subscribing or unsubscribing took its target from the redirect and redirectunsub request parameters. A safeguard exists, acym_checkRedirect(), which compares the destination with an allowed-hosts list. When that list is empty, which it is out of the box, the function allowed any destination, so on a default install the safeguard did nothing. A crafted link that starts on the real site, with its real domain in the address, could end on an attacker’s page.

In 11.1.2 an empty allowed-hosts list no longer means every destination is allowed.

The CVE record credits Phil Taylor / mySites.guru and K1nako / Ghent University VDP.

Proving the report date

On 24 October 2026, while the fix was still unreleased, we posted the SHA-256 hash of a one-line statement about this report on social media and on our responsible disclosure page, without the statement itself. Now that 11.1.2 is out, this is the statement, word for word:

Its SHA-256 hash is ace00090fac39856ccd4b399c0915659cc367d7ea58b0ca258d223a051dacf56. To check it, hash the statement as a single line of UTF-8 with no trailing newline (427 bytes):

printf '%s' 'mySites.guru (Phil Taylor) privately reported three vulnerabilities in AcyMailing 11.1.1 for Joomla to Acyba on 2026-10-07, copying the Joomla Security Strike Team: anonymous subscription tampering (forced unsubscribe), a low-privilege cross-user subscription IDOR, and anonymous enumeration of mailing lists including invisible and access-restricted ones. Acyba confirmed all three by 2026-10-09 (HelpScout ticket 3475685068).' | shasum -a 256

The statement says three vulnerabilities because it describes the first report, sent on 7 October. The other four findings went to Acyba on 20 October.

Does this affect AcyMailing on WordPress?

AcyMailing is built for both Joomla and WordPress from shared code. We tested on Joomla only. The CVE records list the WordPress plugin as affected by five of the seven CVEs:

• CVE-2026-120466, the forced unsubscribe
• CVE-2026-118495, the readable subscriber record and key
• CVE-2026-120467, the cross-user subscription change
• CVE-2026-120470, the readable online version of a campaign
• CVE-2026-120469, the open redirect

The records for the list enumeration (CVE-2026-120468) and the module access-level bypass (CVE-2026-120471) say the WordPress plugin is not affected. If you run AcyMailing on WordPress, update it to 11.1.2 as well.

What mySites.guru does about it

mySites.guru records the installed version of every extension on every connected Joomla and WordPress site and compares it with its vulnerability rules. Every connected Joomla site below 11.1.2 is flagged on its dashboard and in its audit, using the installed version number, not the site’s own update data. That is why the flag still works on a site whose AcyMailing update site has been deleted: the check does not depend on Joomla reporting the update.

To act on it across a portfolio of client sites, the AcyMailing extension search lists every install grouped by version, and the mass updater pushes 11.1.2 to all of them at once. A site that lost its update site needs the package reinstalled first, because the one-click and automatic updates both start from the update Joomla reports.

How these were found

These came from a manual audit of the AcyMailing front-end controllers, with no scanner involved. Each finding was demonstrated on a local test install with a throwaway canary and then reversed, so the box was left as it started. We report this way because the extensions our customers run are the ones we most want to find holes in before someone else does.

The work is part of what a mySites.guru subscription pays for. If you look after more than a few Joomla or WordPress sites and would like to know which of them still run AcyMailing 11.1.1 or older, try mySites.guru and it will tell you.