Common Weakness Enumeration

CWE-862

Allowed-with-Review

Missing Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

15696 vulnerabilities reference this CWE, most recent first.

GHSA-6C3H-GXFP-37VM

Vulnerability from github – Published: 2026-02-19 18:31 – Updated: 2026-02-20 18:31
VLAI
Details

Missing Authorization vulnerability in cmsmasters CMSMasters Content Composer cmsmasters-content-composer allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects CMSMasters Content Composer: from n/a through <= 2.5.8.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-23547"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-19T09:16:12Z",
    "severity": "HIGH"
  },
  "details": "Missing Authorization vulnerability in cmsmasters CMSMasters Content Composer cmsmasters-content-composer allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects CMSMasters Content Composer: from n/a through \u003c= 2.5.8.",
  "id": "GHSA-6c3h-gxfp-37vm",
  "modified": "2026-02-20T18:31:27Z",
  "published": "2026-02-19T18:31:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23547"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/cmsmasters-content-composer/vulnerability/wordpress-cmsmasters-content-composer-plugin-2-5-8-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:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6C46-P6J5-3F49

Vulnerability from github – Published: 2026-01-13 20:37 – Updated: 2026-01-13 20:37
VLAI
Summary
TYPO3 CMS Allows Broken Access Control in Redirects Module
Details

Problem

Backend users with access to the redirects module and write permission on the sys_redirect table were able to read, create, and modify any redirect record - without restriction to the user’s own file‑mounts or web‑mounts. This allowed attackers to insert or alter redirects pointing to arbitrary URLs - facilitating phishing or other malicious redirect attacks.

Solution

Update to TYPO3 versions 10.4.55 ELTS, 11.5.49 ELTS, 12.4.41 LTS, 13.4.23 LTS, 14.0.2 that fix the problem described.

Credits

Thanks to Georg Dümmler for reporting this issue, and to TYPO3 security team member Elias Häußler for fixing it.

References

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 14.0.1"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-redirects"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "14.0.0"
            },
            {
              "fixed": "14.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 13.4.22"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-redirects"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "13.0.0"
            },
            {
              "fixed": "13.4.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 12.4.40"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-redirects"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.0.0"
            },
            {
              "fixed": "12.4.41"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 11.5.48"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-redirects"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.5.49"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.4.54"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-redirects"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.4.55"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59021"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-13T20:37:37Z",
    "nvd_published_at": "2026-01-13T12:15:50Z",
    "severity": "MODERATE"
  },
  "details": "### Problem\nBackend users with access to the redirects module and write permission on the `sys_redirect` table were able to  read, create, and modify any redirect record - without restriction to the user\u2019s own file\u2011mounts or web\u2011mounts. This allowed attackers to insert or alter redirects pointing to arbitrary URLs - facilitating phishing or other malicious redirect attacks.\n\n### Solution\nUpdate to TYPO3 versions 10.4.55 ELTS, 11.5.49 ELTS, 12.4.41 LTS, 13.4.23 LTS, 14.0.2 that fix the problem described.\n\n### Credits\nThanks to Georg D\u00fcmmler for reporting this issue, and to TYPO3 security team member Elias H\u00e4u\u00dfler for fixing it.\n\n### References\n* [TYPO3-CORE-SA-2026-002](https://typo3.org/security/advisory/typo3-core-sa-2026-002)",
  "id": "GHSA-6c46-p6j5-3f49",
  "modified": "2026-01-13T20:37:37Z",
  "published": "2026-01-13T20:37:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/TYPO3/typo3/security/advisories/GHSA-6c46-p6j5-3f49"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59021"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TYPO3/typo3/commit/8a46abd8993e3a5a31a834dcd6c8f91adef57ce4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TYPO3/typo3/commit/bac370df5c1c3fcf5ebc1c030fbd2bec86d6a686"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TYPO3/typo3/commit/fbbae3b9a40d0420207ef7af990cdf1ac0612c0b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/TYPO3/typo3"
    },
    {
      "type": "WEB",
      "url": "https://typo3.org/security/advisory/typo3-core-sa-2026-002"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "TYPO3 CMS Allows Broken Access Control in Redirects Module"
}

GHSA-6C4C-5HCJ-J9PJ

Vulnerability from github – Published: 2024-06-12 09:30 – Updated: 2024-06-12 09:30
VLAI
Details

Missing Authorization vulnerability in Brett Shumaker Simple Staff List.This issue affects Simple Staff List: from n/a through 2.2.4.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-51526"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-12T09:15:11Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in Brett Shumaker Simple Staff List.This issue affects Simple Staff List: from n/a through 2.2.4.",
  "id": "GHSA-6c4c-5hcj-j9pj",
  "modified": "2024-06-12T09:30:48Z",
  "published": "2024-06-12T09:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51526"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/simple-staff-list/wordpress-simple-staff-list-plugin-2-2-4-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"
    }
  ]
}

GHSA-6C4V-HV9Q-25JC

Vulnerability from github – Published: 2026-08-16 06:30 – Updated: 2026-08-16 06:30
VLAI
Details

The ShortPixel Adaptive Images – WebP, AVIF, CDN, Image Optimization plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 3.11.5. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with subscriber-level access and above, to modify configuration options of third-party plugins including ShortPixel Image Optimizer, Autoptimize, WP Rocket, Imagify, and LiteSpeed Cache, as well as the plugin's own API key and account binding. Exploitation requires the respective third-party plugins to be installed, as the impact against those plugins' settings is only reachable when those plugins are present.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-15345"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-16T06:16:50Z",
    "severity": "MODERATE"
  },
  "details": "The ShortPixel Adaptive Images \u2013 WebP, AVIF, CDN, Image Optimization plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 3.11.5. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with subscriber-level access and above, to modify configuration options of third-party plugins including ShortPixel Image Optimizer, Autoptimize, WP Rocket, Imagify, and LiteSpeed Cache, as well as the plugin\u0027s own API key and account binding. Exploitation requires the respective third-party plugins to be installed, as the impact against those plugins\u0027 settings is only reachable when those plugins are present.",
  "id": "GHSA-6c4v-hv9q-25jc",
  "modified": "2026-08-16T06:30:25Z",
  "published": "2026-08-16T06:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15345"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/shortpixel-adaptive-images/tags/3.11.5/includes/actions/notice.actions.class.php#L16"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/shortpixel-adaptive-images/tags/3.11.5/includes/actions/notice.actions.class.php#L566"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/shortpixel-adaptive-images/tags/3.11.5/includes/actions/notice.actions.class.php#L614"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/shortpixel-adaptive-images/tags/3.11.5/includes/actions/notice.actions.class.php#L87"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/shortpixel-adaptive-images/tags/3.11.5/includes/controllers/notice.class.php#L747"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?reponame=\u0026old=3625451%40shortpixel-adaptive-images\u0026new=3625451%40shortpixel-adaptive-images"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/c3efae8f-ca89-4d8c-a177-6793994b3ea0?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-6C66-33PW-Q83J

Vulnerability from github – Published: 2026-06-11 12:32 – Updated: 2026-06-11 12:32
VLAI
Details

A Missing Authorization vulnerability in the playbook import functionality in Dialogflow CX on Google Cloud Platform allows an authenticated user with specific roles to escalate privileges and potentially take over a GCP project using a maliciously crafted playbook import.

This vulnerability was patched on 15 March 2026, and no customer action is needed.

Severity
9.4 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/U:Clear
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-4764"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-11T12:16:31Z",
    "severity": "CRITICAL"
  },
  "details": "A Missing Authorization vulnerability in the playbook import functionality in Dialogflow CX on Google Cloud Platform allows an authenticated user with specific roles to escalate privileges and potentially take over a GCP project using a maliciously crafted playbook import.\n\n\nThis vulnerability was patched on 15 March 2026, and no customer action is needed.",
  "id": "GHSA-6c66-33pw-q83j",
  "modified": "2026-06-11T12:32:44Z",
  "published": "2026-06-11T12:32:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4764"
    },
    {
      "type": "WEB",
      "url": "https://docs.cloud.google.com/dialogflow/docs/release-notes#May_07_2026"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Clear",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-6C6R-5XR4-CR5M

Vulnerability from github – Published: 2026-07-21 20:22 – Updated: 2026-07-21 20:22
VLAI
Summary
Gitea: Cross-repository issue/comment attachment re-linking can expose private attachment content
Details

Summary

Gitea's issue and comment attachment update paths accept attachment UUIDs without verifying that each attachment belongs to the target issue/comment repository. If an authenticated attacker knows a victim attachment UUID, they can re-link that attachment to an attacker-controlled issue or comment, causing later attachment access checks to use the attacker's repository authorization context.

Affected

  • Component: web issue/comment attachment handling.
  • Confirmed version: main commit a39b2775edcb3ba53def96794491b91335117d81 (v1.27.0-dev-352-ga39b2775ed).
  • Fixed in: not fixed at the time of validation.
  • Other versions: not exhaustively tested. The affected code path appears structurally similar to versions that contain the current issue/comment attachment update logic.

Description / Root Cause

files[] values from issue/comment edit flows are passed to updateAttachments in routers/web/repo/issue.go:589-629. That helper calls:

  • models/issues/issue_update.go:267-278 (UpdateIssueAttachments)
  • models/issues/comment.go:623-642 (UpdateCommentAttachments)

Both functions load attachments by UUID and update the attachment linkage, but neither validates that the attachment row's RepoID matches the repository of the target issue/comment. They also do not reject attachments already linked to a different issue/comment.

Attachment reads then use the linked issue/release repository to decide access:

  • services/repository/repository.go:185-207 returns the repository ID from IssueID or ReleaseID.
  • routers/web/repo/attachment.go:153-184 checks read permission on that linked repository.
  • routers/web/repo/attachment.go:216-224 opens and serves the file from the attachment's storage path after the linked-repository permission check succeeds.

For the global /attachments/{uuid} route in routers/web/web.go:872-876, there is no current repository context, so the early attach.RepoID mismatch check in ServeAttachment does not protect against this re-linking case.

A patched sibling path already demonstrates the intended invariant: models/repo/release.go:179-215 rejects release attachments whose RepoID differs from the release repository. That guard was introduced for CVE-2026-20736, but the issue/comment paths still lack an equivalent check.

Impact

An attacker who can edit an issue/comment in a repository they can read can move a known victim attachment UUID into that repository's authorization context. After the re-link, the attachment download path resolves access against the attacker-controlled repository while serving the original attachment file.

This can disclose private issue/comment attachments if the attacker has obtained the UUID through prior legitimate access, copied links, notification content, logs, browser history, or another exposure. The attack does not require write access to the victim repository.

Reproduction Summary

Full HTTP/E2E observation:

  • A local Gitea server was started with an isolated SQLite database.
  • A victim user created private repositories, private issues, and issue attachments containing unique marker strings.
  • An attacker user first attempted to download each victim attachment through /attachments/{uuid} and received 404.
  • The attacker then submitted the victim UUID through the real issue edit route in an attacker-controlled public repository.
  • The same attacker could then download the victim issue attachment through /attachments/{uuid} and received 200; the response body contained the unique issue marker.
  • The attacker repeated the flow through the real comment edit route and could download the second victim attachment with 200; the response body contained the unique comment marker.

Model-level issue-path behavior:

  • A fixture attachment with RepoID = 2 and IssueID = 4 was passed to UpdateIssueAttachments for attacker issue ID = 1, whose RepoID = 1.
  • The call succeeded.
  • The attachment row still had RepoID = 2, but its IssueID was changed to the attacker issue.
  • GetAttachmentLinkedTypeAndRepoID then resolved the attachment to attacker repository RepoID = 1.

Model-level comment-path behavior:

  • The same cross-repository attachment UUID was passed to UpdateCommentAttachments for attacker comment ID = 1.
  • The call succeeded.
  • The attachment row still had RepoID = 2, but its IssueID and CommentID were changed to the attacker's issue/comment.
  • The linked repository used for access checks became attacker repository RepoID = 1.

Negative control:

  • Existing release test TestAddReleaseAttachmentsRejectsDifferentRepo passes and confirms the release path rejects the same class of cross-repository attachment linkage.

Detailed verifier and step-by-step runbook are available on request.

Suggested Fix

Add repository and linkage validation before updating issue/comment attachments.

Recommended checks:

  • Load the target issue for UpdateIssueAttachments and derive its RepoID.
  • Load the target comment's issue for UpdateCommentAttachments and derive its RepoID.
  • Reject any attachment whose RepoID differs from the target issue repository.
  • Reject attachments already linked to a different issue/comment/release, except for attachments already linked to the same object being updated.
  • If caller context is available at the web/service layer, also require new unlinked attachments to belong to the current actor or to have been uploaded in the current edit session.
  • Preserve any legacy RepoID = 0 migration behavior only when it can be proven safe for the target repository.

Also consider a cleanup/audit query for existing inconsistent rows where attachment.issue_id != 0 and attachment.repo_id differs from the linked issue repository.

Regression Tests

Add tests that fail before the fix and pass after it:

  • UpdateIssueAttachments rejects an attachment whose RepoID differs from the target issue's RepoID.
  • UpdateCommentAttachments rejects an attachment whose RepoID differs from the target comment issue's RepoID.
  • Same-repository unlinked attachment linking still works for normal issue/comment editing.
  • Attachments already linked to a different issue/comment cannot be moved by passing their UUID in files[].
  • Existing release guard test remains passing.
Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-57886"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T20:22:58Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nGitea\u0027s issue and comment attachment update paths accept attachment UUIDs without verifying that each attachment belongs to the target issue/comment repository. If an authenticated attacker knows a victim attachment UUID, they can re-link that attachment to an attacker-controlled issue or comment, causing later attachment access checks to use the attacker\u0027s repository authorization context.\n\n## Affected\n\n- Component: web issue/comment attachment handling.\n- Confirmed version: `main` commit `a39b2775edcb3ba53def96794491b91335117d81` (`v1.27.0-dev-352-ga39b2775ed`).\n- Fixed in: not fixed at the time of validation.\n- Other versions: not exhaustively tested. The affected code path appears structurally similar to versions that contain the current issue/comment attachment update logic.\n\n## Description / Root Cause\n\n`files[]` values from issue/comment edit flows are passed to `updateAttachments` in `routers/web/repo/issue.go:589-629`. That helper calls:\n\n- `models/issues/issue_update.go:267-278` (`UpdateIssueAttachments`)\n- `models/issues/comment.go:623-642` (`UpdateCommentAttachments`)\n\nBoth functions load attachments by UUID and update the attachment linkage, but neither validates that the attachment row\u0027s `RepoID` matches the repository of the target issue/comment. They also do not reject attachments already linked to a different issue/comment.\n\nAttachment reads then use the linked issue/release repository to decide access:\n\n- `services/repository/repository.go:185-207` returns the repository ID from `IssueID` or `ReleaseID`.\n- `routers/web/repo/attachment.go:153-184` checks read permission on that linked repository.\n- `routers/web/repo/attachment.go:216-224` opens and serves the file from the attachment\u0027s storage path after the linked-repository permission check succeeds.\n\nFor the global `/attachments/{uuid}` route in `routers/web/web.go:872-876`, there is no current repository context, so the early `attach.RepoID` mismatch check in `ServeAttachment` does not protect against this re-linking case.\n\nA patched sibling path already demonstrates the intended invariant: `models/repo/release.go:179-215` rejects release attachments whose `RepoID` differs from the release repository. That guard was introduced for CVE-2026-20736, but the issue/comment paths still lack an equivalent check.\n\n## Impact\n\nAn attacker who can edit an issue/comment in a repository they can read can move a known victim attachment UUID into that repository\u0027s authorization context. After the re-link, the attachment download path resolves access against the attacker-controlled repository while serving the original attachment file.\n\nThis can disclose private issue/comment attachments if the attacker has obtained the UUID through prior legitimate access, copied links, notification content, logs, browser history, or another exposure. The attack does not require write access to the victim repository.\n\n## Reproduction Summary\n\nFull HTTP/E2E observation:\n\n- A local Gitea server was started with an isolated SQLite database.\n- A victim user created private repositories, private issues, and issue attachments containing unique marker strings.\n- An attacker user first attempted to download each victim attachment through `/attachments/{uuid}` and received `404`.\n- The attacker then submitted the victim UUID through the real issue edit route in an attacker-controlled public repository.\n- The same attacker could then download the victim issue attachment through `/attachments/{uuid}` and received `200`; the response body contained the unique issue marker.\n- The attacker repeated the flow through the real comment edit route and could download the second victim attachment with `200`; the response body contained the unique comment marker.\n\nModel-level issue-path behavior:\n\n- A fixture attachment with `RepoID = 2` and `IssueID = 4` was passed to `UpdateIssueAttachments` for attacker issue `ID = 1`, whose `RepoID = 1`.\n- The call succeeded.\n- The attachment row still had `RepoID = 2`, but its `IssueID` was changed to the attacker issue.\n- `GetAttachmentLinkedTypeAndRepoID` then resolved the attachment to attacker repository `RepoID = 1`.\n\nModel-level comment-path behavior:\n\n- The same cross-repository attachment UUID was passed to `UpdateCommentAttachments` for attacker comment `ID = 1`.\n- The call succeeded.\n- The attachment row still had `RepoID = 2`, but its `IssueID` and `CommentID` were changed to the attacker\u0027s issue/comment.\n- The linked repository used for access checks became attacker repository `RepoID = 1`.\n\nNegative control:\n\n- Existing release test `TestAddReleaseAttachmentsRejectsDifferentRepo` passes and confirms the release path rejects the same class of cross-repository attachment linkage.\n\nDetailed verifier and step-by-step runbook are available on request.\n\n## Suggested Fix\n\nAdd repository and linkage validation before updating issue/comment attachments.\n\nRecommended checks:\n\n- Load the target issue for `UpdateIssueAttachments` and derive its `RepoID`.\n- Load the target comment\u0027s issue for `UpdateCommentAttachments` and derive its `RepoID`.\n- Reject any attachment whose `RepoID` differs from the target issue repository.\n- Reject attachments already linked to a different issue/comment/release, except for attachments already linked to the same object being updated.\n- If caller context is available at the web/service layer, also require new unlinked attachments to belong to the current actor or to have been uploaded in the current edit session.\n- Preserve any legacy `RepoID = 0` migration behavior only when it can be proven safe for the target repository.\n\nAlso consider a cleanup/audit query for existing inconsistent rows where `attachment.issue_id != 0` and `attachment.repo_id` differs from the linked issue repository.\n\n## Regression Tests\n\nAdd tests that fail before the fix and pass after it:\n\n- `UpdateIssueAttachments` rejects an attachment whose `RepoID` differs from the target issue\u0027s `RepoID`.\n- `UpdateCommentAttachments` rejects an attachment whose `RepoID` differs from the target comment issue\u0027s `RepoID`.\n- Same-repository unlinked attachment linking still works for normal issue/comment editing.\n- Attachments already linked to a different issue/comment cannot be moved by passing their UUID in `files[]`.\n- Existing release guard test remains passing.",
  "id": "GHSA-6c6r-5xr4-cr5m",
  "modified": "2026-07-21T20:22:58Z",
  "published": "2026-07-21T20:22:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-6c6r-5xr4-cr5m"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/38406"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/38426"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/de4b8277e9cb576f2315fb03b5ab6478b42a1d31"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/f69e15afe7496cc62e96dab244629c69eb31a7bf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: Cross-repository issue/comment attachment re-linking can expose private attachment content"
}

GHSA-6C8M-Q6G9-VRW3

Vulnerability from github – Published: 2026-08-18 20:51 – Updated: 2026-08-18 20:51
VLAI
Summary
Lemur: Authenticated low-privilege users can read plaintext destination credentials (SFTP password / private-key passphrase) via the destinations API
Details

Summary

Lemur's destination read endpoints -- GET /api/1/destinations and GET /api/1/destinations/<id> -- return the full set of stored plugin option values to any authenticated user, with no authorization check and no redaction of secret-bearing options. The sibling write endpoints (POST/PUT/DELETE) are gated with @admin_permission.require(http_exception=403), but the two read handlers are protected only by login_required (inherited from AuthenticatedResource). They do not even exclude read-only users.

The built-in SFTP destination plugin (sftp-destination) stores its password and privateKeyPass options in cleartext in the destinations.options column (the plugin's own docstring states "Passwords are not encrypted and stored as a plain text."). Because DestinationOutputSchema serializes every option value verbatim, any authenticated principal -- including a read-only user -- can retrieve these credentials and use them to authenticate to the remote SFTP server to which Lemur deploys certificates.

Details

Read endpoints lack the authorization that their write siblings enforce:

lemur/destinations/views.py

class DestinationsList(AuthenticatedResource):
    @validate_schema(None, destinations_output_schema)
    def get(self):                       # <-- only login_required; no admin/read-only gate
        ...
        return service.render(args)

    @validate_schema(destination_input_schema, destination_output_schema)
    @admin_permission.require(http_exception=403)   # write path IS gated
    def post(self, data=None): ...

class Destinations(AuthenticatedResource):
    @validate_schema(None, destination_output_schema)
    def get(self, destination_id):       # <-- only login_required; no admin/read-only gate
        return service.get(destination_id)

    @validate_schema(destination_input_schema, destination_output_schema)
    @admin_permission.require(http_exception=403)   # write path IS gated
    def put(self, destination_id, data=None): ...

    @admin_permission.require(http_exception=403)   # write path IS gated
    def delete(self, destination_id): ...

The output schema emits all option values, including secret ones:

lemur/destinations/schemas.py

class DestinationOutputSchema(LemurOutputSchema):
    ...
    options = fields.List(fields.Dict())          # raw option dicts, incl. {"name":"password","value":...}

    @post_dump
    def fill_object(self, data):
        if data:
            data["plugin"]["pluginOptions"] = data["options"]   # copied verbatim into plugin block too
            ...
        return data

options is the raw JSONType DB column (lemur/destinations/models.py), stored exactly as the plugin saved it. The SFTP plugin stores plaintext credentials:

lemur/plugins/lemur_sftp/plugin.py

"""
    Passwords are not encrypted and stored as a plain text.
"""
options = [
    ...
    {"name": "password",       "type": "str", "required": False, ...},   # plaintext
    {"name": "privateKeyPass", "type": "str", "required": False, ...},   # plaintext
    ...
]

There is no read-only enforcement on these GET handlers (no StrictRolePermission() call), so even users explicitly restricted to read-only access can read the secrets.

PoC

Reproduction of Lemur's exact serialization path (verbatim DestinationOutputSchema + PluginOutputSchema, marshmallow 2.21.0), fed a stored SFTP destination row with password auth:

from marshmallow import fields, post_dump, Schema

class PluginOutputSchema(Schema):                 # verbatim from lemur/schemas.py
    id = fields.Integer(); label = fields.String(); description = fields.String()
    active = fields.Boolean(); options = fields.List(fields.Dict(), dump_to="pluginOptions")
    slug = fields.String(); title = fields.String()

class DestinationOutputSchema(Schema):            # verbatim from lemur/destinations/schemas.py
    id = fields.Integer(); label = fields.String(); description = fields.String()
    active = fields.Boolean(); plugin = fields.Nested(PluginOutputSchema)
    options = fields.List(fields.Dict())
    @post_dump
    def fill_object(self, data):
        if data:
            data["plugin"]["pluginOptions"] = data["options"]
            for option in data["plugin"]["pluginOptions"]:
                if "export-plugin" in option["type"]:
                    option["value"]["pluginOptions"] = option["value"]["plugin_options"]
        return data

class Destination:                                # a stored SFTP destination row
    id = 4; label = "prod-nginx-sftp"; description = "Deploy certs via SFTP"; active = True
    options = [
        {"name": "host", "type": "str", "value": "10.0.5.20"},
        {"name": "user", "type": "str", "value": "deploy"},
        {"name": "password", "type": "str", "value": "S3cr3t-SFTP-Passw0rd!"},
        {"name": "privateKeyPass", "type": "str", "value": "rsa-key-passphrase-xyz"},
    ]
    plugin = {"slug": "sftp-destination", "title": "SFTP",
              "description": "Allow the uploading of certificates to SFTP",
              "options": [], "id": 1, "label": None, "active": None}

out = DestinationOutputSchema().dump(Destination()).data
import json; print(json.dumps(out))
assert "S3cr3t-SFTP-Passw0rd!" in json.dumps(out)
assert "rsa-key-passphrase-xyz" in json.dumps(out)

Output (truncated) -- the plaintext secrets appear in both options and plugin.pluginOptions:

{"options":[ ... {"name":"password","type":"str","value":"S3cr3t-SFTP-Passw0rd!"},
 {"name":"privateKeyPass","type":"str","value":"rsa-key-passphrase-xyz"} ...],
 "plugin":{"pluginOptions":[ ... {"name":"password","value":"S3cr3t-SFTP-Passw0rd!"} ...],
 "slug":"sftp-destination", ...}}

End-to-end, as a low-privilege (or read-only) user holding a normal Lemur JWT:

GET /api/1/destinations/4 HTTP/1.1
Host: lemur.example.com
Authorization: Bearer <low-priv-user-token>

HTTP/1.1 200 OK
{ "plugin": { "pluginOptions": [ ... {"name":"password","value":"S3cr3t-SFTP-Passw0rd!"} ... ] } }

Impact

Confidentiality breach of deployment credentials. Any authenticated Lemur user -- regardless of role, including users intentionally limited to read-only -- can enumerate all configured destinations and read their plaintext secrets. For SFTP destinations this yields the SSH password and/or the passphrase protecting the RSA key Lemur uses to push certificates. With these, an attacker authenticates directly to the remote certificate-deployment hosts, replacing or reading their TLS material -- a scope change beyond Lemur itself (S:C). The same read path exposes any other secret-bearing option a destination plugin stores in cleartext.

Suggested fix: gate the destination GET handlers with admin_permission (consistent with the write handlers), and/or redact option values whose type/name marks them as secret before serialization in DestinationOutputSchema.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "lemur"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-71307"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-18T20:51:26Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nLemur\u0027s destination read endpoints -- `GET /api/1/destinations` and `GET /api/1/destinations/\u003cid\u003e` -- return the full set of stored plugin option values to any authenticated user, with no authorization check and no redaction of secret-bearing options. The sibling write endpoints (`POST`/`PUT`/`DELETE`) are gated with `@admin_permission.require(http_exception=403)`, but the two read handlers are protected only by `login_required` (inherited from `AuthenticatedResource`). They do not even exclude `read-only` users.\n\nThe built-in SFTP destination plugin (`sftp-destination`) stores its `password` and `privateKeyPass` options in cleartext in the `destinations.options` column (the plugin\u0027s own docstring states \"Passwords are not encrypted and stored as a plain text.\"). Because `DestinationOutputSchema` serializes every option value verbatim, any authenticated principal -- including a `read-only` user -- can retrieve these credentials and use them to authenticate to the remote SFTP server to which Lemur deploys certificates.\n\n\n### Details\nRead endpoints lack the authorization that their write siblings enforce:\n\n`lemur/destinations/views.py`\n```python\nclass DestinationsList(AuthenticatedResource):\n    @validate_schema(None, destinations_output_schema)\n    def get(self):                       # \u003c-- only login_required; no admin/read-only gate\n        ...\n        return service.render(args)\n\n    @validate_schema(destination_input_schema, destination_output_schema)\n    @admin_permission.require(http_exception=403)   # write path IS gated\n    def post(self, data=None): ...\n\nclass Destinations(AuthenticatedResource):\n    @validate_schema(None, destination_output_schema)\n    def get(self, destination_id):       # \u003c-- only login_required; no admin/read-only gate\n        return service.get(destination_id)\n\n    @validate_schema(destination_input_schema, destination_output_schema)\n    @admin_permission.require(http_exception=403)   # write path IS gated\n    def put(self, destination_id, data=None): ...\n\n    @admin_permission.require(http_exception=403)   # write path IS gated\n    def delete(self, destination_id): ...\n```\n\nThe output schema emits all option values, including secret ones:\n\n`lemur/destinations/schemas.py`\n```python\nclass DestinationOutputSchema(LemurOutputSchema):\n    ...\n    options = fields.List(fields.Dict())          # raw option dicts, incl. {\"name\":\"password\",\"value\":...}\n\n    @post_dump\n    def fill_object(self, data):\n        if data:\n            data[\"plugin\"][\"pluginOptions\"] = data[\"options\"]   # copied verbatim into plugin block too\n            ...\n        return data\n```\n\n`options` is the raw `JSONType` DB column (`lemur/destinations/models.py`), stored exactly as the plugin saved it. The SFTP plugin stores plaintext credentials:\n\n`lemur/plugins/lemur_sftp/plugin.py`\n```python\n\"\"\"\n    Passwords are not encrypted and stored as a plain text.\n\"\"\"\noptions = [\n    ...\n    {\"name\": \"password\",       \"type\": \"str\", \"required\": False, ...},   # plaintext\n    {\"name\": \"privateKeyPass\", \"type\": \"str\", \"required\": False, ...},   # plaintext\n    ...\n]\n```\n\nThere is no `read-only` enforcement on these GET handlers (no `StrictRolePermission()` call), so even users explicitly restricted to read-only access can read the secrets.\n\n\n### PoC\nReproduction of Lemur\u0027s exact serialization path (verbatim `DestinationOutputSchema` + `PluginOutputSchema`, marshmallow 2.21.0), fed a stored SFTP destination row with password auth:\n\n```python\nfrom marshmallow import fields, post_dump, Schema\n\nclass PluginOutputSchema(Schema):                 # verbatim from lemur/schemas.py\n    id = fields.Integer(); label = fields.String(); description = fields.String()\n    active = fields.Boolean(); options = fields.List(fields.Dict(), dump_to=\"pluginOptions\")\n    slug = fields.String(); title = fields.String()\n\nclass DestinationOutputSchema(Schema):            # verbatim from lemur/destinations/schemas.py\n    id = fields.Integer(); label = fields.String(); description = fields.String()\n    active = fields.Boolean(); plugin = fields.Nested(PluginOutputSchema)\n    options = fields.List(fields.Dict())\n    @post_dump\n    def fill_object(self, data):\n        if data:\n            data[\"plugin\"][\"pluginOptions\"] = data[\"options\"]\n            for option in data[\"plugin\"][\"pluginOptions\"]:\n                if \"export-plugin\" in option[\"type\"]:\n                    option[\"value\"][\"pluginOptions\"] = option[\"value\"][\"plugin_options\"]\n        return data\n\nclass Destination:                                # a stored SFTP destination row\n    id = 4; label = \"prod-nginx-sftp\"; description = \"Deploy certs via SFTP\"; active = True\n    options = [\n        {\"name\": \"host\", \"type\": \"str\", \"value\": \"10.0.5.20\"},\n        {\"name\": \"user\", \"type\": \"str\", \"value\": \"deploy\"},\n        {\"name\": \"password\", \"type\": \"str\", \"value\": \"S3cr3t-SFTP-Passw0rd!\"},\n        {\"name\": \"privateKeyPass\", \"type\": \"str\", \"value\": \"rsa-key-passphrase-xyz\"},\n    ]\n    plugin = {\"slug\": \"sftp-destination\", \"title\": \"SFTP\",\n              \"description\": \"Allow the uploading of certificates to SFTP\",\n              \"options\": [], \"id\": 1, \"label\": None, \"active\": None}\n\nout = DestinationOutputSchema().dump(Destination()).data\nimport json; print(json.dumps(out))\nassert \"S3cr3t-SFTP-Passw0rd!\" in json.dumps(out)\nassert \"rsa-key-passphrase-xyz\" in json.dumps(out)\n```\n\nOutput (truncated) -- the plaintext secrets appear in both `options` and `plugin.pluginOptions`:\n```json\n{\"options\":[ ... {\"name\":\"password\",\"type\":\"str\",\"value\":\"S3cr3t-SFTP-Passw0rd!\"},\n {\"name\":\"privateKeyPass\",\"type\":\"str\",\"value\":\"rsa-key-passphrase-xyz\"} ...],\n \"plugin\":{\"pluginOptions\":[ ... {\"name\":\"password\",\"value\":\"S3cr3t-SFTP-Passw0rd!\"} ...],\n \"slug\":\"sftp-destination\", ...}}\n```\n\nEnd-to-end, as a low-privilege (or read-only) user holding a normal Lemur JWT:\n```\nGET /api/1/destinations/4 HTTP/1.1\nHost: lemur.example.com\nAuthorization: Bearer \u003clow-priv-user-token\u003e\n\nHTTP/1.1 200 OK\n{ \"plugin\": { \"pluginOptions\": [ ... {\"name\":\"password\",\"value\":\"S3cr3t-SFTP-Passw0rd!\"} ... ] } }\n```\n\n### Impact\nConfidentiality breach of deployment credentials. Any authenticated Lemur user -- regardless of role, including users intentionally limited to `read-only` -- can enumerate all configured destinations and read their plaintext secrets. For SFTP destinations this yields the SSH password and/or the passphrase protecting the RSA key Lemur uses to push certificates. With these, an attacker authenticates directly to the remote certificate-deployment hosts, replacing or reading their TLS material -- a scope change beyond Lemur itself (S:C). The same read path exposes any other secret-bearing option a destination plugin stores in cleartext.\n\nSuggested fix: gate the destination GET handlers with `admin_permission` (consistent with the write handlers), and/or redact option values whose type/name marks them as secret before serialization in `DestinationOutputSchema`.",
  "id": "GHSA-6c8m-q6g9-vrw3",
  "modified": "2026-08-18T20:51:26Z",
  "published": "2026-08-18T20:51:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/security/advisories/GHSA-6c8m-q6g9-vrw3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/commit/751c970ec42a53d00ecc9c6a96e0e51b6737ae53"
    },
    {
      "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:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Lemur: Authenticated low-privilege users can read plaintext destination credentials (SFTP password / private-key passphrase) via the destinations API"
}

GHSA-6CC3-6HQ4-GC95

Vulnerability from github – Published: 2026-01-22 18:30 – Updated: 2026-01-26 21:30
VLAI
Details

Missing Authorization vulnerability in Brecht WP Recipe Maker wp-recipe-maker allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP Recipe Maker: from n/a through <= 10.2.4.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-24357"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-22T17:16:39Z",
    "severity": "HIGH"
  },
  "details": "Missing Authorization vulnerability in Brecht WP Recipe Maker wp-recipe-maker allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP Recipe Maker: from n/a through \u003c= 10.2.4.",
  "id": "GHSA-6cc3-6hq4-gc95",
  "modified": "2026-01-26T21:30:34Z",
  "published": "2026-01-22T18:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24357"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/wp-recipe-maker/vulnerability/wordpress-wp-recipe-maker-plugin-10-2-4-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:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6CC6-Q8X8-H7VM

Vulnerability from github – Published: 2024-02-27 06:30 – Updated: 2026-04-08 18:32
VLAI
Details

The Thank You Page Customizer for WooCommerce – Increase Your Sales plugin for WordPress is vulnerable to unauthorized execution of shortcodes due to a missing capability check on the get_text_editor_content() function in all versions up to, and including, 1.1.2. This makes it possible for authenticated attackers, with subscriber-level access and above, to execute arbitrary shortcodes.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-1687"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-27T06:15:45Z",
    "severity": "MODERATE"
  },
  "details": "The Thank You Page Customizer for WooCommerce \u2013 Increase Your Sales plugin for WordPress is vulnerable to unauthorized execution of shortcodes due to a missing capability check on the get_text_editor_content() function in all versions up to, and including, 1.1.2. This makes it possible for authenticated attackers, with subscriber-level access and above, to execute arbitrary shortcodes.",
  "id": "GHSA-6cc6-q8x8-h7vm",
  "modified": "2026-04-08T18:32:36Z",
  "published": "2024-02-27T06:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1687"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3041096%40woo-thank-you-page-customizer\u0026new=3041096%40woo-thank-you-page-customizer\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/310afe02-3a51-4633-b359-65ae58d0c032?source=cve"
    }
  ],
  "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"
    }
  ]
}

GHSA-6CCG-P595-WXJR

Vulnerability from github – Published: 2023-12-04 03:30 – Updated: 2023-12-07 00:30
VLAI
Details

In imsservice, there is a possible way to write permission usage records of an app due to a missing permission check. This could lead to local information disclosure with no additional execution privileges needed

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-42671"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-04T01:15:08Z",
    "severity": "MODERATE"
  },
  "details": "In imsservice, there is a possible way to write permission usage records of an app due to a missing permission check. This could lead to local information disclosure with no additional execution privileges needed",
  "id": "GHSA-6ccg-p595-wxjr",
  "modified": "2023-12-07T00:30:37Z",
  "published": "2023-12-04T03:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42671"
    },
    {
      "type": "WEB",
      "url": "https://www.unisoc.com/en_us/secy/announcementDetail/https://www.unisoc.com/en_us/secy/announcementDetail/1731138365803266049"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design
  • Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

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

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

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

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

CAPEC-665: Exploitation of Thunderbolt Protection Flaws

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

← Back to the CWE list