A missing AcyMailing update site can prevent Joomla administrators from seeing an available security update. This operational issue matters because AcyMailing Enterprise versions 6.0.0 through 11.0.5 are affected by two unauthenticated vulnerabilities fixed in version 11.1.0 or later.
If AcyMailing does not appear in Joomla’s update checks, do not assume the installed version is current. Confirm the installed version and its update-site configuration, then restore a reliable update path before a routine maintenance task leaves a serious extension update unseen.
Why a missing update site matters for Joomla extension vulnerabilities
Joomla’s update system depends on update sites: registered locations that tell the CMS where to look for newer versions of installed extensions. When an extension’s update site is absent, disabled or otherwise unavailable, Joomla may have no source from which to discover that extension’s releases. The administrator can therefore receive a clean update screen while still running an older version.
That is an operational risk rather than a vulnerability in Joomla’s CVE records. It becomes particularly significant when a vendor has released a security fix. In this case, the official CVE records identify two unauthenticated issues affecting AcyMailing Enterprise for Joomla versions 6.0.0 through 11.0.5. Both are addressed in AcyMailing 11.1.0 or later.
The practical lesson is broader than one extension: a functioning Joomla update process requires more than clicking “Check for Updates.” Administrators also need to verify that important third-party extensions retain their update-site registrations and can report available releases.
The confirmed AcyMailing security issues
The following information is based on the published records for CVE-2026-94131 and CVE-2026-94132. The affected range and recommended version apply to AcyMailing Enterprise: versions 6.0.0 through 11.0.5 are affected, while 11.1.0 or later is the recommended update target.
| Extension | CVE | Authentication | Affected versions | Recommended version | CVSS 4.0 | CISA KEV status |
|---|---|---|---|---|---|---|
| AcyMailing Enterprise for Joomla | CVE-2026-94131 | None required | 6.0.0 through 11.0.5 | 11.1.0 or later | 8.3 High | Not listed |
| AcyMailing Enterprise for Joomla | CVE-2026-94132 | None required | 6.0.0 through 11.0.5 | 11.1.0 or later | 9.5 Critical | Not listed |
CVE-2026-94131: arbitrary file deletion
CVE-2026-94131 is an unauthenticated arbitrary file deletion vulnerability with a CVSS 4.0 score of 8.3 (High). The record describes a condition in which a subscriber can store a file path in a file-type custom field and cause deletion when that field is cleared. The impact can extend beyond the intended upload area and may include critical files such as configuration.php.
For an unpatched site, the immediate defensive priorities are to update, ensure backups are available, and verify that critical configuration files remain present and intact after maintenance.
CVE-2026-94132: mailbox action remote code execution
CVE-2026-94132 is an unauthenticated remote code execution issue in the AcyMailing Enterprise mailbox action feature, with a CVSS 4.0 score of 9.5 (Critical). Insufficient checks on MIME parts in incoming email can allow an attacker who can send mail to a monitored mailbox to place a PHP file in the web root and execute code.
Until the extension is updated, administrators should disable or tightly restrict the mailbox action feature where feasible, especially when a monitored mailbox can receive messages from untrusted senders. After patching, review the webroot and relevant server logs for unexpected PHP files or anomalous activity.
What Joomla Rebuild can change
Joomla’s Update Sites Rebuild function is intended to reconstruct update-site entries from extension manifests. It is useful in the right circumstances, but it should not be treated as a harmless reset on a production system.
The operational concern reported for AcyMailing is that an update-site entry that exists only in the database, rather than being declared in an extension manifest, can be removed during a rebuild. If that happens, AcyMailing may remain installed and functional, but Joomla can no longer use that missing entry to discover new AcyMailing releases. The result can be delayed or hidden security updates.
This behaviour is not a separate CVE-tracked vulnerability, and it is not covered by CVE-2026-94131 or CVE-2026-94132. It is a configuration and maintenance problem with security consequences: an unavailable update channel can leave an administrator unaware that a remedial release exists.
Do not use Rebuild solely to troubleshoot a missing third-party update notification unless you understand which update-site records will be reconstructed and how you will restore any that disappear. Before using it on a site running AcyMailing, record the existing Update Sites list and ensure you have a tested backup.
How to check and restore the AcyMailing update path
Start with a controlled verification rather than a guess based on the Joomla update screen. The goal is to establish three facts: which AcyMailing version is installed, whether its update site exists and is enabled, and whether Joomla can discover the current release.
- Record the installed version. In Joomla administration, locate AcyMailing in the extension management area and confirm its version. Treat any version from 6.0.0 through 11.0.5 as requiring an urgent plan to move to 11.1.0 or later.
- Inspect Update Sites. Open Joomla’s Extension Manager and review Update Sites. Look for the AcyMailing entry and confirm that it is enabled. A missing entry is different from an entry that is present but temporarily unable to contact its source.
- Preserve evidence before changing settings. Note the current extension version, the update-site state, and recent maintenance actions. This record is useful when managing several client sites or escalating a support request.
- Restore the extension from a trusted package when necessary. If the AcyMailing update site is absent, reinstalling AcyMailing from a trusted vendor package is a practical way to restore the extension’s registered update configuration. Back up first and follow the vendor’s current installation guidance.
- Run an update check again. After restoring the update site, refresh the update information and confirm that Joomla can see the applicable release. Then update to 11.1.0 or later.
- Validate after the update. Confirm normal mailing functions, inspect critical files including
configuration.php, and review webroot directories and logs for unexpected PHP files if the mailbox action feature was enabled before patching.
Reinstallation is not a substitute for incident investigation if there are signs of unauthorised changes. In that situation, preserve relevant logs and follow the organisation’s incident-response process while completing the update.
Severity, NVD status and exploitation are different signals
The two scores in this article are CVSS version 4.0 scores. CVSS expresses the technical severity of a vulnerability under the scoring model; it does not, by itself, confirm that the vulnerability has been exploited against real sites. CVSS 4.0 scores should not be converted into, or presented as, CVSS 3.1 scores.
At the time of writing, the NVD entries for CVE-2026-94131 and CVE-2026-94132 are marked “Awaiting Analysis”. CVSS 4.0 metrics are present, but that status means full NVD analysis is not yet complete and may change as NVD finishes its review.
Neither CVE appears in the CISA Known Exploited Vulnerabilities catalog at the time of writing. The authoritative records reviewed do not confirm exploitation in the wild. That absence does not reduce the need to patch: both vulnerabilities are unauthenticated, the affected range is known, and a fixed version is available. It does mean administrators should avoid claims that exploitation or ransomware use has been confirmed when the available authoritative evidence does not establish either claim.
A publisher has reported the existence of a public proof of concept for CVE-2026-94132, but the CVE and NVD records do not reference it and the authoritative data used here does not independently verify that claim. It should not be used as a basis for changing the confirmed risk assessment or for assuming observed exploitation.
Prioritised remediation checklist
- Priority 1 — identify exposure: inventory all Joomla sites using AcyMailing Enterprise and record the installed version.
- Priority 2 — patch: update every affected installation from versions 6.0.0 through 11.0.5 to AcyMailing 11.1.0 or later as soon as operationally possible.
- Priority 3 — reduce interim risk: on unpatched sites, temporarily disable or restrict the mailbox action feature, particularly for mailboxes that accept messages from untrusted senders.
- Priority 4 — restore update visibility: confirm the AcyMailing update site is present and enabled in Joomla. If it is missing, restore it by reinstalling from a trusted package, then verify that Joomla can discover current updates.
- Priority 5 — protect critical files: maintain recoverable backups of
configuration.phpand other critical files, and verify file integrity after updating. - Priority 6 — review the system: inspect relevant logs and webroot directories for unexpected PHP files, especially where the mailbox action feature was active before the update.
- Priority 7 — improve maintenance controls: document update-site changes, avoid unplanned Rebuild operations, and monitor the AcyMailing vendor site and Joomla security communications for revised guidance.
For agencies and freelancers, make update-site validation part of recurring maintenance. A version inventory alone is not enough if the site has lost the mechanism that reports new versions.
Preventing a repeat
The durable fix is not only to patch this release; it is to make third-party update discovery observable. Include update-site checks in maintenance runbooks, especially after extension reinstallations, migrations, database repairs or use of Joomla maintenance tools. A simple before-and-after record of enabled update sites can quickly identify an extension that has become disconnected from its update source.
Extension developers can help by ensuring their update-site declarations are represented in extension manifests so that maintenance operations can reconstruct them consistently. Site owners should avoid manually editing extension update metadata unless directed by trusted vendor documentation or qualified support.
The original operational report that brought attention to the missing update-site scenario is available as a publisher report on the AcyMailing update-site issue. Its operational observations should be considered alongside, not instead of, the CVE and NVD records used for the confirmed vulnerability details.
For affected AcyMailing Enterprise sites, the next step is straightforward: restore visibility of updates, install 11.1.0 or later, and validate the result. Doing so addresses the known affected versions while strengthening the update process that helps prevent future security fixes from being missed.
Add comment