Common Weakness Enumeration

CWE-1188

Allowed

Initialization of a Resource with an Insecure Default

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product initializes or sets a resource with a default that is intended to be changed by the product's installer, administrator, or maintainer, but the default is not secure.

477 vulnerabilities reference this CWE, most recent first.

GHSA-WHGH-2R37-M9VR

Vulnerability from github – Published: 2022-05-24 17:09 – Updated: 2023-05-22 21:30
VLAI
Details

A vulnerability in the firmware of the Cisco UCS C-Series Rack Servers could allow an authenticated, physical attacker to bypass Unified Extensible Firmware Interface (UEFI) Secure Boot validation checks and load a compromised software image on an affected device. The vulnerability is due to improper validation of the server firmware upgrade images. An attacker could exploit this vulnerability by installing a server firmware version that would allow the attacker to disable UEFI Secure Boot. A successful exploit could allow the attacker to bypass the signature validation checks that are done by UEFI Secure Boot technology and load a compromised software image on the affected device. A compromised software image is any software image that has not been digitally signed by Cisco.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-1950"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-02-19T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the firmware of the Cisco UCS C-Series Rack Servers could allow an authenticated, physical attacker to bypass Unified Extensible Firmware Interface (UEFI) Secure Boot validation checks and load a compromised software image on an affected device. The vulnerability is due to improper validation of the server firmware upgrade images. An attacker could exploit this vulnerability by installing a server firmware version that would allow the attacker to disable UEFI Secure Boot. A successful exploit could allow the attacker to bypass the signature validation checks that are done by UEFI Secure Boot technology and load a compromised software image on the affected device. A compromised software image is any software image that has not been digitally signed by Cisco.",
  "id": "GHSA-whgh-2r37-m9vr",
  "modified": "2023-05-22T21:30:16Z",
  "published": "2022-05-24T17:09:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1950"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20200219-ucs-boot-bypass"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sd-wan-cred-EVGSF259"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WJV4-G95P-RG69

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

A vulnerability has been identified in RUGGEDCOM ROS for RSL910 devices (All versions < ROS V5.0.1), RUGGEDCOM ROS for all other devices (All versions < ROS V4.3.4), SCALANCE XB-200/XC-200/XP-200/XR300-WG (All versions between V3.0 (including) and V3.0.2 (excluding)), SCALANCE XR-500/XM-400 (All versions between V6.1 (including) and V6.1.1 (excluding)). After initial configuration, the Ruggedcom Discovery Protocol (RCDP) is still able to writeto the device under certain conditions, potentially allowing users located in the adjacentnetwork of the targeted device to perform unauthorized administrative actions.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-12736"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-20",
      "CWE-665"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-12-26T04:29:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in RUGGEDCOM ROS for RSL910 devices (All versions \u003c ROS V5.0.1), RUGGEDCOM ROS for all other devices (All versions \u003c ROS V4.3.4), SCALANCE XB-200/XC-200/XP-200/XR300-WG (All versions between V3.0 (including) and V3.0.2 (excluding)), SCALANCE XR-500/XM-400 (All versions between V6.1 (including) and V6.1.1 (excluding)). After initial configuration, the Ruggedcom Discovery Protocol (RCDP) is still able to writeto the device under certain conditions, potentially allowing users located in the adjacentnetwork of the targeted device to perform unauthorized administrative actions.",
  "id": "GHSA-wjv4-g95p-rg69",
  "modified": "2025-08-12T12:30:31Z",
  "published": "2022-05-13T01:42:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12736"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-856721.html"
    },
    {
      "type": "WEB",
      "url": "https://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-856721.pdf"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/101041"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1039463"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1039464"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WMRH-7WQ5-QC6J

Vulnerability from github – Published: 2026-05-06 21:31 – Updated: 2026-05-06 21:31
VLAI
Details

HCL BigFix Service Management (SM) is susceptible to a Root File System Not Mounted as Read-Only. An improperly configured root file system may allow

unintended modifications to critical system components, potentially increasing the risk of system compromise or unauthorized changes.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-31974"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-06T19:16:35Z",
    "severity": "LOW"
  },
  "details": "HCL BigFix Service Management (SM) is susceptible to a Root File System Not Mounted as Read-Only. An improperly configured root file system may allow\n\nunintended modifications to critical system components, potentially increasing the risk of system compromise or unauthorized changes.",
  "id": "GHSA-wmrh-7wq5-qc6j",
  "modified": "2026-05-06T21:31:36Z",
  "published": "2026-05-06T21:31:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31974"
    },
    {
      "type": "WEB",
      "url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0128144"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WWRJ-3HVJ-PRPM

Vulnerability from github – Published: 2025-12-15 20:59 – Updated: 2026-01-06 22:41
VLAI
Summary
Misskey has a login rate limit bypass via spoofed X-Forwarded-For header
Details

Summary

When using an untrusted reverse proxy or not using a reverse proxy at all, attackers can bypass IP rate limiting by adding a forged X-Forwarded-For header. Starting with version 2025.9.1, an option (trustProxy) has been added in config file to prevent this from happening. However, it is initialized with an insecure default value before version 2025.12.0, making it still vulnerable if the configuration is not set correctly.

Workaround

If you are running Misskey with a trusted reverse proxy, you should not be affected by this vulnerability.

  • There is no workaround for the Misskey itself. Please update Misskey to the latest version or set up a trusted reverse proxy.
  • From v2025.9.1 to v2025.11.1, workaround is available. Set trustProxy: false in config file.
  • This is patched in v2025.12.0 by flipping default value of trustProxy to false. If you are using trusted reverse proxy and not remember you manually overrided this value, please take time to check your config for optimal behavior.

Details

Fastify recommend not trusting X-Forwarded-For IPs Due to misconfiguration in https://github.com/misskey-dev/misskey/blob/develop/packages/backend/src/server/api/SigninApiService.ts#L94 attacks can spoof their IPs.

PoC

POST /api/signin-flow HTTP/1.1
Host: misskey.localhost:3123
Content-Length: 45
Content-Type: application/json
Connection: keep-alive
X-Forwarded-For: 127.1.1.31, 1.1.1.12

{"username":"admin",
    "password":"password"}

image

Impact

An attacker can brute force accounts bypassing rate limiting protection.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "misskey-js"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2025.9.1"
            },
            {
              "fixed": "2025.12.0-alpha.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-66482"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-307"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-15T20:59:59Z",
    "nvd_published_at": "2025-12-16T00:16:02Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nWhen using an untrusted reverse proxy or not using a reverse proxy at all, attackers can bypass IP rate limiting by adding a forged X-Forwarded-For header. Starting with version 2025.9.1, an option (`trustProxy`) has been added in config file to prevent this from happening. However, it is initialized with an insecure default value before version 2025.12.0, making it still vulnerable if the configuration is not set correctly.\n\n### Workaround\n\nIf you are running Misskey with a trusted reverse proxy, you should *not* be affected by this vulnerability.\n\n- There is no workaround for the Misskey itself. Please update Misskey to the latest version or set up a trusted reverse proxy.\n- From v2025.9.1 to v2025.11.1, workaround is available. Set `trustProxy: false` in config file.\n- This is patched in v2025.12.0 by flipping default value of `trustProxy` to `false`. If you are using trusted reverse proxy and not remember you manually overrided this value, please take time to check your config for optimal behavior.\n\n### Details\n[Fastify recommend not trusting X-Forwarded-For IPs](https://fastify.dev/docs/latest/Reference/Server/#trustproxy)\nDue to misconfiguration in https://github.com/misskey-dev/misskey/blob/develop/packages/backend/src/server/api/SigninApiService.ts#L94 attacks can spoof their IPs.\n\n### PoC\n\n```\nPOST /api/signin-flow HTTP/1.1\nHost: misskey.localhost:3123\nContent-Length: 45\nContent-Type: application/json\nConnection: keep-alive\nX-Forwarded-For: 127.1.1.31, 1.1.1.12\n\n{\"username\":\"admin\",\n\t\"password\":\"password\"}\n```\n![image](https://github.com/user-attachments/assets/ce9f77e2-b339-4081-86a6-d44ed42e9ca5)\n\n\n### Impact\nAn attacker can brute force accounts bypassing rate limiting protection.",
  "id": "GHSA-wwrj-3hvj-prpm",
  "modified": "2026-01-06T22:41:27Z",
  "published": "2025-12-15T20:59:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/misskey-dev/misskey/security/advisories/GHSA-wwrj-3hvj-prpm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66482"
    },
    {
      "type": "WEB",
      "url": "https://github.com/misskey-dev/misskey/commit/5512898463fa8487b9e6488912f35102b91f25f7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/misskey-dev/misskey"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Misskey has a login rate limit bypass via spoofed X-Forwarded-For header"
}

GHSA-X2WV-Q3CC-VC36

Vulnerability from github – Published: 2024-10-01 06:30 – Updated: 2024-11-11 09:30
VLAI
Details

Insecure initial password configuration issue in SEIKO EPSON Web Config allows a remote unauthenticated attacker to set an arbitrary password and operate the device with an administrative privilege. As for the details of the affected versions, see the information provided by the vendor under [References].

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-47295"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-01T04:15:18Z",
    "severity": "HIGH"
  },
  "details": "Insecure initial password configuration issue in SEIKO EPSON Web Config allows a remote unauthenticated attacker to set an arbitrary password and operate the device with an administrative privilege. As for the details of the affected versions, see the information provided by the vendor under [References].",
  "id": "GHSA-x2wv-q3cc-vc36",
  "modified": "2024-11-11T09:30:41Z",
  "published": "2024-10-01T06:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47295"
    },
    {
      "type": "WEB",
      "url": "https://epson.com/Support/wa00958"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/vu/JVNVU95133448"
    },
    {
      "type": "WEB",
      "url": "https://www.epson.jp/support/misc_t/240930_03_oshirase.htm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X34F-9F72-PQ82

Vulnerability from github – Published: 2025-09-04 21:31 – Updated: 2025-09-05 18:31
VLAI
Details

In generateRandomPassword of LocalBluetoothLeBroadcast.java, there is a possible way to intercept the Auracast audio stream due to an insecure default value. This could lead to remote (proximal/adjacent) information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-32330"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-04T19:15:36Z",
    "severity": "MODERATE"
  },
  "details": "In generateRandomPassword of LocalBluetoothLeBroadcast.java, there is a possible way to intercept the Auracast audio stream due to an insecure default value. This could lead to remote (proximal/adjacent) information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-x34f-9f72-pq82",
  "modified": "2025-09-05T18:31:19Z",
  "published": "2025-09-04T21:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32330"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/frameworks/base/+/5b10581d2a91ddb256a1e37efcbcdb015091f5a1"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2025-09-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X4GX-CGH5-8GQX

Vulnerability from github – Published: 2026-09-29 21:33 – Updated: 2026-09-29 21:33
VLAI
Details

In Anjvision YSSD‑RTMP‑H5 firmware version 3.3.2.4, several ONVIF service endpoints process management requests without enforcing required authentication. This could allow an unauthorized attacker to access sensitive device operations.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
9.3 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-100291"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-29T20:17:09Z",
    "severity": "CRITICAL"
  },
  "details": "In Anjvision YSSD\u2011RTMP\u2011H5 firmware version 3.3.2.4, several ONVIF service endpoints process management requests without enforcing required authentication. This could allow an unauthorized attacker to access sensitive device operations.",
  "id": "GHSA-x4gx-cgh5-8gqx",
  "modified": "2026-09-29T21:33:22Z",
  "published": "2026-09-29T21:33:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100291"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-272-05"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-XCG6-8PRP-MXMV

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

Insecure default variable initialization for the Intel BSSA DFT feature may allow a privileged user to potentially enable an escalation of privilege via local access.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-0114"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-665"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-16T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Insecure default variable initialization for the Intel BSSA DFT feature may allow a privileged user to potentially enable an escalation of privilege via local access.",
  "id": "GHSA-xcg6-8prp-mxmv",
  "modified": "2022-05-24T19:11:15Z",
  "published": "2022-05-24T19:11:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0114"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20220210-0007"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00525.html"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00527.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XFF3-5C9P-2MR4

Vulnerability from github – Published: 2026-04-24 15:43 – Updated: 2026-05-13 13:37
VLAI
Summary
New API: Stripe Webhook Signature Bypass via Empty Secret Enables Unlimited Quota Fraud
Details

Summary

A critical vulnerability exists in the Stripe webhook handler that allows an unauthenticated attacker to forge webhook events and credit arbitrary quota to their account without making any payment. The vulnerability stems from three compounding flaws:

  1. The Stripe webhook endpoint does not reject requests when StripeWebhookSecret is empty (the default).
  2. When the HMAC secret is empty, any attacker can compute valid webhook signatures, effectively bypassing signature verification entirely.
  3. The Recharge function does not validate that the order's PaymentMethod matches the callback source, enabling cross-gateway exploitation — an order created via any payment method (e.g., Epay) can be fulfilled through a forged Stripe webhook.

Affected Components

  • controller/topup_stripe.go — StripeWebhook(), sessionCompleted()
  • model/topup.go — Recharge(), RechargeCreem(), RechargeWaffo()
  • controller/topup.go — EpayNotify()
  • controller/topup_creem.go — CreemAdaptor.RequestPay() (missing PaymentMethod field)
  • router/api-router.go — webhook route registered without any guard

CWE Classification

  • CWE-345: Insufficient Verification of Data Authenticity
  • CWE-1188: Initialization with an Insecure Default (empty webhook secret)
  • CWE-863: Incorrect Authorization (cross-gateway order fulfillment)

Vulnerability Details

Flaw 1: Empty Webhook Secret Bypasses Signature Verification

The StripeWebhookSecret setting defaults to an empty string "". The Stripe Go SDK (webhook.ConstructEventWithOptions) does not reject empty secrets — it computes HMAC-SHA256 with an empty key, producing a deterministic and publicly computable signature.

Vulnerable code (controller/topup_stripe.go):

func StripeWebhook(c *gin.Context) {
    // No check for empty StripeWebhookSecret
    payload, _ := io.ReadAll(c.Request.Body)
    signature := c.GetHeader("Stripe-Signature")
    endpointSecret := setting.StripeWebhookSecret // defaults to ""
    event, err := webhook.ConstructEventWithOptions(payload, signature, endpointSecret, ...)
    // When secret is "", attacker can compute valid HMAC with the same empty key
}

The webhook route is unconditionally registered with no authentication middleware and no rate limiting:

apiRouter.POST("/stripe/webhook", controller.StripeWebhook)

Flaw 2: Missing payment_status Verification

The sessionCompleted handler only checks status == "complete" but does not verify payment_status == "paid". Stripe's checkout.session.completed event can fire with payment_status = "unpaid" for delayed payment methods (bank transfer, SEPA, Boleto, etc.) or payment_status = "no_payment_required" for 100% discount coupons.

Additionally, checkout.session.async_payment_succeeded and checkout.session.async_payment_failed events are not handled, so delayed payments that ultimately fail are never rolled back.

Flaw 3: Cross-Gateway Order Fulfillment (No PaymentMethod Validation)

The model.Recharge() function (called by the Stripe webhook) looks up orders solely by trade_no and does not validate that the order's PaymentMethod is "stripe":

func Recharge(referenceId string, customerId string) (err error) {
    // Finds ANY pending order by trade_no, regardless of PaymentMethod
    tx.Where("trade_no = ?", referenceId).First(topUp)
    if topUp.Status != "pending" { return }
    // Credits quota without checking topUp.PaymentMethod
    quota = topUp.Money * QuotaPerUnit
    tx.Model(&User{}).Update("quota", gorm.Expr("quota + ?", quota))
}

This allows an attacker to create orders through any configured payment gateway (Epay, Creem, Waffo) and then complete them via a forged Stripe webhook — even if Stripe itself was never configured.

Attack Scenario

Prerequisites: Any payment method is configured (e.g., Epay) + StripeWebhookSecret is empty (default).

  1. Attacker registers a user account.
  2. Attacker calls POST /api/user/pay to create an Epay top-up order (e.g., amount=10000). The order is stored with status=pending.
  3. Attacker queries GET /api/user/topup/self to retrieve the trade_no of the pending order.
  4. Attacker computes HMAC-SHA256 with an empty key over a crafted checkout.session.completed payload containing the stolen trade_no as client_reference_id.
  5. Attacker sends POST /api/stripe/webhook with the forged payload and signature header.
  6. The server verifies the signature (passes because the secret is empty), calls Recharge(), which finds the Epay order by trade_no, marks it as success, and credits the full quota.
  7. Attacker repeats steps 2–6 indefinitely for unlimited credits.

Proof of concept (pseudocode):

import hmac, hashlib, time, json, requests

timestamp = int(time.time())
payload = json.dumps({
    "type": "checkout.session.completed",
    "data": {
        "object": {
            "client_reference_id": "<trade_no from step 3>",
            "status": "complete",
            "payment_status": "paid",
            "customer": "cus_fake",
            "amount_total": "0",
            "currency": "usd"
        }
    }
})
# Empty secret = publicly computable signature
sig = hmac.new(b"", f"{timestamp}.{payload}".encode(), hashlib.sha256).hexdigest()
header = f"t={timestamp},v1={sig}"

requests.post("https://target/api/stripe/webhook",
    data=payload,
    headers={"Stripe-Signature": header, "Content-Type": "application/json"})

Remediation

Fix 1: Reject webhooks when secret is empty

func StripeWebhook(c *gin.Context) {
    if setting.StripeWebhookSecret == "" {
        c.AbortWithStatus(http.StatusForbidden)
        return
    }
    // ... existing logic
}

Fix 2: Verify payment_status and handle async payment events

func sessionCompleted(event stripe.Event) {
    // ... existing status check ...
    paymentStatus := event.GetObjectValue("payment_status")
    if paymentStatus != "paid" {
        return // Wait for async_payment_succeeded event
    }
    fulfillOrder(event, referenceId, customerId)
}

Add handlers for checkout.session.async_payment_succeeded and checkout.session.async_payment_failed.

Fix 3: Validate PaymentMethod in all recharge functions

// In model.Recharge (Stripe):
if topUp.PaymentMethod != "stripe" {
    return ErrPaymentMethodMismatch
}

// In model.RechargeCreem:
if topUp.PaymentMethod != "creem" {
    return ErrPaymentMethodMismatch
}

// In model.RechargeWaffo:
if topUp.PaymentMethod != "waffo" {
    return ErrPaymentMethodMismatch
}

// In controller.EpayNotify:
if topUp.PaymentMethod == "stripe" || topUp.PaymentMethod == "creem" || topUp.PaymentMethod == "waffo" {
    return // reject cross-gateway fulfillment
}

Additional fix: Set PaymentMethod on Creem order creation

The Creem order creation was missing the PaymentMethod field entirely:

topUp := &model.TopUp{
    // ...
    PaymentMethod: "creem", // was missing
}

Patched Versions

  • v0.12.10 — includes all three fixes described above.

All users are strongly encouraged to upgrade immediately.

Workaround (for users unable to upgrade immediately)

If users cannot upgrade to v0.12.10 right away, apply all of the following mitigations:

  1. Set StripeWebhookSecret to any non-empty value. Go to the admin panel → Payment → Stripe, and set the Webhook Signing Secret to any random string (e.g., whsec_placeholder_do_not_leave_empty). It does not need to be a real Stripe secret — any non-empty value will prevent the empty-key HMAC forgery. This is the single most important step — it closes the primary attack vector. If Stripe payments are used in production, replace with the real secret from the project's Stripe Dashboard → Webhooks to ensure legitimate webhooks continue to work.

  2. If Stripe is not in use, block the webhook endpoint. If users have not configured Stripe payments, use a reverse proxy (Nginx, Caddy, etc.) to deny access to /api/stripe/webhook: nginx location = /api/stripe/webhook { return 403; }

Note: The workaround only mitigates Flaw 1 (empty secret bypass). Flaws 2 (missing payment_status check) and 3 (cross-gateway fulfillment) are only fully addressed in v0.12.10. Upgrading is the only complete fix.

Impact

  • Financial fraud: Attacker obtains unlimited API quota without payment.
  • Operator financial loss: Fraudulent quota is consumed against upstream AI providers (OpenAI, Anthropic, Google, etc.), charged to the operator.
  • Silent exploitation: Fraudulent top-ups appear as normal successful transactions in system logs, making detection difficult.
  • Wide exposure: The default insecure configuration means virtually all deployments with any payment method enabled are vulnerable.

Timeline

  • 2025-04-15: Vulnerability reported by @ChangeYu0229
  • 2025-04-15: Vulnerability confirmed and root cause analysis completed
  • 2025-04-15: Fix developed and applied
  • 2025-04-15: Patched in v0.12.10

Resources

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/QuantumNous/new-api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.12.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41432"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-345",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-24T15:43:25Z",
    "nvd_published_at": "2026-05-08T23:16:35Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nA critical vulnerability exists in the Stripe webhook handler that allows an **unauthenticated attacker to forge webhook events** and credit arbitrary quota to their account without making any payment. The vulnerability stems from three compounding flaws:\n\n1. The Stripe webhook endpoint does not reject requests when `StripeWebhookSecret` is empty (the default).\n2. When the HMAC secret is empty, any attacker can compute valid webhook signatures, effectively **bypassing signature verification entirely**.\n3. The `Recharge` function does not validate that the order\u0027s `PaymentMethod` matches the callback source, enabling **cross-gateway exploitation** \u2014 an order created via any payment method (e.g., Epay) can be fulfilled through a forged Stripe webhook.\n\n## Affected Components\n\n- `controller/topup_stripe.go` \u2014 `StripeWebhook()`, `sessionCompleted()`\n- `model/topup.go` \u2014 `Recharge()`, `RechargeCreem()`, `RechargeWaffo()`\n- `controller/topup.go` \u2014 `EpayNotify()`\n- `controller/topup_creem.go` \u2014 `CreemAdaptor.RequestPay()` (missing `PaymentMethod` field)\n- `router/api-router.go` \u2014 webhook route registered without any guard\n\n## CWE Classification\n\n- **CWE-345**: Insufficient Verification of Data Authenticity\n- **CWE-1188**: Initialization with an Insecure Default (empty webhook secret)\n- **CWE-863**: Incorrect Authorization (cross-gateway order fulfillment)\n\n## Vulnerability Details\n\n### Flaw 1: Empty Webhook Secret Bypasses Signature Verification\n\nThe `StripeWebhookSecret` setting defaults to an empty string `\"\"`. The Stripe Go SDK (`webhook.ConstructEventWithOptions`) does **not** reject empty secrets \u2014 it computes `HMAC-SHA256` with an empty key, producing a deterministic and publicly computable signature.\n\n**Vulnerable code** (`controller/topup_stripe.go`):\n```go\nfunc StripeWebhook(c *gin.Context) {\n    // No check for empty StripeWebhookSecret\n    payload, _ := io.ReadAll(c.Request.Body)\n    signature := c.GetHeader(\"Stripe-Signature\")\n    endpointSecret := setting.StripeWebhookSecret // defaults to \"\"\n    event, err := webhook.ConstructEventWithOptions(payload, signature, endpointSecret, ...)\n    // When secret is \"\", attacker can compute valid HMAC with the same empty key\n}\n```\n\nThe webhook route is unconditionally registered with **no authentication middleware and no rate limiting**:\n```go\napiRouter.POST(\"/stripe/webhook\", controller.StripeWebhook)\n```\n\n### Flaw 2: Missing `payment_status` Verification\n\nThe `sessionCompleted` handler only checks `status == \"complete\"` but does **not** verify `payment_status == \"paid\"`. Stripe\u0027s `checkout.session.completed` event can fire with `payment_status = \"unpaid\"` for delayed payment methods (bank transfer, SEPA, Boleto, etc.) or `payment_status = \"no_payment_required\"` for 100% discount coupons.\n\nAdditionally, `checkout.session.async_payment_succeeded` and `checkout.session.async_payment_failed` events are not handled, so delayed payments that ultimately fail are never rolled back.\n\n### Flaw 3: Cross-Gateway Order Fulfillment (No PaymentMethod Validation)\n\nThe `model.Recharge()` function (called by the Stripe webhook) looks up orders solely by `trade_no` and does **not** validate that the order\u0027s `PaymentMethod` is `\"stripe\"`:\n\n```go\nfunc Recharge(referenceId string, customerId string) (err error) {\n    // Finds ANY pending order by trade_no, regardless of PaymentMethod\n    tx.Where(\"trade_no = ?\", referenceId).First(topUp)\n    if topUp.Status != \"pending\" { return }\n    // Credits quota without checking topUp.PaymentMethod\n    quota = topUp.Money * QuotaPerUnit\n    tx.Model(\u0026User{}).Update(\"quota\", gorm.Expr(\"quota + ?\", quota))\n}\n```\n\nThis allows an attacker to create orders through **any** configured payment gateway (Epay, Creem, Waffo) and then complete them via a forged Stripe webhook \u2014 even if Stripe itself was never configured.\n\n## Attack Scenario\n\n**Prerequisites**: Any payment method is configured (e.g., Epay) + `StripeWebhookSecret` is empty (default).\n\n1. Attacker registers a user account.\n2. Attacker calls `POST /api/user/pay` to create an Epay top-up order (e.g., `amount=10000`). The order is stored with `status=pending`.\n3. Attacker queries `GET /api/user/topup/self` to retrieve the `trade_no` of the pending order.\n4. Attacker computes `HMAC-SHA256` with an empty key over a crafted `checkout.session.completed` payload containing the stolen `trade_no` as `client_reference_id`.\n5. Attacker sends `POST /api/stripe/webhook` with the forged payload and signature header.\n6. The server verifies the signature (passes because the secret is empty), calls `Recharge()`, which finds the Epay order by `trade_no`, marks it as `success`, and credits the full quota.\n7. Attacker repeats steps 2\u20136 indefinitely for unlimited credits.\n\n**Proof of concept** (pseudocode):\n```python\nimport hmac, hashlib, time, json, requests\n\ntimestamp = int(time.time())\npayload = json.dumps({\n    \"type\": \"checkout.session.completed\",\n    \"data\": {\n        \"object\": {\n            \"client_reference_id\": \"\u003ctrade_no from step 3\u003e\",\n            \"status\": \"complete\",\n            \"payment_status\": \"paid\",\n            \"customer\": \"cus_fake\",\n            \"amount_total\": \"0\",\n            \"currency\": \"usd\"\n        }\n    }\n})\n# Empty secret = publicly computable signature\nsig = hmac.new(b\"\", f\"{timestamp}.{payload}\".encode(), hashlib.sha256).hexdigest()\nheader = f\"t={timestamp},v1={sig}\"\n\nrequests.post(\"https://target/api/stripe/webhook\",\n    data=payload,\n    headers={\"Stripe-Signature\": header, \"Content-Type\": \"application/json\"})\n```\n\n## Remediation\n\n### Fix 1: Reject webhooks when secret is empty\n```go\nfunc StripeWebhook(c *gin.Context) {\n    if setting.StripeWebhookSecret == \"\" {\n        c.AbortWithStatus(http.StatusForbidden)\n        return\n    }\n    // ... existing logic\n}\n```\n\n### Fix 2: Verify `payment_status` and handle async payment events\n```go\nfunc sessionCompleted(event stripe.Event) {\n    // ... existing status check ...\n    paymentStatus := event.GetObjectValue(\"payment_status\")\n    if paymentStatus != \"paid\" {\n        return // Wait for async_payment_succeeded event\n    }\n    fulfillOrder(event, referenceId, customerId)\n}\n```\n\nAdd handlers for `checkout.session.async_payment_succeeded` and `checkout.session.async_payment_failed`.\n\n### Fix 3: Validate PaymentMethod in all recharge functions\n```go\n// In model.Recharge (Stripe):\nif topUp.PaymentMethod != \"stripe\" {\n    return ErrPaymentMethodMismatch\n}\n\n// In model.RechargeCreem:\nif topUp.PaymentMethod != \"creem\" {\n    return ErrPaymentMethodMismatch\n}\n\n// In model.RechargeWaffo:\nif topUp.PaymentMethod != \"waffo\" {\n    return ErrPaymentMethodMismatch\n}\n\n// In controller.EpayNotify:\nif topUp.PaymentMethod == \"stripe\" || topUp.PaymentMethod == \"creem\" || topUp.PaymentMethod == \"waffo\" {\n    return // reject cross-gateway fulfillment\n}\n```\n\n### Additional fix: Set PaymentMethod on Creem order creation\nThe Creem order creation was missing the `PaymentMethod` field entirely:\n```go\ntopUp := \u0026model.TopUp{\n    // ...\n    PaymentMethod: \"creem\", // was missing\n}\n```\n\n## Patched Versions\n\n- **v0.12.10** \u2014 includes all three fixes described above.\n\nAll users are strongly encouraged to upgrade immediately.\n\n## Workaround (for users unable to upgrade immediately)\n\nIf users cannot upgrade to v0.12.10 right away, apply **all** of the following mitigations:\n\n1. **Set `StripeWebhookSecret` to any non-empty value.** Go to the admin panel \u2192 Payment \u2192 Stripe, and set the Webhook Signing Secret to **any random string** (e.g., `whsec_placeholder_do_not_leave_empty`). It does **not** need to be a real Stripe secret \u2014 any non-empty value will prevent the empty-key HMAC forgery. **This is the single most important step** \u2014 it closes the primary attack vector. If Stripe payments are used in production, replace with the real secret from the project\u0027s [Stripe Dashboard \u2192 Webhooks](https://dashboard.stripe.com/webhooks) to ensure legitimate webhooks continue to work.\n\n2. **If Stripe is not in use, block the webhook endpoint.** If users have not configured Stripe payments, use a reverse proxy (Nginx, Caddy, etc.) to deny access to `/api/stripe/webhook`:\n   ```nginx\n   location = /api/stripe/webhook {\n       return 403;\n   }\n   ```\n\n\u003e **Note**: The workaround only mitigates Flaw 1 (empty secret bypass). Flaws 2 (missing `payment_status` check) and 3 (cross-gateway fulfillment) are only fully addressed in v0.12.10. **Upgrading is the only complete fix.**\n\n## Impact\n\n- **Financial fraud**: Attacker obtains unlimited API quota without payment.\n- **Operator financial loss**: Fraudulent quota is consumed against upstream AI providers (OpenAI, Anthropic, Google, etc.), charged to the operator.\n- **Silent exploitation**: Fraudulent top-ups appear as normal successful transactions in system logs, making detection difficult.\n- **Wide exposure**: The default insecure configuration means virtually all deployments with any payment method enabled are vulnerable.\n\n## Timeline\n\n- **2025-04-15**: Vulnerability reported by [@ChangeYu0229](https://github.com/ChangeYu0229)\n- **2025-04-15**: Vulnerability confirmed and root cause analysis completed\n- **2025-04-15**: Fix developed and applied\n- **2025-04-15**: Patched in v0.12.10\n\n## Resources\n\n- [Stripe Webhook Signature Verification Docs](https://docs.stripe.com/webhooks#verify-official-libraries)\n- [Stripe Checkout Fulfillment Guide \u2014 Handle async payment methods](https://docs.stripe.com/checkout/fulfillment#async-payment-methods)\n- [CWE-345: Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html)\n- [CWE-1188: Initialization with an Insecure Default](https://cwe.mitre.org/data/definitions/1188.html)",
  "id": "GHSA-xff3-5c9p-2mr4",
  "modified": "2026-05-13T13:37:29Z",
  "published": "2026-04-24T15:43:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/QuantumNous/new-api/security/advisories/GHSA-xff3-5c9p-2mr4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41432"
    },
    {
      "type": "WEB",
      "url": "https://docs.stripe.com/checkout/fulfillment#async-payment-methods"
    },
    {
      "type": "WEB",
      "url": "https://docs.stripe.com/webhooks#verify-official-libraries"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/QuantumNous/new-api"
    },
    {
      "type": "WEB",
      "url": "https://github.com/QuantumNous/new-api/releases/tag/v0.12.10"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "New API: Stripe Webhook Signature Bypass via Empty Secret Enables Unlimited Quota Fraud"
}

GHSA-XG3X-5QG6-QVM9

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

Ceragon FibeAir IP-10 wireless radios through 7.2.0 have a default password of mateidu for the mateidu account (a hidden user account established by the vendor). This account can be accessed via both the web interface and SSH. In the web interface, this simply grants an attacker read-only access to the device's settings. However, when using SSH, this gives an attacker access to a Linux shell. NOTE: the vendor has commented "The mateidu user is a known user, which is mentioned in the FibeAir IP-10 User Guide. Customers are instructed to change the mateidu user password. Changing the user password fully solves the vulnerability."

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-9137"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-05-21T21:29:00Z",
    "severity": "HIGH"
  },
  "details": "Ceragon FibeAir IP-10 wireless radios through 7.2.0 have a default password of mateidu for the mateidu account (a hidden user account established by the vendor). This account can be accessed via both the web interface and SSH. In the web interface, this simply grants an attacker read-only access to the device\u0027s settings. However, when using SSH, this gives an attacker access to a Linux shell. NOTE: the vendor has commented \"The mateidu user is a known user, which is mentioned in the FibeAir IP-10 User Guide. Customers are instructed to change the mateidu user password. Changing the user password fully solves the vulnerability.\"",
  "id": "GHSA-xg3x-5qg6-qvm9",
  "modified": "2022-05-13T01:47:48Z",
  "published": "2022-05-13T01:47:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-9137"
    },
    {
      "type": "WEB",
      "url": "http://blog.iancaling.com/post/160817658078"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-665: Exploitation of Thunderbolt Protection Flaws

An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.

← Back to the CWE list