OSSEVA FOR APACHE CAMEL
Apache Camel support after end of life: patched LTS lines, no forced Jakarta rewrite
Apache Camel support from OSSeva covers the lines the Camel project no longer fixes. Camel 3 ended in December 2024 and each Camel 4 LTS line gets about a year of fixes, so on 20 October 2026 only 4.18 (to 17 February 2027) and 4.22 (to 11 August 2027) are supported. Send your work email and an engineer replies within 1 business day.
| Who it is for | Integration teams with routes on Camel 2.25, 3.14, 3.20, 4.4 or 4.8, or on a Camel 4 LTS line that has expired |
|---|---|
| What you get | Signed, patched builds of the LTS line your routes were written against, bundled component dependencies included. Assure adds a route inventory, a costed path to a supported LTS and 24/7 reactive support. |
| How it is priced | Per application estate, not per route or component. Ask for a quote. |
| What happens next | You send your work email, we confirm your version and components, and you get a coverage plan. |
Reply within 1 business day · No commitment · or book a 15-minute call
Last reviewed
Trusted globally by enterprises
Camel LTS end-of-life dates, checked 20 October 2026
These are the Camel lines OSSeva covers and the last Camel 3 line, with the end-of-life dates endoflife.date gives for them.
| Line | End of life | Status on 20 October 2026 |
|---|---|---|
| 2.25 | 31 Jan 2022 | End of life |
| 3.14 LTS | 31 Dec 2022 | End of life |
| 3.20 LTS | 31 Dec 2023 | End of life |
| 3.22 LTS (last Camel 3) | 26 Dec 2024 | End of life |
| 4.4 LTS | 12 Feb 2025 | End of life |
| 4.8 LTS | 10 Sep 2025 | End of life |
| 4.18 LTS | 17 Feb 2027 | Supported |
| 4.22 LTS | 11 Aug 2027 | Supported |
Camel 4.10 LTS ended on 11 February 2026 and 4.14 LTS on 11 August 2026. If you run either, send the exact version with your email and we reply with the build details.
Camel end-of-life chart, every version →Camel 3 end of life →Camel 4.18 end of life →
Camel advisories published since each line ended
Counts are entries in OSSeva's CVE directory published after the line's end-of-life date whose affected range includes that line's final release (3.14.10, 3.20.9, 4.4.5, 4.8.9).
| Line | End of life | Entries since |
|---|---|---|
| 3.14 LTS | 31 Dec 2022 | 11 |
| 3.20 LTS | 31 Dec 2023 | 12 |
| 4.4 LTS | 12 Feb 2025 | 9 |
| 4.8 LTS | 10 Sep 2025 | 10 |
The nine entries that affect 4.4, and so also 3.20 and 4.8, all published since 23 February 2026
| CVE | Published | CVSS | Affected range (NVD) | Fixed upstream in |
|---|---|---|---|---|
| CVE-2026-25747 | 2026-02-23 | 8.8 | 3.0.0 before 4.10.9; 4.11.0 before 4.14.5; 4.15.0 before 4.18.0 | 4.10.9; 4.14.5; 4.18.0 |
| CVE-2026-27172 | 2026-04-27 | 8.8 | 3.0.0 before 4.14.6; 4.15.0 before 4.18.1 | 4.14.6; 4.18.1; 4.19.0 |
| CVE-2026-33454 | 2026-04-27 | 9.4 | 3.0.0 before 4.14.6; 4.15.0 before 4.18.1 | 4.14.6; 4.18.1; 4.19.0 |
| CVE-2026-40453 | 2026-04-27 | 9.9 | >=3.0.0 <4.14.6; >=4.15.0 <4.18.2; 4.19.0 | See advisory |
| CVE-2026-40473 | 2026-04-27 | 8.8 | 3.0.0 before 4.14.6; 4.15.0 before 4.18.2; 4.19.0 before 4.20.0 | 4.14.6; 4.18.2; 4.20.0 |
| CVE-2026-40860 | 2026-04-27 | 9.8 | >=3.0.0 <4.14.7; >=4.15.0 <4.18.2; 4.19.0 | See advisory |
| CVE-2026-43866 | 2026-07-06 | 7.3 | 3.0.0 before 4.14.8; 4.15.0 before 4.18.3; 4.19.0 before 4.21.0 | 4.14.8; 4.18.3; 4.21.0 |
| CVE-2026-47323 | 2026-05-19 | 9.8 | 3.18.0 before 4.14.6; 4.15.0 before 4.18.2 | 4.14.6; 4.18.2; 4.19.0 |
| CVE-2026-59230 | 2026-08-24 | 6.5 | 2.17.0 before 4.14.9; 4.15.0 before 4.18.4; 4.19.0 before 4.22.0 | 4.14.9; 4.18.4; 4.22.0 |
CVE-2025-27636 and CVE-2025-29891 were fixed only on 3.22.4, 4.8.5 and 4.10.2, so a 3.20 estate has no fix for them. Confirm any entry at nvd.nist.gov.
Why now
The support window is one year, and it does not move
Camel's own download page states the policy plainly: LTS releases receive bug and security fixes for up to one year. 4.22.0 was released in August 2026 with end of life in August 2027; 4.18.4 was released in August 2026 with end of life in February 2027. Anything older gets nothing, and the archive page is where those releases go.
Camel 3 to 4 was a breaking migration, and Camel 2 to 3 was worse
Camel 4 moved to Jakarta EE namespaces, requiring every javax import across the route base to change, and raised the Java baseline. Camel 3 had already restructured the component modules. Each jump forces a coordinated change across every route, every custom processor and every test — which is why so many estates stopped at a version and stayed there.
Camel routes sit directly on untrusted input
Camel is the layer parsing the file drops, consuming the queues, calling the partner endpoints and unmarshalling the XML and JSON in between. Advisories in the marshalling components, the HTTP consumers and the expression languages are reachable from exactly the data Camel exists to ingest. It is not an internal-only component even when it is deployed as one.
Versions covered
All versions below receive active CVE patches from OSSeva. Version numbers in monospace are exact release identifiers.
| Version | Status | Active CVEs |
|---|---|---|
| 2.25.x(Long past upstream EOL — OSSeva patched) | EOL | Clean |
| 3.14.x LTS(Past upstream EOL — OSSeva patched) | EOL | Clean |
| 3.20.x LTS(Past upstream EOL — OSSeva patched) | EOL | Clean |
| 4.4.x LTS(Past upstream EOL — OSSeva patched) | EOL | Clean |
| 4.8.x LTS(Past upstream EOL — OSSeva patched) | EOL | Clean |
| 4.18.x LTS(Upstream EOL Feb 2027) | Extended | Clean |
| 4.22.x LTS(Upstream EOL Aug 2027) | Current | Clean |
Running a Apache Camel version or build not listed here?
What you get
Three tiers — pick the level of engagement that matches your team's operational needs and compliance requirements.
OSSeva Patch
CVE patches for the Camel LTS line your routes were written against.
- Security backports for Camel 2.x, 3.x and expired 4.x LTS lines
- Component-level patching across the modules you actually use
- Marshalling and expression-language advisory priority coverage
- Maven / Gradle / Spring Boot starter delivery
- Signed artifacts (GPG)
- Route inventory and migration assessment
- 24/7 managed operations
OSSeva Assure
Patch plus a route inventory and a costed path to a supported LTS.
- Everything in Patch
- Full route and component inventory across the estate
- Jakarta namespace migration impact assessment
- Endpoint exposure and credential handling audit
- SOC 2 / HIPAA attestation package
- Staged upgrade plan to a supported LTS line
- 24/7 reactive support
OSSeva Operate
Full MSP: 24/7 route monitoring, 15-min SLA, named integration engineers.
- Everything in Assure
- 24/7 route throughput, error and dead-letter monitoring
- 15-minute P1 incident response SLA
- Named senior Camel integration engineer
- Error handler and redelivery policy management
- Migration execution to a supported LTS line
- Quarterly route and capacity reviews
All tiers priced per cluster/application — not per core.
How it installs
OSSeva artifacts arrive via your existing package infrastructure. Pull the patched version the same way you pull upstream today — just from the OSSeva registry.
# Resolved Camel version across a multi-module build
mvn dependency:tree -Dincludes=org.apache.camel | \
grep -oE 'camel-[a-z0-9-]+:jar:[0-9.]+' | sort -u
# Anything below 4.18 receives no upstream security fixes.
# At runtime, via the Camel management endpoint
curl -s http://localhost:8080/actuator/camelroutes | jq 'length'<dependencyManagement>
<dependencies>
<dependency>
<groupId>io.osseva.camel</groupId>
<artifactId>camel-bom</artifactId>
<version>3.20.9-osseva-1</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<!-- Component coordinates are unchanged; only the BOM moves. -->
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-jackson</artifactId>
</dependency>Migrate from Expired Camel LTS lines and Camel 2.x / 3.x
OSSeva backports security fixes onto the LTS line your routes were written and tested against, so no javax-to-jakarta rewrite is forced by a security deadline. When migration does happen it is scoped from a real route inventory rather than a guess at how many components are in play.
Pricing model
OSSeva for Apache Camel is priced per application estate — not per route, component or message.
Who provides Apache Camel support after end of life?
Third parties, since the Camel project stops fixing a line when it leaves the supported LTS list. OSSeva supports Apache Camel today. Patch ships signed builds with backported CVE fixes for the 2.25, 3.14, 3.20, 4.4 and 4.8 lines. Assure adds compliance attestation and VEX statements. Operate adds 24/7 managed operations with a 15-minute P1 response.
How long does Apache Camel support an LTS release?
Up to one year. Camel's download page says LTS versions receive bug and security fixes for up to one year, and it lists two supported LTS lines: 4.22.1, end of life August 2027, and 4.18.5, end of life February 2027. Releases outside those lines receive no further fixes from the project.
Is Camel 3 still supported?
No. The Camel team announced on 23 December 2024 that Camel 3 was end of life at the end of 2024. The final 3.x release, 3.22.4, shipped on 9 March 2025, and its release notes give 31 December 2024 as the end-of-life date. Every Camel 3 LTS line, including 3.14 and 3.20, is past upstream end of life. OSSeva ships patched builds for those lines today.
What makes the Camel 3 to 4 upgrade so expensive?
Camel 4 moved to the Jakarta EE namespaces, so every javax import across routes, custom processors, type converters and tests has to change, and the Java baseline moved to 17. For an estate with hundreds of routes that is a coordinated change with a full integration regression cycle behind it, not a dependency bump.
Do you patch the individual Camel components or just the core?
The components, which is where the advisories actually land. Camel ships over 300 components and the risk concentrates in the marshalling and transport ones — Jackson, JAXB, HTTP, FTP, and the expression languages. OSSeva patches the component set you use, including the third-party libraries those components bundle.
We run Camel on Spring Boot. Does that change anything?
It adds a second version constraint. Camel Spring Boot is released in lockstep with Camel core and pins a compatible Spring Boot line, so a Camel upgrade usually drags a Spring Boot upgrade with it. OSSeva covers both sides of that pairing, and the Spring Boot coverage is handled under the same engagement.
Does OSSeva support current Camel versions or only end-of-life ones?
Both. The versions list covers Camel 2.25, 3.14, 3.20, 4.4, 4.8, 4.18 and 4.22 with patches active on every line, including the two LTS lines upstream still supports, 4.18 and 4.22. Patch ships backports for 2.x, 3.x and expired 4.x LTS lines, and Assure plans the staged upgrade to a supported LTS. OSSeva Operate patches Critical CVEs (CVSS ≥ 9.0) within 48 hours and High within 7 days.
How is OSSeva Camel support priced?
OSSeva for Apache Camel is priced per application estate, not per route, component or message. Patch covers signed patched builds, Assure adds the route inventory and staged upgrade plan with 24/7 reactive support, and Operate adds proactive 24/7 monitoring and end-to-end managed operations with a 15-minute P1 SLA. Book a discovery call for a quote.
Get a quote
Ready to get Apache Camel patched and supported?
Tell us your Apache Camel versions and an engineer replies within 1 business day with coverage and a price. Prefer a call? It takes 15 minutes.
Prefer to talk or read more first?