Cyber Resilience

CVE-2026-48817

Encode Starlette ≤ 1.1.0

Published
17 June 2026
Modified
26 June 2026
Patch / advisory
CVSS Score v3.1 5.3
Click a component to see what it means
Raw vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score 0.0021 12th percentile
Risk Priority 44 floored blend · peak EPSS

Summary

CVE-2026-48817 is a medium-severity Unsafe Reflection (CWE-470) vulnerability in Encode Starlette. Its CVSS base score is 5.3 (Medium).

Operationally, exploitation aligns with the MITRE ATT&CK technique Reflective Code Loading (T1620); ranked at the 12th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

The strongest mitigations our analysis identified map to SI-10 (Information Input Validation) and AC-3 (Access Enforcement) — see the control section below for these in your framework.

OWASP Top 10 for Web (2025)

EU & UK References

Vulnerability Data

Starlette is a lightweight ASGI framework/toolkit. In versions 1.0.1 and below, when dispatching a request, HTTPEndpoint selects the handler by lowercasing the HTTP method and looking it up as an attribute with getattr, without restricting the lookup to a known…

more

set of HTTP verbs. When an HTTPEndpoint subclass is registered through Route(...) without an explicit methods= argument, the route does not constrain the method and every method reaches the endpoint. If a non-standard HTTP method whose lowercased name matches an attribute on the endpoint subclass reaches the endpoint, that attribute is invoked as if it were a request handler. An attacker can use this to reach methods that were never meant to be HTTP handlers, such as internal helpers, without the authorization checks applied by the intended public handler. An application (including Starlette-based frameworks like FastAPI) is affected if it registers an HTTPEndpoint subclass via Route(...) without explicitly setting methods=, and that subclass includes extra methods named like non-standard HTTP verbs that take one request argument and return a response. This issue has been fixed in version 1.1.0.

CWE(s)

Related Threats

MITRE ATT&CK Enterprise Techniques

T1620 Reflective Code Loading Stealth
Adversaries may reflectively load code into a process in order to conceal the execution of malicious payloads.
Derived from this CVE’s CWE(s) via the direct CWE→ATT&CK cross-walk.

CVEs Like This One

CVE-2026-48818Same product: Encode Starlette
CVE-2023-29159Same product: Encode Starlette
CVE-2026-54283Same product: Encode Starlette
CVE-2023-30798Same product: Encode Starlette
CVE-2026-54282Same product: Encode Starlette
CVE-2026-48710Same product: Encode Starlette
CVE-2026-25498Shared CWE-470
CVE-2026-8178Shared CWE-470
CVE-2025-12967Shared CWE-470
CVE-2026-41175Shared CWE-470

Affected Assets

encode
starlette
≤ 1.1.0

Mitigating Controls

Mitigating Controls (NIST 800-53 r5) AI

Input validation directly stops externally supplied class or method names from selecting improper code via reflection.

Enforces authorization checks on the code or classes ultimately invoked, blocking unauthorized selections even if reflection is used.

Limits privileges of any code reached through unsafe reflection, reducing blast radius without stopping the selection itself.

Mitigating Controls (NIST CSF 2.0) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.

PR.PS-06 mostly match
prevents

Secure SDLC practices directly avoid introducing externally controlled class selection via reflection.

ID.RA-01 partial match
prevents

Vulnerability identification processes can discover unsafe reflection during code review or scanning.

PR.PS-05 partial match
prevents

Preventing execution of unauthorized code can block exploitation of unsafe reflection at runtime.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

prevents

Secure coding standards directly forbid unsafe reflection and require whitelisting or static alternatives.

finds

Security testing can detect and block unsafe reflection patterns before release.

prevents

Secure development lifecycle mandates input validation and design reviews that reduce unsafe reflection risks.

prevents

Application security requirements can explicitly prohibit or constrain reflection based on untrusted input.

prevents

Secure architecture principles discourage dynamic class loading from external data sources.

none

Access restrictions limit who can supply the malicious input but do not address the reflection flaw itself.

References