Export limit exceeded: 24374 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 401276 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 401276 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (401276 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-87057 | 1 Olm-operator-konflux-sample | 1 Olm-operator-konflux-sample | 2026-10-04 | 4.2 Medium |
| A flaw was found in olm-operator-konflux-sample. The build pipelines use mutable floating tags to reference runtime base images instead of immutable SHA256 digests. This configuration allows for the content of the base images to be altered without detection, potentially leading to the introduction of malicious code or unexpected changes in the build process. An attacker could exploit this to compromise the integrity of the software supply chain. | ||||
| CVE-2026-87061 | 1 Olm-operator-konflux-sample | 1 Olm-operator-konflux-sample | 2026-10-04 | 2.6 Low |
| A flaw was found in olm-operator-konflux-sample. The `bundle-hack/update_bundle.sh` script lacks mechanisms to stop execution immediately upon encountering an error. This oversight allows critical data processing steps, such as those involving `skopeo` or `jq` commands, to fail silently and proceed with outdated or incomplete information. Consequently, this could lead to data integrity issues within the system. | ||||
| CVE-2026-87064 | 1 Konflux-operator-tasks | 1 Konflux-operator-tasks | 2026-10-04 | 2.6 Low |
| A flaw was found in konflux-operator-tasks. The GitHub workflows used by this component do not explicitly define their required permissions. This oversight means the workflows may inherit default access tokens that grant broader privileges than intended. Such excessive permissions could potentially allow an attacker to gain unauthorized access or perform actions beyond the intended scope, leading to information disclosure or unauthorized modifications. | ||||
| CVE-2026-96577 | 2 Oc-mirror, Redhat | 3 Oc-mirror, Assisted Installer, Openshift | 2026-10-04 | 7.1 High |
| A flaw was found in oc-mirror. During mirroring operations, the embedded local cache registry binds to all network interfaces without authentication or encryption instead of restricting access to the local system. An unauthenticated attacker on an adjacent network can connect to the exposed service to push tampered container images, delete cached images, or access mirrored content. | ||||
| CVE-2026-94282 | 2 Libxi, X.org | 2 Libxi, Libxi | 2026-10-04 | 5.6 Medium |
| An out-of-bounds read in libXi's XI2 enter/leave/focus cookie conversion in libXi before 1.8.4 could be used by malicious X server to crash an attached X client. | ||||
| CVE-2026-95622 | 1 Modemmanager | 1 Modemmanager | 2026-10-04 | 6.5 Medium |
| A flaw was found in ModemManager. When parsing a Cell Broadcast Message, some 3GPP data-coding-scheme values (8-bit and reserved character sets) are not handled. The process hits a reachable assertion and aborts. An attacker who can deliver a crafted Cell Broadcast PDU over the radio network, or via a modem AT channel, can cause ModemManager to exit. Repeated aborts can exhaust systemd's default start limit and leave the service failed. | ||||
| CVE-2026-94603 | 1 Podman Project | 1 Podman | 2026-10-04 | 8.6 High |
| A flaw was found in Podman. When a container image with checkpoint annotations is executed using the podman run command, Podman treats the image as a restored checkpoint and ignores user-specified sandboxing options, such as dropped privileges. An attacker can exploit this issue by enticing a user to run a specially crafted image, leading to a container sandbox bypass and potential execution with elevated system privileges. | ||||
| CVE-2026-103431 | 1 Collectl | 1 Collectl | 2026-10-04 | 7.7 High |
| colmux in collectl before 4.3.20.2 does not sanitize ANSI/VT100 terminal escape sequences in data received from remote collectl instances before displaying it, allowing a local user on a monitored host to inject escape sequences into the terminal of an operator running colmux, via a crafted process name (argv[0]). | ||||
| CVE-2026-67172 | 1 Hcltech | 1 Bigfix Service Management | 2026-10-04 | 3.7 Low |
| HCL BigFix Service Management is affected by an Information Disclosure vulnerability the application returns sensitive information in error messages when invalid inputs are sent to certain API endpoints . This information could enable an attacker to facilitate further attacks. | ||||
| CVE-2025-31980 | 1 Hcltech | 1 Bigfix Service Management | 2026-10-04 | 4.3 Medium |
| HCL BigFix Service Management is affected by an Improper Input Validation vulnerability, which could allow an attacker to inject unvalidated, malformed data into the application, enabling potential injection attacks or errors in downstream processing systems. | ||||
| CVE-2026-12423 | 2 Redhat, Theforeman | 4 Satellite, Satellite Capsule, Satellite Utils and 1 more | 2026-10-04 | 7.5 High |
| A flaw was found in Foreman. The Red Hat Satellite /unattended/provision API endpoint is vulnerable to an authentication bypass due to a semantic logic flaw in host_verifier.rb. The application verifies the database state of a provisioning token rather than its actual presence in the incoming HTTP request. Because a host actively undergoing provisioning has an unexpired token in the database, the server's valid_host_token? method evaluates to true, granting access to the kickstart template even if the requester provides no token at all in the URL. | ||||
| CVE-2025-71427 | 1 Gongrzhe | 1 Office-word-mcp-server | 2026-10-04 | 6.8 Medium |
| Office-PowerPoint-MCP-Server through 2.0.7 contains a path traversal vulnerability that allows MCP callers to write and read files outside the working directory by supplying absolute paths or ../ sequences. Attackers can steer an AI agent via prompt injection to abuse save_presentation, open_presentation, or manage_image output_path to overwrite any server-writable file or load external files. | ||||
| CVE-2026-17508 | 1 Legion Of The Bouncy Castle Inc. | 3 Bc-fja, Bc-java, Bc-lts-java | 2026-10-04 | N/A |
| In Bouncy Castle for Java before 1.86, several password-based key derivation entry points ran the KDF with cost parameters taken from the untrusted input being processed, without bounding them, so a small input could dictate an arbitrary amount of work before any password or integrity check could reject it. The affected paths are the RFC 9579 PBMAC1 MAC calculator builders, which took the PBKDF2 iteration count and derived-key length straight out of PBMAC1Params (JcePBMac1CalculatorBuilder, and PKCS12PBEUtils.createPBMac1Calculator reached from PKCS12PfxPdu.isMacValid); the scrypt parallelization parameter p in the PKCS#8 and PKCS#12 cost guards, which bounded only the cost parameter N and the block size r even though the scratch buffer scales with r times p, so the configured memory ceiling could be evaded entirely; the raw JCA PBKDF2 provider (org.bouncycastle.jcajce.provider.symmetric.PBEPBKDF2); and the bcrypt round count read from an encrypted OpenSSH v1 private key's own kdfoptions. Each now bounds the parameter before deriving, in line with the caps already applied elsewhere in the tree, with the OpenSSH round count configurable through the new org.bouncycastle.openssh.max_rounds property. This completes the bounding begun in 1.85 for the PKCS#8 / PBES2 decryptors (CVE-2026-15055). This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series). | ||||
| CVE-2026-103763 | 2 B3log, Siyuan | 2 Siyuan, Siyuan | 2026-10-04 | 5.8 Medium |
| SiYuan before v3.8.5 contains an information disclosure vulnerability that allows read-only publish readers to learn metadata of publish-excluded documents through the getNotebookInfo endpoint. Attackers, including anonymous visitors when no reader password is set, can query publish-visible notebooks to obtain document count, size and modification timestamps of hidden documents. | ||||
| CVE-2026-104733 | 1 Process-one | 1 Ejabberd | 2026-10-04 | N/A |
| User Impersonation in ProcessOnes XMMP Server ejabberd <= 26.04 allows an attacker to impersonate arbitrary users via unvalidated authzid parameter in SASL-PLAIN mechanism. | ||||
| CVE-2026-104721 | 1 Qos.ch Sarl | 1 Logback-classic | 2026-10-04 | 5.6 Medium |
| Path-traversal vulnerability in QOS.CH Sarl Logback-classic on Java (logback-classic module) allows path-traversal vulnerability. More specifically, an MDC-based discriminator value flows unsanitized into a nested FileAppender path, letting an attacker who influences that MDC value (e.g. via an HTTP header) create and append log files outside the intended directory. This issue affects Logback-classic: from 0.9.14 through 1.6.4. This vulnerability is similar to CVE-2026-19880 but involves other attack techniques. | ||||
| CVE-2026-104982 | 2 Linux Mint, Linuxmint | 2 Xreader, Xreader | 2026-10-04 | 4.3 Medium |
| A flaw has been found in Linux Mint Xreader up to 4.6.5. This issue affects the function setup_document_content_list/g_strdup_printf of the file backend/epub/epub-document.c of the component EPUB File Handler. This manipulation causes path traversal. The attack is possible to be carried out remotely. The exploit has been published and may be used. Upgrading to version 4.6.6 is capable of addressing this issue. Patch name: a5aecea074e8564b7a22f1ce054b31ec862974b7. It is advisable to upgrade the affected component. One of the project maintainers explains, that "EPUB support was removed from Xreader and reimplemented in Xepub". | ||||
| CVE-2026-97873 | 1 Legion Of The Bouncy Castle Inc. | 2 Bc-java, Bc-lts-java | 2026-10-04 | N/A |
| In Bouncy Castle for Java before 1.86, the raw JCA provider's legacy PBES1 (PKCS#5 scheme 1) and PKCS#12 PBE families ran their password-based key derivation with an iteration count taken from untrusted input without bounding it, so a small input could dictate an arbitrary amount of work before anything could be verified. The AlgorithmParameters implementations (PKCS12PBE and its object identifier aliases, and PBKDF1) accepted any count from an encoded PKCS12PBEParams or PBEParameter, narrowing a value beyond the int range with intValue(), and every Cipher, Mac and SecretKeyFactory in these families derived with whatever count it was given, including one decoded by another provider's AlgorithmParameters, as when javax.crypto.EncryptedPrivateKeyInfo.getKeySpec() decrypts a PKCS#12 PBE-protected private key with BC. Both the parameter parse and the derivations now reject a negative or over-limit count under the org.bouncycastle.pbe.max_iteration_count property (default 10,000,000) that already bounded PBKDF2 (CVE-2026-17508), and the parse rejects a count beyond the int range rather than narrowing it. This issue also affects Bouncy Castle for Java LTS before 2.73.13. | ||||
| CVE-2026-85515 | 1 Legion Of The Bouncy Castle Inc. | 3 Bc-fja, Bc-java, Bc-lts-java | 2026-10-04 | N/A |
| In Bouncy Castle for Java before 1.86, a truncated OpenPGP encrypted message was accepted with no error reported, and on the SEIPD version 1 path with no integrity check performed at all. RFC 9580 sec. 13.7 permits an implementation to release the cleartext of the fully authenticated chunks when streaming but requires it to indicate a clear error as soon as the truncation is detected, and to report suspect integrity when it discovers malleable ciphertext. The truncation was detected and then discarded: when a message is truncated but the length field of the enclosing packet is left unchanged, BCPGInputStream.PartialInputStream raises an EOFException for the missing ciphertext, and BCPGInputStream.nextPacketTag() reports an EOFException as a clean end of message, so the packet stream above it stopped as though no packets remained. On the AEAD path (SEIPD version 2 and the version 5 AEAD packet), when the literal data packet ended on an AEAD chunk boundary and the consumer read in increments smaller than one chunk, the look-ahead for the packet after the literal triggered the truncated chunk read, so BcAEADUtil and JceAEADUtil never reached the trailing message tag of sec. 5.13.2 that authenticates the total plaintext length; the caller received the plaintext of the fully authenticated chunks, every packet following the literal was silently dropped, and no exception was raised, so a signed and encrypted message read back as a well-formed unsigned one. Every byte released on that path remained individually authenticated, making this a missing truncation error rather than a forgery, and it is a residual of CVE-2026-12817, which closed the same outcome for an attacker who corrects the outer packet length. On the SEIPD version 1 path the consequence was more serious: IntegrityProtectedInputStream verifies the modification detection code from close(), and reached close() only by closing itself when a read of it returned -1, which a truncated message never produces, so PGPEncryptedData.verify() never ran and the recipient was handed CFB-decrypted plaintext on which no integrity check of any kind had been performed. Measured on a message truncated into that shape, 136 distinct single-byte modifications of the ciphertext produced accepted, altered plaintext with no exception raised. Reachability is a property of the message rather than of attacker-supplied input: the AEAD shape held for 3 of 131 consecutive payload lengths measured, and the SEIPD version 1 shape for one payload length in sixteen, at a truncation offset that did not move with the payload length. The low-level API is unaffected, a caller that invokes PGPEncryptedData.verify() directly getting the check regardless, as are consumers reading in increments of a whole AEAD chunk or more. The AEAD decryption streams now re-throw such an EOFException as a plain IOException, which nextPacketTag() does not launder; OpenPGPMessageInputStream.close() now closes its layer's integrity-protected stream itself rather than relying on that stream having seen the end of its data; and IntegrityProtectedInputStream.close() was made idempotent, as java.io.Closeable requires, which that depends on, since the stream is genuinely closed twice on the ordinary path and PGPEncryptedData.verify() consumes the digest state behind it and cannot be run a second time. This issue also affects Bouncy Castle for Java LTS before 2.73.13, on the AEAD route only, as that edition does not ship the high-level OpenPGP API the SEIPDv1 route runs through. It also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpg-fips 1.0.14 (1.0.X series), 2.0.14.1 (2.0.X series) and 2.1.14 (2.1.X series), on the AEAD route only, as those editions do not ship the high-level OpenPGP API. | ||||
| CVE-2026-71892 | 1 Legion Of The Bouncy Castle Inc. | 2 Bc-fja, Bc-java | 2026-10-04 | N/A |
| In Bouncy Castle for Java before 1.86, the opt-in key-size validation on CMS key-transport recipients, org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation(true), never ran for a message using RFC 9709 content-encryption key derivation (id-alg-cek-hkdf-sha256). The branch that should have selected the actual content-encryption algorithm carried in the key derivation AlgorithmIdentifier's parameters compared the encrypted-key byte array against the id-alg-cek-hkdf-sha256 object identifier, a comparison between a byte array and an ASN1ObjectIdentifier that is false for every possible input, so the check fell through to a key-size lookup on the outer wrapper OID. That OID identifies a key-derivation construction rather than a cipher and has no registered key size, so the size comparison was skipped entirely. A key-transport EnvelopedData or AuthEnvelopedData whose transported, HKDF-derived content-encryption key did not match the key size of the advertised content-encryption algorithm was therefore accepted even with validation explicitly enabled, silently defeating the only mechanism the API offers for enforcing recovered key size. The recipient now dispatches on the content-encryption AlgorithmIdentifier's algorithm OID, so validation checks the recovered key against the inner content-encryption algorithm. Messages with a matching key size, non-HKDF messages, and recipients that do not enable validation are unaffected. This issue also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series). | ||||