CVE-2023-3635
Squareup Okio 0.5.0 – 1.17.6
Raw vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:HCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2023-3635 is a medium-severity Signed to Unsigned Conversion Error (CWE-195) vulnerability in Squareup Okio. Its CVSS base score is 5.9 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique Data Obfuscation (T1001); ranked in the top 31% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2023-2158
Vulnerability Data
GzipSource does not handle an exception that might be raised when parsing a malformed gzip buffer. This may lead to denial of service of the Okio client when handling a crafted GZIP archive, by using the GzipSource class.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
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.
Secure SDLC practices (static analysis, code review, safe-integer standards) directly prevent signed-to-unsigned conversion errors.
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.
Secure development life cycle mandates practices that can catch signed-to-unsigned conversion errors during design and coding.
A.8.26 only requires that security requirements (including resilience against attacks such as buffer overflows or SQL injection) be identified and specified during development or acquisition; it does not itself enforce, implement, or prevent the signed-to-unsigned conversion error from arising or being exploitable.
A.8.27 mandates establishing and applying security engineering principles (e.g. least privilege, security by design, hardening) and design reviews during the SDLC; it does not stop a signed-to-unsigned conversion error from being exploitable if the flawed code is written and deployed.
Secure coding standards directly prohibit unsafe signed-to-unsigned casts and require defensive checks.
Security testing in development can detect conversion-related defects before release.