Sourcerer 14.0.0 fixes PHP execution from unverified content

On 17 August 2026 Regular Labs released version 14.0.0 of Sourcerer, the Joomla extension that lets you place PHP, JavaScript and CSS inside your content. The changelog carries one entry tagged both [SECURITY FIX] and [BC BREAK]:

It runs that code wherever you put it: articles, modules, components, the page head. To do that it inspects the finished page on every render and executes the tags it finds. The question 14.0.0 answers is one Sourcerer never used to ask about most of the page: where did this code come from?

TL;DR

• Sourcerer 16.0.0 is the fix. The CVE record was re-scoped on 26 August and now puts the affected range at 1.0.0 to 15.0.0, so 14.0.0, 14.0.1 and 15.0.0 are affected too, despite each having been published as a fix
• It is being exploited in the wild, since roughly 19 August per the Joomla Security Strike Team, which is two days after the first fix shipped
• Before 14.0.0, the only content whose origin Sourcerer verified was article text. Code that reached the page any other way simply ran
• From 14.0.0, a block executes only if the plugin can trace it to a trusted source: article content, or a Custom module whose rendered text still matches what is stored
• HTML-escaping is not a mitigation. Sourcerer decodes HTML entities inside its own tags on purpose, so WYSIWYG-authored code works
• PHP execution is enabled by default, and the default forbidden-function list blocks shell functions, not file writes
• Tracked as CVE-2026-74253, CVSS 4.0 10.0, critical, published by the Joomla CNA on 17 August 2026 and re-scoped on 26 August 2026 from ”< 14.0.0” to ”< 16.0.0”. The earlier CVE-2026-64796 is a separate issue and stops at 12.2.8
• This is a deliberate breaking change. Some legitimate code will stop running until you allow it, which is the correct trade
• Sourcerer is installed on thousands of the Joomla sites we manage, and roughly nine in ten of those installs are on an affected build today

What 14.0.0 changed, and what it missed

The fix is structural rather than a patched line. Version 14.0.0 adds a trust-marking step. Content Sourcerer can vouch for gets marked as it passes through the page, and only marked blocks may execute code. Two origins qualify. Article content does, as it did before. A Custom module does when the text being rendered still matches what is stored in the database for that module, which is how the plugin knows the code you are about to run is the code an administrator actually saved.

Everything else now counts as unverified. On the Free edition those blocks are removed rather than run. On Pro, each unverified CSS, JavaScript or PHP type has to be allowed explicitly before it will execute again.

That was the right shape of fix, and it was not complete. Marking trusted content only helps if every route by which untrusted content can reach the render is covered, and it was not. An attacker could still get Sourcerer syntax into the page by supplying it through a URL, through a form field name or value, through a raw request body, an upload, a cookie or a request header. The vendor closed those routes in 16.0.0 on 26 August, with a second changelog entry tagged [SECURITY FIX]:

16.0.0 also blocks common filesystem-write functions by default and adds them to your existing saved settings, which is the change most likely to break something you rely on. Pro gains a Trusted Request User Groups setting for choosing which logged-in users may submit Sourcerer tags through requests.

Three releases in nine days

The sequence is the story here, because it explains how a site could be patched twice and still be exposed. The full timeline is at the bottom of this post; the short version is that the two releases in the middle both looked like fixes.

The uncomfortable part is who this caught. Anyone who ignored the 17 August release was exposed, which is the normal outcome and the normal advice covers it. Anyone who applied it immediately was also exposed, for another nine days, and had every reason to believe they were not. Their extension manager said 14.0.0, the CVE record said 14.0.0 was the fix, and so did we.

Two halves of the same Joomla extension problem

This is the second Sourcerer security release in under a month, and the two are halves of one problem.

On 22 July 2026 Regular Labs shipped a coordinated hardening release across its whole catalogue. Sourcerer 13.0.0 was part of it, and the CVE that came out of it, CVE-2026-64796, describes the Free edition failing to “require both the article creator and last modifier to be Super Users before executing article PHP”. That closed the article path: from 13.0.0, PHP in an article only runs if trusted people wrote and last touched it.

August’s release closes the rest of the page. The article path had an author check; the module, component, head and final-rendering positions had no origin check at all. Getting the first half right is what made the second half visible.

The practical consequence is that patching one does not patch the other. CVE-2026-64796 gives its affected range as 1.0.0 to 12.2.8. A site sitting on 13.1.1 is outside that range, is not flagged by it, and is still affected by the August issue. That second record, CVE-2026-74253, now runs from 1.0.0 to 15.0.0 and covers the whole line up to 16.0.0.

Why escaping the input does not save you

The natural assumption is that a site is safe as long as it escapes what users type, because escaped angle brackets cannot open a PHP block. With Sourcerer that assumption falls apart, and the reason is a documented feature, not a bug.

Code written in a WYSIWYG editor arrives with its angle brackets converted to HTML entities. So that code still runs, Sourcerer decodes entities inside its own tags before handling the contents. The decoding has no way to tell code an administrator typed into TinyMCE from text that arrived from somewhere else. Escaped text is not automatically inert, and “we escape our output” is not the control that protects a site here.

Two other defaults matter when you are weighing urgency. PHP execution is on out of the box. The default list of forbidden PHP functions covers shell-execution functions, so it stops a payload shelling out, but it does not cover writing files.

We are deliberately not publishing a working request or a payload. Nothing above is a recipe, and you do not need any of it to decide whether to update.

Which Joomla sites are affected?

Every site running a build below 16.0.0. The CVE record starts its range at 1.0.0, so there is no older version to fall back to, and the builds worth naming now are 14.0.0, 14.0.1 and 15.0.0, because those sites took the security update, did what they were told, and are still affected. Being current is not the same as being safe when the vendor has to fix the same flaw three times.

One trap when you check versions by hand: Pro builds append a PRO suffix, so a Pro site reports 15.0.0PRO rather than 15.0.0. String comparisons and spreadsheet sorts handle that badly, and it is why a “less than 16.0.0” rule written the obvious way can misjudge a Pro build in either direction. Compare the numeric part and treat anything below 16.0.0, Free or Pro, as affected.

Sourcerer is installed on thousands of the Joomla sites we manage, and roughly nine in ten of those installs are on an affected build today. Our own vulnerability rules were bounded at 13.1.1 until 26 August, in line with the CVE record as it then read, which means the sites that had updated to 14.x or 15.0.0 were showing a clean bill of health while they were exposed. We widened the rule to below 16.0.0 the morning the re-scope appeared and alerted the affected customers directly.

What should I do now?

Update Sourcerer to 16.0.0. Not 14.0.1, not 15.0.0. Then plan for the breaking changes rather than being surprised by them: legitimate code Sourcerer was picking up from a module, component, head or final-rendering position stopped running at 14.0.0 until you allow that type explicitly on Pro, and from 16.0.0 any Sourcerer PHP that writes files will be blocked by default. If the site depends on Sourcerer for anything structural, test on a staging copy first.

Because this one was exploited before a working fix existed, updating is not the whole job. Check the site for administrator accounts you did not create, and audit for files that changed when you were not deploying. Updating closes the door; it does not evict anyone who already came through it, and what this flaw hands out is arbitrary PHP.

If you cannot update immediately, disabling the Sourcerer system plugin removes the exposure, because that is the plugin that renders Sourcerer tags. It also removes the functionality, so treat it as a stop-gap rather than a fix.

Disclosure and severity

This is not our find. The CVE record credits Łukasz Rybak as the finder; the vendor changelog credits nobody, and Regular Labs published no separate advisory beyond the entry quoted at the top of this post. We read the 13.1.1 and 14.0.0 packages side by side to work out what the entry means, and we confirmed the behavioural difference between the two versions on our own Joomla 6 test site.

The record classifies the weakness as CWE-94, improper control of generation of code, which is the same call we made: code from an unverified origin was executed as PHP. It adds CAPEC-242, code injection. The impact once a block runs is complete: arbitrary PHP in the site’s own process.

Our own provisional scores were lower, and the difference is reachability. We could not reach the flaw through Joomla core alone: core’s input filtering stripped our test payload out of a reflected search parameter, raw and entity-encoded alike, so we could demonstrate no anonymous route at all on a stock site. We scored what we had proved, treating a suitable delivery position as a requirement (AT:P) and putting the everyday case behind a login. The CNA scored the flaw itself, with the reflected route its finder demonstrated. Its record is the one to quote, and ours is here for completeness.

Our provisional variant	Vector (CVSS:4.0/...)	Score	Severity
Low-privileged account, raw-rendered position outside the article path	AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N	7.7	High
Anonymous, where another extension renders raw request input	AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N	9.2	Critical

Field	Detail
Component	Sourcerer for Joomla (plg_system_sourcerer and plg_editors-xtd_sourcerer), Free and Pro
Vendor	Regular Labs (regularlabs.com)
Type	Execution of code from an unverified origin
CVE	CVE-2026-74253, published 17 August 2026 by the Joomla CNA and re-scoped 26 August 2026 from ”< 14.0.0” to ”< 16.0.0”. CVE-2026-64796 covers the earlier, separate issue in 1.0.0 to 12.2.8
CVSS 4.0	10.0 (critical), AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. Our own provisional figures, published before the record existed, were 7.7 and 9.2
CWE	CWE-94 (improper control of generation of code), CAPEC-242 (code injection)
Affected versions	1.0.0 up to and including 15.0.0 per the re-scoped CVE record, Free and Pro. That includes 14.0.0, 14.0.1 and 15.0.0, each of which was published as a fix
Fixed in	16.0.0, released 26 August 2026. The earlier 14.0.0 (17 August) and 15.0.0 (24 August) did not close it
Exploited	Yes, in the wild since roughly 19 August 2026 per the Joomla Security Strike Team, confirmed to us 24 August 2026
Finder	Łukasz Rybak, credited in the CVE record. Not a mySites.guru find, and the vendor changelog credits nobody
Vendor advisory	None beyond the changelog entry