VulnerabilityPublished 29 Oct 2026

duplicity · PyJWT: HS256/384/512 verify accepts empty HMAC key via oct JWK (PyJWK/PyJWKClient) enabling token forgery

Affects duplicitySource GCVE Database

Mentioned vulnerabilities

CVSS 7.4 High : upgrade to 3.2.1 soon.

Data as of 30 Oct 2026, 07:30 UTC

CVSS 3.1 base score

7.4High

How severe the flaw is on the 0–10 CVSS scale.

Patch: Available – fixed in 3.2.1

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

Attack Vector: Network
Attack Complexity: High
Privileges Required: None
User Interaction: None
Scope: Unchanged
Confidentiality: High
Integrity: High
Availability: None

Bold values are the worst case: easiest to exploit or largest impact.

Attack Vector: Network: The vulnerable component is bound to the network stack and the set of possible attackers extends beyond the other options listed, up to and including the entire Internet. Such a vulnerability is often termed 'remotely exploitable' and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers).
Attack Complexity: High: A successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected. For example, a successful attack may require an attacker to: gather knowledge about the environment in which the vulnerable target/component exists; prepare the target environment to improve exploit reliability; or inject themselves into the logical network path between the target and the resource requested by the victim in order to read and/or modify network communications (e.g., a man in the middle attack).
Privileges Required: None: The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack.
User Interaction: None: The vulnerable system can be exploited without any interaction from any user.
Scope: Unchanged: An exploited vulnerability can only affect resources managed by the same security authority. In this case, the vulnerable component and the impacted component are either the same, or both are managed by the same security authority.
Confidentiality: High: There is total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact.
Integrity: High: There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component.
Availability: None: There is no impact to availability within the impacted component.

Definitions: FIRST CVSS v3.1 specification.

What to do

Upgrade duplicity to 3.2.1.

Affected software

Product	Affected	Fixed in
Homebrewduplicity`pkg:brew/duplicity`Other threats	Affected >=0.8.19 <3.2.1	Fixed in 3.2.1

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

### Summary `HMACAlgorithm.from_jwk` accepts a symmetric (`kty=oct`) JWK whose `k` value is the empty string and returns a zero-length key without raising. When a token is then verified with that key object (a `PyJWK`, or a `PyJWK` resolved by `PyJWKSet` / `PyJWKClient`), the HMAC verifier computes `HMAC(key=b"", signing_input)` and accepts any token an attacker forged with the same empty key. The attacker needs no secret knowledge: they reproduce the digest locally with an empty key and set the token's `kid` to the empty-`k` JWK. The empty-key rejection that `HMACAlgorithm.prepare_key` performs for string/bytes secrets (added in 2.13.0) was never propagated to the sibling `from_jwk` code path, so the JWK/JWKS verification route stays exploitable. Under default decode options this path only emits an `InsecureKeyLengthWarning`, not an error, so verification still succeeds. This is the same "empty/nil HMAC key is accepted by verify" defect the JWT ecosystem is currently closing library-side: fast-jwt CVE-2026-44351 (CVSS 9.1) and ruby-jwt CVE-2026-45363 both added a library-side reject-empty-HMAC-key precondition. ### Affected versions `PyJWT` (PyPI package `pyjwt`) `<= 2.13.0`, current `master` at commit `7144e4534c34810f4525dc4578a32addd8212cff`. The string/bytes secret path is already guarded in 2.13.0; the JWK/JWKS path is not. ### Privilege required Unauthenticated. Any party who can reach a JWT-verifying endpoint of an application that verifies via a `PyJWK` / `PyJWKSet` / `PyJWKClient` whose oct key has an empty `k` can forge tokens with arbitrary claims. Preconditions: the verifier resolves the HMAC key from a JWK/JWKS whose oct entry carries an empty `k`. This occurs when the signing secret is sourced from an unset environment variable / unset config row / key-finder fallback that base64url-encodes `b""` into the published JWKS, or when the application trusts a JWKS containing such an entry. The equivalent unset-secret case for the string-secret API (`jwt.decode(token, key="")`) is already rejected in 2.13.0; the JWK route is the remaining reachable surface for the same misconfiguration. ### Vulnerable code `jwt/algorithms.py`, `HMACAlgorithm.from_jwk` (line 380): ```python @staticmethod def from_jwk(jwk: str | JWKDict) -> bytes: try: if isinstance(jwk, str): obj: JWKDict = json.loads(jwk) elif isinstance(jwk, dict): obj = jwk else: raise ValueError except ValueError: raise InvalidKeyError("Key is not valid JSON") from None if obj.get("kty") != "oct": raise InvalidKeyError("Not an HMAC key") return base64url_decode(obj["k"]) # <-- empty k -> b"", no rejection ``` Contrast the sibling `prepare_key`, which DID get the guard (lines 325-329): ```python def prepare_key(self, key: str | bytes) -> bytes: key_bytes = force_bytes(key) if len(key_bytes) == 0: raise InvalidKeyError("HMAC key must not be empty.") ``` In `jwt/api_jws.py`, `_verify_signature` (lines 389-416) uses the `PyJWK` key material directly, bypassing `prepare_key`, and the length warning is non-fatal by default: ```python if isinstance(key, PyJWK): if alg != key.algorithm_name: raise InvalidAlgorithmError( f"Token algorithm {alg!r} does not match the key's " f"algorithm {key.algorithm_name!r}" ) alg_obj = key.Algorithm prepared_key = key.key # from_jwk output (b""), prepare_key not run else: try: alg_obj = self.get_algorithm_by_name(alg) except NotImplementedError as e: raise InvalidAlgorithmError("Algorithm not supported") from e prepared_key = alg_obj.prepare_key(key) key_length_msg = alg_obj.check_key_length(prepared_key) if key_length_msg: if effective_options.get("enforce_minimum_key_length", False): raise InvalidKeyError(key_length_msg) else: warnings.warn(key_length_msg, InsecureKeyLengthWarning, stacklevel=4) # default: warn only if not alg_obj.verify(signing_input, prepared_key, signature): # verify with b"" succeeds raise InvalidSignatureError("Signature verification failed") ``` `PyJWK.__init__` sets `self.key = self.Algorithm.from_jwk(self._jwk_data)`, so a `{"kty":"oct","k":""}` JWK yields `PyJWK.key == b""`. `PyJWKSet` and `PyJWKClient.get_signing_key_from_jwt` build `PyJWK` objects the same way, so the JWKS-over-HTTP resolution route is affected identically. The 2.13.0 release note (`CHANGELOG.rst`) documents the `prepare_key` JWK/PEM hardening (GHSA-xgmm-8j9v-c9wx) and the `PyJWK` alg-binding fix (GHSA-jq35-7prp-9v3f), and the test suite has `test_hmac_prepare_key_rejects_empty_key` plus `test_hmac_from_jwk_should_raise_exception_if_empty_json` (which tests an empty JSON object `{}`, not an oct key with e

References

Community reviews

Loading reviews…

What to do

Affected software

Description

Technical details

References

Community reviews

Related threats