If you received an email from me pointing you to this page, it is because your website appears to be running a release of powermail (the TYPO3 form extension by in2code, Composer package in2code/powermail, which lives in your files under typo3conf/ext/powermail/ or, on a Composer installation, vendor/in2code/powermail/) that falls within the affected range of a known security issue. This page explains what the issue is, how to work out whether it applies to your site, which release to update to, and how to check whether anyone has already used it against you.

Before anything else, the most important fact about this notice: a release in the affected range does not by itself mean your site is exposed. The issue below only comes into play on forms that have a field flagged as the sender’s name, and I cannot see how your forms are configured from outside:

  • The issue only reaches a powermail form that has at least one field with the checkbox “This field contains the Name of the sender” ticked (on the field’s Extended tab in the TYPO3 backend). If none of your forms use that flag, this does not affect you, even on an affected release.
  • That said, the flag is common. The form wizard’s standard Name field usually sets it, and the vendor’s own advisory calls the configuration “common and default-adjacent”. So please do check rather than assume.

I can read your powermail release from a public file, but I cannot read your form settings, so this notice is a precautionary heads-up rather than a confirmed finding about your site.

The issue is CVE-2026-77136 (TYPO3 advisory TYPO3-EXT-SA-2026-022), an unauthenticated server-side template injection in the extension’s mail handling. It affects every powermail release before 10.9.3, every 11.x and 12.x release before 12.6.1, and every 13.x release before 13.2.1. It is fixed in 10.9.3, 12.6.1 and 13.2.1, all released on 25 August 2026, one for each TYPO3 line. There is no release old enough to be unaffected: the weakness is part of the extension’s original design, not something that arrived in a later version.

A word on urgency, because this is a conditional notice. If none of your forms has a field flagged as the sender’s name, updating is ordinary maintenance. If one of them does, please treat the update as a priority: the vendor’s advisory reports that this issue is being actively exploited, and in that configuration a visitor with no account at all can make your server evaluate template code of their choosing, which can disclose your configuration, environment variables and source code and, depending on the setup, lead to remote code execution.

This is an extension flaw, not a TYPO3 core flaw. A fully up-to-date TYPO3 does not protect you if the powermail extension itself is on an affected release.

Is this message legitimate?

Yes. This is a good-faith, responsible-disclosure notice from an independent security researcher. I am not asking you for money, passwords, or access to your site, and I have not attempted to break into it, submit any of your forms, or send anything to it.

All I did was look at publicly visible files that your website serves to every visitor (the same way your homepage is public) and note the release that the extension’s own assets identify. I specifically did not submit a form, did not send any template syntax anywhere, and did not go near the extension’s mail handling. Nothing about this check touches your data, your backend, or any private part of your site (more detail under What I did and did not do below).

If you would like to verify who I am, see the contact details at the bottom of this page and the About page.

Why this matters

Powermail builds the contact and enquiry forms on a great many TYPO3 sites. When a visitor submits a form, the extension sends a mail to the site’s configured receiver, and it fills in the sender’s name on that mail from whichever form fields the editor has flagged as containing the sender’s name.

Powermail lets editors write small pieces of TYPO3’s Fluid template language into certain mail settings, for example so a subject line can read “Message from {firstname}”. That is a deliberate feature for values an editor typed. In affected releases, the sender’s name assembled from the visitor’s own input was handed to the same template engine, as if an editor had written it. So a visitor could type Fluid syntax into the name field of a public form, and the server would evaluate it while building the receiver mail.

Two things follow from that, and they pull in opposite directions. The first is that this only matters where a form field actually carries the sender-name flag; a site whose forms use no such field is not reachable through this issue. The second is that where the flag is set, no account, no password, and no cooperation from anyone is required: the form is open to the public by design, and the only thing the attacker needs to do is submit it. The vendor rates the issue Critical (a CVSS 4.0 score of 9.5), and its advisory says it is being actively exploited.

I am describing this at the level a site owner needs in order to act, and no further. I am not publishing the details that would let someone reproduce it, and I would ask you not to try it against your own site or anyone else’s. Checking your form fields and your release, as described below, tells you everything you need to decide what to do.

If my email cited this issue, it means the release your site’s assets identify falls within the affected range. I did not test whether your particular site is exploitable, and I cannot see how your forms are built. All I observed is the release.

Am I affected?

Two questions decide it, in this order.

First: does any form field carry the sender-name flag?

This is the deciding question, and only you can answer it. Checking your own forms is entirely safe and is the whole point of this page.

  1. Log in to the TYPO3 backend and open the page (or the folder) that holds your powermail forms. Each form is a record with one or more pages, and each page holds the fields.
  2. Open each field record and look at its Extended tab for the checkbox “This field contains the Name of the sender”. It is most often ticked on the field where visitors type their name.
  3. If no field on any of your forms has that checkbox ticked, this issue does not reach your site, even on an affected release, though updating is still worth doing as ordinary maintenance.
  4. If any field has it ticked, the issue applies to you and you should update promptly (see How to update). If you cannot update right away, untick that checkbox on every field that has it: this is the vendor’s own recommended mitigation and it closes the issue on its own. The cost is that the sender’s name will no longer be filled in on the mails the form sends, until you update and tick it again.

Please do not try to reproduce the problem against your own site or anyone else’s; you do not need to in order to answer the question above.

Second: which release are you running?

You do not have to take my word for it. Note that there is no public version file for a TYPO3 extension the way there is for, say, a WordPress plugin, so the reliable reads are all from inside your installation:

From the TYPO3 backend (authoritative): go to Admin Tools then Extensions. The list of installed extensions shows the release of each one; find powermail. (On a Composer-based installation the list is read-only, but it still shows the installed release.)

From the command line, on a Composer installation: run composer show in2code/powermail in your project directory. The versions line is the installed release.

From the files: open ext_emconf.php inside the extension folder (typo3conf/ext/powermail/ on a classic installation, vendor/in2code/powermail/ on a Composer one) and look for the 'version' entry near the top.

Then apply this rule, noting that versions compare numerically, not alphabetically (10.9.2 is newer than 10.8.2, and 13.2.1 is newer than 13.2.0):

  • 13.0.0 through 13.2.0: potentially affected, subject to the flag question above. Update to 13.2.1 or later.
  • 11.0.0 through 12.6.0: potentially affected, subject to the flag question above. Update to 12.6.1 or later. This includes every 11.x release: there is no separate 11.x fix, and 12.6.1 runs on the same TYPO3 versions (12.2 to 12.5) as 11.x did, so it is a straight extension update with no TYPO3 upgrade needed.
  • 10.9.2 and everything older: potentially affected, subject to the flag question above. If you are on 9.x or 10.x (TYPO3 11.5), update to 10.9.3 or later. If you are on 7.x or 8.x (TYPO3 8.7 through 10.4), see the next paragraph.
  • 13.2.1, 12.6.1 or 10.9.3 and newer within their line: already fixed as far as this issue is concerned.

If you are on powermail 7.x or 8.x, there is no fixed release that runs on your TYPO3 version: 10.9.3 requires TYPO3 11.5. For those sites the vendor’s instruction is the mitigation above, untick “This field contains the Name of the sender” on every field that has it, and to plan a TYPO3 upgrade to a supported line, where a fixed powermail release is available. The TYPO3 versions those generations run on are themselves long out of support, which is a second reason to plan that move.

One check that does not work, so please do not rely on it. If you look at your page source you will see the extension’s assets with a long number attached, for example .../JavaScript/Powermail/Form.min.js?1785752971 (or embedded in the filename as Form.min.1785752971.js). That number is a file timestamp that TYPO3 appends for cache-busting, not a version, and you cannot read a release off it by eye. It happens to be what my check used, in a way I explain below, but the reads above are the ones to trust.

How to update

The fixed releases are published on the TYPO3 Extension Repository (TER), on Packagist, and on GitHub, so this is a normal extension update. Back up first, then update through the mechanism that matches how your site was installed:

  1. Back up your site (files and database) before making changes. Most hosting providers offer one-click backups.
  2. Composer installation (most sites on TYPO3 12 and 13, and many on 11): in your project directory run the requirement update for your line, for example composer require "in2code/powermail:^13.2.1" on TYPO3 13, "in2code/powermail:^12.6.1" on TYPO3 12, or "in2code/powermail:^10.9.3" on TYPO3 11.5. Then run your usual post-update steps (vendor/bin/typo3 extension:setup on TYPO3 12 and 13, or the equivalent your deployment uses) and flush the caches.
  3. Classic (non-Composer) installation: in the TYPO3 backend go to Admin Tools then Extensions, switch the dropdown to Get Extensions, search for powermail, and update it to the fixed release for your line. If your site cannot reach TER, the vendor’s advisory links the release archives directly (see References); upload the archive through Extensions then the upload button. Flush the caches afterwards.
  4. After updating, confirm the new release (13.2.1, 12.6.1 or 10.9.3, whichever matches your line) using the steps above, and submit one of your own forms as a test to check that mails still arrive normally.

While you are in there, it is worth confirming that TYPO3 itself and your other extensions are up to date, since the same principle applies to all of them.

After updating: was this already used against you?

Updating closes the issue, and for many sites that is the whole task. This page is a precautionary notice, not an incident report: I have no visibility into whether anything happened on your site, and I did not look.

But because the vendor reports that this issue has been exploited in the wild, one follow-up is worth doing, and it is conditional on the same flag question. If your site had a form with a sender-name field while running an affected release, then it was possible for someone to have run template code on your server through that form, and updating does not undo anything that may already have been read. The vendor’s advisory gives a simple self-check, and it costs nothing to run:

  • Look at the sender names your forms have received. Check the mails your forms sent you, and the stored submissions in the TYPO3 backend (powermail’s own Mails module) or in the database table tx_powermail_domain_model_mail, for sender names containing Fluid syntax such as f:, v: or {namespace. A real visitor’s name never looks like that.
  • If you find any, the vendor’s guidance is to treat the system as potentially compromised. Because this issue can expose configuration and environment variables, the sensible response in that case is to rotate the secrets your site holds: the database password, TYPO3’s encryptionKey, the Install Tool password, and any API keys or credentials stored in your configuration or environment. Review your backend users for accounts you do not recognise, look for unexpected files on the server, and if your organisation has an IT security team or a national CERT, loop them in.
  • If you find none, and especially if no field carried the flag in the first place, updating alone is enough.

To be clear about the framing: this is a self-check, not a declaration that your site was attacked. This notice is based on a release fingerprint, not on any evidence of an incident.

What I did and did not do

To be fully transparent about the check behind my email: I only read files that your site already serves to every visitor, specifically your homepage and the addresses of the powermail assets written into it. I did not access your TYPO3 backend, your database, your form configuration, or any private part of the site.

In particular, I never submitted any of your forms and never sent template syntax to your site or anyone else’s. Nothing was submitted, tested, or exploited. That matters more here than on most of these pages, because a form submission is the exact action this issue concerns, so “I did not touch it” is the whole difference between a disclosure and an intrusion.

How the release was identified, since a TYPO3 extension publishes no version file. TYPO3 appends each asset’s last-modified time to its URL, as in Form.min.js?1785752971. On a site installed with Composer, that time is the moment the release was published, because Composer preserves it when it unpacks the package, so the number identifies the release exactly: every powermail release has its own. I compared the number your site serves against the published release times and wrote to you only on an exact match. Anything else, which is what a site installed through the Extension Manager or deployed by copying files typically serves, reads as “unknown” and I did not write to those sites at all.

That method has one known blind spot, and it errs on the side of caution. The fixes change only the extension’s PHP code, not its public assets. So if your site was patched by replacing only the code (a manual hot-patch rather than a full update), its assets still carry the old release’s timestamp and it reads as an affected release even though it is protected. If you have already remediated this by other means, no action is needed, and I apologise for the noise.

I am also deliberately not publishing the details that would help someone act on this issue. The description above stops at the level a site owner needs, and I do not link any proof-of-concept code.

This is a version-based observation: your site’s assets identify a release in the affected range. It is not a statement that your site was exploitable at the time I checked. Because the issue depends on a form-field setting I cannot see, a site in that range may well not be exposed at all, and a site in that range may separately be protected by other means such as a web application firewall.

I do not have a webmaster / I am stuck

If you are not the person who maintains the site, please forward this page to whoever does (your web developer, agency, or hosting provider). They will recognize the steps above quickly.

If you are maintaining the site yourself and get stuck, I am happy to help point you in the right direction at no cost. Reach out using the contact details below.

Contact

Evan Harris, Security Researcher

I reach out about issues like this purely to help operators secure their sites. If you would prefer not to be contacted again, just let me know and I will honor that.

References

Official advisories and tracking

Vendor / extension