CWE-347
AllowedImproper Verification of Cryptographic Signature
Abstraction: Base · Status: Draft
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1278 vulnerabilities reference this CWE, most recent first.
GHSA-HC36-C89J-5F4J
Vulnerability from github – Published: 2026-04-09 20:28 – Updated: 2026-05-13 16:21Unverified certifier signatures persisted by acquire_certificate
Affected packages
Both bsv-sdk and bsv-wallet are published from the sgbett/bsv-ruby-sdk repository. The vulnerable code lives in lib/bsv/wallet_interface/wallet_client.rb, which is physically shipped inside both gems (the bsv-wallet.gemspec files list bundles the entire lib/bsv/wallet_interface/ tree). Consumers of either gem are independently vulnerable; the two packages are versioned separately, so each has its own affected range.
| Package | Affected | Patched |
|---|---|---|
bsv-sdk |
>= 0.3.1, < 0.8.2 |
0.8.2 |
bsv-wallet |
>= 0.1.2, < 0.3.4 |
0.3.4 |
Summary
BSV::Wallet::WalletClient#acquire_certificate persists certificate records to storage without verifying the certifier's signature over the certificate contents. Both acquisition paths are affected:
acquisition_protocol: 'direct'— the caller supplies all certificate fields (includingsignature:) and the record is written to storage verbatim.acquisition_protocol: 'issuance'— the client POSTs to a certifier URL and writes whatever signature the response body contains, also without verification.
An attacker who can reach either API (or who controls a certifier endpoint targeted by the issuance path) can forge identity certificates that subsequently appear authentic to list_certificates and prove_certificate.
Details
BRC-52 requires a certificate's signature field to be verified against the claimed certifier's public key over a canonical hashing of (type, subject, serialNumber, revocationOutpoint, fields) before the certificate is trusted. The reference TypeScript SDK enforces this in Certificate.verify().
Direct path
The Ruby implementation's acquire_via_direct path (lib/bsv/wallet_interface/wallet_client.rb) constructs the certificate record directly from caller-supplied fields:
def acquire_via_direct(args)
{
type: args[:type],
subject: @key_deriver.identity_key,
serial_number: args[:serial_number],
certifier: args[:certifier],
revocation_outpoint: args[:revocation_outpoint],
signature: args[:signature],
fields: args[:fields],
keyring: args[:keyring_for_subject]
}
end
The returned record is then written to the storage adapter by acquire_certificate. No verification of args[:signature] against args[:certifier]'s public key occurs at any point in this path.
Issuance path
acquire_via_issuance POSTs to a certifier-supplied URL and parses the response body into a certificate record, which is then written to storage without verifying the returned signature. A hostile or compromised certifier endpoint — or anyone able to redirect/MITM the plain HTTP request — can therefore return an arbitrary signature value for any subject and have it stored as authentic. This is the same class of bypass as the direct path; it was tracked separately as finding F8.16 in the compliance review and is closed by the same fix.
Downstream impact
Downstream reads via list_certificates and selective-disclosure via prove_certificate treat stored records as valid without re-verifying, so any forgery that slips past acquire_certificate is trusted permanently.
Impact
Any caller that can invoke acquire_certificate — via either acquisition protocol — can forge a certificate attributed to an arbitrary certifier identity key, containing arbitrary fields, and have it persisted as authentic. Applications and downstream gems that rely on the wallet's certificate store as a source of truth for identity attributes (e.g. KYC assertions, role claims, attestations) are subject to credential forgery.
This is a credential-forgery primitive, not merely a spec divergence from BRC-52.
CVSS rationale
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N → 8.1 (High)
- AV:N — network-reachable in any wallet context that exposes
acquire_certificateto callers. - AC:L — low attack complexity: pass arbitrary bytes as
signature:. - PR:L — low privileges: any caller authorised to invoke
acquire_certificate. - UI:N — no user interaction required.
- C:H — forged credentials via
prove_certificatecan assert attributes about the subject. - I:H — the wallet's credential store is polluted with attacker-controlled data.
- A:N — availability unaffected.
Proof of concept
client = BSV::Wallet::WalletClient.new(key, storage: BSV::Wallet::MemoryStore.new)
client.acquire_certificate(
type: 'age-over-18',
acquisition_protocol: 'direct',
certifier: claimed_trusted_pubkey_hex,
serial_number: 'any-serial',
revocation_outpoint: ('00' * 32) + '.0',
signature: 'deadbeef' * 16, # arbitrary bytes — never verified
fields: { 'verified' => 'true' },
keyring_for_subject: {}
)
client.list_certificates(
certifiers: [claimed_trusted_pubkey_hex],
types: ['age-over-18']
)
# => returns the forged record as if it were a real certificate from that certifier
Affected versions
The vulnerable direct-path code was introduced in commit d14dd19 ("feat(wallet): implement BRC-100 identity certificate methods (Phase 5)") on 2026-03-27 20:35 UTC. The vulnerable issuance-path code was added one day later in 6a4d898 ("feat(wallet): implement certificate issuance protocol", 2026-03-28 04:38 UTC), which removed an earlier raise UnsupportedActionError and replaced it with an unverified HTTP POST.
bsv-sdk: the v0.3.1 chore bump (89de3a2) was committed 28 minutes after d14dd19, so the direct-path bypass shipped in the v0.3.1 tag. The v0.3.1 release raised UnsupportedActionError for the issuance path, so the issuance-path bypass first shipped in v0.3.2 (5a335de). Every subsequent release up to and including v0.8.1 is affected by at least one path, and every release from v0.3.2 onwards is affected by both. Combined affected range: >= 0.3.1, < 0.8.2.
bsv-wallet: at the time both commits landed, the wallet gem was at version 0.1.1. The first wallet release containing any of the vulnerable code was v0.1.2 (5a335de, 2026-03-30), which shipped both paths simultaneously. Every subsequent release up to and including v0.3.3 is affected on both paths. Affected range: >= 0.1.2, < 0.3.4.
Patches
Upgrade to bsv-sdk >= 0.8.2 and/or bsv-wallet >= 0.3.4. Both releases ship the same fix: a new module BSV::Wallet::CertificateSignature (lib/bsv/wallet_interface/certificate_signature.rb), which builds the BRC-52 canonical preimage (type, serial_number, subject, certifier, revocation_outpoint, lexicographically-sorted fields) and verifies the certifier's signature against it via ProtoWallet#verify_signature with protocol ID [2, 'certificate signature'] and counterparty = the claimed certifier's public key. Both acquire_via_direct and acquire_via_issuance now call CertificateSignature.verify! before returning the certificate to acquire_certificate, so invalid certificates raise BSV::Wallet::CertificateSignature::InvalidError (a subclass of InvalidSignatureError) and are never written to storage.
Consumers should upgrade whichever gem they depend on directly; they do not need both. bsv-wallet 0.3.4 additionally tightens its dependency on bsv-sdk from the stale ~> 0.4 to >= 0.8.2, < 1.0, which forces the known-good pairing and pulls in the sibling advisory fixes (F1.3, F5.13) tracked separately.
The issuance-path fix also partially closes finding F8.16 from the same compliance review. F8.16's second aspect — switching the issuance transport from ad-hoc JSON POST to BRC-104 AuthFetch — is not addressed here and remains deferred to a future release.
Fixed in sgbett/bsv-ruby-sdk#306.
Workarounds
If upgrading is not immediately possible:
- Do not expose
acquire_certificate(either acquisition protocol) to untrusted callers. - Do not invoke
acquire_certificatewithacquisition_protocol: 'issuance'against a certifier URL you do not fully trust, and require TLS for any such request. - Treat any record returned by
list_certificates/prove_certificateas unverified and perform an out-of-band BRC-52 verification against the certifier's public key before acting on it.
Credit
Identified during the 2026-04-08 cross-SDK compliance review, tracked as findings F8.15 (direct path) and F8.16 (issuance path, partial).
References
- HLR: sgbett/bsv-ruby-sdk#305
- Fix PR: sgbett/bsv-ruby-sdk#306
- Compliance review:
.architecture/reviews/20260408-cross-sdk-compliance-review.md - BRC-52 specification: https://brc.dev/52
- TypeScript reference:
Certificate.verify()in@bsv/sdk
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "bsv-sdk"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.1"
},
{
"fixed": "0.8.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "bsv-wallet"
},
"ranges": [
{
"events": [
{
"introduced": "0.1.2"
},
{
"fixed": "0.3.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40070"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-09T20:28:10Z",
"nvd_published_at": "2026-04-09T18:17:03Z",
"severity": "HIGH"
},
"details": "# Unverified certifier signatures persisted by `acquire_certificate`\n\n## Affected packages\n\nBoth `bsv-sdk` and `bsv-wallet` are published from the [sgbett/bsv-ruby-sdk](https://github.com/sgbett/bsv-ruby-sdk) repository. The vulnerable code lives in `lib/bsv/wallet_interface/wallet_client.rb`, which is **physically shipped inside both gems** (the `bsv-wallet.gemspec` `files` list bundles the entire `lib/bsv/wallet_interface/` tree). Consumers of either gem are independently vulnerable; the two packages are versioned separately, so each has its own affected range.\n\n| Package | Affected | Patched |\n| --- | --- | --- |\n| `bsv-sdk` | `\u003e= 0.3.1, \u003c 0.8.2` | `0.8.2` |\n| `bsv-wallet` | `\u003e= 0.1.2, \u003c 0.3.4` | `0.3.4` |\n\n## Summary\n\n`BSV::Wallet::WalletClient#acquire_certificate` persists certificate records to storage **without verifying the certifier\u0027s signature** over the certificate contents. Both acquisition paths are affected:\n\n- `acquisition_protocol: \u0027direct\u0027` \u2014 the caller supplies all certificate fields (including `signature:`) and the record is written to storage verbatim.\n- `acquisition_protocol: \u0027issuance\u0027` \u2014 the client POSTs to a certifier URL and writes whatever signature the response body contains, also without verification.\n\nAn attacker who can reach either API (or who controls a certifier endpoint targeted by the issuance path) can forge identity certificates that subsequently appear authentic to `list_certificates` and `prove_certificate`.\n\n## Details\n\nBRC-52 requires a certificate\u0027s `signature` field to be verified against the claimed certifier\u0027s public key over a canonical hashing of `(type, subject, serialNumber, revocationOutpoint, fields)` before the certificate is trusted. The reference TypeScript SDK enforces this in `Certificate.verify()`.\n\n### Direct path\n\nThe Ruby implementation\u0027s `acquire_via_direct` path (`lib/bsv/wallet_interface/wallet_client.rb`) constructs the certificate record directly from caller-supplied fields:\n\n```ruby\ndef acquire_via_direct(args)\n {\n type: args[:type],\n subject: @key_deriver.identity_key,\n serial_number: args[:serial_number],\n certifier: args[:certifier],\n revocation_outpoint: args[:revocation_outpoint],\n signature: args[:signature],\n fields: args[:fields],\n keyring: args[:keyring_for_subject]\n }\nend\n```\n\nThe returned record is then written to the storage adapter by `acquire_certificate`. No verification of `args[:signature]` against `args[:certifier]`\u0027s public key occurs at any point in this path.\n\n### Issuance path\n\n`acquire_via_issuance` POSTs to a certifier-supplied URL and parses the response body into a certificate record, which is then written to storage without verifying the returned signature. A hostile or compromised certifier endpoint \u2014 or anyone able to redirect/MITM the plain HTTP request \u2014 can therefore return an arbitrary `signature` value for any subject and have it stored as authentic. This is the same class of bypass as the direct path; it was tracked separately as finding **F8.16** in the compliance review and is closed by the same fix.\n\n### Downstream impact\n\nDownstream reads via `list_certificates` and selective-disclosure via `prove_certificate` treat stored records as valid without re-verifying, so any forgery that slips past `acquire_certificate` is trusted permanently.\n\n## Impact\n\nAny caller that can invoke `acquire_certificate` \u2014 via either acquisition protocol \u2014 can forge a certificate attributed to an arbitrary certifier identity key, containing arbitrary fields, and have it persisted as authentic. Applications and downstream gems that rely on the wallet\u0027s certificate store as a source of truth for identity attributes (e.g. KYC assertions, role claims, attestations) are subject to credential forgery.\n\nThis is a credential-forgery primitive, not merely a spec divergence from BRC-52.\n\n## CVSS rationale\n\n`AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N` \u2192 **8.1 (High)**\n\n- **AV:N** \u2014 network-reachable in any wallet context that exposes `acquire_certificate` to callers.\n- **AC:L** \u2014 low attack complexity: pass arbitrary bytes as `signature:`.\n- **PR:L** \u2014 low privileges: any caller authorised to invoke `acquire_certificate`.\n- **UI:N** \u2014 no user interaction required.\n- **C:H** \u2014 forged credentials via `prove_certificate` can assert attributes about the subject.\n- **I:H** \u2014 the wallet\u0027s credential store is polluted with attacker-controlled data.\n- **A:N** \u2014 availability unaffected.\n\n## Proof of concept\n\n```ruby\nclient = BSV::Wallet::WalletClient.new(key, storage: BSV::Wallet::MemoryStore.new)\n\nclient.acquire_certificate(\n type: \u0027age-over-18\u0027,\n acquisition_protocol: \u0027direct\u0027,\n certifier: claimed_trusted_pubkey_hex,\n serial_number: \u0027any-serial\u0027,\n revocation_outpoint: (\u002700\u0027 * 32) + \u0027.0\u0027,\n signature: \u0027deadbeef\u0027 * 16, # arbitrary bytes \u2014 never verified\n fields: { \u0027verified\u0027 =\u003e \u0027true\u0027 },\n keyring_for_subject: {}\n)\n\nclient.list_certificates(\n certifiers: [claimed_trusted_pubkey_hex],\n types: [\u0027age-over-18\u0027]\n)\n# =\u003e returns the forged record as if it were a real certificate from that certifier\n```\n\n## Affected versions\n\nThe vulnerable direct-path code was introduced in commit `d14dd19` (\"feat(wallet): implement BRC-100 identity certificate methods (Phase 5)\") on 2026-03-27 20:35 UTC. The vulnerable issuance-path code was added one day later in `6a4d898` (\"feat(wallet): implement certificate issuance protocol\", 2026-03-28 04:38 UTC), which removed an earlier `raise UnsupportedActionError` and replaced it with an unverified HTTP POST.\n\n**`bsv-sdk`:** the v0.3.1 chore bump (`89de3a2`) was committed 28 minutes after `d14dd19`, so the direct-path bypass shipped in the **v0.3.1** tag. The v0.3.1 release raised `UnsupportedActionError` for the issuance path, so the issuance-path bypass first shipped in **v0.3.2** (`5a335de`). Every subsequent release up to and including **v0.8.1** is affected by at least one path, and every release from v0.3.2 onwards is affected by both. Combined affected range: `\u003e= 0.3.1, \u003c 0.8.2`.\n\n**`bsv-wallet`:** at the time both commits landed, the wallet gem was at version 0.1.1. The first wallet release containing any of the vulnerable code was **v0.1.2** (`5a335de`, 2026-03-30), which shipped both paths simultaneously. Every subsequent release up to and including **v0.3.3** is affected on both paths. Affected range: `\u003e= 0.1.2, \u003c 0.3.4`.\n\n## Patches\n\nUpgrade to `bsv-sdk \u003e= 0.8.2` **and/or** `bsv-wallet \u003e= 0.3.4`. Both releases ship the same fix: a new module `BSV::Wallet::CertificateSignature` (`lib/bsv/wallet_interface/certificate_signature.rb`), which builds the BRC-52 canonical preimage (`type`, `serial_number`, `subject`, `certifier`, `revocation_outpoint`, lexicographically-sorted `fields`) and verifies the certifier\u0027s signature against it via `ProtoWallet#verify_signature` with protocol ID `[2, \u0027certificate signature\u0027]` and counterparty = the claimed certifier\u0027s public key. Both `acquire_via_direct` and `acquire_via_issuance` now call `CertificateSignature.verify!` before returning the certificate to `acquire_certificate`, so invalid certificates raise `BSV::Wallet::CertificateSignature::InvalidError` (a subclass of `InvalidSignatureError`) and are never written to storage.\n\nConsumers should upgrade whichever gem they depend on directly; they do not need both. `bsv-wallet 0.3.4` additionally tightens its dependency on `bsv-sdk` from the stale `~\u003e 0.4` to `\u003e= 0.8.2, \u003c 1.0`, which forces the known-good pairing and pulls in the sibling advisory fixes (F1.3, F5.13) tracked separately.\n\nThe issuance-path fix also partially closes finding **F8.16** from the same compliance review. F8.16\u0027s second aspect \u2014 switching the issuance transport from ad-hoc JSON POST to BRC-104 AuthFetch \u2014 is not addressed here and remains deferred to a future release.\n\nFixed in sgbett/bsv-ruby-sdk#306.\n\n## Workarounds\n\nIf upgrading is not immediately possible:\n\n- Do not expose `acquire_certificate` (either acquisition protocol) to untrusted callers.\n- Do not invoke `acquire_certificate` with `acquisition_protocol: \u0027issuance\u0027` against a certifier URL you do not fully trust, and require TLS for any such request.\n- Treat any record returned by `list_certificates` / `prove_certificate` as unverified and perform an out-of-band BRC-52 verification against the certifier\u0027s public key before acting on it.\n\n## Credit\n\nIdentified during the 2026-04-08 cross-SDK compliance review, tracked as findings F8.15 (direct path) and F8.16 (issuance path, partial).\n\n## References\n\n- HLR: sgbett/bsv-ruby-sdk#305\n- Fix PR: sgbett/bsv-ruby-sdk#306\n- Compliance review: [`.architecture/reviews/20260408-cross-sdk-compliance-review.md`](../../.architecture/reviews/20260408-cross-sdk-compliance-review.md)\n- BRC-52 specification: https://brc.dev/52\n- TypeScript reference: `Certificate.verify()` in `@bsv/sdk`",
"id": "GHSA-hc36-c89j-5f4j",
"modified": "2026-05-13T16:21:47Z",
"published": "2026-04-09T20:28:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sgbett/bsv-ruby-sdk/security/advisories/GHSA-hc36-c89j-5f4j"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40070"
},
{
"type": "WEB",
"url": "https://github.com/sgbett/bsv-ruby-sdk/issues/305"
},
{
"type": "WEB",
"url": "https://github.com/sgbett/bsv-ruby-sdk/pull/306"
},
{
"type": "WEB",
"url": "https://github.com/sgbett/bsv-ruby-sdk/commit/4992e8a265fd914a7eeb0405c69d1ff0122a84cc"
},
{
"type": "WEB",
"url": "https://brc.dev/52"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/bsv-sdk/CVE-2026-40070.yml"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/bsv-wallet/CVE-2026-40070.yml"
},
{
"type": "PACKAGE",
"url": "https://github.com/sgbett/bsv-ruby-sdk"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "bsv-sdk and bsv-wallet persist unverified certifier signatures in acquire_certificate (direct and issuance paths)"
}
GHSA-HC7F-QWFJ-7FCF
Vulnerability from github – Published: 2026-06-11 09:31 – Updated: 2026-06-11 09:31The UpdraftPlus: WP Backup & Migration Plugin plugin for WordPress is vulnerable to Authentication Bypass in all versions up to, and including, 1.26.4 via the UpdraftPlus_Remote_Communications_V2::wp_loaded function. This is due to insufficient validation of the remote communications message format, where signature verification can be bypassed and unchecked decryption return values collapse to a predictable all-zero encryption key. This makes it possible for unauthenticated attackers to forge arbitrary RPC commands and run them as the connected administrator, such as uploading and activating a malicious plugin, which ultimately leads to remote code execution.
{
"affected": [],
"aliases": [
"CVE-2026-10795"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-11T07:16:26Z",
"severity": "HIGH"
},
"details": "The UpdraftPlus: WP Backup \u0026 Migration Plugin plugin for WordPress is vulnerable to Authentication Bypass in all versions up to, and including, 1.26.4 via the UpdraftPlus_Remote_Communications_V2::wp_loaded function. This is due to insufficient validation of the remote communications message format, where signature verification can be bypassed and unchecked decryption return values collapse to a predictable all-zero encryption key. This makes it possible for unauthenticated attackers to forge arbitrary RPC commands and run them as the connected administrator, such as uploading and activating a malicious plugin, which ultimately leads to remote code execution.",
"id": "GHSA-hc7f-qwfj-7fcf",
"modified": "2026-06-11T09:31:55Z",
"published": "2026-06-11T09:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10795"
},
{
"type": "WEB",
"url": "https://plugins.svn.wordpress.org/updraftplus/tags/1.26.4/vendor/team-updraft/common-libs/src/updraft-rpc/class-udrpc.php"
},
{
"type": "WEB",
"url": "https://plugins.svn.wordpress.org/updraftplus/tags/1.26.4/vendor/team-updraft/common-libs/src/updraft-rpc/class-udrpc2.php"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3561938/updraftplus/trunk/vendor/team-updraft/common-libs/src/updraft-rpc/class-udrpc2.php"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/e901c2a0-2477-4b9a-8483-6002419e0a2f?source=cve"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-HCHW-XWHF-3QVM
Vulnerability from github – Published: 2024-11-12 03:30 – Updated: 2026-06-26 03:31In neomutt and mutt, the To and Cc email headers are not validated by cryptographic signing which allows an attacker that intercepts a message to change their value and include himself as a one of the recipients to compromise message confidentiality.
{
"affected": [],
"aliases": [
"CVE-2024-49393"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-12T02:15:18Z",
"severity": "HIGH"
},
"details": "In neomutt and mutt, the To and Cc email headers are not validated by cryptographic signing which allows an attacker that intercepts a message to change their value and include himself as a one of the recipients to compromise message confidentiality.",
"id": "GHSA-hchw-xwhf-3qvm",
"modified": "2026-06-26T03:31:24Z",
"published": "2024-11-12T03:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49393"
},
{
"type": "WEB",
"url": "https://github.com/neomutt/neomutt/issues/4223"
},
{
"type": "WEB",
"url": "https://github.com/neomutt/neomutt/pull/4221"
},
{
"type": "WEB",
"url": "https://github.com/neomutt/neomutt/pull/4227"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2024-49393"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2325317"
}
],
"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"
}
]
}
GHSA-HCVW-475W-8G7P
Vulnerability from github – Published: 2026-02-09 21:31 – Updated: 2026-02-13 20:32A flaw was found in Keycloak. An attacker can exploit this vulnerability by modifying the organization ID and target email within a legitimate invitation token's JSON Web Token (JWT) payload. This lack of cryptographic signature verification allows the attacker to successfully self-register into an unauthorized organization, leading to unauthorized access.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-services"
},
"ranges": [
{
"events": [
{
"introduced": "26.5.0"
},
{
"fixed": "26.5.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-services"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "26.2.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-services"
},
"ranges": [
{
"events": [
{
"introduced": "26.3.0"
},
{
"fixed": "26.4.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-1529"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-10T18:35:20Z",
"nvd_published_at": "2026-02-09T20:15:55Z",
"severity": "HIGH"
},
"details": "A flaw was found in Keycloak. An attacker can exploit this vulnerability by modifying the organization ID and target email within a legitimate invitation token\u0027s JSON Web Token (JWT) payload. This lack of cryptographic signature verification allows the attacker to successfully self-register into an unauthorized organization, leading to unauthorized access.",
"id": "GHSA-hcvw-475w-8g7p",
"modified": "2026-02-13T20:32:01Z",
"published": "2026-02-09T21:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1529"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/issues/46145"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/pull/46155"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/commit/82cd7941d1dd28fa14a67a6e6b912301f1a5e1a1"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/commit/8fc9a98026106a326f4faa98d4c9a48341ace2d7"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/commit/b2519756487b519f95c07aa8b10afe003e492119"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:2363"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:2364"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:2365"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:2366"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-1529"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2433783"
},
{
"type": "PACKAGE",
"url": "https://github.com/keycloak/keycloak"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Keycloak affected by improper invitation token validation"
}
GHSA-HFCF-V2F8-X9PC
Vulnerability from github – Published: 2026-05-08 17:43 – Updated: 2026-05-15 23:49Summary
ScriptExecution.correctlySpends() contains two fast-path verification bugs for standard P2PKH and native P2WPKH spends in core/src/main/java/org/bitcoinj/script/ScriptExecution.java.
In both branches, bitcoinj verifies an attacker-controlled signature/public-key pair but fails to verify that the public key is the one committed to by the output being spent. As a result, any attacker keypair can satisfy bitcoinj's local verification for arbitrary P2PKH and P2WPKH outputs.
This doesn't affect the SPV (simple payment verification) trust model, as this model follows PoW and doesn't verify input signatures at all.
Details
The issue is in the optimized branches of ScriptExecution.correctlySpends(...).
In the P2PKH fast path at core/src/main/java/org/bitcoinj/script/ScriptExecution.java:1042, the code:
- parses the attacker-supplied signature from
scriptSig - parses the attacker-supplied public key from
scriptSig - computes the sighash against the victim output's
scriptPubKey - checks only
pubkey.verify(sigHash, signature)
It never enforces the missing P2PKH binding:
HASH160(pubkey) == ScriptPattern.extractHashFromP2PKH(scriptPubKey)
That means the OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG semantics are not actually enforced in this fast path.
Relevant code:
} else if (ScriptPattern.isP2PKH(scriptPubKey)) {
if (chunks.size() != 2)
throw new ScriptException(...);
TransactionSignature signature;
try {
byte[] data = Objects.requireNonNull(chunks.get(0).data);
signature = TransactionSignature.decodeFromBitcoin(data, true, true);
} catch (SignatureDecodeException x) {
throw new ScriptException(...);
}
ECKey pubkey = ECKey.fromPublicOnly(Objects.requireNonNull(chunks.get(1).data));
Sha256Hash sigHash = txContainingThis.hashForSignature(scriptSigIndex, scriptPubKey,
signature.sigHashMode(), false);
boolean validSig = pubkey.verify(sigHash, signature);
if (!validSig)
throw new ScriptException(...);
}
In the native P2WPKH fast path at core/src/main/java/org/bitcoinj/script/ScriptExecution.java:1023, the bug is similar. The code:
- reads the attacker-supplied pubkey from
witness - builds
scriptCodefrom that attacker pubkey withScriptBuilder.createP2PKHOutputScript(pubkey) - computes the BIP143 sighash using that attacker-derived
scriptCode - verifies the signature against the attacker pubkey
It never enforces:
HASH160(pubkey) == ScriptPattern.extractHashFromP2WH(scriptPubKey)
So for P2WPKH, the attacker controls both the pubkey and the scriptCode used for signing.
Relevant code:
if (ScriptPattern.isP2WPKH(scriptPubKey)) {
Objects.requireNonNull(witness);
if (witness.getPushCount() < 2)
throw new ScriptException(...);
TransactionSignature signature;
try {
signature = TransactionSignature.decodeFromBitcoin(witness.getPush(0), true, true);
} catch (SignatureDecodeException x) {
throw new ScriptException(...);
}
ECKey pubkey = ECKey.fromPublicOnly(witness.getPush(1));
Script scriptCode = ScriptBuilder.createP2PKHOutputScript(pubkey);
Sha256Hash sigHash = txContainingThis.hashForWitnessSignature(scriptSigIndex, scriptCode, value,
signature.sigHashMode(), false);
boolean validSig = pubkey.verify(sigHash, signature);
if (!validSig)
throw new ScriptException(...);
}
Affected call sites include:
core/src/main/java/org/bitcoinj/core/TransactionInput.java:546core/src/main/java/org/bitcoinj/wallet/Wallet.java:4520core/src/main/java/org/bitcoinj/signers/LocalTransactionSigner.java:84core/src/main/java/org/bitcoinj/signers/CustomTransactionSigner.java:77
These call sites use correctlySpends() for transaction/input validation and pre-signing checks. Any application that treats a successful result from this path as proof that a spend is valid is affected.
Fix
The issue is fixed on the release-0.17 branch via 2bc5653c41d260d840692bc554690d4d79208f9c, and on master via b575a682acf614b9ff95cacbdeb48f86c3ababe0. A 0.17.1 maintenance release has been made available on Maven Central.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.bitcoinj:bitcoinj-core"
},
"ranges": [
{
"events": [
{
"introduced": "0.15"
},
{
"fixed": "0.17.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44714"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T17:43:06Z",
"nvd_published_at": "2026-05-15T17:16:47Z",
"severity": "HIGH"
},
"details": "### Summary\n`ScriptExecution.correctlySpends()` contains two fast-path verification bugs for standard `P2PKH` and native `P2WPKH` spends in `core/src/main/java/org/bitcoinj/script/ScriptExecution.java`.\n\nIn both branches, bitcoinj verifies an attacker-controlled signature/public-key pair but fails to verify that the public key is the one committed to by the output being spent. As a result, any attacker keypair can satisfy bitcoinj\u0027s local verification for arbitrary `P2PKH` and `P2WPKH` outputs.\n\nThis doesn\u0027t affect the SPV (simple payment verification) trust model, as this model follows PoW and doesn\u0027t verify input signatures at all.\n\n### Details\nThe issue is in the optimized branches of `ScriptExecution.correctlySpends(...)`.\n\nIn the `P2PKH` fast path at `core/src/main/java/org/bitcoinj/script/ScriptExecution.java:1042`, the code:\n\n- parses the attacker-supplied signature from `scriptSig`\n- parses the attacker-supplied public key from `scriptSig`\n- computes the sighash against the victim output\u0027s `scriptPubKey`\n- checks only `pubkey.verify(sigHash, signature)`\n\nIt never enforces the missing `P2PKH` binding:\n\n- `HASH160(pubkey) == ScriptPattern.extractHashFromP2PKH(scriptPubKey)`\n\nThat means the `OP_DUP OP_HASH160 \u003chash\u003e OP_EQUALVERIFY OP_CHECKSIG` semantics are not actually enforced in this fast path.\n\nRelevant code:\n\n```java\n} else if (ScriptPattern.isP2PKH(scriptPubKey)) {\n if (chunks.size() != 2)\n throw new ScriptException(...);\n TransactionSignature signature;\n try {\n byte[] data = Objects.requireNonNull(chunks.get(0).data);\n signature = TransactionSignature.decodeFromBitcoin(data, true, true);\n } catch (SignatureDecodeException x) {\n throw new ScriptException(...);\n }\n ECKey pubkey = ECKey.fromPublicOnly(Objects.requireNonNull(chunks.get(1).data));\n Sha256Hash sigHash = txContainingThis.hashForSignature(scriptSigIndex, scriptPubKey,\n signature.sigHashMode(), false);\n boolean validSig = pubkey.verify(sigHash, signature);\n if (!validSig)\n throw new ScriptException(...);\n}\n```\n\nIn the native `P2WPKH` fast path at `core/src/main/java/org/bitcoinj/script/ScriptExecution.java:1023`, the bug is similar. The code:\n\n- reads the attacker-supplied pubkey from `witness`\n- builds `scriptCode` from that attacker pubkey with `ScriptBuilder.createP2PKHOutputScript(pubkey)`\n- computes the BIP143 sighash using that attacker-derived `scriptCode`\n- verifies the signature against the attacker pubkey\n\nIt never enforces:\n\n- `HASH160(pubkey) == ScriptPattern.extractHashFromP2WH(scriptPubKey)`\n\nSo for `P2WPKH`, the attacker controls both the pubkey and the `scriptCode` used for signing.\n\nRelevant code:\n\n```java\nif (ScriptPattern.isP2WPKH(scriptPubKey)) {\n Objects.requireNonNull(witness);\n if (witness.getPushCount() \u003c 2)\n throw new ScriptException(...);\n TransactionSignature signature;\n try {\n signature = TransactionSignature.decodeFromBitcoin(witness.getPush(0), true, true);\n } catch (SignatureDecodeException x) {\n throw new ScriptException(...);\n }\n ECKey pubkey = ECKey.fromPublicOnly(witness.getPush(1));\n Script scriptCode = ScriptBuilder.createP2PKHOutputScript(pubkey);\n Sha256Hash sigHash = txContainingThis.hashForWitnessSignature(scriptSigIndex, scriptCode, value,\n signature.sigHashMode(), false);\n boolean validSig = pubkey.verify(sigHash, signature);\n if (!validSig)\n throw new ScriptException(...);\n}\n```\n\nAffected call sites include:\n\n- `core/src/main/java/org/bitcoinj/core/TransactionInput.java:546`\n- `core/src/main/java/org/bitcoinj/wallet/Wallet.java:4520`\n- `core/src/main/java/org/bitcoinj/signers/LocalTransactionSigner.java:84`\n- `core/src/main/java/org/bitcoinj/signers/CustomTransactionSigner.java:77`\n\nThese call sites use `correctlySpends()` for transaction/input validation and pre-signing checks. Any application that treats a successful result from this path as proof that a spend is valid is affected.\n\n### Fix\nThe issue is fixed on the `release-0.17` branch via 2bc5653c41d260d840692bc554690d4d79208f9c, and on `master` via b575a682acf614b9ff95cacbdeb48f86c3ababe0. A 0.17.1 maintenance release has been made available on Maven Central.",
"id": "GHSA-hfcf-v2f8-x9pc",
"modified": "2026-05-15T23:49:51Z",
"published": "2026-05-08T17:43:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/bitcoinj/bitcoinj/security/advisories/GHSA-hfcf-v2f8-x9pc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44714"
},
{
"type": "WEB",
"url": "https://github.com/bitcoinj/bitcoinj/commit/2bc5653c41d260d840692bc554690d4d79208f9c"
},
{
"type": "WEB",
"url": "https://github.com/bitcoinj/bitcoinj/commit/b575a682acf614b9ff95cacbdeb48f86c3ababe0"
},
{
"type": "PACKAGE",
"url": "https://github.com/bitcoinj/bitcoinj"
},
{
"type": "WEB",
"url": "https://github.com/bitcoinj/bitcoinj/releases/tag/v0.17.1"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "bitcoinj has a ScriptExecution P2PKH/P2WPKH Verification Bypass"
}
GHSA-HFMF-Q43V-2FFJ
Vulnerability from github – Published: 2019-08-23 21:42 – Updated: 2021-08-17 22:08Versions of openpgp prior to 4.2.0 are vulnerable to Improper Key Verification. The OpenPGP standard allows signature packets to have subpackets which may be hashed or unhashed. Unhashed subpackets are not cryptographically protected and cannot be trusted. The openpgp package does not verify whether a subpacket is hashed. Furthermore, due to the order of parsing a signature packet information from unhashed subpackets overwrites information from hashed subpackets. This may allow an attacker to modify the contents of a key certification signature or revocation signature. Doing so could convince a victim to use an obsolete key for encryption. An attack require a victim to import a manipulated key or update an existing key with a manipulated version.
Recommendation
Upgrade to version 4.2.0 or later.
If you are upgrading from a version <4.0.0 it is highly recommended to read the High-Level API Changes section of the openpgp 4.0.0 release: https://github.com/openpgpjs/openpgpjs/releases/tag/v4.0.0
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.2"
},
"package": {
"ecosystem": "npm",
"name": "openpgp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-9154"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2019-08-23T21:41:08Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Versions of `openpgp` prior to 4.2.0 are vulnerable to Improper Key Verification. The OpenPGP standard allows signature packets to have subpackets which may be hashed or unhashed. Unhashed subpackets are not cryptographically protected and cannot be trusted. The `openpgp` package does not verify whether a subpacket is hashed. Furthermore, due to the order of parsing a signature packet information from unhashed subpackets overwrites information from hashed subpackets. This may allow an attacker to modify the contents of a key certification signature or revocation signature. Doing so could convince a victim to use an obsolete key for encryption. An attack require a victim to import a manipulated key or update an existing key with a manipulated version.\n\n\n## Recommendation\n\nUpgrade to version 4.2.0 or later. \nIf you are upgrading from a version \u003c4.0.0 it is highly recommended to read the `High-Level API Changes` section of the `openpgp` 4.0.0 release: https://github.com/openpgpjs/openpgpjs/releases/tag/v4.0.0",
"id": "GHSA-hfmf-q43v-2ffj",
"modified": "2021-08-17T22:08:26Z",
"published": "2019-08-23T21:42:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9154"
},
{
"type": "WEB",
"url": "https://github.com/openpgpjs/openpgpjs/pull/797"
},
{
"type": "WEB",
"url": "https://github.com/openpgpjs/openpgpjs/pull/797/commits/47138eed61473e13ee8f05931119d3e10542c5e1"
},
{
"type": "WEB",
"url": "https://github.com/openpgpjs/openpgpjs/releases/tag/v4.2.0"
},
{
"type": "WEB",
"url": "https://sec-consult.com/en/blog/advisories/multiple-vulnerabilities-in-openpgp-js"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-OPENPGP-460247"
},
{
"type": "WEB",
"url": "https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/Mailvelope_Extensions/Mailvelope_Extensions_pdf.html#download=1"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/advisories/1161"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/154191/OpenPGP.js-4.2.0-Signature-Bypass-Invalid-Curve-Attack.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Improper Key Verification in openpgp"
}
GHSA-HFPC-8R3F-GW53
Vulnerability from github – Published: 2026-03-03 20:25 – Updated: 2026-03-25 18:31Summary
AWS-LC is an open-source, general-purpose cryptographic library.
Impact
Improper signature validation in PKCS7_verify() in AWS-LC allows an unauthenticated user to bypass signature verification when processing PKCS7 objects with Authenticated Attributes.
Customers of AWS services do not need to take action. aws-lc-sys contains code from AWS-LC. Applications using aws-lc-sys should upgrade to the most recent release of aws-lc-sys.
Impacted versions:
aws-lc-sys versions: >= 0.24.0, < 0.38.0
Patches
The patch is included in v0.38.0
Workarounds
There is no workaround. Applications using aws-lc-sys should upgrade to the most recent release of aws-lc-sys.
Resources
If there are any questions or comments about this advisory, contact [AWS/Amazon] Security via the vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "aws-lc-sys"
},
"ranges": [
{
"events": [
{
"introduced": "0.24.0"
},
{
"fixed": "0.38.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-03T20:25:39Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nAWS-LC is an open-source, general-purpose cryptographic library.\n\n### Impact\nImproper signature validation in PKCS7_verify() in AWS-LC allows an unauthenticated user to bypass signature verification when processing PKCS7 objects with Authenticated Attributes.\n\nCustomers of AWS services do not need to take action. aws-lc-sys contains code from AWS-LC. Applications using aws-lc-sys should upgrade to the most recent release of aws-lc-sys.\n\n#### Impacted versions: \naws-lc-sys versions: \u003e= 0.24.0, \u003c 0.38.0\n\n### Patches\nThe patch is included in v0.38.0\n\n### Workarounds\nThere is no workaround. Applications using aws-lc-sys should upgrade to the most recent release of aws-lc-sys.\n\n### Resources\nIf there are any questions or comments about this advisory, contact [AWS/Amazon] Security via the [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.",
"id": "GHSA-hfpc-8r3f-gw53",
"modified": "2026-03-25T18:31:14Z",
"published": "2026-03-03T20:25:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aws/aws-lc-rs/security/advisories/GHSA-hfpc-8r3f-gw53"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-lc/security/advisories/GHSA-jchq-39cv-q4wj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3338"
},
{
"type": "WEB",
"url": "https://aws.amazon.com/security/security-bulletins/2026-005-AWS"
},
{
"type": "PACKAGE",
"url": "https://github.com/aws/aws-lc-rs"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0047.html"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "AWS-LC has PKCS7_verify Signature Validation Bypass"
}
GHSA-HG5R-VQ93-9FV6
Vulnerability from github – Published: 2026-07-21 20:36 – Updated: 2026-07-21 20:36Summary
Gitea Actions Artifacts V4 signed upload/download URLs can be rewritten to access a different running task and repository context while preserving the original HMAC signature. An attacker with permission to run a Gitea Actions job can turn a signed URL for an attacker-controlled artifact into a URL that reads artifacts from another task context, or writes attacker-controlled data into another task's artifact upload staging context, including in a private repository.
This is one vulnerability with two exploit paths:
DownloadArtifact: cross-task/cross-repository artifact read, givingC:H.UploadArtifact: cross-task artifact staging write and metadata mutation, givingI:H.
Details
The root cause is that the V4 artifact signed URL signature is built from raw concatenated fields without delimiters or length-prefixing:
func (r *artifactV4Routes) buildSignature(endpoint, expires, artifactName string, taskID, artifactID int64) []byte {
mac := hmac.New(sha256.New, setting.GetGeneralTokenSigningSecret())
mac.Write([]byte(endpoint))
mac.Write([]byte(expires))
mac.Write([]byte(artifactName))
_, _ = fmt.Fprint(mac, taskID)
_, _ = fmt.Fprint(mac, artifactID)
return mac.Sum(nil)
}
Affected code: routers/api/actions/artifactsv4.go:164-171.
Because artifactName, taskID, and artifactID are concatenated without boundaries, two different URL tuples can produce the same HMAC input. For example:
signed tuple:
artifactName = "artifact-795-153"
taskID = 48
artifactID = <attacker artifact id>
forged tuple:
artifactName = "artifact-795-1"
taskID = 53
artifactID = 48<attacker artifact id>
The final HMAC input suffix is identical:
artifact-795-15348<attacker artifact id>
The attacker does not need to know the target artifact's database artifactID. The forged URL's artifactID only needs to carry digits that preserve the original HMAC input. After verification, the actual target artifact is looked up by target task/run/attempt and artifactName, not by the signed artifactID.
The signed URL handlers are unauthenticated and use ArtifactV4Contexter() only:
m.Group("", func() {
m.Put("UploadArtifact", r.uploadArtifact)
m.Get("DownloadArtifact", r.downloadArtifact)
}, ArtifactV4Contexter())
Affected code: routers/api/actions/artifactsv4.go:156-159.
After verifying the HMAC, verifySignature() trusts the URL-controlled taskID, loads that task, checks that it is running, and returns the URL-controlled artifactName. It parses artifactID for the HMAC, but does not load or bind the artifact by that signed artifact ID:
task, err := actions_model.GetTaskByID(ctx, taskID)
...
if task.Status != actions_model.StatusRunning {
...
}
...
return task, artifactName, true
Affected code: routers/api/actions/artifactsv4.go:224-267.
The artifact lookup then uses the URL-selected task's run/attempt plus URL-selected artifact name:
has, err := db.GetEngine(ctx).Where(builder.Eq{
"run_id": runID,
"run_attempt_id": runAttemptID,
"artifact_name": name,
}, builder.Like{"content_encoding", "%/%"}).Get(&art)
Affected code: routers/api/actions/artifactsv4.go:270-278.
For download, the forged URL reaches downloadArtifact(), which verifies the signature, resolves the artifact by the forged task/run/name context, and serves it:
task, artifactName, ok := r.verifySignature(ctx, "DownloadArtifact")
...
artifact, err := r.getArtifactByName(ctx, task.Job.RunID, task.Job.RunAttemptID, artifactName)
...
err = actions.DownloadArtifactV4ReadStorage(ctx.Base, artifact)
Affected code: routers/api/actions/artifactsv4.go:674-693.
For upload, the forged URL reaches uploadArtifact(), which verifies the signature, resolves the target artifact by the forged task/run/name context, appends attacker-controlled data, and updates target artifact metadata:
task, artifactName, ok := r.verifySignature(ctx, "UploadArtifact")
...
artifact, err := r.getArtifactByName(ctx, task.Job.RunID, task.Job.RunAttemptID, artifactName)
...
uploadedLength, err := appendUploadChunkV3(r.fs, ctx, artifact, artifact.RunID, artifact.FileSize)
...
artifact.FileCompressedSize += uploadedLength
artifact.FileSize += uploadedLength
...
actions_model.UpdateArtifactByID(ctx, artifact.ID, artifact)
Affected code: routers/api/actions/artifactsv4.go:382-422.
The strengthened dynamic PoC also opens the storage object created by the forged upload and verifies that the attacker-controlled bytes were written under the target run and target artifact ID staging path. This demonstrates an unauthorized write primitive into the target artifact upload context. The current PoC does not claim that a finalized artifact download already serves modified bytes; for the integrity path, the confirmed impact is cross-context staging write plus target artifact metadata mutation. In normal artifact upload flow, data in this staging area is what FinalizeArtifact later consumes.
V4 artifact creation also appears to omit the existing artifact-name validation:
artifactName := req.Name
...
artifact, err := actions_model.CreateArtifact(ctx, ctx.ActionTask, artifactName, fileName, retentionDays)
Affected code: routers/api/actions/artifactsv4.go:309-337.
This is a hardening issue, but it is not required for the demonstrated tuple-boundary collision. The crafted artifact names in the PoC use ordinary characters such as letters, digits, and hyphens that would normally be valid. The root cause is the ambiguous signed payload plus the post-verification lookup by URL-selected task/run/name context.
The target task must be running, but that is the normal validity window of these signed URLs. The exploit itself is a deterministic parameter rewrite against the active artifact URL flow, so AC:L is appropriate.
Even if the integrity impact is scored conservatively, the DownloadArtifact path independently demonstrates cross-repository private artifact disclosure.
Practical constraints:
- the target task must be in
runningstate; - the target task ID and artifact name must be known or predictable;
- for
DownloadArtifacton newer branches, the target artifact must already beUploadConfirmedwhile the target task is still running. Older V4 implementations differ slightly in artifact lookup/status handling; the PoC validates the branch-specific condition used by each tested release; - the forged decimal
artifactIDmust parse asint64; - the exact storage effect depends on the configured artifact storage backend. The local PoC uses the default non-Azure storage path. The root cause still exists before storage backend handling because the signed URL context is confused before upload/download dispatch.
- the demonstrated exploit applies when Gitea issues its own V4
UploadArtifact/DownloadArtifactsigned URLs. Storage backends or configurations that return direct backend URLs should be assessed separately, because they may bypass these Gitea signed URL handlers.
PoC
Tested against Gitea main checkout:
6a270662690439cabe8582e92c22b04d1f8a3fe9
Verified affected versions tested locally:
main 6a27066269 reproduced dynamically
v1.26.1 afdbd9b7c5 reproduced dynamically
v1.25.5 f913d90ab6 reproduced dynamically
v1.24.7 99053ce4fa reproduced dynamically
v1.23.8 cccd54999a reproduced dynamically
v1.22.6 8eefa1f6de reproduced dynamically with Go 1.22.12 test toolchain
v1.21.11 V4 artifactsv4.go route not present in routers/api/actions; not affected by this V4 signed URL path as tested
Unless otherwise noted, the affected code snippets and line numbers above refer to the tested main checkout 6a27066269. Older release branches contain the same vulnerable signed URL construction and post-verification context confusion, but line numbers and artifact lookup details differ slightly between releases. For example, newer code includes run_attempt_id in the artifact lookup, while older V4 implementations look up by run/name/path/content-encoding. These differences do not affect the demonstrated HMAC boundary-collision primitive.
For main, v1.26.1, and v1.25.5, the PoC uses the private user2/repo2 fixture and demonstrates cross-repository artifact read. For v1.24.7, v1.23.8, and v1.22.6, the compatible test fixtures differ, so the portable PoC demonstrates the same signed URL rewrite across task/run contexts; v1.22.6 creates the target artifact inside the test because that release does not include the newer artifact fixture file.
The private-repository disclosure impact is demonstrated on releases with suitable private repository fixtures; on older fixtures, the portable test confirms the same cross-context signed URL rewrite primitive, which applies to private targets under the same running-task and known-identifier conditions. The PoC was adapted per release only to account for fixture and test-toolchain differences; the exploit primitive is the same signed URL tuple rewrite.
Local test environment:
- Gitea integration test environment.
- Default local Actions artifact storage, not Azure direct upload.
- Existing fixture tasks/artifacts from Gitea's test fixtures.
- The dynamic PoC sets the target task status to
runningbefore exploiting the URL, matching the vulnerable signed URL requirement.
Run:
cd /home/kali/gitea/pocs
GITEA_REPO=/home/kali/gitea/repo GOTOOLCHAIN=auto go run ./actions_artifact_v4_cross_task_access_dynamic_poc.go
The dynamic PoC writes a temporary integration test into the Gitea checkout, runs only that test, and removes the temporary test afterward.
The test uses:
attacker task: 48
attacker run: 792
attacker job: 193
attacker repository id: 4
target task: 53
target run: 795
target job: 198
target repository: user2/repo2, repository id 2
target artifact: artifact-795-1
crafted attacker artifact: artifact-795-153
PoC flow:
- Create an Actions authorization token for attacker task
48. - Verify the attacker token cannot request a signed URL for target run
795through the authenticated Twirp API. - Create an attacker-controlled V4 artifact named
artifact-795-153. - Upload and finalize that attacker artifact to obtain a legitimate signed URL.
- Rewrite the signed download URL:
artifactName=artifact-795-1
taskID=53
artifactID=48<attackerArtifactID>
- Send the forged final
GETwithout any token and receive the private target artifact fromuser2/repo2. - Rewrite the signed upload URL in the same way.
- Send a forged
PUT ...&comp=appendBlockwith attacker-controlled data. - Confirm the target artifact metadata was changed by the forged upload.
- Open the target run/artifact staging chunk from storage and confirm it contains the attacker-controlled bytes.
Observed output:
source=/home/kali/gitea/repo
ok code.gitea.io/gitea/tests/integration 9.069s
reproduced: attacker task cannot request a target-run signed URL through the authenticated Twirp method
reproduced: attacker-created V4 signed URL keeps its HMAC after taskID/artifactName/artifactID rewrite
reproduced: unauthenticated final GET returns the URL-selected target artifact instead of attacker content
reproduced: forged UploadArtifact URL writes attacker-controlled bytes into target run/artifact staging storage and changes target artifact metadata
condition=attacker can run a Gitea Actions task and target task/artifact identifiers are known while target task is running
cvss_candidate=CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
Example version test commands:
cd /home/kali/gitea/pocs
GITEA_REPO=/home/kali/gitea/version-tests/gitea-v1.26.1 go run ./actions_artifact_v4_cross_task_access_dynamic_poc.go
GITEA_REPO=/home/kali/gitea/version-tests/gitea-v1.25.5 go run ./actions_artifact_v4_cross_task_access_dynamic_poc.go
GITEA_REPO=/home/kali/gitea/version-tests/gitea-v1.24.7 go run ./actions_artifact_v4_cross_task_access_dynamic_poc.go
GITEA_REPO=/home/kali/gitea/version-tests/gitea-v1.23.8 go run ./actions_artifact_v4_cross_task_access_dynamic_poc.go
GITEA_REPO=/home/kali/gitea/version-tests/gitea-v1.22.6 GITEA_TEST_GOTOOLCHAIN=go1.22.12 go run ./actions_artifact_v4_cross_task_access_dynamic_poc.go
Some release worktrees require a local gitea binary before integration tests run:
cd /path/to/gitea-release-worktree
go build -tags 'sqlite sqlite_unlock_notify' -o gitea .
Impact
This is a cross-task and cross-repository authorization bypass in Gitea Actions artifact handling.
An attacker who can run an Actions job can obtain a valid V4 artifact signed URL for their own task, rewrite it without invalidating the HMAC, and make the server operate in another running task's context.
Impacted users are Gitea instances with Actions enabled and V4 artifact signed URL handling in use. Private repositories are impacted because the forged signed URL handlers do not re-check repository access after reconstructing task context from URL parameters.
Confirmed impact:
- Confidentiality: read artifacts from a target running task in a private repository.
- Integrity: write attacker-controlled artifact data into the target run/artifact staging storage and mutate target artifact metadata.
This can expose build outputs, logs or packaged artifacts stored as workflow artifacts, and can interfere with in-flight artifact upload staging. Depending on the target upload/finalization flow, it may poison artifact data consumed by later workflow steps, release automation, deployment jobs, or downstream users.
Recommended fix:
- Sign a canonical structured payload, such as JSON/protobuf or length-prefixed fields, instead of concatenating raw values. A versioned payload is preferable, for example
HMAC(version || canonical_payload). - Include and enforce endpoint, expiry, task ID, artifact ID, artifact name, run ID, run attempt ID, repository ID, and owner ID in the signed payload.
- After signature verification, load the artifact by signed
artifactID. - Reject the request unless the signed artifact ID, task ID, run ID, run attempt ID, repository ID, owner ID, and artifact name all match.
- Apply artifact-name validation to V4 artifact creation as hardening.
Adding separators alone is not a complete fix if the post-verification code still trusts URL fields and looks up the artifact only by name/run context. Artifact-name validation is also hardening rather than a root-cause fix, because normal valid artifact names can contain digits and separators. The important security property is binding the signed URL to one canonical artifact, task, run, repository, owner, endpoint, and expiry.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "code.gitea.io/gitea"
},
"ranges": [
{
"events": [
{
"introduced": "1.22.0"
},
{
"fixed": "1.26.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-58426"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T20:36:38Z",
"nvd_published_at": "2026-07-03T21:17:05Z",
"severity": "CRITICAL"
},
"details": "### Summary\n\nGitea Actions Artifacts V4 signed upload/download URLs can be rewritten to access a different running task and repository context while preserving the original HMAC signature. An attacker with permission to run a Gitea Actions job can turn a signed URL for an attacker-controlled artifact into a URL that reads artifacts from another task context, or writes attacker-controlled data into another task\u0027s artifact upload staging context, including in a private repository.\n\nThis is one vulnerability with two exploit paths:\n\n- `DownloadArtifact`: cross-task/cross-repository artifact read, giving `C:H`.\n- `UploadArtifact`: cross-task artifact staging write and metadata mutation, giving `I:H`.\n\n### Details\n\nThe root cause is that the V4 artifact signed URL signature is built from raw concatenated fields without delimiters or length-prefixing:\n\n```go\nfunc (r *artifactV4Routes) buildSignature(endpoint, expires, artifactName string, taskID, artifactID int64) []byte {\n mac := hmac.New(sha256.New, setting.GetGeneralTokenSigningSecret())\n mac.Write([]byte(endpoint))\n mac.Write([]byte(expires))\n mac.Write([]byte(artifactName))\n _, _ = fmt.Fprint(mac, taskID)\n _, _ = fmt.Fprint(mac, artifactID)\n return mac.Sum(nil)\n}\n```\n\nAffected code: `routers/api/actions/artifactsv4.go:164-171`.\n\nBecause `artifactName`, `taskID`, and `artifactID` are concatenated without boundaries, two different URL tuples can produce the same HMAC input. For example:\n\n```text\nsigned tuple:\nartifactName = \"artifact-795-153\"\ntaskID = 48\nartifactID = \u003cattacker artifact id\u003e\n\nforged tuple:\nartifactName = \"artifact-795-1\"\ntaskID = 53\nartifactID = 48\u003cattacker artifact id\u003e\n```\n\nThe final HMAC input suffix is identical:\n\n```text\nartifact-795-15348\u003cattacker artifact id\u003e\n```\n\nThe attacker does not need to know the target artifact\u0027s database `artifactID`. The forged URL\u0027s `artifactID` only needs to carry digits that preserve the original HMAC input. After verification, the actual target artifact is looked up by target task/run/attempt and `artifactName`, not by the signed `artifactID`.\n\nThe signed URL handlers are unauthenticated and use `ArtifactV4Contexter()` only:\n\n```go\nm.Group(\"\", func() {\n m.Put(\"UploadArtifact\", r.uploadArtifact)\n m.Get(\"DownloadArtifact\", r.downloadArtifact)\n}, ArtifactV4Contexter())\n```\n\nAffected code: `routers/api/actions/artifactsv4.go:156-159`.\n\nAfter verifying the HMAC, `verifySignature()` trusts the URL-controlled `taskID`, loads that task, checks that it is running, and returns the URL-controlled `artifactName`. It parses `artifactID` for the HMAC, but does not load or bind the artifact by that signed artifact ID:\n\n```go\ntask, err := actions_model.GetTaskByID(ctx, taskID)\n...\nif task.Status != actions_model.StatusRunning {\n ...\n}\n...\nreturn task, artifactName, true\n```\n\nAffected code: `routers/api/actions/artifactsv4.go:224-267`.\n\nThe artifact lookup then uses the URL-selected task\u0027s run/attempt plus URL-selected artifact name:\n\n```go\nhas, err := db.GetEngine(ctx).Where(builder.Eq{\n \"run_id\": runID,\n \"run_attempt_id\": runAttemptID,\n \"artifact_name\": name,\n}, builder.Like{\"content_encoding\", \"%/%\"}).Get(\u0026art)\n```\n\nAffected code: `routers/api/actions/artifactsv4.go:270-278`.\n\nFor download, the forged URL reaches `downloadArtifact()`, which verifies the signature, resolves the artifact by the forged task/run/name context, and serves it:\n\n```go\ntask, artifactName, ok := r.verifySignature(ctx, \"DownloadArtifact\")\n...\nartifact, err := r.getArtifactByName(ctx, task.Job.RunID, task.Job.RunAttemptID, artifactName)\n...\nerr = actions.DownloadArtifactV4ReadStorage(ctx.Base, artifact)\n```\n\nAffected code: `routers/api/actions/artifactsv4.go:674-693`.\n\nFor upload, the forged URL reaches `uploadArtifact()`, which verifies the signature, resolves the target artifact by the forged task/run/name context, appends attacker-controlled data, and updates target artifact metadata:\n\n```go\ntask, artifactName, ok := r.verifySignature(ctx, \"UploadArtifact\")\n...\nartifact, err := r.getArtifactByName(ctx, task.Job.RunID, task.Job.RunAttemptID, artifactName)\n...\nuploadedLength, err := appendUploadChunkV3(r.fs, ctx, artifact, artifact.RunID, artifact.FileSize)\n...\nartifact.FileCompressedSize += uploadedLength\nartifact.FileSize += uploadedLength\n...\nactions_model.UpdateArtifactByID(ctx, artifact.ID, artifact)\n```\n\nAffected code: `routers/api/actions/artifactsv4.go:382-422`.\n\nThe strengthened dynamic PoC also opens the storage object created by the forged upload and verifies that the attacker-controlled bytes were written under the target run and target artifact ID staging path. This demonstrates an unauthorized write primitive into the target artifact upload context. The current PoC does not claim that a finalized artifact download already serves modified bytes; for the integrity path, the confirmed impact is cross-context staging write plus target artifact metadata mutation. In normal artifact upload flow, data in this staging area is what `FinalizeArtifact` later consumes.\n\nV4 artifact creation also appears to omit the existing artifact-name validation:\n\n```go\nartifactName := req.Name\n...\nartifact, err := actions_model.CreateArtifact(ctx, ctx.ActionTask, artifactName, fileName, retentionDays)\n```\n\nAffected code: `routers/api/actions/artifactsv4.go:309-337`.\n\nThis is a hardening issue, but it is not required for the demonstrated tuple-boundary collision. The crafted artifact names in the PoC use ordinary characters such as letters, digits, and hyphens that would normally be valid. The root cause is the ambiguous signed payload plus the post-verification lookup by URL-selected task/run/name context.\n\nThe target task must be running, but that is the normal validity window of these signed URLs. The exploit itself is a deterministic parameter rewrite against the active artifact URL flow, so `AC:L` is appropriate.\n\nEven if the integrity impact is scored conservatively, the `DownloadArtifact` path independently demonstrates cross-repository private artifact disclosure.\n\nPractical constraints:\n\n- the target task must be in `running` state;\n- the target task ID and artifact name must be known or predictable;\n- for `DownloadArtifact` on newer branches, the target artifact must already be `UploadConfirmed` while the target task is still running. Older V4 implementations differ slightly in artifact lookup/status handling; the PoC validates the branch-specific condition used by each tested release;\n- the forged decimal `artifactID` must parse as `int64`;\n- the exact storage effect depends on the configured artifact storage backend. The local PoC uses the default non-Azure storage path. The root cause still exists before storage backend handling because the signed URL context is confused before upload/download dispatch.\n- the demonstrated exploit applies when Gitea issues its own V4 `UploadArtifact`/`DownloadArtifact` signed URLs. Storage backends or configurations that return direct backend URLs should be assessed separately, because they may bypass these Gitea signed URL handlers.\n\n### PoC\n\nTested against Gitea `main` checkout:\n\n```text\n6a270662690439cabe8582e92c22b04d1f8a3fe9\n```\n\nVerified affected versions tested locally:\n\n```text\nmain 6a27066269 reproduced dynamically\nv1.26.1 afdbd9b7c5 reproduced dynamically\nv1.25.5 f913d90ab6 reproduced dynamically\nv1.24.7 99053ce4fa reproduced dynamically\nv1.23.8 cccd54999a reproduced dynamically\nv1.22.6 8eefa1f6de reproduced dynamically with Go 1.22.12 test toolchain\nv1.21.11 V4 artifactsv4.go route not present in routers/api/actions; not affected by this V4 signed URL path as tested\n```\n\nUnless otherwise noted, the affected code snippets and line numbers above refer to the tested `main` checkout `6a27066269`. Older release branches contain the same vulnerable signed URL construction and post-verification context confusion, but line numbers and artifact lookup details differ slightly between releases. For example, newer code includes `run_attempt_id` in the artifact lookup, while older V4 implementations look up by run/name/path/content-encoding. These differences do not affect the demonstrated HMAC boundary-collision primitive.\n\nFor `main`, `v1.26.1`, and `v1.25.5`, the PoC uses the private `user2/repo2` fixture and demonstrates cross-repository artifact read. For `v1.24.7`, `v1.23.8`, and `v1.22.6`, the compatible test fixtures differ, so the portable PoC demonstrates the same signed URL rewrite across task/run contexts; `v1.22.6` creates the target artifact inside the test because that release does not include the newer artifact fixture file.\n\nThe private-repository disclosure impact is demonstrated on releases with suitable private repository fixtures; on older fixtures, the portable test confirms the same cross-context signed URL rewrite primitive, which applies to private targets under the same running-task and known-identifier conditions. The PoC was adapted per release only to account for fixture and test-toolchain differences; the exploit primitive is the same signed URL tuple rewrite.\n\nLocal test environment:\n\n- Gitea integration test environment.\n- Default local Actions artifact storage, not Azure direct upload.\n- Existing fixture tasks/artifacts from Gitea\u0027s test fixtures.\n- The dynamic PoC sets the target task status to `running` before exploiting the URL, matching the vulnerable signed URL requirement.\n\nRun:\n\n```bash\ncd /home/kali/gitea/pocs\nGITEA_REPO=/home/kali/gitea/repo GOTOOLCHAIN=auto go run ./actions_artifact_v4_cross_task_access_dynamic_poc.go\n```\n\nThe dynamic PoC writes a temporary integration test into the Gitea checkout, runs only that test, and removes the temporary test afterward.\n\nThe test uses:\n\n```text\nattacker task: 48\nattacker run: 792\nattacker job: 193\nattacker repository id: 4\n\ntarget task: 53\ntarget run: 795\ntarget job: 198\ntarget repository: user2/repo2, repository id 2\ntarget artifact: artifact-795-1\ncrafted attacker artifact: artifact-795-153\n```\n\nPoC flow:\n\n1. Create an Actions authorization token for attacker task `48`.\n2. Verify the attacker token cannot request a signed URL for target run `795` through the authenticated Twirp API.\n3. Create an attacker-controlled V4 artifact named `artifact-795-153`.\n4. Upload and finalize that attacker artifact to obtain a legitimate signed URL.\n5. Rewrite the signed download URL:\n\n```text\nartifactName=artifact-795-1\ntaskID=53\nartifactID=48\u003cattackerArtifactID\u003e\n```\n\n6. Send the forged final `GET` without any token and receive the private target artifact from `user2/repo2`.\n7. Rewrite the signed upload URL in the same way.\n8. Send a forged `PUT ...\u0026comp=appendBlock` with attacker-controlled data.\n9. Confirm the target artifact metadata was changed by the forged upload.\n10. Open the target run/artifact staging chunk from storage and confirm it contains the attacker-controlled bytes.\n\nObserved output:\n\n```text\nsource=/home/kali/gitea/repo\nok code.gitea.io/gitea/tests/integration 9.069s\nreproduced: attacker task cannot request a target-run signed URL through the authenticated Twirp method\nreproduced: attacker-created V4 signed URL keeps its HMAC after taskID/artifactName/artifactID rewrite\nreproduced: unauthenticated final GET returns the URL-selected target artifact instead of attacker content\nreproduced: forged UploadArtifact URL writes attacker-controlled bytes into target run/artifact staging storage and changes target artifact metadata\ncondition=attacker can run a Gitea Actions task and target task/artifact identifiers are known while target task is running\ncvss_candidate=CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N\n```\n\nExample version test commands:\n\n```bash\ncd /home/kali/gitea/pocs\nGITEA_REPO=/home/kali/gitea/version-tests/gitea-v1.26.1 go run ./actions_artifact_v4_cross_task_access_dynamic_poc.go\nGITEA_REPO=/home/kali/gitea/version-tests/gitea-v1.25.5 go run ./actions_artifact_v4_cross_task_access_dynamic_poc.go\nGITEA_REPO=/home/kali/gitea/version-tests/gitea-v1.24.7 go run ./actions_artifact_v4_cross_task_access_dynamic_poc.go\nGITEA_REPO=/home/kali/gitea/version-tests/gitea-v1.23.8 go run ./actions_artifact_v4_cross_task_access_dynamic_poc.go\nGITEA_REPO=/home/kali/gitea/version-tests/gitea-v1.22.6 GITEA_TEST_GOTOOLCHAIN=go1.22.12 go run ./actions_artifact_v4_cross_task_access_dynamic_poc.go\n```\n\nSome release worktrees require a local `gitea` binary before integration tests run:\n\n```bash\ncd /path/to/gitea-release-worktree\ngo build -tags \u0027sqlite sqlite_unlock_notify\u0027 -o gitea .\n```\n\n### Impact\n\nThis is a cross-task and cross-repository authorization bypass in Gitea Actions artifact handling.\n\nAn attacker who can run an Actions job can obtain a valid V4 artifact signed URL for their own task, rewrite it without invalidating the HMAC, and make the server operate in another running task\u0027s context.\n\nImpacted users are Gitea instances with Actions enabled and V4 artifact signed URL handling in use. Private repositories are impacted because the forged signed URL handlers do not re-check repository access after reconstructing task context from URL parameters.\n\nConfirmed impact:\n\n- Confidentiality: read artifacts from a target running task in a private repository.\n- Integrity: write attacker-controlled artifact data into the target run/artifact staging storage and mutate target artifact metadata.\n\nThis can expose build outputs, logs or packaged artifacts stored as workflow artifacts, and can interfere with in-flight artifact upload staging. Depending on the target upload/finalization flow, it may poison artifact data consumed by later workflow steps, release automation, deployment jobs, or downstream users.\n\nRecommended fix:\n\n- Sign a canonical structured payload, such as JSON/protobuf or length-prefixed fields, instead of concatenating raw values. A versioned payload is preferable, for example `HMAC(version || canonical_payload)`.\n- Include and enforce endpoint, expiry, task ID, artifact ID, artifact name, run ID, run attempt ID, repository ID, and owner ID in the signed payload.\n- After signature verification, load the artifact by signed `artifactID`.\n- Reject the request unless the signed artifact ID, task ID, run ID, run attempt ID, repository ID, owner ID, and artifact name all match.\n- Apply artifact-name validation to V4 artifact creation as hardening.\n\nAdding separators alone is not a complete fix if the post-verification code still trusts URL fields and looks up the artifact only by name/run context. Artifact-name validation is also hardening rather than a root-cause fix, because normal valid artifact names can contain digits and separators. The important security property is binding the signed URL to one canonical artifact, task, run, repository, owner, endpoint, and expiry.",
"id": "GHSA-hg5r-vq93-9fv6",
"modified": "2026-07-21T20:36:38Z",
"published": "2026-07-21T20:36:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-hg5r-vq93-9fv6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58426"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/pull/37707"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/commit/1c2d5e9b03f71dd12d450b2af9a79f2557b50226"
},
{
"type": "WEB",
"url": "https://blog.gitea.com/release-of-1.26.2"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-gitea/gitea"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/releases/tag/v1.26.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Gitea Actions Artifacts V4 signed URL HMAC ambiguity allows cross-repository artifact read and cross-task upload-state write"
}
GHSA-HH2H-986F-MGV6
Vulnerability from github – Published: 2026-08-13 12:31 – Updated: 2026-08-13 12:31Zohocorp ManageEngine Password Manager Pro versions before 13232 and PAM360 versions before 8551 are vulnerable to an authentication bypass vulnerability due to improper SAML validation.
{
"affected": [],
"aliases": [
"CVE-2026-12263"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-13T11:17:38Z",
"severity": "HIGH"
},
"details": "Zohocorp ManageEngine Password Manager Pro versions before 13232 and PAM360 versions before 8551 are vulnerable to an authentication bypass vulnerability due to improper SAML validation.",
"id": "GHSA-hh2h-986f-mgv6",
"modified": "2026-08-13T12:31:09Z",
"published": "2026-08-13T12:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12263"
},
{
"type": "WEB",
"url": "https://www.manageengine.com/products/passwordmanagerpro/advisory/cve-2026-12263.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HJGW-9XVW-334R
Vulnerability from github – Published: 2022-05-24 16:49 – Updated: 2024-04-04 01:13Mailvelope prior to 3.3.0 allows private key operations without user interaction via its client-API. By modifying an URL parameter in Mailvelope, an attacker is able to sign (and encrypt) arbitrary messages with Mailvelope, assuming the private key password is cached. A second vulnerability allows an attacker to decrypt an arbitrary message when the GnuPG backend is used in Mailvelope.
{
"affected": [],
"aliases": [
"CVE-2019-9149"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-07-09T21:15:00Z",
"severity": "MODERATE"
},
"details": "Mailvelope prior to 3.3.0 allows private key operations without user interaction via its client-API. By modifying an URL parameter in Mailvelope, an attacker is able to sign (and encrypt) arbitrary messages with Mailvelope, assuming the private key password is cached. A second vulnerability allows an attacker to decrypt an arbitrary message when the GnuPG backend is used in Mailvelope.",
"id": "GHSA-hjgw-9xvw-334r",
"modified": "2024-04-04T01:13:33Z",
"published": "2022-05-24T16:49:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9149"
},
{
"type": "WEB",
"url": "https://github.com/mailvelope/mailvelope/blob/master/Changelog.md#v330"
},
{
"type": "WEB",
"url": "https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/Mailvelope_Extensions/Mailvelope_Extensions_pdf.html"
},
{
"type": "WEB",
"url": "https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/Mailvelope_Extensions/Mailvelope_Extensions_pdf.pdf?__blob=publicationFile\u0026v=3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"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.