Common Weakness Enumeration

CWE-940

Allowed

Improper Verification of Source of a Communication Channel

Abstraction: Base · Status: Incomplete

The product establishes a communication channel to handle an incoming request that has been initiated by an actor, but it does not properly verify that the request is coming from the expected origin.

92 vulnerabilities reference this CWE, most recent first.

GHSA-G88P-PPWJ-3QFF

Vulnerability from github – Published: 2025-09-24 18:30 – Updated: 2025-09-24 18:30
VLAI
Details

A vulnerability in the IPv6 Router Advertisement (RA) packet processing of Cisco Access Point Software could allow an unauthenticated, adjacent attacker to modify the IPv6 gateway on an affected device.

This vulnerability is due to a logic error in the processing of IPv6 RA packets that are received from wireless clients. An attacker could exploit this vulnerability by associating to a wireless network and sending a series of crafted IPv6 RA packets. A successful exploit could allow the attacker to temporarily change the IPv6 gateway of an affected device. This could also lead to intermittent packet loss for any wireless clients that are associated with the affected device.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-20365"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-940"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-24T17:15:40Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the IPv6 Router Advertisement (RA) packet processing of Cisco Access Point Software could allow an unauthenticated, adjacent attacker to modify the IPv6 gateway on an affected device.\n\n This vulnerability is due to a logic error in the processing of IPv6 RA packets that are received from wireless clients. An attacker could exploit this vulnerability by associating to a wireless network and sending a series of crafted IPv6 RA packets. A successful exploit could allow the attacker to temporarily change the IPv6 gateway of an affected device. This could also lead to intermittent packet loss for any wireless clients that are associated with the affected device.",
  "id": "GHSA-g88p-ppwj-3qff",
  "modified": "2025-09-24T18:30:31Z",
  "published": "2025-09-24T18:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20365"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ap-ipv6-gw-tUAzpn9O"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G8FC-VRCG-8VJG

Vulnerability from github – Published: 2024-04-15 18:13 – Updated: 2024-06-04 19:35
VLAI
Summary
Constallation has pods exposed to peers in VPC
Details

Impact

Cilium allows outside actors (world entity) to directly access pods with their internal pod IP, even if they are not exposed explicitly (e.g. via LoadBalancer). A pod that does not authenticate clients and that does not exclude world traffic via network policy may leak sensitive data to an attacker inside the cloud VPC.

Patches

The issue has been patched in v2.16.3.

Workarounds

This network policy excludes all world traffic. It mitigates the problem, but will also block all desired external traffic. If vulnerable pods are known, a policy can be crafted to only firewall those instead (see also https://docs.cilium.io/en/stable/security/policy/language/#access-to-from-outside-cluster).

apiVersion: "cilium.io/v2"
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: "from-world-to-role-public"
spec:
  endpointSelector:
    matchLabels: {}
    #  role: public
  ingressDeny:
    - fromEntities:
      - world

References

The tracking bug for a Cilium-side fix is https://github.com/cilium/cilium/issues/25626.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/edgelesssys/constellation/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.16.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-940"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-15T18:13:15Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nCilium allows outside actors (`world` entity) to directly access pods with their internal pod IP, even if they are not exposed explicitly (e.g. via `LoadBalancer`). A pod that does not authenticate clients and that does not exclude `world` traffic via network policy may leak sensitive data to an attacker _inside the cloud VPC_.\n\n### Patches\n\nThe issue has been patched in [v2.16.3](https://github.com/edgelesssys/constellation/releases/tag/v2.16.3).\n\n### Workarounds\n\nThis network policy excludes all `world` traffic. It mitigates the problem, but will also block all desired external traffic. If vulnerable pods are known, a policy can be crafted to only firewall those instead (see also https://docs.cilium.io/en/stable/security/policy/language/#access-to-from-outside-cluster).\n\n```yaml\napiVersion: \"cilium.io/v2\"\nkind: CiliumClusterwideNetworkPolicy\nmetadata:\n  name: \"from-world-to-role-public\"\nspec:\n  endpointSelector:\n    matchLabels: {}\n    #  role: public\n  ingressDeny:\n    - fromEntities:\n      - world\n```\n\n### References\n\nThe tracking bug for a Cilium-side fix is https://github.com/cilium/cilium/issues/25626. \n",
  "id": "GHSA-g8fc-vrcg-8vjg",
  "modified": "2024-06-04T19:35:51Z",
  "published": "2024-04-15T18:13:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/edgelesssys/constellation/security/advisories/GHSA-g8fc-vrcg-8vjg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cilium/cilium/issues/25626"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/edgelesssys/constellation"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2024-2727"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Constallation has pods exposed to peers in VPC"
}

GHSA-G8G9-3VC7-2Q6V

Vulnerability from github – Published: 2025-09-05 18:31 – Updated: 2025-09-05 18:31
VLAI
Details

Some payload elements of the messages sent between two stations in a networking architecture are not properly checked on the receiving station allowing an attacker to execute unauthorized commands in the application.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-9999"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-940"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-05T17:15:40Z",
    "severity": "HIGH"
  },
  "details": "Some payload elements of the messages sent between two stations in a networking architecture are not properly checked on the receiving station allowing an attacker to execute unauthorized commands in the application.",
  "id": "GHSA-g8g9-3vc7-2q6v",
  "modified": "2025-09-05T18:31:25Z",
  "published": "2025-09-05T18:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9999"
    },
    {
      "type": "WEB",
      "url": "https://www.pcvue.com/security/#SB2025-4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:Y/R:U/V:X/RE:M/U:Green",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-H645-7253-PP3X

Vulnerability from github – Published: 2024-07-16 21:30 – Updated: 2024-08-01 15:32
VLAI
Details

An issue in H3C Technologies Co., Limited H3C Magic RC3000 RC3000V100R009 allows a remote attacker to execute arbitrary code via the Routing functionality.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-40516"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-940"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-16T19:15:13Z",
    "severity": "HIGH"
  },
  "details": "An issue in H3C Technologies Co., Limited H3C Magic RC3000 RC3000V100R009 allows a remote attacker to execute arbitrary code via the Routing functionality.",
  "id": "GHSA-h645-7253-pp3x",
  "modified": "2024-08-01T15:32:02Z",
  "published": "2024-07-16T21:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40516"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/as-lky/2acc62c6283c7a1fe3af046b05091d15"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HC77-8V8P-W9RP

Vulnerability from github – Published: 2024-06-17 18:31 – Updated: 2024-08-01 15:31
VLAI
Details

Redmi router RB03 v1.0.57 is vulnerable to TCP DoS or hijacking attacks. An attacker in the same WLAN as the victim can disconnect or hijack the traffic between the victim and any remote server by sending out forged TCP RST messages to evict NAT mappings in the router.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-37664"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-940"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-17T18:15:17Z",
    "severity": "LOW"
  },
  "details": "Redmi router RB03 v1.0.57 is vulnerable to TCP DoS or hijacking attacks. An attacker in the same WLAN as the victim can disconnect or hijack the traffic between the victim and any remote server by sending out forged TCP RST messages to evict NAT mappings in the router.",
  "id": "GHSA-hc77-8v8p-w9rp",
  "modified": "2024-08-01T15:31:49Z",
  "published": "2024-06-17T18:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37664"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ouuan/router-vuln-report/blob/master/nat-rst/redmi-rb03-nat-rst.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J4H9-5VJ5-4VFF

Vulnerability from github – Published: 2024-02-13 09:30 – Updated: 2024-02-13 09:30
VLAI
Details

A vulnerability has been identified in SIMATIC CP 343-1 (6GK7343-1EX30-0XE0) (All versions), SIMATIC CP 343-1 Lean (6GK7343-1CX10-0XE0) (All versions), SIPLUS NET CP 343-1 (6AG1343-1EX30-7XE0) (All versions), SIPLUS NET CP 343-1 Lean (6AG1343-1CX10-2XE0) (All versions). Affected products incorrectly validate TCP sequence numbers. This could allow an unauthenticated remote attacker to create a denial of service condition by injecting spoofed TCP RST packets.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-51440"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-940"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-13T09:15:46Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in SIMATIC CP 343-1 (6GK7343-1EX30-0XE0) (All versions), SIMATIC CP 343-1 Lean (6GK7343-1CX10-0XE0) (All versions), SIPLUS NET CP 343-1 (6AG1343-1EX30-7XE0) (All versions), SIPLUS NET CP 343-1 Lean (6AG1343-1CX10-2XE0) (All versions). Affected products incorrectly validate TCP sequence numbers. This could allow an unauthenticated remote attacker to create a denial of service condition by injecting spoofed TCP RST packets.",
  "id": "GHSA-j4h9-5vj5-4vff",
  "modified": "2024-02-13T09:30:32Z",
  "published": "2024-02-13T09:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51440"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-516818.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JF7P-XVX5-8827

Vulnerability from github – Published: 2023-10-04 21:30 – Updated: 2024-04-04 08:18
VLAI
Details

TouchLink packets processed after timeout or out of range due to Operation on a Resource after Expiration and Missing Release of Resource after Effective Lifetime may allow a device to be added outside of valid TouchLink range or pairing duration

This issue affects Ember ZNet 7.1.x from 7.1.3 through 7.1.5; 7.2.x from 7.2.0 through 7.2.3; Version 7.3 and later are unaffected

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-41094"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672",
      "CWE-940"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-04T21:15:09Z",
    "severity": "CRITICAL"
  },
  "details": "\nTouchLink packets processed after timeout or out of range due to Operation on a Resource after Expiration and Missing Release of Resource after Effective Lifetime may allow a device to be added outside of valid TouchLink range or pairing duration\n\nThis issue affects Ember ZNet 7.1.x from 7.1.3 through 7.1.5; 7.2.x from 7.2.0 through 7.2.3; Version 7.3 and later are unaffected\n\n\n",
  "id": "GHSA-jf7p-xvx5-8827",
  "modified": "2024-04-04T08:18:46Z",
  "published": "2023-10-04T21:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41094"
    },
    {
      "type": "WEB",
      "url": "https://community.silabs.com/0688Y00000aIPzL"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M3PM-RPGG-5WJ6

Vulnerability from github – Published: 2025-02-18 19:25 – Updated: 2025-02-18 22:51
VLAI
Summary
Home Assistant does not correctly validate SSL for outgoing requests in core and used libs
Details

Summary

Problem: Potential man-in-the-middle attacks due to missing SSL certificate verification in the project codebase and used third-party libraries.

Details

In the past, aiohttp-session/request had the parameter verify_ssl to control SSL certificate verification. This was a boolean value. In aiohttp 3.0, this parameter was deprecated in favor of the ssl parameter. Only when ssl is set to None or provided with a correct configured SSL context the standard SSL certificate verification will happen.

When migrating integrations in Home Assistant and libraries used by Home Assistant, in some cases the verify_ssl parameter value was just moved to the new ssl parameter. This resulted in these integrations and 3rd party libraries using request.ssl = True, which unintentionally turned off SSL certificate verification and opened up a man-in-the-middle attack vector.

Example: https://github.com/home-assistant/core/blob/c4411914c2e906105b765c00af5740bd0880e946/homeassistant/components/discord/notify.py#L84

When you scan the libraries used by the integrations in Home Assistant, you will find more issues like this.

The general handling in Home Assistant looks good, as homeassistant.helpers.aoihttp_client._async_get_connector handles it correctly.

PoC

  1. Check that expired.badssl.com:443 gives an SSL error in when connecting with curl or browser.
  2. Add the integration adguard with the setting host=expired.badssl.com, port=443, use-ssl=true, verify-ssl=true.
  3. Check the logs - you get a HTTP 403 response.

Expected behavior: 1. The integration log shows an ssl.SSLCertVerificationError.

The following code shows the problem with ssl=True. No exception is raised when ssl=True (Python 3.11.6).

import asyncio
from ssl import SSLCertVerificationError

import aiohttp

BAD_URL = "https://expired.badssl.com/"


async def run_request(verify_ssl, result_placeholder: str):
    async with aiohttp.ClientSession() as session:
        exception_fired: bool = False
        try:
            await session.request("OPTIONS", BAD_URL, ssl=verify_ssl)
        except SSLCertVerificationError:
            exception_fired = True
        except Exception as error:
            print(error)
        else:
            exception_fired = False
        print(result_placeholder.format(exception_result=exception_fired))


# Case 1: ssl=False --> expected result: No exception
asyncio.run(run_request(False, "Test case 1: expected result: False - result: {exception_result}"))

# Case 2: ssl=None --> expected result: Exception
asyncio.run(run_request(None, "Test case 2: expected result: True - result: {exception_result}"))

# Case 3: ssl=True --> expected result: No Exception
asyncio.run(run_request(True, "Test case 3: expected result: False - result: {exception_result}"))

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "homeassistant"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2024.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-25305"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347",
      "CWE-940"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-18T19:25:24Z",
    "nvd_published_at": "2025-02-18T19:15:29Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nProblem: Potential man-in-the-middle attacks due to missing SSL certificate verification in the project codebase and used third-party libraries.\n\n## Details\n\nIn the past, `aiohttp-session`/`request` had the parameter `verify_ssl` to control SSL certificate verification. This was a boolean value. In `aiohttp` 3.0, this parameter was deprecated in favor of the `ssl` parameter. Only when `ssl` is set to `None` or provided with a correct configured SSL context the standard SSL certificate verification will happen.\n\nWhen migrating integrations in Home Assistant and libraries used by Home Assistant, in some cases the `verify_ssl` parameter value was just moved to the new `ssl` parameter. This resulted in these integrations and 3rd party libraries using `request.ssl = True`, which unintentionally turned off SSL certificate verification and opened up a man-in-the-middle attack vector.\n\nExample:\nhttps://github.com/home-assistant/core/blob/c4411914c2e906105b765c00af5740bd0880e946/homeassistant/components/discord/notify.py#L84\n\nWhen you scan the libraries used by the integrations in Home Assistant, you will find more issues like this.\n\nThe general handling in Home Assistant looks good, as `homeassistant.helpers.aoihttp_client._async_get_connector` handles it correctly.\n\n## PoC\n\n1. Check that expired.badssl.com:443 gives an SSL error in when connecting with curl or browser.\n2. Add the integration adguard with the setting `host=expired.badssl.com`, `port=443`, `use-ssl=true`, `verify-ssl=true`.\n3. Check the logs - you get a HTTP 403 response.\n\nExpected behavior:\n1. The integration log shows an `ssl.SSLCertVerificationError`.\n\nThe following code shows the problem with `ssl=True`. No exception is raised when `ssl=True` (Python 3.11.6).\n\n```\nimport asyncio\nfrom ssl import SSLCertVerificationError\n\nimport aiohttp\n\nBAD_URL = \"https://expired.badssl.com/\"\n\n\nasync def run_request(verify_ssl, result_placeholder: str):\n    async with aiohttp.ClientSession() as session:\n        exception_fired: bool = False\n        try:\n            await session.request(\"OPTIONS\", BAD_URL, ssl=verify_ssl)\n        except SSLCertVerificationError:\n            exception_fired = True\n        except Exception as error:\n            print(error)\n        else:\n            exception_fired = False\n        print(result_placeholder.format(exception_result=exception_fired))\n\n\n# Case 1: ssl=False --\u003e expected result: No exception\nasyncio.run(run_request(False, \"Test case 1: expected result: False - result: {exception_result}\"))\n\n# Case 2: ssl=None --\u003e expected result: Exception\nasyncio.run(run_request(None, \"Test case 2: expected result: True - result: {exception_result}\"))\n\n# Case 3: ssl=True --\u003e expected result: No Exception\nasyncio.run(run_request(True, \"Test case 3: expected result: False - result: {exception_result}\"))\n\n```",
  "id": "GHSA-m3pm-rpgg-5wj6",
  "modified": "2025-02-18T22:51:42Z",
  "published": "2025-02-18T19:25:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/home-assistant/core/security/advisories/GHSA-m3pm-rpgg-5wj6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25305"
    },
    {
      "type": "WEB",
      "url": "https://github.com/home-assistant/core/commit/8c6547f1b64f4a3d9f10090b97383353c9367892"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/home-assistant/core"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Home Assistant does not correctly validate SSL for outgoing requests in core and used libs"
}

GHSA-MF23-WM84-G9X3

Vulnerability from github – Published: 2025-01-14 21:31 – Updated: 2025-11-03 21:32
VLAI
Details

IPv4-in-IPv6 and IPv6-in-IPv6 tunneling (RFC 2473) do not require the validation or verification of the source of a network packet, allowing an attacker to spoof and route arbitrary traffic via an exposed network interface. This is a similar issue to CVE-2020-10136.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-23018"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-940"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-14T20:15:32Z",
    "severity": "MODERATE"
  },
  "details": "IPv4-in-IPv6 and IPv6-in-IPv6 tunneling (RFC 2473) do not require the validation or verification of the source of a network packet, allowing an attacker to spoof and route arbitrary traffic via an exposed network interface. This is a similar issue to CVE-2020-10136.",
  "id": "GHSA-mf23-wm84-g9x3",
  "modified": "2025-11-03T21:32:09Z",
  "published": "2025-01-14T21:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23018"
    },
    {
      "type": "WEB",
      "url": "https://datatracker.ietf.org/doc/html/rfc2473"
    },
    {
      "type": "WEB",
      "url": "https://papers.mathyvanhoef.com/usenix2025-tunnels.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.kb.cert.org/vuls/id/199397"
    },
    {
      "type": "WEB",
      "url": "https://www.top10vpn.com/research/tunneling-protocol-vulnerability"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MFVQ-M3JJ-8864

Vulnerability from github – Published: 2022-12-28 15:30 – Updated: 2023-01-10 15:40
VLAI
Summary
usememos/memos vulnerable to Improper Verification of Source of a Communication Channel
Details

usememos/memos 0.9.0 and prior is vulnerable to Improper Verification of Source of a Communication Channel.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/usememos/memos"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-4800"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-940"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-30T19:57:43Z",
    "nvd_published_at": "2022-12-28T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "usememos/memos 0.9.0 and prior is vulnerable to Improper Verification of Source of a Communication Channel.",
  "id": "GHSA-mfvq-m3jj-8864",
  "modified": "2023-01-10T15:40:34Z",
  "published": "2022-12-28T15:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4800"
    },
    {
      "type": "WEB",
      "url": "https://github.com/usememos/memos/commit/3556ae4e651d9443dc3bb8a170dd3cc726517a53"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/usememos/memos"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/aa45a6eb-cc38-45e5-a301-221ef43c0ef8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "usememos/memos vulnerable to Improper Verification of Source of a Communication Channel"
}

Mitigation
Architecture and Design
  • Use a mechanism that can validate the identity of the source, such as a certificate, and validate the integrity of data to ensure that it cannot be modified in transit using an Adversary-in-the-Middle (AITM) attack.
  • When designing functionality of actions in the URL scheme, consider whether the action should be accessible to all mobile applications, or if an allowlist of applications to interface with is appropriate.
CAPEC-500: WebView Injection

An adversary, through a previously installed malicious application, injects code into the context of a web page displayed by a WebView component. Through the injected code, an adversary is able to manipulate the DOM tree and cookies of the page, expose sensitive information, and can launch attacks against the web application from within the web page.

CAPEC-594: Traffic Injection

An adversary injects traffic into the target's network connection. The adversary is therefore able to degrade or disrupt the connection, and potentially modify the content. This is not a flooding attack, as the adversary is not focusing on exhausting resources. Instead, the adversary is crafting a specific input to affect the system in a particular way.

CAPEC-595: Connection Reset

In this attack pattern, an adversary injects a connection reset packet to one or both ends of a target's connection. The attacker is therefore able to have the target and/or the destination server sever the connection without having to directly filter the traffic between them.

CAPEC-596: TCP RST Injection

An adversary injects one or more TCP RST packets to a target after the target has made a HTTP GET request. The goal of this attack is to have the target and/or destination web server terminate the TCP connection.