lukaszlenart opened a new pull request, #1852: URL: https://github.com/apache/struts/pull/1852
`THREAT_MODEL.md` is a v0 draft written in June, before the five bulletins published on **2026-08-14**. Read against them it does not describe the framework the PMC has actually been defending: **three of the five would have been closed as non-findings**, and the remaining two had no security property to violate. | Bulletin | Class | v0 disposition | | --- | --- | --- | | S2-070 (CVE-2026-73631) | shared parse state, JSON plugin | no §8 property — `MODEL-GAP` | | S2-071 (CVE-2026-73632) | shared serialization state, JSON plugin | no §8 property — `MODEL-GAP` | | S2-072 (CVE-2026-73633) | unbounded JSON body read | §11a "I streamed a huge body" | | S2-073 (CVE-2026-73634) | unbounded CSP report read | §11a, same bullet | | S2-074 (CVE-2026-73635) | unbounded localized-text cache growth | §3 super-linear-only rule | ## The substantive error: the DoS boundary `SECURITY.md` says two separate things — a disclaimer about generic attacks against *any* networked server, and a design philosophy about avoiding consumption non-linear in the size of inputs. The v0 model fused them into a triage threshold and excluded everything linear. All three DoS bulletins are linear; all three carry CVEs. S2-074's reporter flagged the linear growth himself, and we issued a CVE anyway. The line is restated as **boundedness, not curve shape** across §3/§9/§11a, and `SECURITY.md` gets the matching paragraph so the model is no longer paraphrasing that document into a rule it does not state. That is the one change here outside the threat model, and it is the reason for it. ## Two new §8 properties - **§8.6 per-request state isolation** — from S2-070/071. Note S2-070's impact line includes *bypass of a configured limit*: one defect voiding another control, not merely leaking. - **§8.7 bounded consumption of request-derived input** — from S2-072/073/074. Covers bounded body reads, bounded framework-managed state, and the S2-072 wrinkle that an advertised limit must bound the read it names. §7 gains the two client capabilities these imply (concurrency, repetition); §6 gains the request body as its own surface, plus a note that a request value used as a **cache key** is an input class of its own. ## Optional feature ≠ non-default configuration Four of the five bulletins concern surfaces that are inert until an application enables them (JSON body population, `enableSMD`, a mapped CSP-report endpoint). As written, §13 let a triager close every one as `OUT-OF-MODEL: non-default-config`. §2 and §13 now reserve that disposition for settings the project documents as *unsafe*. ## Also - §5a records the **7.3.0 / 6.11.0** hardening — `struts.i18n.cacheType`, `struts.i18n.cacheMaxSize`, `struts.csp.report.maxSize`, and the opt-in `struts.locale.validateRequestLocale` — as a second envelope change after 7.0. All four verified against `default.properties` on `main`. - **Q-dos** and **Q-plugins** move to answered: the PMC settled both by issuing CVEs, so only the wording is still open. **Q-concurrency**, **Q-bounds** and **Q-optional** replace them. - §12 gains the trigger that would have caught this earlier: *a published bulletin whose class is not already a §8 property* — a release-time check rather than a next-report-triage one. - §16 maps each bulletin to the sections it drives. - §1 and §9 stop implying every real finding is OGNL-shaped. OGNL is still the highest-severity class; it is no longer the highest-volume one. ## Notes for review No ticket — process-doc change, per the `SECURITY.md`/`AGENTS.md`/`THREAT_MODEL.md` convention. All five bulletins were confirmed **unrestricted on the cwiki** before being cited. The document stays a **DRAFT**: the corrections are drawn from the published bulletins, not from a PMC position on the model itself, and the §14 questions are still open. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
