TYPO3 Powermail CVE-2026-77136: active SSTI through the sender field
An anonymous form passed sender_name into a Fluid View as template source. Analysis of active exploitation, ViewHelpers, versions 10.9.3/12.6.1/13.2.1 and response.
- AUTHOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLISHED
- 25 August 2026
- READING TIME
- 19 min read
- TOPIC
- Threats and Incidents
TYPO3 published a critical warning on 25 August for the Powermail extension. CVE-2026-77136 allows an anonymous user to submit Fluid template syntax in a form field configured as “This field contains the name of the sender.” The value entered a Fluid View unsanitised as template source, allowing an attacker to invoke ViewHelpers, disclose configuration, environment variables and application source, and potentially achieve remote code execution.
The vendor says the flaw is actively exploited. It carries a suggested CVSS 4.0 score of 9.5 (Critical) with exploit maturity E:A. No account or administrator action is required: a normal form submission is enough when the affected field is assigned the sender_name role. Powermail is a third-party extension and is not part of a default TYPO3 installation.
Versions that require immediate updating
Affected branches are 10.9.2 and earlier, 11.0.0–12.6.0, and 13.0.0–13.2.0. Fixed releases are 10.9.3, 12.6.1 and 13.2.1 respectively. All three arrived on 25 August as security releases. Teams should move to the correct fixed branch or the latest compatible version rather than wait for a full CMS deployment cycle.
Where an old installation cannot be updated immediately, the official mitigation is to disable “This field contains the name of the sender” field configuration. This removes the known reachable path but does not replace updating. Check every form, language variant, site copy and environment because one forgotten configuration is enough to retain exposure.
Confirm the version in the effective in2code/powermail package, lockfile and active extension directory. A container image can contain a new composer.lock while a shared volume retains an old copy. In a cluster, every node serving forms needs the fix.
How a form field became a program
The Fluid engine uses template syntax and ViewHelpers to generate output. When an application passes untrusted text as a variable, the engine should treat it as a display value. Powermail instead placed raw sender_name where a template source belonged. Markup submitted by a user was parsed as Fluid instructions rather than as a sender’s name.
This is classic server-side template injection. Impact depends on the available ViewHelpers, extensions and server configuration. Not every input automatically yields an operating-system shell, but executing server-side helpers is sufficient to read sensitive data and construct a further chain. The official advisory says RCE is possible, not that every site has an identical guaranteed path.
The sender_name condition explains AT:P in the CVSS 4.0 vector: a particular form configuration must be present. The vendor calls it common and default-adjacent, so it is not an exotic edge case. An administrator does not need to enable debugging or install a uniquely dangerous helper for configuration disclosure to become possible.
Why an HTML filter or WAF does not solve SSTI
HTML sanitisation protects a different interpreter. It may remove browser markup, while Fluid syntax is processed on the server before a response or email is generated. Encoding at a stage followed by decoding can also preserve active semantics. The strongest fix stops treating user data as template source.
A WAF can detect familiar template tokens, but legitimate syntax is rich and can use varying namespaces and encodings. Blocking a few strings cannot be complete, especially after the vendor confirmed active attacks. A WAF rule is a temporary shield and telemetry source, not the primary remediation.
Fixed releases apply a ViewHelper allowlist in extension configuration. Organisations using custom helpers need to add required entries deliberately. Test form submission, email content and integrations after updating, but do not restore a broad list merely to make an old template pass without analysis.
Official detection: messages and the Powermail database
TYPO3 recommends checking received emails and the sender_name field stored in tx_powermail_domain_model_mail. Search for Fluid syntax, including prefixes such as f:, v: and namespace declarations. Their presence may indicate ViewHelper execution and data exposure. Preserve the exact value, timestamp, form identifier and associated request.
This is a starting point rather than a complete IOC. An attacker may use another prefix, inline syntax, encoding or a helper from a local extension. Review reverse-proxy, application and email logs for unusual POST requests, Fluid errors, long sender values and responses whose size differs from the normal baseline.
On the host, correlate request time with configuration-file reads, new PHP child processes, outbound traffic and webroot changes. A ViewHelper that only discloses data into a generated email may create no child process. Mail logs and stored form records are therefore as important as EDR.
Responding when Fluid syntax is found
The official advisory says to treat the system as potentially compromised and analyse and repair it carefully. First preserve the database, messages, logs and current configuration. Restrict the form or detach the affected node, then update the extension. Do not delete a suspicious record before preserving evidence.
Establish which data the PHP process could read: TYPO3_CONTEXT, database configuration, encryption keys, email, storage and API credentials. Determine whether an HTTP response or generated email contained configuration or source fragments. Inspect backend accounts, content changes, extensions, scheduler tasks and files added during the exposure period.
If code execution is confirmed or persistent changes cannot be excluded, rebuild the host from a clean artifact and verified database. Rotate reachable secrets after removing attacker access. Updating Powermail closes the entry point but does not undo a previously created account, file or stolen token.
Priorities in a multisite environment
Agencies and organisations maintaining many instances should first discover every in2code/powermail installation, then link version to sender_name configuration and public form exposure. Prioritise Internet-facing sites, forms accepting anonymous submissions and systems that hold production secrets in the same process.
Do not omit archived campaign sites and subdomains. An older page may see little traffic but share database, SMTP or hosting-panel access. If one image or deployment repository supplies Powermail to multiple customers, patch the component centrally while hunting separately in each database.
Designing the template boundary safely
Separate templates from data through types and APIs. Template sources should come from a repository or tightly authorised management plane, while form values enter only as variables. If the business genuinely needs user-authored templates, provide a separate restricted language, an exact helper allowlist, limits and an isolated renderer without secrets.
A regression test should place template syntax in every field and prove it appears literally or is safely rejected. Exercise email, backend preview, export and database rendering because the same value may enter multiple contexts. Protecting only the front-end view does not secure later email generation.
Source facts and Breachroad conclusions
Active exploitation, the sender_name condition, Fluid View mechanism, affected versions, CVSS, fixed releases and detection guidance come from the official TYPO3 advisory. Powermail release notes confirm the ViewHelper allowlist. The public source does not provide campaign scale, actor attribution or the outcome of every incident, so those details should not be inferred.
The extended correlation plan, secret analysis, multisite priorities and template-design rules are Breachroad conclusions. AppSec training for PHP teams helps engineers recognise interpreter boundaries, while web application penetration testing can assess SSTI, form configuration and process containment.
