CVE-2023-50966: erlang jose PBES2 p2c risk and the 1.11.7 fix

The erlang-jose library (JOSE for Erlang and Elixir) was assigned CVE-2023-50966 after researchers discovered that maliciously large PBES2 iteration counts (the JOSE header field known as p2c) can be abused to cause excessive CPU consumption during JWE decryption—an attacker-controlled denial-of-service vector that affects versions through 1.11.6. Microsoft’s public advisory maps the problem into its product portfolio by explicitly attesting that Azure Linux includes this open-source library and is therefore potentially affected, while promising to update the CVE/VEX mapping if additional Microsoft products are later identified as carriers. (osv.dev)

Background / Overview​

The JOSE family of libraries implements JSON Object Signing and Encryption primitives (JWT/JWE/JWS) across ecosystems. In Erlang and Elixir land, the widely used package is published as jose (erlang-jose). The vulnerability at the heart of CVE-2023-50966 arises during PBES2-based key wrapping: when a JWE uses PBES2 (a password-based key-wrapping scheme), the implementation derives a wrapping key with PBKDF2 using an iteration count taken from the JOSE header p2c parameter. If the implementation fails to bound that iteration count, an attacker can embed an enormous p2c value inside a JWE header and force the decryption routine to perform an enormous number of PBKDF2 rounds—consuming CPU and potentially saturating a host’s processing capacity.
The practical effect is a denial-of-service (low confidentiality/integrity impact but non-trivial availability impact) that can be triggered remotely by supplying crafted JWE content to any service that accepts and decrypts JWE values using an affected version of erlang-jose. NVD and multiple security trackers categorize this as Uncontrolled Resource Consumption (CWE-400) and assign a medium severity profile (CVSS v3.1 base ≈ 5.3).
Upstream remediation for the package was released quickly: the erlang-jose changelog documents release 1.11.7, which implements a maximum p2c limit (10,000 by default) and raises an error if the incoming header’s p2c exceeds that threshold. The changelog and advisory entries make this the canonical fix; security vendors and scanners recommend upgrading to 1.11.7 or later.

---

Technical details: how the PBES2 / p2c abuse works​

What is p2c (PBES2 Count) and why it matters​

PBES2 (Password-Based Encryption Scheme 2) relies on a password-derivation function—typically PBKDF2—to derive symmetric keys usable for wrapping or unwrapping content-encryption keys. PBKDF2’s work factor is the iteration count: higher values increase computation cost for both legitimate users and attackers. When iteration counts are negotiated by the sender (as is allowed by the JOSE JWE header p2c parameter), unbounded acceptance of p2c becomes an attack surface: the decryptor must perform work proportional to p2c without any internal safety cap, so a crafted high p2c value multiplies CPU work.

Where erlang-jose went wrong​

Prior to the patch, erlang-jose passed the p2c-derived iteration count straight into PBKDF2 without strict upper-bounding. The upstream patch adds a function josebes2_count_maximum/0 and an enforced ceiling (default 10,000), so that inflated p2c headers now produce a controlled, predictable error instead of unbounded CPU work. The changelog explicitly documents the security patch.

Exploitability and real-world context​

• Attack complexity: low — the attacker only needs to send a crafted JWE header to a vulnerable decryption endpoint.
• Privileges required: none in many realistic cases (the attacker need only get the service to attempt decryption).
• Likely targets: any service that accepts JWE and performs server-side decryption with an affected erlang-jose library — for example, message brokers, API gateways, internal microservices or any consumer of JWE-protected payloads that uses Erlang/Elixir-based stacks.

Because the impact is CPU exhaustion rather than data compromise, this vulnerability is primarily a service-availability problem. Attackers cannot typically extract keys or plaintext solely via this primitive, but they can degrade or deny service for legitimate users.

---

Ecosystem impact: who patched, where it appears in the wild​

Multiple Linux distributions and security scanners added detections and published advisories or patches following the disclosure. Canonical’s Ubuntu security tracker lists the vulnerability and marks packages as needing evaluation across supported releases; Fedora, Red Hat and other mainstream distributions carried updates for their Erlang and jose packages; vulnerability scanners (Qualys, Nessus, Tenable) integrated checks that flag susceptible packages in images and hosts. For cloud images built and maintained by vendors, those package updates flow into vendor-specific images (for example, the RabbitMQ packaged for a distribution may carry a dependency on an Erlang package that pulls in jose).

• Fix: upgrade jose to 1.11.7 or higher. The upstream changelog documents the fix and the default p2c maximum.
• Package scanners: Nessus/Tenable and other scanners added plugin checks that detect vulnerable rabbitmq-server and jose package versions in Azure Linux and other images as part of their normal signature updates.

---

Microsoft’s statement: Azure Linux and the product-scope attestation​

Microsoft’s Security Response Center (MSRC) entries for CVEs increasingly include a short FAQ answering whether a given Microsoft product includes the implicated open- 6, Microsoft’s public advisory text states that Azure Linux includes this open-source library and is therefore potentially affected, and it highlights Microsoft’s commitment to publish CSAF/VEX attestations (machine-readable product-to-CVE mappings) as part of their transparency efforts. Microsoft adds that if impact to additional products is identified, they will update the CVE to reflect this.
Independent community copies and discussions of MSRC CVE pages repeatedly reproduce that phrasing: Microsoft is making a product-scoped attestation — it has inventory-checked Azure Linux and found the vulnerable component there, and it is disclosing that fact proactively, while leaving open the possibility that other Microsoft artifacts may require additional mapping. Analysts and community responders emphasize that such attestation is confirmatory for the named product only — it does not operate as a categorical exclusion that no other Microsoft product could contain the same vulnerable library.

---

Is Azure Linux the only Microsoft product that includes erlang-jose?​

Short answer: According to Microsoft’s public Cinux is the only Microsoft product Microsoft has publicly attested so far to include the erlang-jose library and therefore be potentially affected**, and MSRC has committed to update that mapping if additional Microsoft products are later identified. That statement is the authoritative Microsoft response at the time the advisory was published.
Longer, cautious answer and practical reading of that statement:

• A Microsoft attestation thats the library” is an explicit inventory result for that product; it is not a technical guarantee that other Microsoft products cannot include the same third-party package. Multiple Microsoft artifacts (marketplace images, container images, platform components that ship Linux-based images, partner images, appliance-style packages) could, in theory, include third-party stacks that use Erlang or that bundle RabbitMQ or other Erlang-based software. Microsoft’s present attestation simply means they have completed inventory verification for Azure Linux and will publish updates for other product families if and when they find additional carriers.
• Operational implication: treat Microsoft’s attestation as the canonical signal for Azure Linux (i.e., act on that immediately if you run Azure Linux images). But do not interpret the absence of attestations for other Microsoft product families as proof they are unaffected—absent attestations are not definitive evidence of absence. Security teams should assume unverified Microsoft artifacts may be affected until either Microsoft publishes a VEX/CSAF mapping for that product or until customers/administrators verify packages inside their own deployed images.

---

Critical analysis: strengths, limits, and remaining risk​

Strengths of Microsoft’s approach​

• **Product-scopedosoft’s move to publish per-product CSAF/VEX attestations provides deterministic, machine-actionable inventory signals that customers can consume and automate against. Publicly attesting that Azure Linux includes the library gives administrators a clear remediation path and reduces ambiguity about where to apply immediate fixes.
• Timely upstream fix and distro updates — erlang-jose maintainers released 1.11.7 to implement a safe p2c ceiling; distro maintainers and scanners incorporated fixes and detections. The existence of a clear upstream mitigation reduces long-term risk for responsible operators who promptly update.

Limits and residual risks​

• Attestation is scoped, not exhaustive. Microsoft’s statement is accurate for Azure Linux but is not an exclusivity guarantee for other Microsoft products. Other Microsoft-distributed images, appliances, or services that embed Linux images or third-party components could theoretically include the same vulnerable library, and they may not yet have been inventory-checked or attested. The absence of public attestations does not constitute a guarantee of absence.
• Downstream bundling / transitive dependencies. Even if Microsoft does not ship a package named jose, other packages (for example, a packaged RabbitMQ or a vendor-supplied container image) might carry a copy of the library or vendor-specific fork. This is a common supply-chain risk: binaries and images often bundle dependencies in ways not visible at the package-name level. Vulnerability scanners that rely purely on package names/versions can miss non-standard bundling.
• Operational detection gaps. Some customers run older, immutable images, or third-party Marketplace images, or appliances where patching is performed by the image maintainer. Unless operators validate inner-image package versions or pull updated images, those workloads may remain exposed despite the upstream fix being available. Microsoft’s attestation helps Azure Linux customers, but tenants that run custom VMs, Marketplace images, or containers must still confirm their images and assume responsibility to patch or rebuild images where necessary.

---

Practical guidance and remediation checklist​

If you are responsible for systems that could be affected, take the following prioritized actions now:

• Identify vulnerable instances
• Inventory all systems, images and containers that might contain Erlang/Elixir stacks, RabbitMQ installations, or other BEAM-based software.
• Run a package and file inventory inside images and VMs (check for jose versions < 1.11.7 and for bundled or vendored jose sources).
• Use updated vulnerability scanner signatures (Qualys, Nessus/Tenable, etc.) that include the CVE detection rules for jose.
• Patch or upgrade
• If you directly depend on jose, upgrade to 1.11.7 or newer immediately. The upstream changelog documents the p2c cap as the fix.
• If rabbitmq-server or other packaged software carries a vulnerable dependency, apply the distro-provided security update for your distribution (Ubuntu, Fedora, Red Hat, SUSE, etc.).
• Contain and mitigate where patching is not yet possible
• Implement network-level protections to rate-limit or filter suspicious JWE payloads where feasible.
• Add application-layer checks to validate and cap p2c values before calling into library routines, if you control the decryptor code path.
• Consider turning ofupport if your operational model does not require it (evaluate compatibility carefully).
• For Azure customers
• If you run Microsoft-published Azure Linux images: apply the Microsoft-supplied security updates as they are released for the Azure Linux channels; Microsoft’s advisory already maps Azure Linux as a product to the library in question.
• Confirm whether any Marketplace or partner images you run contain Erlang-based components; contact maintainers for patch timelines if they do.
• Audit and supply-chain hygiene
• Ingest Microsoft’s CSAF/VEX product attestations once available; these are machine-readable and enable automation of product-to-CVE mapping in enterprise tooling. Microsoft indicated this is part of their transparency rollout.
• Ensure internal CI/CD and image-build pipelines reject or flag vendored dependencies that are out-of-date.

---

How to read Microsoft’s wording as an operator​

Microsoft’s phrasing—“Azure Linux includes this open-source library and is therefore potentially affected… If impact to additional products is identified, we will update the CVE to reflect this”—is concise by design. Read operationally:

• Treat Azure Linux as a confirmed carrier (take action on Azure Linux images immediately).
• Treat all other Microsoft artifacts as unverified rather than guaranteed-safe—perform your own verification, especially if you run marketplace images, custom managed appliances, or containers sourced from third parties. The absence of a Microsoft attestation for a given product is not a proof of absence of the vulnerable component.

---

What defenders should do differently going forward​

This CVE illustrates recurring themes in modern software supply-chain risk:

• Inventory beats assumption. Product- or vendor-provided attestations are valuable, but they are complements to—not replacements for—local inventory and SBOM veris should operate as if any third-party image might include transitive libraries until they can be verified.
• Machine-readable VEX/CSAF matters. Microsoft’s investment in publishing CSAF/VEX mappings makes automation practical: integrate those attestations into your vulnerability management pipelines to remove doubt where Microsoft has completed an inventory check. But continue to treat un-listed product families as “not yet checked.”
• Don’t rely solely on package-manager visibility. Vendors frequently bundle libraries or ship patched binaries that do not align cleanly with package names; ensure scanners can inspect inside images and archives to find vendored dependencies.

---

Conclusion​

CVE-2023-50966 is a clear, fixable denial-of-service vulnerability in the erlang-jose (JOSE for Erlang/Elixir) package caused by an unbounded PBES2 iteration count. Upstream fixed it in jose 1.11.7 by introducing a default p2c ceiling; distributions and scanners have incorporated detections and updates. Microsoft’s public advisory explicitly attests that Azure Linux includes the affected library and is therefore potentially affected, and Microsoft has committed to expand its product mappings should additional Microsoft products be found to include the same component. That attestation should be treated as authoritative for Azure Linux — but it is a scoped inventory statement, not an exclusivity guarantee: administrators must still inventory their own environments, inspect any Marketplace or vendor images they use, and apply the upstream or distro-provided updates to remove the risk.
If you run Azure Linux images, prioritize applying the Microsoft/distro updates now. If you run other Microsoft-distributed artifacts, perform the verification steps above rather than assuming “no attestation = no impact”; treat the absence of a published product mapping as “not yet checked” and proceed accordingly.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center