CWE-862
Allowed-with-ReviewMissing Authorization
Abstraction: Class · Status: Incomplete
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
15794 vulnerabilities reference this CWE, most recent first.
GHSA-4H5W-RFR3-39RP
Vulnerability from github – Published: 2025-01-02 12:32 – Updated: 2026-04-23 15:34Missing Authorization vulnerability in gVectors Team wpDiscuz allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects wpDiscuz: from n/a through 7.6.10.
{
"affected": [],
"aliases": [
"CVE-2023-46309"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-02T12:15:11Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in gVectors Team wpDiscuz allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects wpDiscuz: from n/a through 7.6.10.",
"id": "GHSA-4h5w-rfr3-39rp",
"modified": "2026-04-23T15:34:13Z",
"published": "2025-01-02T12:32:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46309"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/wpdiscuz/vulnerability/wordpress-wpdiscuz-plugin-7-6-10-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4H68-4RGV-J269
Vulnerability from github – Published: 2024-04-09 21:31 – Updated: 2026-04-08 21:32The Pods – Custom Content Types and Fields plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 3.0.10 (with the exception of 2.7.31.2, 2.8.23.2, 2.9.19.2). This is due to the fact that the plugin allows the use of a file inclusion feature via shortcode. This makes it possible for authenticated attackers, with contributor access or higher, to create pods and users (with default role).
{
"affected": [],
"aliases": [
"CVE-2023-6965"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-09T19:15:13Z",
"severity": "MODERATE"
},
"details": "The Pods \u2013 Custom Content Types and Fields plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 3.0.10 (with the exception of 2.7.31.2, 2.8.23.2, 2.9.19.2). This is due to the fact that the plugin allows the use of a file inclusion feature via shortcode. This makes it possible for authenticated attackers, with contributor access or higher, to create pods and users (with default role).",
"id": "GHSA-4h68-4rgv-j269",
"modified": "2026-04-08T21:32:28Z",
"published": "2024-04-09T21:31:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6965"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/pods/trunk/classes/PodsView.php#L750"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026new=3039486%40pods%2Ftrunk\u0026old=3039467%40pods%2Ftrunk\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/c5d330cd-ad1f-451e-bf41-39cfeb296cf0?source=cve"
}
],
"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"
}
]
}
GHSA-4H75-RHHF-H6MJ
Vulnerability from github – Published: 2025-12-18 09:30 – Updated: 2026-01-20 15:32Missing Authorization vulnerability in ThemeAtelier IDonatePro idonate-pro allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects IDonatePro: from n/a through <= 2.1.9.
{
"affected": [],
"aliases": [
"CVE-2025-58938"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-18T08:16:01Z",
"severity": "HIGH"
},
"details": "Missing Authorization vulnerability in ThemeAtelier IDonatePro idonate-pro allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects IDonatePro: from n/a through \u003c= 2.1.9.",
"id": "GHSA-4h75-rhhf-h6mj",
"modified": "2026-01-20T15:32:24Z",
"published": "2025-12-18T09:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58938"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/idonate-pro/vulnerability/wordpress-idonatepro-plugin-2-1-9-broken-access-control-vulnerability-2?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/idonate-pro/vulnerability/wordpress-idonatepro-plugin-2-1-9-broken-access-control-vulnerability-2?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-4H89-J5FQ-8VXV
Vulnerability from github – Published: 2025-04-03 15:31 – Updated: 2026-04-01 18:34Missing Authorization vulnerability in jeffikus WooTumblog allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects WooTumblog: from n/a through 2.1.4.
{
"affected": [],
"aliases": [
"CVE-2025-31729"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-03T14:15:38Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in jeffikus WooTumblog allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects WooTumblog: from n/a through 2.1.4.",
"id": "GHSA-4h89-j5fq-8vxv",
"modified": "2026-04-01T18:34:27Z",
"published": "2025-04-03T15:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31729"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/woo-tumblog/vulnerability/wordpress-wootumblog-plugin-2-1-4-content-injection-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-4H97-P9WQ-CHQJ
Vulnerability from github – Published: 2026-08-18 20:51 – Updated: 2026-08-18 20:51Summary
The CertificateExport handler in lemur/certificates/views.py nests its entire ownership / CertificatePermission check inside an if plugin.requires_key: branch. When the selected export plugin advertises requires_key = False, the authorization check is skipped entirely and any authenticated user can invoke plugin.export(cert.body, cert.chain, cert.private_key, options) against a certificate they do not own. The handler additionally writes a "key_view" audit-log event for every call, regardless of whether the plugin actually accessed the private key, polluting the audit trail with false positives.
Root Cause
lemur/certificates/views.py:1573:
if plugin.requires_key:
if not cert.private_key:
return (..., 400)
else:
if g.current_user != cert.user:
owner_role = role_service.get_by_name(cert.owner)
permission = CertificatePermission(owner_role, [x.name for x in cert.roles])
if not permission.can():
return (..., 403)
log_service.create(g.current_user, "key_view", certificate=cert) # always logged
extension, passphrase, data = plugin.export(
cert.body, cert.chain, cert.private_key, options
)
The authorization gate is structurally inside the if plugin.requires_key: block. With requires_key = False, control falls straight through to plugin.export(...) with no ownership check. The cert.private_key is passed to the plugin regardless of the flag — the flag only describes what the plugin advertises it needs, not what it actually receives.
The only currently shipping ExportPlugin with requires_key = False is JavaTruststoreExportPlugin (lemur/plugins/lemur_jks/plugin.py), whose export() ignores the key argument and emits a public-only Java truststore. The present-day data exposure is therefore limited to public certificate material. The bug is nonetheless filed as a real authorization gap because:
- The structural defect is latent and silent - any future
requires_key = FalseExportPluginthat does readcert.private_keywill inherit the bypass with no test or code-review signal. - The unconditional
log_service.create(..., "key_view", ...)call falsely records key-view events for callers who never viewed a key, weakening incident-response signal.
Affected Endpoints
| Method | Path | Source |
|---|---|---|
| POST | /api/1/certificates/<id>/export |
lemur/certificates/views.py:1573 |
Impact
In the current codebase:
- Any authenticated user can mint a Java truststore (
java-truststore-jksplugin) containing any certificate's public body and chain, without owning the certificate or holding a role with permission over it. - The audit log records a
key_viewevent for the calling user against that certificate, despite no private key having been accessed. Defenders investigating apparent key-view events will encounter false positives that they cannot distinguish from genuine accesses.
Latent risk:
- A future
ExportPluginauthor who setsrequires_key = Falsebecause their plugin can operate without a key (e.g., for a fall-back code path) but still uses the key when one is provided will silently leak private keys to any authenticated user. The same code review that approves the plugin will not flag this — the authorization invariant is held by a structurally distantif-branch in the view, not by the plugin itself.
Remediation
Lift the authorization check out of the if plugin.requires_key: block so it runs for every export call:
# Authorization first, unconditionally.
if g.current_user != cert.user:
owner_role = role_service.get_by_name(cert.owner)
permission = CertificatePermission(owner_role, [x.name for x in cert.roles])
if not permission.can():
return (dict(message="You are not authorized to export this certificate."), 403)
if plugin.requires_key:
if not cert.private_key:
return (dict(message="Plugin requires a key but none is present."), 400)
log_service.create(g.current_user, "key_view", certificate=cert) # only when key actually accessed
extension, passphrase, data = plugin.export(
cert.body, cert.chain, cert.private_key, options
)
This makes the authorization gate independent of the plugin's requires_key flag and correctly scopes the key_view audit event to calls that actually involve key access.
Steps to Reproduce
-
Set up Lemur with default configuration. Create an admin user
adminand a non-admin userevewith theread-onlyrole (or any role without certificate permissions). -
As
admin, issue a certificate. Note itsid. -
As
eve, invoke export with thejava-truststore-jksplugin:
curl -X POST https://lemur.local/api/1/certificates/<cert_id>/export \
-H "Authorization: Bearer <eve_jwt>" \
-H "Content-Type: application/json" \
-d '{
"plugin": {
"slug": "java-truststore-jks",
"plugin_options": [
{"name": "passphrase", "value": "test"}
]
}
}'
-
Observe HTTP 200 with a base64-encoded JKS truststore in the response.
evehad no permission overadmin's certificate, yet successfully exported its public material. -
Inspect the audit log table or
lemur logs list:
psql lemur -c "SELECT user_id, log_type, certificate_id, logged_at FROM logs
WHERE certificate_id = <cert_id> ORDER BY logged_at DESC LIMIT 1;"
The log row shows log_type = 'key_view' for eve against admin's certificate, despite no private key actually being accessed by the truststore plugin - confirming the audit-log pollution facet of the bug.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "lemur"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.9.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-71322"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-18T20:51:42Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n \nThe `CertificateExport` handler in `lemur/certificates/views.py` nests its entire ownership / `CertificatePermission` check inside an `if plugin.requires_key:` branch. When the selected export plugin advertises `requires_key = False`, the authorization check is skipped entirely and any authenticated user can invoke `plugin.export(cert.body, cert.chain, cert.private_key, options)` against a certificate they do not own. The handler additionally writes a `\"key_view\"` audit-log event for every call, regardless of whether the plugin actually accessed the private key, polluting the audit trail with false positives.\n \n## Root Cause\n \n`lemur/certificates/views.py:1573`:\n \n```python\nif plugin.requires_key:\n if not cert.private_key:\n return (..., 400)\n else:\n if g.current_user != cert.user:\n owner_role = role_service.get_by_name(cert.owner)\n permission = CertificatePermission(owner_role, [x.name for x in cert.roles])\n if not permission.can():\n return (..., 403)\n \nlog_service.create(g.current_user, \"key_view\", certificate=cert) # always logged\nextension, passphrase, data = plugin.export(\n cert.body, cert.chain, cert.private_key, options\n)\n```\n \nThe authorization gate is structurally inside the `if plugin.requires_key:` block. With `requires_key = False`, control falls straight through to `plugin.export(...)` with no ownership check. The `cert.private_key` is passed to the plugin regardless of the flag \u2014 the flag only describes what the plugin *advertises* it needs, not what it actually receives.\n \nThe only currently shipping `ExportPlugin` with `requires_key = False` is `JavaTruststoreExportPlugin` (`lemur/plugins/lemur_jks/plugin.py`), whose `export()` ignores the `key` argument and emits a public-only Java truststore. The present-day data exposure is therefore limited to public certificate material. The bug is nonetheless filed as a real authorization gap because:\n \n1. The structural defect is latent and silent - any future `requires_key = False` `ExportPlugin` that *does* read `cert.private_key` will inherit the bypass with no test or code-review signal.\n2. The unconditional `log_service.create(..., \"key_view\", ...)` call falsely records key-view events for callers who never viewed a key, weakening incident-response signal.\n \n## Affected Endpoints\n \n| Method | Path | Source |\n|---|---|---|\n| POST | /api/1/certificates/`\u003cid\u003e`/export | lemur/certificates/views.py:1573 |\n \n## Impact\n \nIn the current codebase:\n \n- Any authenticated user can mint a Java truststore (`java-truststore-jks` plugin) containing any certificate\u0027s public body and chain, without owning the certificate or holding a role with permission over it.\n- The audit log records a `key_view` event for the calling user against that certificate, despite no private key having been accessed. Defenders investigating apparent key-view events will encounter false positives that they cannot distinguish from genuine accesses.\n \nLatent risk:\n \n- A future `ExportPlugin` author who sets `requires_key = False` because their plugin can *operate* without a key (e.g., for a fall-back code path) but still uses the key when one is provided will silently leak private keys to any authenticated user. The same code review that approves the plugin will not flag this \u2014 the authorization invariant is held by a structurally distant `if`-branch in the view, not by the plugin itself.\n \n## Remediation\n \nLift the authorization check out of the `if plugin.requires_key:` block so it runs for every export call:\n \n```python\n# Authorization first, unconditionally.\nif g.current_user != cert.user:\n owner_role = role_service.get_by_name(cert.owner)\n permission = CertificatePermission(owner_role, [x.name for x in cert.roles])\n if not permission.can():\n return (dict(message=\"You are not authorized to export this certificate.\"), 403)\n \nif plugin.requires_key:\n if not cert.private_key:\n return (dict(message=\"Plugin requires a key but none is present.\"), 400)\n log_service.create(g.current_user, \"key_view\", certificate=cert) # only when key actually accessed\n \nextension, passphrase, data = plugin.export(\n cert.body, cert.chain, cert.private_key, options\n)\n```\n \nThis makes the authorization gate independent of the plugin\u0027s `requires_key` flag and correctly scopes the `key_view` audit event to calls that actually involve key access.\n \n## Steps to Reproduce\n \n1. Set up Lemur with default configuration. Create an admin user `admin` and a non-admin user `eve` with the `read-only` role (or any role without certificate permissions).\n \n2. As `admin`, issue a certificate. Note its `id`.\n \n3. As `eve`, invoke export with the `java-truststore-jks` plugin:\n````\n curl -X POST https://lemur.local/api/1/certificates/\u003ccert_id\u003e/export \\\n -H \"Authorization: Bearer \u003ceve_jwt\u003e\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\n \"plugin\": {\n \"slug\": \"java-truststore-jks\",\n \"plugin_options\": [\n {\"name\": \"passphrase\", \"value\": \"test\"}\n ]\n }\n }\u0027\n````\n \n4. Observe HTTP 200 with a base64-encoded JKS truststore in the response. `eve` had no permission over `admin`\u0027s certificate, yet successfully exported its public material.\n \n5. Inspect the audit log table or `lemur logs list`:\n````\n psql lemur -c \"SELECT user_id, log_type, certificate_id, logged_at FROM logs\n WHERE certificate_id = \u003ccert_id\u003e ORDER BY logged_at DESC LIMIT 1;\"\n````\n The log row shows `log_type = \u0027key_view\u0027` for `eve` against `admin`\u0027s certificate, despite no private key actually being accessed by the truststore plugin - confirming the audit-log pollution facet of the bug.",
"id": "GHSA-4h97-p9wq-chqj",
"modified": "2026-08-18T20:51:42Z",
"published": "2026-08-18T20:51:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Netflix/lemur/security/advisories/GHSA-4h97-p9wq-chqj"
},
{
"type": "WEB",
"url": "https://github.com/Netflix/lemur/commit/5683bbea8b10cce07f9a8abf1e4a7d3b2031c585"
},
{
"type": "PACKAGE",
"url": "https://github.com/Netflix/lemur"
},
{
"type": "WEB",
"url": "https://github.com/Netflix/lemur/releases/tag/v1.9.3"
}
],
"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"
}
],
"summary": "Lemur: Missing authorization check on POST /certificates/\u003cid\u003e/export for plugins with requires_key = False"
}
GHSA-4H9H-538F-3P9H
Vulnerability from github – Published: 2025-05-19 15:31 – Updated: 2026-04-01 18:35Missing Authorization vulnerability in Blair Williams Shortlinks by Pretty Links allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Shortlinks by Pretty Links: from n/a through 3.6.15.
{
"affected": [],
"aliases": [
"CVE-2025-48247"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-19T15:15:27Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Blair Williams Shortlinks by Pretty Links allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Shortlinks by Pretty Links: from n/a through 3.6.15.",
"id": "GHSA-4h9h-538f-3p9h",
"modified": "2026-04-01T18:35:08Z",
"published": "2025-05-19T15:31:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48247"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/pretty-link/vulnerability/wordpress-shortlinks-by-pretty-links-3-6-15-broken-access-control-vulnerability?_s_id=cve"
}
],
"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"
}
]
}
GHSA-4H9Q-4JCF-X3V3
Vulnerability from github – Published: 2022-12-06 09:30 – Updated: 2022-12-07 18:30In power management service, there is a missing permission check. This could lead to set up power management service with no additional execution privileges needed.
{
"affected": [],
"aliases": [
"CVE-2022-39095"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-06T07:15:00Z",
"severity": "HIGH"
},
"details": "In power management service, there is a missing permission check. This could lead to set up power management service with no additional execution privileges needed.",
"id": "GHSA-4h9q-4jcf-x3v3",
"modified": "2022-12-07T18:30:28Z",
"published": "2022-12-06T09:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39095"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/1599588060988411006"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/1610118225591336001"
}
],
"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-4HC2-9PVR-GCXJ
Vulnerability from github – Published: 2025-12-08 18:30 – Updated: 2025-12-08 21:30In multiple functions of CertInstaller.java, there is a possible way to install certificates due to a permissions bypass. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
{
"affected": [],
"aliases": [
"CVE-2025-48575"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-08T17:16:15Z",
"severity": "HIGH"
},
"details": "In multiple functions of CertInstaller.java, there is a possible way to install certificates due to a permissions bypass. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.",
"id": "GHSA-4hc2-9pvr-gcxj",
"modified": "2025-12-08T21:30:20Z",
"published": "2025-12-08T18:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48575"
},
{
"type": "WEB",
"url": "https://android.googlesource.com/platform/packages/apps/CertInstaller/+/d688ebdbfd404df1e25654bfdf9e790ad9f0db3c"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2025-12-01"
}
],
"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-4HF2-VC5G-V7QR
Vulnerability from github – Published: 2025-08-28 15:30 – Updated: 2026-04-01 18:35Missing Authorization vulnerability in inkthemes WP Mailgun SMTP allows Accessing Functionality Not Properly Constrained by ACLs. This issue affects WP Mailgun SMTP: from n/a through 1.0.7.
{
"affected": [],
"aliases": [
"CVE-2025-48327"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-28T13:15:53Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in inkthemes WP Mailgun SMTP allows Accessing Functionality Not Properly Constrained by ACLs. This issue affects WP Mailgun SMTP: from n/a through 1.0.7.",
"id": "GHSA-4hf2-vc5g-v7qr",
"modified": "2026-04-01T18:35:59Z",
"published": "2025-08-28T15:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48327"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/wp-mailgun-smtp/vulnerability/wordpress-wp-mailgun-smtp-plugin-1-0-7-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4HF3-6269-C3W3
Vulnerability from github – Published: 2026-03-13 21:31 – Updated: 2026-03-13 21:31Missing Authorization vulnerability in Josh Kohlbach Advanced Coupons for WooCommerce Coupons advanced-coupons-for-woocommerce-free allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Advanced Coupons for WooCommerce Coupons: from n/a through <= 4.7.1.
{
"affected": [],
"aliases": [
"CVE-2026-31919"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-13T19:54:39Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Josh Kohlbach Advanced Coupons for WooCommerce Coupons advanced-coupons-for-woocommerce-free allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Advanced Coupons for WooCommerce Coupons: from n/a through \u003c= 4.7.1.",
"id": "GHSA-4hf3-6269-c3w3",
"modified": "2026-03-13T21:31:47Z",
"published": "2026-03-13T21:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31919"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/advanced-coupons-for-woocommerce-free/vulnerability/wordpress-advanced-coupons-for-woocommerce-coupons-plugin-4-7-1-broken-access-control-vulnerability?_s_id=cve"
}
],
"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"
}
]
}
Mitigation
- 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
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
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
- 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
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.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.