Hírolvasó
VU#330121: IDrive for Windows contains local privilege escalation vulnerability
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 AUTHORITY\SYSTEM permissions.
DescriptionIDrive 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:\ProgramData\IDrive. 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.
ImpactThis 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.
SolutionIDrive 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.
AcknowledgementsThanks to Matthew Owens and FRSecure for discovering and reporting this vulnerability. This document was written by Molly Jaconski.
VU#577436: Hard coded credentials vulnerability in GoHarbor's Harbor
GoHarbor's Harbor default admin password presents a security risk because it does not require change upon initial deployment.
DescriptionGoHarbor'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.
ImpactAn 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.
SolutionOperators 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
AcknowledgementsThanks to notnotnotveg (notnotnotveg@gmail.com) who reported this vulnerability. This document was written by Michael Bragg.
24 órás késleltetés vár az ismeretlen Android alkalmazásokra
Új generációs infostealer célozza a Chrome titkosítását
Orosz hírszerzéshez kötött Signal adathalászatról adott ki közleményt több ügynökség
Hitelesnek tűnő Microsoft e-mailekkel terjedő új adathalász kampány
Soron kívüli frissítést adott ki az Oracle egy feltehetően aktívan kihasznált sérülékenység miatt
Zero-day támadások hulláma érinti a Cisco rendszereket
DarkSword exploitlánccal törnek fel iOS-eszközöket
Kritikus Telnetd sérülékenység: hitelesítés nélkül távoli root kódfuttatás fenyegeti a rendszereket
Hogyan tegyük biztonságossá az AI-ügynököket?
Kibertámadás érte Lengyelország nukleáris kutatóközpontját
A WebKitet érintő biztonsági frissítést adott ki az Apple
Tovább bővül az EU kiberbiztonsági szankciós listája
HPE AOS-CX rendszerét érintő sérülékenységek
Közepes súlyosságú hiba került a CISA KEV katalógusába
Az Instagram megszünteti a titkosított chatelést
Facebook-hirdetésekben terjedő manipulált videók irányítják a felhasználókat befektetési csalások felé
VU#624941: LibreChat RAG API contains a log-injection vulnerability
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.
DescriptionLibreChat’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.
ImpactBy 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.
SolutionUnfortunately, 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.
AcknowledgementsThanks to Caio Bittencourt for coordinating the disclosure of this vulnerability. This document was written by Dr. Elke Drennan, CISSP.
