CVE-2022-3102

MEDIUMCVSS · not yet scored

Also known asGHSA-gwp4-mcv4-w95j (GitHub Security Advisories) · PYSEC-2026-827 (OSV.dev)

—
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • No CVSS published and no exploitation signals yet
CISA-KEV: Not listedEPSS PROB: —CVSS v2: —Exploit: None knownExposed services: Not assessed

A fix is available — apply it.

jwcrypto token substitution can lead to authentication bypass

The JWT code can auto-detect the type of token being provided, and this can lead the application to incorrect conclusions about the trustworthiness of the token. Quoting the private disclosure we received : "Under certain circumstances, it is possible to substitute a [..] signed JWS with a JWE that is encrypted with the public key that is normally used for signature validation." This substitution attack can occur only if the validating application also have access to the private key, normally used to sign the tokens, available during validation of the received JWT. The significance of this attacks depends on the use of the token, it may lead to authentication bypass or authorization bypass (respectively if claims are used to authenticate or authorize certain actions), because the attacker has full control of the data placed in the JWE and can inject any desired claim value.

Several mitigating factors exist that can protect applications from this issue:

  • If the private key corresponding to the public key used to encrypt the JWE is not available to the application an exception will be raised.
  • If the JWK is specified with the 'use' parameter set to 'sig' (as expected for keys used only for signing/verification) an exception will be raised.
  • If the JWK is specified with the 'key_ops' parameter set and it does not include the 'decrypt' operation an exception will be raised.
  • Applications may check the token type before validation, in this case they would fail to detect an expected JWS

Normally, signing and validation are done by different applications, so this scenario should be unlikely. However it is possible to have applications that both sign and validate tokens and do not separate JWKs in use, or do not set a JWK 'use' type.

Due to the mitigating factors, and the fact that specific operational constraints and conditions need to be in place to successfully exploit this issue to generate an authentication bypass, we rate this security issue as moderate. Other avenues may decide on a different rating based on use case, always verify what conditions apply to your use of the library to assess risk.

Many thanks to Tom Tervoort of Secura for finding and reporting this issue.

CVSS
—
EchelonGraph score
Not yet assessedNo source has published severity data for this CVE yet — no CVSS score from NVD or a CNA, no GitHub advisory, and it is not in CISA KEV. This is not a rating of zero; we cannot assess it yet.
EG Score
—
EG Risk
—
EPSS PROB
—
EPSS %ILE
—
KEV
Not listed

What the EG score is made of (scorer v4.0: the three questions the 0–10 score mixes, published apart · methodology)

EG Severity
Not assessed: no CVSS publishedA missing CVSS is not a severity of zero.
EG Likelihood
Unknown (no EPSS on record)Unknown, not low: FIRST has published no EPSS probability for this CVE.
Confirmed exploitation
None on record (CISA KEV, EG-KEV Tier 1)Reported apart from the likelihood: an observed fact, not a probability.
EG Priority
No SSVC decision: EchelonGraph has not assessed this CVECISA BOD 26-04: 14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.Each input and its source, and whom BOD 26-04 binds: the BOD 26-04 block below.

BOD 26-04 (CISA's remediation timeline, Table 1)14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.

The score's inputs: In CISA KEV no (CISA's KEV catalog) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). Where an input reads “CISA's BOD 26-04 default”, no one has published it for this CVE, and CISA's implementation guidance says: “If “Automatable” and “Technical Impact” information items about a CVE ID are not available and the CVE ID is not in the KEV Catalog, CISA will treat its values as “no” and “total,” respectively, until CISA or a third party provides metadata about the CVE ID. CISA will always provide the Vulnrichment data for a CVE ID listed in the KEV Catalog.” Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it

Published

September 21, 2022

Last Modified

September 21, 2022

Vendor Advisories for CVE-2022-3102(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Patch Availability(1)

Vendor / EcosystemFix (by version range) / PatchReleasedSource
pipjwcrypto @ 1.4 (fixes < 1.4)—ghsa

Patches are aggregated from vendor advisories (Red Hat, Microsoft, Cisco, GitHub) and package ecosystems (OSV, GHSA). Multiple rows for the same upstream release have been deduplicated.

Affected Packages

(1 across 1 ecosystem)
PyPI(1)
PackageVulnerable rangeFix by version rangeDependents
jwcrypto0.2.0 ... 1.3.1 (17 versions)
  • every version up to 1.4: fixed in 1.4
—

Data Freshness Timeline

(refreshed 0× in last 7d / 1× in last 30d)

Each row is a time one of our pipelines fetched, updated or re-scored this CVE. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed its CVE.org record (CNA or CISA ADP). An arrow marks a change the record states ("CVSS → 9.1"); EPSS and GHSA rows show the values recorded at that time, not what changed (EPSS values are rounded; hover one for the exact figures). "EchelonGraph re-scored" is our own recompute of this CVE's score, not an update from a source, and is not counted in the refreshes above. Most recent first.

  1. 2026-11-03 19:21 UTCEchelonGraph re-scored
  2. 2026-11-03 19:21 UTCGHSA enrichmentGHSA-gwp4-mcv4-w95j · GitHub severity MODERATE

Related CVEs(same product)

Frequently asked(3)

What is CVE-2022-3102?
CVE-2022-3102 is a medium-severity vulnerability; its CVE record was published on September 21, 2022. jwcrypto token substitution can lead to authentication bypass The JWT code can auto-detect the type of token being provided, and this can lead the application to incorrect conclusions about the trustworthiness of the token. Quoting the private disclosure we received : "Under certain circumstances,…
When was the CVE record for CVE-2022-3102 published?
The CVE record for CVE-2022-3102 was published on September 21, 2022. That is the record's publication date; the vulnerability itself may have been made public earlier. EchelonGraph's copy of the record carries a last-modified date of September 21, 2022; the record at its source may have been updated since.
How do I remediate CVE-2022-3102?
A fix for CVE-2022-3102 is available: update to the fixed version the vendor names in its advisory. The vendor advisories EchelonGraph has for CVE-2022-3102 are linked in the Vendor Advisories panel on this page.

Dependency Blast Radius

See which npm, PyPI, Go, and Maven packages are affected by CVE-2022-3102

Explore →

Is Your Infrastructure Affected by CVE-2022-3102?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.

Book a Demo →Browse All CVEs