The Editor Plugin Hands Out the Key: TYPO3 CVE-2026-113459 and a Fifteen-CVE Extension Batch

On 20 October 2026 the TYPO3 security team published nine third-party extension advisories in one batch — TYPO3-EXT-SA-2026-028 through 036 — and NVD issued the corresponding fifteen CVE identifiers in a single run between 10:17:03Z and 10:17:05Z. Fourteen of them are the ordinary furniture of CMS extension security: missing authorization checks, two SQL injections, an SSRF proxy, a predictable download token, an unverified PayPal callback. One is not, and it is the reason this batch lands on an AI security site.

CVE-2026-113459: the key is in the page

TYPO3-EXT-SA-2026-035 covers the “TYPO3 AI Integration Extension” (ns_t3ai, Composer package nitsan/ns-t3ai), affected versions 14.0.1 and below, fixed in 14.0.2. The advisory’s second finding reads, in full: “In versions running on TYPO3 10 and 11, the configured OpenAI API key is embedded in every backend page, so that the editor plugin can contact the OpenAI service directly from the browser. Any authenticated backend user can read the key and use it at the expense of the site operator.” NVD rates it CVSS 4.0 7.1 high under CWE-201, insertion of sensitive information into sent data.

There is no clever bug here, and that is the finding. The key is not leaked by a traversal or an injection or a race — it is placed in the page on purpose, because the feature was designed to call OpenAI from the browser and a browser-side call needs a credential the browser can read. The vulnerability is the architecture stated out loud. Every editor, every freelancer with a temporary backend login, every integration account, every contractor who once had access and whose session you never audited: all of them can open the page source and take a credential that bills the site operator and carries whatever rate limit and organisational scope that key was issued with. “Any authenticated backend user” in a CMS is not a small set, and it is emphatically not the set of people you intended to hand a provider key to.

This is the same failure we keep documenting as AI features are bolted onto existing software: the credential boundary that the host application spent twenty years getting right is bypassed by a feature that needs to talk to a model provider and takes the shortest path there. We wrote about the downstream half of this problem in the OpenCode console breach, where exposed provider keys were the asset being collected. Here is the upstream half: a plugin that publishes one to every logged-in user by design.

The scope note matters for triage. The key exposure is conditional on running TYPO3 10 or 11 and on an API key having been configured at all — which means the exposed population skews heavily toward installations already behind on their CMS major version, the same installations least likely to be reading a third-party extension advisory on the day it publishes.

The other half of the same advisory

SA-2026-035 carries a second identifier, CVE-2026-112239 (CVSS 4.0 7.2 high, CWE-862 and CWE-915), and it is arguably the worse of the pair: the extension “provides a backend endpoint that writes a submitted value into a submitted field of a submitted page record. It neither checks the user’s permissions nor limits which fields can be changed.” Three attacker-chosen values — record, field, value — with no authorization check and no field allowlist. The advisory spells out the consequence: any authenticated backend user can change any property of any page, including its access permissions and configuration, outside the scope granted to them. That is privilege escalation with extra steps, and it is a clean example of mass assignment reaching a permissions model rather than a data model.

Note a discrepancy worth recording if you are scoring this internally: the TYPO3 advisory publishes a single suggested CVSS 4.0 vector for the advisory as a whole (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N), weighted toward the integrity impact of the record write, while NVD scored the two CVEs separately and gave the key exposure VC:H. Both readings are defensible; they answer different questions. Take the per-CVE records for tracking and the advisory vector for understanding what the maintainers thought the dominant impact was.

The rest of the batch

The remaining eight advisories are worth a scan if you run TYPO3, because several are unauthenticated. SA-2026-034 (ameos_filemanager ≤ 3.1.2, CVE-2026-112238, 8.7 high) is the most severe: the file search wraps the search term in quotes itself and escapes only LIKE wildcards, not quote characters, so a crafted term escapes the string literal in every searched field — unauthenticated database read, fixed in 3.1.3. SA-2026-029 (sg_cookie_optin, CVE-2026-112064/112065/112066) is the ironic one: a cookie-consent extension whose history module accepted sorting, grouping and index options straight into a query with only the filter conditions parameterised, letting a backend user read arbitrary data including backend and frontend password hashes; its sibling CVEs add missing module authorization and a JSON import that lets non-admins inject arbitrary frontend scripts. SA-2026-032 (dlf, Kitodo.Presentation, CVE-2026-112237) is an unauthenticated SSRF where one HTTP method on a public proxy endpoint skips the authorization check the others apply, returning status codes and selected headers — enough for internal host and port probing, with response bodies withheld.

SA-2026-028 (fal_protect) stopped applying access protection to file storages with a non-default relative base path, serving protected files directly from the web server, but only on TYPO3 14.3. SA-2026-033 (fluid_form) pairs a predictable download token — also printed in plaintext in notification email — with unescaped visitor input in HTML summary emails. SA-2026-036 (shop) lets any visitor cancel an unpaid order by identifier and overwrite its stored PayPal notification, because neither endpoint verifies ownership or provider origin. SA-2026-031 (analytics) is a pair of IDOR and missing-authorization findings on a backend dashboard.

And SA-2026-030 deserves a line for sheer instructiveness: the “Accessible Form Captcha” extension (bw_captcha 4.0.0–5.4.1, CVE-2026-112067) hides the correct answer inside the image data of the CAPTCHA itself — a side effect of the audio accessibility feature, which is enabled by default. Anyone who can request the image can read the answer out of it. In an era where the realistic adversary against a contact form is an automated agent, a challenge that ships its own solution is not a speed bump.

What to do

If you run ns_t3ai, upgrade to 14.0.2 and then rotate the OpenAI API key — the upgrade stops the key being published, it does not un-publish the one that has been in every backend page render up to now. Treat that key as disclosed to everyone who has held a backend session, review provider-side usage and billing for unfamiliar activity, and reissue it with the narrowest scope and the lowest spend limit the feature actually needs. The structural fix, independent of this extension, is that a provider credential should never be reachable by a browser: proxy model calls through the server, where the key stays, and let the browser talk only to your own endpoint with your own session.

For the rest of the batch, the TYPO3 extension manager and Packagist have fixed versions for all nine: fal_protect 1.8.2, sg_cookie_optin 7.4.6 and 8.1.12, bw_captcha 5.4.2, analytics 1.1.1, dlf 6.0.1 and 7.0.2, fluid_form 5.0.10 and 6.0.6, ameos_filemanager 3.1.3, shop 4.9.4, 5.21.1 and 6.3.0. Prioritise the three unauthenticated ones — the SQL injection in ameos_filemanager, the SSRF in dlf, and the order-manipulation pair in shop. None of the fifteen identifiers are in the CISA KEV catalogue (checked directly, catalogue version 2026.10.16, 1,748 entries, zero hits); no exploitation has been reported.

Our verification was read-only. All nine advisories — TYPO3-EXT-SA-2026-028 through 036 — were read first-hand from typo3.org, including component and Composer package names, affected and fixed version ranges, severities, suggested CVSS 4.0 vectors, problem descriptions and credits; every quoted sentence is verbatim from the advisory it is attributed to. All fifteen CVE identifiers, their NVD publication timestamps between 2026-10-20T10:17:03Z and 10:17:05Z, vulnStatus values, CVSS 4.0 scores, CWE assignments and reference lists were read first-hand from the NVD 2.0 API. The scoring discrepancy between the SA-2026-035 advisory vector and the per-CVE NVD records was observed directly by comparing the two. KEV status was checked directly against the published catalogue. Brave Search was used for discovery only and surfaced a CVE-mirror entry for CVE-2026-113459 with no independent technical analysis. We installed nothing, stood up no TYPO3 instance, installed none of the named extensions, requested no CAPTCHA image, called no endpoint and executed nothing; no third-party request was sent beyond reading the cited public records.

Sources: