CVE-2026-49099
Apache Camel Salesforce: le costanti di intestazione Exchange senza prefisso Camel bypassano il filtro delle intestazioni HTTP, consentendo a un client HTTP di influenzare il comportamento interno
- Pubblicato
- 6 lug 2026
- Aggiornato
- 7 lug 2026
- Assegnazione CNA
- apache
- Evidenza osservata
- 6 ago 2026
CVSS primario
nvd · CVSS 3.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:NBasso · prossimi 30 giorni
- Percentile
- 43,0%
- Data del modello
- 21 set 2026
L'EPSS è una stima statistica, non una certezza o una misura di impatto. Combinalo con CVSS, stato KEV, esposizione e ambiente.
Riepilogo
Neutralizzazione impropria di elementi speciali nell'output utilizzato da un componente a valle ('Injection'), bypass dell'autorizzazione tramite vulnerabilità della chiave controllata dall'utente nel componente Salesforce di Apache Camel. Il produttore camel-salesforce risolve i suoi parametri operativi - la query SOQL, la ricerca SOSL, il nome e l'id dell'SObject di destinazione, l'URL e il metodo Apex REST, e i parametri di query Apex - dalle intestazioni dei messaggi Exchange, leggendo l'intestazione in preferenza al valore configurato sull'endpoint (AbstractSalesforceProcessor.getParameter() legge prima l'intestazione e usa la configurazione dell'endpoint solo come fallback). Le costanti delle intestazioni di controllo in SalesforceEndpointConfig (ad esempio SOBJECT_QUERY = sObjectQuery, SOBJECT_SEARCH = sObjectSearch, SOBJECT_NAME = sObjectName, SOBJECT_ID = sObjectId, APEX_URL = apexUrl, APEX_METHOD = apexMethod, e il prefisso apexQueryParam.) usavano valori semplici, senza prefisso Camel. Poiché questi nomi non iniziano con il prefisso Camel / camel, HttpHeaderFilterStrategy - che blocca solo il namespace delle intestazioni Camel sul confine HTTP - li lasciava passare da una richiesta HTTP in entrata direttamente nell'Exchange. In una route che collega un consumatore HTTP (ad esempio platform-http) a un produttore salesforce:, qualsiasi client HTTP poteva quindi impostare queste intestazioni e sovrascrivere ciò che la route intendeva fare - fornendo la propria query SOQL o ricerca SOSL per leggere dati da qualsiasi SObject a cui l'utente Salesforce connesso può accedere, sovrascrivendo il nome e l'id dell'SObject di destinazione per le operazioni CRUD, o reindirizzando una chiamata Apex REST a un endpoint e metodo HTTP diversi (inclusi metodi distruttivi) con parametri di query iniettati. Tutte queste operazioni vengono eseguite con i pieni permessi dell'utente Salesforce connesso (di integrazione), che sono tipicamente ampi. Non sono richieste credenziali all'attaccante quando il consumatore di collegamento non è autenticato. Questo problema riguarda Apache Camel: dalla 4.0.0 prima della 4.14.8, dalla 4.15.0 prima della 4.18.3, dalla 4.19.0 prima della 4.21.0. Si consiglia agli utenti di aggiornare alla versione 4.21.0, che risolve il problema. Se gli utenti sono sul flusso di release LTS 4.14.x, si consiglia di aggiornare alla 4.14.8. Se gli utenti sono sul flusso di release 4.18.x, si consiglia di aggiornare alla 4.18.3. Dopo l'aggiornamento, le route che impostano i parametri operativi di Salesforce tramite i nomi di intestazione grezzi devono usare i nomi CamelSalesforce* (ad esempio CamelSalesforceSObjectQuery e CamelSalesforceApexUrl) invece dei vecchi valori sObject* / apex*; l'ortografia delle opzioni dell'endpoint è invariata. Per le distribuzioni che non possono aggiornare immediatamente, rimuovere le intestazioni di controllo di Salesforce da qualsiasi ingresso non attendibile prima del produttore salesforce: (ad esempio removeHeaders('sObject*') e removeHeaders('apex*') all'inizio della route), e impostare i parametri di query, SObject e Apex da una fonte attendibile.
Utilizzo responsabile
Utilizza le informazioni sulla vulnerabilità solo sui sistemi che possiedi o che sei autorizzato a testare. Kitploit si collega ai metadati della ricerca pubblica e non memorizza codici exploit o payload dannosi.