This is an automated email from the ASF dual-hosted git repository. oscerd pushed a commit to branch add-cve-2026-88900 in repository https://gitbox.apache.org/repos/asf/camel-website.git
commit 5e050927fc957de8a12f780a4829482954efb986 Author: Andrea Cosentino <[email protected]> AuthorDate: Mon Oct 19 10:36:07 2026 +0200 chore: add the security advisory for CVE-2026-88900 (camel-jgroups) The camel-jgroups consumer set the exchange body from Message.getObject(), which Java-deserializes cluster messages with no ObjectInputFilter, on a default channel without authentication. Fixed in 4.18.5, 4.22.1 and 4.23.0 by CAMEL-24676, with the 4.23.0 start-up guard of CAMEL-25223. All three releases are on Maven Central. Co-Authored-By: Claude Opus 5.5 <[email protected]> Signed-off-by: Andrea Cosentino <[email protected]> --- content/security/CVE-2026-88900.md | 27 ++++++++++++++++++++++ content/security/CVE-2026-88900.txt.asc | 41 +++++++++++++++++++++++++++++++++ 2 files changed, 68 insertions(+) diff --git a/content/security/CVE-2026-88900.md b/content/security/CVE-2026-88900.md new file mode 100644 index 00000000..51bb4961 --- /dev/null +++ b/content/security/CVE-2026-88900.md @@ -0,0 +1,27 @@ +--- +title: "Apache Camel Security Advisory - CVE-2026-88900" +date: 2026-10-19T10:00:00+02:00 +url: /security/CVE-2026-88900.html +draft: false +type: security-advisory +cve: CVE-2026-88900 +severity: HIGH +summary: "Camel-JGroups: Unsafe Java deserialization of cluster messages in the JGroups consumer can lead to remote code execution" +description: "JGroupsEndpoint.createExchange(Message), which CamelJGroupsReceiver calls for every message the jgroups consumer receives before the exchange is routed, set the exchange body from org.jgroups.Message.getObject(). For an ObjectMessage, which is the message type the Camel jgroups producer sends, JGroups Java-deserializes the payload through an ObjectInputStream on its own receive thread as the message arrives, and getObject() returns the resulting object. No java.io.ObjectInp [...] +mitigation: "Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.1. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier, and the 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines, reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a [...] +credit: "This issue was discovered by h1ei1" +affected: "From 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1." +fixed: 4.18.5, 4.22.1 and 4.23.0 +--- + +The JIRA tickets: https://issues.apache.org/jira/browse/CAMEL-24676 and https://issues.apache.org/jira/browse/CAMEL-25223 refer to the commits that resolved the issue, and have more details. + +The fix was merged on main in https://github.com/apache/camel/pull/26267 (commit 0ef94ee8feabf56a5c595c07b2c60f64a73ba14e), and backported to camel-4.22.x in https://github.com/apache/camel/pull/26281 (commit da07367d1b6e2bb00ddb6afa5cfa08a6c0c0bd0f) and to camel-4.18.x in https://github.com/apache/camel/pull/26283 (commit f988494d01145473551ca75fc11cda3e5cb49f2d). The follow-up hardening of CAMEL-25223 was merged on main in https://github.com/apache/camel/pull/27205 (commit d30328a49596 [...] + +CAMEL-24676 makes the consumer check the class of the body returned by Message.getObject() before the exchange is routed, through a new deserializationFilter option labelled consumer and security that takes a pattern in the jdk.serialFilter syntax. When the option is not set, the JVM-wide jdk.serialFilter is honoured if present, and otherwise a default allow-list is applied that permits standard Java and Apache Camel types, denies java.net and rejects everything else. A refused message i [...] + +Both changes alter default behaviour and are documented in the upgrade guides: routes that exchange their own classes over the cluster must widen the class check through the deserializationFilter option, and on 4.23.0 every consumer must either have one of the controls above configured or set acceptAllObjects=true. The start-up guard is a breaking change for existing consumers on the default channel and was therefore not backported to camel-4.22.x and camel-4.18.x. The JGroups versions t [...] + +The unfiltered call to Message.getObject() has been part of the consumer since camel-jgroups was first released in 2.13.0, so every release line before the fixed versions carries it. The releases from 4.0.0 through the 4.14.x line, and the 4.15.x to 4.17.x and 4.19.x to 4.21.x lines, reached end of life before this issue was resolved, and no fix will be issued for them. The camel-jgroups-raft component is not affected: it hands byte arrays to the Raft handle and does not deserialize Java [...] + +This issue belongs to the same family as CVE-2026-40860, which concerned JMS ObjectMessage payloads deserialized when camel-jms read the message body: in both cases the deserialization is performed by the messaging library when Camel asks for the body, rather than through an ObjectInputStream that Camel constructs itself. It is classified as CWE-502 (Deserialization of Untrusted Data). diff --git a/content/security/CVE-2026-88900.txt.asc b/content/security/CVE-2026-88900.txt.asc new file mode 100644 index 00000000..e382c710 --- /dev/null +++ b/content/security/CVE-2026-88900.txt.asc @@ -0,0 +1,41 @@ +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA512 + +- --- +title: "Apache Camel Security Advisory - CVE-2026-88900" +date: 2026-10-19T10:00:00+02:00 +url: /security/CVE-2026-88900.html +draft: false +type: security-advisory +cve: CVE-2026-88900 +severity: HIGH +summary: "Camel-JGroups: Unsafe Java deserialization of cluster messages in the JGroups consumer can lead to remote code execution" +description: "JGroupsEndpoint.createExchange(Message), which CamelJGroupsReceiver calls for every message the jgroups consumer receives before the exchange is routed, set the exchange body from org.jgroups.Message.getObject(). For an ObjectMessage, which is the message type the Camel jgroups producer sends, JGroups Java-deserializes the payload through an ObjectInputStream on its own receive thread as the message arrives, and getObject() returns the resulting object. No java.io.ObjectInp [...] +mitigation: "Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.1. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier, and the 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines, reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a [...] +credit: "This issue was discovered by h1ei1" +affected: "From 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1." +fixed: 4.18.5, 4.22.1 and 4.23.0 +- --- + +The JIRA tickets: https://issues.apache.org/jira/browse/CAMEL-24676 and https://issues.apache.org/jira/browse/CAMEL-25223 refer to the commits that resolved the issue, and have more details. + +The fix was merged on main in https://github.com/apache/camel/pull/26267 (commit 0ef94ee8feabf56a5c595c07b2c60f64a73ba14e), and backported to camel-4.22.x in https://github.com/apache/camel/pull/26281 (commit da07367d1b6e2bb00ddb6afa5cfa08a6c0c0bd0f) and to camel-4.18.x in https://github.com/apache/camel/pull/26283 (commit f988494d01145473551ca75fc11cda3e5cb49f2d). The follow-up hardening of CAMEL-25223 was merged on main in https://github.com/apache/camel/pull/27205 (commit d30328a49596 [...] + +CAMEL-24676 makes the consumer check the class of the body returned by Message.getObject() before the exchange is routed, through a new deserializationFilter option labelled consumer and security that takes a pattern in the jdk.serialFilter syntax. When the option is not set, the JVM-wide jdk.serialFilter is honoured if present, and otherwise a default allow-list is applied that permits standard Java and Apache Camel types, denies java.net and rejects everything else. A refused message i [...] + +Both changes alter default behaviour and are documented in the upgrade guides: routes that exchange their own classes over the cluster must widen the class check through the deserializationFilter option, and on 4.23.0 every consumer must either have one of the controls above configured or set acceptAllObjects=true. The start-up guard is a breaking change for existing consumers on the default channel and was therefore not backported to camel-4.22.x and camel-4.18.x. The JGroups versions t [...] + +The unfiltered call to Message.getObject() has been part of the consumer since camel-jgroups was first released in 2.13.0, so every release line before the fixed versions carries it. The releases from 4.0.0 through the 4.14.x line, and the 4.15.x to 4.17.x and 4.19.x to 4.21.x lines, reached end of life before this issue was resolved, and no fix will be issued for them. The camel-jgroups-raft component is not affected: it hands byte arrays to the Raft handle and does not deserialize Java [...] + +This issue belongs to the same family as CVE-2026-40860, which concerned JMS ObjectMessage payloads deserialized when camel-jms read the message body: in both cases the deserialization is performed by the messaging library when Camel asks for the body, rather than through an ObjectInputStream that Camel constructs itself. It is classified as CWE-502 (Deserialization of Untrusted Data). +-----BEGIN PGP SIGNATURE----- + +iQEzBAEBCgAdFiEEJ2Y0ButtuvUpHyYV406fOAL/QQAFAmrV1jgACgkQ406fOAL/ +QQAieQf9G2BgbQx8xEJIFrob8nN4Dg0uZTokCTWbcefeSYZKpnbPjFDt3H836dUx +K4AvZZ374VjFL1eIoINZnS24CSABaw3EK5fyn+/pSxvdIP6pDAyE8exVAsvR2snB +qcj+Z449hIy4xJ96jdcNlMcnAYy8CuW/hp+Gm3PZPSbmzZj7MPluLXhLh67i5Q5W +qphDSCYNKqlbgZD9zvkOXvC0yh+rFSTUq8DzAZNwMZAo/vbJBGV5R1tCYkfcFE9J +6L68N65OAbVzF2O6hQWsgeTMply2VvI1CpelnGs1gYHFRdvfvJkc2RR+N60bNPlz +4E7X1PeKwO21dDykCAOQVxyER9V8JA== +=9Fxm +-----END PGP SIGNATURE-----
