Our news and updates

In Elasticsearch versions up to 8.19.16/9.3.5/9.4.2 a medium severity vulnerability CVE-2026-56149 was detected. This vulnerability allows an authenticated user with elevated privileges to cause a Denial of Service (DoS) by rendering the affected node unavailable. This occurs due to an Allocation of Resources Without Limits or Throttling (CWE-770) flaw in the processing of machine learning requests. By submitting a specially crafted machine learning request, an attacker can trigger excessive memory allocation (CAPEC-130), leading to resource exhaustion and the subsequent unavailability of the Elasticsearch node. There’s no fix available for this issue at the moment. For more details, visit https://nvd.nist.gov/vuln/detail/CVE-2026-56149.

In Docling versions 2.45.0 to before 2.91.0 a medium severity vulnerability CVE-2026-44018 was detected. This vulnerability allows an attacker to read sensitive files, exhaust system resources, or cause application crashes, leading to unauthorized information disclosure and Denial of Service (DoS). This occurs due to unsafe archive extraction and a lack of security controls during XML parsing in the METS-GBS backend. By crafting a malicious METS-GBS archive and exploiting the input document format detection mechanisms (such as via XML External Entity (XXE) injection or archive bombs), an attacker can compromise the parsing process. To address this issue, users should upgrade Docling to version 2.91.0 or later. For more details, visit https://nvd.nist.gov/vuln/detail/CVE-2026-44018.

In ChromaDB versions 0.4.17 and later a high severity vulnerability CVE-2026-45833 was detected. This vulnerability allows an authenticated attacker with UPDATE_COLLECTION permissions to execute arbitrary code on the server, leading to Remote Code Execution (RCE). This occurs due to a code injection flaw when the application handles model repositories. By sending a malicious model repository to the /api/v2/tenants/default_tenant/databases/default_database/collections/{collection_id} endpoint and setting the trust_remote_code parameter to true, an attacker can trick the system into executing their malicious payload.There’s no fix available for this issue at the moment. For more details, visit https://nvd.nist.gov/vuln/detail/CVE-2026-45833.

In Appsmith versions prior to 2.1 a high severity vulnerability CVE-2026-50189 was detected. This vulnerability allows an authenticated administrator to execute arbitrary OS commands inside the Docker container, leading to Remote Code Execution (RCE). This occurs because the bundled supervisord exposes an XML-RPC interface that is reachable from outside the container via a Caddy reverse-proxy route at /supervisor/*. Additionally, the required authentication password (APPSMITH_SUPERVISOR_PASSWORD) is inadvertently exposed via the GET /api/v1/admin/env endpoint. By combining these issues, an attacker can retrieve the password, authenticate, and send maliciously crafted XML-RPC calls (such as twiddler.addProgramToGroup) to execute commands on the underlying system. To address this issue, users should upgrade Appsmith to version 2.1 or later. For more details, visit https://nvd.nist.gov/vuln/detail/CVE-2026-50189.

In Budibase versions prior to 3.39.12 a critical severity vulnerability CVE-2026-54350 was detected. This vulnerability allows an unauthenticated attacker to read or modify all documents within the backing databases (such as MongoDB, CouchDB, Elasticsearch, or DynamoDB). This occurs due to a NoSQL operator injection flaw when processing published-app query templates. The application fails to properly escape JSON metacharacters (such as quotes and braces) when substituting user-controlled parameters into the raw JSON query body. By injecting these characters, an attacker can manipulate the parsed JSON object to include NoSQL operators (e.g., $exists: true), overriding the intended filters and expanding the query scope to the entire collection. Furthermore, endpoints associated with PUBLIC queries do not enforce CSRF protection or require an active session. To address this issue, users should upgrade Budibase to version 3.39.12 or later. For more details, visit https://nvd.nist.gov/vuln/detail/CVE-2026-54350.

In Helm versions 4.0.0 to before 4.1.4 a high severity vulnerability CVE-2026-35204 was detected. This vulnerability allows an attacker to write the contents of a plugin to arbitrary filesystem locations outside the designated Helm plugin directory. This occurs due to a path traversal flaw when installing or updating a specially crafted Helm plugin. If the version field within the plugin’s plugin.yaml file contains POSIX dot-dot path separators (e.g., /../), Helm fails to properly sanitize the path before writing files. To address this issue, users should upgrade Helm to version 4.1.4 or later. As a temporary workaround, users can manually validate that the plugin.yaml of any Helm plugin does not include path separators in the version field before installation. For more details, visit https://nvd.nist.gov/vuln/detail/CVE-2026-35204.

In Docling versions prior to 2.91.0 a high severity vulnerability CVE-2026-44017 was detected. This vulnerability allows an attacker to write arbitrary files to any location writable by the process, potentially leading to Remote Code Execution (RCE) or persistent backdoors. This occurs due to a Zip Slip flaw in the EasyOCR model download functionality, where ZIP archives are extracted without properly validating member paths. If an attacker successfully compromises the model download source—such as through a supply chain attack, DNS spoofing, or a Man-in-the-Middle (MITM) attack—they can deliver a maliciously crafted ZIP file containing directory traversal sequences. To address this issue, users should upgrade Docling to version 2.91.0 or later. For more details, visit https://nvd.nist.gov/vuln/detail/CVE-2026-44017.

In Gogs versions prior to 0.14.3 a critical severity vulnerability CVE-2026-52811 was detected. This vulnerability allows an authenticated attacker with repository write access to write files outside the repository working tree, potentially leading to Remote Code Execution (RCE) or unauthorized SSH access. This occurs due to improper symlink validation in the UploadRepoFiles function, which only checks for symlinks at the leaf of the upload target rather than evaluating the entire path. By committing a parent directory symlink and then crafting a multipart upload with a filename containing a literal backslash (which gets converted to a directory separator), an attacker can redirect the file write through the symlink. Because the system opens the destination without preventing symlink following (missing O_NOFOLLOW), the attacker can overwrite sensitive files anywhere the gogs user has write permissions, such as ~git/.ssh/authorized_keys for SSH access or <repo>.git/hooks/post-receive for RCE on the next push. To address this issue, users should upgrade Gogs to version 0.14.3 or later. For more details, visit https://nvd.nist.gov/vuln/detail/CVE-2026-52811.

In Gitea versions before 1.25.4 a critical severity vulnerability CVE-2026-20897 was detected. This vulnerability allows an authenticated user with write access to one repository to delete Git LFS locks belonging to other repositories, leading to unauthorized data modification and broken access control. This occurs due to an Insecure Direct Object Reference (IDOR) flaw, where the application does not properly validate repository ownership during the Git LFS lock deletion process. To address this issue, users should upgrade Gitea to a patched version 1.25.4 or later. For more details, visit https://nvd.nist.gov/vuln/detail/CVE-2026-20897.