Six TYPO3 extension advisories on 19 May 2026 — two RCEs, two SQL injections, ke_search times three, one access-control gap, and what patch order the cluster demands

TL;DR — the 90-second summary

What was published?

Six advisories TYPO3-EXT-SA-2026-008 to -013, all from 19 May 2026 around 18:00 UTC. Affected extensions: crawler, sf_register, news, ke_search, tt_address, ceselector.

How severe on average?

One Critical (ceselector, CVSS vector screams unauthenticated RCE), two High (news with SQL injection, crawler with RCE), three Medium (tt_address, sf_register, ke_search).

Which two patterns repeat?

First Insecure Deserialization (CWE-502) — both ceselector and crawler hand unserialize() attacker-controlled input (cookie respectively HTTP response header). Second SQL Injection (CWE-89) — tt_address and news build queries without proper parameterisation. Both patterns have been known for years, but seeing them in this combination on a single advisory day is rare.

Am I affected with an auto-update pipeline (Renovate, Dependabot, Mend)?

If any of the six extensions is in your Composer lock, yes — in a patch-pipeline-managed environment the six patch releases show up automatically as merge requests against the image definitions. The container rebuild is graceful; the worker restart stays invisible to end users.

Am I affected if I run self-hosted without an auto-update pipeline?

Then yes, and you should update today. Order by risk: first ceselector (Critical, public-facing RCE), then news (High, public-facing SQLi), then crawler (High, admin escalation), then the rest.

Which two configuration conditions should I know about?

ceselector is only exploitable under Persistent Mode: Static. The news SQLi only bites when the Date Menu of news articles plugin instance is active anddisableOverrideDemand is not set. Whoever knows and can verify both conditions has a risk analysis before the update.

Operational response to the cluster

Moselwal positions itself explicitly on auto-update-ready platforms — the CTA at the bottom of this post sums that up in a sentence. The operational principle behind it: a patch pipeline (Renovate, Dependabot, Mend or similar) scans Composer packages several times a day and pushes new patch versions automatically into merge requests against the image definitions. A wave like the 19 May cluster therefore flows into the build pipeline without a night shift: the six patch releases (crawler 12.0.11 / 11.0.13, sf_register 14.0.2 / 13.2.4, news 14.0.3 / 13.0.2 / 12.3.2 / 11.4.4, ke_search 7.0.1 / 6.6.1 / 5.6.2, tt_address 10.0.1 / 9.1.1 / 8.1.2, ceselector 6.0.1 / 5.0.1 / 4.0.2 / 3.0.3) appear as merge requests, the CI rebuilds the container images, the worker restarts (FrankenPHP, php-fpm) are graceful, and the service remains available to end users without interruption.

Anyone without that — a standalone TYPO3 installation without an auto-update pipeline — has a very narrow window on the Critical and High severity items. The following sections walk through each advisory: what happens technically, what preconditions exploitation requires, and which update order makes sense.

TYPO3-EXT-SA-2026-013 — ceselector (Critical, RCE via unserialize cookie)

Technical analysis

On the persistent-mode lookup, the extension reads a client cookie that is meant to carry the most recently chosen content element selection in serialised form. The cookie value is handed to PHP’s unserialize() directly, without schema validation and without an allowed_classes allow-list. That is a textbook PHP-object-injection primitive: an unauthenticated attacker can craft a serialised payload with arbitrary class instances whose __destruct(), __wakeup() or __toString() magic methods fire during deserialisation. Combined with any PHP class that has a gadget-capable __destruct (TYPO3 core has documented POP-chain gadgets for this), this is a full RCE in the web-server process.

Precondition for exploitation

Persistent Mode: Static must be set in the plugin settings. If you run the plugin in dynamic mode or without persistence, you are not directly exploitable. Update anyway — that is cheap insurance against configuration drift in the future.

TYPO3-EXT-SA-2026-010 — news (High, SQL injection in date-menu plugin)

Technical analysis

The Date Menu of news articles plugin instance accepts a URL parameter carrying a date or a date range for menu generation. The parameter flows directly into the generated SQL query without parameter binding. That makes string-interpolation-based SQL injection possible — an unauthenticated attacker can append arbitrary UNION SELECT statements and pull content from other tables.

Precondition for exploitation

Two conditions must hold at the same time: the Date Menu of news articles plugin must be in use, and the TypoScript setting plugin.tx_news.settings.disableOverrideDemand must not be enabled. Setting disableOverrideDemand = 1 disables the vulnerable code path — that has been the recommended hardening measure for years.

TYPO3-EXT-SA-2026-008 — crawler (High, RCE via X-T3Crawler-Meta header)

Technical analysis

The site crawler crawls configured URLs and reads an X-T3Crawler-Meta response header from the HTTP response that is meant to carry metadata of the crawled page. The header value is processed with unserialize() without an allowed_classes restriction. If an attacker controls the endpoint the crawler fetches (their own site, a compromised third party, an open redirect with header injection on the backend), they can return a serialised payload as a response header and trigger PHP object injection inside the crawler worker process — again with the known POP-chain gadgets from TYPO3 core.

Precondition for exploitation

Administrative privileges to create a crawler-capable page configuration and start a scheduler task. So the vulnerability is not a direct RCE path for unauthenticated attackers — but it is a privilege-escalation path for non-super-admin administrators.

TYPO3-EXT-SA-2026-011 — ke_search (Medium, three-pack of XXE + path traversal + information disclosure)

Technical analysis — three vectors, one extension

Vector 1 — XXE in the OOXML parsing pipeline. The file indexer of ke_search processes .xlsx and .pptx files by parsing the embedded XML streams. The XML parser configuration does not disable external-entity resolution. If an attacker plants a crafted xlsx/pptx file in an indexed directory, XML parsing can trigger an entity reference to local files (file:///etc/passwd) or to external URLs (out-of-band SSRF) — and the resolved content lands in the search index, i.e. in the frontend output.

Vector 2 — Path traversal in the file indexer. The file indexer does not normalise the directories configuration path. A backend user with indexer-configuration rights can set sequences like ../../../etc and thereby pull files from arbitrary directories on the server into the search index.

Vector 3 — Information disclosure via additional_tables. The additional_tables configuration of the page and tt_content indexers accepts arbitrary table and field names. A backend user with indexer-configuration rights can copy sensitive internal TYPO3 tables (be_users.password hashes, sys_log entries) into the search index.

TYPO3-EXT-SA-2026-012 — tt_address (Medium, latent SQL injection in getSqlQuery())

Technical analysis

The method AddressRepository::getSqlQuery() builds a database query without sanitising input. That is a textbook SQL-injection site — however: the method itself is not called from anywhere inside the tt_address extension. A default setup is therefore not directly exploitable.

The method is public. Custom extensions that consume AddressRepository via DI or direct instantiation and call getSqlQuery() with untrusted input expose their site. That is why the security team deliberately set the severity lower than the CVSS score.

TYPO3-EXT-SA-2026-009 — sf_register (Medium, FE user-group escalation in self-service registration)

Technical analysis

The create and edit flows of the self-service registration do not restrict which properties of the FrontendUser model may be set via HTTP POST, and do not check the FE user-group assignment. During registration or while editing existing account information, an attacker can submit an additional form field usergroup[] with the UID of a privileged FE user group — the property is set on the model unchecked and persisted. Result: self-registration into an FE user group that should normally only be reachable through controlled paths.

This is a classic mass-assignment vulnerability — Symfony calls this pattern „over-aggressive form mapping“. The fix version sets an explicit allowedProperties or unsetProperty statement in the controller that removes the usergroup property from the incoming request.

Two recurring patterns — what 19 May tells us about TYPO3 extension hygiene

Six advisories on one day is a lot, but the structural observation is not „TYPO3 has a problem“ — it is „two anti-patterns known for years are firing in parallel across the extension landscape“:

First: PHP object injection via unserialize() on attacker-controlled data. Both ceselector and crawler call unserialize() on external bytes — one via a cookie, the other via an HTTP response header. Both have been documented as an anti-pattern since the early 2010s. The clean fix is either to pass an allowed_classes allow-list or to switch entirely to structured formats like JSON. That both extensions surface on the same day with the same pattern is no coincidence — a security researcher most likely went grepping for unserialize calls in popular extensions.

Second: SQL injection through string interpolation instead of parameter binding. news and tt_address make the same mistake: query construction with string concatenation instead of prepared statements. Exploitable on news, only exploitable in custom-extension constellations on tt_address. This too is a solved problem since Doctrine DBAL and the TYPO3 QueryBuilder API — the fix is usually a 5-line change from ->where("title LIKE '%" . $input . "%'") to ->where("title LIKE :input")->setParameter('input', '%' . $input . '%').

The ke_search three-pack sits slightly outside this pattern — it carries a different lesson: when an extension exposes several configuration knobs to backend users, each one of them needs to be hardened against path and schema manipulation.

Detection and verification

Even in a patch-pipeline-managed environment, manual verification per setup type is done in 15 minutes — and for self-hosted setups without an auto-update pipeline it’s mandatory anyway:

Which extensions are installed?

composer show 'tomasnorre/crawler' 'evoweb/sf-register' 'georgringer/news' \
              'tpwd/ke_search' 'friendsoftypo3/tt-address' 'mmc/ceselector' 2>/dev/null

Reconcile the version column against the fixed-version list above.

Check the news configuration (CVE-2026-8726)

# Where is disableOverrideDemand set?
grep -rn 'disableOverrideDemand' typo3conf/ Configuration/ vendor/*/Configuration/

If the plugin is in use and disableOverrideDemand is not set: update with priority High, or at least set disableOverrideDemand = 1 as a hot-fix in TypoScript.

Check ke_search indexer configuration (CVE-2026-46722/-46723/-46724)

SELECT uid, title, type, directories, additional_tables
  FROM tx_kesearch_indexerconfig
 WHERE deleted = 0 AND hidden = 0;

Inspect directories for .. sequences; reconcile additional_tables against your table allow-list; remove any configuration that doesn’t match the expected site structure in the next backend session.

Operator recommendation — operational decision block

Recommendation by setup type

Single-tenant TYPO3 hosting with Renovate

No operational pressure, rollout runs automatically. Optional verification that the new version is live: composer show <package> in the container, or the backend → extension manager.

TYPO3 without Renovate but in Composer mode

This morning: composer update mmc/ceselector tomasnorre/crawler georgringer/news tpwd/ke_search friendsoftypo3/tt-address evoweb/sf-register --with-all-dependencies, followed by vendor/bin/typo3 cache:flush and a worker restart.

TYPO3 in classic mode (no Composer)

Update each extension via the extension manager in the TYPO3 backend to the fixed version. Order by severity: ceselector (Critical) → news (High) → crawler (High) → ke_search (Medium) → tt_address (Medium) → sf_register (Medium).

TYPO3 long-term support v11 / v12

Fix versions for the older lines are available too (see the version table per advisory). Check Composer constraints to make sure the new patch version is picked up.

How Moselwal handles advisory waves

For advisory waves like the 19 May cluster, a three-layer approach makes sense — and that is exactly why Moselwal builds its platforms around auto-update readiness:

Layer 1: patch pipeline picks up the releases. A version-watcher pipeline (Renovate, Dependabot, Mend) scans Composer packages several times a day. As soon as the advisory patches show up, the pipeline pushes a merge request against the image definition; CI rebuilds the image. A Critical RCE like ceselector therefore does not wait for the next manual pull.

Layer 2: rolling rebuild prioritised by exposure. Once the new images are available, the rollout runs in stages. Order: stacks with exploitable configuration in one of the Critical / High severity items first (ceselector with Persistent-Static, news with date-menu plugin and no disableOverrideDemand), followed by the long tail. Worker restarts (FrankenPHP, php-fpm, mod_php) are graceful; the service remains available to end users without interruption.

Layer 3: audit pass over the configuration state. Alongside the rollout, a script-driven audit runs: which extension is on which version, which critical plugin settings are active, which backend users have indexer-configuration rights. The result feeds into the next maintenance routine — the cluster is therefore not just “patched away”, but used as an occasion for a systematic configuration review.

Anyone maintaining a TYPO3 platform who wants to set up a comparable wave routine will find the entry point in the CTA below.

Bottom line

Six advisories on a single day is a lot, but structurally nothing new. Two recurring anti-patterns (unserialize() on untrusted bytes, string interpolation in SQL queries) meet a ke_search three-pack of XXE, path traversal and schema-validation gaps. The Critical issue (ceselector) has clear exploitation preconditions; the news SQLi is the operationally most likely mass threat.

For stacks running an auto-update pipeline (Renovate, Dependabot or similar), the fix versions flow into the build without manual intervention and without visible service interruption. For self-hosted TYPO3 setups without an auto-update pipeline, the order above applies: first ceselector (Critical, unauthenticated), then news (High, unauthenticated), then crawler, then ke_search, then tt_address and sf_register. For active date-menu plugins without disableOverrideDemand, a hot-fix TypoScript without a Composer update also makes sense to bridge the gap until the patch lands.

Whoever wants to weather waves like this regularly without a night shift should consider Renovate or a comparable version watcher. A disclosure wave like this one won’t be the last in the coming months.