OSSEVA FOR APACHE CAMEL
Two supported lines. Twelve months each. Hundreds of routes.
Apache Camel maintains only its two most recent LTS releases, each for roughly a year. As of now that is the 4.22 line, end of life August 2027, and the 4.18 line, end of life February 2027. Every Camel 2.x and 3.x deployment, and every expired 4.x LTS, is running unpatched.
Last reviewed
Trusted globally by enterprises
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 |
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 managed operations
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. Contact for pricing →
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.
Frequently asked questions
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.4, 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.
Ready to get Apache Camel patched and supported?
Start with a 45-minute discovery call. We confirm your version coverage, scope the engagement, and have you onboarded within your first quarter.