Vulnerabilities

CVE-2026-82617 is a regular-expression denial-of-service flaw (CWE-1333, inefficient regex complexity) in the two built-in name-finder patterns, EMAIL and URL, exposed by opennlp.tools.namefind.RegexNameFinderFactory in Apache OpenNLP. An application that obtains these finders via RegexNameFinderFactory.getDefaultRegexNameFinders(...) and applies them to untrusted text through RegexNameFinder.find(String[]) or find(String) can be driven into quadratic backtracking or unbounded matcher recursion by small crafted inputs: roughly 32 KB of text burns several seconds of CPU per EMAIL scan and returns no match, while roughly 4 KB of &-separated URL query tokens exhausts the thread stack and raises java.lang.StackOverflowError (about 1 KB suffices on worker threads with reduced stacks such as -Xss512k). Because no authentication or special configuration is needed, anyone who can control the text fed to these finders can convert each request into seconds to minutes of pinned CPU or abrupt thread death, denying service to the embedding application. Affected are applications embedding Apache OpenNLP 2.0.0 through 2.5.11 or 3.0.0-M1 through 3.0.0-M5 that have selected one of these two built-in finders; the flaw is specific to the built-in EMAIL/URL patterns and does not implicate model-based NER usage. There is no known exploitation, public proof-of-concept, or KEV listing as of now; fixed releases are 2.5.12 and 3.0.0-M6.

Do: Upgrade to Apache OpenNLP 2.5.12, or to 3.0.0-M6 if you track the 3.0.0 milestone line, both of which fix the flaw. Until patched, avoid running the built-in EMAIL/URL finders from getDefaultRegexNameFinders() on untrusted input, or cap analyzed text to well under 1 KB on small-stack server worker threads and run find() on threads with larger stacks to prevent thread death. Audit whether your code path actually calls RegexNameFinder.find(String[])/find(String) with these default finders, since model-based NER usage is not implicated.

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.

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.

CVE-2026-57967 is a missing-authentication flaw (CWE-306) in the CORE protocol of Apache Artemis and Apache ActiveMQ Artemis message brokers. An unauthenticated remote attacker who can reach the broker's CORE acceptor can send a crafted SESSION_REATTACH packet to steal an already-established session. By doing so, the attacker assumes ongoing execution of the previously authenticated session, effectively impersonating a legitimate connected client. All versions from 1.0.0 through 2.44.0 (Apache ActiveMQ Artemis) and 2.50.0 through 2.56.0 (Apache Artemis) are affected, and version 2.57.0 fixes the issue. No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is known at this time.

Do: Upgrade to Apache ActiveMQ Artemis 2.57.0, which fixes the issue for both product lines. Until upgraded, restrict network access to the broker's CORE acceptor port (commonly 61616) so only trusted networks and clients can reach it, and review broker logs for unexpected or unexplained session reattachment activity.

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.

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.

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.

CVE-2026-78254 is a path traversal flaw (CWE-23) in the ftp and scp download tasks of Apache Ant: in versions prior to 1.10.18, a server providing downloaded files can use relative paths to write outside the dedicated destination directory. It is triggered when an Ant build uses the ftp or scp task to fetch files from a malicious server, or via a machine-in-the-middle attack against plain ftp; for scp and ftps, the attacking server must still pass the tasks' server identity checks. A successful attack lets the attacker overwrite files of their choosing on the machine running the build, using the permissions of the user executing Ant, potentially tampering with scripts, libraries, or build outputs. Affected users are those running Apache Ant builds (before 1.10.18) that download files with the ftp or scp tasks, especially against servers that are not fully trusted or are reached over untrusted networks. No exploitation is currently known: there is no public proof-of-concept, the flaw is not in CISA's KEV, and EPSS estimates only a 0.4% probability of exploitation within 30 days.

Do: Upgrade to Apache Ant 1.10.18, which by default prevents these tasks from writing outside the destination directory. Do not bypass server identity checks for scp and ftps, and switch ftp tasks from plain ftp to ftps where possible to prevent machine-in-the-middle attacks. Audit build files for ftp/scp download usage and restrict them to trusted, verified servers until patched.

There is a lack of XSS escaping in the Spark History Server prior to 3.5.8 which allows a malicious Spark job to generate arbitrary unescaped frontend code which could lead to a minimal privilege escalation in browser. Users are encouraged to upgrade to Spark 3.5.8 or later. This CVE is marked as "low" since the path to exploit requires both relatively high permissions (ability to launch a Spark job) and requires tricking a user with higher permissions to log in and visit the Spark history web page. Users are encouraged to upgrade their Spark history servers to Spark 3.5.8 or later.

Apache Wicket versions 8.0.0 through 8.18.0, 9.0.0 through 9.23.0, and 10.0.0 through 10.10.0 fail to enforce the per-file size limit (Form#setFileMaxSize) and file count limit (Form#setFileCountMax) when a multipart request body has already been consumed by another component, causing Wicket to fall back to reading uploads via HttpServletRequest#getParts() and process them as if those limits had been satisfied. This fallback is reached in deployments where a servlet annotated with @MultipartConfig, Spring Boot's multipart resolver, or a filter calling HttpServletRequest#getParameter() parses the multipart body first, affecting upload paths such as Form with FileUploadField, FileUploadToResourceField and AjaxFileDropBehavior. A remote uploader can submit files larger or more numerous than the application permits (bounded by whatever the other parsing component allows), and a part lacking a Content-Type header is additionally read into memory in full during parsing, enabling attacker-controlled large allocations and potential memory exhaustion and denial of service (CVSS 7.5, availability impact high). Only applications that explicitly configure a per-file or file-count limit and route uploads through such a co-parsing path are affected; the total upload size limit Form#setMaxSize is not impacted, and applications configuring neither of the two affected limits are unaffected. No public proof-of-concept, in-the-wild exploitation, or CISA KEV listing is known, and EPSS estimates a 0.8% probability of exploitation within 30 days.

Do: Upgrade to Apache Wicket 8.19.0, 9.24.0, or 10.11.0 as applicable, and migrate 7.x or older deployments to a supported branch. As an interim mitigation, configure equivalent limits in the component that parses the request body, for example spring.servlet.multipart.max-file-size and max-request-size in Spring Boot, or maxFileSize and maxRequestSize in @MultipartConfig or the web.xml multipart-config element. Audit whether your deployment has a @MultipartConfig servlet, Spring Boot's multipart resolver, or a filter calling getParameter() on multipart requests ahead of Wicket, and whether Form#setFileMaxSize or Form#setFileCountMax limits are set, since both conditions are required for exposure.

When Apache Shiro is used with the Jakarta EE integration module, a low-privileged user can craft an HTTP request that causes the server to initiate a connection to an attacker-controlled URL and transmit attacker-controlled data. This vulnerability affects Apache Shiro versions 2.x through 3.0.0 only in deployments that use the Jakarta EE integration module. Mitigation: Upgrade to version 3.0.1 or later, which fixes the issue. + Alternatively, you can set the `org.apache.shiro.form-resubmit-host` (String) and `org.apache.shiro.form-resubmit-port` (Integer) system properties to restrict the host and port that Shiro will connect to when resubmitting a form.

Inefficient Algorithmic Complexity vulnerability in Apache APISIX. A single small request can pin a gateway worker at 100% CPU for an extended period in graphql-limit-count routes. This issue affects Apache APISIX: 3.17.0. Users are recommended to upgrade to version 3.18.0, which fixes the issue.

Reliance on Untrusted Inputs in a Security Decision vulnerability in Apache APISIX. This vulnerability allows an attacker to escalate privilege or perform an authorization bypass by sending certain values that the attach-consumer-label plugin does not sanitise correctly. This issue affects Apache APISIX: from 3.11.0 through 3.17.0. Users are recommended to upgrade to version 3.18.0, which fixes the issue.

Authentication Bypass by Capture-replay vulnerability in Apache Tomcat's DIGEST authenticator. If, before windowSize requests have been made, a client makes a DIGEST authenticated request with a nonceCount on the upper boundary of the replay window then that request is replayable once only while the associated nonceCount remains within the replay window. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.24, from 10.1.0-M1 through 10.1.57, from 9.0.0.M1 through 9.0.120. The following versions were EOL at the time the CVE was created but are known to be affected: from 8.5.0 through 8.5.100, from 7.0.30 through 7.0.109. Other unsupported versions may also be affected. Users are recommended to upgrade to version 11.0.25, 10.1.58 or 9.0.121, which fix the issue.

SQL injection in Hive Metastore direct SQL partition-name resolution in Apache Hive before 4.2.1 on all platforms allows authenticated users with access to Hive Metastore APIs to read, modify, or affect unintended partition metadata (including statistics updates, truncation targets, and file-metadata cache operations) via crafted partition names in metastore RPC requests when direct SQL is enabled (the default). Users are recommended to upgrade to version 4.2.1, which fixes this issue. Details about the issue: Several Hive Metastore RPCs resolve partitions by full partition name (PART_NAME) through direct-SQL helpers. In those paths, client-supplied partition names are embedded into SQL using string concatenation (DirectSqlUpdatePart.quoteString() → '...') instead of bind parameters. A partition name containing a single quote (and crafted SQL) can alter the generated WHERE clause so that lookups intended for one partition match additional rows. That can affect reads, stats updates, truncate targets, metadata-cache targets, and related operations when metastore.try.direct.sql is enabled (default: true). An authenticated or network-trusted caller with the ability to invoke Hive Metastore partition-name APIs against a target table (directly or via Hive/other clients), when direct SQL is enabled can perform this attack. Also, the impact is mainly within table & partition targeting (read/update/truncate/drop/cache the wrong partitions in a table they can reference), not arbitrary cross-database access via this bug alone.