2026-08-01 · view entry permalink →
CVE-2026-65883 — Aimy Captcha-Less Form Guard for Joomla: the anti-spam token is deserialized before any check, and the XOR keystream ships in the same page (CVSS 9.8)
VulnCheck disclosed CVE-2026-65883 on 2026-07-30 in Aimy Captcha-Less Form Guard, a Joomla anti-spam plugin published by Aimy Extensions (Netzum Sorglos Software GmbH), affecting versions 18.0 through 20.0 and fixed in 20.1 (VulnCheck, 2026-07-30). The plugin's premise is that it needs no puzzle: instead of a challenge it plants a hidden field named clfgd in every protected form and validates it server-side on submit. The handler onCheckAnswer() base64-decodes that field, passes it through XorHelper::crypt() and hands the result to unserialize() before any other check — and, as VulnCheck puts it, "there is no signature, no allowed_classes, and no integrity check of any kind. The only thing between the request and unserialize() is a repeating-key XOR, and the plugin publishes a ciphertext for that keystream in every form it renders, which makes the keystream recoverable and the object forgeable" (VulnCheck, 2026-07-30). VulnCheck's structured severity block records CVSS 9.8 on AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, with CWE-502 deserialization of untrusted data leading to CWE-94 code injection (VulnCheck, 2026-07-30).
Two mechanics decide the blast radius. Reachability is total: "the captcha runs on public forms, and Joomla's JForm::validate() evaluates every field's rule independently, so the captcha rule fires even when every other field in the form is empty or invalid" (VulnCheck, 2026-07-30) — an attacker does not need to submit a plausible form, only to hit the endpoint. Code execution, by contrast, is conditional on the core version: the gadget VulnCheck's exploit uses is Joomla's own FormattedtextLogger, which "fires on Joomla 3.9 through 5.2.1; 5.2.2 hardened it so FormattedtextLogger::__wakeup throws before it can run", and the researcher notes that none of the published phpggc chains work as-is against a current 5.4 (VulnCheck, 2026-07-30). The important qualification is that patching the core does not remove the bug: VulnCheck is explicit that "the object injection and the captcha bypass live in the plugin and are present on every version. On a patched core the only missing piece is a working gadget, and any other extension or bundled library on the site can supply one, which puts RCE back on the table" (VulnCheck, 2026-07-30).
No in-the-wild exploitation is reported for this CVE. What justifies acting on it ahead of the routine cycle is the wave it sits in: VulnCheck records that the Joomla CNA published 52 CVEs in 2025 and 132 through July of 2026, and that three of this year's unauthenticated extension bugs — in the JCE editor, SP Page Builder and Page Builder CK, all CVSS 9.8 — "were exploited in the wild and added to both VulnCheck KEV and the CISA KEV" (VulnCheck, 2026-07-30). A single-request, no-credentials path to code execution in the same ecosystem, with full mechanics now published, is the profile that has been weaponised repeatedly in this wave. The working exploit itself is a module in the discloser's commercial exploit-intelligence product rather than a public proof-of-concept, so the barrier is the published mechanics, not a downloadable script. For Swiss and European municipal and public-sector estates, where Joomla is a common content-management choice, the exposure question is not whether the site is important but whether this plugin is installed.
Detection concepts, telemetry class first. In web-server access logs, the observable is a POST carrying the clfgd parameter to a form endpoint where the rest of the submission is empty or malformed — a shape that legitimate form traffic does not produce, because a real user submits a filled form and a real bot submitting garbage is what the plugin is supposed to reject rather than deserialize. The plugin writes its own rejection record (manipulated form: clfgd broken) when decoding fails, so a run of those log lines from one source is a tuning attempt in progress rather than routine spam. On the host, PHP-process telemetry is the post-exploitation anchor: the web-server user spawning a shell or writing a new PHP file under the web root, and file-creation events in writable Joomla directories outside a deployment window. Hardening: upgrade the plugin to 20.1; keeping Joomla core at 5.2.2 or later removes the specific published gadget but, per the advisory, does not remove the injection primitive itself.
Triage: exposure cannot be measured from the outside here, and that is the point worth carrying. VulnCheck notes that "the captcha only renders on the forms an administrator attached it to, never on a homepage, so the internet-wide scanners that index homepages under-report this one badly", and that "absence of hits in Shodan or Censys is a property of how those crawlers work here, not a measure of the install base" (VulnCheck, 2026-07-30). A clean external scan is not evidence of not being affected; the extension inventory is.
There is no signature, no allowed_classes, and no integrity check of any kind. The only thing between the request and unserialize() is a repeating-key XOR, and the plugin publishes a ciphertext for that keystream in every form it renders, which makes the keystream recoverable and the object forgeable.
Reachability is unauthenticated: the captcha runs on public forms, and Joomla's JForm::validate() evaluates every field's rule independently, so the captcha rule fires even when every other field in the form is empty or invalid.
One footnote on measuring exposure: the captcha only renders on the forms an administrator attached it to, never on a homepage, so the internet-wide scanners that index homepages under-report this one badly.
Builds on: 2026-07-31/balbooa-gridbox-cve-2026-65884-anon-admin-registration-rce · 2026-07-26/joomla-gridbox-cookie-forged-super-user-auth-bypass-wave