CVE-2026-41583

{"id": "CVE-2026-41583", "cveTags": [], "metrics": {"ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-41583", "role": "CISA Coordinator", "options": [{"exploitation": "none"}, {"automatable": "yes"}, {"technicalImpact": "total"}], "version": "2.0.3", "timestamp": "2026-05-08T19:42:41.730920Z"}}], "cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 9.1, "attackVector": "NETWORK", "baseSeverity": "CRITICAL", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "NONE", "confidentialityImpact": "NONE"}, "impactScore": 5.2, "exploitabilityScore": 3.9}], "cvssMetricV40": [{"type": "Secondary", "source": "security-advisories@github.com", "cvssData": {"Safety": "NOT_DEFINED", "version": "4.0", "Recovery": "NOT_DEFINED", "baseScore": 9.3, "Automatable": "NOT_DEFINED", "attackVector": "NETWORK", "baseSeverity": "CRITICAL", "valueDensity": "NOT_DEFINED", "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X", "exploitMaturity": "NOT_DEFINED", "providerUrgency": "NOT_DEFINED", "userInteraction": "NONE", "attackComplexity": "LOW", "attackRequirements": "NONE", "privilegesRequired": "NONE", "subIntegrityImpact": "HIGH", "vulnIntegrityImpact": "HIGH", "integrityRequirement": "NOT_DEFINED", "modifiedAttackVector": "NOT_DEFINED", "subAvailabilityImpact": "HIGH", "vulnAvailabilityImpact": "HIGH", "availabilityRequirement": "NOT_DEFINED", "modifiedUserInteraction": "NOT_DEFINED", "modifiedAttackComplexity": "NOT_DEFINED", "subConfidentialityImpact": "NONE", "vulnConfidentialityImpact": "NONE", "confidentialityRequirement": "NOT_DEFINED", "modifiedAttackRequirements": "NOT_DEFINED", "modifiedPrivilegesRequired": "NOT_DEFINED", "modifiedSubIntegrityImpact": "NOT_DEFINED", "modifiedVulnIntegrityImpact": "NOT_DEFINED", "vulnerabilityResponseEffort": "NOT_DEFINED", "modifiedSubAvailabilityImpact": "NOT_DEFINED", "modifiedVulnAvailabilityImpact": "NOT_DEFINED", "modifiedSubConfidentialityImpact": "NOT_DEFINED", "modifiedVulnConfidentialityImpact": "NOT_DEFINED"}}]}, "affected": [{"source": "security-advisories@github.com", "affectedData": [{"vendor": "ZcashFoundation", "product": "zebra", "versions": [{"status": "affected", "version": "zebrad < 4.3.1"}, {"status": "affected", "version": "zebra-script < 5.0.2"}]}]}], "published": "2026-05-08T15:16:41.070", "references": [{"url": "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-8m29-fpq5-89jj", "tags": ["Vendor Advisory"], "source": "security-advisories@github.com"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Secondary", "source": "security-advisories@github.com", "description": [{"lang": "en", "value": "CWE-573"}]}], "descriptions": [{"lang": "en", "value": "ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.3.1 and prior to zebra-script version 5.0.2, after a refactoring, Zebra failed to validate a consensus rule that restricted the possible values of sighash hash types for V5 transactions which were enabled in the NU5 network upgrade. Zebra nodes could thus accept and eventually mine a block that would be considered invalid by zcashd nodes, creating a consensus split between Zebra and zcashd nodes. In a similar vein, for V4 transactions, Zebra mistakenly used the \"canonical\" hash type when computing the sighash while zcashd (correctly per the spec) uses the raw value, which could also crate a consensus split. This issue has been patched in zebrad version 4.3.1 and zebra-script version 5.0.2."}, {"lang": "es", "value": "ZEBRA es un nodo Zcash escrito completamente en Rust. Antes de la versi\u00f3n 4.3.1 de zebrad y antes de la versi\u00f3n 5.0.2 de zebra-script, despu\u00e9s de una refactorizaci\u00f3n, Zebra no validaba una regla de consenso que restring\u00eda los posibles valores de los tipos de hash sighash para las transacciones V5 que se habilitaron en la actualizaci\u00f3n de red NU5. Los nodos Zebra pod\u00edan as\u00ed aceptar y eventualmente minar un bloque que ser\u00eda considerado inv\u00e1lido por los nodos zcashd, creando una divisi\u00f3n de consenso entre los nodos Zebra y zcashd. De manera similar, para las transacciones V4, Zebra usaba err\u00f3neamente el tipo de hash \u2019can\u00f3nico\u2019 al calcular el sighash, mientras que zcashd (correctamente seg\u00fan la especificaci\u00f3n) usa el valor en bruto, lo que tambi\u00e9n podr\u00eda crear una divisi\u00f3n de consenso. Este problema ha sido parcheado en la versi\u00f3n 4.3.1 de zebrad y la versi\u00f3n 5.0.2 de zebra-script."}], "lastModified": "2026-10-26T18:10:00.173", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:a:zfnd:zebra-script:*:*:*:*:*:rust:*:*", "vulnerable": true, "matchCriteriaId": "C00A15FC-1AB4-4FD0-A10D-214A4AD3A2B0", "versionEndExcluding": "5.0.2"}, {"criteria": "cpe:2.3:a:zfnd:zebrad:*:*:*:*:*:rust:*:*", "vulnerable": true, "matchCriteriaId": "0D5F3C05-ECFC-43B1-9168-8E114125F6B7", "versionEndExcluding": "4.3.1"}], "operator": "OR"}]}], "sourceIdentifier": "security-advisories@github.com"}