Apache

Path traversal in Apache Ivy's PackagerResolver (versions 2.0.0 through 2.5.3) allows an attacker with write access to a packager repository to overwrite arbitrary files outside the configured buildRoot directory by embedding '../' sequences in module coordinates such as organisation, name, or revision. The overwrite occurs during the Ant-script-driven repackaging phase that PackagerResolver triggers on artifact download. No public exploit code has been identified at time of analysis, and the vendor has released version 2.6.0 as the fix, confirmed via the Apache Ant project site on July 14, 2026.

SQL injection in Apache Fineract's Office Search API (GET /api/v1/offices) in all versions up to and including 1.14.0 lets an authenticated user who holds the office-view permission inject arbitrary SQL through the orderBy request parameter. Because it bypasses the ColumnValidator hardening added for CVE-2024-32838, an attacker can run time-based blind SQL injection to exfiltrate database contents and, by launching concurrent injections that hold connections open, exhaust the database connection pool to cause denial of service. No public exploit identified at time of analysis; the flaw is documented via an oss-security advisory and an upstream fix pull request (apache/fineract #6048).

Blind boolean-based SQL injection in Apache Fineract's Client Search API (GET /api/v1/clients) through version 1.14.0 lets an authenticated user who holds the view-clients permission concatenate unvalidated orderBy (and sortOrder) parameters directly into the backing SQL query. Attackers can extract arbitrary database contents one bit at a time and, on MySQL/MariaDB back ends, read arbitrary files accessible to the DB process via LOAD_FILE(). There is no public exploit identified at time of analysis, though the vendor's fix PR (#6020) ships an integration test containing a working injection payload; not listed in CISA KEV.

SQL injection in Apache Fineract's Report Execution API (the runreports endpoint) in all versions up to and including 1.14.0 lets an authenticated user holding report-run permission inject arbitrary SQL through crafted report parameter values, because those values are concatenated into the generated query without sufficient validation. This yields unauthorized read access to data well beyond what the report was scoped to expose, and by extension other database contents. There is no public exploit identified at time of analysis and the flaw is not in CISA KEV; the upstream fix landed in PR #5980, which introduces a configurable InputValidator/validation-profile framework.

Unauthenticated arbitrary file read in FacturaScripts (all versions through v2026.2) lets remote attackers retrieve protected documents by abusing the static file controllers Files.php and Myfiles.php, which authorize requests on the raw URL prefix rather than the resolved filesystem path. A request such as /Plugins/../MyFiles/Private/invoice.pdf passes the prefix allow-list yet resolves to a private file, leaking customer/supplier invoices, attachments, and .sql database backups. A detailed, reproducible exploit is publicly available in the GitHub Security Advisory; there is no vendor-released patch identified at time of analysis and no evidence of active exploitation.

Arbitrary file read in Apache OpenMeetings 5.0.0 through 9.0.x allows any room moderator to exfiltrate files accessible to the OS account running the server, including credentials and secrets, via a crafted download request to the WhiteBoard download service. The vulnerability stems from insufficient path validation in the WB download endpoint, enabling directory traversal outside the intended file scope. No active exploitation has been confirmed (not in CISA KEV), but the ability to read credential files makes this high-priority for any internet-exposed deployment where moderator access is not tightly controlled.

Cluster-communication confidentiality and integrity in Apache Tomcat can be undermined because the secure-configuration requirements for the EncryptInterceptor were never clearly documented, leaving operators liable to deploy the cluster session-replication channel insecurely. The flaw affects Tomcat 7.0.100-7.0.109, 8.5.38-8.5.100, 9.0.13-9.0.119, 10.1.0-M1-10.1.56 and 11.0.0-M1-11.0.23, and is fixed in 9.0.120, 10.1.57 and 11.0.24. It carries a CVSS 9.1 (C:H/I:H) but SSVC records exploitation as none, no public exploit identified at time of analysis, and the root cause is a documentation weakness (CWE-1059) rather than a code defect.

Security constraint bypass in Apache Tomcat (8.5.0-8.5.100, 9.0.0.M1-9.0.119, 10.1.0-M1-10.1.56, 11.0.0-M1-11.0.23) lets remote attackers reach protected resources by abusing improperly handled hex URL encoding in the RewriteValve, defeating URL-pattern security constraints. Because the flaw resides in the rewrite valve, only deployments that use the RewriteValve together with security constraints are exposed, but where present an unauthenticated attacker (per CVSS PR:N) can access or manipulate resources meant to be restricted. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV; EPSS data was not provided.

Improper authorization in Apache Kylin's REST API job endpoints allows authenticated users to retrieve job metadata from projects they are not authorized to access. The `JobController.getJobList` and `JobController.getJobDetail` endpoints lack project-scoped permission verification, meaning any authenticated user can query build job information across project boundaries within a shared Kylin deployment. Apache Kylin versions 4 through 5.0.3 are affected; no public exploit code or active exploitation has been identified at time of analysis.

OS command injection in Apache Kylin (versions 4 through 5.0.3) allows attackers to execute arbitrary operating-system commands by supplying malicious job configuration parameters that a backend API passes unsanitized to the OS command line. Because Kylin runs as a distributed analytics engine, successful exploitation yields full host compromise with the privileges of the Kylin service account. Per the vendor CVSS (AV:N/PR:N), the flaw is scored as network-reachable and unauthenticated with high impact across confidentiality, integrity, and availability; no public exploit is identified at time of analysis, and it is not listed in CISA KEV.

SQL injection in Apache Kylin (versions 4 through 5.0.3) allows attackers to inject arbitrary SQL through a backend API used to refresh the table catalog, where untrusted input is concatenated into a dynamically generated SQL statement. The upstream CVSS 3.1 vector rates this as unauthenticated (PR:N) with full confidentiality, integrity, and availability impact (9.8), enabling database read/write and potentially further compromise. There is no public exploit identified at time of analysis and it is not listed in CISA KEV.

Missing authentication on Apache Doris Frontend (FE) HTTP REST administrative APIs allows any unauthenticated attacker with network reach to the FE HTTP service to invoke privileged administrative operations, degrading cluster integrity and availability up to full denial of service. All Apache Doris releases before 3.1.0 (per EUVD, the 2.1.0 through pre-3.1.0 line) are affected, and a fixed release exists in 3.1.0. There is no public exploit identified at time of analysis and the issue is not listed in CISA KEV; the 9.1 Critical CVSS reflects the trivial unauthenticated network exploitability rather than confirmed in-the-wild use.

Remote code execution in the plank/laravel-mediable package before 7.0.0 lets attackers upload a double-extension file such as shell.php.jpg that passes all MIME, extension, and aggregate-type validation because of the trailing .jpg, yet retains an inner .php in its stored basename. On Apache/nginx servers misconfigured to execute any filename containing .php, the stored artifact runs as PHP. Reported by VulnCheck with a vendor patch in 7.0.0; there is no public exploit identified at time of analysis and it is not listed in CISA KEV.

Privilege escalation in the Apache Airflow FAB auth manager (apache-airflow-providers-fab before 3.7.2) lets a low-privileged user who is granted per-DAG access to a DAG literally named 'DAGs' silently receive the global all-DAGs permission, gaining read and edit access to every DAG in the deployment. The flaw stems from a resource-name collision in resource_name(), where the reserved global resource string 'DAGs' is indistinguishable from a legitimate dag_id of the same value. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV.

Man-in-the-middle interception of Apache Airflow's Git provider (apache-airflow-providers-git before 0.4.1) is possible because git-over-SSH operations run with StrictHostKeyChecking=no by default, so no SSH host-key verification occurs. An attacker positioned on the network path between an Airflow worker and its Git server can impersonate the server to steal the SSH deploy key or inject malicious DAG content, leading to code execution on workers. No public exploit identified at time of analysis, and it is not listed in CISA KEV; CVSS is 8.1 (High) driven by high attack complexity (AC:H) requiring an on-path position.

Authenticated SSRF in Apache Gravitino's JobManager component (versions 1.0.0 through 1.2.1) enables authenticated users to coerce the server into making arbitrary outbound HTTP requests to internal network hosts and cloud instance metadata services (e.g., AWS IMDS at 169.254.169.254, GCP metadata endpoints) by supplying unvalidated URIs within job templates. In cloud-hosted deployments this is a credential-theft primitive: metadata service access can yield IAM role credentials with blast radius extending well beyond the Gravitino service itself. No public exploit or CISA KEV listing has been identified at time of analysis; vendor labels severity as moderate, though cloud-metadata reachability elevates real-world impact above that rating in typical deployment contexts.

Improper URL encoding in Apache Gravitino versions 1.0.0 through 1.2.0 lets remote attackers inject crafted path segments through unencoded, user-supplied metadata identifiers, redirecting or manipulating the internal HTTP requests Gravitino issues on the user's behalf. Because the CVSS vector (AV:N/PR:N) indicates no authentication and yields a 9.1 Critical score with high confidentiality and integrity impact, an attacker can potentially reach unintended endpoints, tamper with metadata operations, or exfiltrate data from back-end catalog services. No public exploit identified at time of analysis, and the flaw is fixed in version 1.2.1.

WAF filtering bypass in OWASP ModSecurity (libmodsecurity) before 3.0.16 lets remote unauthenticated attackers smuggle malicious payloads past inspection rules by exploiting a multipart/form-data parser differential. The engine silently strips embedded line breaks from non-file form-field values before populating ARGS and ARGS_POST, so any rule whose detection depends on a newline (e.g. command, header, or injection syntax spanning a line break) fails to match while the backend still receives and acts on the intact payload. No public exploit identified at time of analysis, but the CVSS base score of 8.6 reflects a scope-changing integrity impact on every application shielded by an affected deployment.

WAF rule bypass in ModSecurity 3.0.0-3.0.15 on i386 architecture allows network-accessible attackers to evade rules that use the t:utf8toUnicode transformation, potentially permitting injection attacks or other malicious payloads to reach protected applications undetected. The root cause is CWE-467 - sizeof() applied to a char pointer in utf8_to_unicode.cc yields the pointer width (4 bytes on i386) rather than the unicode buffer length, corrupting transformation output. No public exploit code or active exploitation has been identified at time of analysis; the fix is available in v3.0.16.

Malformed JSON output in Apache Log4j API versions 2.13.1-2.25.4 and 2.26.0 allows a remote attacker who can inject non-finite floating-point values (NaN, Infinity, -Infinity) into a logged MapMessage to corrupt downstream log records and disrupt log ingestion pipelines. This is an incomplete fix follow-on to CVE-2026-34481: the prior patch left code paths in MapMessage.asJson() and MapMessage.getFormattedMessage(["JSON"]) that still emit bare IEEE 754 non-finite tokens prohibited by RFC 8259. No public exploit or active exploitation (CISA KEV) has been identified; the CVSS 4.0 score of 6.3 reflects limited subsequent-system integrity impact rather than direct host compromise.

Denial of service in the Apache IoTDB C++ client (versions 1.3.5 before 1.3.8 and 2.0.5 before 2.0.10) allows a malicious or compromised IoTDB server to crash any connected client by returning malformed TsBlock response data. The client's TsBlock deserializer performs out-of-bounds reads (CWE-125) on attacker-controlled server payloads, terminating the client process. There is no public exploit identified at time of analysis, EPSS probability is low (0.14%), and impact is limited to availability of the client - no confidentiality or integrity effect is claimed.

Authorization bypass in Apache IoTDB's REST API endpoint /rest/v2/fastLastQuery allows authenticated users to access last-value time-series data they are not authorized to view. Affected versions span the 1.3.x branch (1.3.5 through 1.3.7) and the 2.0.x branch (2.0.5 through 2.0.9). No public exploit code or active exploitation has been identified at time of analysis, but the REST interface nature of the flaw means any valid credential holder can attempt unauthorized data retrieval without elevated privilege.

Privilege escalation in Apache IoTDB 2.0.8 through 2.0.9 allows any authenticated low-privilege user to rename their own account to the reserved '__internal_auditor' identity and thereby inherit full tree-path access across all stored time-series data. The flaw stems from the system trusting a reserved auditor username without protecting it from ordinary user-driven renames, so a normal database user can self-promote to auditor-level authority. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV; it was reported and fixed by the Apache project in 2.0.10.

Unsafe reflection in Apache IoTDB's pipe processor lets a user-supplied fully qualified Java class name be loaded and instantiated via Class.forName().newInstance() with no allowlisting, enabling arbitrary class loading and likely remote code execution in the database server process. It affects all releases from 1.0.0 up to (but not including) 2.0.10 and is fixed in 2.0.10. No public exploit identified at time of analysis, and EPSS is low (0.25%, 17th percentile), though CISA SSVC rates the technical impact as total and considers exploitation automatable.

Denial of service in Apache IoTDB versions 1.0.0 up to (but not including) 2.0.10 lets an unauthenticated network attacker crash the AirGap receiver thread by exploiting unbounded recursion in its readLength method. When the pipe_air_gap_receiver_enabled=true option is set, repeated E-language prefixes in a single socket stream drive recursion arbitrarily deep until the JVM stack is exhausted and a StackOverflowError is raised. There is no public exploit identified at time of analysis, and the EPSS probability is low (0.14%, 4th percentile), consistent with SSVC marking exploitation as 'none' though 'automatable: yes'.

Unauthenticated denial of service in Apache IoTDB (1.0.0 through 2.0.9) allows remote attackers to crash or degrade the DataNode process when the AirGap pipe receiver is enabled. The receiver's readLength method reads an attacker-controlled 32-bit length field from a raw TCP connection on port 9780 and passes it directly to new byte[length], letting a single connection trigger a heap allocation of up to ~2 GB and exhaust JVM memory. No public exploit has been identified at time of analysis, but exploitation is trivial once the feature is enabled, and Apache has released a fixed version (2.0.10).

Arbitrary file write in Apache IoTDB (versions 1.0.0 through 2.0.9) lets remote attackers plant files anywhere the IoTDB process can write by abusing an unsafe API that fails to sanitize user-supplied pathnames. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) indicates unauthenticated network exploitation with high confidentiality and integrity impact, and controlled file placement can escalate to code execution or overwrite of critical files. No public exploit has been identified at time of analysis, and EPSS is low (0.16%, 5th percentile) despite the 9.1 severity.

Authentication bypass via capture-replay in Apache IoTDB (1.0.0 through 2.0.9) lets attackers reuse stale credentials against the REST interface because Basic Authentication continues to accept cached credentials that should have been invalidated. An attacker who has captured or previously held valid credentials can keep authenticating after those credentials should have expired or been revoked, gaining full read/write control of the time-series database. No public exploit identified at time of analysis, and EPSS is low (0.18%, 8th percentile), so no active exploitation is indicated despite the 9.8 CVSS.

Signature-verification bypass in YesWiki (v4.6.5 and earlier, ActivityPub-federated Bazar forms) lets an unauthenticated remote attacker forge a valid ActivityPub actor and have Create/Update/Delete activities processed as if properly signed. The flaw stems from HttpSignatureService::verifySignature() using a loose boolean check (!openssl_verify(...)) that treats openssl_verify()'s -1 internal-error return as success. A detailed proof-of-concept exists (publicly available exploit code exists) demonstrating full CRUD on Bazar entries; the issue is not in CISA KEV and no EPSS score was provided.

Path traversal via the COAR Notify / Linked Data Notifications (LDN) service in DSpace 8.0-8.3 and 9.0-9.2 allows an authenticated DSpace administrator to reference arbitrary filesystem paths as LDN inbound-pattern templates, causing those files to be read and interpreted as Apache Velocity templates. While no public exploit or active exploitation has been identified, the vulnerability was demonstrated as part of a proven attack chain in which an administrator stages a malicious Velocity payload in a predictable file location and triggers its execution, enabling either sensitive file disclosure or arbitrary Java code execution via Velocity template injection. No special conditions (KEV, public PoC) are confirmed at time of analysis.

Cross-origin information disclosure in the Apache Helix REST service (helix-rest) through 2.0.0 lets a remote attacker who lures an authenticated operator to a malicious web page read responses from and send requests to administrative REST endpoints. The CORSFilter unconditionally returns Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true and reflects arbitrary preflight method/header values, defeating the browser same-origin policy. There is no public exploit identified at time of analysis and EPSS risk is low (0.17%, 7th percentile), and it is not on the CISA KEV list.

Remote code execution in Apache Gravitino before 1.2.1 allows unauthenticated callers to abuse the testConnection API by submitting a crafted H2 JDBC URL whose INIT parameter runs arbitrary Java on the server. The flaw only manifests when Gravitino is backed by the H2 database - a configuration primarily used for testing and local development - and CISA SSVC rates technical impact as total and exploitation as automatable, though no public exploit has surfaced. Fixed in 1.2.1; because Gravitino is usually deployed on internal networks and H2 is not the production default, the vendor characterizes real-world severity as low despite the 9.1 CVSS score.

Remote code execution in Vtiger CRM before 8.4.0 lets an authenticated low-privileged user upload a malicious .phar file through the Documents module and execute arbitrary PHP. The extension denylist in config.inc.php omits .phar, and a stale Apache 2.2-syntax .htaccess is silently ignored on Apache 2.4, so the payload lands in a web-accessible directory reachable by unauthenticated HTTP - the attack begins authenticated but the final execution step is unauthenticated. Publicly available exploit code exists (published by VulnCheck/Jiva Security); no CISA KEV listing and no EPSS score were provided.

Authenticated remote code execution in Vtiger CRM through version 8.4.0 lets an administrator upload a crafted ZIP archive through the ModuleManager import feature and drop executable PHP files directly into the web-root modules/ directory, yielding a persistent web shell. Because Apache resolves and executes those PHP files before Vtiger's routing layer runs, the resulting shell bypasses the application's authentication entirely and survives independently of the attacker's login session. Publicly available exploit code exists (VulnCheck / Jiva Security), though there is no public exploit identified as being used in active attacks and it is not listed in CISA KEV.

Remote code execution in Apache Airflow before 3.3.0 lets a DAG author embed a malicious trigger whose attacker-controlled class path is loaded via an unrestricted import_string() when the Scheduler or API Server deserializes the serialized DAG, executing arbitrary code in those privileged processes and breaking the core Airflow boundary that DAG-author code must never run in the Scheduler/API Server. Reported by Apache with a fix in 3.3.0, it currently has no public exploit identified and a low EPSS of 0.69% (48th percentile), and it is not listed in CISA KEV. The practical severity depends heavily on how much a deployment trusts its DAG authors, since exploitation requires the ability to submit a DAG.

Apache Airflow REST API exposes provider secrets in plaintext through the task-instance detail and list endpoints when tasks are in a deferred state. Any authenticated user holding DAG-scoped task-instance read access - a permission commonly granted to non-admin roles - can retrieve API keys, passwords, or other secrets passed by deferred operators into trigger kwargs. Fixed in Apache Airflow 3.3.0; no public exploit code identified at time of analysis, though exploitation is trivially achievable by any authenticated user with the requisite read permission.

Sensitive credential exposure in Apache Airflow's Bulk Variables API allows authenticated users with bulk Variable read permission to retrieve plaintext values from JSON-typed variables whose key names use secret-suffixed conventions such as `*_password`, `*_token`, or `*_secret`. The redactor function was invoked without passing the variable key, so the `should_hide_value_for_key` check - which is responsible for masking secrets based on key-name patterns - could never fire for JSON-decodable variable values. This affects all deployments prior to 3.3.0 that store sensitive credentials in JSON-typed Airflow Variables under secret-suffixed key names; no public exploit has been identified at time of analysis, and exploitation is bounded by the requirement for authenticated access with a specific permission grant.

{dag_id}` endpoint and its UI equivalent perform authorization only on the requested DAG identifier, not on the full file contents returned. No public exploit has been identified and the issue is not listed in CISA KEV, but it directly undermines per-DAG access control in multi-tenant or team-partitioned Airflow deployments.

Incomplete authorization filtering in Apache Airflow's `/ui/dependencies` scheduling graph endpoint exposes restricted DAG identifiers to authenticated users who lack read permission on those DAGs. The endpoint correctly filters top-level serialized DAG keys against the caller's ACL but leaks referenced DAG IDs through `dep.source` and `dep.target` fields of trigger and sensor dependency entries, enabling cross-team DAG enumeration in multi-tenant deployments. This is a residual gap from an incomplete fix for CVE-2026-28563; no public exploit has been identified at time of analysis, and a vendor patch is available in apache-airflow 3.3.0.

Apache Airflow's Config API leaks plaintext secrets-backend credentials to authenticated users with Config read permission, because per-key environment variable overrides (e.g., AIRFLOW__SECRETS__BACKEND_KWARG__SECRET_ID) generate synthetic config entries whose names are absent from the sensitive_config_values masking list. Affected deployments are those that configure secrets backends such as HashiCorp Vault via these per-key environment variable patterns, exposing credentials like Vault role_id and secret_id through normal API responses. No public exploit has been identified at the time of analysis; the vendor-released fix is apache-airflow 3.3.0.

Account takeover in FOSSBilling 0.5.6 through 0.7.2 arises because the reset_password guest API endpoint reuses an existing, unexpired ClientPasswordReset token rather than rotating it on each request. An attacker who has captured a victim's earlier reset link retains a valid path to hijack the account even after the victim requests a fresh reset, since the original token is never invalidated and its 15-minute window is anchored to the first request. No public exploit is identified at time of analysis, and the CVSS 4.0 score is 7.7 (High); version 0.8.0 fixes the flaw.

Arbitrary file read in OpenRemote's KNXProtocol asset-import handler lets any authenticated user (PR:L, any realm) upload a malicious ETS project ZIP whose 0.xml is parsed via Saxon XSLT and XMLInputFactory without XXE hardening, resolving external entities to exfiltrate server files such as /etc/passwd, openmrs-runtime.properties, and cloud credential files, with SSRF against internal endpoints as a secondary impact. This is an incomplete-fix regression of CVE-2026-40882, which only hardened the parallel Velbus handler and left KNXProtocol's two XML parsing calls unprotected. A full working proof-of-concept reproducing both parsing stages is publicly available; the vulnerability is not listed in CISA KEV.

Untrusted Java deserialization in Apache OpenNLP's SvmDoccatModel (libsvm document categorization module, versions 3.0.0-M1 through before 3.0.0-M4) lets an attacker who supplies a crafted serialized stream to the public static SvmDoccatModel.deserialize(InputStream) trigger deserialization of an arbitrary object graph before the SvmDoccatModel cast occurs. Where a usable gadget chain exists on the consuming application's classpath, this yields remote code execution in the loading JVM; OpenNLP ships no gadget itself, so realistic risk falls on downstream apps that embed the module alongside vulnerable transitive dependencies. No public exploit identified at time of analysis and the flaw is not in CISA KEV, though the SSVC assessment marks it automatable with partial technical impact.

Improper input validation in Apache Camel (versions through 4.14.7, 4.15.0-4.18.2, and 4.19.0-4.20.0) allows remote attackers to trigger information disclosure and limited integrity/availability effects against exposed Camel integration endpoints. The CVSS 3.1 base score is 7.3 (High) with a fully remote, unauthenticated vector, and the Apache-issued advisory tags the flaw as Information Disclosure. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but the network-reachable, no-privilege vector warrants prompt patching.

Improper input validation in Apache Camel - the open-source Java integration framework - affects versions through 4.14.7, 4.15.0 through 4.18.2, and 4.19.0 through 4.20.0, and per the Apache-published advisory carries partial (Low) impact to confidentiality, integrity, and availability. Tagged as an Information Disclosure issue, it is remotely reachable per the CVSS network vector and appears to let a remote attacker submit malformed input that the framework fails to properly validate, potentially exposing limited data or perturbing message processing. There is no public exploit identified at time of analysis and it is not listed in CISA KEV.

Improper input validation in Apache Camel versions 4.8.0 through 4.18.2 and 4.19.0 through 4.20.0 allows remote unauthenticated attackers to send crafted input that the framework fails to validate, yielding limited information disclosure and partial integrity/availability impact per the CVSS vector. The flaw is reported directly by the Apache Software Foundation and is fixed in 4.18.3 and 4.21.0; there is no public exploit identified at time of analysis and it is not on the CISA KEV list. The moderate 7.3 (High) score reflects easy network reachability but limited per-impact severity (C:L/I:L/A:L).

Authentication bypass via sessionId spoofing in Apache IoTDB (1.3.3 through versions before 2.0.8) lets a remote, unauthenticated attacker forge the sessionId parameter on certain Thrift RPC query handlers and retrieve valid query results without ever calling openSession. This exposes stored time-series data to arbitrary readers. No public exploit identified at time of analysis, and EPSS is low (0.20%, 10th percentile) despite the 9.1 CVSS, so exploitation is not confirmed in the wild.

Denial of service in Apache IoTDB versions 1.3.3 through 2.0.7 lets remote attackers crash the DataNode process by submitting a single query whose time span and aggregation interval are unbounded. Because the affected query interface enforces no reasonable limit on these parameters, a request combining a very large time range with a minimal interval forces the DataNode to materialize an enormous result set in memory, exhausting the Java heap. No public exploit has been identified at time of analysis and the issue is not in CISA KEV, but the fix is easy to reverse-engineer from the version bump to 2.0.8.

Untrusted JMS deserialization in Apache Camel's JMS-family components (camel-jms, camel-sjms, camel-sjms2, camel-amqp, camel-activemq, camel-activemq6) lets an attacker who can publish an ObjectMessage to a consumed queue or topic inject arbitrary Exchange state - body, IN/OUT headers, properties, variables, exchange id and exception - into a Camel route. It affects 3.0.0 through 4.14.7, 4.15.0 through 4.18.2, and 4.19.0 through 4.20.x when mapJmsMessage (the default) is enabled and Camel acts as a JMS consumer. This is a bypass of the earlier CVE-2026-40860 hardening, requires no gadget chain (only java.lang/java.util types), carries CVSS 7.3, and has no public exploit identified at time of analysis (EPSS 0.18%).

Arbitrary file write in Apache IoTDB DataNode (versions 1.3.3 up to but not including 2.0.8) allows attackers who can reach the internal DataNode RPC port to smuggle path-traversal sequences in an uploaded Trigger JAR filename, writing files outside the Trigger installation directory with the IoTDB process's privileges. Because the write is attacker-controlled, it can plausibly be escalated to remote code execution by overwriting configuration or startup artifacts. There is no public exploit identified at time of analysis, and the EPSS score is low (0.15%, 4th percentile), consistent with exploitation being gated on an exposed internal port rather than a default-reachable service.

Java object deserialization in the Apache Camel camel-pqc component allows code execution in the key-management application when an attacker who can write to the backing AWS Secrets Manager secret stores a malicious serialized payload. The flaw affects Apache Camel 4.18.0-4.18.2 and 4.19.0-4.20.x, where AwsSecretsManagerKeyLifecycleManager.deserializeMetadata() calls a raw ObjectInputStream.readObject() with no class filter, so gadget side effects fire before the KeyMetadata cast. Rated CVSS 9.8 by Apache, but exploitation genuinely requires IAM write access to the specific secret; there is no public exploit identified at time of analysis and EPSS is low at 0.19% (8th percentile).

Confused-deputy operation redirection in the Apache Camel camel-cxf SOAP component (versions 4.0.0 before 4.14.8, 4.15.0 before 4.18.3, and 4.19.0 before 4.21.0) lets an attacker steer which backend SOAP operation gets invoked. Because the operationName / operationNamespace selection headers lacked the Camel/camel prefix, HttpHeaderFilterStrategy failed to strip them at the HTTP boundary, so in any route bridging an HTTP consumer (e.g. platform-http) into a cxf: producer, an HTTP client could inject these headers and force CxfProducer to call a different WSDL operation than intended - for example swapping a read for a destructive write. No public exploit is identified at time of analysis, EPSS is low (0.15%), and it is not in CISA KEV.

Cypher injection in Apache Camel's camel-neo4j producer allows attackers who control JSON key names in the CamelNeo4jMatchProperties map to execute arbitrary Cypher queries against the connected Neo4j database, enabling unauthorized read, modification, or deletion of any node or relationship. The flaw exists across three release streams (4.10.0-4.14.7, 4.15.0-4.18.2, 4.19.0-4.20.x) and is a direct bypass of the partial fix introduced in CVE-2025-66169, which bound property values as query parameters but left property names (JSON keys) concatenated verbatim into the WHERE clause. No public exploit code or CISA KEV listing has been identified at time of analysis, though the prior related CVE in the same producer indicates recurring injection exposure in this component.

Remote code execution via unsafe Java deserialization affects the camel-pqc component of Apache Camel 4.18.0-4.18.2 and 4.19.0-4.20.x. The HashiCorp Vault and AWS Secrets Manager KeyLifecycleManager implementations (and a legacy-migration path in the file-based manager) read post-quantum key metadata back with a raw ObjectInputStream.readObject() lacking any ObjectInputFilter or allow-list, so a principal able to write to the key backend can plant a gadget object that executes during normal key-lifecycle operations. No public exploit has been identified at time of analysis and EPSS is low (0.19%), but SSVC rates technical impact as total; this is an incomplete-remediation follow-on to CVE-2026-40048.

Query injection and authorization bypass in the Apache Camel Lucene component (camel-lucene) lets remote unauthenticated HTTP clients override the full-text search a route intends to run. Because the raw header names QUERY and RETURN_LUCENE_DOCS lack the Camel/camel prefix, HttpHeaderFilterStrategy does not strip them at the HTTP boundary, so an attacker-supplied header flows straight into the Exchange and executes against the index - enabling disclosure of documents the requester should not see (e.g. a match-all query dumping the whole index) and CPU-heavy regex queries. Affects 4.0.0-4.14.7, 4.15.0-4.18.2, and 4.19.0-4.20.x; no public exploit identified at time of analysis, and EPSS is low (0.16%, 6th percentile).

Header injection in Apache Camel Mail Component enables attackers to override SMTP JavaMail session properties by supplying crafted headers in the mail.smtp./ mail.smtps. namespace through any untrusted inbound protocol - including HTTP query parameters, JMS, or Kafka - that feeds into a Camel route terminating at an SMTP producer. On releases before 4.19.0, the most severe impact is full SMTP host redirection: the producer reconnects to an attacker-controlled server and authenticates with the endpoint's configured credentials, resulting in credential theft. On 4.19.0 through pre-4.21.0, host redirection is blocked, but attackers can still weaken transport security (disabling STARTTLS, manipulating SSL trust, or injecting a SOCKS proxy) and intercept outgoing mail content. No public exploit identified at time of analysis, and this CVE is not listed in the CISA KEV catalog.

Header injection in the Apache Camel camel-nats component (4.0.0-4.14.7, 4.15.0-4.18.2, 4.19.0-4.20.x) allows any NATS client that can publish to a consumed subject to inject arbitrary Camel-internal control headers into the Exchange because the consumer's default DefaultHeaderFilterStrategy has no inbound filter rules. An attacker can override headers such as CamelHttpUri, CamelFileName, or CamelSqlQuery to redirect HTTP producers, rename files, or alter queries in downstream route steps. No public exploit identified at time of analysis; EPSS is low (0.19%, 9th percentile) and CISA SSVC lists exploitation as none, but the flaw is remotely reachable without credentials when the NATS server runs with its default (no-auth) configuration.

Authentication token-lifetime bypass in the Apache Camel Keycloak component (camel-keycloak) affects versions 4.18.0-4.18.2 and 4.19.0-4.20.x, allowing expired or not-yet-valid Keycloak access tokens to be accepted as valid. The KeycloakSecurityHelper builds its TokenVerifier via withChecks() with only subject and issuer checks, so Keycloak's IS_ACTIVE exp/nbf validation is never installed, and any route relying on this helper will trust tokens outside their intended lifetime. NVD scores it CVSS 9.8, though EPSS is low (0.15%, 5th percentile) and there is no public exploit identified at time of analysis.

Unauthenticated Camel control-header injection in Apache Camel's camel-cometd component (4.0.0 before 4.14.8, 4.15.0 before 4.18.3, and 4.19.0 before 4.21.0) lets any client that completes a Bayeux/CometD handshake inject internal headers such as CamelHttpUri, CamelFileName or CamelJmsDestinationName into the Camel Exchange, hijacking the behaviour of downstream producers. Because a CometdComponent installs no Bayeux SecurityPolicy by default, no authentication is required (PR:N), and the injected headers survive internal direct/seda/vm hops. Reported by Apache with a fix in 4.21.0; there is no public exploit identified at time of analysis and EPSS is low at 0.19% (9th percentile).

Authorization bypass in Apache Camel's camel-elasticsearch-rest-client component allows unauthenticated remote attackers to override Elasticsearch query operations by injecting HTTP headers. Because the component uses unprefixed header constants ('SEARCH_QUERY', 'OPERATION', 'INDEX_NAME', 'INDEX_SETTINGS', 'ID') that are not blocked by Camel's inbound HttpHeaderFilterStrategy - which filters only 'Camel'-prefixed names - any HTTP client reaching a Camel route that fronts an elasticsearch-rest-client producer can substitute their own query body, operation type, or target index. Practical outcomes include full index enumeration via match_all, targeted document deletion, and field-level data exfiltration. No public exploit has been identified at time of analysis and this CVE is not listed in CISA KEV, but the attack requires no credentials and is trivially reproducible from the description alone.

Remote code execution in the Apache Camel camel-hazelcast component allows an attacker who can join or reach the Hazelcast cluster to run arbitrary code on every Camel node. The flaw exists because Camel-created Hazelcast instances apply no Java deserialization filter by default, so crafted serialized objects sent over the cluster protocol are deserialized (ObjectInputStream.readObject) before Camel processes them. It affects Camel 4.0.0-4.14.7, 4.15.0-4.18.2, and 4.19.0-4.20.x whenever a hazelcast consumer or repository uses Camel's own default configuration; there is no public exploit identified at time of analysis and EPSS is low (0.49%, 39th percentile).

Blind out-of-band data exfiltration in Apache Camel 4.14.0-4.20.x arises because the default ObjectInputFilter pattern bundled with several components ('java.**;javax.**;org.apache.camel.**;!*') uses a recursive java.** glob that allow-lists java.net.URL and java.net.InetAddress. Remote attackers who can deliver a Java-serialized payload to an affected Camel consumer - most notably the camel-jms family, where JmsBinding.extractBodyFromJms calls ObjectMessage.getObject() by default (mapJmsMessage=true) - can force the JVM to issue DNS queries to an attacker-controlled host during deserialization side-effects, yielding an observable out-of-band channel. Reported by Apache; there is no public exploit identified at time of analysis, EPSS is low (0.31%, 23rd percentile), and it is not listed in CISA KEV.

Remote code execution in Apache Camel's camel-vertx-http component (4.0.0-4.14.7, 4.15.0-4.18.2, 4.19.0) arises when a producer endpoint deserializes 5xx HTTP response bodies marked application/x-java-serialized-object through a raw java.io.ObjectInputStream with no class filtering. Exploitation is limited to non-default deployments where transferException=true or allowJavaSerializedObject=true is set and throwExceptionOnFailure remains true, letting an attacker who controls or intercepts the backend deliver a malicious serialized object and, given a gadget chain on the classpath, run code on the Camel host. This is a vendor-reported (Apache) issue with a publicly available advisory; there is no public exploit identified at time of analysis and EPSS is low at 0.39% (31st percentile).

Argument injection and directory traversal in Apache Camel's camel-docling component (4.15.0 before 4.18.3) let attackers who can influence the CamelDoclingCustomArguments or path-bearing exchange headers inject unintended docling CLI flags and traversal-laden path values into the externally executed docling tool. Because the original DoclingProducer validation relied on a flag denylist and only rejected literal '../' sequences, crafted arguments could reach the subprocess and resolve files outside the intended directory, yielding high confidentiality and integrity impact but no OS command injection (ProcessBuilder uses the list form, so no shell interprets the values). There is no public exploit identified at time of analysis and the flaw is not in CISA KEV; EPSS is low (0.79%, 52nd percentile).

Improper input validation (CWE-20) in the camel-aws2-sns component of Apache Camel stems from a missing inbound HeaderFilterStrategy rule on Sns2HeaderFilterStrategy, mirroring the flaw fixed in the sibling camel-aws2-sqs component (CVE-2026-46456). However, camel-aws2-sns is producer-only - Sns2Endpoint throws UnsupportedOperationException on createConsumer - so no externally-supplied SNS message attributes are ever mapped inbound into a Camel Exchange, leaving the missing filter rule unreachable by any attacker. Despite the NVD CVSS 9.8 rating, the vendor explicitly classifies this as a defense-in-depth alignment with no known exploit path, and EPSS scores it at just 0.16% (6th percentile); no public exploit identified at time of analysis.

Camel-internal control header injection in the Apache Camel AWS2-SQS component (camel-aws2-sqs) lets any principal holding sqs:SendMessage on a consumed SQS queue override downstream producer behaviour in a route. Because Sqs2HeaderFilterStrategy defined only an outbound filter and no inbound filter, DefaultHeaderFilterStrategy copied sender-supplied attributes such as CamelHttpUri, CamelFileName and CamelSqlQuery verbatim into the Exchange, so an attacker can redirect HTTP producers, rename files or override SQL queries. This is a design flaw with no public exploit identified at time of analysis; EPSS is low (0.16%, 6th percentile) and it is not on CISA KEV.

Information disclosure in Apache Camel's camel-undertow HTTP server consumer (versions 4.0.0 through 4.21.0) exposes complete Java stack traces to unauthenticated HTTP clients whenever a route processing exception occurs, due to a misconfigured default and a code-level bypass. Unlike every other Camel HTTP server component (camel-http, camel-jetty, camel-servlet, camel-platform-http), all of which default muteException to true, camel-undertow defaulted this option to false - and for Rest DSL consumers the option was silently ignored entirely due to a hard-coded false in RestUndertowHttpBinding, meaning muteException=true gave false confidence without actual protection. No public exploit has been identified at time of analysis; however exploitation requires only the ability to send a malformed HTTP request to a reachable endpoint, making this trivially accessible to any network-level attacker.

Server-side request forgery and secret disclosure in the Apache Camel camel-iggy consumer (versions 4.17.0-4.18.2 and 4.19.0-4.20.x) allow an actor able to publish to a consumed Iggy stream to inject Camel control headers such as CamelHttpUri into the Exchange. When the consumer feeds a downstream HTTP producer, the attacker redirects the server-side request to internal services or cloud metadata endpoints, and because the producer resolves Camel property placeholders on the attacker-controlled URI, environment variables, application properties, and vault secrets are exfiltrated. No public exploit identified at time of analysis, and EPSS is low (0.15%), but the confidentiality impact is rated High.

Server-side request forgery and secret disclosure in Apache Camel's camel-atmosphere-websocket component allow a remote attacker to hijack downstream server-side HTTP requests by injecting Camel control headers as WebSocket query parameters. Affecting Camel 4.0.0-4.14.7, 4.15.0-4.18.2 and 4.19.0-4.20.x, the flaw lets an attacker set CamelHttpUri to redirect internal HTTP calls (e.g., to cloud metadata endpoints) and force resolution of Camel property placeholders, leaking environment variables, application properties and vault secrets. Where the WebSocket endpoint is exposed without authentication the issue is unauthenticated (CVSS 7.5); there is no public exploit identified at time of analysis and EPSS is low (0.24%).

Authentication bypass in Apache Camel's camel-keycloak component (versions 4.15.0-4.18.2 and 4.19.0-4.20.x) allows any caller presenting a non-null Authorization: Bearer header value - including an arbitrary string or a forged, unsigned JWT - to bypass Keycloak token verification entirely and access routes protected by KeycloakSecurityPolicy. The cryptographic token checks (signature, issuer, expiry) are embedded exclusively inside role and permission validation routines that are never invoked when requiredRoles and requiredPermissions are empty, which is the documented default 'Basic Setup.' Where the protected route connects to a code-execution-capable Camel producer, this authentication bypass can escalate to unauthenticated remote code execution; no public exploit has been identified at time of analysis.

Stack trace disclosure in Apache Camel's camel-netty-http component (versions 4.0.0-4.21.0 across three release streams) exposes full Java Throwable stack traces to unauthenticated HTTP clients whenever a route processing error occurs under the default configuration. The root cause is an insecure default: the muteException option backed by an uninitialized Java primitive boolean defaulted to false in camel-netty-http while all other Camel HTTP server components (camel-http, camel-jetty, camel-servlet, camel-platform-http) correctly default it to true. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog, but the low-effort triggering condition - any malformed request that causes a route exception - makes opportunistic enumeration straightforward against exposed endpoints.

Header injection in Apache Camel's camel-salesforce component allows any HTTP client to override SOQL queries, SOSL searches, Salesforce object targets, and Apex REST endpoints by setting non-Camel-prefixed Exchange headers that the framework's HttpHeaderFilterStrategy fails to block. Routes that bridge an HTTP consumer (such as platform-http) into a salesforce: producer are the attack surface; when that HTTP consumer is unauthenticated, exploitation requires zero attacker credentials. All injected operations execute under the configured Salesforce integration user's permissions, which are typically broad, enabling unauthorized data exfiltration or destructive CRUD and Apex calls across the organization's Salesforce instance. No public exploit has been identified and the vulnerability is not listed in the CISA KEV catalog at time of analysis.

Header injection in Apache Camel's camel-kafka component allows HTTP clients to redirect Kafka messages to arbitrary topics in routes that bridge an HTTP consumer into a Kafka producer. The kafka.OVERRIDE_TOPIC, kafka.OVERRIDE_TIMESTAMP, and kafka.PARTITION_KEY Exchange header constants used non-CamelKafka-prefixed names, causing them to bypass HttpHeaderFilterStrategy - which blocks only the Camel/camel namespace - while remaining readable by KafkaProducer.evaluateTopic() as authoritative control directives. No public exploit code has been identified and no CISA KEV listing exists at time of analysis, but when the HTTP ingress is unauthenticated the attack requires only a standard HTTP client and a known Kafka topic name.

Header injection in Apache Camel's camel-irc component enables unauthenticated HTTP clients to redirect outgoing IRC messages to attacker-chosen channels or users by supplying non-Camel-prefixed headers (e.g., irc.sendTo) that Camel's HttpHeaderFilterStrategy fails to block. Affected versions span 4.0.0-4.14.7, 4.15.0-4.18.2, and 4.19.0-4.20.x; fixes are available in 4.14.8, 4.18.3, and 4.21.0. No public exploit code or CISA KEV listing exists at time of analysis, but the attack requires no credentials when the bridging HTTP consumer is unauthenticated, making it trivially reproducible against any qualifying deployment.

Routing header injection in Apache Camel's camel-dapr component allows any actor with publish access to a subscribed Dapr Pub/Sub topic to redirect or exfiltrate re-published messages to an arbitrary Dapr Pub/Sub component and topic. The flaw exists in routes that both consume and republish via Dapr - specifically, DaprPubSubConsumer blindly copies attacker-controlled CloudEvent fields (pub/sub-name and topic) into producer-direction routing headers (CamelDaprPubSubName and CamelDaprTopic), which DaprConfigurationOptionsProxy then prefers over the route's configured endpoint destination. No public exploit code or CISA KEV listing exists at time of analysis, but exploitation is mechanically straightforward for any publisher on the subscribed topic.

Authorization bypass in Apache Camel's camel-jira component (versions 4.0.0 through pre-4.21.0) allows unauthenticated HTTP clients - in routes that bridge an HTTP consumer to a jira: producer - to drive arbitrary JIRA issue operations using the endpoint's configured service-account credentials, including deleting or transitioning issues, creating issues in unauthorized projects, modifying fields, and manipulating watchers. The root cause is that JIRA control header constants (IssueKey, ProjectKey, IssueTransitionId, linkType, and others) use non-Camel-prefixed string values, bypassing the HttpHeaderFilterStrategy which only guards the 'Camel/'/'camel' header namespace at the HTTP boundary. Fixes are confirmed in 4.14.8, 4.18.3, and 4.21.0; no public exploit has been identified at time of analysis, and this vulnerability is not listed in CISA KEV.

Server-side request forgery in the Apache Camel camel-dns component lets any HTTP client control DNS lookups when a route bridges an HTTP consumer (e.g. platform-http) into a dns: producer. Because the dns.server, dns.name, dns.domain, dns.type, dns.class and term headers lack the Camel/camel prefix, HttpHeaderFilterStrategy does not strip them at the HTTP boundary, so an attacker can point the resolver at an attacker-controlled DNS server and enumerate internal hostnames. It affects Camel 4.0.0-4.14.7, 4.15.0-4.18.2 and 4.19.0-4.20.x; no public exploit identified at time of analysis, and EPSS is low (0.15%), but SSVC rates the flaw automatable with total technical impact.

Unauthenticated NoSQL operation hijacking in Apache Camel's camel-mongodb-gridfs component (4.0.0-4.14.7, 4.15.0-4.18.2, 4.19.0-4.20.x) lets a remote HTTP client override the intended GridFS operation and inject MongoDB query documents. When a route bridges an HTTP consumer such as platform-http into a mongodb-gridfs: producer that has no explicit operation set (the default), the raw gridfs.operation, gridfs.objectid and gridfs.metadata headers pass through the HTTP header filter because they lack the Camel/camel prefix, allowing an attacker to turn an intended upload into remove, listAll, or findOne and to inject NoSQL operators. There is no public exploit identified at time of analysis and EPSS is low (0.16%), but CVSS is 9.8 and SSVC rates technical impact as total and automatable.

Server-side request forgery and parameter/field injection in the Apache Camel camel-solr component (versions 4.0.0 through 4.14.7, 4.15.0 through 4.18.2, and 4.19.0 through 4.20.x) allow remote attackers to hijack Solr requests issued by a Camel route. Because the SolrParam. and SolrField. header prefixes lack the Camel/camel namespace, HttpHeaderFilterStrategy does not strip them at the HTTP boundary, so any client hitting a route that bridges an HTTP consumer (e.g. platform-http) into a solr: producer can inject arbitrary Solr parameters - notably shards or stream.url to force the Solr server into attacker-chosen outbound requests (internal services, cloud metadata endpoints), or qt to reach admin handlers - and inject arbitrary indexed-document fields. Rated CVSS 9.1; there is no public exploit identified at time of analysis and EPSS is low (0.18%), but SSVC marks the flaw as automatable with total technical impact.

Server-side request forgery and secret disclosure in Apache Camel's camel-vertx-websocket component (versions 4.0.0-4.14.7, 4.15.0-4.18.2, and 4.19.0-4.20.x) let a WebSocket client inject Camel-internal control headers such as CamelHttpUri because inbound query/path parameters are copied into the Exchange header map without a HeaderFilterStrategy. In routes that bridge the WebSocket consumer into a downstream HTTP producer, an attacker can redirect the server-side HTTP request to internal services or cloud metadata endpoints, and because the HTTP producer resolves Camel property placeholders on the attacker-supplied URI, environment variables, application properties, and vault secrets are resolved and exfiltrated. When the WebSocket endpoint is exposed without authentication (PR:N per CVSS), this is reachable by an unauthenticated remote attacker; there is no public exploit identified at time of analysis, and EPSS is low at 0.24%.

Path traversal in Apache Airflow's Google provider (apache-airflow-providers-google before 22.2.1) lets a principal with write access to a source GCS bucket overwrite arbitrary files on the SFTP server (GCSToSFTPOperator) or the worker host (GCSTimeSpanFileTransformOperator) by crafting a GCS object name containing `..` segments. Because the bucket writer is frequently a lower-trust party than the DAG author (partner uploads, ingest-only service accounts, public-data buckets), exploitation crosses a trust boundary that operators may not have modeled. No public exploit is identified at time of analysis, and CISA SSVC rates exploitation as none, so this is a real but non-default, targeted-risk integrity flaw rather than a mass-exploitable one.

XML External Entity injection in Apache Lucene.Net's PatternParser component (Lucene.Net.Analysis.Common library) allows attackers who can supply XML input to the parser to read arbitrary files from the host filesystem or trigger server-side request forgery. Affected deployments span versions 4.8.0-beta00005 through 4.8.0-beta00017. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV, but the well-understood XXE attack class combined with the availability of a fix version makes patching straightforward and strongly advisable.

Path traversal in the Apache Lucene.Net.Replicator library (versions 4.8.0-beta00005 through 4.8.0-beta00017) allows a remote, unauthenticated attacker to read files outside the intended index-replication directory by supplying crafted pathnames during index synchronization. The flaw is a CWE-22 restricted-directory bypass confined to file disclosure; there is no public exploit identified at time of analysis and it is not listed in CISA KEV, though the vendor-supplied CVSS 4.0 base score of 8.9 reflects high confidentiality impact across a scope boundary. Exploitation is gated by high attack complexity and specific attack requirements, making practical abuse less trivial than the raw score suggests.

Path traversal (CWE-22) in the Apache Lucene.Net.Replicator library lets remote attackers read files outside the intended index directory by supplying crafted pathnames to the replication service, disclosing arbitrary server-side files. All releases from 4.8.0-beta00005 through 4.8.0-beta00017 are affected, and Apache fixed it in 4.8.0-beta00018. There is no public exploit identified at time of analysis and it is not in CISA KEV, but the CVSS 4.0 base score of 8.9 (High) reflects unauthenticated network access and high confidentiality impact including a subsequent-system scope change.

IP header spoofing in GoFiber's BalancerForward proxy middleware allows any remote unauthenticated attacker to inject a forged X-Real-IP header that upstream servers treat as authoritative. The middleware calls Header.Add() rather than Header.Set() when stamping the real client IP, causing the attacker-supplied value to remain as the first header instance - the one read by nginx, Express, Apache, and most HTTP servers for rate limiting, IP-based ACLs, and audit logging. No public exploit has been identified at time of analysis, but exploitation requires only the ability to set an arbitrary HTTP header, making this trivially accessible to any network attacker targeting deployments using the BalancerForward helper.

Denial of service in Apache HttpComponents Core (HttpCore) 5.0-alpha through 5.4.2 and the 5.5 beta line up to 5.5-beta1 allows a remote unauthenticated attacker to exhaust server memory by sending HTTP/1.1 messages containing an excessive number of headers or excessively long headers. The HTTP/1.1 message parser accumulates this header data without enforcing sane bounds, letting a single crafted request drive availability loss (CVSS 7.5, A:H only). There is no public exploit identified at time of analysis, and CISA's SSVC assessment rates exploitation as 'none' with only partial technical impact.

Memory exhaustion denial-of-service in Apache HttpComponents Core's HTTP/2 HPACK decoder allows remote attackers to crash Java services by sending oversized compressed header blocks before the HTTP/2 SETTINGS acknowledgement is processed. The root cause is a timing gap in the connection handshake: the server's configured maximum header list size limit is not enforced until after the SETTINGS ACK exchange completes, leaving a window during which an attacker can flood the decoder with arbitrarily large compressed header data. Affected artifacts are org.apache.httpcomponents.core5:httpcore5-h2 versions 5.4.2 and earlier and 5.5-beta1 and earlier. No public exploit or CISA KEV listing has been identified at time of analysis.

Remote code execution risk in c3p0 versions prior to 0.14.0 arises from the library serving as an essential 'sink' in Java deserialization gadget chains. c3p0's DataSource and ConnectionPoolDataSource objects conform to JavaBean's getXXX() naming convention, causing commons-beanutils and similar libraries to invoke JDBC connection methods as though they were safe property accessors during deserialization - triggering arbitrary JDBC driver execution under attacker control. No public exploit code or CISA KEV listing has been identified at time of analysis; the CVSS 4.0 vector scores this at 6.3, largely due to the partial attack requirements (AT:P), though real-world impact when prerequisites are met can substantially exceed that rating.

Improper input validation in Apache ActiveMQ lets an attacker who can write or modify LDAP entries matching the broker's configured searchBase and searchFilter instantiate transports that are otherwise denied inside the broker JVM. By doing so the attacker can force the broker to fetch an attacker-controlled URL and spawn a second BrokerService within the same JVM, an integrity-impacting condition affecting Apache ActiveMQ, ActiveMQ Broker, and ActiveMQ All before 5.19.8 and 6.x before 6.2.7. There is no public exploit identified at time of analysis and the issue is not listed in CISA KEV.

Denial-of-service in Apache ActiveMQ STOMP connectors lets a remote peer that can reach an exposed STOMP port crash or exhaust the broker by sending a negative content-length value. On the NIO STOMP transport the attacker streams body bytes to grow the per-connection command buffer past configured limits and force an out-of-memory condition, while the blocking STOMP transport instead throws an abnormal transport exception that closes the affected connection. The flaw affects ActiveMQ, ActiveMQ All, and ActiveMQ Stomp before 5.19.8 and the 6.0.0-6.2.6 line; no public exploit identified at time of analysis and the issue is not listed in CISA KEV.