CVE-2026-39958
Raw vector
CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2026-39958 is a medium-severity CRLF Injection (CWE-93) vulnerability. Its CVSS base score is 5.2 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique Content Injection (T1659); ranked at the 29th 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) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-39958 is a vulnerability in the oma package manager for AOSC OS, specifically affecting the oma-topics component prior to version 1.25.2. oma-topics fetches metadata known as "Topic Manifests" from remote repository servers at paths like {mirror}/debs/manifest/topics.json and registers them as APT source entries. The name field in these manifests is not checked for transliteration issues, allowing malformed manifests to inject unauthorized entries into /etc/apt/sources.list.d/atm.list during the fetching and registration process. The vulnerability is rated at CVSS 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H) and maps to CWE-93.
A remote attacker who can supply a malformed Topic Manifest—such as by controlling a mirror or testing repository—can exploit this with network access, low complexity, no privileges, and no user interaction. Successful exploitation causes oma-topics to add attacker-controlled APT source entries to the system's sources list, potentially enabling the installation of malicious packages and compromising system integrity and availability.
The vulnerability is fixed in oma version 1.25.2. Mitigation details are provided in the GitHub security advisory at GHSA-86jc-7r6q-cr3f, pull request #733, commit b361c0f219bbf91a684610c76210f71f093dbc18, and the release notes for v1.25.2. Security practitioners should ensure systems update to at least version 1.25.2.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-20962
Vulnerability Data
oma is a package manager for AOSC OS. Prior to 1.25.2, oma-topics is responsible for fetching metadata for testing repositories (topics) named "Topic Manifests" ({mirror}/debs/manifest/topics.json) from remote repository servers, registering them as APT source entries. However, the name field in…
more
said metadata were not checked for transliteration. In this case, a malicious party may supply a malformed Topic Manifest, which may cause malicious APT source entries to be added to /etc/apt/sources.list.d/atm.list as oma-topics finishes fetching and registering metadata. This vulnerability is fixed in 1.25.2.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V4.2.4
Mitigating Controls (NIST 800-53 r5) AI
Input validation directly stops untrusted data containing CRLF sequences from reaching the component that treats CRLF as a delimiter.
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 directly require input neutralization and validation to block CRLF injection.
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.
Security testing can detect CRLF flaws but does not itself implement the neutralization.
Secure development lifecycle mandates input validation and output encoding that directly prevents CRLF injection.
Application security requirements include rules for neutralizing special characters such as CRLF in inputs.
Secure architecture principles encourage safe handling of untrusted data but do not prescribe specific CRLF controls.
Secure coding standards explicitly require neutralization of CRLF sequences, fully addressing this weakness.