CVE-2023-0460
Google Youtube Android Player Api 1.2 – 1.2.2
Raw vector
CVSS:3.1/AV:A/AC:H/PR:L/UI:R/S:U/C:L/I:H/A:NCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2023-0460 is a medium-severity Unsafe Reflection (CWE-470) vulnerability in Google Youtube Android Player Api. Its CVSS base score is 5.1 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique Data Obfuscation (T1001); ranked at the 1th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2023-12514
Vulnerability Data
The YouTube Embedded 1.2 SDK binds to a service within the YouTube Main App. After binding, a remote context is created with the flags Context.CONTEXT_INCLUDE_CODE | Context.CONTEXT_IGNORE_SECURITY. This allows the client app to remotely load code from YouTube Main App…
more
by retrieving the Main App’s ClassLoader. A potential vulnerability in the binding logic used by the client SDK where the SDK ends up calling bindService() on a malicious app rather than YT Main App. This creates a vulnerability where the SDK can load the malicious app’s ClassLoader instead, allowing the malicious app to load arbitrary code into the calling app whenever the embedded SDK is invoked. In order to trigger this vulnerability, an attacker must masquerade the Youtube app and install it on a device, have a second app that uses the Embedded player and typically distribute both to the victim outside of the Play Store.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Likely Mitigating Controls AI
Per-CVE control mapping for this CVE has not run yet; the list below is derived from the weakness types (CWEs) cited in the NVD entry.
Externally controlled class or code selection can be resolved and invoked inside the chamber, surfacing unsafe reflection without system impact.
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.
Vulnerability identification processes can discover unsafe reflection during code review or scanning.
Preventing execution of unauthorized code can block exploitation of unsafe reflection at runtime.
Secure SDLC practices directly avoid introducing externally controlled class selection via reflection.
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.
A.8.25 mandates secure SDLC practices including secure coding guidelines, security requirements, checkpoints, testing (scans/penetration), and developer training that can catch/prevent unsafe reflection flaws during development; this stops exploitation for a minority slice (first-party code written under the process) but leaves the bulk of the weakness (e.g. in third-party libraries, legacy code, or incomplete enforcement) untouched.
Application security requirements can explicitly prohibit or constrain reflection based on untrusted input.
A.8.27 mandates security-by-design principles (e.g. distrust external input, least privilege, secure session control, data validation/sanitization, design reviews against attack patterns) that reach a slice of unsafe reflection cases but leave a bounded remainder (e.g. reflection in third-party libraries or dynamic class loading where principles are applied incompletely).
Secure coding standards directly forbid unsafe reflection and require whitelisting or static alternatives.