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.
Read more Data Analytics
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.
Read more Developer Tools
In Backstage (@backstage/plugin-techdocs-node) versions prior to 1.13.11 and 1.14.1 a high severity vulnerability CVE-2026-25153 was detected. This vulnerability allows an attacker to execute arbitrary Python code on the TechDocs build server, leading to Remote Code Execution (RCE). This occurs when TechDocs is configured with runIn: local and a malicious actor modifies a repository’s mkdocs.yml file to include malicious MkDocs hooks. To address this issue, users should upgrade @backstage/plugin-techdocs-node to versions 1.13.11, 1.14.1, or later, which introduce an allowlist that strips unsupported configuration keys like hooks. Alternatively, users can mitigate the risk by configuring TechDocs with runIn: docker or using MkDocs versions prior to 1.4.0. For more details, visit https://nvd.nist.gov/vuln/detail/CVE-2026-25153.
In GitBucket versions up to 4.46.1 a medium severity vulnerability CVE-2026-13540 was detected. This vulnerability allows a remote attacker to perform Server-Side Request Forgery (SSRF), potentially gaining unauthorized access to internal network resources. This occurs due to improper handling of the url argument within the Git.cloneRepository.setURI function in the src/main/scala/gitbucket/core/service/RepositoryCreationService.scala file. By supplying a maliciously crafted URL during repository cloning or creation, an attacker can coerce the server into making unintended network requests. A public exploit has been released, which heightens the risk of active attacks. To address this issue, users should apply the vendor-supplied patch (commit 487a9b980f56aa73b6a044b1e86a92eed5043215) or upgrade to a patched release 4.46.2 (or later). For more details, visit https://nvd.nist.gov/vuln/detail/CVE-2026-13540.
In Appsmith versions prior to 1.99 a low severity vulnerability CVE-2026-49979 was detected. This vulnerability allows an attacker to perform Server-Side Request Forgery (SSRF), internal port scanning, and service banner enumeration. This occurs because the POST /api/v1/admin/send-test-email endpoint accepts user-controlled smtpHost and smtpPort parameters and establishes a raw JavaMail TCP connection without any IP validation. This completely bypasses the WebClientUtils.IP_CHECK_FILTER, which only applies to Spring WebClient HTTP requests. Furthermore, the endpoint returns the raw MailException.getMessage() verbatim in the API error response, leaking internal network details to the attacker. To address this issue, users should upgrade Appsmith to version 1.99 or later. For more details, visit https://nvd.nist.gov/vuln/detail/CVE-2026-49979.
In Argo Workflows versions prior to 3.7.14 and 4.0.5 a high severity vulnerability CVE-2026-42296 was detected. This vulnerability allows an authenticated user with create Workflow permissions to bypass templateReferencing: Strict security boundaries, potentially leading to privilege escalation. This occurs due to an incomplete fix for CVE-2026-31892, which fails to restrict critical pod spec overrides. As a result, an attacker can gain host network access, switch service accounts, override pod security contexts, add tolerations to schedule on control-plane nodes, or enable ServiceAccount token mounting. While external Kubernetes controls (like PodSecurity admission or OPA/Gatekeeper) might mitigate some impacts, clusters relying solely on Argo’s Strict mode are fully exposed. To address this issue, users should upgrade Argo Workflows to versions 3.7.14, 4.0.5, or later. For more details, visit https://nvd.nist.gov/vuln/detail/CVE-2026-42296.
In Django versions 6.0 before 6.0.3, 5.2 before 5.2.12, and 4.2 before 4.2.29 (with earlier unsupported versions potentially affected) a high severity vulnerability CVE-2026-25673 was detected. This vulnerability allows a remote attacker to cause a Denial of Service (DoS) through resource exhaustion. This occurs because URLField.to_python() calls urllib.parse.urlsplit(), which performs NFKC Unicode normalization on Windows systems. This normalization process is disproportionately slow for certain Unicode characters. By submitting large URL inputs containing these specific characters, an attacker can severely degrade system performance or cause a crash. To address this issue, users should upgrade Django to versions 6.0.3, 5.2.12, 4.2.29, or later. For more details, visit https://nvd.nist.gov/vuln/detail/CVE-2026-25673.