Search: 7.3.1.1

A vulnerability in the filelock library versions 3.22.0 through 4.2.0 allows a local user with write access to a lock marker file (but without permission to remove it) to forge the process ID in the marker. This causes another process running as the lock owner or root to incorrectly consider the lock stale, remove the live marker, and acquire the lock. As a result, two processes may concurrently hold the lock and execute the critical section simultaneously without error. The issue arises when the marker file is created with group or other write permissions, such as with an explicit permissive mode or a lax umask (002 or 000) in a sticky or non-removable directory. The default umask 022 is not affected. The vulnerability has a CVSS 3.1 score of 4.7 (Medium) and impacts integrity but not confidentiality or availability.

The ReadWriteLock and AsyncReadWriteLock classes in esphome versions 2026.7.1 through 2026.9.x resolve lock file paths following symlinks and pass them to SQLite without refusing symlinks. This allows a local attacker with write access to the lock directory to create files owned by the victim at arbitrary paths, interfere with SQLite locking by causing database lock errors, or break mutual exclusion by enabling two victim processes to hold the write lock simultaneously. The issue affects Linux, macOS, and Windows 11. A fix is available in esphome 2026.10.0.

GitPython versions up to 3.1.62 contain a vulnerability in the Head.checkout() method that allows an attacker to cause an arbitrary file read via a specially crafted branch name. This occurs because the method does not properly sanitize its positional argument (the branch name), allowing injection of git command options such as --pathspec-from-file. An attacker controlling a repository with a malicious default branch name can exploit this by having the vulnerable application clone and check out that branch, causing sensitive files (e.g., /etc/passwd) to be read and returned in an exception. The issue is a partial regression of previously fixed vulnerabilities and has a CVSS 3.1 score of 7.5 (High). A fix is available in version 0.9.2_11.

A memory leak vulnerability exists in the msgpack-python C extension when deserializing MessagePack data with strict_map_key validation enabled (default). The leak occurs because a decoded map value is not released upon key validation failure, causing unbounded memory growth and potential denial of service. Additionally, a memory-safety issue in the streaming Unpacker API can cause use-after-free or double free errors, potentially leading to crashes. The pure-Python fallback does not exhibit the memory leak. The issue affects msgpack-python version 1.2.2 and possibly earlier versions starting from 1.1.x, though the exact earliest affected version is uncertain. No official patch links are provided yet. The vulnerability has a CVSS score of 7.5 (high severity).

IDrive Backup for Windows versions 7.0.1.1 and earlier contain a vulnerability in the id_service.exe component that allows a local attacker to execute arbitrary code. This issue is resolved in version 7.0.1.2.

A vulnerability in IDrive Backup for Windows versions 7.0.1.1 and earlier allows a local attacker to execute arbitrary code via the id_service.exe component. This issue is fixed in version 7.0.1.2.

A vulnerability in filelock's ReadWriteLock and AsyncReadWriteLock components allows a local user with write permissions in the directory containing the SQLite lock database to manipulate symlinks or journal files. This can cause the lock user’s SQLite database to be reopened following symlinks, enabling the attacker to write arbitrary data or unlink files with the lock user's privileges. The issue affects filelock versions 3.20.4 through 4.2.0 and requires a non-sticky writable directory shared with the attacker. The vulnerability has a CVSS score of 7.1 (High) and impacts integrity and availability but not confidentiality.

A vulnerability in virtualenv's bash activation prompt allows attacker-controlled prompt text to be interpreted as executable syntax under certain older bash compatibility modes (4.2 and lower) and specific shell scenarios involving dash. This can lead to command execution when the user activates the environment and the prompt is drawn. The issue arises because the prompt string is assigned to PS1 and then expanded again by the shell, with some paths not properly escaping or sanitizing the prompt content. The vulnerability affects virtualenv versions starting from 20.0.0b1 with certain changes introduced in 21.14.7 and confirmed in 21.14.8. Exploitation requires attacker influence over the prompt argument and user activation of the environment in a vulnerable shell context.

A vulnerability in the filelock library versions 3.22.0 through 4.2.0 allows a local unprivileged user to cause two processes to simultaneously hold the same soft file lock due to inode reuse on certain filesystems like ext4 and xfs. This occurs when a stale lock break mechanism mistakenly removes a live lock file after inode reuse, enabling concurrent lock holders without detection. The issue requires a shared sticky directory writable by the attacker and at least two contending processes from the lock user. The vulnerability impacts integrity but not confidentiality or availability and has a CVSS score of 4.7 (medium severity). A fix is available in version 0.34.0.

GitPython versions >=0.26.0 and <0.33.0 contain vulnerabilities in three wrapper methods that omit necessary unsafe protocol and option checks. The ls_remote method forwards URLs without checking for unsafe protocols, enabling potential remote code execution (RCE) if the victim's git transport policy permits the 'ext' transport. The merge_base and IndexFile.move methods forward caller-controlled arguments without proper unsafe option checks, exposing latent argument-injection risks. These issues were verified on the main branch post the latest release 0.33.0, which includes fixes. The overall severity is high with a CVSS score of 7.5.

WeGIA is a web manager for charitable institutions. Prior to 3.8.7, a stored cross-site scripting vulnerability in `saude/historico_prontuarios.php` arises because the `textoProntuario` field accepts arbitrary HTML or JavaScript without proper sanitization. An attacker able to create or access a patient's medical record can submit the field through `POST /controle/control.php` with `nomeClasse=SaudeControle`, `metodo=alterarProntuario`, and `id_fichamedica`. The stored content is rendered when another user accesses `/html/saude/historico_prontuarios.php` with `id_historico`, automatically executing attacker-controlled JavaScript in the victim's browser. The vulnerability permits session cookie theft and potential account compromise depending on the victim's privileges. This issue is fixed in version 3.8.7.

WeGIA is a web manager for charitable institutions. Prior to 3.8.7, a stored DOM cross-site scripting vulnerability in `web/html/memorando/listar_despachos.php` results from unsafe handling of the `texto` field. The affected flow spans `web/controle/memorando/DespachoControle.php` and `web/dao/memorando/DespachoDAO.php`: `FILTER_SANITIZE_SPECIAL_CHARS` is applied during storage, but `html_entity_decode()` later decodes the stored content and `jQuery .html()` inserts the result into the DOM. An attacker able to submit a memorandum dispatch through `/controle/control.php` using `DespachoControle` and `metodo=incluir` can store malicious HTML or JavaScript. The code executes automatically when another user views the memorandum thread through `/html/memorando/listar_despachos.php` with `id_memorando`. This permits arbitrary JavaScript execution, theft of administrator `PHPSESSID` session tokens, privileged session hijacking, account takeover, and unauthorized access to privileged or internal functionality. This issue is fixed in version 3.8.7.

WeGIA is a web manager for charitable institutions. Prior to the advisory's stated patched version 3.8.7, the `/controle/control.php` dispatch endpoint accepts attacker-controlled `nomeClasse`, `metodo`, and record identifier parameters through `extract($_REQUEST)`, including id, `idatendido`, `idInterno`, and `id_funcionario`, while the affected Controle CRUD methods do not verify record ownership. Any authenticated user can view, modify, or delete another user's records, exposing CPF, RG, addresses, medical records, financial data, and employee records. `AtendidoControle` lacks ownership checks on alterar, excluir, `listarUm`, `alterarInfPessoal`, `alterarDocumentacao`, `alterarImagem`, `alterarEndereco`, and `alterarStatus`; `InternoControle` lacks them on incluir, alterar, excluir, `listarUm`, `listarTodos`, and `listarCpf`. `FuncionarioControle` lacks ownership checks on `alterarInfPessoal`, `alterarEndereco`, `alterarDocumentacao`, `alterarImagem`, `alterarCargaHoraria`, and excluir; `VoluntarioControle` lacks them on `alterarInfPessoal`, `alterarEndereco`, `alterarDetalhes`, `alterarImagem`, and excluir. `AtendidoControle` and `InternoControle` additionally lack CSRF validation, allowing a malicious page visited by an authenticated victim to perform state-changing operations using the victim's session. `FuncionarioControle` and `VoluntarioControle` have per-method CSRF checks, but those checks do not prevent the object-authorization bypass. The advisory identifies version 3.8.7 as patched.

joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Prior to 1.7.5, joserfc.jwe.decrypt_json() accepts a JWE General JSON Serialization recipients array without a count limit and calls decrypt_cek() for every entry. An unauthenticated attacker who can submit a JWE to an endpoint using an RSA key-management algorithm can choose the number of private-key decryption operations performed by one request. The verify_all_recipients option does not reduce this work because the affected loop processes every recipient before consulting that setting, allowing repeated requests to exhaust service CPU without affecting confidentiality or integrity. This issue is fixed in version 1.7.5.