Struts CVE-2026-104711: two of four affected lines are end of life; the remedy is a mapper change, not a patch

Two of the four affected Struts lines are end of life, and Apache gives them no code fix

Apache's security bulletin S2-075 lists four affected version ranges for CVE-2026-104711, an OGNL injection in the legacy RESTful action mapper that, in Apache's words, "may lead to remote code execution". Two of the four ranges are tagged "(EOL)": Struts 2.0.0 through 2.3.37, and Struts 2.5.0 through 2.5.33. The fix Apache recommends, Struts 7.4.0 or 6.12.0, exists only for the other two. That is two of four lines, or 50 per cent (derived), with no code fix from Apache. For those lines the bulletin's only remedy is to stop using the legacy mapper.

So for an application on an end-of-life line the control is not "apply the update". It is one of three things: remove the legacy mapper from its configuration, move to a supported branch, or take the application off the internet. The first two are in the bulletin. The third is not: it comes from the UK guidance read below, and this briefing says so where it matters. The slug of this briefing says that end-of-life branches "get no fix". Read against the primary, that holds for a code fix and needs one correction: the bulletin does not use those words. The project's own End-of-Life page says that for an end-of-life branch the team "no longer provides security patches, bug fixes, or updates", and that such versions receive "no support at all" from the project. The bulletin also gives a workaround for every affected line, so "no fix" does not mean "nothing to do".

What this does not establish matters as much. Apache rates S2-075 "Moderate", the lower of the two ratings used in this batch, and says remote code execution is "possible". Neither the bulletin nor the CVE record says anything about exploitation. No source read gives a count of how many applications use the legacy mapper. The word "unauthenticated" that one database uses for this flaw is not in Apache's text for CVE-2026-104711: it comes from a scoring assumption by CISA, set out below. And the 6 October date that circulates in secondary coverage is late: Apache's release and bulletin pages are dated 2 October 2026 and its announcements and CVE records 5 October. 6 October is when the news pages and CISA's enrichment of the records appeared.

From Apache's own dates, 12 October is 10 days after the 2 October release and 7 days after the 5 October announcement (both derived; six if counted from 6 October). This briefing reads the primaries: the Struts project's announcements, the four bulletins, the release notes, the project's end-of-life, security and action-mapper pages, the CVE and NVD records, and CISA's catalogue file. Reading began at 20:23 BST on Monday 12 October 2026 and the volatile pages were re-read at 20:49. Four secondary pages were read only as pointers. Where they disagree with the primary, the primary decides.

The four bulletins in Apache's words

All four were announced on 5 October 2026 for the same two releases, Struts 7.4.0 and 6.12.0, which are dated 2 October. Apache rates three of them Moderate and the REST plugin one Important, which matches the secondary reports. The affected ranges differ by flaw, and the table gives each as Apache lists it.

The four Struts bulletins of 5 October 2026, from the Apache bulletin pages (each last updated 2 October 2026) and the CVE records. EOL marks the lines the bulletins themselves tag end of life.

Bulletin and CVE	Apache's summary and impact	Apache rating	Affected, as listed
S2-075, CVE-2026-104711	OGNL injection in the legacy RESTful action mapper can lead to remote code execution. Impact: possible remote code execution.	Moderate	2.0.0 to 2.3.37 (EOL); 2.5.0 to 2.5.33 (EOL); 6.0.0 to 6.11.0; 7.0.0 to 7.3.0 only when the OGNL allowlist is disabled
S2-076, CVE-2026-104712	Disproportionate response size when a request parameter bound to a BigDecimal property is rendered through the tag library. Impact: denial of service.	Moderate	2.5.14 to 2.5.33 (EOL); 6.0.0 to 6.11.0; 7.0.0 to 7.3.0. Struts 2.3.x and earlier are stated as not affected
S2-077, CVE-2026-104713	Unbounded read of a REST request body in the REST plugin, in its default configuration. Impact: denial of service.	Important	2.1.8 to 2.3.37 (EOL); 2.5.0 to 2.5.33 (EOL); 6.0.0 to 6.11.0; 7.0.0 to 7.3.0. Applications that do not use the REST plugin are not affected
S2-078, CVE-2026-104714	A message formatter shared between concurrent requests lets one user's date or time value appear in another user's response. Impact: disclosure of data, denial of service.	Moderate	2.0.0 to 2.3.37 (EOL); 2.5.0 to 2.5.33 (EOL); 6.0.0 to 6.11.0; 7.0.0 to 7.3.0

Counting from the table (derived): the 2.5.x line is in the affected range of all four bulletins and 2.3.x in three of four. The CVE record for CVE-2026-104711 was reserved on 2 October and published on 5 October at 18:35 UTC, about 80 hours later (derived). NVD lists it as analysed.

Is the REST plugin flaw separate from the mapper flaw? On the record, yes. S2-075 says applications using the Struts REST plugin are not affected by the mapper flaw. S2-077 says applications that use the plugin to accept request bodies are exposed to an unbounded read in the plugin's default configuration. They are separate bulletins and separate CVEs with different weakness types in their records (an expression injection, CWE-917, and an unbounded allocation, CWE-770, both derived from the records) and different impacts: code execution in one, denial of service in the other. What they share is the fixed releases.

Which version lines are affected, which are end of life, and which are fixed

Version-line matrix for CVE-2026-104711 (S2-075), from the bulletin, the CVE record, the project's End-of-Life and download pages, and its announcements. The affected column assumes the legacy RESTful action mapper is configured.

Version line	Affected by the mapper flaw?	Support status as the project states it	Fixed version
2.0 to 2.3.x (2.0.0 to 2.3.37)	Yes, if the legacy mapper is configured	End of life. EOL page: 12 September 2019	None. Bulletin remedy: stop using the legacy mapper
2.5.x (2.5.0 to 2.5.33)	Yes, if the legacy mapper is configured	End of life. EOL page: 30 October 2023	None. Same remedy
6.0 to 6.11 (6.x line)	Yes, if configured. The bulletin states no allowlist condition for 6.x	Supported. No end date found on the project pages read	6.12.0
7.0 to 7.3 (7.x line)	Only when the OGNL allowlist is disabled. It is enabled by default	Supported. 7.4.0 is the current release	7.4.0

Struts 1.x is a separate framework, is in none of these ranges, and ended on 5 April 2013 by the project's table. The bulletin attaches the allowlist condition to Struts 7 only. The project's security page says the allowlist exists from Struts 6.4 and is on by default from 7.0. Whether turning it on protects an application on 6.4 to 6.11 is not stated, and one secondary page wrongly applies the condition to all of 6.x.

Moving from an old line is a project, not a patch. The project's announcements give the minimums: the 6.x series needs Servlet API 3.1, JSP API 2.1 and Java 8, and the 7.x series needs Java 17 and Jakarta EE. The project's 2.5.x end-of-life notice says migrating from 2.5.x to 6.x "will be smoother" than going straight to 7.x. Apache's 7.4.0 release notes also list breaking changes, among them a default size limit on REST plugin request bodies. Read them before moving.

Three details about the workaround are easy to miss. First, the bulletin names the default mapper, the restful2 mapper and the REST plugin as safe destinations, yet the 6.12.0 and 7.4.0 release notes deprecate both the legacy and the restful2 mappers and say to use the REST plugin. The REST plugin is the component in S2-077, the Important-rated flaw, which has no configuration-only mitigation and only a proxy or container size limit as a workaround. So on an end-of-life line, moving to the REST plugin trades one flaw for another (inference from the bulletins); the default mapper, which the notes do not deprecate, avoids both. Second, Apache's own release note describes the cause as the legacy mapper not applying the action-name validation that the default mapper applies, which is consistent with the default mapper being stated as unaffected (inference). Third, the project's action mapper documentation shows that several mappers can be chained in a composite arrangement, and its example includes the legacy one. The bulletin says "configured to use" the legacy mapper and does not say whether one entry in a chain counts. Treat it as in scope until shown otherwise (inference).

End of life in the project's own words, and how old it is

The project's End-of-Life page tabulates three ended branches: 2.5.x on 30 October 2023, 2.3.x on 12 September 2019, and 1.x on 5 April 2013. It says an end-of-life branch gets no security patches, bug fixes or updates, and that the user mailing list and issue tracker support only supported versions. The download page says versions no longer listed receive no further security patches. Only 7.4.0 and 6.12.0 are listed.

End-of-life dates for the two affected 2.x lines, from the project's End-of-Life page, its 2018, 2019 and 2023 announcements and its release notes. Ages are derived at 12 October 2026.

Line	End-of-life date and notice	Last release	Derived age at 12 Oct 2026
2.3.x	12 September 2019 (EOL page). The end of life was announced on 14 November 2018 with six months' notice	2.3.37, 30 December 2018	7 years 1 month (2,587 days); last release 7 years 9 months ago
2.5.x	30 October 2023 on the EOL page's table. The notice of the same date says the branch "will reach its end of life in 6 months"	2.5.33, 7 December 2023	2 years 11 months (1,078 days) by the table date; about 2 years 5 months (895 days) if six months are added; last release 2 years 10 months ago

The project's two pages disagree on the 2.5.x date, so both are shown. On either reading the 2.x line has been unsupported for years: seven years and one month for 2.3.x, so no flaw found on that line since has had a security fix, and about two and a half to nearly three years for 2.5.x (all derived). No 2.3.x or 2.5.x release appears on the project's 2024, 2025 or 2026 announcement pages, so 2.5.33, the last version in all four bulletins' ranges, is the last release seen.

Commercial support exists. The project's pages list HeroDevs, which sells what it calls Never-Ending Support for end-of-life Struts, and the project states that the Apache Software Foundation does not endorse any commercial offering. HeroDevs has a vested interest here: its page for CVE-2026-104711 labels the flaw Critical and offers its own fix for 2.5.x. That page was read only for its labels and its claim, and the claim was not tested. The NCSC's vulnerability-management guidance adds a caution that applies to any such arrangement: products under extended support "may not receive fixes for all known vulnerabilities" and updates may have to be installed manually, so it recommends migrating once a product is out of mainstream support.

Stated and not stated: the record, line by line

"Not stated" means not found in the primaries and records read. It does not mean the information does not exist.

What the Apache bulletins, the CVE and NVD records and CISA's files state about CVE-2026-104711 and its three companions, and what they do not. Read on 12 October 2026.

The question	Stated	Not stated
Is it exploited?	Apache's bulletin and CVE record say nothing. CISA's enrichment of the record (6 October, 14:08 UTC) records exploitation as none. None of the four CVEs is in CISA's KEV catalogue, version 2026.10.08. Secondary pages say no exploitation is confirmed.	Any telemetry from honeypots, responders or threat-intelligence firms, either way. None found. No statement is not proof of no exploitation.
Is a proof of concept public?	One secondary page says none is confirmed. Another says none was verified in its data.	Whether working code exists. Not searched for, and none is linked. Two secondary pages print request-level detail that this briefing does not repeat.
How common is the legacy mapper configuration?	Apache rates the flaw Moderate. Its published scale says Moderate is likely where a configuration "isn't widely used". The 6.12.0 and 7.4.0 notes deprecate the mapper.	Any count. No source gives one. Linking Apache's rating to prevalence is this briefing's inference.
Is the REST plugin flaw the mapper flaw?	No: separate bulletins, CVEs, weakness types and impacts. They share fixed releases.	Any interaction between them.
Do workarounds exist on end-of-life lines?	Yes, per bulletin. S2-075: use another mapper. S2-076: a bounded decimal converter. S2-077: no configuration-only fix, so cap request body size in the reverse proxy or container. S2-078: format dates before the message.	Whether anyone has tested them on 2.x beyond the authors, and whether a mapper inside a composite arrangement counts.
Is it unauthenticated?	Apache's CVE text for CVE-2026-104712 says unauthenticated. CISA's CVSS vector for CVE-2026-104711 records no privileges required.	Apache's own text for CVE-2026-104711 does not say.
Does Struts 6 with the allowlist on escape?	The bulletin attaches the allowlist condition to Struts 7 only.	Anything about 6.4 to 6.11 with the allowlist enabled.
Which vendor products embed affected Struts?	No primary source names a product.	Which products, and when their vendors will ship fixes. No vendor advisory naming Struts for these CVEs was found. That vendors are covered is not established.

Five comforting words, and what each one hides

A label can do the work of a control only if someone checks what it covers. Here five labels each sound like safety.

The friendly-name fallacy applied to CVE-2026-104711. The right-hand column is drawn from the primaries cited in this briefing.

The label	What it sounds like	What the record says
Apache	A trusted foundation will look after it	Volunteers support current lines. For an end-of-life line the project says it gives "no support at all", and it does not endorse commercial support.
Patched	A fix exists	A fix exists for 6.x and 7.x only. For 2.0.0 to 2.3.37 and 2.5.0 to 2.5.33 there is a workaround and no code fix, and the affected range runs to the last release of each line.
Framework	Our own code, so we would know	A library inside applications and, plausibly, inside vendor products you did not write (inference). Apache addresses its bulletins to "All Struts 2 developers and users". Whether you run it is an inventory question.
Internal application	Not reachable by an attacker	The bulletin conditions the flaw on configuration, not location. Reachability depends on your network, which Apache cannot see. The NCSC still sets a 14-day update window for internal software.
Moderate	Low priority	Apache's rating is about likely configurations. CISA's enrichment scores the same flaw 9.8, Critical. The two answer different questions.

The ratings for the one flaw show how far a label travels from the record. Apache's text rating is "Moderate" and carries no CVSS score. CISA's enrichment (the CISA-ADP container, which NVD names as the source) gives a CVSS 3.1 score of 9.8, Critical, with privileges required none and attack complexity low, and records the SSVC decision points as exploitation none, automatable yes and technical impact total. Amazon Linux lists it as Important at 8.1 and Red Hat shows a preliminary 8.1, both with attack complexity high. HeroDevs' page says Critical, and one news headline says Critical while its body repeats Apache's Moderate and Important. NVD has not scored CVE-2026-104711 itself, but it scored CVE-2026-104714 at 8.8, High, against Apache's Moderate. A SentinelOne database page repeats CISA's 9.8 and the word "unauthenticated", carries a disclaimer that it was generated using AI, shows an impact box that contradicts its own vector, and attaches the allowlist condition to 6.x. None of this means any one source is wrong. A CVSS score describes a flaw where the vulnerable configuration exists. Apache's rating reflects how likely that configuration is. The NCSC says plainly: "You shouldn't make decisions based purely on a single severity score, such as CVSS."

What CISA's catalogue says about Struts today, and what it does not say about these flaws

CISA's Known Exploited Vulnerabilities file, catalogue version 2026.10.08 released at 20:09 UTC on 8 October and read again at 20:49 BST on 12 October, holds 1,739 entries. On 8 October CISA added five older entries: an ISC BIND flaw (CVE-2015-5477), a ProFTPD flaw (CVE-2015-3306), an Apache Struts flaw (CVE-2016-3081), an ONLYOFFICE Docs flaw (CVE-2021-3199) and a Strapi flaw (CVE-2023-22894). Each has a due date of 11 October, three days after it was added (derived). That date has now passed by one day. Under CISA's directive BOD 26-04 such dates bind US federal civilian agencies; they are not a UK requirement.

The Struts entry, CVE-2016-3081, is described by CISA as a command injection that could allow remote code execution when Dynamic Method Invocation is enabled. Its NVD record was published on 26 April 2016, so CISA listed it 10 years 5 months after publication (derived: 3,817 days), and the versions NVD's description names, 2.3.19 to 2.3.28, sit inside the 2.3.x line that the project ended on 12 September 2019. CISA's entry gives the forensic triage field as Yes and the known ransomware use field as Unknown. By the product field the catalogue now holds nine Struts entries, 0.5 per cent of its entries (derived), one of them, CVE-2017-5638, flagged as used in ransomware campaigns.

That is a general statement about Struts, not a tie to the new flaws. A catalogue entry means CISA lists the flaw as known to be exploited, and says nothing about who, where or how often. What it does say is that old Struts flaws are still being used in 2026, and that a framework version being old is not the same as a framework version being ignored by attackers. It says nothing about CVE-2026-104711, which is not in the catalogue as of this read. Two cautions go with that. The NCSC notes that a catalogue only records exploitation that has already occurred. And the fix is public, as are the release notes describing the cause, and at least two secondary pages already print technical detail, so a change in the exploitation picture within days would be unsurprising (inference). The sources' silence is dated: it holds as of this read.

UK: Cyber Essentials, the NCSC, the ICO and the supply-chain contract

Cyber Essentials v3.3 (April 2026), as read from the requirements document, section 3, Security Update Management. All software on in-scope devices must be "licensed and supported"; must be "removed from devices when it becomes unsupported", or removed from scope by a defined sub-set that blocks all traffic to or from the internet; and must be updated, including vulnerability fixes, within 14 days of release where the vendor calls them critical or high risk, the CVSS v3 base score is 7 or above, or the vendor gives no level. The definitions say software includes libraries, and that licensed and supported software is software a vendor has committed to support by providing regular vulnerability fixes, with a future date at which they will stop. The vendor need not have created the software but must be able to modify it.

What this implies for an application on Struts 2.3.x or 2.5.x is this briefing's inference, not the document's wording. On its face the application sits on software its project no longer supports, so within scope it must be removed or kept wholly off the internet. Whether a commercial extended-support contract counts as a vendor "committed to support" is a question for the assessor. The document does not mention such arrangements. For 6.x and 7.x, the same document gives a date: 14 days from the 2 October release is Friday 16 October 2026, four days from this read (derived), if the update counts as high risk, which on the CVSS limb it does for three of the four CVEs (9.8, 7.5 and 8.8 on CISA's scores, derived). Struts 6.12.0 and 7.4.0 each fix issues of differing severity in a single release, and the document's caution says such an update falls under the 14 days if any issue qualifies. Two limits: the document says bespoke and custom components of web applications are out of scope by default, and it does not say how a third-party library inside a bespoke application is treated; and for a vendor's product the clock plausibly starts from the vendor's own update, not Apache's (inference).

The update clocks in the UK sources, counted from the 2 October 2026 release of Struts 6.12.0 and 7.4.0. Dates are derived; the US federal date is for a different flaw and is shown for contrast.

Clock	Source	Ends	Status on 12 October
5 days, internet-facing services and software	NCSC vulnerability management guidance, best-practice timescales	Wednesday 7 October	Passed 5 days ago
7 days, operating system and applications	NCSC, same table	Friday 9 October	Passed 3 days ago
14 days, in-scope software	Cyber Essentials v3.3	Friday 16 October	4 days left
3 days after listing, a different flaw	CISA KEV due date for CVE-2016-3081, US federal agencies	Sunday 11 October	Passed 1 day ago

NCSC on obsolete software. Its guidance, last reviewed on 13 May 2025, says that all software eventually becomes out of date and that "The only fully effective way to mitigate this risk is to stop using the obsolete product." For those who cannot, it advises limiting what can reach the product, removing unneeded services, treating it as untrusted, zoning the network and improving monitoring. Its vulnerability-management guidance (reviewed 1 May 2026) says to categorise obsolete and extended-support products during asset discovery, and that the decision not to update is a senior-level risk decision that should be recorded and owned by the business, not the security team.

ICO and UK GDPR. If a Struts flaw is used to take personal data, Article 33, as shown on legislation.gov.uk, requires the controller to notify the regulator "without undue delay and, where feasible, not later than 72 hours after having become aware", and a processor to notify the controller without undue delay. The text now names "the Commission" after amendments in force from 30 September 2026; the ICO's own breach page says to notify "us" within 72 hours. Article 32 asks for appropriate technical and organisational measures, taking account of the state of the art. Nothing read links these CVEs to any breach. That an unsupported component is relevant to "appropriate" is an inference, not a finding by any regulator that this briefing has read.

The supplier contract. Struts is often a component rather than a product, so the practical question is whether your suppliers know they ship it. The Software Security Code of Practice (published 7 May 2025, updated 15 January 2026, voluntary) expects vendors to understand the composition of their software and the risks of third-party components (principle 1.2), to tell customers what level of support is provided (4.1), and to give at least a year's notice before support ends (4.2). Its implementation guidance suggests a software bill of materials as one format for the inventory and says a vendor should be able to share that inventory with customers. The NCSC's active-exploitation guidance says the rapid-response process must be reflected in supplier contracts so that critical suppliers are contractually liable to mitigate quickly. So ask, in writing, for the SBOM or equivalent, the Struts version line and mapper setting in each product, and the date each supplier will ship a fix. Asking is the inference; the guidance supports it without requiring it. The same support-end question arises elsewhere: see the briefings on Atlassian's fixed builds and their support dates and on the French supermarket refrigeration attack and end-of-life units.

What to do, in the order worth doing it

The question that exposes the gap

A flaw with a Moderate label, a trusted foundation's name and a fixed version looks like a Tuesday task. For half of the lines it affects, the fixed version does not exist, and the lines have been unsupported for between about two and a half and seven years.

So the question is not whether you can apply the update. It is this: if the Struts line your application runs on will never receive a fix, what date does it leave the internet, who signed for the days until then, and could you show that entry in your risk register today?

Key facts