Common Weakness Enumeration

CWE-672

Allowed-with-Review

Operation on a Resource after Expiration or Release

Abstraction: Class · Status: Draft

The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.

141 vulnerabilities reference this CWE, most recent first.

GHSA-38QG-7H9Q-7H29

Vulnerability from github – Published: 2025-10-31 12:30 – Updated: 2025-11-05 00:31
VLAI
Details

When passing through PCI devices, the detach logic in libxl won't remove access permissions to any 64bit memory BARs the device might have. As a result a domain can still have access any 64bit memory BAR when such device is no longer assigned to the domain.

For PV domains the permission leak allows the domain itself to map the memory in the page-tables. For HVM it would require a compromised device model or stubdomain to map the leaked memory into the HVM domain p2m.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-58149"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-31T12:15:35Z",
    "severity": "HIGH"
  },
  "details": "When passing through PCI devices, the detach logic in libxl won\u0027t remove\naccess permissions to any 64bit memory BARs the device might have.  As a\nresult a domain can still have access any 64bit memory BAR when such\ndevice is no longer assigned to the domain.\n\nFor PV domains the permission leak allows the domain itself to map the memory\nin the page-tables.  For HVM it would require a compromised device model or\nstubdomain to map the leaked memory into the HVM domain p2m.",
  "id": "GHSA-38qg-7h9q-7h29",
  "modified": "2025-11-05T00:31:32Z",
  "published": "2025-10-31T12:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58149"
    },
    {
      "type": "WEB",
      "url": "https://xenbits.xenproject.org/xsa/advisory-476.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/10/24/1"
    },
    {
      "type": "WEB",
      "url": "http://xenbits.xen.org/xsa/advisory-476.html"
    }
  ],
  "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"
    }
  ]
}

GHSA-3CJH-P6PW-JHV9

Vulnerability from github – Published: 2023-09-19 17:00 – Updated: 2023-09-19 17:00
VLAI
Summary
Pow Mnesia cache doesn't invalidate all expired keys on startup
Details

Use of Pow.Store.Backend.MnesiaCache is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all Pow.Store.Backend.MnesiaCache instances have been shut down for a period that is longer than the keys' remaining TTL and the expired key won't be invalidated on startups.

Workarounds

The expired keys, including all expired sessions, can be manually invalidated by running:

:mnesia.sync_transaction(fn ->
  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:"$_"]}]), fn {_, key,  {_value, expire}} ->
    ttl = expire - :os.system_time(:millisecond)
    if ttl < 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})
  end)
end)

References

https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17 https://github.com/pow-auth/pow/issues/713 https://github.com/pow-auth/pow/pull/714

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Hex",
        "name": "pow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.14"
            },
            {
              "fixed": "1.0.34"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-42446"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-298",
      "CWE-672"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-09-19T17:00:08Z",
    "nvd_published_at": "2023-09-18T22:15:47Z",
    "severity": "MODERATE"
  },
  "details": "Use of `Pow.Store.Backend.MnesiaCache` is susceptible to session hijacking as expired keys are not being invalidated correctly on startup. A cache key may become expired when all `Pow.Store.Backend.MnesiaCache` instances have been shut down for a period that is longer than the keys\u0027 remaining TTL and the expired key won\u0027t be invalidated on startups.\n\n### Workarounds\n\nThe expired keys, including all expired sessions, can be manually invalidated by running:\n\n```elixir\n:mnesia.sync_transaction(fn -\u003e\n  Enum.each(:mnesia.dirty_select(Pow.Store.Backend.MnesiaCache, [{{Pow.Store.Backend.MnesiaCache, :_, :_}, [], [:\"$_\"]}]), fn {_, key,  {_value, expire}} -\u003e\n    ttl = expire - :os.system_time(:millisecond)\n    if ttl \u003c 0, do: :mnesia.delete({Pow.Store.Backend.MnesiaCache, key})\n  end)\nend)\n```\n\n### References\nhttps://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17\nhttps://github.com/pow-auth/pow/issues/713\nhttps://github.com/pow-auth/pow/pull/714\n",
  "id": "GHSA-3cjh-p6pw-jhv9",
  "modified": "2023-09-19T17:00:08Z",
  "published": "2023-09-19T17:00:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pow-auth/pow/security/advisories/GHSA-3cjh-p6pw-jhv9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42446"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pow-auth/pow/issues/713"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pow-auth/pow/pull/714"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pow-auth/pow/commit/15dc525be03c466daa5d2119ca7acdec7b24ed17"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pow-auth/pow"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Pow Mnesia cache doesn\u0027t invalidate all expired keys on startup"
}

GHSA-3RM8-6R4W-V7HC

Vulnerability from github – Published: 2026-09-29 18:32 – Updated: 2026-09-30 21:32
VLAI
Details

Use of released resource in Core in Google Chrome prior to 154.0.8037.57 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-95366"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-29T18:17:30Z",
    "severity": "MODERATE"
  },
  "details": "Use of released resource in Core in Google Chrome prior to 154.0.8037.57 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium)",
  "id": "GHSA-3rm8-6r4w-v7hc",
  "modified": "2026-09-30T21:32:01Z",
  "published": "2026-09-29T18:32:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-95366"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_0856730748.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/497204165"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3W9M-VG42-8V9H

Vulnerability from github – Published: 2022-12-22 21:30 – Updated: 2025-04-16 15:34
VLAI
Details

By using XSL Transforms, a malicious webserver could have served a user an XSL document that would continue to execute JavaScript (within the bounds of the same-origin policy) even after the tab was closed. This vulnerability affects Firefox < 97.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-22755"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-22T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "By using XSL Transforms, a malicious webserver could have served a user an XSL document that would continue to execute JavaScript (within the bounds of the same-origin policy) even after the tab was closed. This vulnerability affects Firefox \u003c 97.",
  "id": "GHSA-3w9m-vg42-8v9h",
  "modified": "2025-04-16T15:34:06Z",
  "published": "2022-12-22T21:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22755"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1309630"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2022-04"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-442R-3R9F-48CM

Vulnerability from github – Published: 2022-05-24 17:27 – Updated: 2023-02-03 00:30
VLAI
Details

get_gate_page in mm/gup.c in the Linux kernel 5.7.x and 5.8.x before 5.8.7 allows privilege escalation because of incorrect reference counting (caused by gate page mishandling) of the struct page that backs the vsyscall page. The result is a refcount underflow. This can be triggered by any 64-bit process that can use ptrace() or process_vm_readv(), aka CID-9fa2dd946743.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-25221"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-10T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "get_gate_page in mm/gup.c in the Linux kernel 5.7.x and 5.8.x before 5.8.7 allows privilege escalation because of incorrect reference counting (caused by gate page mishandling) of the struct page that backs the vsyscall page. The result is a refcount underflow. This can be triggered by any 64-bit process that can use ptrace() or process_vm_readv(), aka CID-9fa2dd946743.",
  "id": "GHSA-442r-3r9f-48cm",
  "modified": "2023-02-03T00:30:17Z",
  "published": "2022-05-24T17:27:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25221"
    },
    {
      "type": "WEB",
      "url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.8.7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/linus/8891adc61dce2a8a41fc0c23262b681c3ec4b73a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/linus/9fa2dd946743ae6f30dc4830da19147bf100a7f2"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20201001-0003"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2020/09/08/4"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/09/10/4"
    }
  ],
  "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-44M6-Q7G6-5VP6

Vulnerability from github – Published: 2025-01-14 15:30 – Updated: 2025-03-19 18:30
VLAI
Details

An operation on a resource after expiration or release in Fortinet FortiManager 6.4.12 through 7.4.0 allows an attacker to gain improper access to FortiGate via valid credentials.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-47571"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-14T14:15:32Z",
    "severity": "HIGH"
  },
  "details": "An operation on a resource after expiration or release in Fortinet FortiManager 6.4.12 through 7.4.0 allows an attacker to gain improper access to FortiGate via valid credentials.",
  "id": "GHSA-44m6-q7g6-5vp6",
  "modified": "2025-03-19T18:30:48Z",
  "published": "2025-01-14T15:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47571"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.fortinet.com/psirt/FG-IR-24-239"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-47FV-C4CG-C767

Vulnerability from github – Published: 2024-03-02 00:31 – Updated: 2025-01-09 18:32
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

ipc/mqueue, msg, sem: avoid relying on a stack reference past its expiry

do_mq_timedreceive calls wq_sleep with a stack local address. The sender (do_mq_timedsend) uses this address to later call pipelined_send.

This leads to a very hard to trigger race where a do_mq_timedreceive call might return and leave do_mq_timedsend to rely on an invalid address, causing the following crash:

RIP: 0010:wake_q_add_safe+0x13/0x60 Call Trace: __x64_sys_mq_timedsend+0x2a9/0x490 do_syscall_64+0x80/0x680 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f5928e40343

The race occurs as:

  1. do_mq_timedreceive calls wq_sleep with the address of struct ext_wait_queue on function stack (aliased as ewq_addr here) - it holds a valid struct ext_wait_queue * as long as the stack has not been overwritten.

  2. ewq_addr gets added to info->e_wait_q[RECV].list in wq_add, and do_mq_timedsend receives it via wq_get_first_waiter(info, RECV) to call __pipelined_op.

  3. Sender calls __pipelined_op::smp_store_release(&this->state, STATE_READY). Here is where the race window begins. (this is ewq_addr.)

  4. If the receiver wakes up now in do_mq_timedreceive::wq_sleep, it will see state == STATE_READY and break.

  5. do_mq_timedreceive returns, and ewq_addr is no longer guaranteed to be a struct ext_wait_queue * since it was on do_mq_timedreceive's stack. (Although the address may not get overwritten until another function happens to touch it, which means it can persist around for an indefinite time.)

  6. do_mq_timedsend::__pipelined_op() still believes ewq_addr is a struct ext_wait_queue *, and uses it to find a task_struct to pass to the wake_q_add_safe call. In the lucky case where nothing has overwritten ewq_addr yet, ewq_addr->task is the right task_struct. In the unlucky case, __pipelined_op::wake_q_add_safe gets handed a bogus address as the receiver's task_struct causing the crash.

do_mq_timedsend::__pipelined_op() should not dereference this after setting STATE_READY, as the receiver counterpart is now free to return. Change __pipelined_op to call wake_q_add_safe on the receiver's task_struct returned by get_task_struct, instead of dereferencing this which sits on the receiver's stack.

As Manfred pointed out, the race potentially also exists in ipc/msg.c::expunge_all and ipc/sem.c::wake_up_sem_queue_prepare. Fix those in the same way.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-47069"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-01T22:15:46Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nipc/mqueue, msg, sem: avoid relying on a stack reference past its expiry\n\ndo_mq_timedreceive calls wq_sleep with a stack local address.  The\nsender (do_mq_timedsend) uses this address to later call pipelined_send.\n\nThis leads to a very hard to trigger race where a do_mq_timedreceive\ncall might return and leave do_mq_timedsend to rely on an invalid\naddress, causing the following crash:\n\n  RIP: 0010:wake_q_add_safe+0x13/0x60\n  Call Trace:\n   __x64_sys_mq_timedsend+0x2a9/0x490\n   do_syscall_64+0x80/0x680\n   entry_SYSCALL_64_after_hwframe+0x44/0xa9\n  RIP: 0033:0x7f5928e40343\n\nThe race occurs as:\n\n1. do_mq_timedreceive calls wq_sleep with the address of `struct\n   ext_wait_queue` on function stack (aliased as `ewq_addr` here) - it\n   holds a valid `struct ext_wait_queue *` as long as the stack has not\n   been overwritten.\n\n2. `ewq_addr` gets added to info-\u003ee_wait_q[RECV].list in wq_add, and\n   do_mq_timedsend receives it via wq_get_first_waiter(info, RECV) to call\n   __pipelined_op.\n\n3. Sender calls __pipelined_op::smp_store_release(\u0026this-\u003estate,\n   STATE_READY).  Here is where the race window begins.  (`this` is\n   `ewq_addr`.)\n\n4. If the receiver wakes up now in do_mq_timedreceive::wq_sleep, it\n   will see `state == STATE_READY` and break.\n\n5. do_mq_timedreceive returns, and `ewq_addr` is no longer guaranteed\n   to be a `struct ext_wait_queue *` since it was on do_mq_timedreceive\u0027s\n   stack.  (Although the address may not get overwritten until another\n   function happens to touch it, which means it can persist around for an\n   indefinite time.)\n\n6. do_mq_timedsend::__pipelined_op() still believes `ewq_addr` is a\n   `struct ext_wait_queue *`, and uses it to find a task_struct to pass to\n   the wake_q_add_safe call.  In the lucky case where nothing has\n   overwritten `ewq_addr` yet, `ewq_addr-\u003etask` is the right task_struct.\n   In the unlucky case, __pipelined_op::wake_q_add_safe gets handed a\n   bogus address as the receiver\u0027s task_struct causing the crash.\n\ndo_mq_timedsend::__pipelined_op() should not dereference `this` after\nsetting STATE_READY, as the receiver counterpart is now free to return.\nChange __pipelined_op to call wake_q_add_safe on the receiver\u0027s\ntask_struct returned by get_task_struct, instead of dereferencing `this`\nwhich sits on the receiver\u0027s stack.\n\nAs Manfred pointed out, the race potentially also exists in\nipc/msg.c::expunge_all and ipc/sem.c::wake_up_sem_queue_prepare.  Fix\nthose in the same way.",
  "id": "GHSA-47fv-c4cg-c767",
  "modified": "2025-01-09T18:32:06Z",
  "published": "2024-03-02T00:31:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47069"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4528c0c323085e645b8765913b4a7fd42cf49b65"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/807fa14536b26803b858da878b643be72952a097"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a11ddb37bf367e6b5239b95ca759e5389bb46048"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-48GG-32Q2-4R6M

Vulnerability from github – Published: 2024-08-25 03:30 – Updated: 2025-10-13 15:12
VLAI
Summary
Hyperledger Fabric does not verify request has a timestamp within the expected time window
Details

Hyperledger Fabric through 2.5.9 does not verify that a request has a timestamp within the expected time window.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hyperledger/fabric"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.5.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-45244"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-294",
      "CWE-672"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-08-26T14:56:07Z",
    "nvd_published_at": "2024-08-25T02:15:03Z",
    "severity": "MODERATE"
  },
  "details": "Hyperledger Fabric through 2.5.9 does not verify that a request has a timestamp within the expected time window.",
  "id": "GHSA-48gg-32q2-4r6m",
  "modified": "2025-10-13T15:12:40Z",
  "published": "2024-08-25T03:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45244"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hyperledger/fabric/commit/155457a6624b3c74b22e5729c35c8499bfe952cd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hyperledger/fabric"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shanker-sec/HLF_TxTime_spoofing"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shanker-sec/hlf-time-oracle"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Hyperledger Fabric does not verify request has a timestamp within the expected time window"
}

GHSA-4HF6-3X24-C9M8

Vulnerability from github – Published: 2026-03-11 00:35 – Updated: 2026-03-11 20:57
VLAI
Summary
Parse Server's MFA recovery codes not consumed after use
Details

Impact

When multi-factor authentication (MFA) via TOTP is enabled for a user account, Parse Server generates two single-use recovery codes. These codes are intended as a fallback when the user cannot provide a TOTP token. However, recovery codes are not consumed after use, allowing the same recovery code to be used an unlimited number of times. This defeats the single-use design of recovery codes and weakens the security of MFA-protected accounts.

An attacker who obtains a single recovery code can repeatedly authenticate as the affected user without the code ever being invalidated.

Patches

The fix ensures that each recovery code is removed from the stored recovery code list after a successful login.

Workarounds

There is no known workaround.

References

  • GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-4hf6-3x24-c9m8
  • Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.7
  • Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.33
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0-alpha.1"
            },
            {
              "fixed": "9.6.0-alpha.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.6.33"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-31875"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-11T00:35:41Z",
    "nvd_published_at": "2026-03-11T18:16:27Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nWhen multi-factor authentication (MFA) via TOTP is enabled for a user account, Parse Server generates two single-use recovery codes. These codes are intended as a fallback when the user cannot provide a TOTP token. However, recovery codes are not consumed after use, allowing the same recovery code to be used an unlimited number of times. This defeats the single-use design of recovery codes and weakens the security of MFA-protected accounts.\n\nAn attacker who obtains a single recovery code can repeatedly authenticate as the affected user without the code ever being invalidated.\n\n### Patches\n\nThe fix ensures that each recovery code is removed from the stored recovery code list after a successful login.\n\n### Workarounds\n\nThere is no known workaround.\n\n### References\n\n- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-4hf6-3x24-c9m8\n- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.7\n- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.33",
  "id": "GHSA-4hf6-3x24-c9m8",
  "modified": "2026-03-11T20:57:55Z",
  "published": "2026-03-11T00:35:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-4hf6-3x24-c9m8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31875"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/parse-community/parse-server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/releases/tag/8.6.33"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/releases/tag/9.6.0-alpha.7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Parse Server\u0027s MFA recovery codes not consumed after use"
}

GHSA-4PCJ-QPX3-MJMX

Vulnerability from github – Published: 2026-07-16 21:30 – Updated: 2026-07-16 21:30
VLAI
Details

An issue was discovered in cyrus-imapd in Cyrus IMAP through 3.12.2. URLAUTH does not honor revoked authorizer access. A URLAUTH URL minted while the authorizer had access continued to work after that access was revoked.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-47087"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-16T19:16:49Z",
    "severity": "LOW"
  },
  "details": "An issue was discovered in cyrus-imapd in Cyrus IMAP through 3.12.2. URLAUTH does not honor revoked authorizer access. A URLAUTH URL minted while the authorizer had access continued to work after that access was revoked.",
  "id": "GHSA-4pcj-qpx3-mjmx",
  "modified": "2026-07-16T21:30:37Z",
  "published": "2026-07-16T21:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47087"
    },
    {
      "type": "WEB",
      "url": "https://www.cyrusimap.org/3.12/imap/download/release-notes/3.12/x/3.12.3.html"
    },
    {
      "type": "WEB",
      "url": "https://www.cyrusimap.org/imap/download/release-notes/index.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.