docs(blog): Built to Patch Fast: Apache Camel's Security Response in 2026

[oscerd]

Adds a blog post about how the July security batch was handled, aimed at readers who saw "32 CVEs in one release" and want to know what that actually means.

Rather than walking the list, the post is about the response process:

• Release cadence. A table of every 2026 release that carried security fixes. The clustering is the point: five releases across three lines in nine days in April, three in four days in July.
• The LTS lines got more, not less. 4.18.3 shipped 34 advisories and 4.14.8 shipped 27, against 4.21.0's 32. The extras are findings whose main-line fix landed in an earlier minor.
• Incomplete fixes. Both cases in this batch (CVE-2026-40048 → CVE-2026-46590, CVE-2026-40860 → CVE-2026-43866) were corrected in the next release on every line, each with its own CVE and advisory. Also covers CVE-2026-42527, the deserialization filter our own hardening series broke.
• Why 32 at once. One report gets read as a pattern and swept across the component set, which is why 22 of the 32 are the same broken header boundary in 22 components, and why 4.21.0 also renamed the header constants across 30+ components so the filter covers them by construction.
• Upgrade matrix, including the one finding (CVE-2026-49042, camel-langchain4j-tools) that affects 4.14.x but was not backported because the fix changes behaviour, with the advisory workaround spelled out.
• Credits for the six external researchers, and a reference table of all 32.

Data provenance

Every number is derived from files in this repo and cross-checked before committing:

Claim	Source
4.21.0 fixed 32	32 advisories in content/security/ with 4.21.0 in fixed:
4.18.3 fixed 34, 4.14.8 fixed 27	same query per version
26 of the 32 backported to 4.14.8	intersection of the 4.21.0 set with 4.14.8
5 HIGH / 26 MEDIUM / 1 LOW	severity: across the 32
Yu Bao credited on 24	credit: across the 32
All release dates	date: in the RELEASE-* announcement posts

All 32 advisories in the batch appear in the reference table, and every CVE link resolves to an existing file under content/security/.

Note on the Trust page

While checking these numbers I found that content/trust/_index.md says the 4.14.8, 4.18.3 and 4.21.0 releases "fixed and disclosed 32 vulnerabilities between them". Read strictly that is 34, since two findings shipped in 4.18.3 and 4.14.8 with an earlier main-line fix. It under-counts rather than overstates, but it does not say what it computes, and it now reads inconsistently against this post. Fixed separately in #1712.

Not verified

I could not render the page locally: no Hugo binary and no node_modules in the working copy. The post uses only Markdown already present in sibling posts, with no shortcodes or raw HTML.

🤖 Generated with Claude Code

[oscerd]

Pushed c2b2984, which links the public reproducers.

Each finding got a runnable proof of concept before the fix was written, so the post now has a section on why we build them and what is in each one, plus a PoC column in the reference table linking the repository for each CVE.

Reproducers exist for 31 of the 32. The exception is CVE-2026-56140, the camel-aws2-sns hardening change, which has nothing to reproduce because the component is producer-only. That is also what backs the claim made a section earlier that it has no reachable path: we tried to build one and could not.

Fifteen of the repositories carry both a Camel Spring Boot and a Camel Quarkus variant, since a few of these behave differently depending on which runtime hosts the consumer.

All 31 links were verified against the GitHub API as existing and public before pushing.