Export limit exceeded: 419348 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (419348 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-78403 | 1 Thalesgroup | 1 Sentinel Keys Server | 2026-10-30 | 9.8 Critical |
| Stack-based buffer overflow and missing authorization vulnerability in Thales Sentinel Keys Server on Windows allows Overflow Buffers. Sentinel Keys Server does not check the length of the first field in the HTTP request. An attacker may craft an HTTP request and send it to Sentinel Keys Server. It may lead to remote code execution as NT AUTHORITY\SYSTEM. This issue affects Sentinel Keys Server: versions lower than 1.3.8.0. | ||||
| CVE-2026-115828 | 1 Delinea | 1 Secret Server | 2026-10-30 | N/A |
| In Secret Server versions earlier than 12.3.1, Secret Server did not always validate the PIN or biometric check when using a FIDO2-compliant device | ||||
| CVE-2026-115830 | 1 Delinea | 1 Secret Server | 2026-10-30 | N/A |
| In Secret Server versions earlier than 12.3.1, a user under certain conditions could submit an unsigned JWT and receive cloudadmin permissions in response. | ||||
| CVE-2026-119328 | 1 Immich-app | 1 Immich | 2026-10-30 | 6.5 Medium |
| Immich is a high-performance self-hosted photo and video management solution. Prior to 3.3.0, the unauthenticated machine-learning /predict endpoint in machine-learning/immich_ml/main.py accepted an options object and passed its values into model construction in machine-learning/immich_ml/models/base.py without restricting security-sensitive parameters. An attacker with network access to the service could set cache_dir to an arbitrary writable path, causing model downloads to write there and causing clear_cache() to pass that path to shutil.rmtree() after selected model-loading failures. Depending on filesystem permissions and the selected path, this could modify files in mounted data locations or recursively delete an attacker-selected directory. The model-name allowlist prevents this issue from becoming arbitrary-model deserialization or code execution. This issue is fixed in version 3.3.0. | ||||
| CVE-2026-119330 | 1 Immich-app | 1 Immich | 2026-10-30 | 3.5 Low |
| Immich is a high-performance self-hosted photo and video management solution. 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. This exposed victim metadata, thumbnails, and the byte-identical original file and created a persistent sharing relationship that could be redistributed. This issue is fixed in version 3.2.0. | ||||
| CVE-2026-116239 | 1 Pgadmin | 1 Pgadmin 4 | 2026-10-30 | 8.5 High |
| In server mode pgAdmin 4 keeps an account per authentication source, so the same username can exist as, for example, an internal account and an LDAP account. After LDAP or Kerberos authenticated a user, pgAdmin chose the account to log in by username alone, or took the account Flask-Security's login form had looked up, without checking that it came from the source that authenticated the user. The session therefore belonged to another account, with its role, its servers and its saved database passwords: - An LDAP or Kerberos user whose username matched an internal account was logged in as that internal account, including the administrator account created when pgAdmin is first set up. - With internal authentication listed before LDAP or Kerberos in AUTHENTICATION_SOURCES, the login form's internal validation looks up the account whose email was typed and keeps it even though its password does not match. A Kerberos user could type another Kerberos user's principal and be logged in as that user, and an LDAP user could do the same with an LDAP account whose email is their username. Exploitation requires valid credentials for an LDAP directory or Kerberos realm that pgAdmin is configured to use. The fix looks the account up by the authenticated username and the source that authenticated it, and no longer uses the account the login form found for any source but internal authentication. Internal authentication logs in that account only if it is an internal account. Desktop mode is not affected. This issue affects pgAdmin 4: before 9.19. | ||||
| CVE-2026-116241 | 1 Pgadmin | 1 Pgadmin 4 | 2026-10-30 | 9.9 Critical |
| pgAdmin 4's Import/Export Data tool wraps a user's query export in a psql \copy (...) TO command and checks that the query's parentheses are balanced so that nothing can escape the wrapper. The check rejected a backslash inside a single-quoted string, but not inside a double-quoted identifier, where it treated the next double quote as closing the identifier. psql's \copy parser applies the connection's escape character to whichever quote opened a token, so with standard_conforming_strings off a backslash-escaped double quote does not close the identifier. pgAdmin's and psql's view of the quoting then diverged, a closing parenthesis hidden from the check ended the \copy (...) wrapper, and a following TO PROGRAM clause was executed by psql on the pgAdmin host, as the operating-system account running pgAdmin, before the server rejected the statement. An ordinary database role can turn standard_conforming_strings off for itself, and the Import/Export Data permission is granted to non-administrators by default. This is a bypass of the fix for CVE-2026-17566. The fix rejects any backslash inside a double-quoted identifier, as was already done for single-quoted strings, since its meaning depends on a server setting that cannot be known reliably when the query is validated. This issue affects pgAdmin 4: before 9.19. | ||||
| CVE-2026-116248 | 1 Pgadmin | 1 Pgadmin 4 | 2026-10-30 | 6.8 Medium |
| In pgAdmin 4 server mode only administrators are meant to share a server with all users; the server dialog shows the Shared switch only to them. The create and update endpoints of the server API, however, stored the "shared" flag and shared username they were sent, so any user able to register a server could share one with every other user. The servers.json import had a similar gap: a non-administrator's "Shared" entries were removed only after validation, so a file that also held an invalid entry could create a shared server. A shared server carries no credentials, so this gives no direct access. It lets a user plant a server, named to look trusted, in every other user's tree and pointing at a host the user controls; anyone who then connects to it presents their own database password to that host. The fix refuses a non-administrator's request that would share a server with HTTP 403, prunes a non-administrator's shared entries from a servers.json import before validating it, and warns at startup about servers shared earlier by non-administrators. This issue affects pgAdmin 4: before 9.19. | ||||
| CVE-2026-116249 | 1 Pgadmin | 1 Pgadmin 4 | 2026-10-30 | 8.4 High |
| In server mode pgAdmin 4 resolves a server's password file, SSL certificate, key, CRL and SSH tunnel identity file relative to the user's storage directory, but get_complete_file_path() only stripped leading slashes before joining the two. A path such as "../<another user>/.pgpass", set through the server dialog, the REST API or a servers.json import, therefore named another user's file, and connecting used that user's saved passwords, client certificate or SSH key. The sslkeylogfile connection parameter was passed to libpq unchanged, so a path outside storage let libpq create or append a file as the account running pgAdmin. make_conninfo() also quoted connection parameter values but not their names, so a crafted parameter name could smuggle additional keyword=value pairs past these checks. The fix requires the resolved path, with symbolic links followed, to stay inside the user's storage directory or the named shared storage directory, confines sslkeylogfile the same way, and accepts only exact libpq keywords as connection parameter names. A refused path or keyword is reported instead of letting libpq fall back to a default. This issue affects pgAdmin 4: before 9.19. | ||||
| CVE-2026-116250 | 1 Pgadmin | 1 Pgadmin 4 | 2026-10-30 | 6.5 Medium |
| In server mode pgAdmin 4 validates a path a user gives for a file in their storage directory with check_access_permission() and then opened it by name. Several places opened it with a plain open() or handed the path to a utility that opened it later: the servers.json export and import and the import file listing, and the files given to pg_dump, pg_dumpall, pg_restore and psql by Backup, Restore and Import/Export Data. A symbolic link swapped in at the file or at any parent directory between the check and the open redirected the operation outside the storage directory, so a file could be written, overwritten or read, or loaded into a table, as the operating-system account running pgAdmin. A hard link to an outside file, which O_NOFOLLOW does not detect, and a FIFO, which could hang a request, had the same effect. CVE-2026-86861 fixed this for the File Manager's save_file; these were the remaining paths. Exploitation requires creating such a link or FIFO inside the user's storage directory. pgAdmin offers no way to do so, and the per-user storage directories belong to the pgAdmin account, so this requires write access to the storage backend as a different operating-system user, for example a shared or network-mounted storage directory, and winning the race. The fix opens each file by walking down from the storage directory one component at a time with O_NOFOLLOW, accepting only a regular file with one link, and passes the utilities the open descriptor (/dev/fd/N) on Linux. Error messages no longer include the server path. This issue affects pgAdmin 4: before 9.19. | ||||
| CVE-2026-119335 | 1 Pi-hole | 1 Pi-hole | 2026-10-30 | 7.8 High |
| Pi-hole is a DNS sinkhole that protects devices from unwanted content without installing any client-side software. Prior to 6.5, advanced/Scripts/utils.sh getFTLPID() attempts to validate the pihole-owned /run/pihole-FTL.pid file with expr "${FTL_PID}" : "[^[:digit:]]", but this rejects only values whose first character is not a digit. An attacker with code execution as the pihole user can write a digit-prefixed arithmetic expression to the pihole-owned PID file. Root-run pihole subcommands then evaluate [[ "$pid" -eq "-1" ]], causing Bash to recursively evaluate array subscripts and execute command substitution as root. This bypasses the content-validation portion of the CVE-2026-41489 remediation while leaving its hardcoded PID-file path protection intact. This issue is fixed in version 6.5. | ||||
| CVE-2026-119337 | 1 Infiniflow | 1 Ragflow | 2026-10-30 | 7.1 High |
| RAGFlow is an open-source RAG (Retrieval-Augmented Generation) engine. From 0.25.2 until 0.27.3, POST /api/v1/agents/chat/completions invokes completion_openai and returns through the openai-compatible branch before UserCanvasService.accessible() checks whether the caller may access the requested agent. An authenticated user who knows another user's private agent UUID can execute that Only me workflow and read its output across the user or tenant boundary; configured tools may also cause side effects, but stronger impacts were not demonstrated. This issue is fixed in version 0.27.3. | ||||
| CVE-2026-119342 | 1 Stirling | 1 Stirling Pdf | 2026-10-30 | 5.3 Medium |
| Stirling-PDF is a locally hosted web application that facilitates various operations on PDF files. From 2.13.1 until 2.13.2, the POST /api/v1/convert/svg/pdf endpoint renders attacker-supplied SVG through Apache Batik, and a scheme-less root-relative image reference bypasses SvgSanitizer.isExternalUrl() before Batik resolves it against the file:///input.svg document base as a same-origin local file. The convert() and addSvgAsPage() paths in app/core/src/main/java/stirling/software/SPDF/utils/SvgToPdf.java can then render image-decodable server files into the returned PDF when sanitization is enabled, including without authentication on login-disabled deployments or with non-admin access when login is enabled. The issue discloses PNG, JPG, GIF, or SVG content and provides an existence oracle only for image-decodable paths; plain text, binary files, directories, XInclude text, external entities, explicit file URLs, and tested HTTP references are not disclosed through this mechanism. This issue is fixed in version 2.13.2. | ||||
| CVE-2026-62254 | 1 Libredwg | 1 Libredwg | 2026-10-30 | 5.5 Medium |
| LibreDWG is a free C library to read and write DWG files. Prior to 0.14, a specially crafted R13-R2000 DWG can trigger algorithmic resource exhaustion in `decode_R13_R2000` in `src/decode.c`. The class-decoding loop performs `realloc` on every iteration without a sanity check on `num_classes`. Manipulating that field forces an extremely slow allocation loop and denial of service when the file is parsed. Running the parser in a sandbox with memory limits is a workaround rather than a remediation. This issue is fixed in version 0.14. | ||||
| CVE-2026-62250 | 1 Libredwg | 1 Libredwg | 2026-10-30 | 5.5 Medium |
| LibreDWG is a free C library to read and write DWG files. Prior to 0.14.8413, a crafted pre-R13 DWG can make `decode_preR13_entities()` in `src/decode.c` enter a nonterminating loop that allocates a new object each iteration. `decode_preR13` in `src/decode_r11.c` computes `size` from the raw file-controlled `entities_start` and `entities_end` header bounds; the callee clamps `end` to `dat->size` but never recalculates `size`. At `end` of input, `bit_read_RC` and `bit_read_RS` stop advancing `dat->byte`, the overflow guard fails because `end` equals `dat->size`, and the no-advance check compares against `oldpos` saved before the loop instead of the previous iteration. This leaves repeated allocation of `dwg->object` entries until allocation fails or the process is OOM-killed, not merely a constant-memory CPU hang. The defect remains after the clamping and no-progress changes associated with the earlier issue 1131. Applications and tools calling `dwg_read_file()` on untrusted files, including `dwg2dxf`, `dwgread` and `dwg2svg`, can suffer denial of service when a user or automated pipeline opens a malformed file; no attacker credentials are required. This issue is fixed in repository nightly version 0.14.8413. | ||||
| CVE-2026-54610 | 1 Libredwg | 1 Libredwg | 2026-10-30 | 3.3 Low |
| LibreDWG is a free C library to read and write DWG files. Prior to 0.14, `bit_TV_to_utf8()` in `src/bits.c` can write to the caller-provided `src` buffer despite accepting const input. On an `iconv()` error other than `E2BIG`, the function frees its output buffer and passes the original input alias to `bit_u_expand()`, which expands or shrinks Unicode and multibyte escape sequences in place. If the input is a string literal, read-only mapping, or other immutable buffer, the write can cause a segmentation fault and denial of service; mutable caller-owned input can be unexpectedly modified before being returned. This affects applications that expose the conversion API to untrusted input under those conditions. Direct file-triggered exploitability through normal DWG decode/export paths remains unconfirmed because many TV strings are heap allocated by bit_read_TV(). This issue is fixed in version 0.14. | ||||
| CVE-2026-57201 | 1 Asterisk | 2 Asterisk, Certified Asterisk | 2026-10-30 | 7.5 High |
| Asterisk is an open source private branch exchange and telephony toolkit. Prior to Asterisk 20.20.1, 21.12.3, 22.10.1, 23.4.1 and Certified Asterisk 20.7-cert11, 22.8-cert3, a stack buffer overflow in the H.323 `ooTrace()` trace-logging function can occur when unbounded `vsprintf` writes into a fixed `2048-byte buffer`. A remote attacker may send a carefully crafted packet that causes the Asterisk process to crash. The `chan_ooh323` addon channel driver must be explicitly compiled and installed, which is not the default, and its port must be publicly reachable. This issue is fixed in Asterisk 20.20.1, 21.12.3, 22.10.1, 23.4.1 and Certified Asterisk 20.7-cert11, 22.8-cert3. | ||||
| CVE-2026-57200 | 1 Asterisk | 2 Asterisk, Certified Asterisk | 2026-10-30 | 7.5 High |
| Asterisk is an open source private branch exchange and telephony toolkit. Prior to Asterisk 20.20.1, 21.12.3, 22.10.1, 23.4.1 and Certified Asterisk 22.8-cert3, an authenticated attacker with read-only permissions for the `Asterisk REST Interface (ARI)` may, under certain conditions, execute write operations through `REST-over-WebSocket`. The authorization bypass permits `arbitrary module path` loading and conditional remote code execution. The Asterisk HTTP web server must be enabled and reachable, and the attacker must already have valid `read-only ARI credentials`. HTTP is disabled by default and binds only to 127.0.0.1 by default even when enabled. This issue is fixed in Asterisk 20.20.1, 21.12.3, 22.10.1, 23.4.1 and Certified Asterisk 22.8-cert3. | ||||
| CVE-2026-57188 | 1 Asterisk | 2 Asterisk, Certified Asterisk | 2026-10-30 | 6.5 Medium |
| Asterisk is an open source private branch exchange and telephony toolkit. Prior to Asterisk 20.20.1, 21.12.3, 22.10.1, 23.4.1 and Certified Asterisk 20.7-cert11, 22.8-cert3, an authenticated attacker may cause a stack buffer overflow in `res_xmpp` `XMPP namespace prefix` handling using carefully crafted packets. The `res_xmpp` module must be loaded, an XMPP connection must be configured in `xmpp.conf`, and the attacker must have an XMPP account on the same or a federated server. This issue is fixed in Asterisk 20.20.1, 21.12.3, 22.10.1, 23.4.1 and Certified Asterisk 20.7-cert11, 22.8-cert3. | ||||
| CVE-2026-57185 | 1 Asterisk | 2 Asterisk, Certified Asterisk | 2026-10-30 | 6.5 Medium |
| Asterisk is an open source private branch exchange and telephony toolkit. Prior to Asterisk 20.20.1, 21.12.3, 22.10.1, 23.4.1 and Certified Asterisk 20.7-cert11, 22.8-cert3, an authenticated attacker may crash Asterisk through a buffer over-read in the `PJSIP MWI body parser` by sending a carefully crafted `SIP NOTIFY` request. The attacker must pass SIP authentication using either a username/password or `source IP address matching`. This issue is fixed in Asterisk 20.20.1, 21.12.3, 22.10.1, 23.4.1 and Certified Asterisk 20.7-cert11, 22.8-cert3. | ||||