CVE Vulnerability Catalog

In RAGFlow from 0.25.2 until 0.27.3, the POST /api/v1/agents/chat/completions endpoint invokes completion_openai and returns through the OpenAI-compatible branch before UserCanvasService.accessible() checks access to the agent. An authenticated user who knows another user's private agent UUID can execute that workflow and read its output across the user or tenant boundary.

In Pi-hole from 6.4.2 until 6.5, the root-run updatecheck.sh cron job applies truncate -s 0 and chmod 644 to /etc/pihole/versions while following symbolic links in a directory owned by the pihole user. An attacker running as pihole can replace the path with a symlink so the scheduled root operations truncate or create an arbitrary root-owned file, or race them so chmod makes a sensitive target world-readable.

In Pi-hole prior to 6.5, getFTLPID() in utils.sh validates the pihole-owned /run/pihole-FTL.pid file with expr, rejecting only values whose first character is not a digit. An attacker with code execution as pihole can write a digit-prefixed arithmetic expression that Bash then evaluates as root, enabling command substitution execution.

In Pi-hole prior to 6.5, gravity.sh checks file:// adlist readability with sudo -u pihole test -r but then allows curl, sometimes running as root, to normalize URL dot segments and open a different file. A pihole-readable decoy can therefore pass the check while curl reads a root-only target, and /proc/self paths can similarly resolve against different processes.

In draw.io Desktop prior to 31.5.2, the Windows application launched powershell and attrib by bare executable name. When draw.io was not already running, opening a diagram from File Explorer made the diagram directory the current working directory, allowing a colocated attacker-controlled powershell.bat or attrib.exe to be resolved first.

In the Ladybird browser prior to commit 209579c, FinalizationRegistry::cleanup() removed a dead record, retained an iterator to the next record, and then invoked attacker-controlled JavaScript through the cleanup callback. If that callback called unregister() for the next record, the retained iterator referenced a freed node, and the next iteration read its fields after free.

In the Ladybird browser prior to commit c0d68bd, CSSStyleSheet.cssRules, insertRule(), and deleteRule() did not enforce the stylesheet origin-clean flag with the required SecurityError, even though cross-origin imported stylesheets were correctly marked non-origin-clean. A malicious page could read rules and insert or delete rules in the victim stylesheet, bypassing the Same-Origin Policy.

In Immich prior to 3.2.0, the shared-link creation API accepted albumId and assetIds as independent fields in server/src/services/shared-link.service.ts but authorized only the resource selected by the requested link type. An authenticated attacker who already knew a victim-owned asset UUID could select SharedLinkType.Album for an attacker-owned album while supplying that UUID in assetIds; SharedLinkService.create() persisted the unchecked association in shared_link_asset and made the victim asset available through the new anonymous shared-link credential.

In Immich before 3.0.0, the GET /api/map/markers endpoint exposed to a view-only partner the GPS coordinates and existence of a sharer's archived photos or videos. The exposure is limited to location metadata and asset identifiers, as image bytes remain protected.

In Immich before 3.3.0, the unauthenticated machine-learning /predict endpoint accepted an options object without restricting security-sensitive parameters. An attacker with network access could set cache_dir to an arbitrary writable path, causing model downloads to write there and clear_cache() to recursively delete an attacker-selected directory via shutil.rmtree().

In pgAdmin 4, materialized view refresh passed the target database name to psql's --dbname argument unchanged. libpq treats a value containing "=" or a postgresql:// URI as a full connection string, allowing redirection to a chosen host and port and disclosure of the saved server password.

In pgAdmin 4, changing a user's password (by the user or an administrator) did not invalidate existing sessions. A session established before the change, e.g. on another device or by someone with the old password, stayed logged in until it expired.

In server mode pgAdmin 4 validated a user-supplied file path in the storage directory with check_access_permission() and then opened it by name using a plain open() or passed the path to utilities (pg_dump, pg_dumpall, pg_restore, psql) and to servers.json export/import and import file listing. Swapping in a symbolic or hard link or a FIFO between the check and the open redirected the operation outside the storage directory, allowing a file to be written, overwritten or read, or loaded into a table, as the pgAdmin operating-system account. This affects pgAdmin 4 before 9.19.

In pgAdmin 4 server mode before 9.19, get_complete_file_path() only stripped leading slashes before joining paths, so a path such as ../<another user>/.pgpass could name another user's file. The sslkeylogfile parameter was passed to libpq unchanged, and make_conninfo() quoted parameter values but not names, allowing additional keyword=value pairs to be smuggled in.

In pgAdmin 4 server mode, the server API create and update endpoints stored the "shared" flag and shared username, letting any user able to register a server share it with everyone. The servers.json import had a similar gap, as a non-administrator's "Shared" entries were removed only after validation.

In pgAdmin 4 before 9.19, when a server had no password file, client certificate, or client key configured, or the configured file could not be found, pgAdmin omitted the parameter and libpq fell back to the defaults of the operating-system account running pgAdmin. In server mode any user could therefore connect using the service account's saved passwords or client certificate.

In pgAdmin 4, the server password was written into pgAdmin's own process environment (as PGPASSWORD for the PSQL tool and under a per-process variable for a utility) and never removed. In server mode the environment is shared across all users' requests and copied into started processes, so another user could inherit the password and use it to connect.

In pgAdmin 4 server mode, libpq looks up connection services in the service file of the operating-system account, allowing users to use that account's credentials or certificate files. The vulnerability affects versions before 9.19 and can lead to unauthorized access to database servers.

In pgAdmin 4 server mode, removing KRB5CCNAME caused the Kerberos library to fall back to the service account's default credential cache, allowing any user to connect as the service principal. The vulnerability affects versions before 9.19 and also includes bypassing gssencmode=disable and SSPI behavior on Windows.

In pgAdmin 4 server mode, the user-set binary path was not checked against SHARED_STORAGE directories, allowing an executable to be uploaded and run as the pgAdmin service account. The vulnerability is especially relevant on Windows where files can be executable, and affects versions before 9.19.