What is the CVSS score of CVE-2026-47085?

CVE-2026-47085 has a CVSS 3.1 base score of 4.0 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N. EPSS exploitation probability: 0.2%.

Is there a patch available for CVE-2026-47085?

Yes, a patch is available for CVE-2026-47085. Update the affected software to the latest version immediately.

Cyrus IMAP CVE-2026-47085

EUVD-2026-45008 MEDIUM

Generation of Predictable Numbers or Identifiers (CWE-340)

2026-07-16 mitre

GHSA-8jrh-wq6h-53c4

Information Disclosure Red Hat Suse Cyrus Imap Cyrusimap

4.0

CVSS 3.1 · Vendor: mitre

Severity by source

Vendor (mitre) PRIMARY

4.0 MEDIUM

AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N

vuln.today AI

4.0 MEDIUM

Network-exploitable via URLAUTH with no attacker authentication needed; AC:H for the per-folder mboxkey-absence prerequisite outside attacker control; S:C reflects cross-account boundary read access.

3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

SUSE

MEDIUM

qualitative

Red Hat

4.0 MEDIUM

qualitative

Primary rating from Vendor (mitre).

CVSS VectorVendor: mitre

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Changed

Confidentiality

Low

Integrity

None

Availability

None

Lifecycle Timeline

Patch available

Jul 16, 2026 - 20:48 EUVD

Analysis Generated

Jul 16, 2026 - 19:02 vuln.today

DescriptionCVE.org

An issue was discovered in cyrus-imapd in Cyrus IMAP through 3.12.2. URLAUTH token forgery can occur via a missing mboxkey. If an attacker knew a folder name on the victim's account for which the victim had never issued an auth URL, they could forge a working URLAUTH token by computing an HMAC-SHA1 value with a predictable key, giving them read access to the mailbox. (URLAUTH is an obscure feature, meaning that the odds of any user actually being susceptible to this attack are very low. Perhaps no public clients use URLAUTH.)

AnalysisAI

URLAUTH token forgery in Cyrus IMAP through 3.12.2 allows a network-based unauthenticated attacker to read the contents of a victim's mailbox folder by computing a forged authentication token using a predictable HMAC-SHA1 key. The predictability arises specifically when a victim has never issued a URLAUTH-authenticated URL for a given folder, leaving the per-folder mboxkey absent and thus falling back to a computable value. No public exploit code has been identified and no active exploitation has been confirmed; real-world impact is further constrained by URLAUTH being an obscure IMAP extension with negligible public client adoption.

Technical ContextAI

Cyrus IMAP implements the URLAUTH extension defined in RFC 4467, which enables IMAP users to issue authenticated URLs granting third-party services access to specific mailbox folders without sharing credentials. Each folder is protected by a per-folder secret called an mboxkey, which serves as the HMAC-SHA1 signing key for URLAUTH tokens. The root cause of this vulnerability is classified as CWE-340 (Generation of Predictable Numbers or Identifiers): when no mboxkey has ever been generated for a folder - because the legitimate user has never issued a URLAUTH token for it - the signing key defaults to a predictable value. An attacker who knows a valid folder name can exploit this by computing a mathematically valid HMAC-SHA1 token independently, presenting it to the server as a forged URLAUTH credential. The affected product is identified by CPE cpe:2.3:a:cyrusimap:cyrus_imap:*:*:*:*:*:*:*:*, encompassing all Cyrus IMAP versions through 3.12.2.

RemediationAI

Upgrade Cyrus IMAP to version 3.12.3 or later, as indicated by the vendor release notes at https://www.cyrusimap.org/3.12/imap/download/release-notes/3.12/x/3.12.3.html. For earlier maintained branches, consult the release notes index at https://www.cyrusimap.org/imap/download/release-notes/index.html to confirm whether a branch-specific patch has been issued, as fix availability for branches prior to 3.12.x is not confirmed from the available intelligence data. As a compensating control where immediate patching is not feasible, disabling or restricting the URLAUTH feature at the server level would eliminate the attack surface entirely, since the vulnerability is contingent on URLAUTH being functional; this trade-off is low-risk in practice because the CVE description notes that virtually no public IMAP clients consume URLAUTH, meaning disabling it is unlikely to break any production functionality. If URLAUTH is in active use by specific integrations, restricting IMAP access to those known client IP addresses via firewall rules would meaningfully reduce exposure while the patch is applied.