Common Weakness Enumeration

CWE-347

Allowed

Improper Verification of Cryptographic Signature

Abstraction: Base · Status: Draft

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

1128 vulnerabilities reference this CWE, most recent first.

GHSA-6VJQ-3XR5-4JH8

Vulnerability from github – Published: 2024-04-09 18:30 – Updated: 2024-04-09 18:30
VLAI
Details

Secure Boot Security Feature Bypass Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-26194"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-09T17:15:37Z",
    "severity": "HIGH"
  },
  "details": "Secure Boot Security Feature Bypass Vulnerability",
  "id": "GHSA-6vjq-3xr5-4jh8",
  "modified": "2024-04-09T18:30:25Z",
  "published": "2024-04-09T18:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26194"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-26194"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6VVH-PXR4-25R7

Vulnerability from github – Published: 2026-06-18 21:08 – Updated: 2026-06-18 21:08
VLAI
Summary
PHP JWT Framework: Chacha20Poly1305 key-encryption algorithm discards the Poly1305 authentication tag, performing no authentication on decryption
Details

Impact

The experimental Chacha20Poly1305 key-encryption algorithm generates the 16-byte Poly1305 authentication tag during encryptKey() but discards it: the tag is never written to the header and therefore never reaches the wire. On the receiving side, decryptKey() calls openssl_decrypt('chacha20-poly1305', ...) without the tag argument, which makes OpenSSL skip authentication entirely.

As a result the AEAD construction is silently degraded to unauthenticated ChaCha20: a tampered encrypted CEK is accepted, and because ChaCha20 is a stream cipher, a single-byte change in the ciphertext propagates as a single-byte change in the recovered CEK with no integrity check (CWE-353 / CWE-347). An attacker on the token path can manipulate the wrapped key without detection.

Affected configurations

Applications that register Jose\Experimental\KeyEncryption\Chacha20Poly1305 (package web-token/jwt-experimental) as a JWE alg.

Patches

encryptKey() now publishes the Poly1305 tag as the base64url tag header parameter (and asserts it is 16 bytes). decryptKey() requires the tag header, validates its length, and passes it to openssl_decrypt() so the tag is actually verified, in line with RFC 7539 / RFC 8439. Tampering now results in a decryption failure.

Note: this changes the wire format of tokens produced with this experimental algorithm (a tag header is now emitted and required).

Workarounds

Do not use the experimental Chacha20Poly1305 key-encryption algorithm for untrusted input until upgraded.

References

  • RFC 7539 / RFC 8439 (ChaCha20-Poly1305 AEAD)
  • CWE-353: Missing Support for Integrity Check

Résolution

Un correctif a été préparé sur une branche dédiée basée sur 3.4.x, avec des tests anti-régression dédiés (fork privé temporaire de cette advisory, PR #1).

ChaCha20-Poly1305 — le tag d'authentification Poly1305 est désormais publié dans le header au chiffrement et vérifié au déchiffrement (RFC 7539), rétablissant l'intégrité AEAD.

Validation : php -l OK, PHPUnit vert, aucune nouvelle erreur PHPStan introduite (différentiel nul vs 3.4.x), aucun commentaire ajouté dans le code source. Après merge, cascade prévue 3.4.x → 4.0.x → 4.1.x.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "web-token/jwt-experimental"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "4.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "web-token/jwt-library"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "web-token/jwt-library"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "web-token/jwt-library"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.1.0"
            },
            {
              "fixed": "4.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-347",
      "CWE-353"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T21:08:15Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nThe experimental `Chacha20Poly1305` key-encryption algorithm generates the 16-byte Poly1305 authentication tag during `encryptKey()` but **discards it**: the tag is never written to the header and therefore never reaches the wire. On the receiving side, `decryptKey()` calls `openssl_decrypt(\u0027chacha20-poly1305\u0027, ...)` **without the tag argument**, which makes OpenSSL skip authentication entirely.\n\nAs a result the AEAD construction is silently degraded to unauthenticated ChaCha20: a tampered encrypted CEK is accepted, and because ChaCha20 is a stream cipher, a single-byte change in the ciphertext propagates as a single-byte change in the recovered CEK with no integrity check (CWE-353 / CWE-347). An attacker on the token path can manipulate the wrapped key without detection.\n\n### Affected configurations\n\nApplications that register `Jose\\Experimental\\KeyEncryption\\Chacha20Poly1305` (package `web-token/jwt-experimental`) as a JWE `alg`.\n\n### Patches\n\n`encryptKey()` now publishes the Poly1305 tag as the base64url `tag` header parameter (and asserts it is 16 bytes). `decryptKey()` requires the `tag` header, validates its length, and passes it to `openssl_decrypt()` so the tag is actually verified, in line with RFC 7539 / RFC 8439. Tampering now results in a decryption failure.\n\n\u003e Note: this changes the wire format of tokens produced with this experimental algorithm (a `tag` header is now emitted and required).\n\n### Workarounds\n\nDo not use the experimental `Chacha20Poly1305` key-encryption algorithm for untrusted input until upgraded.\n\n### References\n\n- RFC 7539 / RFC 8439 (ChaCha20-Poly1305 AEAD)\n- CWE-353: Missing Support for Integrity Check\n\n## R\u00e9solution\n\nUn correctif a \u00e9t\u00e9 pr\u00e9par\u00e9 sur une branche d\u00e9di\u00e9e bas\u00e9e sur `3.4.x`, avec des tests anti-r\u00e9gression d\u00e9di\u00e9s (fork priv\u00e9 temporaire de cette advisory, PR #1).\n\n**ChaCha20-Poly1305** \u2014 le tag d\u0027authentification Poly1305 est d\u00e9sormais publi\u00e9 dans le header au chiffrement et v\u00e9rifi\u00e9 au d\u00e9chiffrement (RFC 7539), r\u00e9tablissant l\u0027int\u00e9grit\u00e9 AEAD.\n\n**Validation :** `php -l` OK, PHPUnit vert, aucune nouvelle erreur PHPStan introduite (diff\u00e9rentiel nul vs `3.4.x`), aucun commentaire ajout\u00e9 dans le code source. Apr\u00e8s merge, cascade pr\u00e9vue `3.4.x \u2192 4.0.x \u2192 4.1.x`.",
  "id": "GHSA-6vvh-pxr4-25r7",
  "modified": "2026-06-18T21:08:15Z",
  "published": "2026-06-18T21:08:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/web-token/jwt-framework/security/advisories/GHSA-6vvh-pxr4-25r7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/web-token/jwt-library/GHSA-6vvh-pxr4-25r7.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/web-token/jwt-framework"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "PHP JWT Framework: Chacha20Poly1305 key-encryption algorithm discards the Poly1305 authentication tag, performing no authentication on decryption"
}

GHSA-6W2F-Q3RQ-JH8V

Vulnerability from github – Published: 2021-12-31 00:00 – Updated: 2022-01-08 00:00
VLAI
Details

Trendnet AC2600 TEW-827DRU version 2.08B01 contains an improper access control configuration that could allow for a malicious firmware update. It is possible to manually install firmware that may be malicious in nature as there does not appear to be any signature validation done to determine if it is from a known and trusted source. This includes firmware updates that are done via the automated "check for updates" in the admin interface. If an attacker is able to masquerade as the update server, the device will not verify that the firmware updates downloaded are legitimate.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-20156"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-30T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Trendnet AC2600 TEW-827DRU version 2.08B01 contains an improper access control configuration that could allow for a malicious firmware update. It is possible to manually install firmware that may be malicious in nature as there does not appear to be any signature validation done to determine if it is from a known and trusted source. This includes firmware updates that are done via the automated \"check for updates\" in the admin interface. If an attacker is able to masquerade as the update server, the device will not verify that the firmware updates downloaded are legitimate.",
  "id": "GHSA-6w2f-q3rq-jh8v",
  "modified": "2022-01-08T00:00:35Z",
  "published": "2021-12-31T00:00:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20156"
    },
    {
      "type": "WEB",
      "url": "https://www.tenable.com/security/research/tra-2021-54"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-6W2P-CGH8-M9Q9

Vulnerability from github – Published: 2023-02-13 21:31 – Updated: 2025-06-19 00:31
VLAI
Details

The cryptographic code signing process and controls on ConnectWise Control through 22.9.10032 (formerly known as ScreenConnect) are cryptographically flawed. An attacker can remotely generate or locally alter file contents and bypass code-signing controls. This can be used to execute code as a trusted application provider, escalate privileges, or execute arbitrary commands in the context of the user. The attacker tampers with a trusted, signed executable in transit.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-25718"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-13T20:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The cryptographic code signing process and controls on ConnectWise Control through 22.9.10032 (formerly known as ScreenConnect) are cryptographically flawed. An attacker can remotely generate or locally alter file contents and bypass code-signing controls. This can be used to execute code as a trusted application provider, escalate privileges, or execute arbitrary commands in the context of the user. The attacker tampers with a trusted, signed executable in transit.",
  "id": "GHSA-6w2p-cgh8-m9q9",
  "modified": "2025-06-19T00:31:02Z",
  "published": "2023-02-13T21:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25718"
    },
    {
      "type": "WEB",
      "url": "https://cybir.com/2022/cve/connectwise-control-dns-spoofing-poc"
    },
    {
      "type": "WEB",
      "url": "https://m.youtube.com/watch?v=fbNVUgmstSc\u0026pp=0gcJCf0Ao7VqN5tD"
    },
    {
      "type": "WEB",
      "url": "https://www.connectwise.com"
    },
    {
      "type": "WEB",
      "url": "https://www.connectwise.com/blog/cybersecurity/the-importance-of-responsible-security-disclosures"
    },
    {
      "type": "WEB",
      "url": "https://www.huntress.com/blog/clearing-the-air-overblown-claims-of-vulnerabilities-exploits-severity"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6W9W-QMVW-3V7Q

Vulnerability from github – Published: 2022-05-13 01:30 – Updated: 2025-12-03 21:30
VLAI
Details

In verify_emsa_pkcs1_signature() in gmp_rsa_public_key.c in the gmp plugin in strongSwan 4.x and 5.x before 5.7.0, the RSA implementation based on GMP does not reject excess data after the encoded algorithm OID during PKCS#1 v1.5 signature verification. Similar to the flaw in the same version of strongSwan regarding digestAlgorithm.parameters, a remote attacker can forge signatures when small public exponents are being used, which could lead to impersonation when only an RSA signature is used for IKEv2 authentication.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-16151"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-09-26T21:29:00Z",
    "severity": "HIGH"
  },
  "details": "In verify_emsa_pkcs1_signature() in gmp_rsa_public_key.c in the gmp plugin in strongSwan 4.x and 5.x before 5.7.0, the RSA implementation based on GMP does not reject excess data after the encoded algorithm OID during PKCS#1 v1.5 signature verification. Similar to the flaw in the same version of strongSwan regarding digestAlgorithm.parameters, a remote attacker can forge signatures when small public exponents are being used, which could lead to impersonation when only an RSA signature is used for IKEv2 authentication.",
  "id": "GHSA-6w9w-qmvw-3v7q",
  "modified": "2025-12-03T21:30:55Z",
  "published": "2022-05-13T01:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16151"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2018/09/msg00032.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201811-16"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3771-1"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2018/dsa-4305"
    },
    {
      "type": "WEB",
      "url": "https://www.strongswan.org/blog/2018/09/24/strongswan-vulnerability-%28cve-2018-16151%2C-cve-2018-16152%29.html"
    },
    {
      "type": "WEB",
      "url": "https://www.strongswan.org/blog/2018/09/24/strongswan-vulnerability-(cve-2018-16151,-cve-2018-16152).html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-11/msg00077.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-12/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-03/msg00047.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"
    }
  ]
}

GHSA-6WWQ-69Q4-FC36

Vulnerability from github – Published: 2026-03-16 15:30 – Updated: 2026-03-16 15:30
VLAI
Details

Philips Hue Bridge hk_hap Ed25519 Signature Verification Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Philips Hue Bridge. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the ed25519_sign_open function. The issue results from improper verification of a cryptographic signature. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-28480.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-3562"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-16T14:19:52Z",
    "severity": "MODERATE"
  },
  "details": "Philips Hue Bridge hk_hap Ed25519 Signature Verification Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Philips Hue Bridge. Authentication is not required to exploit this vulnerability.\n\nThe specific flaw exists within the ed25519_sign_open function. The issue results from improper verification of a cryptographic signature. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-28480.",
  "id": "GHSA-6wwq-69q4-fc36",
  "modified": "2026-03-16T15:30:44Z",
  "published": "2026-03-16T15:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3562"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-26-160"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6X44-W3XG-HQQF

Vulnerability from github – Published: 2026-05-19 20:04 – Updated: 2026-05-19 20:04
VLAI
Summary
Coder: PKCS#7 signature bypass in Azure instance identity allows unauthenticated agent token theft
Details

Summary

azureidentity.Validate() verifies that the PKCS#7 signer certificate chains to a trusted Azure CA but never verifies the PKCS#7 signature itself. An attacker can embed a legitimate Azure certificate alongside arbitrary content e.g. {"vmId":"<target>"} and the forged vmId will be accepted returning the victim workspace agent's session token.

No authentication is required. The attacker only needs to know a target VM's vmId which is a UUIDv4.

that's a practical limitation which would typically require prior access to be exploited

Root Cause

In unpatched Coder releases the signature over the PKCS#7 content is not validated - only the signing certificate is checked.

Impact

An attacker on any Azure VM or with access to a publicly available Azure IMDS certificate from CT logs can:

  1. Steal an agent session token by sending a forged PKCS#7 envelope to POST /api/v2/workspaceagents/azure-instance-identity which is unauthenticated.
  2. With the stolen token access:
  3. Git SSH private key via GET /workspaceagents/me/gitsshkey: push to repositories and impersonate the workspace owner.
  4. OAuth access tokens via GET /workspaceagents/me/external-auth: GitHub, GitLab, and Bitbucket tokens in plaintext.
  5. Workspace secrets via the agent manifest: environment variables, file paths, and API keys.

Attack Path Diagram

PKCS7_diagram (1)

Affected Versions

All versions of Coder v2 are affected.

Patches

Fixed in #25286

The fix was backported to all supported release lines:

Patched Versions
v2.33.3
v2.32.2
v2.31.12
v2.30.8
v2.29.13
v2.24.5

Workarounds

If unable to patch we recommend immediately reconfiguring any Azure templates to use token authentication rather than azure-instance-identity until the patch is released and you are fully upgraded.

  1. Modify the coder_agent.auth value to be token.
  2. Add CODER_AGENT_TOKEN=${coder_agent.main.token} to the set of environment variables for the Coder Workspace Agent initialization script.

Recognition

We'd like to thank Ben Tran of calif.io and Anthropic’s Security Team (ANT-2026-22445) for independently disclosing this issue!

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.33.0-rc.0"
            },
            {
              "fixed": "2.33.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.32.0-rc.0"
            },
            {
              "fixed": "2.32.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.31.0"
            },
            {
              "fixed": "2.31.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.30.0"
            },
            {
              "fixed": "2.30.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.29.0"
            },
            {
              "fixed": "2.29.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.24.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.27.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46354"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-19T20:04:13Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\n`azureidentity.Validate()` verifies that the PKCS#7 signer certificate chains to a trusted Azure CA but never verifies the PKCS#7 signature itself. An attacker can embed a legitimate Azure certificate alongside arbitrary content e.g. `{\"vmId\":\"\u003ctarget\u003e\"}` and the forged `vmId` will be accepted returning the victim workspace agent\u0027s session token.\n\n**No authentication is required.** The attacker only needs to know a target VM\u0027s `vmId` which is a `UUIDv4`.\n\u003e that\u0027s a practical limitation which would typically require prior access to be exploited\n\n## Root Cause\n\nIn unpatched Coder releases the signature over the PKCS#7 content is not validated - only the signing certificate is checked.\n\n## Impact\n\nAn attacker on any Azure VM or with access to a publicly available Azure IMDS certificate from CT logs can:\n\n1. **Steal an agent session token** by sending a forged PKCS#7 envelope to `POST /api/v2/workspaceagents/azure-instance-identity` which is unauthenticated.\n2. **With the stolen token** access:\n   - **Git SSH private key** via `GET /workspaceagents/me/gitsshkey`: push to repositories and impersonate the workspace owner.\n   - **OAuth access tokens** via `GET /workspaceagents/me/external-auth`: GitHub, GitLab, and Bitbucket tokens in plaintext.\n   - **Workspace secrets** via the agent manifest: environment variables, file paths, and API keys.\n\n## Attack Path Diagram\n\n\u003cimg width=\"5588\" height=\"4176\" alt=\"PKCS7_diagram (1)\" src=\"https://github.com/user-attachments/assets/74e88a89-a995-450d-87ab-6feed03579a5\" /\u003e\n\n## Affected Versions\n\nAll versions of Coder v2 are affected.\n\n## Patches\n\nFixed in [#25286 ](https://github.com/coder/coder/pull/25286)\n\nThe fix was backported to all supported release lines:\n\n| Patched Versions |\n| --- |\n| [**v2.33.3**](https://github.com/coder/coder/releases/tag/v2.33.3) |\n| [**v2.32.2**](https://github.com/coder/coder/releases/tag/v2.32.2) |\n| [**v2.31.12**](https://github.com/coder/coder/releases/tag/v2.31.12) |\n| [**v2.30.8**](https://github.com/coder/coder/releases/tag/v2.30.8) |\n| [**v2.29.13**](https://github.com/coder/coder/releases/tag/v2.29.13) |\n| [**v2.24.5**](https://github.com/coder/coder/releases/tag/v2.24.5) |\n\n## Workarounds\n\nIf unable to patch we recommend immediately reconfiguring any Azure templates to use token authentication rather than `azure-instance-identity` until the patch is released and you are fully upgraded.\n\n1. Modify the [`coder_agent.auth`](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent#auth-1) value to be `token`.\n2. Add `CODER_AGENT_TOKEN=${coder_agent.main.token}` to the set of environment variables for the Coder Workspace Agent initialization script.\n\n## Recognition\n\nWe\u0027d like to thank [Ben Tran](https://github.com/bencalif) of [calif.io](http://calif.io) and Anthropic\u2019s Security Team (`ANT-2026-22445`) for independently disclosing this issue!",
  "id": "GHSA-6x44-w3xg-hqqf",
  "modified": "2026-05-19T20:04:13Z",
  "published": "2026-05-19T20:04:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/coder/coder/security/advisories/GHSA-6x44-w3xg-hqqf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/coder/pull/25286"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/coder/coder"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/coder/releases/tag/v2.24.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/coder/releases/tag/v2.29.13"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/coder/releases/tag/v2.30.8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/coder/releases/tag/v2.31.12"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/coder/releases/tag/v2.32.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/coder/releases/tag/v2.33.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Coder: PKCS#7 signature bypass in Azure instance identity allows unauthenticated agent token theft"
}

GHSA-6X7C-M4CM-F7RP

Vulnerability from github – Published: 2023-12-29 03:30 – Updated: 2026-01-27 18:32
VLAI
Details

Some Honor products are affected by signature management vulnerability, successful exploitation could cause the forged system file overwrite the correct system file

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-23436"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-29T02:15:44Z",
    "severity": "HIGH"
  },
  "details": "Some Honor products are affected by signature management vulnerability, successful exploitation could cause the forged system file overwrite the correct system file",
  "id": "GHSA-6x7c-m4cm-f7rp",
  "modified": "2026-01-27T18:32:04Z",
  "published": "2023-12-29T03:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23436"
    },
    {
      "type": "WEB",
      "url": "https://www.hihonor.com/global/security/cve-2023-23436"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-72QV-V5C2-V52F

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

It is possible for an attacker to manipulate documents to appear to be signed by a trusted source. All versions of Apache OpenOffice up to 4.1.10 are affected. Users are advised to update to version 4.1.11. See CVE-2021-25635 for the LibreOffice advisory.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-41832"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-11T08:15:00Z",
    "severity": "HIGH"
  },
  "details": "It is possible for an attacker to manipulate documents to appear to be signed by a trusted source. All versions of Apache OpenOffice up to 4.1.10 are affected. Users are advised to update to version 4.1.11. See CVE-2021-25635 for the LibreOffice advisory.",
  "id": "GHSA-72qv-v5c2-v52f",
  "modified": "2022-05-24T19:17:13Z",
  "published": "2022-05-24T19:17:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41832"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rd3214a568b43dd335b5d558f521377f4bff750684dea18eb041fc1bb%40%3Cusers.openoffice.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rfbc93cd7cea40e2ad3b6e080f688dd02566cdd2b1984fcbb6f8b0fb6@%3Cannounce.apache.org%3E"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-72R8-VMJ4-CFRP

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

IBM Cognos Analytics 11 Configuration tool, under certain circumstances, will bypass OIDC namespace signature verification on its id_token. IBM X-Force ID: 150902.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-1842"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-11-09T01:29:00Z",
    "severity": "LOW"
  },
  "details": "IBM Cognos Analytics 11 Configuration tool, under certain circumstances, will bypass OIDC namespace signature verification on its id_token. IBM X-Force ID: 150902.",
  "id": "GHSA-72r8-vmj4-cfrp",
  "modified": "2022-05-13T01:32:34Z",
  "published": "2022-05-13T01:32:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1842"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/150902"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20190329-0003"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20190401-0003"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/docview.wss?uid=ibm10738249"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1042031"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:H/PR:L/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.