Vulnerabilidades

*** Pendiente de traducción *** The flash-attention training framework thru commit e724e2588cbe754beb97cf7c011b5e7e34119e62 (2025-13-04) contains an insecure deserialization vulnerability (CWE-502) in its checkpoint loading mechanism. The load_checkpoint() function in checkpoint.py and the checkpoint loading code in eval.py use torch.load() without enabling the security-restrictive weights_only=True parameter. This allows the deserialization of arbitrary Python objects via the pickle module. An attacker can exploit this by providing a maliciously crafted checkpoint file. When a victim loads this checkpoint during model warmstarting or evaluation, arbitrary code is executed on the victim's system.

*** Pendiente de traducción *** The flash-attention project thru commit e724e2588cbe754beb97cf7c011b5e7e34119e62 (2025-13-04) contains a code injection vulnerability (CWE-94) in its training script. The script registers the Python eval() function as a Hydra configuration resolver under the name eval. This allows configuration files to execute arbitrary Python code via the ${eval:...} syntax. An attacker can exploit this by providing a malicious configuration file, leading to arbitrary code execution when the training script is run with that configuration.

*** Pendiente de traducción *** CosyVoice thru commit 6e01309e01bc93bbeb83bdd996b1182a81aaf11e (2025-30-21) contains an insecure deserialization vulnerability (CWE-502) in its gRPC server component. When the server starts, it loads the speech synthesis model from a user-specified directory using torch.load() without enabling the weights_only=True security parameter. This allows the deserialization of arbitrary Python objects via the pickle module. An attacker can exploit this by providing malicious model files within a directory. When a victim starts the gRPC server pointing to this directory, arbitrary code is executed on the victim's system during server initialization.

*** Pendiente de traducción *** CosyVoice thru commit 6e01309e01bc93bbeb83bdd996b1182a81aaf11e (2025-30-21) contains an insecure deserialization vulnerability (CWE-502) in its make_parquet_list.py data processing tool. The script loads PyTorch .pt files (utterance embeddings, speaker embeddings, speech tokens) using torch.load() without enabling the weights_only=True security parameter. This allows the deserialization of arbitrary Python objects via the pickle module. An attacker can exploit this by providing malicious .pt files within a data directory. When a victim processes this directory using the tool, arbitrary code is executed on the victim's system.

*** Pendiente de traducción *** CosyVoice thru commit 6e01309e01bc93bbeb83bdd996b1182a81aaf11e (2025-30-21) contains an insecure deserialization vulnerability (CWE-502) in its average_model.py model averaging tool. The script loads PyTorch checkpoint files (epoch_*.pt) for model averaging using torch.load() without enabling the weights_only=True security parameter. This allows the deserialization of arbitrary Python objects via the pickle module. An attacker can exploit this by providing malicious checkpoint files within a directory. When a victim uses the tool to average models from this directory, arbitrary code is executed on the victim's system.

*** Pendiente de traducción *** Docling's METS GBS backend is vulnerable to XML Entity Expansion (XXE) attacks thru 2.61.0. The backend extracts and validates XML files from .tar.gz archives using etree.fromstring() without disabling entity resolution. An attacker can craft a malicious XML file with nested entity definitions (XML Bomb) and package it into a .tar.gz archive. When processed by Docling, the exponential expansion of entities during XML parsing leads to excessive resource consumption, resulting in a denial of service (DoS) condition on the system running the Docling parser.

*** Pendiente de traducción *** A weakness has been identified in Open5GS up to 2.7.7. Impacted is the function ogs_nnrf_nfm_handle_nf_profile of the file lib/sbi/nnrf-handler.c of the component NRF. This manipulation causes denial of service. The attack is possible to be carried out remotely. The exploit has been made available to the public and could be used for attacks. The pull request to fix this issue awaits acceptance.

*** Pendiente de traducción *** A security vulnerability has been detected in Open5GS up to 2.7.7. The affected element is the function yuarel_parse in the library /lib/sbi/conv.c of the component NRF. Such manipulation of the argument hnrf-uri leads to denial of service. The attack may be performed from remote. The exploit has been disclosed publicly and may be used. The project was informed of the problem early through an issue report but has not responded yet.

*** Pendiente de traducción *** Symbolic-link path traversal (CWE-61, CWE-22) in pgAdmin 4 File Manager.<br /> <br /> check_access_permission used os.path.abspath, which resolves &amp;#39;..&amp;#39; but does not resolve symbolic links, while the subsequent kernel write follows symlinks. An authenticated user could plant a symbolic link inside their own storage directory pointing outside it and induce pgAdmin to write to any path reachable by the pgAdmin process.<br /> <br /> Fix switches the access check to os.path.realpath for both source and destination, and adds an _open_upload_target helper that opens the target with O_NOFOLLOW (mode 0o600) to close the leaf-component TOCTOU between the access check and the open. File mode is hardened from 0o644 to 0o600.<br /> <br /> This issue affects pgAdmin 4: before 9.15.

*** Pendiente de traducción *** Improper restriction of excessive authentication attempts (CWE-307) in pgAdmin 4.<br /> <br /> pgAdmin enforces MAX_LOGIN_ATTEMPTS only inside its custom /authenticate/login view. Flask-Security&amp;#39;s default /login view, which is registered automatically by security.init_app() and is reachable on every server, never consulted the User.locked field: pgAdmin&amp;#39;s User model relied on Flask-Security&amp;#39;s UserMixin.is_locked() (which always returns &amp;#39;not locked&amp;#39;) and Flask-Login&amp;#39;s is_active (which only checks the active column, not locked). An attacker who triggered an account lockout via /authenticate/login could therefore obtain a session by re-submitting valid credentials directly to /login, defeating the brute-force-protection control for accounts using the INTERNAL authentication source. The same bypass also means that login attempts via /login are never rate-limited, so an attacker can perform an unbounded online password-guessing attack against INTERNAL accounts regardless of MAX_LOGIN_ATTEMPTS.<br /> <br /> Fix overrides User.is_active and User.is_locked() so the locked column is enforced on every authentication path. LDAP, OAuth2, Kerberos, and Webserver users are not reachable by this bypass because they have no local password and are rejected by Flask-Security&amp;#39;s LoginForm.validate before the locked check; the lockout itself is also internal-only (the /authenticate/login view filters by auth_source=INTERNAL).<br /> <br /> This issue affects pgAdmin 4: before 9.15.

*** Pendiente de traducción *** OS command injection (CWE-78) vulnerability in pgAdmin 4 Import/Export query export.<br /> <br /> User-supplied input was interpolated directly into a psql \copy metacommand template without sanitization. An authenticated user could inject ") TO PROGRAM &amp;#39;cmd&amp;#39;" to break out of the \copy (...) context and achieve arbitrary command execution on the pgAdmin server, or ") TO &amp;#39;/path&amp;#39;" for arbitrary file write. Additional fields (format, on_error, log_verbosity) were also raw-interpolated and exploitable.<br /> <br /> Fix adds a parens-balance parser modeled on psql&amp;#39;s strtokx tokenizer, allow-lists format/on_error/log_verbosity, rejects null bytes in the query, and tightens type and gating checks.<br /> <br /> This issue affects pgAdmin 4: before 9.15.

*** Pendiente de traducción *** Local file inclusion (LFI) and server-side request forgery (SSRF) vulnerabilities in pgAdmin 4 LLM API configuration endpoints.<br /> <br /> User-supplied api_key_file and api_url preferences were passed to the LLM provider clients without validation. An authenticated user could read arbitrary server-side files by pointing api_key_file at any path readable by the pgAdmin process, or coerce pgAdmin into making requests to internal targets (e.g. cloud metadata services such as 169.254.169.254) by setting api_url, exploiting the chat path and model-list endpoints.<br /> <br /> Fix restricts api_key_file to the user&amp;#39;s private storage (server mode) or home directory (desktop mode), enforces a printable-ASCII key shape and a 1024-byte read cap, and gates api_url against a configurable allow-list (config.ALLOWED_LLM_API_URLS) at every entry point.<br /> <br /> This issue affects pgAdmin 4: before 9.15.