Hírolvasó
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.
Steam-en terjedő káros kódok után nyomoz az FBI
Soron kívüli biztonsági frissítést adott ki a Google a Chrome két zero day sérülékenysége miatt
Miért olyan kockázatosak a SIM-csere támadások
Új funkció a WhatsAppon a gyermekek online biztonsága érdekében
VU#907705: Graphql-upload-minimal has a prototype pollution vulnerability.
Version 1.6.1 of the Flash Payments package graphql-upload-minimal is vulnerable to prototype pollution. This vulnerability, located in the processRequest() function, allows an attacker to inject special property names into the operations.variables object and pollute global object prototypes, ultimately impacting the entire Node.js process.
Descriptiongraphql-upload-minimal is a lightweight Node.js middleware package that implements the GraphQL multipart request specification, enabling file uploads in GraphQL servers. It parses multipart/form-data requests and maps uploaded files into the GraphQL operations object, making them accessible to resolvers.
The vulnerability exists in the processRequest() function, which handles multipart file upload requests. It processes a user-supplied map parameter that determines where uploaded files should be placed within the GraphQL operations.variables object.
The issue occurs because user-supplied property paths are not validated before being resolved and written into the target object. Special JavaScript property names such as __proto__, __constructor__, and prototype are not restricted, allowing crafted paths to traverse the prototype chain and modify Object.prototype.
Because Object.prototype is the base prototype from which most JavaScript objects inherit, altering it results in global prototype pollution across the Node.js process. Once polluted, manipulated properties may be inherited by all subsequently created objects for the lifetime of the process.
Because Object.prototype is the foundational prototype for most JavaScript objects, modifying it can affect the behavior of all Node.js processes. Since the impact extends across the entire Node.js process and persists until the service is restarted, it can potentially result in logic corruption, denial of service, or unintended privilege escalation.
SolutionUsers should upgrade to graphql-upload-minimal version 1.6.3 or later, which can be found at https://github.com/flash-oss/graphql-upload-minimal/tree/master . The patched release introduces safeguards to prevent unsafe prototype-chain property assignments during multipart file upload processing.
AcknowledgementsThanks to Maor Caplan from Alma Security for reporting this vulnerability. This document was written by Michael Bragg.
A Microsoft jelszómentességgel veszi fel a harcot az adathalászat ellen
Egy új trükk, amellyel a kártevő átcsúszhat a szűrőkön
VU#665416: SGLang (sglang) is vulnerable to code execution attacks via unsafe pickle deserialization
Two unsafe pickle deserialization vulnerabilities have been discovered in the SGLang open-source project, one within the tool's multimodal generation module and another within the Encoder Parallel Disaggregation system. SGLang is a serving framework for large language models (LLMs) and multimodal models. These vulnerabilities, tracked as CVE-2026-3059 and CVE-2026-3060, allow an attacker to provide a malicious pickle file to a device using SGLang's multimodal generation system or the encoder parallel disaggregation system, enabling code execution. CVE-2026-3989 allows an attacker to provide a malicious pickle file that, when attempted to be replayed with the replay_request_dump.py script, will result in code execution. It is recommended that project maintainers avoid implementing Pickle functions due to the inherent security risks.
DescriptionSGLang is a framework for serving various large language models (LLMs) and multimodal AI models, supporting models such as Qwen, DeepSeek, Mistral, and Skywork, and is compatible with OpenAI APIs. Two unsafe pickle deserialization vulnerabilities have been identified in the project, tracked as CVE-2026-3059 and CVE-2026-3060.
CVE-2026-3059 SGLangs multimodal generation module is vulnerable to unauthenticated remote code execution through the ZMQ broker, which deserializes untrusted data using pickle.loads() without authentication.
CVE-2026-3060 SGLangs encoder parallel disaggregation system is vulnerable to unauthenticated remote code execution through the disaggregation module, which deserializes untrusted data using pickle.loads() without authentication.
SGLang is vulnerable to CVE-2026-3059 when the multimodal generation system is enabled, and to CVE-2026-3060 when the encoder parallel disaggregation system is enabled. If either condition is met and an attacker knows the TCP port on which the ZMQ broker is listening and can send requests to the server, they can exploit the vulnerability by sending a malicious pickle file to the broker, which will then deserialize it.
CVE-2026-3989 SGLangs replay_request_dump.py contains an insecure pickle.load() without validation and proper deserialization. An attacker can take advantage of this by providing a malicious .pkl file, which will execute the attackers code on the device running the script.
The SGLang project's replay_request_dump.py script uses pickle.load() without trust validation, allowing for arbitrary code execution if an attacker can control the pickle file contents. This vulnerability has low applicability but high impact, and can be exploited if an attacker can provide a malicious pickle file or write to the crash dump directory, potentially through social engineering or by compromising a directory where crash dump information is automatically saved. The script, intended to replay crash dump information, poses a risk if an attacker can manipulate the input files or directories used by the script.
The use of Pickle is strongly discouraged due to its inherent security risks. Deserializing a pickle file with pickle.loads() can lead to Remote Code Execution (RCE) if an attacker can provide a malicious file. This is because the pickle file format stores not only data but also instructions on how to reconstruct the object, which are executed during deserialization. As a result, an attacker can potentially execute arbitrary Python code.
To mitigate these risks, projects should consider implementing safer serialization formats, such as JSON or XML, or using tools like msgpack to perform more data-driven serialization and deserialization instead of open-ended capabilities such as pickle. This can help prevent RCE attacks and ensure the secure exchange of data.
ImpactAn attacker who can send crafted messages to the ZeroMQ interface may trigger unsafe pickle deserialization in SGLang when certain features are enabled, potentially leading to remote code execution. Additionally, an attacker who can provide a malicious pickle file in the context of a crash dump may also exploit CVE-2026-3989. Successful exploitation could allow arbitrary code execution in the context of the SGLang service, potentially leading to host compromise, lateral movement, data exfiltration, or denial-of-service (DoS) attacks. Deployments that expose the affected interface to untrusted networks are at the highest risk of exploitation.
SolutionUsers of SGLang should restrict access to the service interfaces and ensure they are not exposed to untrusted networks. Proper network segmentation and access controls should be implemented to prevent unauthorized interaction with the ZeroMQ endpoints. During coordinated disclosure, no vendor statement was obtained. A proposed patch was submitted to the maintainers, but no response was received at the time of publication.
AcknowledgementsThanks to the reporter, Igor Stepansky. This document was written by Christopher Cullen.
