SURIQ
The same corner of one Craft CMS plugin has now produced two critical, unauthenticated flaws in about five weeks. On July 6, 2026, the maintainer of Formie, a widely used form builder for Craft CMS, published an advisory for CVE-2026-52889: a hidden form field could take a value straight from an incoming web request and hand it to Craft's template engine to run. Someone who never logs in can reach it just by loading a public form. The fix is Formie 3.1.27, and if you run this plugin it is today's work.
This is server-side template injection (SSTI): text a visitor controls gets evaluated as a template instead of being treated as plain data. Craft draws its pages with Twig, the template language behind the CMS, and Twig can reach application objects. So the advisory scopes the impact to the site's configuration and what its template environment exposes, ranging from leaking sensitive data, to changing application state, to full remote code execution on the server. The advisory rates it CVSS 9.8.
Which forms are actually exposed
Not every Formie form is at risk. The dangerous setup is a Hidden field whose default value is pulled from the incoming request. Formie lets a Hidden field seed its default from request context: the visitor's browser user-agent string, the referring page, the current URL, a value from the query string, or a cookie. Those are handy for tagging where a submission came from. The bug is that Formie assigned that request-supplied value to the field's default and then rendered it through Twig in Hidden::getFrontEndInputOptions() when the form was drawn. Anything an attacker can place in one of those request parts, including a header they fully control like the user-agent, reached the template engine.
Affected range: Formie 3.0.0-beta.1 through 3.1.26 on Craft 5. Fixed in 3.1.27, which now renders Twig only for the admin-authored Custom default and treats the request-derived defaults as plain strings. If none of your public forms use a Hidden field with one of those dynamic defaults, you are not in the exploitable path, but patch anyway: the safe version is one upgrade away, and manual audits of every form are error prone.
Same feature, second advisory in five weeks
Here is the part worth pausing on. This is not the first unauthenticated Twig injection in Formie's Hidden field. In late May 2026 the same maintainer shipped a fix for CVE-2026-45697, also rated 9.8, also an unauthenticated SSTI in a Hidden field, that time through the field's Custom default value. That one was patched in Formie 2.2.20 and 3.1.24. Roughly five weeks later, a follow-up advisory showed the request-derived defaults were still being evaluated as Twig.
| Advisory | What was evaluated as Twig | Fixed in |
|---|---|---|
| CVE-2026-45697 (late May 2026) | A Hidden field's Custom default value, submitted by the visitor | Formie 2.2.20 and 3.1.24 |
| CVE-2026-52889 (July 6, 2026) | A Hidden field's request-derived default: the user-agent, referrer, current URL, a query value, or a cookie | Formie 3.1.27 |
The two advisories together show a first fix that closed one input path, the Custom default, while a separate class of request-derived input into the same feature stayed evaluated as Twig until this second fix. If you patched in May and assumed the Hidden-field template problem was closed, it was not. The practical lesson for anyone running Formie is to treat every dynamic Hidden-field default as untrusted input, and not to read the May update as the end of it. Unauthenticated code-execution paths in CMS form plugins are a recurring theme this year, from the Joomla JCE takeover to a form-entries plugin on WordPress; a public form is attack surface by definition.
How to tell if someone has probed you
At the time of writing no public exploit code had surfaced and there is no report of exploitation in the wild, but the affected feature is trivial to reach and the outline is now public. If you want to look back before you patch, template-injection probes have a distinctive shape: template-expression syntax, the double-brace markers Twig uses, showing up in places that should never contain them, such as the user-agent header, the referrer, query-string values, or cookies, on requests that load a page carrying a Formie form. Legitimate traffic almost never puts template delimiters in a user-agent string. Pull your web-server access logs and any firewall or reverse-proxy logs and search those request fields for brace-template markers around your public form URLs.
In MITRE ATT&CK terms this is Exploit Public-Facing Application (T1190). The detection worth keeping after you patch is any template-expression syntax appearing in request headers or parameters against your Craft endpoints. That signal covers this whole class of bug, not just this one CVE.
What to do now
- Upgrade Formie to
3.1.27on every Craft 5 site you run. That is the single fix. - Inventory your public forms for Hidden fields set to a dynamic default drawn from the request (a header, the URL, a query value, or a cookie). Those are the exposed ones, and worth a look even after patching.
- If you cannot patch right away, change any such Hidden field to a static default so the attacker-controlled value never enters the template path.
- Search historical access and firewall logs for template-expression markers in the user-agent, referrer, query parameters, or cookies on form pages, to check whether anyone probed before you closed the gap.
Two critical bugs in one feature in five weeks is the signal. Formie is an otherwise normal, actively maintained plugin, and both flaws were patched quickly, so this is no reason to tear it out. It is a reason to watch any place where a form quietly turns request data into template input, and to keep your Craft update cadence measured in days, not months.