Vulnerabilities

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.

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.

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.

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.

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.

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.

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.

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.

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.

Deserialization of untrusted data (CWE-502) in pgAdmin 4 FileBackedSessionManager.<br /> <br /> The session manager performed unsafe deserialization of session-file contents (using Python&amp;#39;s standard object-serialization module) before performing any HMAC integrity check. Any file dropped into the sessions directory was deserialized unconditionally. An authenticated user with write access to the sessions directory (whether by misconfiguration or in combination with another path-traversal flaw) could plant a crafted serialized payload to achieve operating-system level remote code execution under the pgAdmin process identity.<br /> <br /> Fix prepends a 64-byte hex SHA-256 HMAC over the session body, computed with SECRET_KEY, and verifies it via hmac.compare_digest before any deserialization. The check is raised (rather than asserted) on empty SECRET_KEY so it is not stripped under -O.<br /> <br /> This issue affects pgAdmin 4: before 9.15.

An arbitrary file write vulnerability exists in Casdoor&amp;#39;s Local File System storage provider. Due to insufficient path sanitization, an authenticated attacker with administrative privileges can perform a Path Traversal attack to create or overwrite arbitrary files anywhere on the host filesystem, bypassing the application&amp;#39;s intended storage sandbox.

Authorization vulnerability in pgAdmin 4 server mode affecting Server Groups, Servers, Shared Servers, Background Processes, and Debugger modules.<br /> <br /> Multiple endpoints fetched user-owned objects without filtering by the requesting user&amp;#39;s identity. An authenticated user could access another user&amp;#39;s private servers, server groups, background processes, and debugger function arguments by guessing object IDs.<br /> <br /> Additionally, the Shared Servers feature contained multiple issues including credential leakage (passexec_cmd, passfile, SSL keys), privilege escalation via writable passexec_cmd (a shell command executed when establishing the connection) allowing arbitrary command execution in the owner&amp;#39;s process context, and owner-data corruption via SQLAlchemy session mutations. Several owner-only fields (passexec_cmd, passexec_expiration, db_res, db_res_type) were writable by non-owners through the API, and additional fields (kerberos_conn, tags, post_connection_sql) lacked per-user persistence so non-owner edits mutated the owner&amp;#39;s record.<br /> <br /> Fix centralises access control via a new server_access module, scopes all user-owned models with a UserScopedMixin, returns HTTP 410 from connection_manager when access is denied in server mode, suppresses owner-only fields for non-owners across the merge / API response / ServerManager paths, and adds an explicit owner-only write guard. The remediation landed in two pull requests; both are referenced.<br /> <br /> This issue affects pgAdmin 4: before 9.15.