Joomill Autolanguage 2.7.2 Fixes a Stored XSS Created by Translating an Article

TL;DR

Joomill released Autolanguage PRO 2.7.2 on 13 November 2026, with the free 2.7.2 out the same day. Its changelog has three Security entries. The one most worth acting on is a stored cross-site scripting (XSS) flaw: an author who is not allowed to post raw HTML could write a script tag as harmless escaped text, and the plugin’s translation of that article turned it into a working script tag, saved past Joomla’s text filters.

The other two fixes are a batch translation that did not check rights on each selected item, and a Gemini API key that PRO sent in the request URL. There is no CVE for any of them yet and the vendor page credits no reporter, so the scores here are our own assessment. The XSS scores slightly below the batch flaw because a victim has to open the translated item, but a script running in an administrator’s browser is the effect to act on first.

Autolanguage is a third-party Joomla extension by Jeroen Moolenschot of Joomill. These are flaws in the extension, and Joomla core is not affected.

What Autolanguage 2.7.2 Fixes

Autolanguage is a Joomla system plugin that translates content into a site’s other content languages and links the translations as associations. It translates when an item is saved and also offers batch translation. The free edition translates articles and categories through Google, Microsoft, OpenAI or Mistral. PRO adds DeepL, Anthropic, Gemini, DeepSeek and xAI, and translates menus, menu items, modules, tags, mail templates and YOOtheme content as well.

The Security section of the 2.7.2 changelog has three entries. The first column is the opening of each one in the vendor’s own words:

The rest of 2.7.2 is ordinary maintenance. Dictionary terms are no longer replaced inside links, image paths or attributes, and alt and title attributes in HTML are now translated. zh-TW, pt-BR and Serbian Latin are translated into the right variant, six of the AI services now retry a throttled request, and social links on the install screens have accessible names.

The Stored XSS in Autolanguage Translations

Joomla decides what an author may save with its text filters. An Author’s filter strips a script tag from an article. It leaves <script> alone, because that is text: the browser prints the characters and runs nothing. A tutorial that shows code to its readers is full of entities like that.

Autolanguage subscribes to Joomla’s onContentAfterSave event, so its work starts after the filter has finished. In 2.7.1 the order of operations was:

1. The author saves the article. Joomla’s text filter runs and keeps the escaped script text, correctly.
2. Autolanguage sends the saved text to the translation service, once for each other content language.
3. Each result comes back and is run through a full HTML entity decode. <script> becomes <script>.
4. The plugin stores each translation. Nothing sends it through the text filter again.

Step 3 was this call, which appears three times in TranslationService.php:

html_entity_decode($result, ENT_QUOTES | ENT_HTML5, 'UTF-8')

The vendor’s changelog describes the result: “Every translated result was run through a full HTML entity decode, so <script> that an article showed as text became a real script tag in every translation, written past Joomla’s text filters.”

So the filter checked the one version of the content that was safe, and the unsafe versions were created afterwards by code that writes to the database on its own authority. The script then runs for anyone who views a translated item. That includes visitors on the front end and administrators who open the translation in the backend, which is how a low-privilege account reaches a high-privilege session.

The same risk applies to any extension that translates content. Machine translation creates new content. A translated article is a second, third or fourth item that no human typed, and it never passes through the filter that guarded the original. Any step that changes markup after the filter has run, as an entity decode does, has to treat its own output as untrusted input.

Version 2.7.2 replaces the call with one that compares the result against the source:

HtmlText::decodeEntities($result, $source)

In the vendor’s words: “Only the entities a translation service adds are decoded now; an entity for <, >, & or " that the source itself carries stays as it is”. If the source held one of those four characters in entity form, the translation keeps it in entity form.

Autolanguage Batch Translation Skipped Per-Item Rights

Joomla lets a site limit a user to certain categories, or allow them to create items without editing existing ones. Autolanguage’s batch translation did not look that closely. The changelog says: “Rights on the component were enough to have the plugin overwrite translations, also for a user limited per category or allowed to create but not to edit.”

In practice a user confined to one category could select items elsewhere, run a batch translation and have the plugin replace the existing translations of those items. The content written is the translation service’s output, which is why we rate the effect as a limited loss of integrity.

Version 2.7.2 adds a BatchAccess class. Per the changelog, “The source item, the category a new translation goes into and every existing translation now need the edit rights Joomla’s own edit screen asks for; an item that fails is skipped and counted in a warning”. The class’s own docblock says it “Ships in both editions, because articles and categories are batch translated in FREE”, so this fix is not limited to PRO.

The Gemini API Key in the Request URL

In PRO 2.7.1 the Gemini API key was appended to the request URL as ?key=, both in GeminiTranslator.php and in GeminiModelsField.php, which loads the model list in the plugin’s settings. A web address is the part of a request that proxies and firewalls write to their logs, so the key was copied into every log on the route out of the server.

Version 2.7.2 sends it as an x-goog-api-key header. We rate this Low and have not scored it: a visitor cannot exploit it, and the exposure is to whoever can read those logs. The free edition has no Gemini support, so it is unaffected.

Which Autolanguage Versions Are Affected?

Every Autolanguage version below 2.7.2 that we checked has the full entity decode. It is in the free 2.0.0, 2.4.1 and 2.7.1 packages and in PRO 2.7.1, so the stored XSS goes back at least to 2.0.0. For the other two issues we can confirm 2.7.1, and the vendor does not state how far back they go.

This is how the Autolanguage sites in the mySites.guru database were spread across versions on release day:

About 80% of those sites run the PRO edition, so the Gemini change is relevant to most of them if Gemini is the service they chose.

What To Do on Each Autolanguage Site Now

1. Update to Autolanguage 2.7.2, free or PRO.
2. Open the translated items that automatic or batch translation created, and look for script tags or unexpected markup that is not in the source item. Start with items whose source was written by lower-privilege users. The update stops new cases, and it does not clean a translation that was already stored.
3. In Joomla, check Global Configuration > Text Filters, and make sure the Author and Registered groups are still on a filtered list.
4. On PRO with Gemini, rotate the Gemini API key if your traffic passes through a proxy or firewall that logs URLs.
5. Review which backend users can run batch translation.

How mySites.guru Flags Autolanguage

mySites.guru flags every connected Joomla site running the Autolanguage system plugin, free or PRO, below 2.7.2. mySites.guru did not find these flaws; Joomill fixed them in its own release.

Flagged sites appear in the vulnerable extension list, so one screen shows which sites still need the update. The mass updater then pushes extension updates across Joomla sites in one run. Every Autolanguage rule we hold is on the Autolanguage vulnerabilities page.

The same kind of hole, script from anyone allowed to write an article, turned up in two Regular Labs extensions:

Modules Anywhere 10.0.0 and Tabs & Accordions 3.2.0 Close Two Content Author Security HolesCVE-2026-100750 and CVE-2026-100751: Regular Labs fixed two High severity issues in Modules Anywhere 10.0.0 and Tabs & Accordions 3.2.0 for Joomla.Read the full post

For a site that has already been hacked, fix.mySites.guru patches it, audits it for backdoors and hands it back secure for a single fixed fee, usually the same day.