Overview
The IDrive Cloud Backup Client for Windows, versions 7.0.0.63 and earlier, contains a privilege escalation vulnerability that allows any authenticated user to run arbitrary executables with NT AUTHORITYSYSTEM permissions.
Description
IDrive is a cloud backup service that allows users to encrypt, sync, and store data from multiple devices such as PCs, Macs, iPhones, and Androids in one cloud-based account. IDrive provides a Windows client for both desktop and server editions, which acts as both a thick client and a thin client with a web interface to manage cloud backups.
CVE-2026-1995 The IDrive Windows client utility id_service.exe runs as a process with elevated SYSTEM privileges and regularly reads from several files located under C:ProgramDataIDrive. The UTF16-LE encoded contents of these files are used by the service as arguments for starting processes. Because of weak permission configurations, these files can be edited by any standard user logged into the system. An authenticated, low-privilege attacker can overwrite or add a new file that specifies a path to an arbitrary script or .exe, which will then be executed by the id_service.exe process with SYSTEM privileges.
Impact
This vulnerability enables an authenticated local user, or any user with access to the affected directory, to execute arbitrary code as SYSTEM on the target Windows device. A local attacker could exploit this vulnerability to escalate privileges and gain full control over the target machine, potentially enabling data theft, system modification, or arbitrary script execution.
Solution
IDrive has reported that a patch for this vulnerability is currently in development. Users should monitor IDrive releases and update their software to the latest version as soon as it becomes available. In the meantime, users are advised to restrict write permissions for the affected directory and employ additional controls such as EDR monitoring and Group Policies to detect and prevent unauthorized file modifications.
Acknowledgements
Thanks to Matthew Owens and FRSecure for discovering and reporting this vulnerability. This document was written by Molly Jaconski.

Overview
GoHarbor’s Harbor default admin password presents a security risk because it does not require change upon initial deployment.
Description
GoHarbor’s Harbor is an open-source OCI-compliant container registry project that stores, signs, and manages container images. Harbor initializes with a default administrator account (admin) and password (Harbor12345), configured through the harbor_admin_password parameter in the harbor.yml.
While operators are expected to change these credentials during or after deployment, Harbor does not enforce a password change during setup or upon first login. If the default credentials remain unchanged, a remote attacker can authenticate using the publicly known password to gain full administrative access.
Impact
An attacker who gains administrative access can fully compromise the Harbor registry and all managed artifacts. This includes the ability to overwrite or inject malicious container images, enabling supply-chain attacks that may lead to remote code execution in downstream continuous integration and continuous development (CI/CD) pipelines and Kubernetes environments. The attacker can establish persistent access by creating new users, robot accounts, or API tokens, and can weaken or disable security controls such as vulnerability scanning, signature enforcement, and role-based access controls.
Additionally, sensitive images can be exfiltrated by configuring replication to external registries or downloading artifacts directly. Administrative privileges also allow destructive actions such as deleting repositories or corrupting artifacts, resulting in service disruption and loss of system integrity.
Solution
Operators should change the default administrative password either before or immediately after deployment. This can be done through the Harbor web interface or by specifying a unique value for harbor_admin_password in harbor.yml during installation.
A fix has been proposed to address the hardcoded default password by removing or randomizing default credentials during installation. See the Harbor pull request:
https://github.com/goharbor/harbor/pull/19188https://github.com/goharbor/harbor/pull/19188
Acknowledgements
Thanks to notnotnotveg (notnotnotveg@gmail.com) who reported this vulnerability. This document was written by Michael Bragg.

Overview
A log-injection vulnerability in the LibreChat RAG API, version 0.7.0, is caused by improper sanitization of user-supplied input written to system logs. An authenticated attacker can forge or manipulate log entries by inserting CRLF characters, compromising the integrity of audit records. This flaw may further enable downstream attacks if the tampered logs are processed or displayed by insecure log-management tools.
Description
LibreChat’s retrieval-augmented generation (RAG) application programming interface (API) is a specialized, asynchronous backend service developed with Python FastAPI and LangChain that facilitates document-based RAG through a file-level, ID-based indexing system. It operates by extracting and chunking text from user-uploaded files, generating high-dimensional embeddings via providers like OpenAI or local Ollama instances, and storing them in a PostgreSQL database equipped with the pgvector extension for efficient semantic search.
A log-injection vulnerability occurs when an application fails to properly sanitize or validate untrusted user input before including it in system log files, allowing an attacker to manipulate the integrity of the audit trail. By inserting line-feed or carriage-return (CRLF) characters in a POST request, specifically in the file_id parameter of the form data, an authenticated attacker can forge fake log entries.
Impact
By exploiting this vulnerability, an authenticated attacker can obfuscate malicious activity, misdirect forensic investigations, or impersonate other users. Furthermore, if the logs are later viewed through a web-based administrative console or an unsecure log-management tool, this vulnerability can escalate into secondary attacks such as cross-site scripting (XSS) or remote command execution.
Solution
Unfortunately, we were unable to reach the vendor to coordinate this vulnerability. Since a patch is unavailable, we can only offer mitigation strategies.
The following workarounds can help mitigate this vulnerability’s impact on the targeted environment:

Sanitize input logs with a filter in the RAG ingest to prevent malicious data.
Disable the pgvector extension in PostgreSQL, if not in use.
Validate RAG output before passing it to other tools to prevent relaying of data that could lead to indirect prompt injection.

These recommendations are not mutually exclusive and can be implemented in combination to provide layered protection. By taking these steps, organizations can reduce their risk exposure until the vendor addresses the underlying vulnerabilities.
Acknowledgements
Thanks to Caio Bittencourt for coordinating the disclosure of this vulnerability. This document was written by Dr. Elke Drennan, CISSP.