Export limit exceeded: 10620 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (10620 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-41021 | 1 Eaton | 1 Easye4 | 2026-11-04 | 7.5 High |
| Eaton easyE4 uses an insufficiently strong password policy. An attacker who obtains a password hash, including through CVE-2026-41020, could perform an offline password-guessing attack and potentially recover user credentials. | ||||
| CVE-2026-117341 | 1 Octopus | 1 Octopus Server | 2026-11-04 | N/A |
| In affected versions of Octopus Server, creating a user invitation writes the invitation code to the audit event log. When the invitation is linked to a space, a user in that space with appropriate permissions could read the code from the audit event. Successfully exploiting this by redeeming the unclaimed invitation could allow the user to escalate privileges however this is dependant on the permissions assigned for the invited user. | ||||
| CVE-2026-115750 | 1 Frontmcp | 1 Mcp-from-openapi | 2026-11-04 | 3.7 Low |
| mcp-from-openapi from 2.5.0 before 2.9.0 contains a credential exposure vulnerability that allows attackers to capture Authorization and Cookie headers because safeFetch() forwards them on cross-origin redirects. Attackers controlling a spec host or abusing an open redirect can redirect fromURL() spec requests to their own origin to steal bearer tokens or cookies. | ||||
| CVE-2026-114409 | 1 Docker | 1 Desktop | 2026-11-04 | N/A |
| Docker Desktop before version 4.97.0 could write third-party API keys and OAuth access tokens in cleartext to local application logs and diagnostics bundles due to insufficient IPC payload redaction. An attacker with read access to these files could obtain the credentials. These OAuth tokens are not Docker account tokens. Docker Desktop 4.94.0 and 4.95.0 addressed the known logging paths, but logs containing credentials can remain after upgrading. Docker Desktop 4.97.0 fixes the issue and includes cleanup of existing host logs and crash dumps. | ||||
| CVE-2026-108332 | 1 Tanium | 2 Endpoint Configuration Toolset Solution, Threat Response | 2026-11-04 | 6.3 Medium |
| Tanium addressed an improper link resolution before file access vulnerability in Threat Response Client Extension. | ||||
| CVE-2026-108328 | 1 Tanium | 1 Threat Response | 2026-11-04 | 4.2 Medium |
| Tanium addressed an insertion of sensitive information into log file vulnerability in Threat Response. | ||||
| CVE-2026-108325 | 1 Tanium | 1 Reputation | 2026-11-04 | 6.6 Medium |
| Tanium addressed an insertion of sensitive information into log file vulnerability in Reputation. | ||||
| CVE-2026-108306 | 1 Tanium | 2 End-user-cx, Endpoint Configuration Toolset Solution | 2026-11-04 | 7.8 High |
| Tanium addressed a local privilege escalation vulnerability in End-User Notifications. | ||||
| CVE-2026-108305 | 1 Tanium | 2 End-user-cx, Endpoint Configuration Toolset Solution | 2026-11-04 | 7.8 High |
| Tanium addressed a local privilege escalation vulnerability in End-User Notifications. | ||||
| CVE-2024-3094 | 2 Redhat, Tukaani | 4 Enterprise Linux, Jboss Enterprise Application Platform, Rhel Els and 1 more | 2026-11-04 | 10 Critical |
| Malicious code was discovered in the upstream tarballs of xz, starting with version 5.6.0. Through a series of complex obfuscations, the liblzma build process extracts a prebuilt object file from a disguised test file existing in the source code, which is then used to modify specific functions in the liblzma code. This results in a modified liblzma library that can be used by any software linked against this library, intercepting and modifying the data interaction with this library. | ||||
| CVE-2024-1753 | 1 Redhat | 4 Enterprise Linux, Openshift, Rhel Els and 1 more | 2026-11-04 | 8.6 High |
| A flaw was found in Buildah (and subsequently Podman Build) which allows containers to mount arbitrary locations on the host filesystem into build containers. A malicious Containerfile can use a dummy image with a symbolic link to the root filesystem as a mount source and cause the mount operation to mount the host root filesystem inside the RUN step. The commands inside the RUN step will then have read-write access to the host filesystem, allowing for full container escape at build time. | ||||
| CVE-2026-14252 | 1 Ibm | 1 Mq | 2026-11-04 | 6.2 Medium |
| IBM MQ 9.2.0.0 through 9.2.0.44 LTS, 9.3.0.0 through 9.3.0.42 LTS, 9.4.0.0 through 9.4.0.26 LTS, 9.4.0.0 through 9.4.5.1 CD, and 10.0.0.0 through 10.0.0.5 LTS and CD stores potentially sensitive information in log files that could be read by a local user. | ||||
| CVE-2026-113371 | 1 Sonatype | 1 Nexus Repository Manager | 2026-11-04 | N/A |
| Sonatype Nexus Repository 3 returns the signing passphrase of an APT or YUM repository, through an internal REST endpoint, to a user account that holds only the read privilege for administering that repository. The account does not need the privilege to edit the repository. | ||||
| CVE-2026-113372 | 1 Sonatype | 1 Nexus Repository Manager | 2026-11-04 | N/A |
| Sonatype Nexus Repository 3 returns the private signing key of a YUM proxy or group repository to an account that holds only the read privilege for administering that repository. The account does not need the privilege to edit the repository. A party that holds the key can sign repository metadata as that repository. | ||||
| CVE-2026-84528 | 1 Apple | 1 Macos | 2026-11-04 | 3.3 Low |
| A logging issue was addressed with improved data redaction. This issue is fixed in macOS Golden Gate 27, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2. An app may be able to access sensitive user data. | ||||
| CVE-2026-86966 | 1 Apple | 5 Ios And Ipados, Ipados, Iphone Os and 2 more | 2026-11-04 | 5.5 Medium |
| This issue was addressed with improved handling of symlinks. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27 and iPadOS 27, macOS Golden Gate 27, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2, visionOS 27. An app may be able to modify protected parts of the file system. | ||||
| CVE-2026-116242 | 1 Pgadmin | 1 Pgadmin 4 | 2026-11-04 | 8.2 High |
| pgAdmin 4 opens SSH tunnels with the sshtunnel library but gave it neither host_pkey_directories nor ssh_config_file, so it always loaded the unencrypted private keys in ~/.ssh of the operating-system account running pgAdmin, read that account's ~/.ssh/config (IdentityFile, User, HostName, ProxyCommand) for the tunnel host, and could use its ssh-agent. In server mode any user could therefore configure a tunnel to a host that accepts the service account's key, with no credentials of their own or with an identity file that did not exist in their storage, and reach it as that account. The fix makes tunnels in server mode use only the identity file or password the user configured: the service account's keys, configuration and agent are no longer used, and an identity file that cannot be found in the user's storage is reported instead of falling back to ~/.ssh. Desktop mode is unchanged. This issue affects pgAdmin 4: before 9.19. | ||||
| CVE-2026-116244 | 1 Pgadmin | 1 Pgadmin 4 | 2026-11-04 | 8.2 High |
| When a pgAdmin 4 connection was not meant to use a Kerberos user's delegated credentials, pgAdmin removed KRB5CCNAME from its environment, so the Kerberos library fell back to the default credential cache, or a client keytab, of the operating-system account running pgAdmin. libpq then answered any server that asked for GSSAPI authentication with that account's ticket, whatever user name the pgAdmin user gave, so in server mode any user could connect as the service account's Kerberos principal; gssencmode=disable did not prevent it. On Windows, SSPI used the service account's logon in the same way. psql was also started with pgAdmin's environment, which could hold another user's credential cache while that user was connecting. The fix points KRB5CCNAME and KRB5_CLIENT_KTNAME at a file that cannot exist except while a Kerberos-authenticated user connects with Kerberos, and gives every other connection, psql and the utilities require_auth=!gss,!sspi and gssencmode=disable, checked on the final connection string. require_auth needs libpq 16 or later. This issue affects pgAdmin 4: before 9.19. | ||||
| CVE-2026-116814 | 1 Openpanel | 1 Openpanel | 2026-11-04 | 6.5 Medium |
| OpenPanel before 3.0.0 contains an information exposure vulnerability that writes database connection URLs and email template data to standard output logs. Users with log access can obtain database credentials from migration startup logs and password-reset tokens logged when SMTP_HOST and RESEND_API_KEY are unset. | ||||
| CVE-2026-116245 | 1 Pgadmin | 1 Pgadmin 4 | 2026-11-04 | 8.2 High |
| libpq looks a connection service up in the service file of the operating-system account running pgAdmin 4, and an entry there can hold a password or name a password file or client certificate. In server mode any user could set a server's Service, or a "service" connection parameter, to one of those entries and connect with its credentials. A PGPASSWORD or PGSERVICE variable set for that account was likewise used by libpq for every connection without a value of its own and passed on to the utilities, and pg_dumpall read a maintenance database name such as "service=..." as a connection string. The fix adds the SERVER_MODE_ALLOWED_SERVICES setting, empty by default: in server mode only a listed service can be used, the servicefile parameter is refused, and PGPASSWORD and PGSERVICE are removed from pgAdmin's environment at startup. The allowlist is checked again on the final connection string, and the pg_dumpall database name is wrapped as a connection string. This issue affects pgAdmin 4: before 9.19. | ||||