Export limit exceeded: 380538 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (380538 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-55162 | 1 Netflix | 1 Lemur | 2026-08-18 | 6.3 Medium |
| Lemur manages TLS certificate creation. Prior to 1.9.2, lemur/certificates/verify.py accepted CRL Distribution Point and OCSP responder URLs from uploaded certificate extensions and used them in crl_verify and ocsp_verify without adequate destination validation. An authenticated operator could submit a certificate through POST /api/1/certificates/upload and cause verify_string to reach loopback, RFC1918, link-local, or instance-metadata destinations such as 169.254.169.254. The requests could probe internal services and create side effects from the Lemur host network position. The CRL path also used an unbounded cache, allowing attacker-controlled entries to persist and consume memory. The fix validates destinations, supports explicit trusted-host allowlists, and bounds the CRL cache. This issue is fixed in version 1.9.2. | ||||
| CVE-2026-52735 | 1 Zcashfoundation | 1 Zebra | 2026-08-18 | N/A |
| ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, Zebra can accept a block that zcashd rejects because the P2SH signature-operation counter undercounts redeem scripts containing a disabled opcode followed by signature opcodes. In zebra-script/src/lib.rs, p2sh_input_sigop_count used the pure-Rust script::Code::sig_op_count path, whose try_fold parser stops at disabled opcodes such as OP_CODESEPARATOR and returns only the partial count accumulated before the error. The zcashd reference implementation continues static signature-operation counting through disabled opcodes, so an attacker can broadcast P2SH spends that Zebra counts below MAX_BLOCK_SIGOPS while zcashd counts above the 20,000-operation limit. If a Zebra miner includes those transactions, Zebra validators accept the block while zcashd validators reject it, creating a consensus chain split that affects network integrity and availability without requiring the attacker to produce a block. This issue is fixed in version 4.5.0. | ||||
| CVE-2026-52829 | 1 Zcashfoundation | 1 Zebra | 2026-08-18 | 7.5 High |
| ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, an unauthenticated IPv4 peer can deterministically terminate a synced Zebra node using the default Linux dual-stack listener configuration. The handshake path canonicalized an IPv4-mapped IPv6 PeerSocketAddr such as ::ffff:127.0.0.1 to plain IPv4 before storing it through MetaAddr::new_connected, but the mempool misbehavior path forwarded the raw transient address to MetaAddrChange::UpdateMisbehavior. In zebra-network/src/meta_addr.rs, apply_to_meta_addr then compared the canonical address-book entry with the raw update address and reached its unexpected address mismatch assertion. After the misbehavior batch flush, panic equals abort terminated zebrad; the peer only needed to complete a P2P handshake and advertise an invalid mempool transaction. This issue is fixed in version 4.5.0. | ||||
| CVE-2026-55164 | 1 Netflix | 1 Lemur | 2026-08-18 | 4.9 Medium |
| Lemur manages TLS certificate creation. Prior to 1.9.2, lemur.users.service.update assigned a replacement password directly to users.password, while lemur/users/models.py registered User.hash_password only for the before_insert event. Because no before_update listener ran, administrator-initiated password changes through PUT /api/1/users/ were committed as plaintext. The affected user could no longer authenticate normally because bcrypt verification received an unhashed value. A database, backup, replica, query-log, or administrative read compromise exposed immediately usable credentials without offline cracking. The fix registers hashing for before_update and avoids rehashing values that already have a bcrypt prefix. This issue is fixed in version 1.9.2. | ||||
| CVE-2026-71303 | 1 Netflix | 1 Lemur | 2026-08-18 | 7.7 High |
| Lemur manages TLS certificate creation. Prior to 1.9.3, _validate_acme_url enforced ACME_DIRECTORY_HOST_ALLOWLIST when an authority was created, but PUT /api/1/authorities/ passed options to lemur/authorities/service.py without applying the same check. A user holding an authority role could replace the stored acme_url with an internal service or instance-metadata URL such as 169.254.169.254. The next issuance operation loaded that value and passed it to ClientV2.get_directory, causing an outbound request from the Lemur backend. This bypassed the creation-time mitigation for CVE-2026-55166 and could expose internal services or cloud metadata. The fix revalidates acme_url whenever authority options are updated. This issue is fixed in version 1.9.3. | ||||
| CVE-2026-70666 | 1 Netflix | 1 Lemur | 2026-08-18 | 7.4 High |
| Lemur manages TLS certificate creation. Prior to 1.9.3, an authority-role member could update acme_url through PUT /api/1/authorities/ without revalidation and direct setup_acme_client_no_retry to an attacker-controlled ACME server. ACME directory and order responses contain newNonce, newOrder, authorizations, and finalize URLs chosen by that server. The Lemur ClientV2 followed those URLs without requiring their host to match the configured directory host, allowing JWS-signed requests to internal services or cloud metadata endpoints. The issue required an ACME authority and a user authorized for that authority, but did not require global administrator privileges. The fix revalidates updates and introduces _PinnedClientNetwork to enforce a single allowed host for the complete ACME flow. This issue is fixed in version 1.9.3. | ||||
| CVE-2026-71317 | 1 Netflix | 1 Lemur | 2026-08-18 | 6.5 Medium |
| Lemur manages TLS certificate creation. Prior to 1.9.3, POST /api/1/authorities with type=subca did not require AuthorityPermission on the parent authority when ADMIN_ONLY_AUTHORITY_CREATION was false. AssociatedAuthoritySchema resolved the caller-supplied parent and passed it through authority creation to cryptography-issuer, which used the parent authority_certificate.private_key to sign a new intermediate. Any authenticated non-read-only user in that supported configuration could chain a sub-CA to an internal root for which the user held no role. The resulting intermediate could issue trusted certificates and its private key could be used outside Lemur, bypassing normal issuance controls. The fix checks AuthorityPermission on every supplied parent before invoking the issuer. This issue is fixed in version 1.9.3. | ||||
| CVE-2026-71322 | 1 Netflix | 1 Lemur | 2026-08-18 | 4.3 Medium |
| Lemur manages TLS certificate creation. Prior to 1.9.3, CertificateExport placed its CertificatePermission ownership check inside the plugin.requires_key branch for POST /api/1/certificates//export. A plugin declaring requires_key false bypassed that check, and the handler still passed cert.private_key as an argument and recorded a key_view audit event. The bundled JavaTruststoreExportPlugin ignored the key, so the immediate exposure was limited to public certificate material and misleading audit entries, but a future plugin could have consumed the supplied key. The fix passes no private key to plugins that do not require one and confines ownership checks and key_view logging to actual private-key exports. This issue is fixed in version 1.9.3. | ||||
| CVE-2026-71417 | 1 Netflix | 1 Lemur | 2026-08-18 | 7.3 High |
| Lemur manages TLS certificate creation. Prior to 1.9.3, POST /api/1/certificates/upload allowed a non-read-only user to create a duplicate row using another certificate body, authority_id, serial, or external_id without requiring permission on the underlying authority. PUT /api/1/certificates//revoke authorized the caller against only the selected Lemur row, so the creator of the duplicate bypassed CertificatePermission. The duplicate had no cert.endpoints, which also bypassed the safeguard that prevents revocation of deployed certificates. Issuer plugins then revoked the real CA-side certificate using certificate.body or external_id under the stored authority credentials. An attacker could therefore revoke arbitrary managed certificates and cause fleet-wide TLS denial of service. The fix rejects duplicate authority_id and serial identities, requires authority access on upload, and checks every matching row during revocation. This issue is fixed in version 1.9.3. | ||||
| CVE-2026-56874 | 2026-08-18 | N/A | ||
| reserved but not needed | ||||
| CVE-2026-56873 | 2026-08-18 | N/A | ||
| reserved but not needed | ||||
| CVE-2026-56872 | 2026-08-18 | N/A | ||
| reserved but not needed | ||||
| CVE-2026-56871 | 2026-08-18 | N/A | ||
| reserved but not needed | ||||
| CVE-2026-56870 | 2026-08-18 | N/A | ||
| reserved but not needed | ||||
| CVE-2026-56869 | 2026-08-18 | N/A | ||
| reserved but not needed | ||||
| CVE-2026-56868 | 2026-08-18 | N/A | ||
| reserved but not needed | ||||
| CVE-2026-56867 | 2026-08-18 | N/A | ||
| reserved but not needed | ||||
| CVE-2026-16048 | 1 Mattermost | 2 Mattermost, Mattermost Server | 2026-08-18 | 6.3 Medium |
| Mattermost versions 11.8.x <= 11.8.2, 11.7.x <= 11.7.6, 10.11.x <= 10.11.21 fail to restrict channel member role assignment to channel-scoped roles which allows a channel administrator to gain additional channel permissions via the channel member roles API.. Mattermost Advisory ID: MMSA-2026-00697 | ||||
| CVE-2026-16047 | 1 Mattermost | 2 Mattermost, Mattermost Server | 2026-08-18 | 4.3 Medium |
| Mattermost versions 11.7.x <= 11.7.6, 10.11.x <= 10.11.21, 11.8.x <= 11.8.3 fail to validate that users have read access to a channel before linking a board to it, which allows an authenticated attacker to discover the membership of private channels on the same team via creating, patching, importing, or bulk-creating boards with an arbitrary channelId. Mattermost Advisory ID: MMSA-2026-00674 | ||||
| CVE-2026-16046 | 1 Mattermost | 2 Mattermost, Mattermost Server | 2026-08-18 | 3.5 Low |
| Mattermost versions 11.7.x <= 11.7.6, 10.11.x <= 10.11.21 fail to enforce run-state validation on write operations for finished playbook runs which allows a run participant to modify status, checklists, retrospective content, ownership, and participants on completed runs via REST and GraphQL API requests. Mattermost Advisory ID: MMSA-2026-00675 | ||||