| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| 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. |
| Lemur manages TLS certificate creation. Prior to 1.9.3, _validate_revocation_url in lemur/certificates/verify.py checked the original CRL or OCSP URL but the later request could reach a different destination. The CRL requests.get call followed HTTP redirects without validating each Location target, so a public attacker-controlled URL could redirect to loopback, RFC1918, link-local, or instance-metadata addresses. Validation and connection also performed separate DNS resolutions, creating a time-of-check time-of-use window for DNS rebinding on both CRL and OCSP paths. An operator uploading a certificate through POST /api/1/certificates/upload could therefore induce blind internal requests despite the earlier mitigation. The fix disables redirects and pins validated addresses while preserving the correct Host value. This issue is fixed in version 1.9.3. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| reserved but not needed |
| reserved but not needed |
| reserved but not needed |
| reserved but not needed |
| reserved but not needed |
| reserved but not needed |
| reserved but not needed |
| reserved but not needed |
| 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 |
| 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 |
| 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 |
| Mattermost versions 11.7.x <= 11.7.6, 10.11.x <= 10.11.21 Mattermost failed to restrict OAuth deauthorization and personal access token management endpoints to direct user sessions, which allowed an OAuth app with a delegated user token to revoke the user's authorizations or tokens for other integrations via account-management endpoints.. Mattermost Advisory ID: MMSA-2026-00704 |
