ZeroHour

Vulnerabilities

12 CVEs · NVD, GitHub Advisories, CISA KEV, FIRST EPSS, GitHub PoC repos

CVEVulnerabilityCVSSEPSSFlagsAffectedExposurePublished
CVE-2026-80352
+2 in the same advisory: …80351 …80354
YAML injection in Apache Camel K lets CR authors create objects with operator privileges

Apache Camel K contains a YAML injection flaw (CWE-94, improper control of code generation) in its handling of custom resource (CR) configuration, specifically exposed via the Master trait's serviceAccountName field. An authenticated user who is authorized to author Camel K custom resources can embed crafted YAML that causes the operator to apply arbitrary Kubernetes objects. Because the injected objects are created with the privileges of the Camel K operator's service account, an attacker can gain unauthorized creation of cluster resources, potentially enabling privilege escalation or lateral movement within the cluster. Users running Apache Camel K 2.0.0 through 2.9.2 or 2.10.1 are affected; fixed releases are 2.9.3, 2.10.2, and 2.11.0. No public proof-of-concept or in-the-wild exploitation is known, and no CVSS score has been assigned yet.

Do: Upgrade to Apache Camel K 2.9.3, 2.10.2, or 2.11.0. As interim mitigation, limit which users and service accounts can create or modify Camel K custom resources, and audit the cluster for unexpected Kubernetes objects created with the operator's service account, paying attention to Master-trait configuration fields such as serviceAccountName.

9.8
group max
  • Apache Camel K >= 2.0.0 and < 2.9.3 (fixed in 2.9.3; also fixed in 2.11.0)
  • Apache Camel K >= 2.10.1 and < 2.10.2 (fixed in 2.10.2; also fixed in 2.11.0)
nichelikely at most low thousands of Kubernetes/OpenShift clusters running Camel K; no public install counts available
CVE-2026-84939
Path Traversal in Apache FreeMarker Localized Template Lookup (CVE-2026-84939)

Apache FreeMarker is vulnerable to path traversal (CWE-23) in its template loading mechanism when the localized lookup configuration setting is enabled, which is the default. The flaw is triggered if an application allows an attacker to supply an arbitrary, malformed locale identifier to FreeMarker; the malformed locale can cause template loading to traverse outside the intended path. What an attacker gains depends on configuration: files that can be loaded remain restricted by the configured TemplateLoader — FileTemplateLoader already prevents traversal outside its baseDir, and loaders wrapping a class loader or web application context can only reach resources those mechanisms expose — but other loader configurations may allow access outside the designated base directory, potentially enabling unintended file or resource disclosure. Any application embedding Apache FreeMarker versions 2.2.0 through 2.3.34 that passes attacker-controlled locale values into template loading is affected, including downstream products that bundle the library. No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is known at this time.

Do: Upgrade to Apache FreeMarker 2.3.35; as a mitigation on earlier versions, disable the localized lookup setting. Audit applications for code paths where user-supplied locale identifiers reach FreeMarker template loading, and review which TemplateLoader is configured to assess whether files outside the intended base directory can be reached.

9.1<1%
  • Apache FreeMarker 2.2.0 through 2.3.34 (fixed in 2.3.35)
masslikely millions of Java application deployments embed an affected FreeMarker version (library ubiquity estimate); exact count unknown
CVE-2026-73334
Improper Input Validation in Apache Parquet leaks KMS tokens via file-controlled KMS URL

CVE-2026-73334 is an improper input validation flaw (CWE-20) in the org.apache.parquet.crypto.keytools package of Apache Parquet, versions 1.12 through 1.18, which implements envelope encryption of Parquet files with data keys wrapped via a Key Management Service. The flaw is triggered when a reader does not application-control the KMS URL parameter, causing the KMS URL embedded in the Parquet file itself to be forwarded to a pluggable KmsClient implementation; if that client does not validate the destination host, the KMS token is sent to a malicious host specified by the attacker inside the file. An attacker who can supply or tamper with a Parquet file read under this configuration can capture the KMS token, potentially exposing key-management credentials and enabling unauthorized access to encrypted data keys — this is a credential/secret exposure issue, not remote code execution. Users of Parquet's envelope-encryption feature who rely on file-controlled KMS URLs with custom KmsClient plugins lacking host validation are affected; readers that set the KMS URL via application control are not exposed. The issue has not yet received a CVSS score, is not in CISA KEV, has no known public proof-of-concept, and there is no known exploitation in the wild; a fix is expected in version 1.19, which will disable file-controlled KMS URLs by default.

Do: Until the fixed release (1.19, where file-controlled KMS URL is disabled by default) is available, configure readers to set the KMS URL via application control rather than trusting the URL embedded in untrusted Parquet files. If file-controlled KMS URLs must be used, ensure your custom KmsClient implementation validates the target host and uses authentication, and only process Parquet files from trusted sources. Once version 1.19 is released, upgrade and only re-enable file-controlled KMS URLs via the new application parameter if host validation and authentication are implemented in your KMS client plugin.

8.1<1%
  • Apache Parquet (Hadoop) — org.apache.parquet.crypto.keytools 1.12 to 1.18 (fix expected in 1.19 per the disclosure)
largelikely tens of thousands of data-platform deployments run Parquet 1.12–1.18, though only the subset enabling KMS envelope encryption with file-controlled KMS…
CVE-2026-56207
+3 in the same advisory: …57866 …65181 …54048
SAML2 authentication bypass in Apache Impala hs2-http via unverified bearer token

Apache Impala's final step of SAML2 authentication on its hs2-http interface accepts a Bearer token without verifying its cryptographic signature (CWE-347). An attacker with network access to the hs2-http endpoint can submit a forged bearer token with an altered user name, and Impala will accept it as valid. This lets the attacker impersonate another user and act as that user within Impala, bypassing the SAML2 authentication control. All Apache Impala releases from version 4.0.0 onward are affected when SAML2 authentication is used with the hs2-http interface; the issue is fixed in version 4.5.2. No public proof-of-concept or in-the-wild exploitation is known, the flaw is not in CISA KEV, and CVSS has not yet been assigned.

Do: Upgrade to Apache Impala 4.5.2 as soon as practical. Until patched, restrict network access to the hs2-http interface and review hs2-http authentication/audit logs for sessions whose user name does not match corresponding IdP sign-in records to detect possible impersonation. Check whether your deployment actually uses SAML2 authentication on hs2-http, since other configurations are not affected, and watch the Apache advisory for CVSS scoring.

9.8
group max
<1%
  • Apache Impala >= 4.0.0 (fixed in 4.5.2)
nichelikely low thousands of clusters at most; only Impala >= 4.0.0 deployments with SAML2 authentication enabled on the hs2-http interface
CVE-2026-41871
+2 in the same advisory: …41869 …41870
Unauthenticated reflection-based job execution in Apache Nutch Server REST API

CVE-2026-41871 is a missing-authorization flaw (CWE-862) combined with unsafe reflection (CWE-470) in the Nutch Server component, i.e., the Nutch REST API, affecting Apache Nutch versions 1.10 through 1.22. The REST API fails to properly authorize requests, so unauthenticated or untrusted users can send API calls whose externally controlled input determines which classes or code are loaded and executed. An attacker who can reach the exposed Nutch Server can therefore trigger reflection-based job execution, potentially running arbitrary classes or jobs on the server. Only deployments running the optional Nutch Server (REST API) on Nutch 1.10 through 1.22 are affected. There is currently no public proof of concept, no known in-the-wild exploitation, and the issue is not in CISA KEV; the CVSS score has not yet been assigned.

Do: Upgrade to Apache Nutch 1.23, which removes the vulnerable Nutch Server component. If upgrading is not possible, restrict access to any instance running the Nutch Service/REST API to trusted users only, e.g., via firewall rules, ACLs, or an authenticating reverse proxy. Check whether any Nutch Server instances are exposed beyond trusted networks and review the Apache Nutch security advisories page for updates.

9.8
group max
<1%
  • Apache Nutch (Nutch Server / Nutch REST API) 1.10 through 1.22; fixed in 1.23, which removes the Nutch Server
nichelikely low hundreds to low thousands of deployments (optional Nutch Server component in a niche open-source crawler)