CVE-2026-66907

{
  "id": "CVE-2026-66907",
  "sourceIdentifier": "[email protected]",
  "published": "2026-08-24T17:18:06.330",
  "lastModified": "2026-10-24T16:10:00.153",
  "vulnStatus": "Analyzed",
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Relative path traversal vulnerability in Apache Camel Google Storage component.\n\n\n\nThis issue affects Apache Camel: from 4.0.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0.\n\n\n\nThe camel-google-storage consumer downloads Google Cloud Storage objects to the local filesystem when the downloadFileName option is set. That option is documented as a folder or a filename, and when its value contains no expression token the consumer builds the local destination by appending the object name to it: evaluateFileExpression sets the Exchange file-name header to the remote object name and evaluates downloadFileName + \"/${file:name}\". The ${file:name} token returns the file-name header verbatim, unlike ${file:onlyname}, which applies FileUtil.stripPath to it. The resulting string was passed directly to new File(result) and blob.downloadTo(file.toPath()) with no lexical normalization and no check that the destination stayed inside the configured directory. The object name is not route-controlled data: the consumer lists the bucket, iterates every returned blob and creates one exchange per object from blob.getBlobId().getName() verbatim, and the filter option that could restrict those names is not applied at all unless it has been explicitly set. Google Cloud Storage object names are opaque UTF-8 keys that the service stores and lists exactly as written, with no server-side canonicalization, and a forward slash is only a display convention for pseudo-directories, so a key containing parent-directory segments survives round-tripping intact. An object name containing such segments therefore resolved to a location outside the configured downloadFileName directory, letting anyone able to influence the names present in the consumed bucket cause Camel to create or overwrite a file at a location of their choosing, with the privileges of the Camel process. Depending on what the process can write to, overwriting a file outside the download directory can escalate beyond the loss of integrity of that file. The downloadFileName option is an ordinary consumer parameter and carries no security marker, so nothing signalled to users that its value was not being enforced as a containment boundary. The defect is consumer-only; the producer has no download-to-file sink. Camel's other file-download consumers - camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files and the Azure Storage download paths - already constrained their local downloads to the configured directory using a path-segment boundary check; camel-google-storage was the remaining object-store download sink not covered by that work.\n\n\n\nUsers are recommended to upgrade to version 4.22.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.9. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.4. For deployments that cannot upgrade immediately, set the filter option to a regular expression that accepts only simple single-segment object names, so that any name carrying a path separator or a parent-directory segment is excluded before an exchange is created; note that no filtering whatsoever is applied when the option is left unset, and that the expression is matched against the whole object name. Alternatively, give downloadFileName an explicit expression that does not carry the remote path through, for example one built on ${file:onlyname} rather than the implicit ${file:name}, keeping in mind that a downloadFileName containing an expression is treated as route-author-controlled and is not covered by the containment check added in the fix. As defence in depth, treat the object names in any externally writable bucket as untrusted input and do not derive local filesystem paths from them."
    },
    {
      "lang": "es",
      "value": "Vulnerabilidad de salto de ruta relativo en el componente Google Storage de Apache Camel.\n\nEste problema afecta a Apache Camel: desde 4.0.0 antes de 4.14.9, desde 4.15.0 antes de 4.18.4, desde 4.19.0 antes de 4.22.0.\n\nEl consumidor camel-google-storage descarga objetos de Google Cloud Storage al sistema de archivos local cuando la opción downloadFileName está configurada. Esa opción está documentada como una carpeta o un nombre de archivo, y cuando su valor no contiene ningún token de expresión, el consumidor construye el destino local añadiéndole el nombre del objeto: evaluateFileExpression establece el encabezado file-name del Exchange al nombre del objeto remoto y evalúa downloadFileName + '/${file:name}'. El token ${file:name} devuelve el encabezado file-name textualmente, a diferencia de ${file:onlyname}, que le aplica FileUtil.stripPath. La cadena resultante se pasó directamente a new File(result) y blob.downloadTo(file.toPath()) sin normalización léxica y sin ninguna comprobación de que el destino permaneciera dentro del directorio configurado. El nombre del objeto no son datos controlados por la ruta: el consumidor lista el bucket, itera cada blob devuelto y crea un intercambio por objeto a partir de blob.getBlobId().getName() textualmente, y la opción de filtro que podría restringir esos nombres no se aplica en absoluto a menos que se haya configurado explícitamente. Los nombres de objetos de Google Cloud Storage son claves UTF-8 opacas que el servicio almacena y lista exactamente como están escritos, sin canonicalización del lado del servidor, y una barra inclinada es solo una convención de visualización para pseudodirectorios, por lo que una clave que contiene segmentos de directorio padre sobrevive al viaje de ida y vuelta intacta. Un nombre de objeto que contiene tales segmentos, por lo tanto, se resolvió en una ubicación fuera del directorio downloadFileName configurado, permitiendo que cualquiera que pueda influir en los nombres presentes en el bucket consumido haga que Camel cree o sobrescriba un archivo en una ubicación de su elección, con los privilegios del proceso de Camel. Dependiendo de dónde pueda escribir el proceso, sobrescribir un archivo fuera del directorio de descarga puede escalar más allá de la pérdida de integridad de ese archivo. La opción downloadFileName es un parámetro de consumidor ordinario y no lleva ningún marcador de seguridad, por lo que nada indicaba a los usuarios que su valor no se estaba aplicando como un límite de contención. El defecto es solo del consumidor; el productor no tiene un sumidero de descarga a archivo. Otros consumidores de descarga de archivos de Camel - camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files y las rutas de descarga de Azure Storage - ya restringían sus descargas locales al directorio configurado utilizando una comprobación de límite de segmento de ruta; camel-google-storage era el sumidero de descarga de almacén de objetos restante no cubierto por ese trabajo.\n\nSe recomienda a los usuarios actualizar a la versión 4.22.0, que corrige el problema. Si los usuarios están en la rama de versiones LTS 4.14.x, se les sugiere actualizar a 4.14.9. Si los usuarios están en la rama de versiones 4.18.x, se les sugiere actualizar a 4.18.4. Para implementaciones que no pueden actualizarse inmediatamente, configure la opción de filtro a una expresión regular que acepte solo nombres de objetos simples de un solo segmento, de modo que cualquier nombre que contenga un separador de ruta o un segmento de directorio padre sea excluido antes de que se cree un intercambio; tenga en cuenta que no se aplica ningún tipo de filtrado cuando la opción se deja sin configurar, y que la expresión se compara con el nombre completo del objeto. Alternativamente, asigne a downloadFileName una expresión explícita que no transmita la ruta remota, por ejemplo, una construida sobre ${file:onlyname} en lugar del implícito ${file:name}, teniendo en cuenta que un downloadFileName que contiene una expresión se trata como controlado por el autor --TRUNCADO--"
    }
  ],
  "affected": [
    {
      "source": "[email protected]",
      "affectedData": [
        {
          "vendor": "Apache Software Foundation",
          "product": "Apache Camel",
          "defaultStatus": "unaffected",
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "packageName": "org.apache.camel:camel-google-storage",
          "packageURL": "pkg:maven/org.apache.camel/camel-google-storage",
          "versions": [
            {
              "version": "4.0.0",
              "lessThan": "4.14.9",
              "versionType": "semver",
              "status": "affected"
            },
            {
              "version": "4.15.0",
              "lessThan": "4.18.4",
              "versionType": "semver",
              "status": "affected"
            },
            {
              "version": "4.19.0",
              "lessThan": "4.22.0",
              "versionType": "semver",
              "status": "affected"
            }
          ]
        }
      ]
    }
  ],
  "metrics": {
    "cvssMetricV31": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "type": "Secondary",
        "cvssData": {
          "version": "3.1",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
          "baseScore": 7.5,
          "baseSeverity": "HIGH",
          "attackVector": "NETWORK",
          "attackComplexity": "LOW",
          "privilegesRequired": "NONE",
          "userInteraction": "NONE",
          "scope": "UNCHANGED",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "NONE",
          "availabilityImpact": "NONE"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 3.6
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "timestamp": "2026-08-25T19:37:29.965837Z",
          "id": "CVE-2026-66907",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "yes"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "version": "2.0.3"
        }
      }
    ]
  },
  "weaknesses": [
    {
      "source": "[email protected]",
      "type": "Secondary",
      "description": [
        {
          "lang": "en",
          "value": "CWE-23"
        }
      ]
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "operator": "OR",
          "negate": false,
          "cpeMatch": [
            {
              "vulnerable": true,
              "criteria": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*",
              "versionStartIncluding": "4.0.0",
              "versionEndExcluding": "4.14.9",
              "matchCriteriaId": "DEBE8FE2-2989-4FC0-B805-C740A8FDF42A"
            },
            {
              "vulnerable": true,
              "criteria": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*",
              "versionStartIncluding": "4.15.0",
              "versionEndExcluding": "4.18.4",
              "matchCriteriaId": "7BC98A81-8301-4163-A47E-C6A9332A2454"
            },
            {
              "vulnerable": true,
              "criteria": "cpe:2.3:a:apache:camel:*:*:*:*:*:*:*:*",
              "versionStartIncluding": "4.19.0",
              "versionEndExcluding": "4.22.0",
              "matchCriteriaId": "10DE8B35-C125-4461-A7F7-3BDA3E3CB316"
            }
          ]
        }
      ]
    }
  ],
  "references": [
    {
      "url": "https://camel.apache.org/security/CVE-2026-66907.html",
      "source": "[email protected]",
      "tags": [
        "Mailing List",
        "Vendor Advisory"
      ]
    },
    {
      "url": "http://www.openwall.com/lists/oss-security/2026/08/24/11",
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Mailing List",
        "Third Party Advisory"
      ]
    }
  ]
}