An Improper Neutralization of Special Elements Used in a Template Engine (CWE-1336) vulnerability exists in org.jdbi:jdbi3-freemarker through version 3.52.1. This flaw allows arbitrary command execution when attacker-controlled text reaches the FreeMarker template engine via jdbi3-freemarker's SQL templating. The vulnerability arises because the FreeMarker configuration used does not restrict reflective Java class instantiation, enabling exploitation through the ?new built-in. The issue is fixed in version 3.53.0.
Quarkus is a Java framework for building cloud-native applications. In versions prior to 3.20.6.1, 3.27.3.1, 3.33.1.1, 3.35.1.1, 3.34.7, and 3.35.2, a path normalization inconsistency between the security layer and the routing layer allows unauthenticated or lower-privileged users to bypass HTTP path-based authorization policies. Quarkus's security layer performs authorization checks on the raw URL path which preserves matrix parameters (semicolons), while RESTEasy Reactive's routing layer strips matrix parameters before matching endpoints. An attacker can append a semicolon and arbitrary text to a request URL (e.g., /api/admin;anything) to bypass policies protecting /api/admin while still routing to the protected endpoint. This issue has been fixed in versions 3.20.6.1, 3.27.3.1, 3.33.1.1, 3.35.1.1, 3.34.7, and 3.35.2.
The pgjdbc PostgreSQL JDBC driver is vulnerable to a client-side denial of service (DoS) during SCRAM-SHA-256 authentication. A malicious or compromised PostgreSQL server can specify an excessively large PBKDF2 iteration count, causing the client to spend an unbounded amount of CPU time computing the key derivation function. This can exhaust CPU resources on the client, especially with repeated or concurrent connection attempts. The vulnerability affects versions from 42.2.0 up to but not including 42.7.11. A patch is available in version 42.7.11 that caps the maximum allowed PBKDF2 iterations. The issue impacts availability but does not allow authentication bypass or data disclosure.
The PlantUML Macro extension for XWiki is vulnerable to Server-Side Request Forgery (SSRF) due to lack of validation on the 'server' parameter that specifies an alternative PlantUML server. This allows attackers to supply internal or malicious external URLs, causing the XWiki server to connect to unintended targets. Versions prior to 2.4.1 are affected. The issue is fixed in version 2.4.1 by restricting the server parameter to trusted domains configured in XWiki.
Eclipse BaSyx Java Server SDK versions prior to 2.0.0-milestone-10 contain a Server-Side Request Forgery (SSRF) vulnerability in the Operation Delegation feature. This flaw allows unauthenticated remote attackers to make the server send HTTP POST requests to arbitrary internal or external destinations without validating the destination URI. Exploitation can enable attackers to bypass network segmentation and access isolated internal IT/OT infrastructure or cloud metadata services. A fix is available in version 2.0.0-milestone-10.
Eclipse BaSyx Java Server SDK versions before 2.0.0-milestone-10 contain a path traversal vulnerability in the Submodel HTTP API. An unauthenticated attacker can exploit this by supplying a crafted fileName parameter during file upload to write arbitrary files outside intended directories. This can lead to remote code execution and full system compromise. A fix is available in version 2.0.0-milestone-10.
Netty's DefaultHttpRequest and DefaultFullHttpRequest classes allow bypassing URI validation when the URI is changed via the setUri() method after object creation. This leads to CRLF injection enabling HTTP request smuggling and RTSP request injection. The issue arises because constructors validate the URI to prevent injection, but setUri() does not. Consequently, malicious input passed to setUri() is encoded verbatim by HttpRequestEncoder or RtspEncoder, allowing injection of additional requests. Proof-of-concept code demonstrates how multiple HTTP or RTSP requests can be injected and parsed from a single request line.
Apache Polaris before version 1.4.1 has an improper input validation vulnerability (CVE-2026-42811) that allows crafted namespace or table names to bypass intended Google Cloud Storage (GCS) credential restrictions. This flaw causes the downscoped credentials, which should be limited to a single table's files, to instead grant access across the entire configured bucket. The vulnerability arises from unescaped user input in the CEL expression used to restrict access, enabling attackers to break out of the intended scope. This can lead to unauthorized listing, reading, creating, and deleting of objects beyond the authorized table path, including unrelated prefixes within the bucket. A fix is available in Apache Polaris version 1.4.1.
Apache Polaris versions prior to 1.4.1 improperly handle literal '*' characters in namespace and table names when generating temporary AWS S3 access policies. This leads to wildcard expansion in S3 IAM resource patterns and s3:prefix conditions, allowing delegated credentials for crafted table names to access other tables' S3 storage paths. Confirmed impacts include unauthorized reading of table metadata JSON files, listing of table prefixes, and, in some cases, creation and deletion of objects in other tables' storage locations. This vulnerability affects confidentiality, integrity, and availability of data stored in S3 for Polaris tables.
Apache Polaris runtime service versions prior to 1.4.1 contain an improper input validation vulnerability (CVE-2026-42809) that allows an attacker to influence the scope of temporary storage credentials issued during staged table creation. By supplying a custom location or overriding write paths, attackers can cause the system to issue delegated storage credentials scoped to attacker-chosen locations without proper validation or overlap checks. This can lead to unauthorized access to table data and metadata. A fix is available in version 1.4.1.
Apache OpenNLP AbstractModelReader in versions before 2.5.9 and before 3.0.0-M3 contains a vulnerability where unbounded array allocation can cause an OutOfMemoryError. This occurs because certain count fields read from a binary model file are not validated before being used to allocate arrays, allowing an attacker to supply a crafted model file that triggers heap exhaustion and crashes the JVM process. The issue affects any code path that deserializes .bin model files, leading to denial of service. Fixed in versions 2.5.9 and 3.0.0-M3.
XML External Entity (XXE) via Unsanitized Dictionary Parsing in Apache OpenNLP DictionaryEntryPersistor
Versions Affected: before 2.5.9, before 3.0.0-M3
Description: The DictionaryEntryPersistor class initializes a static SAXParserFactory at class-load time without enabling FEATURE_SECURE_PROCESSING or disabling DTD processing. When create(InputStream, EntryInserter) is invoked, the only feature set on the XMLReader is namespace support — external entity resolution and DOCTYPE declarations remain fully enabled. An attacker who can supply a crafted dictionary file (e.g., a stop-word list or domain dictionary) containing a malicious DOCTYPE declaration can trigger local file disclosure via file:// entity references or server-side request forgery via http:// entity references during SAX parsing, before the application processes a single dictionary entry. This is inconsistent with the project's own XmlUtil.createSaxParser() helper, which correctly sets FEATURE_SECURE_PROCESSING and disallow-doctype-decl and is used by all other XML parsing paths in the codebase. The public Dictionary(InputStream) constructor delegates directly to this method and is the documented API for loading user-supplied dictionaries, making untrusted input a realistic scenario.
Mitigation: 2.x users should upgrade to 2.5.9. 3.x users should upgrade to 3.0.0-M3. Users who cannot upgrade immediately should ensure that all dictionary files are sourced from trusted origins and should consider wrapping the Dictionary(InputStream) constructor with input validation that rejects any XML containing a DOCTYPE declaration before it reaches the parser.
Apache Atlas versions from 0.8-incubating through 2.4.0 contain a code injection vulnerability in the DSL search endpoint. This flaw allows an attacker to manipulate Gremlin traversal logic via user-supplied query strings to access unintended data. The vulnerability is exploitable in versions 2.0.0 and later only if the non-default configuration 'atlas.dsl.executor.traversal=false' is set. The issue is fixed in version 2.5.0.
OpenMRS web module upload functionality in versions up to 2.7.8 is vulnerable to a path traversal (Zip Slip) attack via the REST API endpoint POST /openmrs/ws/rest/v1/module. An authenticated attacker can upload a crafted .omod archive with malicious ZIP entries that bypass incomplete path validation, allowing arbitrary file write outside the intended directory. This can lead to remote code execution if a malicious JSP file is written to the web application root. The vulnerability arises from improper path normalization in WebModuleUtil.startModule(), while other extraction methods in the codebase correctly implement such checks. Additionally, the runtime property intended to restrict module management via the web UI does not apply to this REST endpoint, allowing bypass of restrictions.
OpenMRS Core versions up to 2.7.8 have a path traversal vulnerability in the ModuleResourcesServlet, allowing unauthenticated attackers to read arbitrary files on the server. This occurs because the servlet does not properly validate user-supplied paths, enabling directory traversal outside the intended module resource directories. Exploitation requires the server to run on Apache Tomcat versions earlier than 8.5.31, as later versions mitigate the bypass at the container level. A fix is available in OpenMRS version 2.8.6.
Arbitrary Class Instantiation via Model Manifest in Apache OpenNLP ExtensionLoader
Versions Affected: before 1.9.5, before 2.5.9, before 3.0.0-M3
Description:
The ExtensionLoader.instantiateExtension(Class, String) method loads a class by its fully-qualified name via Class.forName() and invokes its no-arg constructor, with the class name sourced from the manifest.properties entry of a model archive. The existing isAssignableFrom check correctly rejects classes that are not subtypes of the expected extension interface (BaseToolFactory for factory=, ArtifactSerializer for serializer-class-*), but the check runs after Class.forName() has already loaded and initialized the named class.
Class.forName() with default initialization semantics executes the target class's static initializer before returning, so an attacker who can supply a crafted model archive can cause the static initializer of any class on the classpath to run during model loading, regardless of whether that class passes the subsequent type check.
Exploitation requires a class with attacker-useful side effects in its static initializer (for example, JNDI lookup, outbound network I/O, or filesystem access) to be present on the classpath, so this is not a drop-in remote code execution; however, the attack surface grows as third-party model distribution becomes more common (community model repositories, Hugging Face-style sharing), where users routinely load model files from origins they do not control. A secondary, narrower vector affects deployments that ship legitimate BaseToolFactory or ArtifactSerializer subclasses with side-effecting no-arg constructors: a malicious manifest can name such a class and force its constructor to run during model load.
Mitigation:
* 2.x users should upgrade to 2.5.9.
* 3.x users should upgrade to 3.0.0-M3.
Note: The fix introduces a package-prefix allowlist that is consulted before Class.forName() is invoked, so the static initializer of a disallowed class is never executed. Classes under the opennlp. prefix remain permitted by default. Deployments that load models referencing factories or serializers outside opennlp.* must opt those packages in, either programmatically via ExtensionLoader.registerAllowedPackage(String) before the first model load, or by setting the OPENNLP_EXT_ALLOWED_PACKAGES system property to a comma-separated list of allowed package prefixes.
Users who cannot upgrade immediately should ensure that all model files are sourced from trusted origins and should audit their classpath for classes with side-effecting static initializers or constructors, particularly any that perform JNDI lookups, network requests, or filesystem operations during class initialization.
jOpenDocument version 1.5 and earlier contains an improper restriction of XML external entity references, leading to a vulnerability classified as CWE-611. This flaw allows for Data Serialization External Entities Blowup, which can be exploited to cause resource exhaustion or other impacts related to XML external entity processing. The vulnerability has a medium severity rating with a CVSS 4.0 score of 5.3. No public exploits or known active exploitation have been reported. No official patch or remediation information is provided in the available data.
Apache MINA versions 2.1.0 through 2.1.11 and 2.2.0 through 2.2.6 are vulnerable to a deserialization flaw due to an incomplete fix for CVE-2026-41635. The vulnerability arises because the classname allowlist check is bypassed for static classes or primitive types in AbstractIoBuffer.resolveClass(), allowing arbitrary code execution when IoBuffer.getObject() is called. This issue is resolved in versions 2.1.12 and 2.2.7 by applying the classname allowlist earlier in the deserialization process. Users of affected versions are advised to upgrade to the fixed releases.
Apache MINA versions 2.1.0 through 2.1.11 and 2.2.0 through 2.2.6 are vulnerable to deserialization of untrusted data due to an incomplete fix for a previous vulnerability (CVE-2024-52046). The classname allowlist intended to restrict deserialization was applied too late, allowing unsafe deserialization to occur. This issue is resolved in versions 2.1.12 and 2.2.7 by applying the allowlist earlier in the deserialization process. Applications using Apache MINA that call IoBuffer.getObject() should upgrade to the fixed versions to mitigate this critical vulnerability.
Apache Neethi versions prior to 3.2.2 do not restrict URIs when manually fetching remote policy references via the PolicyReference API. This allows outbound requests to arbitrary protocols and internal IP addresses. Version 3.2.2 introduces restrictions allowing only http or https URIs and forbids link-local, multicast, and any-local addresses. Users should upgrade to 3.2.2 to address this issue.